Random testing of interrupt-driven software

Abstract

Interrupt-driven embedded software is hard to thoroughly test since it usually contains a very large number of executable paths. Developers can test more of these paths using random interrupt testing-firing random interrupt handlers at random times. Unfortunately, naïve application of random testing to interrupt-driven software does not work: some randomly generated interrupt schedules violate system semantics, causing spurious failures. The contribution of this paper is the design, implementation, and experimental evaluation of RID, a restricted interrupt discipline that hardens embedded software with respect to unexpected interrupts, making it possible to perform random interrupt testing and also protecting it from spurious interrupts after deployment. We evaluate RID by implementing it in TinyOS and then using random interrupt testing to find bugs and also to drive applications toward their worst-case stack depths.

A search-based framework for automatic testing of MATLAB/Simulink models

“…On the other hand, random testing has been reported as an ineffective approach for many testing problems, e.g., testing interrupt-driven embedded software (Regehr, 2005), preamble generation for state transition based testing (Colin and Legeard, 2004), etc.…”

Inter-context control-flow and data-flow test adequacy criteria for nesC applications

“…We developed our testing framework based on the testing frameworks of interrupt-driven software [26] and GUI applications [32]. We used Java and Python to implement our framework.…”

“…On the other hand, if interrupts occur too often, interrupt handlings would occupy the corresponding mote. The interrupt schedule was so chosen that the mote under test spent fifty percent of its cycles on handling interrupts, as suggested by Regehr [26].…”

Distributing test cases more evenly in adaptive random testing

“…In this paper, D is assumed to be of numeric type (that is, input parameters accept either integers or real numbers). For applications of RT and ART on non-numeric programs, readers may consult the studies of Miller et al (1990Miller et al ( , 1995; Slutz (1998);Forrester and Miller (2000); Yoshikawa et al (2003); Regehr (2005) and Merkel (2005); Kuo (2006); Ciupa et al (2006Ciupa et al ( , 2008, respectively.…”

“…What is more, its "randomness" may help reveal failures which cannot be detected by deterministic approaches (such as domain testing (White and Cohen, 1980), data flow testing (Laski and Korel, 1983), and branch testing (Myers, 2004)). Because of these advantages, RT has been successfully applied to detect software failures in industry, such as the testing of UNIX utilities (Miller et al, 1990(Miller et al, , 1995, SQL database systems (Slutz, 1998), Windows NT applications (Forrester and Miller, 2000), Java Just-In-Time compilers (Yoshikawa et al, 2003), and embedded software systems (Regehr, 2005). However, some researchers (Myers, 2004) argued that RT may be the "least effective" testing method because it uses little or no information about the program under test.…”