> ⭐⭐ Besuchen Sie uns bei der SNIA SDC im SMB3 IO Lab (28. September – 1. Oktober 2026) und sehen Sie sich die kommenden Interoperability-Events an.
Windows Protocol Test Suites bieten Interoperabilitätstests gegen die Implementierung von Windows Open Specifications, einschließlich File Services, Identity Management, Remote Desktop und weiteren.
Ursprünglich für interne Tests der Microsoft Open Specifications entwickelt, wurden die Microsoft Protocol Test Suites umfangreich während Plugfests und Interoperabilitätslabors eingesetzt, um gegen Partnerimplementierungen zu testen. Eine Test Suite bewertet, ob eine Protokoll- oder Protokollfamilienimplementierung bestimmte Interoperabilitätsanforderungen erfüllt. Test Suites decken nicht jede Protokollanforderung ab und zertifizieren in keiner Weise eine Implementierung, selbst wenn alle Tests bestanden werden. Jedoch bietet jede Test Suite den Benutzern einen nützlichen Hinweis auf die Interoperabilität.
Windows Protocol Test Suites enthalten die folgenden Komponenten:
Windows Protocol Test Suites basieren auf .NET und können daher auf verschiedenen Plattformen entwickelt und ausgeführt werden. Sie sollten die unten aufgeführte Software entsprechend Ihrem Testzweck installieren, einschließlich ihrer eigenen Abhängigkeiten.
.NET und zugehörige Komponenten
a. Für Windows, Linux und macOS installieren Sie das .NET 8.0 SDK, um Test Suites zu erstellen oder auszuführen.
b. Für diejenigen, die unter Windows arbeiten und eine IDE bevorzugen, installieren Sie Visual Studio 2022 oder höher (empfohlen wird Visual Studio 2022 Community), zusammen mit diesen einzelnen Komponenten aus dem Installer:
| Abschnitt | Einzelne Komponente in Visual Studio 2022 | Windows Protocol Test Suites ausführen | Windows Protocol Test Suites aus dem Quellcode erstellen |
|---|---|---|---|
| .NET | .NET SDK | Erforderlich | Erforderlich |
| Compiler, Build-Tools und Runtime | C# and Visual Basic Roslyn compilers | Erforderlich | |
| Compiler, Build-Tools und Runtime | MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest) | Erforderlich1 | |
| Compiler, Build-Tools und Runtime | C++/CLI support for v143 build tools (Latest) | Erforderlich1 | |
| Compiler, Build-Tools und Runtime | C++ 2022 Redistributable Update | Erforderlich1 | Erforderlich1 |
| Development Activities | C++ core features | Erforderlich1 | |
| SDKs, libraries, and frameworks | Windows 10 SDK (10.0.19041.0) | Erforderlich1 |
Hinweis:
[1]: Diese einzelne Komponente wird von ADFamily und MS-SMBD benötigt, die C++-Code enthalten.
Protocol Test Framework v2.6 (build 2.6.1)
Das Protocol Test Framework wird von Projekten von ProtoSDK und TestSuites als NuGet-Pakete referenziert.
Extrahieren Sie aus NetworkDirect_DDK.zip die Dateien ndspi.h und ndstatus.h in den Projektpfad ProtoSDK\RDMA\include. Dies dient zum Erstellen der SMBD Test Suite.
Dies ist nur erforderlich, wenn der Benutzer PowerShell Core Remoting over SSH verwenden möchte.
Dies ist nur erforderlich, wenn der Benutzer PowerShell Core Remoting over SSH für die Windows-Plattform verwenden möchte.
Dies ist nur erforderlich, wenn der Benutzer die PowerShell-Implementierung unter Windows Server 2012R2 für ISutCommonControlAdapter in CommonTestSuite.ptfconfig verwenden möchte.
a. Wenn Sie die PowerShell-Implementierung für ISutCommonControlAdapter in einer Domänenumgebung wählen, in der der DC unter Windows Server 2012R2 läuft, müssen Sie WMF 5.1 auf dem DC installieren, um die SID vom DC abzurufen. Für andere Windows Server-Versionen, die neuer als Windows Server 2012R2 sind, müssen Sie WMF 5.1 nicht auf dem DC installieren.
b. Wenn Sie die PowerShell-Implementierung für ISutCommonControlAdapter auf Windows-Plattformen (einschließlich Windows Server 2012R2 und neueren Versionen) in einer Arbeitsgruppenumgebung wählen, müssen Sie WMF 5.1 nicht auf dem SUT installieren.
c. Wenn Sie die verwaltete Implementierung für ISutCommonControlAdapter auf Windows-Plattformen (einschließlich Windows Server 2012R2 und neueren Versionen) wählen, werden LDAP-Abfragen verwendet, um die SID abzurufen, und es wird nur die Domänenumgebung unterstützt.
Wenn Sie unter Windows arbeiten, können Sie das Skript im Ordner InstallPrerequisites verwenden, um diese Software automatisch herunterzuladen und zu installieren.
Tipps zur Verwendung des Skripts im Ordner InstallPrerequisites:
Das Skript erfordert Internetkonnektivität, um einige Abhängigkeiten herunterzuladen.
Der Parameter Category wird verwendet, um anzugeben, welcher Satz von Tools heruntergeladen und installiert werden soll, basierend auf den verschiedenen Test Suite-Namen wie FileServer, Kerberos, SMBD, RDP, BranchCache, ADFamily, AZOD, ADFSPIP und ADOD. Die Kategorien sind in PrerequisitesConfig.xml definiert, und Sie können diese Konfigurationsdatei aktualisieren, um Ihre gewünschten Anforderungen zu erreichen.
Der Parameter ConfigPath wird verwendet, um den Pfad der Voraussetzungen-Konfigurationsdatei anzugeben; der Standardwert ist ".\PrerequisitesConfig.xml".
Um das Skript beispielsweise für die FileServer Test Suite auszuführen, öffnen Sie Windows PowerShell und führen Sie die folgenden Befehle im PowerShell Window aus:
cd WindowsProtocolTestSuites\InstallPrerequisites
.\InstallPrerequisites.ps1 -Category FileServer -ConfigPath ".\PrerequisitesConfig.xml"
Set-ExecutionPolicy RemoteSigned
Sie können den folgenden Befehl ausführen, um zu überprüfen, ob die Execution Policy korrekt festgelegt ist:
Get-ExecutionPolicy
Führen Sie dann das Skript erneut aus.
Nachdem Sie eine Kopie geklont dieses Repos haben, können Sie build.ps1 in PowerShell oder build.sh in der Shell für jede Test Suite separat ausführen, nachdem Sie alle für den Build erforderlichen Softwarekomponenten installiert haben, die unter Voraussetzungen aufgeführt sind.
Wenn Sie beispielsweise die FileServer Test Suite erstellen möchten:
cd WindowsProtocolTestSuites\TestSuites\FileServer\src
build.ps1
Nachdem der Build erfolgreich war, sollte die gemeinsame Ordnerstruktur im Ordner WindowsProtocolTestSuite\drop\TestSuites\[TestSuiteName]\ generiert werden.
Bin: alle erstellten Binärdateien, einschließlich ProtoSDK, Adapter und Test Suites.Batch: Batch-Dateien (.ps1, .sh), die zum Starten von Tests verwendet werden können.Scripts: Skripte, die zum Konfigurieren der Testumgebung verwendet werden können.Utils: einige Dienstprogramme, die in Tests verwendet werden können.Alternativ können Sie das vorgefertigte Test Suite-Archiv von Releases herunterladen.
Bevor Sie eine Test Suite ausführen, müssen Sie eines der folgenden Dinge tun:
Unter macOS verwendet die FileServer Test Suite die AesCcm- und AesGcm-Klassen, die OpenSSL erfordern. Wenn auf Ihrem macOS kein OpenSSL 1.1 vorhanden ist, installieren Sie bitte OpenSSL 1.1 und legen Sie die Umgebungsvariable wie folgt fest, bevor Sie die FileServer Test Suite unter macOS ausführen:
brew install [email protected]
export DYLD_LIBRARY_PATH="/usr/local/opt/[email protected]/lib:$DYLD_LIBRARY_PATH"
Hinweis:
brew auf Ihrem macOS nicht installiert ist, können Sie es gemäß brew installieren.DYLD_LIBRARY_PATH enthalten ist oder nicht. Sobald Sie OpenSSL 1.1 auf Ihrem macOS installieren, befindet sich die Krypto-Bibliothek unter /usr/local/Cellar/[email protected]/1.1.1m/lib/libcrypto.1.1.dylib, und /usr/local/opt/openssl verlinkt standardmäßig auf das Verzeichnis /usr/local/Cellar/[email protected]/1.1.1m.Im Ordner Batch unter dem Stammpfad der Test Suite befinden sich mehrere Skripte, mit denen Sie Tests starten können.
Alle Testfälle ausführen
Führen Sie RunAllTestCases.ps1 in PowerShell oder RunAllTestCases.sh in der Shell direkt aus.
Testfälle nach Filtern ausführen
Führen Sie RunTestCasesByFilter.ps1 -Filter [your filter expression] in PowerShell oder RunTestCasesByFilter.sh [your filter expression] in der Shell direkt aus.
Wenn Sie beispielsweise Testfälle mit der Testkategorie BVT und SMB311 ausführen möchten, können Sie den folgenden Befehl ausführen:
RunTestCasesByFilter.sh "TestCategory=BVT&TestCategory=SMB311"
Weitere Informationen zum Erstellen des Filterausdrucks finden Sie unter Filter option details.
Dry Run
Wenn Sie die Testfälle auflisten möchten, bevor Sie sie tatsächlich ausführen, können Sie den Schalter -DryRun zu .ps1-Skripten hinzufügen oder eine nicht leere Zeichenfolge als letztes Argument an .sh-Skripte übergeben.
Wenn Sie beispielsweise Testfälle mit der Testkategorie BVT und SMB311 auflisten möchten, können Sie den folgenden Befehl ausführen:
RunTestCasesByFilter.sh "TestCategory=BVT&TestCategory=SMB311" "list"
Protocol Test Manager Service (PTMService) ist ein Single-Web-Page-Anwendungstool, das Ihnen hilft, Testfälle in den Test Suites zu konfigurieren und auszuführen. PTMService unterstützt mehrere Plattformen, einschließlich Windows, Linux und macOS. Um mit PTMService zu beginnen, können Sie das PTMService Wiki heranziehen.
Für FileServer-Konfigurationen entspricht die PTM-UI-Einstellung Enable Parallel Test Execution der vollqualifizierten .ptfconfig-Eigenschaft Common.PTF.LogProfileParserPatch.Enabled. Setzen Sie sie auf true, um die gestaffelte parallele Ausführung innerhalb eines FileServer-Testlaufs zu aktivieren.
Sie können die Testumgebung gemäß dem User Guide der jeweiligen Test Suite einrichten und die Test Suite konfigurieren.
Jede Test Suite hat ihren eigenen User Guide im Ordner WindowsProtocolTestSuites\TestSuites\[TestSuiteName]\docs.
Im selben Ordner gibt es zwei weitere Arten von Dokumenten:
Den Leitfaden für Mitwirkende finden Sie hier.
Windows Protocol Test Suites stehen unter der MIT-Lizenz.
Die folgenden Ressourcen dienen Neuigkeiten, Diskussionen und Support zu Windows Protocol Test Suites:
Dieses Projekt hat den Microsoft Open Source Code of Conduct übernommen. Weitere Informationen finden Sie in den Code of Conduct FAQ oder kontaktieren Sie [email protected] bei weiteren Fragen oder Kommentaren.