CHAPTER 5 GENERATING TEST SCENARIOS AND TEST CASES FROM AN EVENT-FLOW MODEL

Size: px
Start display at page:

Download "CHAPTER 5 GENERATING TEST SCENARIOS AND TEST CASES FROM AN EVENT-FLOW MODEL"

Transcription

1 CHAPTER 5 GENERATING TEST SCENARIOS AND TEST CASES FROM AN EVENT-FLOW MODEL 5.1 INTRODUCTION The survey presented in Chapter 1 has shown that Model based testing approach for automatic generation of test cases is currently drawing lot of attention from the software testing community. Existing Model-based testing approaches discussed in Chapter1 have extensively used UML models. As far as GUI testing is concerned, the existing approaches have considered GUI events only and have not dealt with other types of events like business events, state events or control events that happen in a system. Not much of an effort has been devoted to test functional requirements of a system more specifically for event-based systems. Existing event-based test case generation approaches have used events either from source code, Petri net model, or from GUI applications, so they require the applications or code to be made available prior to generating test cases. These applications or codes are run on existing GUI automation framework to reverse engineer an event-flow of an application. Not much of an effort has been devoted to use events captured directly from the requirements specification. The proposed approach has used events in place of UML models to generate a model of SUT. Events are used to generate event sequence-based test scenarios from an Event-flow model. A Fault Model for the SUT and test coverage criteria is defined for testing. An algorithm is also proposed to generate test scenarios from an Event-Flow model and help to detect faults described in the proposed Fault model. Regression testing is performed on modified software to provide confidence that the software behaves correctly and that modifications have not adversely affected the software s quality. Events are also used to specify and model changes in software requirements either in terms of addition and/or modification of events or event interdependencies. The proposed approach has also applied a safe and efficient regression 99

2 test selection technique on event-flow model, so as to select tests from test scenario that are deemed necessary to validate a modified software. 5.2 PROPOSED APPROACH TO EVENT-BASED TESTING The entire event-based approach for generating test scenarios, test cases and perform regression testing of a system consists of following steps: 1. Document events identified from requirements using proposed Event Templates. 2. Generate Event-Flow interdependencies from Event Templates. 3. Generate an Event-Flow Graph and precedence relations. 4. Generate Event sequence-based Test Scenarios and Test Cases from an Event flow Graph. 5. Specify and model changes in software requirements if any, either in terms of addition and/or modification of events or event transitions. 6. Apply a safe and efficient regression test selection technique on an event-flow model to select tests from test scenario that are deemed necessary to validate the modified software. The detailed process of documenting events from requirements using proposed Event Templates is described in Chapter 3 and the process of creating an Event-Flow model from Event Templates based on various possible event-flow interdependencies is described in Chapter 4. This chapter describes the remaining steps in detail. Each of these steps is also illustrated with a running example of a case study named Automatic Production Environment (APE) on a real time system taken from Real-Time Lab of Embry-Riddle Aeronautical University [197]. 100

3 5.3 EVENT-FLOW GRAPH AND PRECEDENCE RELATIONS In this sub section, a formal definition of an Event-Flow graph is presented based on Event interdependency. Precedence relations are also defined among events in an Event-Flow Graph Formal Definition of Event-Flow Graph An Event-Flow Graph represents events, their interaction in terms of causative events and trigger vector. It has one event designated as a start event and another designated as an exit event. A start event indicates initialization of a system i.e. once a system is turned on all other events can get executed. An exit event indicates the completion of functionality. In an Event-Flow graph, events are represented using circles, and dependencies between events are represented using arrows. The proposed Event-Flow Graph is different from the one used in Graphical User Interface (GUI) testing [223, 224]. An Event-Flow Graph used in GUI testing represents all possible interactions among the events in a GUI component whereas the proposed Event-Flow Graph depicts all possible event interdependencies among all events happening in a system. Formally, An Event-Flow Graph is defined as: An EFG is a 3-tuple <V, T, C> where V is a nonempty finite set of vertices representing all events in a system with two events designated as a Start (S) node and an Exit (E) node to indicate a system startup and exit events. T is a nonempty finite set of transitions. T V * V. An event e i causes an event e j iff e i is a causative event of e j or similarly an event e i triggers an event e j iff event e i triggers event e j. An edge (v x,v y ) T iff events v x and v y are interdependent either due to causes or triggers relationship. C is a finite set of vertices representing connector nodes {OR, XOR, FORK, JOIN, NOT} A connector node with more than one outgoing transition is classified as an Event-and split (fork), an Event-or split or an Event-xor split node. A connector node with more than one incoming transitions is classified as an Event-and join (join), an Event-or join or an Event- 101

4 xor join. An OR and XOR splits and joins are non-deterministic while an AND splits and joins are deterministic. In an Event-Flow Graph, an Event-and split operator is represented with a fork label, an Event-and join operator is represented with a join label, an ORsplit/join operator is represented with an or label and an XOR-split/join operator is represented with a xor label Event-Flow Precedence Relations Events in an event-flow graph satisfy identical set of partial order relations among them. There are various precedence relations among events that are possible in an event-flow. Precedence relations, denoted as p, over a set of events SE in an event-flow graph are defined as follows. 1. If an event E i SE precedes another event E j SE in an event flow graph, then, there exists a partial order relation between two events E i and E j, denoted as E i p E j. It signifies that event E i occurs before event E j in a system. 2. If an event E i SE precedes a fork, a xor-split or an or-split and another event E j SE is the first event that exists in any thread originated from a fork, an xor-split or an or-split, then E i p E j. 3. If an event E j SE follows next to a join, a xor-join or an or-join and another event E k SE is the last event in any thread joining a join, an xor-join or an or-join, then E k p E j. 4. If an event E i SE and another event E j SE are two consecutive concurrent events in a thread originated from a fork, an xor-split or an or-split, where E i exists before E j, then E i p E j. 5. If an event E i SE and another event E j SE in an event flow graph are involved in a loop (cyclic relation), then, there exists two partial order relations between events E i and E j, 102

5 denoted as E i p E j and E j p E i. It signifies that both E i and E j are involved in a cyclic loop. 5.4 GENERATING EVENT SEQUENCE-BASED TEST SCENARIOS AND TEST CASES FROM AN EVENT FLOW GRAPH This sub section first defines a fault model and presents different event paths that are possible in an Event-flow graph. Then some of the existing test coverage criteria are discussed followed by the test coverage criterion that is able to cover faults defined in the proposed fault model. Subsequently, an approach of generating event sequence-based test scenarios and test cases from an Event-Flow graph is presented Fault Model A Fault model describes certain categories of faults that a test strategy must detect [273]. A fault model defines a small set of possible fault types that can occur in a system. Given a fault model, the goal is to generate a test set T from an Event-Flow graph such that any fault in a system of a type described in a fault model is guaranteed to be revealed when tested against T. The proposed test scenario generation scheme is based on the following fault model that covers eight different types of faults. 1. Event-XOR-Split Fault: This fault occurs at an event-xor- split node. Consider the following case given below in Figure 5.1. E3 E1 xor E2 E4 Figure 5.1: Event-XOR-Split Fault Here, E1 is causative event of E2, E3, E4 and E2, E3, E4 are Triggered events of E1 with an xor spilt dependency. In an ideal state, E1 should trigger exactly one of the events in a Trigger Vector (i.e. E2, E3, E4). In case, when E1 has occurred but none of the events in a Trigger Vector gets triggered or more than one event gets triggered, an Event-XOR-Split Fault occurs. 103

6 2. Event-OR-Split Fault: This fault occurs at an event or-split node. Consider the following case given below in Figure 5.2. E3 E1 or E2 E4 Figure 5.2: Event-OR-Split Fault Here E1 is causative event of E2, E3, E4 and E2, E3, E4 are Triggered events of E1 with an or spilt dependency. In an ideal state, E1 triggers one, more or all events in a Trigger Vector (i.e. E2, E3, E4). In case, when E1 has occurred but none of the events in a Trigger Vector gets triggered, an Event-OR-Split Fault occurs. An Event-or split is more common in real time systems where lots of independent events can be triggered together. 3. Event-AND-Split Fault: This fault occurs at an event-and- split node. Consider the case as shown in Figure 5.3. E3 E1 fork E2 E4 Figure 5.3: Event-AND-Split Fault Here E1 is causative event of E2, E3, E4 and E2, E3, E4 are Triggered events of E1 with and spilt (fork) dependency. In an ideal state, E1 has to trigger all events in a Trigger Vector (i.e. E2, E3, E4). The fault occurs, if all events are not triggered. 4. Event-NOT Fault: This fault occurs at an event-not node. Consider the following case given below in Figure 5.4. E1 not E2 Figure 5.4: Event-NOT Fault 104

7 Here E1 is causative event of E2 and E2 is Triggered event of E1 with an event-not dependency. An Event-not connector node indicate non-occurrence of an event. The fault in this case can occur, if E1 occurs in the presence of Event-not operator. This is a special case of Non-event event as described by Ward and Mellor in [57]. 5. Event-AND-Join Fault: This fault occurs at an event-and join (merge) node. Consider the following case given below in Figure 5.5. E4 E2 join E1 E3 Figure 5.5: Event-AND-Join Fault Here, E1 is Triggered event of E2, E3, E4 and E2, E3, E4 are Causative events of E1 with join (and-join) dependency. Causative events E2, E3, E4 all of them, when happen trigger E1. Fault occurs if either (a) E1 is not triggered even though E2, E3, E4 have occurred or (b) E1 occurs even though all the causative events have not taken place. 6. Event-XOR-Join Fault: This fault occurs at an event-xor- join node. Consider the following case given below in Figure 5.6. E4 E2 xor E1 E3 Figure 5.6: Event-XOR-Join Fault Here, E1 is Triggered event of E2, E3, E4 and E2, E3, E4 are Causative events of E1 with an event-xor join dependency. In an ideal state, exactly one of the causative events E2, E3, E4 should happen to trigger E1. Fault occurs if more than one causative event occurs to trigger E1. 7. Event-OR-Join Fault: This fault occurs at an event-or- join node. Consider the following case given below in Figure

