7 principles software testing
Sieben Prinzipien des Softwaretests: Einschließlich weiterer Details zu Fehlerclustering, Pareto-Prinzip und Pestizidparadoxon.
Ich bin mir sicher, dass jeder das ' Sieben Prinzipien des Softwaretests ”.
Diese grundlegenden Testprinzipien helfen den Testteams, ihre Zeit und Mühe zu nutzen, um den Testprozess effektiv zu gestalten. In diesem Artikel werden wir im Detail zwei Prinzipien kennenlernen, d.h. Defektclustering, Pareto-Prinzip und Pestizid-Paradoxon .
Was du lernen wirst:
- Sieben Prinzipien des Softwaretests
Sieben Prinzipien des Softwaretests
Bevor wir uns eingehend mit diesen beiden Prinzipien befassen, wollen wir kurz die sieben Prinzipien des Softwaretests verstehen.
Lass uns erforschen!!
# 1) Testen zeigt das Vorhandensein von Fehlern
Jede Anwendung oder jedes Produkt wird nach einer ausreichenden Anzahl von Tests durch verschiedene Teams in die Produktion freigegeben oder durchläuft verschiedene Phasen wie Systemintegrationstests, Benutzerakzeptanztests und Betatests usw.
So Haben Sie jemals von einem Testteam gesehen oder gehört, dass es die Software vollständig getestet hat und kein Fehler in der Software vorliegt? ? Stattdessen bestätigt jedes Testteam, dass die Software alle Geschäftsanforderungen erfüllt und gemäß den Anforderungen des Endbenutzers funktioniert.
In der Software-Testbranche wird niemand sagen, dass dies der Fall ist kein Defekt in der Software, was durchaus zutrifft, da Tests nicht beweisen können, dass die Software fehlerfrei oder fehlerfrei ist.
Ziel des Testens ist es jedoch, mit verschiedenen Techniken und Methoden immer mehr versteckte Fehler zu finden. Tests können unentdeckte Fehler aufdecken. Wenn keine Fehler gefunden werden, bedeutet dies nicht, dass die Software fehlerfrei ist.
Beispiel 1 ::
Betrachten Sie eine Banking-Anwendung, diese Anwendung wird gründlich getestet und durchläuft verschiedene Testphasen wie SIT, UAT usw., und derzeit werden keine Fehler im System identifiziert.
Es besteht jedoch die Möglichkeit, dass der tatsächliche Kunde in der Produktionsumgebung eine Funktionalität ausprobiert, die im Bankensystem nur selten verwendet wird, und die Tester diese Funktionalität übersehen haben. Daher wurde bis heute kein Fehler gefunden oder der Code wurde von Entwicklern nie berührt .
Beispiel 2:
Wir haben im Fernsehen mehrere Anzeigen für Seifen, Zahnpasta, Handwäsche oder Desinfektionssprays usw. gesehen.
Stellen Sie sich eine Handwaschwerbung vor, die im Fernsehen besagt, dass 99% der Keime entfernt werden können, wenn diese spezielle Handwäsche verwendet wird. Dies zeigt deutlich, dass das Produkt nicht 100% keimfrei ist. Daher können wir in unserem Testkonzept sagen, dass keine Software fehlerfrei ist.
# 2) Frühes Testen
Tester müssen sich frühzeitig in den Software Development Life Cycle (SDLC) einbringen. Somit können die Mängel während der Anforderungsanalysephase oder etwaige Dokumentationsfehler identifiziert werden. Die Kosten für die Behebung solcher Fehler sind im Vergleich zu den Kosten, die in späteren Testphasen festgestellt werden, sehr gering.
Betrachten Sie das folgende Bild, das zeigt, wie sich die Kosten für die Fehlerbehebung erhöhen, wenn die Tests auf die Live-Produktion umgestellt werden.
(Bild Quelle ))
Das obige Bild zeigt, dass die Kosten für die Behebung eines während der Anforderungsanalyse festgestellten Fehlers geringer sind und mit zunehmender Test- oder Wartungsphase weiter steigen.
Nun ist die Frage Wie früh sollte der Test beginnen? ?
Sobald die Anforderungen festgelegt sind, müssen die Tester zum Testen einbezogen werden. Das Testen sollte an Anforderungsdokumenten, Spezifikationen oder anderen Dokumenttypen durchgeführt werden, damit bei falsch definierten Anforderungen diese sofort behoben werden können, anstatt sie in der Entwicklungsphase zu beheben.
# 3) Vollständige Tests sind nicht möglich
Es ist nicht möglich, alle Funktionen mit allen gültigen und ungültigen Kombinationen von Eingabedaten während des tatsächlichen Tests zu testen. Anstelle dieses Ansatzes wird das Testen einiger Kombinationen basierend auf der Priorität unter Verwendung verschiedener Techniken betrachtet.
Umfassende Tests erfordern unbegrenzte Anstrengungen, und die meisten dieser Anstrengungen sind unwirksam. Außerdem können in den Projektzeitplänen nicht so viele Kombinationen getestet werden. Daher wird empfohlen, Eingabedaten mit verschiedenen Methoden wie Äquivalenzpartitionierung und Grenzwertanalyse zu testen.
Zum Beispiel ,Angenommen, wir haben ein Eingabefeld, das nur Alphabete, Sonderzeichen und Zahlen von 0 bis 1000 akzeptiert. Stellen Sie sich vor, wie viele Kombinationen zum Testen erscheinen würden. Es ist nicht möglich, alle Kombinationen für jeden Eingabetyp zu testen.
Der zum Testen erforderliche Testaufwand ist enorm und wirkt sich auch auf den Zeitplan und die Kosten des Projekts aus. Daher wird immer gesagt, dass erschöpfende Tests praktisch nicht möglich sind.
# 4) Das Testen ist kontextabhängig
Es gibt verschiedene Domains auf dem Markt, wie Banken, Versicherungen, Medizin, Reisen, Werbung usw., und jede Domain hat eine Reihe von Anwendungen. Außerdem haben ihre Anwendungen für jede Domäne unterschiedliche Anforderungen, Funktionen, unterschiedliche Testzwecke, Risiken, Techniken usw.
Verschiedene Domänen werden unterschiedlich getestet, daher basiert das Testen ausschließlich auf dem Kontext der Domäne oder Anwendung.
Zum Beispiel ,Das Testen einer Bankanwendung unterscheidet sich vom Testen einer E-Commerce- oder Werbeanwendung. Das mit jedem Anwendungstyp verbundene Risiko ist unterschiedlich. Daher ist es nicht effektiv, alle Anwendungstypen mit derselben Methode, Technik und demselben Testtyp zu testen.
# 5) Fehlerclustering
Während des Tests kann es vorkommen, dass die meisten festgestellten Fehler auf eine kleine Anzahl von Modulen zurückzuführen sind. Es kann mehrere Gründe dafür geben, wie die Module komplex sein können, die Codierung in Bezug auf solche Module kompliziert sein kann usw.
Dies ist das Pareto-Prinzip des Softwaretests, bei dem 80% der Probleme in 20% der Module auftreten. Wir werden später in diesem Artikel mehr über das Clustering von Fehlern und das Pareto-Prinzip erfahren.
# 6) Pestizid-Paradoxon
Das Pestizid-Paradox-Prinzip besagt, dass, wenn im Laufe der Zeit immer wieder dieselben Testfälle ausgeführt werden, diese Tests nicht in der Lage sind, neue Fehler im System zu identifizieren.
Um dieses „Pestizid-Paradoxon“ zu überwinden, müssen die Testfälle regelmäßig überprüft und überarbeitet werden. Bei Bedarf kann ein neuer Satz von Testfällen hinzugefügt und die vorhandenen Testfälle können gelöscht werden, wenn keine weiteren Fehler im System gefunden werden können.
# 7) Fehlen eines Fehlers
Wenn die Software vollständig getestet wurde und vor der Veröffentlichung keine Fehler gefunden wurden, können wir sagen, dass die Software zu 99% fehlerfrei ist. Was aber, wenn diese Software gegen falsche Anforderungen getestet wird? In solchen Fällen würde es nicht helfen, Fehler zu finden und rechtzeitig zu beheben, da Tests mit falschen Anforderungen durchgeführt werden, die nicht den Anforderungen des Endbenutzers entsprechen.
Zum Beispiel, Angenommen, die Anwendung bezieht sich auf eine E-Commerce-Website und die Anforderungen an die Funktionalität „Warenkorb oder Einkaufskorb“, die falsch interpretiert und getestet wurden. Selbst das Auffinden weiterer Fehler hilft hier nicht, die Anwendung in die nächste Phase oder in die Produktionsumgebung zu verschieben.
Dies sind die sieben Prinzipien des Softwaretests.
Lassen Sie uns jetzt erkunden Defektclustering, Pareto-Prinzip und Pestizid-Paradoxon in Detail .
Fehlerclustering
Beim Testen einer Software stoßen die Tester meist auf eine Situation, in der die meisten gefundenen Fehler mit bestimmten Funktionen zusammenhängen und die übrigen Funktionen eine geringere Anzahl von Fehlern aufweisen.
Fehlerclustering bedeutet eine kleine Anzahl von Modulen, die die meisten Fehler enthalten. Grundsätzlich sind die Fehler nicht gleichmäßig über die gesamte Anwendung verteilt, sondern die Fehler sind auf zwei oder drei Funktionen konzentriert oder zentralisiert.
Manchmal ist es aufgrund der Komplexität der Anwendung möglich, dass die Codierung komplex oder schwierig ist. Ein Entwickler kann einen Fehler machen, der sich nur auf eine bestimmte Funktionalität oder ein bestimmtes Modul auswirkt.
Defect Clustering basiert auf “ Pareto-Prinzip ”Was auch bekannt ist als 80-20 Regel . Dies bedeutet, dass 80% der gefundenen Fehler auf 20% der Module in der Anwendung zurückzuführen sind. Das Konzept des Pareto-Prinzips wurde ursprünglich von einem italienischen Ökonomen definiert - Vilfrodo Pareto .
Wenn Tester 100 Fehler betrachten, ist nicht klar, ob diese 100 Fehler eine zugrunde liegende Bedeutung haben. Wenn diese 100 Fehler jedoch nach bestimmten Kriterien kategorisiert werden, können die Tester möglicherweise verstehen, dass eine große Anzahl von Fehlern nur zu wenigen spezifischen Modulen gehört.
Zum Beispiel ,Betrachten wir das folgende Bild, das für eine der Bankanwendungen getestet wurde, und es zeigt, dass die meisten Fehler mit der Überziehungsfunktion zusammenhängen. Die übrigen Funktionen wie Kontoübersicht, Überweisung, Daueranweisung usw. weisen eine begrenzte Anzahl von Fehlern auf.
(Bild Quelle ))
Das obige Bild zeigt, dass es von den insgesamt 32 Fehlern 18 Fehler in der Überziehungsfunktion gibt, was bedeutet, dass 60% der Fehler im Modul „Überziehung“ gefunden werden.
Daher konzentrieren sich Tester während der Ausführung hauptsächlich auf diesen Bereich, um immer mehr Fehler zu finden. Es wird empfohlen, dass sich die Tester beim Testen auch auf die anderen Module konzentrieren.
Wenn ein und derselbe Code oder dasselbe Modul immer wieder mit einer Reihe von Testfällen als während der ersten Iterationen getestet wird, ist die Anzahl der Fehler hoch. Nach einer gewissen Iteration wird jedoch die Anzahl der Fehler erheblich reduziert. Fehlerclustering zeigt an, dass der fehleranfällige Bereich während des Regressionstests gründlich getestet werden muss.
Pestizid paradox
Wenn bei einem der Module mehr Fehler festgestellt werden, unternehmen die Tester zusätzliche Anstrengungen, um dieses Modul zu testen.
Nach einigen Testiterationen wird die Codequalität verbessert und die Anzahl der Fehler sinkt, da die meisten Fehler vom Entwicklungsteam behoben werden, da die Entwickler auch beim Codieren eines bestimmten Moduls vorsichtig sind, bei dem die Tester mehr Fehler festgestellt haben.
Daher werden an einem Punkt die meisten Fehler entdeckt und behoben, so dass in diesem Modul keine neuen Fehler gefunden werden.
Manchmal kann es jedoch vorkommen, dass Sie beim Codieren eines bestimmten Moduls besonders vorsichtig sind (in unserem Fall das „ Überziehung Modul) kann der Entwickler die anderen Module vernachlässigen, um sie ordnungsgemäß zu codieren, oder die in diesem bestimmten Modul vorgenommenen Änderungen können sich negativ auf die anderen Funktionen wie Kontozusammenfassung, Geldtransfer und Daueranweisungen auswirken.
Wenn die Tester denselben Satz von Testfällen verwenden, um das Modul auszuführen, in dem die meisten Fehler gefunden wurden (Überziehungsmodul), sind diese Testfälle nach der Behebung dieser Fehler durch die Entwickler nicht sehr effektiv, um neue Fehler zu finden. Als End-to-End-Ablauf des Überziehungskredits wird das Modul gründlich getestet und die Entwickler haben den Code für dieses Modul ebenfalls vorsichtig geschrieben.
Diese Testfälle müssen überarbeitet und aktualisiert werden. Es ist auch eine gute Idee, neue Testfälle hinzuzufügen, damit neue und mehr Fehler in verschiedenen Bereichen der Software oder Anwendung gefunden werden können.
Vorbeugende Methoden des Pestizid-Paradoxons
Es gibt zwei Möglichkeiten, wie wir das Pestizid-Paradoxon verhindern können, wie unten gezeigt:
zu) Schreiben Sie eine neue Reihe von Testfällen, die sich auf verschiedene Bereiche oder Module konzentrieren (außer auf frühere fehleranfällige Module - Beispiel: 'Überziehung') der Software.
b) Bereiten Sie neue Testfälle vor und ergänzen Sie die vorhandenen Testfälle.
In dem ' Methode A. ”Können Tester mehr Fehler in den anderen Modulen finden, auf die sie sich bei den früheren Tests nicht konzentriert haben, oder die Entwickler waren beim Codieren nicht besonders vorsichtig.
In unserem obigen Beispiel können Tester mithilfe der neuen Testfälle weitere Fehler in den Modulen 'Kontoübersicht', 'Geldtransfer' oder 'Standing Instructions' finden.
Es kann jedoch vorkommen, dass die Tester das frühere Modul vernachlässigen ( Beispiel: 'Überziehungskredit'), bei dem die meisten Fehler in der früheren Iteration gefunden wurden und dies ein Risiko darstellen könnte, da diesem Modul (Überziehungskredit) nach der Codierung der anderen Module möglicherweise die neuen Fehler injiziert wurden.
In dem ' Methode B. ”Werden neue Testfälle vorbereitet, damit im Rest der Module neue potenzielle Fehler gefunden werden können.
Hier in unserem Beispiel können neu erstellte Testfälle dazu beitragen, Fehler in den Modulen wie Kontoübersicht, Geldtransfer und Daueranweisung zu identifizieren. Tester können jedoch die früheren fehleranfälligen Module nicht ignorieren ( Beispiel: 'Überziehungskredit'), da diese neuen Testfälle mit den vorhandenen Testfällen zusammengeführt werden.
Die vorhandenen Testfälle konzentrierten sich mehr auf das Modul „Überziehung“ und die neuen Testfälle konzentrierten sich auf die anderen Module. Daher werden alle Testfälle mindestens einmal ausgeführt, selbst wenn ein Code auf einem Modul geändert wird. Dadurch wird sichergestellt, dass eine ordnungsgemäße Regression ausgeführt wird und der Fehler aufgrund dieser Codeänderung identifiziert werden kann.
Bei Verwendung des zweiten Ansatzes steigt die Gesamtzahl der Testfälle erheblich an und führt zu mehr Aufwand und Zeitaufwand für die Ausführung. Dies wird sich offensichtlich auf die Projektlaufzeiten und vor allem auch auf das Projektbudget auswirken.
Um dieses Problem zu lösen, können die redundanten Testfälle überprüft und dann entfernt werden. Es gibt viele Testfälle, die nach dem Hinzufügen neuer Testfälle und dem Ändern der vorhandenen Testfälle unbrauchbar werden.
Es muss überprüft werden, welche Testfälle fehlgeschlagen sind, um die Fehler in den letzten 5 Iterationen zu identifizieren (nehmen wir 5 Iterationen an), und welche Testfälle nicht sehr wichtig sind. Es kann auch der Fall sein, dass der in einigen Testfällen abgedeckte Einzelfluss in einem anderen End-to-End-Testfall abgedeckt werden kann und die Testfälle mit Einzelfluss entfernt werden können.
Dies reduziert wiederum die Gesamtzahl der Testfälle.
Zum Beispiel ,Wir haben 50 Testfälle für ein bestimmtes Modul und wir haben festgestellt, dass von diesen 50 Testfällen 20 Testfälle in den letzten Testiterationen keinen neuen Fehler erkennen konnten (nehmen wir 5 Iterationen an). Daher müssen diese 20 Testfälle gründlich überprüft werden, und wir müssen prüfen, wie wichtig diese Testfälle sind, und es kann entsprechend entschieden werden, ob die 20 Testfälle aufbewahrt oder entfernt werden sollen.
Stellen Sie vor dem Entfernen eines Testfalls sicher, dass der in diesen Testfällen abgedeckte Funktionsablauf in einem anderen Testfall behandelt wird. Dieser Prozess muss über alle Module hinweg befolgt werden, damit die Gesamtzahl der Testfälle erheblich reduziert wird. Dadurch wird sichergestellt, dass die Gesamtzahl der Testfälle reduziert wird, die Anforderungsabdeckung jedoch weiterhin zu 100% besteht.
Dies bedeutet, dass alle verbleibenden Testfälle alle Geschäftsanforderungen abdecken, sodass bei der Qualität keine Kompromisse eingegangen werden.
Fazit
Das Testen von Software ist ein wesentlicher Schritt in SDLC, da überprüft wird, ob die Software den Anforderungen des Endbenutzers entspricht oder nicht.
Beim Testen werden so viele Fehler wie möglich festgestellt. Um Tests effektiv und effizient durchführen zu können, sollte jeder die sieben Prinzipien des Softwaretests kennen und verstehen und klar verstehen, dass sie als Säulen für das Testen bekannt sind.
Die meisten Tester haben diese Prinzipien während der eigentlichen Tests implementiert und erlebt.
Verwenden des iPad für die Verkaufsstelle
Im Allgemeinen bedeutet der Begriff Prinzip die Regeln oder Gesetze, die befolgt werden müssen. Daher muss jeder in der Softwaretestbranche diese sieben Prinzipien befolgen, und wenn jemand eines dieser Prinzipien ignoriert, kann dies für das Projekt enorme Kosten verursachen.
Fröhliches Lesen!!
Literatur-Empfehlungen
- Beste Software-Test-Tools 2021 (QA Test Automation Tools)
- Software Testing QA Assistant Job
- Softwaretestkurs: An welchem Softwaretestinstitut soll ich teilnehmen?
- Wählen Sie Software-Tests als Ihre Karriere
- Software Testing Technical Content Writer Freiberufler Job
- Was ist eine fehlerbasierte Testtechnik?
- Einige interessante Fragen zu Softwaretests
- Feedback und Bewertungen zum Softwaretestkurs