An empirical investigation of human-based and tool-supported testing strategies

Abstract

Testen ist heutzutage weit verbreitet in der modernen Softwareentwicklung. Es ist ein fester Bestandteil der meisten Software Entwicklungsmodelle wie dem Spiralmodell oder dem RUP und findet sich in fast jedem Teil von agilen Praktiken wie SCRUM oder XP wieder. Bei größeren Softwareprojekten werden oft eigenständige Tester eingesetzt, deren Hauptaufgabe das Schreiben von Tests ist. Jedoch, insbesondere bei sequentiellen Entwicklungsprozessen, wo nur einmal nach Implementierung der Software getestet wird, werden aus Zeitgründen oftmals nur die notwendigsten Testfälle erstellt, oder es wird sogar komplett darauf verzichtet, wenn die Testbarkeit des Systems nicht gegeben ist. Test-getriebene Entwicklung ist ein sehr vielversprechender Ansatz, bei welchem die Tests bereits vor der eigentlichen Implementierung erstellt werden und somit die Testbarkeit des Systems garantiert wird. Allerdings werden trotzdem oft nur die für das Design notwendigen Testfälle geschrieben. Dies resultiert nicht selten in Systemen, die unvollständig getestet wurden aber dennoch eingesetzt werden.<br />Da die Anforderungen an Softwaresysteme ständig wachsen und sich ändern, dauert es nicht lange, bis man Unit-Tests benötigt. Damit soll sichergestellt werden, dass Erweiterungen des Systems keinen negativen Einfluss auf die bereits vorhandene Funktionalität haben. Um eine ordnungsgemäße Wartung gewährleisten zu können, müssen nun nachträglich die fehlenden Testfälle erstellt werden. Unterschiedliche Teststrategien - manuell erstellte Tests und toolunterstützte Testfallgenerierung - sind vielversprechende Methoden um Unit-Tests in nicht getesteter Software im industriellen Umfeld einzuführen. Lohnt es sich, wenn Entwickler ihre Zeit in die Analyse von alten oder ihnen unbekannten Code investieren? Rentiert es sich in so einem Fall toolunterstützte Testfallgenerierung einzusetzen? Um eine Antwort auf diese Frage zu finden, führen wir einen Vergleich dieser zwei Teststrategien - manuell erstellte Tests und toolunterstützte Testfallgenerierung - durch. Wir untersuchen, welche der beiden effektiver ist, d.h. wie viele Fehler mit dem Tool gefunden werden können im Gegensatz zur manuellen Erstellung der Testfälle, die das Verständnis der Funktionalität des Systems voraussetzt. Als weitere Ziele dieser Arbeit sehen wir uns an, ob es Unterschiede in der Art der gefundenen Fehler gibt und ob die Kombination der beiden Strategien zu einer signifikanten Verbesserung des Ergebnisses führt.<br />Um zu vergleichen, wie viele Fehler mit den unterschiedlichen Strategien und damit nachträglich geschriebenen Unit-Tests gefunden werden können, haben wir ein kontrolliertes Experiment an der Technischen Universität Wien durchgeführt. Java Collection Klassenbibliotheken, mit insgesamt 35 eingestreuten Fehlern, wurden als das zu testende System verwendet. Da es sich um ein Black-Box Experiment handelt wurde der Quellcode zurückgehalten und nur die Javadoc der Klassen zur Verfügung gestellt.<br />Manuelle Tests für den Vergleich wurden aus einem Experiment mit 48 Studenten, die eine Stunde lang Unit-Tests geschrieben haben, bezogen. Randoop wurde dazu verwendet, für dasselbe zu testende System toolunterstützte Tests zu generieren. Randoop ist ein Feedback-gesteuerter Random Test Generator für Java, der das Ergebnis von bereits erzeugten Testfällen beim Generieren von neuen in Betracht zieht.<br />Die Ergebnisse zeigen, dass beide Teststrategien unterschiedliche Beiträge zur Erhöhung der Software Qualität liefern. Randoop erzielte in kurzer Zeit eine höhere Methodenabdeckung als es mit manuellem Testen möglich war. Bezüglich der Fehlerfindungseffektivität war kein signifikanter Unterschied feststellbar, jedoch ist der Aufwand für die Analyse der Testergebnisse bei Randoop höher. Manuell erstellte Testfälle sind viel einfacher verständlich und wartbar. Des Weiteren ist Randoop effektiver im Finden von Überprüfungs- und Algorithmusfehlertypen. Dennoch kann Randoop, im Gegensatz zum manuellen Testen, die Dokumentation einer Klasse nicht verstehen und somit auch nicht dagegen testen. Es kann nur Klassenvariablen und Klassenmethoden direkt testen, die als public deklariert sind, d.h. non-public Variablen und Methoden, die nicht über Delegation von anderen Methoden aus erreichbar sind, müssen manuell mittels Reflexion getestet werden oder das System muss zuerst einem Refactoring unterzogen werden um die Testbarkeit zu erhöhen. Bei den falsch-positiven Fehlern gab es keinen signifikanten Unterschied. Das beste Resultat wurde durch eine Kombination der beiden Teststrategien erzielt. Die Ergebnisse dieser Arbeit sollen Projektmanager, Softwareentwickler, Softwaretester, Qualitätsmanager und Wartungsingenieure dabei unterstützen, die passende Teststrategie für ihr Softwareprodukt zu wählen.<br />

