Guaranteeing full fault coverage for UIO-based testing methods

Abstract

Abstract. This paper presents an analysis of the fault coverage provided by the UIO-based methods for testing communications protocols. Formal analysis of the fault coverage for the non-optimized method and for some of its optimized versions are presented. A test is said to provide full coverage if no erroneous implementation can pass the test. In the case of optimizations based on the Rural Chinese Postman Tour [1] it is shown that unless certain conditions are met the method does not guarantee full fault coverage, even when, as suggested in [3], the uniqueness of UIO sequences (or Partial UIO sequences) are verified in the implementation. The result of the analysis suggests how the existing methods for generating test sequences should be changed in order to guarantee full fault coverage.

Testing as Collecting of Evidence: An Integrated Approach to Test Generation for Finite State Machines

“…Anido and Cavalli [20] demonstrated that a TT produced by combining tests of individual transitions might fail to detect that a given M 0 is faulty even if pre-tests have confirmed that the sequences employed for state recognition have the expected power. They also suggested that, to avoid the situation, TT should, as much as possible, avoid critical converging transitions.…”

“…For an M, a CT constructed by a method precisely implementing a specific checking strategy is a minimum-cost CT among the CTs implementing the strategy, but not necessarily among all CTs for the given F M . As Anido and Cavalli [20] wonder, one occasionally encounters a CT for which none of the known checking strategies seems to explain how it can be so powerful in spite of being so cheap.…”

Automatic Test Case Generation from the Industrial Point of View: Conformance Testing in Iskratel

“…That can be done automatically, by introducing in each state the missing input/NULL loops in the first case, or a reset transition with userdefined input and output symbols in the second case. Based on the observations in [3,15], we have elected to implement four existing test-sequence generation methods, for different purposes. For FSMs that are strongly connected, deterministic, with proper UIOs and with the correct number of states in the implementation, the methods proposed in [2,11] have been implemented for transition testing.…”

“…Due to different specification problem domains the rules are divided into five categories: names of the complete specification, blocks, processes, signals, channels and signal routes. 3 Structure rules define how the specification has to be structured into blocks and processes and how communication paths between them have to be specified. They also recommend how the specified functionality should be structured into components in means of test scenario generation for testing of single components.…”