8 E2 E4 Or E1 E3 Figure 5.7: Event-OR-Join Fault Here, E1 is Trigger event of E2, E3, E4 and E2, E3, E4 are Causative events of E1 with an event-or join dependency. In an ideal state, one, more or all the causative events E2, E3, E4 should happen to trigger E1. Fault occurs, if none of the causative event occurs but E1 is triggered. 8. Synchronization Fault: This fault occurs when some event takes place before completion of all preceding events. The reason for this fault is that events are not executed in timely manner as per the precedence relations between them. Such synchronization fault can either be seen with sequential flow of one event following another without involving any event operator. It can also be seen in concurrent events in which all parallel events are not triggered together at the same time Event Paths There are various types of event paths that are possible in an event flow graph namely-: non-concurrent path, simple basic path, cyclic basic path and concurrent path. Each of the type is described in detail using Figure 5.8. a) Non-concurrent event path is a sequence of non-concurrent events (that is, events which are not executed in parallel) from the start event to an end event in an event-flow graph, where each event in the sequence has at most one occurrence except those events that exist within a loop. Each event in a loop may have at most two occurrences in a sequence. Also all events satisfy the precedence relations among them. Simple Basic path and Cyclic Basic path are two Non-concurrent event paths. 106

9 Figure 5.8: Event-Flow Graph of APE Case Study Simple Basic event path- A simple basic path is a sequence of events where each event in a path occurs exactly once and all events satisfy the precedence relation among them. In an Event-Flow Graph shown in Figure 5.8, s e is a simple basic path. Cyclic Basic event path- A cyclic basic path is a like a simple basic path but it involves a loop. All events in a cyclic basic path also satisfy the precedence relation among them. In an Event-Flow Graph shown in Figure 5.8, s e is a cyclic basic path. In cyclic basic path some of the events may occur more than once. In the above example, event 29 and event 30 occur more than once. Partial Basic event path- A partial basic path is a path that has sequence of events starting from a start event but in terminates on another event instead of an end event, each event in that path occurs exactly once and all events satisfy the 107

10 precedence relation among them. In an Event-Flow Graph shown in Figure 5.8, s 3 11 xor 12 is a partial basic path since it starts from s and ends on event with id 12. b) Concurrent event path has concurrent events. It is a special case of non-concurrent event path, which consists of both non-concurrent and concurrent events satisfying precedence relation among them. Concurrency among events occurs due to presence of a fork, or-split, xor-split connector nodes in an event path. For a complex and large system, it is common to have explosion of concurrent event paths because there would be large number of threads and every thread on an average would have large number of events. In Figure 5.9, Event-flow graph with concurrent events E2, E3, E4, E5 is shown. E2 E4 S fork E3 E5 join E Figure 5.9: Event-Flow Graph with concurrent events In an event-flow graph of Figure 5.9, there are six precedence relations among events: S p E2, S p E3, E2 p E4, E3 p E5, E4 p E, E5 p E. There are six concurrent event paths which satisfy all these relations specified above and consist of same set of events. P1 = s E2 E3 E4 E5 E P2 = s E2 E3 E5 E4 E P3 = s E2 E4 E3 E5 E P4 = s E3 E2 E4 E5 E P5 = s E3 E2 E5 E4 E P6 = s E3 E5 E2 E4 E Depending on runtime environmental condition, execution thread of a system would follow one of the concurrent event paths, but which concurrent event path would be followed, can 108

11 not be known at an analysis level, before execution of a system. For effective testing with limited resource and time, the proposed approach aims to test only relative sequence of concurrent and non concurrent events (i.e. set of precedence relations exist among these events). For this, one representative concurrent event path from a set of concurrent event paths is to be chosen that have same set of events and satisfy same set of precedence relations. The proposed test scenario generation approach selects a concurrent event path such that sequence of all concurrent events encapsulated in that path, corresponds to breadth first search traversal of them in an event-flow graph. This ensures that all precedence relations among events in an event-flow graph are satisfied. One can avoid generation of entire set of concurrent event paths by finding representative concurrent event path from an event-flow graph. This will make the task of test case generation process easier and at the same time avoid path explosion problem, hence, reduce testing efforts. E.g. path in Figure 5.8, start 1 5 xor 7 fork { }--join 17 8 xor fork xor E, is a concurrent path in which events 9, 12 and 15 to be executed concurrently Test coverage criteria Test coverage criteria [274] is a set of rules that guide to decide appropriate elements to be covered to make test scenarios and test cases adequate. In an Event-Flow Graph, there are many, possibly infinite, paths between a start event and an end event. Structural test strategies, also known as "path-oriented" strategies selects a subset of paths to be executed. The selection of paths is aimed at covering a particular set of events of an Event-Flow Graph along with the faults presented in the proposed Fault model. In this section, first existing Test case coverage criteria are discussed in the context of the proposed Event-Flow Graph, followed by the criterion used in generating Test Scenarios and Test Cases. All-Paths The All-Paths criterion requires executing all possible event flow paths through an Event-Flow Graph. This strategy is generally impossible to achieve, since an Event- Flow Graph with cycles / loops have an infinite number of event flow paths. 109

12 All-L-Paths This criterion provides a restriction of All-Paths, by limiting the number of iterations of cycles / loops in a path. The paths selected are those that do not iterate loops more than k times, for a given integer k. The most commonly used k value is 1, where each loop is to be executed at most one. It may be noted that presence of cycles / loops and decision among concurrent events at connector nodes (fork, xor, or) results in path explosion and hence, it is infeasible to consider all paths due to limited capability of resource and time. Event Coverage: Event coverage requires that each event in an Event-Flow Graph must be executed at least once. Such a requirement is necessary to check whether each event executes as expected. This kind of coverage criteria is able to detect synchronization faults but fails to cover other faults due to the fact that an event may occur independently from some other trigger point rather than through connector node. Hence execution of events through connector nodes remains uncovered. E.g. in Figure 5.8, event 15 is triggered independently by event 13, and also through a xor and a fork connector node via two other paths. Thus, only event coverage will not be able to detect faults due to a xor-split and a fork node (and-split). Due to these limitations, the proposed approach uses an Event Path Coverage criterion, as an improved test coverage criterion. Event Path Coverage Criterion- Event path coverage criterion is based on event paths identified in an Event-flow Graph. This coverage criterion is used for testing both loop (cycle) and concurrency among events in an Event-Flow Graph. In the proposed Event- Flow Graph, different events may flow from special connector nodes {OR, XOR, FORK, JOIN, NOT}. Each branch leads towards an event. Testing branches in an Event-flow require that every branch leading to an event be exercised at least once under some test. This ensures that Event-AND split, Event-OR split, Event-XOR split, Event-AND join, Event-OR join, Event-XOR join faults are covered. Both the concurrent and non-concurrent event paths are used to cover these faults. 110

13 5.4.4 Algorithm to generate Test Scenarios Test Scenario is a set of test cases or test scripts along with a sequence in which they are to be executed. Test scenarios are test cases that ensure that all event flows are tested from start to end. Every test scenarios in the proposed approach is an independent tests consisting of a sequence of events that follow each other, where each event is dependent on the occurrence of the previous event. Test scenarios are designed to represent both typical and unusual situations that may occur in an application. In our proposed approach, Test scenarios are generated using event path coverage criterion. To do this, all event paths are obtained from a start event node marked S to an end event node marked E in an event flow graph. An algorithm GenerateEventPaths is proposed to generate event paths. In this algorithm, combination of both depth first search (DFS) and breadth first search (BFS) techniques is used. An event flow graph is traversed by depth first search technique except a portion of a graph (which contains a fork node that initiates a set of concurrent events) with node type marked fork, following which sub tree is traversed following a breadth breath first search traversal of a graph. A breadth first search traversal helps to avoid path explosion problem as discussed before. It ensures that only one representative path is chosen from a set of concurrent event paths. These event paths are not necessarily linearly independent paths due to consideration of loop/ cycle more than once. Algorithm: Generate_Event_Paths Algorithm to generate event paths is divided in two parts. One part deals with generating event paths and other deals with completion of generated paths that are partially completed. Algorithm uses global data structure to record count of visits of every node, a stack for DFS, a Queue for BFS and two 2-D arrays. One array called Join Array records different types of join nodes traversed and other array called Path Array records duplet structure <path as string, status as flag>. Path is kept as a string so that a path can be easily manipulated and occurrence of any event node can be easily found. Current path traversed is represented as a Path Array. Status flag can have value C indicating a completed path i.e. a path having both a start and an end node; T indicating trailing path i.e. a path that 111

