Study of Languages for Systems and Test Description
In this line of research the project will deal with concepts, meta-models and languages for the design and development of systems and testing environments. As prerequisite, a common understanding of terms and concepts is needed and will be reached. The project will develop a common base of test concepts applicable to both protocol and software testing systems. This common base should be applicable for component, integration and interoperability testing of aspects such as functional, performance, load, scalability, security and robustness. The concepts that we will consider are based on recent developments as :
Even though all these technologies provide a comprehensive support for functional testing, they only partially support other possibilities such as :
Thus, the bulk of this line of work consists in using these enhanced testing concepts together with adequate language support for an efficient handling in testing processes. In particular, the project will consider the generation of test cases via refinements from systems specifications, the generation of regression tests on the basis of model revisions, and the automated deployment of test systems onto distributed target test platforms. The use of meta-modelling and model transformation approaches will be investigated to analyse the seamless transition between test specifications on differents levels of abstractions such as test objectives, test cases for platform independent system models, test cases for platform-specific system models, and executable tests.
In this line of research the project will focus on the definition of testing methodologies adapted to communicating systems as well as on the development of software tools for component, integration and interoperability testing. Specifically, the project will consider the following topics :Active and passive testing techniques.
The main purpose of conformance testing is to determine whether an implementation behaves as indicated in the corresponding specifications. Most testing proposals are based on a method called active testing. Intuitively, the tester sends an input to the implementation and waits for an output. If the output lies within the expected outcome, according to the specification, the process continues; otherwise, a fault is detected in the implementation. This kind of testing is called active because the tester has total control over the inputs provided to the implementation under test. The other method, called passive testing, does not involve the presence of an active tester. In passive testing the implementation under test is allowed to run independently without any interaction with a tester. However, the trace that the implementation is executing is observed so that it can be analysed. That is the reason why this kind of testing is alternatively called monitoring. A recent and novel approach to passive testing considers invariants, representing critical properties that the implementation under test must have, to be checked on each execution trace.
Let us remark that the definition of fault models complements the use of these techniques, since they facilitate the definition of coverage criteria as well as error detection, localisation and removal.Definition of new testing architectures.
Dependable systems may be included in real physical environments. Therefore, aspects of these environments such as different architectures, resources and points of control should be considered when performing testing in this kind of systems. We should therefore design specific testing architectures that overcome the difficulties due to this lack of control and accessibility by combining monitoring testing techniques and active testing techniques. Specifically, the classical models of testing architecture should be enhanced in oder to allow the tester to choose Points of Control and Observation (PCO) and/or Points of Observation (PO) at appropriate locations of the sytem, such as :
Communicating systems are usually made of components that may be of different sizes and levels of granularity. They may range from small procedures to sets of components or the system as a whole. We should test each component separately but also as part of the whole system. We should, thus, undertake what is generally known as component testing. Since components, once tested, should be integrated in the system, we also have to perform integration testing. These components also need to interoperate with components of other systems with different configurations, making it necessary to perform interoperability testing.Use and development of software tools and platforms.
The partner GET/INT has developed, within a french national research project, a validation platform called PLATONIS. This platform covers all phases of testing : specification of the system, test selection, test generation and test execution. The network TAROT will use this platform, and others developed by other partners, in order to evaluate the new methodologies on the case studies proposed by the network. This evaluation will also determine the scalability of the proposed methodologies and will be integrated into the training programs of the researchers.
The project will propose new areas of application for wireless networks, such as cellular telephony and WIFI technologies. The project will apply the defined methodology in these two areas.
TAROT will also provide methods and tools to be applied on the new normalisation efforts in the area of protocol standardisation for routing and security that will be significant for the European Community.
Embedded systems are another industrial application domain that will be considered by TAROT. Testing embedded software poses particular technical challenges. These include the interaction with the rest of the system in which the software is embedded, i.e. interaction with non-software components (e.g. electrical, mechanical and optical components), the accessibility of the software under test, i.e. the identification of the points of control and observation and how to access them, the necessity to develop a dedicated test environment, and real-time issues which often play an important role in embedded systems. Whereas real-rime testing theory issues deserve special attention and require specialist real-time knowledge (which are covered in other EU projects), the emphasis of TAROT will be on a test methodology, supported with processes and tools, for complex embedded systems, supporting heterogeneity and non-software interaction, generic and flexible test environments, and model-based test generation and execution. As such, this application area will provide important feedback to the topics of new testing architectures and platforms discussed in the previous section.
TAROT will put particular emphasis on embedded systems in the transport domain (aeronautics and terrestrial), and in complex, software controlled production machines. In fact, the requirements on improvement of the security of persons in transport systems leads to the introduction of special security devices designed to help the driver. The devices consist of embedded software components, and they become more and more sophisticated and complicated. In general, this software is embedded in a larger system and its information processing is not visible to the user. This software must be reliable, safe, secure and efficient. In addition, it must be taken into account that this software is frequently reading, processing and controlling physical quantities, and it requires their behavior to be tested to guarantee the software quality needed for its security. Empirical methods have been used to test these systems with acceptable results but the cost is high and they do not offer a complete security. TAROT will provide automated methods for the test of embedded systems assuring security requirements and reducing both costs and time to market.
|© 2017 INT||Accueil||||Plan du site||||Contact||||Plan d'accès||||Rechercher||||Mentions légales|