DF – Fuzz – Test zum Öffnen und Schließen (Zuverlässigkeit)
Dieser Test führt Tausende von create-open-close-Sequenzen aus und verwendet mehrere verschiedene Möglichkeiten zum Öffnen und Schließen von Instanzen des angegebenen Geräts oder Gerätes: Basic Open Operations, Direct Device Open Operations und ein Open- und Close-Stresstest.
Grundlegende Geöffnete Vorgänge
Während der grundlegenden Geöffneten Vorgänge öffnet der Fuzz-Test wiederholt Instanzen der angegebenen Geräte oder die Geräte, die von dem angegebenen Treiber exportiert wurden, mithilfe verschiedener Methoden und Optionen.
Der Fuzz-Test führt immer die Grundlegenden Geöffneten Vorgänge aus. Sie müssen sie nicht auswählen, und Sie können sie nicht aus einer Testsitzung ausschließen.
Der Fuzz-Test führt alle geöffneten Vorgänge im Benutzermodus durch Aufrufen von Systemdiensten (ZwXxx Routinen) aus, die für das Gerät geeignet sind. Wenn ein geöffneter Aufruf einen Handle an das Gerät zurückgibt, verwendet der Fuzz-Test den Handle, um die anderen Gerätetests auszuführen, die für die Testsitzung ausgewählt sind.
Es gibt fünf Arten von grundlegenden geöffneten Vorgängen:
Standard geöffnet: Der Fuzz-Test öffnet das Gerät asynchron und gibt nur den systemeigenen Gerätenamen an.
Öffnen Sie mit hinzugefügtem Backslash: Der Fuzz-Test stellt einen geöffneten Aufruf für den Gerätenamen dar, gefolgt von einem Backslash (), z. B. \device\cdrom\, wie wenn der Aufruf ein Stammverzeichnis innerhalb des Geräts öffnen sollte.
Dieser Vorgang bestimmt, wie das Treiber- oder Dateisystem offene Anforderungen im Namespace verwaltet. Wenn das Gerät in seinem Namespace keine geöffneten Anforderungen unterstützt, muss der Treiber nicht autorisierten Zugriff verhindern, entweder durch Fehler der Anforderungen oder durch Festlegen der FILE_DEVICE_SECURE_OPEN Geräteeigenschaft beim Aufrufen von IoCreateDevice oder IoCreateDeviceSecure zum Erstellen des Geräteobjekts.
Öffnen Sie als benannte Rohre: Der Fuzz-Test öffnet das Gerät und legt ein benanntes Rohr auf das Gerät fest. Der Zugriffsparameter (ShareAccess) wird zunächst auf Lese- und Schreibzugriff festgelegt, wird jedoch angepasst, wenn die Anforderung fehlschlägt. Wenn das Gerät keine benannten Rohre unterstützt, sollte die Anforderung fehlschlagen.
Öffnen Sie als Maillot: Der Fuzz-Test öffnet das Gerät als Mailslot. Wenn das Gerät diesen Verbindungstyp nicht unterstützt, sollte die Anforderung fehlschlagen.
Öffnen Sie als Strukturverbindung: Der Fuzz-Test öffnet das Gerät als Strukturverbindung für die Verwendung in Remotenetzwerkzugriff. Der Zugriffsparameter (ShareAccess) wird zunächst auf Lese- und Schreibzugriff festgelegt, wird jedoch angepasst, wenn die Anforderung fehlschlägt. Wenn das Gerät diesen Verbindungstyp nicht unterstützt, sollte die Anforderung fehlschlagen.
Die Parameter, die in den geöffneten Anrufen verwendet werden, variieren, um die Merkmale des Geräts zu erfüllen und wahrscheinlich, dass die Anrufe erfolgreich sind. Wenn beispielsweise ein einfacher geöffneter Vorgang fehlschlägt, da der Aufruf die Sicherheitsanforderungen des Geräts nicht erfüllt hat, wiederholt der Fuzz-Test den geöffneten Vorgang mit einer Anforderung für weniger Zugriff. Wenn z. B. ein geöffneter Vorgang, der den Schreibzugriff angefordert hat, einen Sicherheitsverletzungsfehler zurückgibt, wird der Geöffnete mit einer Anforderung für den Lesezugriff wiederholt.
Direkte Geräte geöffnete Vorgänge
Während des Direct Device Open Operations öffnet der Fuzz-Test das Gerät direkt, als Gerät, nicht als Datei in einem Dateisystem. Direct Device Open Operations sind immer synchron. Wenn der Aufruf erfolgreich ist, verwendet der Fuzz-Test den zum Ausführen anderer ausgewählter Tests bereitgestellten Handle.
Test öffnen und schließen
Während des Open- und Close-Tests erstellt der Fuzz-Test mehrere Threads, von denen jede Tausende von create-open-close-Sequenzen ausführt. Dadurch wird die Fähigkeit des Fahrers getestet, ein außergewöhnliches Volumen von andernfalls einfachen und erwarteten Anrufen zu behandeln.
Der Open- und Close-Test verwendet dieselben Optionen, die in basic Open Operation und Open with Added Backslash-Tests verwendet werden und direkt vor diesen Tests ausgeführt werden.
Binärdatei testen: Devfund_FuzzTest.dll Testmethode: DoOpenCloseTest
Testdetails
| Spezifikationen |
|
| Plattformen |
|
| Unterstützte Versionen |
|
| Voraussichtliche Laufzeit (in Minuten) | 15 |
| Kategorie | Szenario |
| Zeitüberschreitung (in Minuten) | 180 |
| Neustart erforderlich | false |
| Erfordert eine spezielle Konfiguration | true |
| Typ | automatic |
Zusätzliche Dokumentation
Tests in diesem Funktionsbereich enthalten möglicherweise zusätzliche Dokumentation, einschließlich Informationen zu Voraussetzungen, Einrichtung und Fehlerbehebung, die in den folgenden Themen zu finden sind:
Ausführen des Tests
Bevor Sie den Test ausführen, vervollständigen Sie die Testeinrichtung wie in den Testanforderungen beschrieben: Device.Fundamentals Reliability Testing Prerequisites.
Problembehandlung
Informationen zur allgemeinen Problembehandlung bei HLK-Testfehlern finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.
Informationen zur Problembehandlung speziell für die Device Fundamentals-Tests im HLK und WDK finden Sie in der zusätzlichen Dokumentation zu Device.DevFund.
Weitere Informationen
Parameter
| Parametername | Parameterbeschreibung |
|---|---|
| DQ | Eine WDTF-SDEL-Abfrage, die verwendet wird, um das/die Zielgerät(e) zu identifizieren - https://go.microsoft.com/fwlink/?LinkId=232678 |
| Wpa2PskAesSsid | NUR erforderlich, wenn das DUT oder eines seiner untergeordneten Geräte ein WiFi-Adapter ist. Bitte geben Sie die SSID eines WPA2-AES-WLAN-Netzwerks an, das der Test zum Testen des WLAN-Adapters verwenden kann. Der Standardwert ist ‚kitstestssid‘. |
| Wpa2PskPassword | NUR erforderlich, wenn das DUT oder eines seiner untergeordneten Geräte ein WiFi-Adapter ist. Bitte geben Sie das Passwort des WPA2-AES-WLAN-Netzwerks ein, das mit dem Parameter Wpa2PskAesSsid angegeben wurde. Der Standardwert ist ‚Passwort‘. |
| ChangeBufferProtectionFlags | Richtig oder falsch. Ändert die Speicherschutzflags von Puffern, die an das getestete Gerät übergeben werden. Die Speicherschutzflags wechseln zwischen keinem Zugriff, schreibgeschütztem Zugriff und schreibgeschütztem Zugriff mit Seitenschutz. |
| Impersonate | Richtig oder falsch. Führt den Test als nicht administrativer Benutzer aus. |
| FillZeroPageWithNull | Richtig oder falsch. Ordnet die Nullseite zu und füllt sie mit NULL-Werten aus. Dieser Test identifiziert Treiber, die keinen Zeigerverweis überprüfen, bevor ein Zeiger dereferenziert wird. |
| DoPoolCheck | Richtig oder falsch. Überwacht die Verwendung der Systemspeicherpools mit und ohne Auslagerung durch den Treiber mithilfe von Pooltags und Lookaside-Listen. Mit dieser Option werden auch Änderungen an der Anzahl der behandelten Ausnahmen überwacht, die auf Fehler bei der Ausnahmebehandlung hinweisen können. |
| DoSync | Richtig oder falsch. Öffnet auch Gerätehandles im SYNC-Modus (FILE_SYNCHRONOUS_IO_ALERT). Zufällige Lese- und Schreibvorgänge werden übersprungen. |
| TestCycles | Anzahl der Testzyklen. |
| DriverVerifierAdditionalDrivers | Zusätzliche Treiber, für die die Treiberüberprüfung aktiviert sein sollte |
| DriverVerifierExcludedFlags | Platzhalter für Treiberüberprüfungs-Flags, die manuell für den Testlauf ausgeschlossen werden können |
| WDKDeviceID | Geräte-ID des zu testenden Geräts |
| QueryHardwareID | Hardware-ID des zu testenden Geräts |
| WDTFREMOTESYSTEM | NUR erforderlich, wenn das DUT oder eines seiner untergeordneten Geräte eine kabelgebundene NIC ist, die keine IPv6-Gateway-Adresse hat. Falls erforderlich, geben Sie bitte eine IPv6-Adresse an, die die Test-NIC anpingen kann, um die Netzwerk-E/A zu testen. Beispiel: fe80::78b6:810:9c12:46cd |
| DriverVerifierCustomizeConfiguration | Gibt an, dass dieser Test möglicherweise die Einstellungen der Treiberüberprüfung automatisch aktualisieren möchte |