Implementation Relations for Distributed Testing
When testing a system that interacts with its environment at several physically distributed interfaces (ports) it is normal to place a local tester at each port. If the local testers do not synchronise their actions then the local tester at port p can only observe the sequence of inputs and outputs...
| Autores: | , , |
|---|---|
| Tipo de recurso: | capítulo de libro |
| Fecha de publicación: | 2023 |
| País: | España |
| Institución: | Universidad Complutense de Madrid (UCM) |
| Repositorio: | Docta Complutense |
| Idioma: | inglés |
| OAI Identifier: | oai:docta.ucm.es:20.500.14352/119491 |
| Acceso en línea: | https://hdl.handle.net/20.500.14352/119491 |
| Access Level: | acceso abierto |
| Palabra clave: | Informática (Informática) 1203.17 Informática |
| Sumario: | When testing a system that interacts with its environment at several physically distributed interfaces (ports) it is normal to place a local tester at each port. If the local testers do not synchronise their actions then the local tester at port p can only observe the sequence of inputs and outputs that occur at p. If, in addition, there is no global clock then it may be impossible to reconstruct the global trace that occurred in testing and testing is then using the distributed test architecture. As a result, the System Under Test (SUT) might be able to produce a global trace that is not allowed by the specification, and so would normally represent a failure, but where the local testers cannot observe this difference. The use of the distributed test architecture thus affects the ability of testing to distinguish between a specification and an SUT and so leads to the need for a different notion of correctness (implementation relation). This paper explores alternative implementation relations for distributed testing and how they relate. |
|---|