Beim Schnittstellentest achtet jeder mehr darauf, welches Tool besser und benutzerfreundlicher ist. Aber nur wenige Leute achten auf die Designprobleme von Schnittstellentestfällen und nur wenige Leute schreiben Schnittstellenanwendungsfälle. Da sie alle codiert sind, welche Anwendungsfälle sollten dann geschrieben werden, oder?
Ist das wirklich richtig? Haben wir etwas übersehen? Wenn beim Regressionstest Hunderte oder Tausende von Schnittstellen ausgeführt werden und keine Fehler gemeldet werden, sind Sie dann wirklich zuversichtlich in Bezug auf das System? Welche funktionalen Anwendungsfälle müssen wir zusätzlich zum Schnittstellentest hinzufügen, um die Szenarien zu überprüfen, in denen die Schnittstelle nicht implementiert werden kann oder schwierig ist?
Persönlich denke ich, dass neben dem Schreiben auf Skriptebene auch die Gestaltung von Schnittstellen-Anwendungsfällen eine sehr wichtige Testaktivität ist. Durch bestimmte Schnittstellen-Anwendungsfalldesigns können die von uns geschriebenen Skripte zielgerichteter und zuverlässiger sein, sodass der Wert und die Bedeutung von Schnittstellentests widergespiegelt werden können, anstatt nur durch Quantität zu gewinnen. Der Testzweck ist klar, entspricht den Grundprinzipien des Schnittstellentests und bestätigt, dass klare Schnittstellenautomatisierungsskripte gute Skripte sind.
1. Was ist der Zweck des Testens eines bestimmten Anwendungsfalls?
Bevor wir Schnittstellentestskripte schreiben, sollten wir klarstellen, was die beabsichtigten Ziele dieser Skripte sind und was sie überprüfen sollen. Basierend auf persönlichen Erfahrungen werden Schnittstellenanwendungsfälle im Allgemeinen in drei Kategorien unterteilt:
Überprüfung einer einzelnen Schnittstelle: Überprüfen Sie hauptsächlich Schnittstellenparameter, Berechtigungen und Rückgabewerte, um sicherzustellen, dass die Schnittstelle „verwendet werden kann“. Diese Art von Anwendungsfall kann normalerweise mit dem Mock-Dienst geschrieben werden, nachdem das Schnittstellendesign abgeschlossen ist; Überprüfung der Szenariologik : basierend auf Benutzerszenarien
Grundlagen: Überprüfen Sie, ob die Parameterübertragung zwischen Schnittstellen und Geschäftsprozessen normal ablaufen kann. Die Komplexität der Anwendungsfälle ist hoch und Sie müssen mit der Beziehung zwischen Geschäft und Schnittstellen sehr vertraut sein. Dies ist der Kernwert des Schnittstellentests.
Ausnahmeüberprüfung: Es wird hauptsächlich überprüft, ob die Schnittstelle im Falle von Parameterausnahmen, Logikausnahmen usw. benutzerfreundliche Fehlermeldungen verarbeiten und ausgeben kann. Normalerweise gibt es viele Szenarien, die sich auf Parameteranomalien konzentrieren, die durch Äquivalenzklassen, Grenzwerte usw. behandelt werden können. Es muss darauf geachtet werden, was die ungewöhnlichen Rückgabeinformationen sind, ob die Informationen klar sind, ob die Aufforderung freundlich ist usw.
2. Quelle der Schnittstelleninformationen
Nachdem wir die Testziele geklärt haben und dann mit dem Schreiben von Testfällen beginnen, werden wir Testdaten und Schnittstellenkombinationen zielgerichteter entwerfen. Was ist die nächste Frage? Wo können Sie überprüfen, ob Ihre Schnittstelleninformationen gültig sind? Grundsätzlich gibt es zwei Wege:
Schnittstellendokumentation: Entwickler schreiben nicht gerne selbst Dokumentationen und hassen es auch, wenn andere keine Dokumentationen schreiben. Daher ist es für Tester ziemlich mühsam, ein echtes und effektives Schnittstellendokument zu erhalten. Im Allgemeinen wird es innerhalb des Teams ein einheitliches Tool zur Verwaltung von Schnittstellendokumenten geben (wenn nicht, ist es nicht schwierig, einen Entwickler zu finden und ihn zu bitten, eines zu bekommen). Wir müssen auf die Wirksamkeit und Aktualität des Schnittstellendokuments achten. Mittlerweile gibt es viele Plug-Ins oder Tools, mit denen Entwickler automatisch Schnittstellendokumente generieren können, z. B. Swaager, Apidoc usw.
Schnittstellenpaketerfassung: Wenn nichts vorhanden ist, verlassen Sie sich auf Ihre eigenen Bemühungen und verwenden Sie Tools wie Fiddler, um die Schnittstelle durch Paketerfassungsanalyse zu erhalten. Wenn es viele solcher Szenarien gibt, können Sie die von Fiddler erfasste Schnittstelle exportieren und dann eine kleine schreiben Das Programm kann direkt in ein Skript umgewandelt werden, das von der Schnittstellenplattform erkannt werden kann, was effizienter ist.
Nachdem wir die Schnittstelleninformationen erhalten haben, müssen wir mehr mit den Entwicklern kommunizieren, um die Bedeutung und Quelle der Parameter zu klären, damit wir Testfälle gezielt entwerfen können. Raten Sie in diesem Link nicht zu viel (viele Tester raten oft). selbst), direkt Fragen Sie einfach den Entwickler. In diesem Abschnitt ist es auch notwendig, die Bedeutung und Priorität der Schnittstellen zu sortieren und zu unterscheiden. Auf diese Weise können Sie bestätigen, welche Schnittstellen beim Entwerfen von Anwendungsfällen Priorität haben, welche Schnittstellen zuerst beiseite gelegt werden können und innerhalb der begrenzten Zeit die wertvollsten Dinge erledigen.
3. Einige Grundprinzipien
Nachdem wir die Schnittstelle erhalten, die Parameterbeschreibung geklärt und die Testziele kombiniert haben, können wir mit dem Entwerfen und Schreiben von Testfällen beginnen. Im Gegensatz zu funktionalen Testfällen müssen bei Schnittstellentestfällen (Skripten) einige Prinzipien beachtet werden:
Automatisierung: Scheint Unsinn zu sein. Alle Anwendungsfälle sollten nicht interaktive Tests sein. Der häufigste ist die Generierung von Tokens, die automatisch gehandhabt werden müssen (ich habe Skripte gesehen, bei denen Sie das Token manuell generieren und dann einfügen müssen vor der Ausführung des Anwendungsfalls. Dies gilt insbesondere bei der Ausführung in verschiedenen Umgebungen.
Unabhängigkeit: Jeder Anwendungsfall sollte unabhängig sein und keine Abhängigkeiten aufweisen. Die Voraussetzungen müssen in einem Anwendungsfall behandelt werden und nicht in mehreren voneinander abhängigen Anwendungsfällen.
Wiederholbar: Anwendungsfalltests können wiederholt ausgeführt werden, daher müssen Sie darauf achten, wie Parameter generiert werden.
Nachhaltigkeit: Wenn Codeänderungen dazu führen, dass bestehende Schnittstellentests fehlschlagen, muss das Codeproblem behoben oder die Codelogik getestet werden.
4. Behaupten Sie diese Dinge
Bei der Gestaltung von Testfällen müssen wir auch auf die Gestaltung von Behauptungen achten. Gute Behauptungen können uns dabei helfen, Probleme zu finden. Anwendungsfälle (Skripte) ohne Behauptungen sind einfach nur unseriös und völlig bedeutungslos. Persönlich werde ich mich bei der Überprüfung von Skripten darauf konzentrieren (viele Tester behaupten, dass das Schreiben sehr einfach ist, um die Daten gut aussehen zu lassen, oder weil sie nachträglich geschrieben werden). Diese Art von Skript leistet im Grunde genommen nutzlose Arbeit für KPI).
Auf der Schnittstellenebene müssen wir mindestens zwei Punkte überprüfen:
Überprüfung der Datenstruktur: Überprüfen Sie, ob die von der Schnittstelle zurückgegebene Datenstruktur mit der vordefinierten übereinstimmt. Wenn der Anrufer Daten verarbeitet, muss er die Daten basierend auf der vordefinierten Datenstruktur analysieren. Wenn sich die Datenstruktur ändert, ist dies für den Anrufer katastrophal (denken Sie an den Vertragstest).
Überprüfung der Kernwerte: Abhängig vom Geschäftsszenario können Sie gezielt überprüfen, ob die Werte bestimmter Schlüssel mit den Erwartungen übereinstimmen, und dies kann durch Kombination von Datenbankabfragen überprüft werden (verschiedene automatisierte Testframeworks verfügen über unterschiedliche Implementierungsmethoden). Dies hängt mehr vom Verständnis des Testers für das Geschäft ab. Flexible Entwurfsüberprüfungspunkte basierend auf tatsächlichen Bedingungen.
Zusätzlich zu den beiden oben genannten Punkten gibt es einige zusätzliche Überprüfungspunkte, die bei Bedarf durchgeführt werden können, z. B. die Datenübertragung mit anderen Parteien, ob auf die zurückgegebene URL zugegriffen werden kann und ob die zurückgegebenen Daten wirklich erforderlich sind (dies ist sehr wichtig). wichtig) Wichtig, zu viele Rücksendungen können viele unerwartete Probleme verursachen) usw. Ergänzung entsprechend der tatsächlichen Situation.
Auf diese Weise haben die durch eine Reihe von Methoden entwickelten Schnittstellenanwendungsfälle einen bestimmten Geschäftswert und können dem Team wirklich helfen und die Testeffizienz verbessern. Bei solchen Testskripten sorgen alle PASS-Ergebnisse dafür, dass sich die Leute wohl fühlen. (Können Sie sich vorstellen, dass alle Skripte ohne Zusicherungen erfolgreich sind, sind Sie trotzdem erleichtert?)
5. Nachwartung von Skripten
Nachdem der Testfall (Skript) geschrieben wurde, bedeutet dies nicht, dass der Schnittstellentest abgeschlossen ist. Wenn wir in anderen Testlinks Fehler finden, die durch Schnittstellenprobleme verursacht werden (z. B. Antwortausnahmen, keine zurückgegebenen Daten usw.), müssen wir diese entsprechend zu den Schnittstellenanwendungsfällen hinzufügen, um zu verhindern, dass ähnliche Situationen erneut auftreten, ohne dass wir sie überprüft haben. Nachdem Sie bestimmte hochwertige Anwendungsfälle (Skripte) gesammelt haben, können Sie den Wert dieser Dinge weiter untersuchen, z. B. sie in Skripte für die Online-Geschäftsüberwachung umwandeln, sie in eine Grundlage für genaue Tests umwandeln usw. Es gibt auch eine anspruchsvollere Spielweise, die darin besteht, die Idee des Chaostests zu nutzen, um unabhängig einen Zweig herauszuziehen und einige Ausnahmen absichtlich zu ändern, damit die Testfälle überprüfen können, ob diese Fehler zur Überprüfung gefunden werden können die Wirksamkeit der Testfälle. Wenn es nicht entdeckt werden kann, müssen wir darüber nachdenken, wie wir das Testskript verbessern können (ähnliche Plattformen sind bereits in der Branche erschienen).
6. Vorbereitung der Testdaten
Lassen Sie uns mehr über die Testdatenvorbereitung sprechen. Dies ist tatsächlich ein sehr wichtiger Link beim Schnittstellentest. Wenn das Skript in mehreren Umgebungen ausgeführt werden soll, dürfen die Testdaten nicht zu streng geschrieben werden. Sie müssen einige Daten entsprechend automatisch abrufen Umwelt. Wert. Für die Aufbereitung von Testdaten gibt es drei allgemeine Spielarten:
Öffentliche Parameter: Durch die Unterscheidung verschiedener Bereiche und Bezeichner gibt es eine spezielle Datei, die die Speicherung einiger gemeinsamer Daten übernimmt, z. B. Benutzernamen in verschiedenen Umgebungen.
Datenerfassung: Generieren Sie die erforderlichen Daten im Voraus über eine bestimmte API oder SQL, fügen Sie sie dann in eine bestimmte Sammlung ein (entweder Parameter oder Dateien) und rufen Sie bei Bedarf die entsprechenden Datenwerte von hier ab.
Datenvorlage: Dies ist eine aktualisierte Version der Datenerfassung. Gemäß dem Geschäftsdatenfluss müssen Sie nur einige einfache Informationen eingeben, um automatisch einen vollständigen Satz Geschäftsdaten zu generieren (was ich persönlich beispielsweise getan habe, ist die automatische Generierung). Generieren Sie einen Satz Geschäftsdaten anhand grundlegender Schulinformationen. Ein Satz gezielter Daten, einschließlich eines vollständigen Satzes von Daten zu Schulen, Klassen, Fächern, Schülern usw.).
[Neueste Version im Jahr 2023] Automatisierte Python-Tests, Abschluss von 60 praktischen Projekten in 7 Tagen und Bereitstellung praktischer Informationen während des gesamten Prozesses. [Automatisierte Tests/Schnittstellentests/Leistungstests/Softwaretests]
Abschließend möchte ich mich bei allen bedanken, die meinen Artikel sorgfältig gelesen haben. Gegenseitigkeit ist immer notwendig. Obwohl es keine sehr wertvolle Sache ist, können Sie es direkt verwenden, wenn Sie es verwenden können:
Diese Informationen sollten das umfassendste und vollständigste Vorbereitungslager für Freunde von [Softwaretests] sein. Dieses Lager hat auch Zehntausende von Testingenieuren auf der schwierigsten Reise begleitet. Ich hoffe, es kann Ihnen auch helfen!