14 has an end node but a missing start node; L indicating leading path i.e. a path that has a start node but a missing end node; B indicating both start and end node missing. Completed paths are used in the second part of the algorithm to complete partially completed paths. Global data structure to record count of visits of every node has a record structure <event id, number of visits> Each record whether pushed on a stack, a queue, a 2-D array that keeps join nodes, has a triplet structure with <parent node, current node, valid flag>. Parent node keeps track of a parent of the visited node whereas a current node keeps track of node currently visited. A valid flag is used to indicate the status (active or deleted) of a record. When a record is first pushed on a stack, its valid flag is set 1 and when it is popped from a stack; its valid flag is set 0. This is to ensure that a record is not physically deleted from a stack as a stack history is needed in the second part of algorithm that completes partially completed paths. Construction of Event paths BEGIN Traverse the entire event flow graph using DFS. For each node visited during traversal, count its number of visits and update the record <event id, number of visits>. If <parent node, current node> is not already present on a stack, then Push <parent node, current node, valid flag> and set the valid flag to 1. EndIf Update the record <event id, number of visits> by incrementing visit count by 1. /* There is no specific order during DFS while traversing adjacent event nodes, however if an event node has an adjacency with an end event node as well as other event nodes, then all other event nodes are pushed on a stack first prior to end node. This is to ensure proper printing of event paths.*/ While not empty Stack { 112

15 Pop the record from a stack, set valid flag to 0 and add parent node and current node to the current path. If event marked by S && event marked by E are encountered then Add the path to a path array. Endif If (find_on_stack(<parent node, current node>) ) then Break the path and add the path to a path array. Endif If (a node has no other outgoing event node other than connector nodes (xor, or, join, or-join, xor- join) ) then Break the path and add the path to a path array. Endif If ( node is marked with E ) then Break the path and add the path to a path array. Endif Update Status Flags in a path array with C, L, T or B. } If (node is marked with join, xor-join, or-join) then Insert node in a Join Array. Endif If (node is marked with fork) then Start traversing the event flow graph in BFS using a Queue, starting from a fork node. /*During BFS traversal*/ Insert a triplet <parent node, current node, valid flag>in a Queue. Add fork node to the current path. While Queue is not empty { Delete the triplet <parent node, current node, valid flag> from queue by making the valid flag

16 END Add node to a current path. } For (i=0 to length of a Join Array) { If (join type matches fork type) then Delete the entry from a Join Array EndIf } Start DFS traversal from the join node. EndIf Completion of Partially completed paths This part of the algorithm aims to complete event paths that are not completed. Such paths in a path array are either marked with T, B, or L in their status flag. In this process stack and queue history is back traced to complete event paths. Paths that end in an event node are completed first. Paths that ends in nodes like XOR/ OR event operators are not completed. For (i=0 to length of a Path Array) { do { If the path has status flag T or B then Current node=first node Back track Stack history to search for a node that matches the current node If (found) { Fetch a parent node of the current node, add to the current path Current node=parent node } } While (Start node not found) 114

17 Set flag B to L and T; to C Fetch next event path. } For (i=0 to length of a Path Array) { do { If the path has status flag L then Current node=first node Back track Path Array to search for a node that matches the current node If (found and status flag is C ) { Complete the partial path by copying nodes from a complete path starting from current node till end node marked by E Change the status flag from L to C. } If (found and status flag is not C ) { Merge the partial path (other than those that end in a join node) with complete path on the basis of common node Change the status flag from L to C. } } While (Start node not found) Fetch next event path. } Partial paths that end with nodes that lead to join nodes are left as such. These paths are not completed in the algorithm as partially they are able to detect the faults due to an Event-OR split and an Event-XOR split faults of the fault model Augmenting the Event-Flow Graph with necessary test information In this sub section, a process is described to annotate an event-flow graph with necessary test information. Whenever an event occurs in a system its occurrence has to be detected at 115

18 an analysis stage. The condition or detection criteria become annotation for an Event flow graph. E.g. an event Guest request for a room is detected by arrival of a Booking request in a system. The construction of an Event-Flow Graph is based on the identification of triggers or causes relationships among events. When an event e i triggers an event e j, an edge between an event e i and an event e j is placed to indicate a transition. A transition is labeled with a string that describes test criteria to detect the occurrence of an event e j. At this level, details of each event such as actions encapsulated in an event and the inputs & output parameters of each action are not considered in order to preserve simplicity of an event-flow graph. This information is used at the level of testing individual events. Information of each event node of an event-flow graph and its related event detection string is stored separately in a data structure, called Event node Description Table (EnDT) Generate Test Cases Test case in the proposed approach consists of following components- Event-sequence based Test Scenario and Sequence of transitions to detect occurrence of events in a test scenario. Event-sequence based Test Scenarios constitute the expected system behavior. On the other hand, the sequence of transitions to detect occurrence of events in a test scenario makes up the source of test input. The values for the sequence of transitions to detect events may be identified with the help of system analyst. As a part of test case generation, necessary values of all components of a test case are obtained from the corresponding Event flow graph and its corresponding EnDT. 5.5 Application of Test Scenarios and Test Case Generation process This section describes application of the proposed approach to generate test scenarios and Test Cases from an Event-Flow Graph on a case study named Automatic Production Environment (APE) on a real time system taken from Real-Time Lab of Embry-Riddle Aeronautical University [197]. In this case study, after applying the proposed steps 1-4 of Event based OOA as described in Chapter 3, 34 events are extracted which are listed in the Table

19 Table 5.1: Some events from APE Case Study 1. User places package at the start place of the Belt 1 (External Event). 2. User places package at the scanner place of the Belt 1 (External Event). 3. User places package at the transition place of the Belt 2 (External Event). 4. User places package at the end place of the Belt 2 (External Event). 5. Sensor 1 sense the package at start place (State/Control Event) 6. Sensor 1 generate no-detect signal at start place 7. Sensor 1 generate detect signal at start place 8. Sensor 2 sense the package at scan place 9. Sensor 2 generate no-detect signal at scan place 10. Sensor 2 generate detect signal at scan place 11. Sensor 3 sense the package at transition place 12. Sensor 3 generate no-detect signal at transition place 13. Sensor 3 generate detect signal at transition place 14. Sensor 4 sense the package at end place 15. Sensor 4 generate no-detect signal at end place 16. Sensor 4 generate detect signal at end place 17. Motor 1 starts conveyor belt Motor 1 stops conveyor belt Motor 2 start conveyor belt 2 to move the package. 20. Motor 2 stops conveyor belt Motor 3 moves the scanner to down position and wait for 10 sec. 22. Motor 3 moves the scanner to home position and wait for 5 sec 23. Scanner down limit sensor detects down position. 24. Scanner up limit sensor detects home position. 25. Motor 4 moves pusher to extend position. 26. Motor 4 return pusher to home position. 27. Pusher forward limit sensor detects extended position. 28. Pusher back limit sensor detects home position. 29. System reports the status of system (sensors and motors) after every two seconds to web server. 30. User refreshes status earlier than 2 seconds. 31. Package is removed from sensor 4 at end place. 32. User toggle (manual / automatic) the control mode of ALCS. 33. ALCS toggle (manual / automatic) the control mode. 34. ALCS reports items track after every 5 sec Event Templates of Case Study APE All the events identified from Automatic Production Environment Case Study, are documented in the proposed Event Templates. Event Templates corresponding to two events listed in Table 5.1 are shown in Table 5.2 and 5.3. Table 5.2: Event Template for event Sensor 1 sense the package at start place 1 Event ID EA05 2. Event Name Sense package at the start place (verb phrase) 3. Description Sensor 1 sense the package at start place (State/Control Event) 4. Initiator Sensor 1 Count 5. Facilitator ALCS / Belt 1(Start place) Count 6. Affecter Package Count 7. Timestamp 8. Causative Events EA01 or Independent (Preconditions) 9. Inputs 10. Trigger Vector Sensor 1 generate no-detect signal at start place Sensor 1 generate detect signal at start place 11. Change-event Connection between Sensor 1 and Package 117

20 Table 5.3: Event Template for event Sensor 1 generate no-detect signal at start place 1 Event ID EA06 2. Event Name Generate no-detect signal (verb phrase) 3. Description Sensor 1 generate no-detect signal at start place (State/Control Event) 4. Initiator Sensor 1 Count 5. Facilitator ALCS / Belt 1(Start place) Count 6. Affecter Signal Count 7. Timestamp 8. Causative Events EA05 (Preconditions) 9. Inputs Signal type 10. Trigger Vector NULL 11. Change-event Connection between Sensor 1 and Signal Generating Test Scenario The Event-Flow interdependencies are generated from Event Templates based on information from causative events and trigger vector section of an Event Template. The resultant Event-Flow Model is transformed into an Event-Flow Graph as shown in Figure Figure 5.10: Event-Flow Graph of APE Case Study 118

21 After applying the first part of algorithm Generate_Event_Path on the event flow graph shown in Figure 5.10, the following event paths are obtained. 1) s E 2) s 4 14 xor E 3) xor ) s 3 11 xor3 12 5) xor ) s 2 8 xor fork join ) xor2 9 8) s 1 5 xor1 7 fork join ) xor1 6 E 10) s 33 E 11) s E In the generated paths, Path 4, 5, and Path 7 are left as partial basic paths as partially they are able to detect faults due to an Event-OR split and an Event-XOR split faults of a fault model. Path 1, 10, 11 are complete event paths in which 10 and 11 are simple basic event path whereas Path 1 is a cyclic basic event path. Path 2, 3, 4, 5, 7 and 9 are Partial basic event path. Path 6 and Path 8 are Concurrent event paths. After applying steps from second part of Generate_Event_Paths algorithm, partially completed paths are converted to complete paths. Path 3 is completed by merging with Path 2. Path 6 is completed by merging with Path 5 and then with Path 3. Path 8 is completed by merging with Path 6. Final event paths are shown below: 1. s E 2. s 4 14 xor E 3. s 4 xor xor E 4. s 3 11 xor s 3 11 xor

