Use state-transition testing to solve the following testing problem Consider a s
ID: 3860399 • Letter: U
Question
Use state-transition testing to solve the following testing problem Consider a simplified version of an automatic teller machine (ATM) used by a bank The description below captures the requirements corresponding to the stages for customer usage of the ATM. The ATM starts in an idle state waiting for a card to be invited. When a card is inserted and it is a valid card, the ATM transitions to the pin entry state. If the card is not valid, the ATM ejects the card and remains in the idle state. - At the pin entry state, if a valid pin is entered, the ATM transitions to the transaction selection state. If the pin is not valid or if the transaction is cancelled, the ATM returns to the idle state with an appropriate message to the user. - At the transaction selection state, the user has four transaction options: (a) check balance, (b) make a deposit (c) make a withdrawal and (d) cancel transaction. - If the user selects cancer transaction the ATM returns to the idle state: if check balance option is selected, the ATM transitions to the balance state: if make a deposit is selected it moves to deposit state, and if make a withdrawal is selected it moves to withdrawal state. - When a transaction is completed at the balance, deposit, or withdrawal stales, the ATM transitions to the close session state. - At the close session state, the user is presented with a "yes" or "no" option to dose the session. If the user selects "yes" to close the session, the ATM returns to the idle state. If "no" is selected the ATM returns to transaction selection state to allow the user to select another transaction. Important: This is a simplified version of an it automated teller machine. A real ATM is more complex than this. You should not use your experience or knowledge of a working ATM to add requirements (e.g. states, events, actions or transitions) to the problem You will be graded solely on using the requirements as given to solve the problem (a) Create a state-transition diagram to capture these requirements. Clearly label the states, events and actions. (b) Use the state-transition diagram to create the following test cases. Your test cases should begin from the start state and end at a terminal state. There is only one terminal state in the slate diagram. (i) The minimum number of test cases to achieve state coverage with the condition that a maximum of only three states can be visited more than once in a test case. (ii) The minimum number of test cases to achieve transition coverage with the following two constraints: (a) no more than two loops should be traversed in each test case from the start state to the terminal state, and (b) the terminal state should not appear more than twice in a test case even when the start state is also the terminal state. For example, if A is both the start and terminal states of the state-transition diagram, a test case such as A rightarrow B rightarrow D rightarrow C rightarrow A is acceptable since A appears a maximum of two times in the test case. (c) Construct a state-transition table showing the current state, event action and next state.Explanation / Answer
In recent years object-oriented paradigm is gaining acceptance for developing large and complex software. OO paradigm has moved into mainstream software development industry. This is due to a variety of claims about how it may improve the development of software, including such factors greater reusability, flexibility and increased extensibility. These outstanding advantages so far in OO software engineering are focused on problem analysis, class design, and implementation techniques, but do not include testing methodologies. Basically, object-oriented analysis (OOA) and object-oriented design (OOD) methodologies examine the problem in the real world and facilitate in decomposing the problem in terms of classes, and some relationships between classes. Therefore, the result of any OOA and OOD technique is a specification of the system under construction and should be complete and consistent with the problem requirements. However, almost all large OO software specifications still contains incompleteness, inconsistentency, and ambiguity [2]. This is because the formulation of OO software specifications require extensive human guidance and writing [12]. We know that many serious conceptual errors are introduced in this first stage of software development --- errors introduced during the specification stage have been shown to be more difficult and more expensive to correct than errors introduced later in the software lifecycle[17,18,19]. In view of this, it is important to provide methods and techniques to test specification-related errors in the early stage of software development[1]. Especially, the inconsistency and incompleteness of specification which lead to the design errors and implementation errors must be detected as early as possible [8,9,10,11]. Although different approaches have been proposed to test OOPs over the past decade, most of them focused on the static and manual analysis of program behavior in a single class instead of OO specification[8,11,12]. The problem of inconsistency and incompleteness of OO software specifications has been rarely discussed. So far two related approaches to verifying the consistency and completeness of procedure-oriented programs include methods based on formal proof systems and static analysis technique such as model checking. These two approaches have drawbacks and are not suitable for OO software specification. Formal Proof Systems. Formal proof systems can be powerful tools in the verification of critical properties of algorithm [20]. Attempts have been made to extend the use of formal proofs and apply them to requirements specifications, for example, the ProCoS (Provably Correct Systems) Project [21,22]. Unfortunately, the languages used in the theorem proving approach, such as process algebras and higher order logics, are not understandable by the non-software professionals involved in most requirements specification efforts and thus are not (in our opinion) suitable as high-level specification languages. Also, formal proofs are notoriously difficult to derive, and these approaches may not be practical for complex systems. Model Checking. Model checking is conceptually simple and is applicable in a wide variety of languages and application areas [23]. Early work in model checking also relied on a global reachability graph. Consequently, the approach suffered from state-space explosion problems. Newer approaches relying on a symbolic representation of the state space can significantly improve the performance of the model checking approach. Symbolic model checking has been applied to large models [24], but only for systems with simple, repetitive elements --- such as those commonly found in hardware applications.
Testing Framework The approach to object-oriented testing(OOT) proposed here includes four components:(1) describe the specification with a state-based requirement specification language, (2) describe the dynamic behavior of the OO specification with an extended state transition diagram, (3) generate test data in the form of regular expression (4) design a testing algorithm based on finite automata to test the OO specification. The requirement state machine language (RSML) is a state-based requirement specification language which provides a convenient way to describe the operation sequences of an object-oriented specification [4]. The RSML specification provides a means for the tester to retrieve implementation information without going to details [13]. It also provides the definition of whole class hierarchy and gives a precise description of the desired operation behavior. Although we prefer to use RSML to depict the object-oriented specification, it would be possible to describe object-oriented specification using other state-based specification notations such as Object Diagram, Event Trace Diagram, and Use-case diagram which are suggested by Booch[28]. It is worthy to note that not having to introduce and force users to learn a new notation is an important feature of this testing framework.
RSML Specification RSML is a state-based requirements specification language suitable to describe complex software specifications. The RSML was developed by the Irvine Safety Research Group using a real aircraft collision-avoidance system called TCAS II (Traffic alert and Collision Avoidance System II) as a testbed [3]. It extends conventional state diagrams with state hierarchies and broadcast communications. Focusing on a subset of RSML, we model a system by a state hierarchy, events, and inputs; in particular, the input and output interfaces in RSML are ignored. In the following, we give a brief overview of RSML.
State Transition Diagram for RSML Specification The RSML specification itself is a state transition diagram (STD). These definitions in section 3.1 provide the abstraction capability needed for the derivation of state transition diagrams in a multi-layer style. This multi-layer representation provides the tester a direct mapping between design specification and usage, and allows the user to view the design in an understandable way. It is also feasible to use this approach to handle the state explosion problem of complex systems. The advantages of deriving the state transition diagram in the way include: 1 Since a class or an object in RSML specification can be represented in a STD, it is natural to represent the whole system as a STD. 2 The behavior of a complex system can be represented in one diagram that allows the user to navigate through several levels. Each level can be fitted into a single
Testing Methodology In this section, we present the object-oriented testing methodology modeled by finite automata. Instead of manually verifying the OO software specification, an innovative method is presented to test the incompleteness and inconsistency of OO software specification.
Fortunately, there have been three primitive regular expression properties to help construct the FA [29]. They are shown as follows: 1. Complement: Given an automata denoted L(M)= ) ( , , , , M = Q q0 F , the complement is L * . To accept L * , complement the final states of M. That is M = ) ( , , , , M = Q q0 Q F . Then M accepts a word w if and only if ( , ) q0 w is in Q-F, that is, w is in L * . 2. Union: Given two automatas ( ) ( , , , , ) 1 1 1 1 1 F1 L M = Q q ,and ( ) ( , , , , ) 2 2 2 2 2 F2 L M = Q q , the union of M1 and M2 denoted M1 M2 is easily done by union the each element in 5-tuple. Then L(M1) L(M2) = M12 (Q1+Q2, 1 2 1 2 1 2 1 2 + , + , q + q , F + F ) 3. Intersection: The construction of intersection involves taking the Cartesian product of states, and we sketch the construction as follows, Let ( ) ( , , , , ) 1 1 1 1 1 F1 L M = Q q and ( ) ( , , , , ) 2 2 2 2 2 F2 L M = Q q be two deterministic finite automata. Let M=(Q1 ×Q2 , 1 2 1 2 , ,[q , q ], F × F ) where for all
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.