Konstruieren von Testfällen, die nicht ätzend sind (und wie man häufige Fehler vermeidet)

Software-Tests sind ein wichtiger Bestandteil des Software-Entwicklungszyklus. Ohne sie könnten Sie Probleme mit der Funktionalität oder größere Fehler in der Benutzerfreundlichkeit übersehen, die Ihre Endbenutzer am Ende frustrieren. Aber nicht alle Testfälle sind gleich. Das Schreiben hochwertiger, effektiver Testfälle ist genauso wichtig wie das Testen Ihrer Anwendungen. Tatsächlich können schlechte Testfälle zu einem Testprozess führen, der kaum effektiver ist als gar kein Testen.

Was haben also schlecht geschriebene Testfälle gemeinsam? Wie können Software-Tester hochwertige Testfälle schreiben und dabei häufige Fehler vermeiden? Um das herauszufinden, haben wir das Internet nach den besten Ratschlägen für das Schreiben von effektiven Testfällen durchsucht und eine Gruppe von Entwicklungsprofis und Softwaretestern um ihre Meinung zu dieser Frage gebeten:

„Was haben schlecht konstruierte Testfälle gemeinsam (und wie können Entwickler diese Fehler vermeiden)?“

Meet Our Panel of Software Testing Experts:

Finden Sie heraus, was unsere Profis zu sagen hatten, indem Sie ihre Antworten unten lesen.

Avaneesh Dubey

@qsometests

Avaneesh Dubey ist der CEO von Qsome Tech. Seine Karriere ist gespickt mit einer Reihe von Innovationen in verschiedenen Aspekten des Geschäfts: Menschen, Prozesse und Technologie. Jetzt baut er Qsome Tech als innovativen Anbieter im Bereich der Softwarequalität auf.

„Es gibt ein paar Dinge, die viele schlecht konstruierte Testfälle gemeinsam haben…“

1. Zu spezifisch – sie führen nur eine bestimmte Testbedingung aus.

Testfälle müssen eine Vielzahl von Bedingungen berücksichtigen, die von der Software erwartet werden. Der Testfall muss in der Lage sein, das Softwaremodul mit nahezu allen möglichen Kombinationen von Hauptbedingungen umfassend zu testen. Um alle Kombinationen von Bedingungen umfassend testen zu können, muss der Autor einen Weg finden, diese Bedingungen so darzustellen, dass sie für andere leicht zu überprüfen sind.

2. Einen kleinen Teil der Funktionalität abdecken – sie müssen einen größeren Teil des Systems testen.

Testfälle konzentrieren sich oft auf eine bestimmte Funktion. Oft wird diese Funktion durch das interne technische Design der Software bestimmt. Stattdessen müssen die Testfälle die Nutzungsmuster und Abläufe widerspiegeln. Jeder Testfall sollte versuchen, einen möglichst großen Teil des Ablaufs abzudecken – über die technischen Grenzen der zugrundeliegenden Anwendung hinweg.

3. Testen nach einer bestimmten Benutzerrolle.

Wir haben oft gesehen, dass Testfälle für eine bestimmte Benutzerrolle geschrieben wurden. Das schränkt sie in ihrem Umfang ein und beeinträchtigt damit ihre Effektivität erheblich. Die effektivsten Testfälle spiegeln die Nutzungsmuster wider. Eine Geschäftsanwendung sollte z.B. mit Testfällen getestet werden, die so konzipiert sind, dass sie den gesamten Geschäftsprozess testen – also alle Benutzerrollen und alle Systeme abdecken, die am Geschäftsprozess beteiligt sein könnten.

4. Geschrieben, um zu beweisen, dass die häufigsten Anwendungsfälle in der Anwendung gut abgedeckt sind.

Dies ist meiner Meinung nach eines der häufigsten Probleme und ist ein Ergebnis dessen, was ich einen „faulen“ Ansatz beim Testdesign nenne. Der Testdesigner wiederholt einfach das Anforderungsdokument in Testfällen. Der Testdesigner sollte stattdessen nach den ‚Eckfällen‘ oder ‚Randbedingungen‘ suchen. Die meisten Entwickler sind leicht in der Lage, Code für die häufigsten Anwendungsfälle zu schreiben. Die Probleme tauchen in dem Moment auf, in dem es eine Bedingung für den häufigsten Anwendungsfall gibt. Ein gut entworfener Testfall wird diese leicht abfangen.

