Abstract Software developers study and reuse existing source code to understand how to properly use application programming interfaces (APIs). However, manually finding sufficient and adequate code examples for a given API is a difficult and a time‐consuming activity. Existing approaches to find or generate examples assume availability of a reasonable set of client code that uses the API. This assumption does not hold for newly released API libraries, non‐widely used APIs, nor private ones. In this work we reuse the important information that is naturally present in test code to circumvent the lack of usage examples for an API when other sources of client code are not available. We propose an approach for automatically identifying the most representative API uses within each unit test case. We then develop an approach to synthesize API usage examples by extracting relevant statements representing the usage of such APIs. We compare the output of a prototype implementation of our approach to both human‐written examples and to a state‐of‐the‐art approach. The obtained results are encouraging; the examples automatically generated with our approach are superior to the state‐of‐the‐art approach and highly similar to the manually constructed examples.

The co-existence of critical and non-critical applications on computing devices, such as mobile phones, is becoming commonplace. The sensitive segments of a critical application should be executed in isolation on Trusted Execution Environments (TEE) so that the associated code and data can be protected from malicious applications. TEE is supported by different technologies and platforms, such as ARM Trustzone, that allow logical separation of "secure" and "normal" worlds.

Binary analysis is a well-investigated area in software engineering and security. Given real-world program binaries, generating test inputs which cause the binaries to crash is crucial. Generation of crashing inputs has many applications including off-line analysis of software prior to deployment, or online analysis of software patches as they are inserted. In this work, we present a method for generating inputs which reach a given "potentially crashing" location. Such potentially crashing locations can be found by a separate static analysis (or by gleaning crash reports submitted by internal / external users) and serve as the input to our method. The test input generated by our method serves as a witness of the crash. Our method is particularly suited for binaries of programs which take in complex structured inputs. Experiments on real-life applications such as the Adobe Reader and the Windows Media Player demonstrate that our Hercules tool built on selective symbolic execution engine S2E can generate crashing inputs within few hours, where symbolic approaches (as embodied by S2E) or blackbox fuzzing approaches (as embodied by the commercial tool PeachFuzzer) failed.

Modern iterative and incremental software development relies on continuous testing. The knowledge of test-to-code traceability links facilitates test-driven development and improves software evolution. Previous research identified traceability links between test cases and classes under test. Though this information is helpful, a finer granularity technique can provide more useful information beyond the knowledge of the class under test. In this paper, we focus on Java classes that instantiate stateful objects and propose an automated technique for precise detection of the focal methods under test in unit test cases. Focal methods represent the core of a test scenario inside a unit test case. Their main purpose is to affect an object's state that is then checked by other inspector methods whose purpose is ancillary and needs to be identified as such. Distinguishing focal from other (non-focal) methods is hard to accomplish manually. We propose an approach to detect focal methods under test automatically. An experimental assessment with real-world software shows that our approach identifies focal methods under test in more than 85% of cases, providing a ground for precise automatic recovery of test-to-code traceability links.

Unit testing aims to ensure that methods correctly implement the specified and implied pre- and post-conditions, while integration testing ensures that modules correctly follow interaction protocols. While the generation of unit test cases has been explored extensively in the literature, there is still little work on the generation of integration test cases. In this paper we present a new technique to generate integration test cases that leverages existing unit test cases. Our key observation is that both, unit and integration testing, use method calls as the atoms to construct test cases from. Unit tests contain information on how to instantiate classes in meaningful ways, how to construct arguments for method calls, and what the resulting system state should be after calling methods with those arguments. We use this information to construct more complex test cases that focus on class interactions rather than on individual state transformations caused by single method calls. This paper presents the approach and shows that the generated test cases can find interesting faults, compared to test suites generated with state of the art approaches.

We present an approach to augment test suites with automatically generated integration test cases. Our approach utilizes existing test cases to direct generation towards producing complex object interactions and execution sequences that have not been observed before.

In this thesis, I investigate the problem of automatically generating test cases. In particular, I focus on the problem of automatic generation of integration test cases from unit test cases. I start from the observation that software is usually provided with many unit test cases, and that unit test cases carry a lot of information about the unit execution that can be used to generate integration test cases. This paper illustrates the approach that I am investigating and that consists in capturing information in unit test cases with static analysis techniques to automatically merge unit test cases to produce useful integration test cases. The preliminary results reported in this paper provide evidence of the effectiveness of the approach. My current research is developing the approach further and producing additional experimental evidence. I expect to complete the research by defining a set of design for testability rules to produce software that facilitates the automatic generation of integration test cases.