Incorporating fuzz testing to unit testing regime
Software defects are a common problem, despite of decades of research on how to seek and destroy bugs. Software defects are not a mere nuisance, since they come with a very real cost to the industry and the users of software, leading to loss of millions of dollars, countless hours of work and even h...
| Main Author: | |
|---|---|
| Format: | Dissertation |
| Language: | English |
| Published: |
University of Oulu
2014
|
| Subjects: | |
| Online Access: | http://urn.fi/URN:NBN:fi:oulu-201311211914 http://nbn-resolving.de/urn:nbn:fi:oulu-201311211914 |
| Summary: | Software defects are a common problem, despite of decades of research on how to seek and destroy bugs. Software defects are not a mere nuisance, since they come with a very real cost to the industry and the users of software, leading to loss of millions of dollars, countless hours of work and even human lives. Thus there is a very real need to invent new ways to hunt down software defects.
This thesis aims to answer questions concerning integration of modern software development pipeline and fuzzing, an effective fault-based testing technique with strong background in security and robustness testing. More specifically, this thesis seeks to find out how to integrate fuzz testing with continuous integration frameworks to lessen the redundancy in testing: fuzzing usually has its own, separate testing pipeline. Additionally this thesis looks into the possibility of automating generation of fuzzed unit tests using a tool that would use existing unit tests as the raw material for creating the tests to determine, if such approach could be feasible.
This study consists of theoretical and empirical parts. The literature part explores software testing research for results relevant to this thesis, empirical part describes a prototype of unit test fuzzer developed for unit tests written in Python, and observations of relevant issues made during the development process while also describing experiences of how well test cases generated by the tool or manually could be introduced to the existing continuous integration workflow. Research method applied is design science.
The findings show that creating the tool described is not as easy as it would first seem, listing issues large enough to motivate discontinuing the prototyping after first initial version. On the other hand, integrating fuzzing to a continuous integration based workflow seems to be a feasible idea, and automated test case generation is not the only way to create fault-based unit tests. |
|---|