5. Jeder Testfall kann völlig nutzlos werden, wenn er nicht systematisch katalogisiert und zur Benutzung bereitgehalten wird.

Stellen Sie sich eine Bibliothek vor, in der Bücher nicht katalogisiert und nicht systematisch in Regalen aufbewahrt werden. Es wäre unmöglich, die Bücher zu benutzen, wenn man sie nicht mit Leichtigkeit finden kann, wenn man sie braucht.

Oft werden Hunderte von Testfällen mit viel Aufwand geschrieben und dann in eine gemeinsame Ordnerstruktur gekippt. Das kann zwar funktionieren, wenn man nur wenige Testfälle hat, aber in dem Moment, in dem die Anzahl der Testfälle zunimmt, bricht das einfach zusammen. Deshalb brauchen wir eine systematische Verschlagwortung und Katalogisierung von Testfällen. Dann sollte ein Testmanagementsystem in der Lage sein, Testfälle „herauszuziehen“, wenn sie ausgeführt werden müssen. Das Erstellen und Pflegen mehrerer Versionen von Testfällen ist entscheidend.

Wes Higbee

@g0t4

Wes Higbee ist der Präsident der Full City Tech Company.

„Testcode, der erzwungen wurde, ist in der Regel wertlos…“

Vielleicht gibt es eine Regel, dass es eine 100%ige Codeabdeckung geben muss, oder dass man keinen Code ohne mindestens einen Test hinzufügen kann. Also schreiben die Leute gerade genug Testcode, um diese Regel zu erfüllen. Es ist glorifizierter Papierkram, TPS-Berichte (Office Space).

Menschen lernen, indem sie nachahmen, was sie beobachten. Wenn Sie also Testen verlangen, ohne den Leuten zu helfen, den Wert des Testens zu verstehen, dann neigen sie dazu, es als zeremoniell zu sehen und versuchen einfach, bestehende Tests zu kopieren und ihren Anwendungsfall hineinzupressen.

Testen ist kein Selbstzweck. Testen, wenn es von Nutzen ist, schafft Vertrauen, kann Zeit sparen und kann zukünftige Änderungen absichern. Wenn also Leute, die diese Vorteile erfahren haben, sie an Gleichgesinnte weitergeben können, dann werden andere Leute diese Vorteile suchen und das führt oft zu produktivem Testen.

Personen, die die Vorteile des Testens erfahren haben, sollten versuchen diese Vorteile zu preisen, nicht das Testen selbst. Wenn Sie zum Beispiel einen komplizierten Code in einem realen Softwaresystem nehmen, der in der Vergangenheit voller Fehler war, und Sie ein paar einfache Tests darum herum machen, und Sie haben diese Fehler nicht mehr – dann wird das Vertrauen steigen, die Leute werden nicht mehr so ängstlich sein, und sie werden sich daran erinnern und das Testen ins Spiel bringen, wenn sie das nächste Mal unsicher sind.

Sie müssen das Testen nicht vorschreiben, wenn die Leute die Vorteile aus erster Hand erfahren haben.

Bernard Perlas

@MyCorporation

Bernard Perlas ist ein Quality Assurance Manager bei MyCorporation, der an der DeVry University ausgebildet wurde. Er führt Tests für bestehende Produkte sowie Updates für Produkte und interne Systeme durch. Er arbeitet an der Entwicklung von UI-Automatisierungstests und Grey-Box-Tests der Website, um sicherzustellen, dass die Informationen korrekt sind.

„Schlecht konstruierte Testfälle haben vage Testschritte gemeinsam…“

Um diese Fehler zu vermeiden, müssen Sie spezifisch sein in Bezug auf das, was Sie testen, und sich über Ihre Schritte auf dem Weg klar sein. Je spezifischer Sie sind, desto eher werden Sie in der Lage sein, Probleme zu replizieren und Bereiche für Verbesserungen zu identifizieren und darauf zu reagieren.

Benjamin Waldher

@wildebeest_dev

Benjamin Waldher ist der Lead Dev Ops Engineer bei Wildebeest.

„Schlechte Testfälle sind oft sehr abhängig von…“

Die interne Funktionsweise des zu testenden Codes, was bedeuten kann, dass wenn interne Details einer Funktion geändert werden, der Testfall bricht – selbst wenn die Funktion bereits richtig funktioniert. Wenn Sie das Gefühl haben, dass Sie diesen Fehler machen, könnte es daran liegen, dass die Funktionen, die Sie testen, zu lang sind, oder dass Sie mehr Trennung von Belangen praktizieren müssen.