22 6. s 2 8 xor fork join xor E 7. s 2 8 xor s 1 5 xor1 7 fork join s 1 5 xor1 6 E 10. s 33 E 11. s E Generating Test Cases For all 34 events of an event-flow graph shown in Figure 5.10, an Event node Description Table (EnDT) is shown in Table 5.4 that gives information of each event node and its related event detection string. Node ID Table 5.4: Event node Description Table (EnDT) Event Name 1 User places package at the start place of the Belt 1 Event Detection String Mode=use; usercmd=place package; loc=start 2 User places package at the scanner place Mode=use; usercmd=place package; of the Belt 1 loc=scanner 3 User places package at the transition Mode=use; usercmd=place package; place of the Belt 2 loc=transition 4 User places package at the end place of Mode=use; usercmd=place package; the Belt 2 loc=end 5 Sensor 1 sense the package at start place Generate S1signal=true 6 Sensor 1 generate no-detect signal at S1signal=nodetect start place 7 Sensor 1 generate detect signal at start S1signal=detect place 8 Sensor 2 sense the package at scan place Generate S2signal=true 9 Sensor 2 generate no-detect signal at S2signal=nodetect scan place 10 Sensor 2 generate detect signal at scan S2signal=detect place 11 Sensor 3 sense the package at transition place Generate S3signal=true 120

23 Nod e ID Table 5.4: Event node Description Table (EnDT) (Cont.) Event Name Event Detection String 12 Sensor 3 generate no-detect signal at transition place S3signal=nodetect 13 Sensor 3 generate detect signal at transition S3signal=detect place 14 Sensor 4 sense the package at end place Generate S4signal=true 15 Sensor 4 generate no-detect signal at end place S4signal=nodetect 16 Sensor 4 generate detect signal at end place S4signal=detect 17 Motor 1 starts conveyor belt 1 Motar1cmd=forward 18 Motor 1 stops conveyor belt 1 Motar1cmd=stop 19 Motor 2 start conveyor belt 2 to move the Motar2cmd=forward package. 20 Motor 2 stops conveyor belt 2. Motar2cmd=stop 21 Motor 3 moves the scanner to down position Scannercmd=scan and wait for 10 sec. 22 Motor 3 moves the scanner to home position Scannercmd=home and wait for 5 sec 23 Scanner down limit sensor detects down Scannerdownsignal=true position. 24 Scanner up limit sensor detects home position. Scannerhomesignal=true 25 Motor 4 moves pusher to extend position. Pushercmd=extend 26 Motor 4 return pusher to home position. Pushercmd=home 27 Pusher forward limit sensor detects extended Pusherextendsignal=true position. 28 Pusher back limit sensor detects home position. Pusherhomeosignal=true 29 System reports the status of system (sensors Mode=auto;systemstatusmsg=true;repeat=t and motors) after every two seconds to web rue server. 30 User refreshes status earlier than 2 seconds. Mode=user;systemstatusmsg=true;repeat=tr ue 31 ALCS toggle to manual control mode. Mode=auto;toggle=usercontrol 32 User toggle to automatic control mode of ALCS. 33 ALCS reports items track after every 2 seconds. 34 Package is removed from sensor 4 at end place. Mode=user;toggle=auto Mode=auto;autocontrolmsg= report item track;repeat=true Mode=use; usercmd=remove pacakage; loc=end 121

24 Various constituent parts of test cases are obtained from the corresponding Event flow graph in Figure5.10 and corresponding EnDT in Table 5.4. Generated test cases are shown in Table 5.5. Table 5.5: Test Cases generated from Event node Description Table (EnDT) Test Event Sequence Sequence of Transitions Case No 1. s 4 14 xor4 16 Mode=use; usercmd=place pacakage; loc=end; E Generate S4signal=true; S4signal=detect; Motar2cmd=stop;Mode=use; usercmd=remove pacakage; loc=end 2. s 4 14 xor4 15 Mode=use; usercmd=place pacakage; loc=end; xor4 16 Generate S4signal=true; S4signal=nodetect; E Motar2cmd=forward; Generate S4signal=true; S4signal=detect; Motar2cmd=stop;Mode=use; usercmd=remove pacakage; loc=end 3. s E Mode=auto;systemstatusmsg=true;repeat=true; Mode=user;systemstatusmsg=true;repeat=true; Mode=auto;systemstatusmsg=true;repeat=true; 4. s 3 11 xor3 13 Mode=use; usercmd=place pacakage; 15 loc=transition; Generate S3signal=true; S3signal=detect; S4signal=nodetect 5. s 2 8 xor2 9 Mode=use; usercmd=place pacakage; loc=scanner; Generate S2signal=true; S2signal=nodetect 6. s 1 5 xor1 7 Mode=use; usercmd=place pacakage; loc=start; fork Generate S1signal=true; join S1signal=detect;S2signal=nodetect && S3signal=nodetect && S4signal=nodetect; Motar1cmd=forward; Generate S2signal=true 122

25 Table 5.5: Test Cases generated from Event node Description Table (EnDT) (Cont.) Test Case No Event Sequence Sequence of Transitions 7. s 2 8 xor Mode=use; usercmd=place pacakage; fork join2 loc=scanner; Generate S2signal=true; S2signal=detect; Motar1cmd=stop; S3signal=nodetect && S4signal=nodetect; 14 xor E Scannercmd=scan; Scannerdownsignal=true; Scannercmd=home; Scannerhomesignal=true; Pushercmd=extend; Pusherextendsignal=true; Pushercmd=home; Pusherhomeosignal=true; S3signal=detect; Motar2cmd=forward; Generate S4signal=true; S4signal=detect; Motar2cmd=stop;Mode=use; usercmd=remove pacakage; loc=end 8. s 1 5 xor1 6 E Mode=use; usercmd=place pacakage; loc=start; Generate S1signal=true; S1signal=nodetect 9. s 33 E Mode=auto;autocontrolmsg= report item track;repeat=true 10. s E Mode=auto;toggle=usercontrol; Mode=user;toggle=auto 11. s 3 11 xor3 12 Mode=use; usercmd=place pacakage; loc=transition; Generate S3signal=true; S3signal=nodetect 5.6 REGRESSION TESTING USING AN EVENT-FLOW GRAPH Regression testing is performed on modified software to ensure that the software behaves correctly and that modifications have not adversely affected the software s quality. 123

26 Regression testing is an expensive activity as it can account for as much as one-half of the cost of software maintenance. The primary goal of regression testing is to validate that changes introduced in a program are correct and do not adversely affect the unchanged portion of a program [278, ]. An important difference between regression testing and development testing is that, during regression testing, an established suite of tests may be available for reuse. During the process of regression testing, these previously developed test cases are deployed for revalidating a modified program. New test cases are also generated for the validation of a program. Thus regression testing consumes large amount of time and computing resources. In order to save cost and time, selective regression testing approaches are applied. One of the regression-testing strategies is retest-all approach that reruns all previous tests, but this may consume excessive time and resources. Selective retest techniques, in contrast, attempts to reduce the time required to retest a modified program by selectively reusing tests and selectively retesting a modified program. Next section presents application of selective retest technique on testing using an event-flow graph Role of Regression Testing in Event-based testing A regression test selection technique chooses, from an existing test set, tests that are deemed necessary to validate modified software [287]. There has been significant amount of research in designing effective regression testing techniques to reduce cost of regression testing. These techniques can be broadly divided into two types: Code-based regression testing and Specification based regression testing [ , 285, 286]. Since the proposed work is on model based testing (i.e. Event-flow model is used as basis of generating test scenarios), so it has used specification based regression testing approach. Generally, in large and evolving software systems, specifications are frequently changed for variety of reasons like: to correct errors in specifications, to enhance or change functionality, to add a new functionality, to delete existing functionality. Specification 124

27 changes are typically made on a requirement level, i.e. system engineers make changes to a specification by changing individual requirements. Based on the work done in [275, 276] three types of elementary modifications are identified at the requirement level: (a) Addition of a new requirement, (b) Deletion of existing requirement or (c) Modification of existing requirement. In the context of an event-based testing, addition and/or modification of events in a system specify changes in software requirements. An Event-flow model is used in regression testing. In an event-flow model, changes in requirements could be either due to addition and/or modification of events, these changes are easily reflected in an Event-flow graph. In such a case, event templates will change for those events in a trigger vector and causative events which are affected due to modification. Subsequently, changes can also be reflected in an event flow graph in terms of addition or deletion or changes in transitions in a graph. In both cases, new modified set of test scenarios if any, can be easily identified from an event-flow graph. It is possible to identify all potentially affected test scenarios from an Event-flow graph. Next section presents various possibilities of changes that may occur in an Event-flow graph Possibilities of changes in requirements that can generate need for Regression testing Requirement for Regression Testing arises due to new events or event dependencies (transitions) getting introduced in a system. It can also be in terms of changing or deleting existing events or event dependencies. These changes are first reflected in event templates by either introducing new templates or changing the existing event templates. Accordingly, Trigger vector and Causative events will be changed in event templates of affected events. Subsequently, changes are reflected in an event flow graph in terms of addition or deletion or changes in nodes or transitions in a graph. These changes are categorized as follows: 125

28 a) Addition or Replacement of new event nodes as predecessor or successor of existing nodes. The existing nodes affected can be a simple event node, an xor-node, an or-node or a fork node. The changes in this category can be: 1. Addition of a new event node in a simple path of events leading to leaf event node (event template with null trigger vector): In this case, depending on the location (predecessor or successor) Trigger vector and Causative event field of the existing and new event will change. If a new event is added as a last event in a sequence, then a transition will be added towards an end node. 2. Addition of a new event to the Trigger vector of an xor-node, an or-node or a fork node: In this case, a new event added will become part of trigger vector of the parent event of an xor-node, an or-node or a fork node affected. The new event will add a transition towards an end node, if a parent event is of an xor-node or an ornode. In case the parent node is of a fork node, a transition will be added from the new event towards join node. 3. Replacing entire set of Trigger vector of an xor-node, an or-node or a fork node with a new event node. In this case, new event added will be trigger vector of the parent event affected. Replaced set of trigger vector will become trigger of new event. 4. Replacing some events from the set of Trigger vector of an xor-node, an or-node or a fork node with a new event node. In this case, new event added will be trigger vector of the parent event of an xor-node, an or-node or a fork node affected and the replaced event will become trigger of new event. b) Addition or Replacement of transitions among event nodes on a simple path or among event nodes on paths at an xor-node, an or-node or a fork node. The existing nodes affected can be simple event nodes, an xor-node, an or-node or a fork node. In case of events on the 126

