آزمایش سیستم های زمان واقعی توزیع شده

For testing of sequential software it is usually sufficient to provide the same input (and program state) in order to reproduce the output. For real-time systems (RTS), on the other hand, we need also to control, or observe, the timing and order of the inputs. If the system additionally is multitasking, we also need to take timing and the concurrency of the executing tasks into account. In this paper we present a method for deterministic testing of multitasking RTS, which allows explorative investigations of real-time system behavior. The method includes an analysis technique that given a set of tasks and a schedule derives all execution orderings that can occur during run-time. These orderings correspond to the possible inter-leavings of the executing tasks. The method also includes a testing strategy that using the derived execution orderings can achieve deterministic, and even reproducible, testing of RTS. Since, each execution ordering can be regarded as a sequential program, it becomes possible to use techniques for testing of sequential software in testing multitasking real-time system software. We also show how this analysis and testing strategy can be extended to encompass distributed computations, communication latencies and the effects of global clock synchronization. The number of execution orderings is an objective measure of the testability of a system since it indicates how many behaviors the system can exhibit during runtime. In the pursuit of finding errors we must thus cover all these execution orderings. The fewer the orderings the better the testability.

Conformance testing, which aims to ensure that the implementation conforms to its specification, is realized by generating test sequences and applying them to the implementation which is referred to as an implementation under test (IUT). Henceforth, the term ‘testing’ means ‘conformance testing’. A lot of work has been done for testing real-time systems [1], [2], [3], [4], [5], [6], [7] and [8] and distributed systems [9], [10], [11], [12], [13], [14] and [15]. Similar to Ref. [16], this article combines real-time and distributed aspects into the same study. As in Refs. [14], [15], [16] and [17], we consider that the distributed IUT consists of several sites, where each site can communicate with its environment through a corresponding port which consists of an input queue and an output queue. For each site of the IUT, the considered test system (TS) contains a tester which is local to this site. Each local tester communicates with the IUT through the port of its corresponding site, and with the other testers through a reliable communication medium which is independent of the IUT (see Fig. 1).An interesting test approach for distributed non-real-time systems contains a first step, where the distributed aspect is ignored and, thus, test sequences are generated by using well-known methods which are applicable for non-distributed systems [18] and [19]. Let us call global test sequence (GTS) each test sequence obtained in this first step. Then, in a second step, each GTS is distributed into the different sites of the (distributed) IUT, in order to obtain local test sequences that are executed by local testers [9], [14], [15] and [17]. The idea is that, in the phase of test execution, checking the conformance to a given GTS consists of checking whether the corresponding local test sequences are executed correctly. The same approach can be applied to distributed real-time systems. In a first step, GTSs are generated ignoring the distributed aspect and, thus, considering only the real-time aspect. And in a second step, GTSs are distributed. In this article, we do not consider the first step, i.e. GTSs are given, and our main objective is to propose: (1) a model for describing the specification of the IUT, (2) an architecture of test execution, i.e. a structure of the TS, and (3) a method of GTS distribution, i.e. an approach for coordinating the local testers which constitute the TS and a procedure for deriving automatically the test sequence of each tester from a GTS. This article improves [16] in the sense that, contrary to Ref. [16], clocks are not assumed perfectly synchronized. This point is very important, because assuming a perfect synchronization is unrealistic. The rest of the paper is organized as follows. Section 2 describes the model of timed automata with n ports (np-TA). This is the model used to describe the specification of the (distributed real-time) IUT. In this section we also precise the task of the TS. In Section 3 we propose a simple distributed architecture for test execution, i.e. for checking the conformance of the IUT to every GTS. In this section we also discuss the synchronization of the clocks of the TS. Section 4 explains in detail the principle of coordination of the local testers during a test execution. In Section 5 we propose a procedure for distributing a GTS into the different sites of the IUT. In Section 6 we conclude and discuss some future research issues.

In this article, we propose a method for testing distributed real-time systems. We assume that GTSs have been generated from the specification of the IUT, ignoring the distributed aspect of the IUT, and we propose an architecture and a coordination method for executing a test, i.e. for checking the conformance of the IUT to every given GTS. In the proposed test architecture, the TS consists of several testers which send/receive inputs/outputs to/from the IUT and exchange coordination messages with one another. An important advantage of the proposed coordination method between testers, is that it takes into account the inaccuracy of clock synchronization. This advantage is very relevant if, for example, the testers communicate through the INTERNET. In the near future, we intend to study the following problems of test execution: 1. In a GTS, the exact instants of inputs/outputs are not specified. During each test execution, the TS has to select an exact instant of each input a in the period of time when a is enabled (i.e. when its EC is satisfied). Therefore, the same given GTS must be tested several times, for different instants of inputs. Since the number of instants at which any input may be applied is theoretically infinite, we will propose a method for selecting a finite number of relevant instants. 2. During the execution of a given GTS Seq, the reception of an unexpected output may mean, either (1) an incorrect execution of Seq or (2) the correct execution of another GTS. This case may occur when the np-TA A which specifies the IUT contains at least a location l which satisfies one of the following conditions: ◦ l has at least two outgoing output transitions which can be enabled at the same time. ◦ l has an outgoing input transition and an outgoing output transition, such that the output transition can be enabled before the input transition. In this case, several GTSs may have to be considered at the same time during a test execution. 3. A GTS Seq may be unexecutable. When this case occurs, the aim is to make it executable by strengthening its timing constraints. This problem has been studied in Ref. [8] for non-distributed real-time systems. The problem is more complex for distributed real-time systems because we have to consider transfer times of messages exchanged between testers. We also intend to extend the np-TA model by using transitions corresponding to the independent occurrences of several events. With such an extension, we will obtain a more appropriate model for representing, for example, multicast transmissions. An example of concrete application is a video-on-demand service where a server multicasts a video stream to several clients.