Matt MacPherson

@itsMattMac

Matt MacPherson ist der Gründer von Edabit.

„Es gibt ein paar Dinge, die schlecht konstruierte Testfälle gemeinsam haben…“

1. Testen von irrelevantem Zeug

Testen ohne einen wirklichen Zweck ist sinnlos. Ich bin ein großer Fan des „Single Responsibility“-Prinzips. Jeder Unit-Test sollte eine Sache testen und das war’s.

2. Sofort testen

Ich werde dafür wahrscheinlich eine Menge Kritik einstecken, aber ich mache nie Unit-Tests, bevor meine Design-Entscheidungen nicht gefestigt sind. Das liegt daran, dass ich weiß, dass ich ziemlich große Änderungen machen werde und diese Änderungen werden wahrscheinlich viele meiner Tests kaputt machen. Das bedeutet, dass ich in der Praxis entweder weniger Tests schreiben werde, oder ich werde keine großen Änderungen am Design vornehmen. Beides ist schlecht, und das Warten auf Klarheit im Design löst das Dilemma.

3. Integrationstests vs. Unit-Tests

Ich sehe viele Entwickler, die Integrationstests machen, obwohl sie eigentlich Unit-Tests machen wollen (und umgekehrt). Wenn Sie die Anwendung als Ganzes auf Fehler testen, wird das als Integrationstest bezeichnet. Der Unit-Test befasst sich mit dem Verhalten einer bestimmten Einheit des Codes, während sich der Integrationstest mit dem Verhalten der Anwendung als Ganzes befasst.

Manu Singh

@ClrMobile

Manu Singh ist ein Mobile Architect bei Clearbridge Mobile mit Erfahrung in Android Design, Entwicklung und Testing. Bei Clearbridge verwaltet Manu die Projektressourcen für ein Team von Entwicklern, die erstklassige Apps für Unternehmenskunden entwickeln.

„Es gibt mehrere Gemeinsamkeiten, die schlecht konstruierte Testfälle aufweisen…“

Erstens sind die Testfälle möglicherweise zu einfach, das heißt, sie testen nur die Hauptfunktion, ohne zu viele Extremfälle zu testen. Um dies zu vermeiden, sollte ein Entwickler so viele Eckfälle wie möglich abdecken. Wenn eine Schnittstelle entwickelt wird und eine Eingabe erfordert, die nicht trivial ist, dann ist das Testen auf schlechte oder leere Eingaben wichtig.

Zweitens spiegeln schlecht konstruierte Testfälle nicht wider, wie ein Benutzer die Funktionalität wahrnehmen und verwenden wird. Testfälle dafür zu erstellen ist schwieriger, da man sich in die Denkweise eines anderen Benutzers versetzen muss. Ziehen Sie in Erwägung, Ihre Benutzer zu segmentieren und ihre Anwendungsfälle zu identifizieren. Identifizieren Sie dann die schnellsten Wege, um eine User Journey abzuschließen, da ein Benutzer versuchen wird, die Anzahl der Schritte zu reduzieren, die er eingeben muss, um eine bestimmte Journey abzuschließen. Es ist wichtig, verschiedene Anwendungsfälle zu qualifizieren, mit Designern und Projektmanagern, um diese Arten von Testfällen weiter zu identifizieren.

Und schließlich testet ein schlecht konstruierter Testfall nicht gegen Aspekte einer App, die dazu führen könnten, dass sie parallel oder nacheinander gestartet wird. Oftmals testen die Testfälle nur für ein bestimmtes Feature einer App, ohne die Auswirkungen zu sehen, wenn mehrere Features aktiviert sind und miteinander interagieren. Die Berücksichtigung von funktionsübergreifenden Testfällen ist wichtig, insbesondere wenn es Leistungseinschränkungen gibt. Zwei scheinbar getrennte Funktionen können die gleichen Ressourcen verbrauchen und so Deadlocks verursachen.

Rick Rampton

@QASource

