Test Cases for the One-Card Network Card Miniport Driver Test (Windows Embedded CE 6.0)
1/6/2010
The following table shows the test cases for the One-Card Network Card Miniport Driver Test.
| Test case | Description |
|---|---|
1 |
Open\Close Tests the ability to open and close an adapter multiple times. A Miniport driver is shielded from the opening of an adapter by the Ndt.dll protocol driver. As a result, this test case tests the Ndt.dll protocol driver rather than the miniport driver. This test case opens and closes one instance of NdisOpen 16 times, and then opens and closes 128 concurrent instances of NdisOpen 16 times. This test fails if the miniport driver has a problem with multiple open instances of NdisOpen. |
2 |
Send Tests the ability to send data both singularly and in bursts. The test case attempts to send data to the various address types supported by the media type of the current driver. This test case fails if a problem occurs with sending packets. |
3 |
Loopback send Tests for the ability to receive loopback packets with a variety of address types on multiple filter settings. The test uses one open instance to send loopback packets and eight instances to receive the packets. Each of the eight instances receiving the packets has a different filter setting, which allows for all supported filter settings to be tested quickly. This test case also verifies that no open instance receives a packet that it should not be receiving. This test case fails if a problem occurs with a filter setting in a driver. |
4 |
Loopback stress Creates packets with various buffer configurations in order to perform 10 instances of the stress test on the loopback packets. This test case fails if a memory leak is detected. |
5 |
Set multicast Tests the ability of the Ethernet and Fiber Distributed Data Interface (FDDI) drivers to create multiple multicast addresses. The test does not verify that the card is able to receive on each of the different addresses. The test verifies only that multicast addresses can be set and deleted. |
6 |
Reset Attempts to reset the network card multiple times while simultaneously sending large numbers of packets. The test also verifies that the card can reset itself in order to properly handle packets that are ready to send when interrupted by a reset. This test case fails if the operation that resets the network card is implemented incorrectly. |
7 |
Cancel send Runs the performance command with a flag that causes the Ndt.dll protocol driver to cancel packets. The performance command queues 100 packets to send. In the next packet to send, the performance command sets the cancel identification, and then attempts to cancel the send operation. This test case fails if an improper cancellation of a packet occurs. |
8 |
Fault handling Sets bits in the registry for the network card driver using the fault injection NDIS technology. These bits cause NDIS to fail the NdisMAllocateMapRegisters, NdisMRegisterInterrupt, NdisMAllocateSharedMemory, NdisMMapIoSpace, NdisMRegisterIoPortRange, ReadNdisGetSetBusConfigSpace, WriteNdisGetSetBusConfigSpace, and NdisMInitializeScatterGatherDma functions. The driver should not load correctly unless it does not call a particular function. |
9 |
Object identifiers Performs a series of NdisRequest function calls to the driver. Verifies that the driver supports the querying of all required object identifiers. |
10 |
64 bit object identifiers Tests the OID_GEN_XMIT_OK and OID_GEN_RCV_OK object identifiers to verify that all queries are handled properly. Each object identifier is queried three times. The object identifier is queried once with a null buffer, once with a 4-byte buffer and once with an 8-byte buffer. |
11 |
Suspend and then resume Tests the behavior of the network card driver when the test suspends and then resumes the operating system (OS). If the run-time image does not support the IOCTL_HAL_ENABLE_WAKE IOCTL or does not wake in response to a SYSINTR_RTC_ALARM interrupt, this test case is skipped. This test case suspends and then resumes the OS 5 times and then attempts to send data over the network card driver to verify that the driver is functional. |
12 |
Stress suspend and then resume Tests power management of the network card driver and stresses the network card driver under suspend and resume operations. This test case has three threads. The main thread performs suspend and resume operations. The second thread sends data continuously over the network card driver. The third thread queries object identifiers (OIDs) continuously. If the network card driver supports power management, the main thread requests that Device Manager put the network card into a D4 state. After one second, the main thread requests that Device Manager restore the network card to a D0 state. If the network card driver does not support power management, the main thread performs a reset operation on the network card and then waits for a random interval of time. This test case assesses the ability of the network card driver to process send requests and OID requests while undergoing power transition. This test case performs 25 suspend and then resume operations. |
13 |
Reset on resume Tests the ability of the network card driver to restore its original settings when a resume operation resets the network card driver. This test case first sets a packet filter, multicast list size, and look-ahead buffer size. This test case then adds multicast addresses to the multicast list. After a reset operation, this test case verifies that the network card driver preserves its original settings. |