1. Was ist Schnittstellentest?
Beim Schnittstellentest handelt es sich um Tests, bei denen die Schnittstellen zwischen Systemkomponenten getestet werden. Schnittstellen dienen vor allem der Erkennung von Interaktionspunkten zwischen externen Systemen und internen Subsystemen. Im Mittelpunkt der Tests steht die Überprüfung der Datenaustausch-, Übertragungs-, Steuerungs- und Verwaltungsprozesse sowie der gegenseitigen logischen Abhängigkeiten zwischen den Systemen.
2. Warum werden Schnittstellentests durchgeführt?
In der Geschichte des Taobao-Systems tauchten zunächst Funktionstests und Leistungstests auf, gefolgt von automatisierten Tests. Aber heute ist die Architektur von Taobao nicht mehr die traditionelle MVC-Struktur, und das System entwickelt sich in eine verteilte, geschäftsorientierte und hochverfügbare Richtung. Heutige Systemarchitekturen sind komplex und weisen viele Schnittstellen zwischen Systemen auf. Herkömmliche Funktionstests, Leistungstests und automatisierte Tests können den Anforderungen der Systementwicklung nicht mehr gerecht werden und es wird dringend eine effektivere, praktischere und nachhaltigere Testmethode benötigt.
Unter dieser Anforderung werden Schnittstellentests generiert. Erstens steigen mit der kontinuierlichen Zunahme der Systemkomplexität die Testkosten herkömmlicher Testmethoden stark an und die Testeffizienz sinkt stark (laut Datenmodell kann ein Fehler auf der untersten Ebene etwa 8 Fehler auf der obersten Ebene verursachen). Ein Fehler auf der untersten Ebene kann leicht zum Ausfall des gesamten Netzwerks führen. Wenn die Komplexität des Systems jedoch zunimmt, können Schnittstellentests eine kostengünstige und hocheffiziente Lösung darstellen.
Zweitens unterscheidet sich der Schnittstellentest vom herkömmlichen Unit-Test. Er ist ein umfassender, effizienter und kontinuierlicher Test der Systemschnittstelle aus Benutzersicht.
Schließlich handelt es sich bei Schnittstellentests um automatisierte und kontinuierliche Integration, weshalb Schnittstellentests die Grundlage für niedrige Kosten und hohe Erträge sein können.
Kurz gesagt, Schnittstellentests sind aufgrund der inhärenten Anforderungen einer hochkomplexen Systemqualität und kostengünstiger wirtschaftlicher Vorteile die beste Lösung. Schnittstellentests sind ein vollständiges System, einschließlich Funktionstests und Leistungstests.
3. Der Prozess des Schnittstellentests
Gemäß den bisherigen praktischen Erfahrungen kann das Schnittstellentesten in die folgenden Schritte unterteilt werden: Anforderungsanalyse und Designüberprüfung, Testframework und Technologieauswahl, Testplanformulierung, Testumgebungsaufbau, Testfalldesign und -überprüfung, Testimplementierung und -ausführung, kontinuierliche Integration. Als nächstes wird jeder Schritt im Detail beschrieben.
1. Anforderungsanalyse und Entwurfsprüfung
Fast alle Softwareaktivitäten beginnen mit der Anforderungsanalyse, ebenso wie Schnittstellentests. In dieser Phase haben wir zwei Aufgaben: Erstens müssen wir die Anforderungen vollständig verstehen und sicherstellen, dass alle das gleiche Verständnis der Anforderungen haben. Zweitens versuchen wir, die Probleme in den Anforderungen selbst herauszufinden.
Nach der Anforderungsanalyse gelangen Sie in die Systemdesignphase. Das Systemdesign sollte nicht in der alleinigen Verantwortung des Systemdesigners oder -entwicklers liegen. Als Schnittstellentester sollten Sie in der Lage sein, aus Sicht des Testens einige Lösungen oder Vorschläge für das Systemdesign bereitzustellen, das Design zu optimieren und die Testbarkeit des Systems zu verbessern.
2. Testrahmen und Technologieauswahl
Nach der Überprüfung des Systemdesigns sollten alle zur Implementierung des Systems erforderlichen Technologien ausgewählt worden sein. In dieser Phase müssen Schnittstellentester ihr eigenes Test-Framework und ihre eigenen Technologien auswählen, die entsprechend dem Systemdesign verwendet werden sollen. Dies ist natürlich nicht notwendig. Wenn der technische Rahmen des von Ihnen getesteten Projekts dem technischen Rahmen des zuvor getesteten Projekts ähnelt, können Sie den vorherigen Testrahmen und die vorherige Testtechnologie verwenden oder auf dieser Grundlage einige Anpassungen vornehmen. Wenn das zu testende Projekt eine andere technische Architektur verwendet, muss sorgfältig überlegt werden, wie das geeignete Test-Framework und die geeignete Technologie ausgewählt werden.
Die Wahl des Schnittstellen-Frameworks und der Technologie hängt von vielen Faktoren ab. Das Prinzip besteht darin, das Framework und die Technologie auszuwählen, die Ihren Testanforderungen am besten entsprechen, und zu versuchen, Ihre Projektmitglieder damit vertraut zu machen. Es ist nicht nötig, ein Tool mit vielen Funktionen zu wählen, das aber kompliziert und schwer zu verstehen ist, nur um den technischen Inhalt des Tests zu verbessern.
3. Formulierung des Testplans
Die Testplanung für Schnittstellentests ähnelt grundsätzlich dem Funktionstest. In dieser Phase muss geklärt werden, welche Testressourcen verfügbar sind, wie Testressourcen zugewiesen werden, was während des gesamten Testprozesses getan werden muss und was zu jedem Zeitpunkt getan werden sollte. Der wichtigste und am meisten übersehene Punkt ist die Risikobewertung. Obwohl es uns unmöglich ist, alle Risiken zu identifizieren, können wir die meisten potenziellen Risiken identifizieren und sie empirisch steuern. Ein gutes Risikomanagement spiegelt die Reife eines Softwareteams wider.
4. Aufbau einer Testumgebung
Nachdem das Test-Framework und die Technologieauswahl abgeschlossen sind, kann die Testumgebung erstellt werden. Ein typischer Prozess zum Erstellen einer Umgebung für UI-Tests könnte wie folgt aussehen: Zuerst erstellen Sie ein Basisprojekt für UI-Tests und entwerfen eine gute Struktur für das Projekt. In diesem Projekt importieren Sie das Testframework und die Abhängigkeiten Ihrer Wahl, bereiten die erforderlichen Konfigurationsdateien für diese Frameworks und Abhängigkeiten vor und verknüpfen dieses Projekt in irgendeiner Form (normalerweise eine Projektabhängigkeit) mit dem Projekt des zu testenden Systems . In dieser Umgebung ist es möglich, einen Basistest durchzuführen und zu bestehen.
5. Entwurf und Überprüfung von Testfällen
Das Testfalldesign der Schnittstelle besteht darin, den Test mit der Schnittstelle als Einheit zu entwerfen. Während des Entwurfsprozesses konzentrieren wir uns auf die möglichen Eingabeparameter der Schnittstelle und die erwarteten Ausgabeergebnisse. Natürlich sollten bei Bedarf auch die Leistung der Schnittstelle und der zu erwartende Druck berücksichtigt werden. Während dieses Prozesses ist es sehr wichtig, die verschiedenen Tests zu priorisieren. Dies gibt Ihnen Hinweise darauf, welche Tests zuerst abgeschlossen werden sollten und welche Tests verzögert werden können, wenn die Testressourcen nicht ausreichen. Das heißt, wenn die Testressourcen ausreichen, kann der Test auch entsprechend der Priorität abgeschlossen werden. Auf diese Weise ist bei Auftreten eines bestimmten Risikos grundsätzlich gewährleistet, dass die Arbeit mit hoher Priorität abgeschlossen wurde und dies auch der Fall sein wird keine Panik.
Nachdem der Testfallentwurf fertiggestellt ist, muss er überprüft werden, und die Ergebnisse der Überprüfung sollten in irgendeiner Form als endgültiger Plan für die Testimplementierung aufgezeichnet werden. An der Evaluierung nehmen am besten folgende Personen teil: Nachfrageseite, Designseite, Entwicklungsseite, Funktionstestseite, Schnittstellentestseite und deren direkte Vorgesetzte. Verschiedene Rollen betrachten das Testdesign aus unterschiedlichen Blickwinkeln, sodass das Testdesign in diesem Prozess erheblich verbessert wird.
6. Testimplementierung und -ausführung
Sobald der Entwurf fertiggestellt und überprüft ist, ist das Testen der Implementierung relativ einfach. Nichts bedeutet, dass ein Testfall über eine Programmiersprache implementiert und ausgeführt wird.
Bei der Testimplementierung kann es vorkommen, dass das Testdesign nicht perfekt ist oder aufgrund geänderter Anforderungen neue Testfälle hinzugefügt werden müssen. Unabhängig vom Grund sollte bei der Durchführung des Tests sofort aufgezeichnet werden, sobald ein perfekter Ort gefunden wurde, um die Integrität des Tests effektiver sicherzustellen.
In diesem Prozess sollten wir auch Testberichte (einschließlich Tagesberichte und Abschlussberichte) erstellen, damit das gesamte Team rechtzeitig die Qualität des Projekts erfassen kann und verschiedene Rollen die Arbeit richtig organisieren können.
7. Kontinuierliche Integration
Kontinuierliche Integration ist ein wichtiges technisches Mittel für Schnittstellentests, um vollautomatisierte Regressionstests zu realisieren. Einfach ausgedrückt besteht die kontinuierliche Integration darin, den geschriebenen Testcode kontinuierlich auszuführen und mithilfe der Versionskontrolltechnologie sicherzustellen, dass der Testcode immer die neueste Version der Systemschnittstelle testet.
Wenn der Schnittstellentest dieses Stadium erreicht, besteht unser Ziel darin, den Testcode kontinuierlich laufen zu lassen, um sicherzustellen, dass das Problem rechtzeitig lokalisiert und gelöst werden kann, wenn der Testcode fehlschlägt. Während Entwickler das System warten, pflegen wir auch unseren Testcode basierend auf den Ergebnissen der kontinuierlichen Integration.
Abschließend ist es wichtig zu beachten, dass die oben genannten Schritte zwar die Normen sind, denen unsere Schnittstellentester folgen, Schnittstellentests jedoch im Gegensatz zu anderen Tests wie Funktionstests gleichzeitig mit der Entwicklung durchgeführt werden müssen. Wir sollten zu Beginn des Projekts beteiligt sein und die Tests sind grundsätzlich abgeschlossen, wenn die Codierung abgeschlossen ist. Jeder Schritt in der Mitte ist auch eng mit der Entwicklung verbunden. Daher werden unsere Schnittstellentestingenieure auch Testentwicklungsingenieure genannt. Wir benötigen sowohl Testkenntnisse als auch Programmierkenntnisse.
8. Qualitätsbewertungsstandards
Ob die Schnittstellenabdeckung den Anforderungen entspricht.
1) Alle extern aufgerufenen Schnittstellen müssen über entsprechende Testfälle verfügen und die Abdeckungsrate muss mehr als 95 % erreichen.
2) Die Abdeckungsrate aller intern verwendeten Schnittstellentestfälle, die die Hauptfunktionen des Produkts betreffen, sollte über 90 % liegen.
3) Für alle intern genutzten Schnittstellen mit Sekundärfunktionen steigt die Abdeckungsrate des Testcodes mit zunehmender Komplexität und Bedeutung der Schnittstelle.
Testen Sie, ob die Überprüfung der Schnittstellengeschäftsregeln im Testfall abgeschlossen ist.
1) Der Testfall sollte die wichtigsten Geschäftsregeln der Schnittstelle abdecken. Die Hauptgeschäftsregeln der Schnittstelle sind die Hauptfunktionen der Schnittstelle, die sich auf die Geschäftsimplementierung und den Aufrufstatus der Schnittstelle auswirken.
Wenn Sie einen Schatz veröffentlichen, dann ist die Veröffentlichung eines brandneuen, gebrauchten, versteigerten, ungenutzten Schatzes usw. die Hauptfunktion.
2) Der Testfall sollte die allgemeinen Geschäftsregeln der Schnittstelle abdecken. Oder ein Beispiel für die Veröffentlichung eines Babys: 80 % der Verkäufer fügen Bilder hinzu, möchten Links usw. Laut Beschreibung. dieses Geschäft
Die Regel hat keinen Einfluss auf den normalen Aufruf der Schnittstelle. Dies wirkt sich jedoch auf die Nutzungsgewohnheiten des Benutzers aus. Daher muss der Testfall einen Link zum Bild und eine Validierung des gewünschten Links im Beschreibungsfeld enthalten.
3) Die Parametervalidierung sollte die Validierung von Grenzwerten und parameterspezifischen Geschäftsregeln umfassen. Viele Schnittstellen unterliegen bestimmten Einschränkungen hinsichtlich ihrer Parameter, beispielsweise sind die Feldlängen auf begrenzt.
Für Testfälle, bei denen die Länge dieses Felds 4, 5 beträgt.
Ob die Abhängigkeitstests zwischen Schnittstellen im Testfall abgedeckt werden sollen. Beispielsweise sollten bei einem Assoziationstest für eine hinzugefügte Schnittstelle andere Assoziationen mit dem Rückgabewert der hinzugefügten Schnittstelle als Parameter aufgerufen werden.
Ändern und löschen Sie beispielsweise Schnittstellen und überprüfen Sie, ob sie aufgerufen und erfolgreich aufgerufen werden können.
Das Ausmaß der Auswirkungen älterer Fehler auf das System:
1) Häufig aufgerufene Schnittstellen dürfen keine Fehler im Zusammenhang mit den Hauptgeschäftsregeln und allgemeinen Geschäftsregeln enthalten, und die Bug-Legacy-Rate der sekundären Geschäftsregeln sollte unter 0,2 % liegen.
2) Schnittstellen, die nicht häufig aufgerufen werden, können keine Fehler in wichtigen Geschäftsregeln enthalten. Die Fehlerauslassungsrate allgemeiner Geschäftsregeln beträgt weniger als 2 %, und die Fehlerauslassungsrate kleinerer Geschäftsregeln beträgt weniger als 5 %.
Ob der Testfall mit dem Testcode konsistent ist.
Ob der Testfall kontinuierlich zurückgeführt werden kann.
Ob die getestete Schnittstelle dem Standard des Anrufers entspricht und ob der Anrufer die Schnittstelle verwenden kann, um die in der Produktdesignspezifikation entworfene Anwendung zu entwickeln.