Rick Rampton ist Head of Client Success bei QASource und betreut die Bereiche Marketing, Vertrieb und Kundenmanagement. Er war maßgeblich am Aufbau von QASource beteiligt und verfügt über eine nachgewiesene Erfolgsbilanz beim Aufbau, Management und der Bindung von leistungsstarken Ingenieurteams im Ausland. Das Unternehmen hat seinen Hauptsitz in Pleasanton, Kalifornien, QASource ist einer der weltweit führenden Software-QS-Anbieter.

„Es gibt mehrere Erkennungsmerkmale, anhand derer wir einen schlecht konstruierten Testfall erkennen können…“

1. Viele Male zeigt eine Zusammenfassung der schlechten Testfälle nicht das Ziel des Testfalls oder das, was erreicht werden muss.
2. Die Voraussetzung für die Ausführung des Testfalls ist nicht klar definiert oder fehlt, was beim Entwickler/Tester zu Verwirrung darüber führen kann, welche Testdaten oder -bedingungen vor der Ausführung des Testfalls erforderlich sind.
3. Wenn Schritte in den Testfällen fehlen, entstehen Lücken für den Entwickler/Tester, die dazu führen, dass er bei der Ausführung von Testfällen Annahmen trifft. Dies kann dazu führen, dass die Testfälle ungenau ausgeführt und wichtige Szenarien übersehen werden.
4. Das Fehlen der richtigen Umgebung für die Ausführung der Testfälle ist ein weiterer Indikator für schlecht konstruierte Testfälle.
5. Wenn das erwartete Ergebnis nicht klar im Testfall beschrieben ist, dann wird der Tester nicht sicher sein, welche Ergebnisse er mit diesem Testfall überprüfen muss.

Rachel Honoway

@rachelhonoway

Rachel ist eine erfahrene Führungskraft, die sich auf Internet-Startups und Wachstumsunternehmen spezialisiert hat. In ihrer Karriere hat sie mit Unternehmern zusammengearbeitet, um SaaS-Produkte und zugehörige Dienstleistungen aufzubauen und zu erweitern.

„Die Abfolge der Ereignisse ist oft zu vereinfacht, was zu einem schlecht konstruierten Testfall führt…“

Entwickler neigen dazu, einen geraden, logischen Weg vom Anfang bis zum Ende anzunehmen. In der Realität werden die Endbenutzer jedoch eine exponentielle Anzahl von Wegen nehmen, von denen viele unlogisch sind. Wenn Entwickler sich nicht die Zeit nehmen, alle Variablen zu berücksichtigen, die den Benutzer in dem Moment beeinflussen, in dem er mit dem Feature/der Seite/Funktion konfrontiert wird, lassen sie viel Raum für falsch-positive Tests.

In der Regel sollten Entwickler mehrere Benutzer beobachten, wie sie mit der Plattform interagieren, und dann einige Zeit damit verbringen, interne Kundenbetreuer (Kundensupport, Produktmanager, Vertriebsmitarbeiter) zu befragen, um den Benutzer besser zu verstehen. Vertriebsmitarbeiter können helfen zu definieren, wer der Benutzer ist und den Bedarf beschreiben, den die Anwendung befriedigt. Mitarbeiter des Kundensupports können häufige Knackpunkte für den Anwenderstamm identifizieren, wie z.B. verlorene Passwörter oder häufige Ablenkungsmanöver, wie z.B. Werbung auf der Seite. Produktmanager können einen Einblick geben, wie der Benutzer mit der Anwendung interagiert und wie diese Interaktion in den größeren Arbeitsablauf oder die tägliche Routine des Benutzers passt, indem sie Ablenkungen beschreiben, die außerhalb der Anwendung selbst auftreten (Verwaltung mehrerer Bildschirme gleichzeitig, mobile Benutzer, die während des Fahrens Benachrichtigungen erhalten, usw.).

Das Verständnis dessen, was den Endbenutzer vom logischen, geraden Weg abbringen kann, hilft den Entwicklern, auf diese Variablen zu testen und ein erfolgreiches Erlebnis trotz Ablenkungen, unlogischer Pfade und Verlust des Fokus zu gewährleisten.

Anthony Breen

@BreenAnthony77

Anthony Breen ist der Mitbegründer und CEO der Feasty Eats App. Feasty Eats ist eine integrierte SaaS-Plattform, die Restaurants dabei hilft, den Traffic während ihrer umsatzschwachen Zeiten zu steigern.

„Wenn man Testfälle in Betracht zieht…“

