Integration Testing and Metamorphic Testing

Yves Le Traon,Tao Xie
DOI: https://doi.org/10.1002/stvr.1817
2022-01-01
Abstract:This issue contains two papers. The first paper focuses on integration testing and the second one focuses on metamorphic testing. The first paper, ‘Towards using coupling measures to guide black-box integration testing in component-based systems’ by Dominik Hellhake, Justus Bogner, Tobias Schmid and Stefan Wagner, concerns integration testing in component-based systems. The authors investigate the correlation between component and interface coupling measures found in literature and the number of observed failures at two architectural levels: the component level and the software interface level. The finding serves as a first step towards an approach for systematic selection of test cases during integration testing of a distributed component-based software system with black-box components. For example, the number of coupled elements may be an indicator for failure-proneness and can be used to guide test case prioritisation during system integration testing; data-flow-based coupling measurements may not capture the nature of an automotive software system and thus are inapplicable; having a grey box model may improve system integration testing. Overall, prioritising testing of highly coupled components/interfaces can be a valid approach for systematic integration testing. (Recommended by Lionel Briand). The second paper, ‘High-coverage metamorphic testing of concurrency support in C compilers’ by Matt Windsor, Alastair F. Donaldson and John Wickerson, presents C4, an approach and automated toolbox for randomised testing of C compilers, by checking whether C compilers compile concurrency in accordance with the expected C11 semantics. C4 generates concurrent test cases where threads communicate using fine-grained atomic operations. In particular, C4 generates test cases with precise oracles, conduct metamorphic fuzzing to each test case, and execute each fuzzed test case on a range of real machines. Test cases generated by C4 can achieve coverage of the LLVM C compiler's parts reached by neither the LLVM test suite nor an existing sequential C fuzzer. In addition, C4 can help gain confidence on the correctness of a compiler's concurrency implementation. The experimental results show that C4 complements the coverage of other methods, exercises some interesting code relating to atomic-action concurrency, and detects fence insertion failures representative of real compiler bugs. (Recommended by Gordon Fraser).
What problem does this paper attempt to address?