STLC - Grundprinzipien testen
Das gemeinsame Ziel des Testens ist es, Fehler so früh wie möglich zu finden. Und sobald die Fehler behoben sind, stellen Sie sicher, dass sie wie erwartet funktionieren und keine anderen Funktionen beeinträchtigen.
Um diese Ziele zu erreichen, werden sieben Grundprinzipien für Softwaretests angegeben:
Was zeigt das Testen?
Tests können zeigen, dass Mängel vorliegen, es kann jedoch nicht nachgewiesen werden, dass das Produkt keine Mängel aufweist. Testphasen stellen sicher, dass die zu testende Anwendung auf der Grundlage der angegebenen Anforderungen funktioniert, und tragen dazu bei, die Wahrscheinlichkeit unentdeckter Fehler in der Anwendung zu verringern. Aber selbst wenn keine Mängel festgestellt werden, bedeutet dies nicht, dass es absolut korrekt ist. Wir können davon ausgehen, dass AUT mit unseren Ausstiegskriterien übereinstimmt und die Anforderungen gemäß SRD einhält.
Ist eine umfassende Prüfung möglich?
Eine 100% ige Abdeckung oder Prüfung aller Kombinationen von Eingaben und möglichen Kombinationen ist nur in trivialen Fällen möglich. Anstelle umfassender Tests werden Risikoanalysen und Prioritäten verwendet, um den Testumfang zu definieren. Hier können die meisten Echtzeitszenarien auch das wahrscheinlichste negative Szenario berücksichtigen. Dies hilft uns, den Fehler zu verfolgen.
Frühes Testen
Die Testaktivitäten sollten so bald wie möglich beginnen und sich auf definierte Ziele in der Teststrategie und die erwarteten Ergebnisse konzentrieren. Die frühe Testphase hilft dabei, Anforderungsfehler oder Abweichungen auf Designebene zu identifizieren. Wenn diese Arten von Fehlern in der Anfangsphase erfasst werden, können wir Zeit sparen und sind auch kostengünstig. Die Antwort darauf, warum das Testen frühzeitig beginnen sollte, ist sehr einfach: Sobald die SRD eingegangen ist, können die Tester die Anforderung aus der Testperspektive analysieren und eine Anforderungsdiskrepanz feststellen.
Fehlerclustering
Basierend auf früheren Produktfehleranalysen kann gesagt werden, dass die meisten Fehler anhand eines kleinen Satzes von Modulen identifiziert werden, die für die Anwendung kritisch sind. Diese Module können anhand der Komplexität, der unterschiedlichen Systeminteraktion oder der Abhängigkeit von verschiedenen anderen Modulen identifiziert werden. Wenn Tester diese wichtigen Module identifizieren können, können sie sich stärker auf diese Module konzentrieren, um alle möglichen Fehler zu identifizieren. In einer Studie wurde festgestellt, dass 8 von 10 Defekten anhand einer 20% igen Funktionalität von AUT identifiziert wurden.
Pestizid paradox
Was ist ein Pestizid-Paradoxon? Wenn Pestizide häufig in Kulturpflanzen eingesetzt werden, kommt es vor, dass die Insekten eine bestimmte Art von Resistenz entwickeln und die so gesprühten Pestizide allmählich auf die Insekten unwirksam zu sein scheinen.
Das gleiche Konzept gilt auch für Tests. Hier sind Insekten Käfer, während Pestizide Testfälle sind, die immer wieder eingesetzt werden. Wenn dieselben Testfallgruppen immer wieder ausgeführt werden, werden diese Testfälle nach einem bestimmten Zeitraum unwirksam und die Tester können keinen neuen Fehler identifizieren.
Um diese Bedingungen zu überwinden, sollten Testfälle von Zeit zu Zeit überarbeitet und überprüft werden, und neue und unterschiedliche Testfälle können hinzugefügt werden. Dies hilft bei der Identifizierung neuer Fehler.
Das Testen ist kontextabhängig
Dieses Prinzip besagt, dass zwei verschiedene Anwendungstypen erst mit demselben Ansatz getestet werden können, wenn beide Anwendungen von gleicher Natur sind. Wenn ein Tester beispielsweise denselben Ansatz für webbasierte Anwendungen und mobile Anwendungen verwendet, ist dies völlig falsch und es besteht ein hohes Risiko für eine schlechte Qualität der Produktfreigabe. Tester sollten unterschiedliche Ansätze, Methoden, Techniken und Abdeckungen für unterschiedliche Arten und Arten von Anwendungen verwenden.
Fehlen von Fehlern - Irrtum
Dieses Prinzip besagt, dass Fehler gefunden und behoben werden müssen, bis die Anwendung oder das System stabil ist, zeitaufwändig ist und auch Ressourcen verbraucht. Selbst nach Behebung von 99% der Defekte besteht ein hohes Risiko einer instabilen Anwendung. Das erste wesentliche Element ist die Überprüfung der Stabilität der Anwendung und der Voraussetzungen der Umgebung. Wenn diese beiden Bedingungen erfüllt sind, können wir erst dann mit den detaillierten Tests beginnen.