Es ist wichtig für Entwickler, auf einige der einfachsten, aber wichtigsten Aspekte des Untersuchungsprozesses zurückzugehen. Genau wie bei einem wissenschaftlichen Experiment gibt es zwei Faktoren, die bei jedem Entwickler im Vordergrund stehen müssen, um einen effektiven und sinnvollen Test zu ermöglichen: Klarheit und Kontrolle. Genauer gesagt, müssen klar umrissene Hypothesen und eine sorgfältige Beachtung der wichtigsten Leistungsindikatoren vor dem Beginn des Tests kommuniziert werden. Dadurch wird ein solider Rahmen für weitere Untersuchungen geschaffen.

Zudem ist es wichtig, dass alle Variablen nicht nur identifiziert, sondern auch sorgfältig kontrolliert werden. Verzerrungen müssen aus den Testpopulationen eliminiert und potenzielle Störvariablen müssen identifiziert werden, damit die Entwickler aufschlussreiche und genaue Daten erhalten können. Ein gut definierter und klar artikulierter Zweck, gepaart mit einer sorgfältig kontrollierten Testumgebung, wird nicht nur wertvolle Ergebnisse liefern, sondern, was noch wichtiger ist, neue Fragen und Hypothesen hervorrufen, die zu einer erweiterten Untersuchung führen.

Devlin Fenton

@devfen

Devlin Fenton ist der CEO von Go99. Devlin leitet ein kleines, spezialisiertes Team von Ingenieuren und Programmierern, die sich der Lösung von Problemen durch die Industrie, für die Industrie verschrieben haben. Dieses Team hat vor kurzem eine digitale Plattform für den Frachtabgleich ins Leben gerufen, die die 700 Milliarden Dollar schwere nordamerikanische Trucking-Branche auf den Kopf stellen soll. Devlin ist der Meinung, dass man ein Expertenteam aufbauen und es gedeihen lassen sollte.

„Die schlimmsten Testfälle sind die, die es nicht gibt.“

Das mit Abstand größte Problem ist, dass es nicht genug davon gibt und das System nicht zuverlässig automatisiert getestet werden kann. Es fehlt die Berücksichtigung der Priorität. Wenn Entwickler erst einmal damit beginnen, Testfälle zu schreiben, entwickeln sie oft viele der einfachen Fälle, die trivialen, statischen und risikoarmen Code testen. Man sollte sich auf komplexen und risikoreichen Code konzentrieren und dafür ist der Anwendungsfall manchmal auch komplexer und schwieriger zu entwickeln.

Der Glaube ist, dass wenn es kein Unit-Test ist, es nicht gemacht werden sollte. Integrationstests, Datentests, Performancetests, Stresstests und so weiter sollten alle Teil der Testsuite sein.

Ein weiteres Problem ist der fehlende Fokus in Bezug auf das Ziel. Handelt es sich zum Beispiel um einen Unit-Test, einen Integrationstest, einen Performance-Test oder einen anderen Typ? Die Vermischung dieser Prioritäten macht die Anwendungsfälle spröder und schwieriger zu beheben. Sie müssen einen Fokus haben und entsprechend annotiert werden, damit die Testsuite zielgerichtet ausgeführt werden kann.

Zudem mangelt es einigen Testfällen an Gründlichkeit, indem sie nur einen glücklichen Pfad abdecken und nicht genug von den Alternativ- und Ausnahmeabläufen. Effektiv folgt der Anwendungsfall dem „Make-it-work“-Standard des Entwicklers, statt dem „Make-it-fail“-Standard des Testens.

Ein weiteres Problem sind Testfälle, die nicht gewartet werden, was dazu führen würde, dass sie bei der Ausführung fehlschlagen, oder sie sind komplett auskommentiert. In der Eile ändern die Entwickler oft den Code und umgehen die Korrektur der Testfälle.

Schlecht konstruierte Testfälle können auch unklar sein, was getestet wird, einschließlich des Objekts, der Methode oder des Szenarios. Testfälle sollten einer Konvention folgen (Namensgebung, Kommentare, etc.), die es einfach macht, den Umfang des Tests zu identifizieren.

Gute Testfälle vermeiden ein Netz von Abhängigkeiten. Abhängigkeiten zwischen Testfällen sollten vermieden werden; andernfalls kann ein einzelner Fehler dazu führen, dass viele Tests fehlschlagen, was es schwieriger macht, die Ursache zu identifizieren. Wenn es eine gemeinsame Logik für das Aufstellen von Vorbedingungen oder das Auswerten von Ergebnissen gibt, sollte diese Logik abstrahiert und gemeinsam genutzt werden, anstatt Testfälle zu stapeln.

