Methodological issues in model-based testing

Abstract

Automatic code generation from models boils down to perceiving models as possibly executable artifacts written in a very high-level programming language. This goes well beyond the use of models for analytical purposes only where, again, it is widely accepted that while it might be too expensive, modeling in itself usually reveals many errors. Currently, the embedded systems industry expresses a high degree of interest in these concepts. We have shown that one must be careful in ensuring redundancy when models are used for testing and code generation. Models for the further can involve both flavors of simplification that we identified in Sec. 10.2, namely the one where information is encapsulated, and the one where information is deliberately dropped. Models for the latter can obviously only involve encapsulation of details.3 We consider a thorough discussion of when the use of models for code generation is likely to pay off utterly important but beyond the scope of this paper. Briefly, we see a separation of concerns, multiple views, and restriction as key success factors of modeling languages [SPHP02]. The following captures the essence of the four scenarios and provides a prudent assessment. Our first scenario considered one model as the basis for code and tests. This is problematic w.r.t. redundancy issues and a restriction to abstractions that boil down to macros. Code generators and environment assumptions can be checked. The second scenario discussed the automatic or manual extraction of abstractions (beyond its technical feasibility). Because there is no redundancy either, the consequences are similar to those of the first scenario. The third scenario discussed the use of dedicated models for test case generation only. Because there is redundancy w.r.t. a manually implemented systems and because of the possibility of applying simplifications in the sense of actually losing information, this scenario appears promising. This is without any considerations of whether or not it is economic to use such models. We will come back to this question in the conclusion in Sec. 10.4. Finally, the fourth scenario considered the use of two independent models, one for test case generation, and one for development. The latter model may or may not be used for the automatic generation of code. This scenario seems to be optimal in that it combines the - not yet empirically verified-advantages of model-based testing and model-based development. Clearly, this approach is the most expensive one. © Springer-Verlag Berlin Heidelberg 2005.