29 path from an xor-node, all events are mutually exclusive so an edge can not be added among events. In case of events on the path from an or-node, all events are independent so addition of an edge will not affect the existing transitions on that path. In case of events on the path from a fork node, addition of an edge from e1 to e2 will also involve corresponding addition of an edge from fork node to e2 and from e2 node to join-node. In case of two events e1 and e2 on two independent simple paths p1 and p2, addition of an edge from e1 to e2 involves updation of trigger vector and causative events of e1 and e2 respectively. a) Deletion of nodes or transitions among event nodes on a simple path or among event nodes on paths at an xor-node, an or-node or a fork node. The changes in this category can be: 1. An Event node deleted on a simple path. 2. An Xor-node is deleted when all events triggering from it are deleted, except one event. 3. A Fork-node is deleted when all events triggering from it are deleted. 4. A Join-node is deleted when all transitions merging on it are deleted. 5. An Event node common on an xor-node, an or-node or a fork node path is deleted when all its causative events are deleted. 6. A Transition from an xor-node, an or-node or a fork node can be deleted. In this case, if a transition from a fork node is deleted its corresponding transition from merging on the join-node is also deleted. If an event node becomes a leaf event node, then a corresponding transition is added to an end node. Modified Event-flow graph shown in Figure 5.11 shows changes with respect to possible options described above: 1. Event node N1 added prior to 31, earlier transition is replaced by two new transitions 2. Event node N2 added post to 33, earlier transition is replaced by two new transitions 127

30 3. Event node N3 added after an xor-node, two new transitions added from an xor node to a new event and from a new event to an end node 4. Event node N4 added after a fork-node, two transitions added from a fork node to a new event and from a new event to a join node 5. Event node N5 replaced entire set of trigger vector of xor node at event-8, one transitions added from an event 8 to an event node N5 6. Event node N6 replaced entire set of trigger vector of fork node at event-18, one transitions added from an event 18 to an event node N6 Figure 5.11: Modified Event-Flow Graph of APE Case Study Applying Regression Test Selection on Event-flow graph In this section, a regression test selection technique [287, 288] is applied that chooses from an existing test set, tests that are deemed necessary to validate modified software. The proposed approach [287, 288] is applied on an Event flow graph constructed from initial 128

31 requirements (Figure 5.10) and its modified version (Figure 5.11) constructed from changed requirements. These two graphs are used to select test scenarios that cover modified parts of an Event flow graph. The set of test scenarios that the approach selects includes every test scenario that can expose faults in the modified Event flow graph. Let R1 be initial requirements with an Event-flow graph G1 and T be the initial test suite consisting of various test scenarios generated from algorithm presented in section When R1 is tested with a test scenario t i from test suite T, it records branch trace from an Event-Flow Graph that consists of branches taken during this execution. An edge (N1, N2) in G1 is traversed by t i if and only if, when R1 is executed with t i events corresponding to nodes N1 and N2 are sequentially executed at least once during the execution. This information is called edge trace for t i on R1. A test history with respect to T is constructed by gathering edge trace information for each test scenario in T and representing it such that for each edge (N1, N2) in G1, the test history records all test scenarios that traversed (N1, N2). This representation is done in O (e*t) bits where e is the number of edges and t is the number of test scenarios in T. Table 5.6 shows Test History where for every edge (N1, N2) a bit vector is shown of size t in which k th bit in bit vector is set, if and only if test scenario k in T traversed the edge (N1, N2) in G1. E.g, In Figure 5.10 an edge (16 20) is traversed by test scenario 2, 3, and 6 so 2 nd, 3 rd and 6 th bit is set in the bit vector This selective retest technique reduces the cost of Regression Testing by selectively reusing existing tests and identifying changed portion in the modified version of an Event-Flow Graph that should be tested. To find tests that are modification-traversing for original requirements R1 and modified requirements R2, both Event-Flow Graphs G1 and G2 are synchronously traversed beginning with a start node S, looking for pairs of event nodes N1 and N1 whose labels are not lexicographically equivalent. A pair wise comparison of an event node compares labels on the first node in G1 to corresponding second node in G2 and so on. If a pair wise comparison of event nodes reaches a first pair of nodes N1 and N1 whose labels are not 129

A Novel Approach for Deriving Test Scenarios and Test Cases from Events

A Novel Approach for Deriving Test Scenarios and Test Cases from Events Journal of Information Processing Systems, Vol.8, No.2, June 2012 http://dx.doi.org/10.3745/jips.2012.8.2.213 A Novel Approach for Deriving Test Scenarios and Test Cases from Events Sandeep K. Singh*,

More information

Test Case Generation for Concurrent System using UML Combinational Diagram

Test Case Generation for Concurrent System using UML Combinational Diagram Test Case Generation for Concurrent System using UML Combinational Diagram Monalisha Khandai #1, Arup Abhinna Acharya #2, Durga Prasad Mohapatra *3 # School of Computer Engineering, KIIT University Bhubaneswar,

More information

ANALYZING PROCESS MODELS USING GRAPH REDUCTION TECHNIQUES

ANALYZING PROCESS MODELS USING GRAPH REDUCTION TECHNIQUES NLYZING PROCESS MODELS USING GRPH REDUCTION TECHNIQUES WSIM SDIQ ND MRI E. ORLOWSK Distributed Systems Technology Centre Department of Computer Science & Electrical Engineering The University of Queensland,

More information

Selection of UML Models for Test Case Generation: A Discussion on Techniques to Generate Test Cases

Selection of UML Models for Test Case Generation: A Discussion on Techniques to Generate Test Cases St. Cloud State University therepository at St. Cloud State Culminating Projects in Computer Science and Information Technology Department of Computer Science and Information Technology 6-2018 Selection

More information

Test Cases Generation from UML Activity Diagrams

Test Cases Generation from UML Activity Diagrams Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing Test Cases Generation from UML Activity Diagrams Hyungchoul Kim, Sungwon

More information

Research Scholar, Gitam University, Visakhapatnam, Andhra Pradeshm, India *2

Research Scholar, Gitam University, Visakhapatnam, Andhra Pradeshm, India *2 IJESRT INTERNATIONAL JOURNAL OF ENGINEERING SCIENCES & RESEARCH TECHNOLOGY Automatic Test case Generation from UML Activity Diagrams V.Mary Sumalatha *1, Dr G.S.V.P.Raju 2 1 Research Scholar, Gitam University,

More information

WEEK 5 - APPLICATION OF PETRI NETS. 4.4 Producers-consumers problem with priority

WEEK 5 - APPLICATION OF PETRI NETS. 4.4 Producers-consumers problem with priority 4.4 Producers-consumers problem with priority The net shown in Fig. 27 represents a producers-consumers system with priority, i.e., consumer A has priority over consumer B in the sense that A can consume

More information