Rohit Keserwani

@EquifaxInsights

Rohit Keserwani ist BI-Consultant und Sr. Business Analyst bei Equifax.

„Ich habe die folgenden Merkmale beobachtet, die in schlechten Testfällen häufig vorkommen…“

1. Impact-Analyse nicht dokumentiert. Wenn ein Testanalyst die Auswirkungen nicht dokumentiert, geht er davon aus, dass er die Auswirkungen nicht kennt. Das Ergebnis? POOF…!

2. Die Testvoraussetzung ist entweder nicht definiert oder nur lose formuliert.

3. Den Benutzerhintergrund übersehen und Dinge annehmen. Wenn Sie den Wissensstand der Person, die testen soll, nicht kennen, nehmen Sie nichts an. Dokumentieren Sie einfach alles bis ins kleinste Detail. Wenn Sie das nicht tun, könnte es passieren, dass Sie von fehlendem Wissen ausgehen, was dazu führen kann, dass der Benutzer anders testet als erwartet.

4. Pass-Kriterien und Toleranz nicht klar definiert. Wenn die Bestehenskriterien aus irgendeinem Grund nicht artikuliert sind, ist die testende Person ihrer Fantasie überlassen, um zu entscheiden, ob ein bestimmter Test bestanden wurde oder nicht. Wenn Sie kein klar definiertes Pass-Szenario haben, hat der Tester keinen Benchmark, mit dem er vergleichen kann. Das würde zu Unklarheiten führen und letztendlich den gesamten Testaufwand in Frage stellen.

Pete Van Horn

@PraxentSoftware

Pete Van Horn ist Business Technology Analyst bei Praxent.

„Ich habe eine Menge Erfahrung mit schlecht konstruierten Testfällen, und ich bin wahrscheinlich auch schuldig, sie von Zeit zu Zeit zu schreiben…“

Viele Male ist ein Testfall nicht einfach ausführbar. Wenn ich ein Entwickler bin, sollte ich in der Lage sein, genügend Informationen zu haben und so positioniert zu sein, dass ich meinen Testfall ausführen kann, um ein Ergebnis zu ermitteln. Ich denke, eine Sache bei Testfällen ist, dass sie nicht unbedingt zu dem beabsichtigten Ergebnis führen müssen, aber sie müssen immer von Ende zu Ende ausführbar sein. Selbst wenn Sie ein negatives Ergebnis erhalten, ist das besser, als stecken zu bleiben. Ein schlecht konstruierter Testfall versetzt denjenigen, der den Test durchführt, nicht in die Lage, ihn vollständig auszuführen.

In Bezug auf die Fehler der Entwickler, denke ich vielleicht zu viel darüber nach, aber typischerweise schreiben Entwickler nicht den Testfall. Sie schreiben vielleicht Unit-Tests, aber ein Testfall wird normalerweise von einem Business-Analysten oder einem Solution Architect geschrieben. Sie sind für die Erstellung des erwarteten Ergebnisses verantwortlich. Ich würde sagen, dass gut geschriebene Testfälle ihren Ursprung in wirklich gut geschriebenen Anforderungen haben. Wenn man gute Anforderungen hat, kann man einen guten Testfall erstellen. Und ein guter Testfall ist in der Lage, von Ende zu Ende ausgeführt zu werden, ohne Unterbrechung.

Hans Buwalda

@logigear

Bei Stackify verstehen wir, wie wichtig Softwaretests im Entwicklungslebenszyklus sind, daher ist es ein Thema, das wir regelmäßig diskutieren. Wussten Sie, dass Sie APM in Ihre Teststrategie integrieren können?

Wenn Sie mehr Expertenratschläge zum Schreiben von qualitativ hochwertigen Testfällen suchen (und warum es wie die wissenschaftliche Methode ist), lesen Sie diesen Beitrag, oder besuchen Sie diesen Artikel für eine Liste von 101 Expertentipps für Softwaretests und Ratschläge, um das Beste aus Ihrem Testprozess herauszuholen. Einen tieferen Einblick in die Arten von Performance-Tests und Software-Tests, Performance-Testing-Schritte und Best Practices erhalten Sie in diesem Leitfaden.