Testing is extremely widespread in modern day software engineering practice. It is a structural part of software development processes such as the spiral model or RUP and applies throughout agile development, for instance, in SCRUM and XP. Larger software development projects have designated testers whose main job is to write test cases.<br />However, especially with sequential development processes, where testing is done only once after major development of the software has been completed, it is common for only the most vital tests to be written because of time constraints or testability problems. Test-Driven Development (TDD) is a promising approach where tests are created even before implementation has begun and the testability of the software is thus guaranteed. However, tests are still likely to be written only when the design demands it. This results in software systems that are not fully tested but deployed anyway.<br />With nowadays ever changing requirements it will not be long until unit tests are needed to ensure that enhancements to systems do not break existing functionality. Hence new and missing test cases that were previously dropped need to be written so that existing systems can be maintained properly. Different testing strategies - tests created by humans and tool-supported test case generation - are promising approaches to introduce unit tests to largely untested software in industrial environments.<br />Is it worth having developers invest their time into old or even unfamiliar code? Does it pay off to use tool-supported test case generation in this regard? To answer these questions we compare the two strategies - human-based test case creation and tool-supported test case generation - regarding their effectiveness, i.e., how many defects can be found automatically by a testing tool as opposed to understanding the functionality of the system under test and then writing them manually.<br />Other goals include identifying differences in the defect types found by each strategy and investigating if the combination of the two leads to any significant improvements. To investigate the defect detection capability of these different strategies and thereby unit tests that are written after a software product has been completed, a controlled experiment was conducted at the Vienna University of Technology. The Java collections library, with a total number of 35 seeded defects, was used as the system under test.<br />The source code itself was withheld because of the black-box nature of the experiment. Only Javadoc of the collections classes was supplied. Manual tests were sourced from an experiment where 48 students implemented unit tests within a short time interval of 60 minutes. Randoop is used to automatically generate unit tests for the same system under test. Randoop is a feedback-directed random test generator for Java. It automatically generates unit tests by incorporating feedback obtained from executing test inputs as they are created.<br />The results of this thesis show that each testing strategy brings distinct contributions to software quality. Higher overall method coverage was achieved in a shorter time interval via random test case generation by Randoop. Defect detection effectiveness showed no significant difference between random test case generation and human-based testing. However, a higher effort for analysis of the generated tests by Randoop was needed, as opposed to tests created by humans, which were far easier to understand and maintain. Moreover, Randoop was more effective in finding algorithm and checking type defects. Nevertheless, Randoop, in contrast to human-based testing, cannot comprehend and test against the contract described in the specification for a particular class. Furthermore it is only able to directly test members and methods that are declared public, i.e., non-public members and methods that are inaccessible through delegation have to be tested by humans using reflection or the system under test has to be refactored first. There was no significant difference ascertainable regarding the amount of false positives found by each strategy. The best result was achieved with a combination of the two strategies.<br />The findings of this thesis can help project managers, software developers, software testers, quality managers and maintenance engineers choose the appropriate testing strategy for their software product.<br />