Inputs and Outputs in CSP

Abstract

This paper addresses refinement and testing based on CSP models, when we distinguish input and output events. In a testing experiment, the tester (or the environment) controls the inputs, and the system under test controls the outputs. The standard models and refinement relations of CSP, however, do not differentiate inputs and outputs and are not, therefore, entirely suitable for testing. Here, we consider an alphabet of events partitioned into inputs and outputs, and present a novel refusal-testing model for CSP with a notion of input-output refusal-traces refinement. We compare that with the ioco relation often used in testing, and find that it is more widely applicable and stronger. This means that mistakes found using traditional ioco testing do indicate mistakes in the development. Finally, we provide a CSP testing theory that takes into account inputs and outputs. With our theory, it becomes feasible to develop techniques and tools for automatic generation of realistic and sound tests from CSP models. Our work reconciles the normally disparate areas of refinement and (formal) testing by identifying how ioco testing can be used to inform refinement-based results, and vice-versa. CCS Concepts: • Software and its engineering ✙ Formal methods; Software testing and debugging; • Computing methodologies ✙ Concurrent computing methodologies;

Testing using CSP Models: Time, Inputs, and Outputs

“…In addition, in [15], since there is no possibility of observing timeouts, we use prioritisation to check refusals: the SUT events are prioritised, and, if they do not happen, we then can issue a verdict event. In that context, we use prioritisation also to handle termination.…”

“…This is required because, if we can observe stability, recorded by 𝛿, then an output cannot be possible. As shown in [15], to study inclusion of sets of suspension traces, it is enough to consider sets ST that satisfy the healthiness condition ST below.…”