FORTH SEMESTER DIPLOMA EXAMINATION IN ENGINEERING/ TECHNOLIGY- MARCH, 2012 DATA STRUCTURE (Common to CT and IF) [Time: 3 hours

FORTH SEMESTER DIPLOMA EXAMINATION IN ENGINEERING/ TECHNOLIGY- MARCH, 2012 DATA STRUCTURE (Common to CT and IF) [Time: 3 hours TED (10)-3071 Reg. No.. (REVISION-2010) (Maximum marks: 100) Signature. FORTH SEMESTER DIPLOMA EXAMINATION IN ENGINEERING/ TECHNOLIGY- MARCH, 2012 DATA STRUCTURE (Common to CT and IF) [Time: 3 hours PART

More information

FORTH SEMESTER DIPLOMA EXAMINATION IN ENGINEERING/ TECHNOLIGY- OCTOBER, 2012 DATA STRUCTURE

FORTH SEMESTER DIPLOMA EXAMINATION IN ENGINEERING/ TECHNOLIGY- OCTOBER, 2012 DATA STRUCTURE TED (10)-3071 Reg. No.. (REVISION-2010) Signature. FORTH SEMESTER DIPLOMA EXAMINATION IN ENGINEERING/ TECHNOLIGY- OCTOBER, 2012 DATA STRUCTURE (Common to CT and IF) [Time: 3 hours (Maximum marks: 100)

More information

Introduction to Software Testing Chapter 2, Sec#: 2.5 Graph Coverage for Specifications

Introduction to Software Testing Chapter 2, Sec#: 2.5 Graph Coverage for Specifications Introduction to Software Testing Chapter 2, Sec#: 2.5 Graph Coverage for Specifications Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/softwa retest/ Design Specifications A design specification

More information

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80 1 / 80 Verification Miaoqing Huang University of Arkansas Outline 1 Verification Overview 2 Testing Theory and Principles Theoretical Foundations of Testing Empirical Testing Principles 3 Testing in Practice

More information

CHAPTER 6 IMPLEMENTATION OF THE EVENT-BASED FRAMEWORK

CHAPTER 6 IMPLEMENTATION OF THE EVENT-BASED FRAMEWORK CHAPTER 6 IMPLEMENTATION OF THE EVENT-BASED FRAMEWORK 6.1 INTRODUCTION This chapter discusses the implementation of our proposed Event-based Framework for OOA of requirements, computation of complexity

More information

12 Abstract Data Types

12 Abstract Data Types 12 Abstract Data Types 12.1 Foundations of Computer Science Cengage Learning Objectives After studying this chapter, the student should be able to: Define the concept of an abstract data type (ADT). Define

More information

DDS Dynamic Search Trees

DDS Dynamic Search Trees DDS Dynamic Search Trees 1 Data structures l A data structure models some abstract object. It implements a number of operations on this object, which usually can be classified into l creation and deletion

More information

[ DATA STRUCTURES ] Fig. (1) : A Tree

[ DATA STRUCTURES ] Fig. (1) : A Tree [ DATA STRUCTURES ] Chapter - 07 : Trees A Tree is a non-linear data structure in which items are arranged in a sorted sequence. It is used to represent hierarchical relationship existing amongst several

More information

Joint Entity Resolution

Joint Entity Resolution Joint Entity Resolution Steven Euijong Whang, Hector Garcia-Molina Computer Science Department, Stanford University 353 Serra Mall, Stanford, CA 94305, USA {swhang, hector}@cs.stanford.edu No Institute

More information

[ DATA STRUCTURES] to Data Structures

[ DATA STRUCTURES] to Data Structures [ DATA STRUCTURES] Chapter - 01 : Introduction to Data Structures INTRODUCTION TO DATA STRUCTURES A Data type refers to a named group of data which share similar properties or characteristics and which

More information

Structural Testing. White Box Testing & Control Flow Analysis

Structural Testing. White Box Testing & Control Flow Analysis Structural Testing White Box Testing & Control Flow Analysis Functional vs. Structural Functional Have I built the right product? Tests derived from the program specification Internal Structure ignored

More information

Binary Trees. Height 1

Binary Trees. Height 1 Binary Trees Definitions A tree is a finite set of one or more nodes that shows parent-child relationship such that There is a special node called root Remaining nodes are portioned into subsets T1,T2,T3.

More information

Pet: An Interactive Software Testing Tool

Pet: An Interactive Software Testing Tool Pet: An Interactive Software Testing Tool Elsa Gunter, Robert Kurshan, and Doron Peled Bell Laboratories 600 Mountain Ave. Murray Hill, NJ 07974 Abstract. We describe here the Pet (standing for path exploration

More information

FINALTERM EXAMINATION Fall 2009 CS301- Data Structures Question No: 1 ( Marks: 1 ) - Please choose one The data of the problem is of 2GB and the hard

FINALTERM EXAMINATION Fall 2009 CS301- Data Structures Question No: 1 ( Marks: 1 ) - Please choose one The data of the problem is of 2GB and the hard FINALTERM EXAMINATION Fall 2009 CS301- Data Structures Question No: 1 The data of the problem is of 2GB and the hard disk is of 1GB capacity, to solve this problem we should Use better data structures

More information

Scribes: Romil Verma, Juliana Cook (2015), Virginia Williams, Date: May 1, 2017 and Seth Hildick-Smith (2016), G. Valiant (2017), M.

Scribes: Romil Verma, Juliana Cook (2015), Virginia Williams, Date: May 1, 2017 and Seth Hildick-Smith (2016), G. Valiant (2017), M. Lecture 9 Graphs Scribes: Romil Verma, Juliana Cook (2015), Virginia Williams, Date: May 1, 2017 and Seth Hildick-Smith (2016), G. Valiant (2017), M. Wootters (2017) 1 Graphs A graph is a set of vertices

More information

Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 4. Testing

Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 4. Testing 4. vs. Model Checking (usually) means checking the correctness of source code Model Checking means verifying the properties of a model given in some formal (not program code) notation Attention: things

More information

An Appropriate Search Algorithm for Finding Grid Resources

An Appropriate Search Algorithm for Finding Grid Resources An Appropriate Search Algorithm for Finding Grid Resources Olusegun O. A. 1, Babatunde A. N. 2, Omotehinwa T. O. 3,Aremu D. R. 4, Balogun B. F. 5 1,4 Department of Computer Science University of Ilorin,

More information

CS 310 Advanced Data Structures and Algorithms

CS 310 Advanced Data Structures and Algorithms CS 31 Advanced Data Structures and Algorithms Graphs July 18, 17 Tong Wang UMass Boston CS 31 July 18, 17 1 / 4 Graph Definitions Graph a mathematical construction that describes objects and relations

More information

1. Introduction to Concurrent Programming

1. Introduction to Concurrent Programming 1. Introduction to Concurrent Programming A concurrent program contains two or more threads that execute concurrently and work together to perform some task. When a program is executed, the operating system

More information

UNIT-II. Part-2: CENTRAL PROCESSING UNIT

UNIT-II. Part-2: CENTRAL PROCESSING UNIT Page1 UNIT-II Part-2: CENTRAL PROCESSING UNIT Stack Organization Instruction Formats Addressing Modes Data Transfer And Manipulation Program Control Reduced Instruction Set Computer (RISC) Introduction:

More information

7. Testing and Debugging Concurrent Programs

7. Testing and Debugging Concurrent Programs 7. Testing and Debugging Concurrent Programs The purpose of testing is to find program failures => A successful test is a test that causes a program to fail. Ideally, tests are designed before the program

More information

A Framework for Space and Time Efficient Scheduling of Parallelism

A Framework for Space and Time Efficient Scheduling of Parallelism A Framework for Space and Time Efficient Scheduling of Parallelism Girija J. Narlikar Guy E. Blelloch December 996 CMU-CS-96-97 School of Computer Science Carnegie Mellon University Pittsburgh, PA 523

More information

The Encoding Complexity of Network Coding

The Encoding Complexity of Network Coding The Encoding Complexity of Network Coding Michael Langberg Alexander Sprintson Jehoshua Bruck California Institute of Technology Email: mikel,spalex,bruck @caltech.edu Abstract In the multicast network

More information

An algorithm for Performance Analysis of Single-Source Acyclic graphs

An algorithm for Performance Analysis of Single-Source Acyclic graphs An algorithm for Performance Analysis of Single-Source Acyclic graphs Gabriele Mencagli September 26, 2011 In this document we face with the problem of exploiting the performance analysis of acyclic graphs

More information

Midterm Wednesday Oct. 27, 7pm, room 142

Midterm Wednesday Oct. 27, 7pm, room 142 Regression Testing Midterm Wednesday Oct. 27, 7pm, room 142 In class, closed book eam Includes all the material covered up (but not including) symbolic eecution Need to understand the concepts, know the

More information

CPS221 Lecture: Threads

CPS221 Lecture: Threads Objectives CPS221 Lecture: Threads 1. To introduce threads in the context of processes 2. To introduce UML Activity Diagrams last revised 9/5/12 Materials: 1. Diagram showing state of memory for a process

More information

Appendix D: Mapping BPMN to BPD Profile

Appendix D: Mapping BPMN to BPD Profile Appendix D: Mapping BPMN to BPD Profile Members of bpmi.org and the OMG are interested in the unification of the UML 2.0 and BPMN notation for the support of the business user. This draft mapping is in

More information

A Semantics to Generate the Context-sensitive Synchronized Control-Flow Graph (extended)

A Semantics to Generate the Context-sensitive Synchronized Control-Flow Graph (extended) A Semantics to Generate the Context-sensitive Synchronized Control-Flow Graph (extended) Marisa Llorens, Javier Oliver, Josep Silva, and Salvador Tamarit Universidad Politécnica de Valencia, Camino de

More information

A Survey on Test Case Generation from UML Model

A Survey on Test Case Generation from UML Model A Survey on Test Case Generation from UML Model Monalisha Khandai #1, Arup Abhinna Acharya #2, Durga Prasad Mohapatra *3 # School of Computer Engineering, KIIT University Bhubaneswar, India * Department

More information

Data Structure. IBPS SO (IT- Officer) Exam 2017

Data Structure. IBPS SO (IT- Officer) Exam 2017 Data Structure IBPS SO (IT- Officer) Exam 2017 Data Structure: In computer science, a data structure is a way of storing and organizing data in a computer s memory so that it can be used efficiently. Data

More information

Self Stabilization. CS553 Distributed Algorithms Prof. Ajay Kshemkalyani. by Islam Ismailov & Mohamed M. Ali

Self Stabilization. CS553 Distributed Algorithms Prof. Ajay Kshemkalyani. by Islam Ismailov & Mohamed M. Ali Self Stabilization CS553 Distributed Algorithms Prof. Ajay Kshemkalyani by Islam Ismailov & Mohamed M. Ali Introduction There is a possibility for a distributed system to go into an illegitimate state,

More information

Goal-Based Agents Problem solving as search. Outline

Goal-Based Agents Problem solving as search. Outline Goal-Based Agents Problem solving as search Vasant Honavar Bioinformatics and Computational Biology Program Center for Computational Intelligence, Learning, & Discovery honavar@cs.iastate.edu www.cs.iastate.edu/~honavar/

More information

TIE Graph algorithms

TIE Graph algorithms TIE-20106 239 11 Graph algorithms This chapter discusses the data structure that is a collection of points (called nodes or vertices) and connections between them (called edges or arcs) a graph. The common

More information

Test Automation. 20 December 2017

Test Automation. 20 December 2017 Test Automation 20 December 2017 The problem of test automation Testing has repetitive components, so automation is justified The problem is cost-benefit evaluation of automation [Kaner] Time for: test

More information

MULTIMEDIA COLLEGE JALAN GURNEY KIRI KUALA LUMPUR

MULTIMEDIA COLLEGE JALAN GURNEY KIRI KUALA LUMPUR STUDENT IDENTIFICATION NO MULTIMEDIA COLLEGE JALAN GURNEY KIRI 54100 KUALA LUMPUR FIFTH SEMESTER FINAL EXAMINATION, 2014/2015 SESSION PSD2023 ALGORITHM & DATA STRUCTURE DSEW-E-F-2/13 25 MAY 2015 9.00 AM

More information

CSc33200: Operating Systems, CS-CCNY, Fall 2003 Jinzhong Niu December 10, Review

CSc33200: Operating Systems, CS-CCNY, Fall 2003 Jinzhong Niu December 10, Review CSc33200: Operating Systems, CS-CCNY, Fall 2003 Jinzhong Niu December 10, 2003 Review 1 Overview 1.1 The definition, objectives and evolution of operating system An operating system exploits and manages

More information

Following are a few basic questions that cover the essentials of OS:

Following are a few basic questions that cover the essentials of OS: Operating Systems Following are a few basic questions that cover the essentials of OS: 1. Explain the concept of Reentrancy. It is a useful, memory-saving technique for multiprogrammed timesharing systems.

More information

Parallel Discrete Event Simulation

Parallel Discrete Event Simulation Parallel Discrete Event Simulation Dr.N.Sairam & Dr.R.Seethalakshmi School of Computing, SASTRA Univeristy, Thanjavur-613401. Joint Initiative of IITs and IISc Funded by MHRD Page 1 of 8 Contents 1. Parallel

More information

Draw a diagram of an empty circular queue and describe it to the reader.

Draw a diagram of an empty circular queue and describe it to the reader. 1020_1030_testquestions.text Wed Sep 10 10:40:46 2014 1 1983/84 COSC1020/30 Tests >>> The following was given to students. >>> Students can have a good idea of test questions by examining and trying the

More information

Testing & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010

Testing & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010 esting & Continuous Integration Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/1/20 University of Colorado, 20 1 Goals 2 Review material from Chapter of Pilone & Miles esting

More information

Faster Or-join Enactment for BPMN 2.0

Faster Or-join Enactment for BPMN 2.0 Faster Or-join Enactment for BPMN 2.0 Hagen Völzer, IBM Research Zurich Joint work with Beat Gfeller and Gunnar Wilmsmann Contribution: BPMN Diagram Enactment Or-join Tokens define the control state Execution

More information

Distributed minimum spanning tree problem

Distributed minimum spanning tree problem Distributed minimum spanning tree problem Juho-Kustaa Kangas 24th November 2012 Abstract Given a connected weighted undirected graph, the minimum spanning tree problem asks for a spanning subtree with

More information

BPMN2BPEL transformation with Fujaba - a Case Study

BPMN2BPEL transformation with Fujaba - a Case Study BPMN2BPEL transformation with Fujaba - a Case Study Ruben Jubeh SE, Kassel University Wilhelmshöher Allee 73 34121 Kassel ruben.jubeh@uni-kassel.de ABSTRACT We have modeled a BPMN to BPEL synthesis transformation

More information

R10 SET - 1. Code No: R II B. Tech I Semester, Supplementary Examinations, May

R10 SET - 1. Code No: R II B. Tech I Semester, Supplementary Examinations, May www.jwjobs.net R10 SET - 1 II B. Tech I Semester, Supplementary Examinations, May - 2012 (Com. to CSE, IT, ECC ) Time: 3 hours Max Marks: 75 *******-****** 1. a) Which of the given options provides the

More information

GUJARAT TECHNOLOGICAL UNIVERSITY MASTER OF COMPUTER APPLICATION SEMESTER: III

GUJARAT TECHNOLOGICAL UNIVERSITY MASTER OF COMPUTER APPLICATION SEMESTER: III GUJARAT TECHNOLOGICAL UNIVERSITY MASTER OF COMPUTER APPLICATION SEMESTER: III Subject Name: Operating System (OS) Subject Code: 630004 Unit-1: Computer System Overview, Operating System Overview, Processes

More information

Elementary Graph Algorithms. Ref: Chapter 22 of the text by Cormen et al. Representing a graph:

Elementary Graph Algorithms. Ref: Chapter 22 of the text by Cormen et al. Representing a graph: Elementary Graph Algorithms Ref: Chapter 22 of the text by Cormen et al. Representing a graph: Graph G(V, E): V set of nodes (vertices); E set of edges. Notation: n = V and m = E. (Vertices are numbered

More information

Graph Theory for Modelling a Survey Questionnaire Pierpaolo Massoli, ISTAT via Adolfo Ravà 150, Roma, Italy

Graph Theory for Modelling a Survey Questionnaire Pierpaolo Massoli, ISTAT via Adolfo Ravà 150, Roma, Italy Graph Theory for Modelling a Survey Questionnaire Pierpaolo Massoli, ISTAT via Adolfo Ravà 150, 00142 Roma, Italy e-mail: pimassol@istat.it 1. Introduction Questions can be usually asked following specific

More information

Database System Concepts

Database System Concepts Chapter 13: Query Processing s Departamento de Engenharia Informática Instituto Superior Técnico 1 st Semester 2008/2009 Slides (fortemente) baseados nos slides oficiais do livro c Silberschatz, Korth

More information

Lecture 10 Notes Linked Lists

Lecture 10 Notes Linked Lists Lecture 10 Notes Linked Lists 15-122: Principles of Imperative Computation (Spring 2016) Frank Pfenning, Rob Simmons, André Platzer 1 Introduction In this lecture we discuss the use of linked lists to

More information

Activities Radovan Cervenka

Activities Radovan Cervenka Unified Modeling Language Activities Radovan Cervenka Activity Model Specification of an algorithmic behavior. Used to represent control flow and object flow models. Executing activity (of on object) is

More information

Search. (Textbook Chpt ) Computer Science cpsc322, Lecture 2. May, 10, CPSC 322, Lecture 2 Slide 1

Search. (Textbook Chpt ) Computer Science cpsc322, Lecture 2. May, 10, CPSC 322, Lecture 2 Slide 1 Search Computer Science cpsc322, Lecture 2 (Textbook Chpt 3.0-3.4) May, 10, 2012 CPSC 322, Lecture 2 Slide 1 Colored Cards You need to have 4 colored index cards Come and get them from me if you still

More information

Chapter 14. Graphs Pearson Addison-Wesley. All rights reserved 14 A-1

Chapter 14. Graphs Pearson Addison-Wesley. All rights reserved 14 A-1 Chapter 14 Graphs 2011 Pearson Addison-Wesley. All rights reserved 14 A-1 Terminology G = {V, E} A graph G consists of two sets A set V of vertices, or nodes A set E of edges A subgraph Consists of a subset

More information

Overview Graph Coverage Criteria

Overview Graph Coverage Criteria Overview Graph Coverage Criteria Graph Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Applied to Applied to Source FSMs Applied to Specs DNF Source Specs Source Models Design

More information

Chapter 5. Decrease-and-Conquer. Copyright 2007 Pearson Addison-Wesley. All rights reserved.

Chapter 5. Decrease-and-Conquer. Copyright 2007 Pearson Addison-Wesley. All rights reserved. Chapter 5 Decrease-and-Conquer Copyright 2007 Pearson Addison-Wesley. All rights reserved. Decrease-and-Conquer 1. Reduce problem instance to smaller instance of the same problem 2. Solve smaller instance

More information

TREES. Trees - Introduction

TREES. Trees - Introduction TREES Chapter 6 Trees - Introduction All previous data organizations we've studied are linear each element can have only one predecessor and successor Accessing all elements in a linear sequence is O(n)

More information

8. Write an example for expression tree. [A/M 10] (A+B)*((C-D)/(E^F))

8. Write an example for expression tree. [A/M 10] (A+B)*((C-D)/(E^F)) DHANALAKSHMI COLLEGE OF ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING EC6301 OBJECT ORIENTED PROGRAMMING AND DATA STRUCTURES UNIT IV NONLINEAR DATA STRUCTURES Part A 1. Define Tree [N/D 08]

More information

Part I: Preliminaries 24

Part I: Preliminaries 24 Contents Preface......................................... 15 Acknowledgements................................... 22 Part I: Preliminaries 24 1. Basics of Software Testing 25 1.1. Humans, errors, and testing.............................

More information

Facts About Testing. Cost/benefit. Reveal faults. Bottom-up. Testing takes more than 50% of the total cost of software development

Facts About Testing. Cost/benefit. Reveal faults. Bottom-up. Testing takes more than 50% of the total cost of software development Reveal faults Goals of testing Correctness Reliability Usability Robustness Performance Top-down/Bottom-up Bottom-up Lowest level modules tested first Don t depend on any other modules Driver Auxiliary

More information

Restricted Use Case Modeling Approach

Restricted Use Case Modeling Approach RUCM TAO YUE tao@simula.no Simula Research Laboratory Restricted Use Case Modeling Approach User Manual April 2010 Preface Use case modeling is commonly applied to document requirements. Restricted Use

More information

CS 125 Section #6 Graph Traversal and Linear Programs 10/13/14

CS 125 Section #6 Graph Traversal and Linear Programs 10/13/14 CS 125 Section #6 Graph Traversal and Linear Programs 10/13/14 1 Depth first search 1.1 The Algorithm Besides breadth first search, which we saw in class in relation to Dijkstra s algorithm, there is one

More information

ONE-STACK AUTOMATA AS ACCEPTORS OF CONTEXT-FREE LANGUAGES *

ONE-STACK AUTOMATA AS ACCEPTORS OF CONTEXT-FREE LANGUAGES * ONE-STACK AUTOMATA AS ACCEPTORS OF CONTEXT-FREE LANGUAGES * Pradip Peter Dey, Mohammad Amin, Bhaskar Raj Sinha and Alireza Farahani National University 3678 Aero Court San Diego, CA 92123 {pdey, mamin,

More information

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design i About the Tutorial A compiler translates the codes written in one language to some other language without changing the meaning of the program. It is also expected that a compiler should make the target

More information

CS24 Week 8 Lecture 1

CS24 Week 8 Lecture 1 CS24 Week 8 Lecture 1 Kyle Dewey Overview Tree terminology Tree traversals Implementation (if time) Terminology Node The most basic component of a tree - the squares Edge The connections between nodes

More information

CSI 604 Elementary Graph Algorithms

CSI 604 Elementary Graph Algorithms CSI 604 Elementary Graph Algorithms Ref: Chapter 22 of the text by Cormen et al. (Second edition) 1 / 25 Graphs: Basic Definitions Undirected Graph G(V, E): V is set of nodes (or vertices) and E is the

More information

6.852: Distributed Algorithms Fall, Class 12

6.852: Distributed Algorithms Fall, Class 12 6.852: Distributed Algorithms Fall, 2009 Class 12 Today s plan Weak logical time and vector timestamps Consistent global snapshots and stable property detection. Applications: Distributed termination.

More information

Chapter 27 Cluster Work Queues

Chapter 27 Cluster Work Queues Chapter 27 Cluster Work Queues Part I. Preliminaries Part II. Tightly Coupled Multicore Part III. Loosely Coupled Cluster Chapter 18. Massively Parallel Chapter 19. Hybrid Parallel Chapter 20. Tuple Space

More information

Chapter 13: Query Processing

Chapter 13: Query Processing Chapter 13: Query Processing! Overview! Measures of Query Cost! Selection Operation! Sorting! Join Operation! Other Operations! Evaluation of Expressions 13.1 Basic Steps in Query Processing 1. Parsing

More information

Introduction to Dynamic Analysis

Introduction to Dynamic Analysis Introduction to Dynamic Analysis Reading assignment Gary T. Leavens, Yoonsik Cheon, "Design by Contract with JML," draft paper, http://www.eecs.ucf.edu/~leavens/jml//jmldbc.pdf G. Kudrjavets, N. Nagappan,

More information

UNIT-4 Black Box & White Box Testing

UNIT-4 Black Box & White Box Testing Black Box & White Box Testing Black Box Testing (Functional testing) o Equivalence Partitioning o Boundary Value Analysis o Cause Effect Graphing White Box Testing (Structural testing) o Coverage Testing

More information

Ans 1-j)True, these diagrams show a set of classes, interfaces and collaborations and their relationships.

Ans 1-j)True, these diagrams show a set of classes, interfaces and collaborations and their relationships. Q 1) Attempt all the following questions: (a) Define the term cohesion in the context of object oriented design of systems? (b) Do you need to develop all the views of the system? Justify your answer?

More information

TIE Graph algorithms

TIE Graph algorithms TIE-20106 1 1 Graph algorithms This chapter discusses the data structure that is a collection of points (called nodes or vertices) and connections between them (called edges or arcs) a graph. The common

More information

Diagnostic Information for Control-Flow Analysis of Workflow Graphs (aka Free-Choice Workflow Nets)

Diagnostic Information for Control-Flow Analysis of Workflow Graphs (aka Free-Choice Workflow Nets) Diagnostic Information for Control-Flow Analysis of Workflow Graphs (aka Free-Choice Workflow Nets) Cédric Favre(1,2), Hagen Völzer(1), Peter Müller(2) (1) IBM Research - Zurich (2) ETH Zurich 1 Outline

More information

Uninformed Search Methods

Uninformed Search Methods Uninformed Search Methods Search Algorithms Uninformed Blind search Breadth-first uniform first depth-first Iterative deepening depth-first Bidirectional Branch and Bound Informed Heuristic search Greedy

More information

Analysis of Algorithms. Unit 4 - Analysis of well known Algorithms

Analysis of Algorithms. Unit 4 - Analysis of well known Algorithms Analysis of Algorithms Unit 4 - Analysis of well known Algorithms 1 Analysis of well known Algorithms Brute Force Algorithms Greedy Algorithms Divide and Conquer Algorithms Decrease and Conquer Algorithms

More information

Data Structure Advanced

Data Structure Advanced Data Structure Advanced 1. Is it possible to find a loop in a Linked list? a. Possilbe at O(n) b. Not possible c. Possible at O(n^2) only d. Depends on the position of loop Solution: a. Possible at O(n)

More information

Chapter 12: Query Processing

Chapter 12: Query Processing Chapter 12: Query Processing Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Overview Chapter 12: Query Processing Measures of Query Cost Selection Operation Sorting Join

More information

CHAPTER 7. Copyright Cengage Learning. All rights reserved.

CHAPTER 7. Copyright Cengage Learning. All rights reserved. CHAPTER 7 FUNCTIONS Copyright Cengage Learning. All rights reserved. SECTION 7.1 Functions Defined on General Sets Copyright Cengage Learning. All rights reserved. Functions Defined on General Sets We

More information

Search Algorithms for Discrete Optimization Problems

Search Algorithms for Discrete Optimization Problems Search Algorithms for Discrete Optimization Problems Ananth Grama, Anshul Gupta, George Karypis, and Vipin Kumar To accompany the text ``Introduction to Parallel Computing'', Addison Wesley, 2003. 1 Topic

More information

UNIT-4 Black Box & White Box Testing

UNIT-4 Black Box & White Box Testing Black Box & White Box Testing Black Box Testing (Functional testing) o Equivalence Partitioning o Boundary Value Analysis o Cause Effect Graphing White Box Testing (Structural testing) o Coverage Testing

More information

Graph. Vertex. edge. Directed Graph. Undirected Graph

Graph. Vertex. edge. Directed Graph. Undirected Graph Module : Graphs Dr. Natarajan Meghanathan Professor of Computer Science Jackson State University Jackson, MS E-mail: natarajan.meghanathan@jsums.edu Graph Graph is a data structure that is a collection

More information

Dataflow-based Coverage Criteria

Dataflow-based Coverage Criteria Dataflow-based Coverage Criteria W. Eric Wong Department of Computer Science The University of Texas at Dallas ewong@utdallas.edu http://www.utdallas.edu/~ewong Dataflow-based Coverage Criteria ( 2012

More information

Control-Flow Analysis

Control-Flow Analysis Control-Flow Analysis Dragon book [Ch. 8, Section 8.4; Ch. 9, Section 9.6] Compilers: Principles, Techniques, and Tools, 2 nd ed. by Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jerey D. Ullman on reserve

More information

DISCRETE-event dynamic systems (DEDS) are dynamic

DISCRETE-event dynamic systems (DEDS) are dynamic IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 7, NO. 2, MARCH 1999 175 The Supervised Control of Discrete-Event Dynamic Systems François Charbonnier, Hassane Alla, and René David Abstract The supervisory

More information

INSTITUTE OF AERONAUTICAL ENGINEERING

INSTITUTE OF AERONAUTICAL ENGINEERING INSTITUTE OF AERONAUTICAL ENGINEERING (Autonomous) Dundigal, Hyderabad - 500 043 COMPUTER SCIENCE AND ENGINEERING TUTORIAL QUESTION BANK Course Name Course Code Class Branch DATA STRUCTURES ACS002 B. Tech

More information

Trees. 3. (Minimally Connected) G is connected and deleting any of its edges gives rise to a disconnected graph.

Trees. 3. (Minimally Connected) G is connected and deleting any of its edges gives rise to a disconnected graph. Trees 1 Introduction Trees are very special kind of (undirected) graphs. Formally speaking, a tree is a connected graph that is acyclic. 1 This definition has some drawbacks: given a graph it is not trivial

More information

! A relational algebra expression may have many equivalent. ! Cost is generally measured as total elapsed time for

! A relational algebra expression may have many equivalent. ! Cost is generally measured as total elapsed time for Chapter 13: Query Processing Basic Steps in Query Processing! Overview! Measures of Query Cost! Selection Operation! Sorting! Join Operation! Other Operations! Evaluation of Expressions 1. Parsing and

More information

Chapter 13: Query Processing Basic Steps in Query Processing

Chapter 13: Query Processing Basic Steps in Query Processing Chapter 13: Query Processing Basic Steps in Query Processing! Overview! Measures of Query Cost! Selection Operation! Sorting! Join Operation! Other Operations! Evaluation of Expressions 1. Parsing and

More information

Copyright 2000, Kevin Wayne 1

Copyright 2000, Kevin Wayne 1 Chapter 3 - Graphs Undirected Graphs Undirected graph. G = (V, E) V = nodes. E = edges between pairs of nodes. Captures pairwise relationship between objects. Graph size parameters: n = V, m = E. Directed

More information

Software Service Engineering

Software Service Engineering Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language

More information

An Introduction to Systematic Software Testing. Robert France CSU

An Introduction to Systematic Software Testing. Robert France CSU An Introduction to Systematic Software Testing Robert France CSU Why do we need to systematically test software? Poor quality products can Inconvenience direct and indirect users Result in severe financial

More information

A taxonomy of race. D. P. Helmbold, C. E. McDowell. September 28, University of California, Santa Cruz. Santa Cruz, CA

A taxonomy of race. D. P. Helmbold, C. E. McDowell. September 28, University of California, Santa Cruz. Santa Cruz, CA A taxonomy of race conditions. D. P. Helmbold, C. E. McDowell UCSC-CRL-94-34 September 28, 1994 Board of Studies in Computer and Information Sciences University of California, Santa Cruz Santa Cruz, CA

More information

Interaction Testing! Chapter 15!!

Interaction Testing! Chapter 15!! Interaction Testing Chapter 15 Interaction faults and failures Subtle Difficult to detect with testing Usually seen after systems have been delivered In low probability threads Occur after a long time

More information

Software Testing for Developer Development Testing. Duvan Luong, Ph.D. Operational Excellence Networks

Software Testing for Developer Development Testing. Duvan Luong, Ph.D. Operational Excellence Networks Software Testing for Developer Development Testing Duvan Luong, Ph.D. Operational Excellence Networks Contents R&D Testing Approaches Static Analysis White Box Testing Black Box Testing 4/2/2012 2 Development

More information