Im Jahr 2002 veröffentlichte das National Institute of Standards and Technology (NIST) einen Bericht, in dem die wirtschaftlichen Auswirkungen unzureichender Softwaretests detailliert beschrieben wurden (NIST-Bericht, 2002). Der Bericht kam zu folgendem Schluss:
„… die nationalen jährlichen Kosten einer unzureichenden Infrastruktur für Softwaretests werden auf 22,2 bis 59,5 Milliarden US-Dollar geschätzt.“
Der NIST-Bericht wies auch darauf hin, dass es in der Praxis beklagenswert mangelhaft sei, Softwaretests durchzuführen.
Sieben Jahre später untersuchten Wong et al. in einem Bericht der IEEE Reliability Society (Wong et al., 2009) 15 weithin bekannte Softwarefehler, von denen einige zum Verlust von Menschenleben führten, und kamen zu folgendem Schluss:
„…es müssen bessere Testverfahren und -praktiken implementiert werden, und dies gilt insbesondere für Software, die mit sicherheitskritischen Systemen in Zusammenhang steht.“
In einem neueren Artikel untersuchten Wong et al. eine Reihe von Softwarefehlern in mehreren Branchen (Wong et al., 2017) und kamen zu einem ziemlich ernüchternden Schluss:
„…die enttäuschende Wahrheit ist, dass Software alles andere als fehlerfrei ist und jedes Jahr große Summen ausgegeben werden, um (fehlerhafte) Software zu reparieren oder zu warten.“
Der Artikel analysierte Softwarefehler über einen Zeitraum von 30 Jahren, von 1985 bis 2015. Er identifizierte die Art der Softwarefehler, die die Fehler verursachten, sowie andere beitragende Faktoren wie Benutzerfehler. Er klassifizierte die Fehler in zwei Kategorien: diejenigen, die tödlich waren (zum Tod führten) und diejenigen, die nicht tödlich waren, aber erhebliche wirtschaftliche Verluste verursachten. Zu den tödlichen Fehlern gehörten der Therac-25-Zwischenfall von 1985, bei dem mindestens sechs Patienten eine Überdosis Strahlung erhielten, sowie Unfälle in der Zivilluftfahrt zwischen 1995 und 1997, bei denen mehr als 650 Menschen ums Leben kamen. Er umfasste auch den Ebola-Zwischenfall von 2014, bei dem ein Softwarefehler in elektronischen Patientenakten zu einer Fehldiagnose eines mit Ebola infizierten Patienten führte, was zu einem späteren Tod führte. Zu den nicht tödlichen Fehlern gehörten ein Softwarefehler in einem Kernkraftwerk, der zu einem Verlust von 2 Millionen Dollar führte, sowie der Softwarefehler bei Ariane 5, der einen Verlust von 7 Milliarden Dollar verursachte. In ihrer Schlussfolgerung machten die Autoren folgende Beobachtung:
„… die Allgegenwart eingebetteter Software in der öffentlichen Infrastruktur, in Transportsystemen, in Konsumgütern und mehr lässt [uns] ungläubig zurück, dass jemand, der an komplexen Softwaresystemen gearbeitet hat, glauben kann, dass es möglich ist, solche Systeme fehlerfrei zu bauen …“
Trotz dieser ernüchternden Schilderungen der Softwaresysteme, auf die wir uns immer mehr verlassen, fehlt in diesen Diskussionen leider ein wichtiger Punkt. Die meisten Softwarefehler bleiben unentdeckt und werden nicht gemeldet. In manchen Fällen ist der Fehler subtil – oder tritt sogar nur zeitweise auf – und wird daher leicht übersehen. Beispielsweise kann eine statistische Softwareanwendung falsch berechnete Statistiken anzeigen. Solche falsch berechneten Statistiken sind Fehler, die jedoch möglicherweise nicht sofort erkennbar sind, insbesondere für einen Laien. Dennoch können solche Fehler zu falschen oder suboptimalen Entscheidungen führen und daher sehr folgenreich sein.
Es ist offensichtlich, dass das Handwerk des Softwareschreibens – unabhängig von der Komplexität der verwendeten integrierten Entwicklungsumgebungen, der Komplexität der Programmiermethoden oder der Fähigkeiten der Programmierer – unvollkommen ist und zu Fehlern führen wird. Diese Realität bedeutet, dass es an der Genauigkeit der Softwaretests liegt, diese Fehler vor der Veröffentlichung der Software zu entdecken. Wie NIST und Wong et. al. anmerken, kann ein Versäumnis erhebliche Konsequenzen haben. Barry Boehm, eine Ikone der Softwareentwicklungsgemeinschaft, wies in seinem bahnbrechenden Aufsatz über die Ökonomie der Softwareentwicklung (Boehm, 1984) darauf hin, dass die Kosten für das Auffinden und Beheben eines Fehlers nach der Softwarebereitstellung normalerweise mindestens 100-mal höher sind als die Kosten für das Identifizieren und Beheben des Fehlers vor der Bereitstellung.
Ist es vor diesem Hintergrund also so, dass Softwaretestmethoden einfach unzureichend sind? Ich würde argumentieren, dass dies nicht der Fall ist. Tatsächlich ist die Softwaretestforschung seit über 50 Jahren ein robustes Forschungsgebiet. 2014 schrieben Orso und Rothermel über die erheblichen Fortschritte bei der Entwicklung von Softwaretestmethoden in den 15 Jahren vor ihrer Arbeit (Orso und Rothermel, 2014). Der 15-jährige Zeitraum vor 2000 war auch eine Zeit dramatischer Entwicklung bei Softwaretestmethoden. Glenford Myers (Myers, 1978) und Boris Beizer (Beizer, 1984), zwei ikonische Figuren der Softwaretest-Community, leisteten ihre Pionierarbeit in den 70er und 80er Jahren. Leider ist das Hauptproblem die Akzeptanz und nicht die Angemessenheit der Testmethoden. Die Softwareentwicklungs-Community hat im Laufe der Jahre trotz der verfügbaren empirischen Beweise für ihre Nützlichkeit nur langsam rigorose Softwaretestmethoden übernommen (Kuhn et. al., 2015, Morgan, 2018). Diese Situation wurde durch zwei Realitäten der Softwareentwicklung noch verschärft. Softwaretests sind notorisch unterfinanziert und verfügen nicht über ausreichend Ressourcen. Darüber hinaus haben die Geschwindigkeit und Komplexität der Softwareentwicklung in den letzten Jahren dramatisch zugenommen.
Softwaresysteme sind heute allgegenwärtiger denn je und spielen in unserem Leben eine immer wichtigere Rolle. Die entscheidende Bedeutung robuster Softwaretestmethoden ist offensichtlich und ein Aspekt der Softwareentwicklung, dessen sich alle Softwareentwickler stärker bewusst sein müssen. Um diesem Bedarf gerecht zu werden, haben wir diese Reihe von Blogbeiträgen ins Leben gerufen. Dieser Beitrag ist der zweite dieser Reihe, und es werden noch weitere folgen.
Zitierte Werke
Beizer, Boris. Softwaresystemtests und Qualitätssicherung . Van Nostrand Reinhold Co., 1984.
Boehm, Barry W. „Software Engineering Economics“. IEEE Transactions on Software Engineering (1984): 4-21.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). „Kombinatorisches Testen: Theorie und Praxis.“ Advances in computers , 99 , 1-66.
Myers, Glenford J. „Ein kontrolliertes Experiment zum Testen von Programmen und Durchläufen/Inspektionen von Code.“ Communications of the ACM 21.9 (1978): 760-768.
Morgan, J. (2018). „Kombinatorisches Testen: ein Ansatz für System- und Softwaretests basierend auf abdeckenden Arrays.“ Analytische Methoden beim System- und Softwaretesten , 131-158.
NIST-Bericht. „Die wirtschaftlichen Auswirkungen einer unzureichenden Infrastruktur für Softwaretests.“ Planungsbericht 02-3 des National Institute of Standards and Technology . Mai 2002.
Orso, A. und Rothermel, G. (2014) „Softwaretests: Ein Forschungsreisebericht (2000–2014)“, in Proceedings on the Future of Software Engineering , ACM, Mai 2014, S. 117–132
Wong, W. Eric, Vidroha Debroy und Andrew Restrepo. „Die Rolle von Software bei den jüngsten katastrophalen Unfällen.“ IEEE Reliability Society 2009 Annual Technology Report 59.3 (2009).
Wong, W. Eric, Xuelin Li und Philip A. Laplante. „Lernen Sie unsere Feinde besser kennen und ebnen Sie den Weg nach vorne: Eine Untersuchung der Rolle von Bugs bei Softwarefehlern.“ Journal of Systems and Software 133 (2017): 68-94.
Wenn eine Software abertausende verschiedene Funktionen bietet, wird es schwierig zu garantieren, dass alle zusammenarbeiten – und dass zwei Funktionen mit einer dritten harmonieren.
Dies ist in Tiny Traps in Jmp und JSL zu sehen.
Manchmal führt die Kombination von zwei oder drei coolen Funktionen zu einem unerwarteten Ergebnis.
Es ist schwierig, all diese winzigen Interaktionen zu testen – aber die Schwarmintelligenz des Benutzers hat eine Chance ; )
Vielen Dank an das JMP-Supportteam für seine Bemühungen, das Benutzerfeedback zu organisieren und zu kanalisieren!
Wir danken den Entwicklern für ihren Eifer, uns Software zu liefern, die einwandfrei funktioniert!
Kombinatorisches Testen (siehe unten für Referenzen aus dem Beitrag) ist ein Testansatz, der sich auf Fehler konzentriert, die auf Interaktionen zurückzuführen sind. Das zugrunde liegende mathematische Objekt ist ein überlagerndes Array und daher ist dies ein hocheffizienter Ansatz, selbst wenn Tausende von Eingaben vorhanden sind! Dies wird ein Thema eines zukünftigen Blogs sein.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). „Kombinatorisches Testen: Theorie und Praxis.“ Advances in computers , 99 , 1-66.
Morgan, J. (2018). „Kombinatorisches Testen: ein Ansatz für System- und Softwaretests basierend auf abdeckenden Arrays.“ Analytische Methoden beim System- und Softwaretesten , 131-158.
@Vins , es werden Methoden entwickelt, um dies zu tun. Die Antwort lautet also „Ja und Ja“. Erst vor ein paar Wochen hat unser Kollege bei MEMOCODE-2024 ( https://memocode2024.github.io/program.html ) einen Vortrag darüber gehalten. Die Idee besteht darin , die Bayes-Analyse zu verwenden, um die Auswahl nachfolgender Testfälle zu steuern (d. h. eine Methode zur sequentiellen Testfallgestaltung). Der Titel des Papiers lautet:
„MaLT: Maschinell-lerngestütztes Testfalldesign und Fehlerlokalisierung komplexer Softwaresysteme.“
Die Protokolle der MEMOCODE-2024-Konferenz werden bald veröffentlicht, aber Sie können das Papier möglicherweise finden, wenn Sie in Google Scholar nach dem Titel suchen. Ich werde wahrscheinlich in meinem Blog zum kombinatorischen Testen ein wenig dazu sagen.
