domains and paths, Nice & ugly domains, domain testing, domains and interfaces testing, domain and interface testing, domains and testability

domains and paths, Nice & ugly domains, domain testing, domains and interfaces testing, domain and interface testing, domains and testability.

1. Software Testing Methodologies Presented by: Dr. B.Rajalingam Associate Professor Department of Computer Science & Engineering St. Martin's Engineering College UNIT 2 Transaction & Data Flow Testing

2. SOFTWARE TESTING METHODOLOGIES Prerequisites 1. A course on “Software Engineering” Course Objectives To provide knowledge of the concepts in software testing such as testing process, criteria, strategies, and methodologies. To develop skills in software test automation and management using latest tools. Course Outcomes : Design and develop the best test strategies in accordance to the development model. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 2

3. Syllabus UNIT - I Introduction: Purpose of testing, Dichotomies, model for testing, consequences of bugs, taxonomy of bugs: Flow graphs and Path testing: Basics concepts of path testing, predicates, path predicates and achievable paths, path sensitizing, path instrumentation, application of path testing. UNIT - II Transaction Flow Testing: transaction flows, transaction flow testing techniques. Dataflow testing: Basics of dataflow testing, strategies in dataflow testing, application of dataflow testing. : domains and paths, Nice & ugly domains, domain testing, domains and interfaces testing, domain and interface testing, domains and testability. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 3

4. Syllabus UNIT - III Paths, Path products and Regular expressions: path products & path expression, reduction procedure, applications, regular expressions & flow anomaly detection. Logic Based Testing: overview, decision tables, path expressions, kv charts, specifications. UNIT - IV State, State Graphs and Transition testing: state graphs, good & bad state graphs, state testing, Testability tips. UNIT - V Graph Matrices and Application: Motivational overview, matrix of graph, relations, power of a matrix, node reduction algorithm, building tools. (Student should be given an exposure to a tool like JMeter or Win-runner). 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 4

5. TEXT BOOKS: 1. Software Testing techniques – Baris Beizer , Dreamtech , second edition. 2. Software Testing Tools – Dr. K. V. K. K. Prasad, Dreamtech . REFERENCE BOOKS: 1. The craft of software testing – Brian Marick , Pearson Education. 2. Software Testing Techniques – SPD(Oreille) 3. Software Testing in the Real World – Edward Kit, Pearson. 4. Effective methods of Software Testing, Perry, John Wiley. 5. Art of Software Testing – Meyers, John Wiley. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 5

6. 6 Sub Topic No’s Sub Topic name Slide No’s 1 Transaction flow Testing: Overview 2 Transaction flow Graph 3 Transaction flow testing techniques 4 Dataflow testing: Basics 5 Dataflow Madel 6 Strategies in dataflow testing 7 Application of dataflow testing 4 May 2021 STM(Unit 2): Dr. B.Rajalingam 6

7. Transaction Flow Testing A transaction is a unit of work seen from a system user's point of view. A transaction consists of a sequence of operations, some of which are performed by a system, persons or devices that are outside of the system. Transaction begins with Birth that is they are created as a result of some external act. At the conclusion of the transaction's processing, the transaction is no longer in the system. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 7

8. Example of a transaction: A transaction for an online information retrieval system might consist of the following steps or tasks: Accept input (tentative birth) Validate input (birth) Transmit acknowledgment to requester Do input processing Search file Request directions from user Accept input Validate input Process request Update file Transmit output Record transaction in log and clean up (death) 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 8

9. TRANSACTION FLOW GRAPHS Transaction flows are introduced as a representation of a system's processing. The methods that were applied to control flow graphs are then used for functional testing. The transaction flow graph is to create a behavioral model of the program that leads to functional testing. The transaction flowgraph is a model of the structure of the system's behavior (functionality). 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 9

10. An example of a Transaction Flow is as follows: STM(Unit 2):-Dr. B.Rajalingam 04-05-2021 10

11. USAGE Transaction flows are indispensable for specifying requirements of complicated systems, especially online systems. A big system such as an air traffic control or airline reservation system has not hundreds, but thousands of different transaction flows. The flows are represented by relatively simple flow graphs, many of which have a single straight-through path. Loops are infrequent compared to control flow graphs. The most common loop is used to request a retry after user input errors. An ATM system, for example, allows the user to try, saying three times, and will take the card away the fourth time. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 11

12. COMPLICATIONS In simple cases, the transactions have a unique identity from the time they're created to the time they're completed. In many systems, the transactions can give birth to others, and transactions can also merge. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 12

13. Births There are three different possible interpretations of the decision symbol or nodes with two or more out links. It can be a Decision, Biosis or a Mitosis. 1. Decision Here the transaction will take one alternative or the other alternative but not both. 2. Biosis Here the incoming transaction gives birth to a new transaction, and both transactions that continue on their separate paths and the parent retains its identity. 3. Mitosis Here the parent transaction is destroyed and two new transactions are created. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 13

14. 14 Transaction Flows – splitting & merging decisions Splits of transactions (Births) A decision point in TFG Alternative 1 Alternative 2 Daughter Tr. Parent Parent Daughter Tr . Daughter Tr. Parent Biosis Mitosis 4 May 2021 STM(Unit 2): Dr. B.Rajalingam

15. Mergers Transaction flow junction points are potentially as troublesome as transaction flow splits. There are three types of junctions: (1) Ordinary Junction (2) Absorption (3) Conjugation Ordinary Junction: An ordinary junction which is similar to the junction in a control flow graph. A transaction can arrive either on one link or the other. Absorption: In absorption case, the predator transaction absorbs prey transaction. The prey was gone but the predator retains its identity. Conjugation: In conjugation case, the two parent transactions merge to form a new daughter. In keeping with the biological flavor , this case is called as conjugation. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 15

16. Transaction Flows – splitting & merging decisions Mergers of transactions Junction Daughter Parent Parent Conjugation Path 2 Path 1 Continue Daughter Tr. Predator Predator Absorption 4 May 2021 STM(Unit 2): Dr. B.Rajalingam 16

17. Transaction Flow Testing Techniques: Get The Transactions Flows: Inspections, Reviews and Walkthroughs: Path Selection: Path Sensitization: Path Instrumentation: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 17

18. Get The Transactions Flows: Complicated systems that process a lot of different, complicated transactions should have explicit representations of the transactions flows, or the equivalent. Transaction flows are like control flow graphs, and consequently we should expect to have them in increasing levels of detail. The system's design documentation should contain an overview section that details the main transaction flows. Detailed transaction flows are a mandatory prerequisite to the rational design of a system's functional test. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 18

19. Inspections, Reviews and Walkthroughs: Transaction flows are natural agenda for system reviews or inspections. In conducting the walkthroughs, you should: Discuss enough transaction types to account for 98%-99% of the transaction the system is expected to process. Discuss paths through flows in functional rather than technical terms. Ask the designers to relate every flow to the specification and to show how that transaction, directly or indirectly, follows from the requirements. Make transaction flow testing the cornerstone of system functional testing just as path testing is the cornerstone of unit testing. Select additional flow paths for loops, extreme values, and domain boundaries. Design more test cases to validate all births and deaths. Publish and distribute the selected test paths through the transaction flows as early as possible so that they will exert the maximum beneficial effect on the project. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 19

20. Path Selection: Select a set of covering paths (c1+c2) using the analogous criteria that were used for structural path testing. Select a covering set of paths based on functionally sensible transactions, as you would for control flow graphs. Try to find the most tortuous, longest, strangest path from the entry to the exit of the transaction flow. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 20

21. Path Sensitization: Add your content...Most of the normal paths are very easy to sensitize-80% - 95% transaction flow coverage (c1+c2) is usually easy to achieve. The remaining small percentage is often very difficult. Sensitization is the act of defining the transaction. If there are sensitization problems on the easy paths, then bet on either a bug in transaction flows or a design bug. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 21

22. Path Instrumentation: Instrumentation plays a bigger role in transaction flow testing than in unit path testing. The information of the path taken for a given transaction must be kept with that transaction and can be recorded by a central transaction dispatcher or by the individual processing modules. In some systems, such traces are provided by the operating systems or a running log. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 22

23. Data Flow Testing: Data flow testing is the name given to a family of test strategies based on selecting paths through the program's control flow in order to explore sequences of events related to the status of data objects. For example, pick enough paths to assure that every data object has been initialized prior to use or that all defined objects have been used for something. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 23

24. Motivation: It is our belief that, just as one would not feel confident about a program without executing every statement in it as part of some test, one should not feel confident about a program without having seen the effect of using the value produced by each and every computation. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 24

25. Data Flow Machines: There are two types of data flow machines with different architectures. Von Neumann machines Multi-instruction, multi-data machines (MIMD). 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 25

26. Von Neumann Machine Architecture: Most computers today are Von-Neumann machines. This architecture features interchangeable storage of instructions and data in the same memory units. The Von Neumann machine Architecture executes one instruction at a time in the following, micro instruction sequence: Fetch instruction from memory Interpret instruction Fetch operands Process or Execute Store result Increment program counter GOTO 1 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 26

27. Multi-instruction, Multi-data machines (MIMD) Architecture: These machines can fetch several instructions and objects in parallel. They can also do arithmetic and logical operations simultaneously on different data objects. The decision of how to sequence them depends on the compiler. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 27

28. Bug Assumption: The bug assumption for data-flow testing strategies is that control flow is generally correct and that something has gone wrong with the software so that data objects are not available when they should be, or silly things are being done to data objects. Also, if there is a control-flow problem, we expect it to have symptoms that can be detected by data-flow analysis. Although we'll be doing data-flow testing, we won't be using data flow graphs as such. Rather, we'll use an ordinary control flow graph annotated to show what happens to the data objects of interest at the moment. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 28

29. Data Flow Graphs: The data flow graph is a graph consisting of nodes and directed links. We will use a control graph to show what happens to data objects of interest at that moment. Our objective is to expose deviations between the data flows we have and the data flows we want. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 29

30. Data Object State and Usage: Data Objects can be created, killed and used. They can be used in two distinct ways: (1) In a Calculation (2) As a part of a Control Flow Predicate. The following symbols denote these possibilities: Defined: d - defined, created, initialized etc Killed or undefined: k - killed, undefined, released etc Usage: u - used for something (c - used in Calculations, p - used in a predicate) 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 30

31. Defined (d): An object is defined explicitly when it appears in a data declaration. Or implicitly when it appears on the left hand side of the assignment. It is also to be used to mean that a file has been opened. A dynamically allocated object has been allocated. Something is pushed on to the stack. A record written. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 31

32. Killed or Undefined (k): An object is killed on undefined when it is released or otherwise made unavailable. When its contents are no longer known with certitude (with absolute certainty / perfectness). Release of dynamically allocated objects back to the availability pool. Return of records. The old top of the stack after it is popped. An assignment statement can kill and redefine immediately. For example, if A had been previously defined and we do a new assignment such as A : = 17, we have killed A's previous value and redefined A 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 32

33. Usage (u): A variable is used for computation (c) when it appears on the right hand side of an assignment statement. A file record is read or written. It is used in a Predicate (p) when it appears directly in a predicate. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 33

34. Data Flow Anomalies: An anomaly is denoted by a two-character sequence of actions. For example, ku means that the object is killed and then used, where as dd means that the object is defined twice without an intervening usage. What is an anomaly is depend on the application. There are nine possible two-letter combinations for d, k and u. some are bugs, some are suspicious, and some are okay. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 34

35. Data Flow Anomalies: dd :- probably harmless but suspicious. Why define the object twice without an intervening usage? dk :- probably a bug. Why define the object without using it? du :- the normal case. The object is defined and then used. kd :- normal situation. An object is killed and then redefined. kk :- harmless but probably buggy. Did you want to be sure it was really killed? ku :- a bug. the object doesnot exist. ud :- usually not a bug because the language permits reassignment at almost any time. uk :- normal situation. uu :- normal situation. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 35

36. In addition to the two letter situations, there are six single letter situations. We will use a leading dash to mean that nothing of interest ( d,k,u ) occurs prior to the action noted along the entry-exit path of interest. A trailing dash to mean that nothing happens after the point of interest to the exit. They possible anomalies are: -k :- possibly anomalous because from the entrance to this point on the path, the variable had not been defined. We are killing a variable that does not exist. -d :- okay. This is just the first definition along this path. -u :- possibly anomalous. Not anomalous if the variable is global and has been previously defined. k- :- not anomalous. The last thing done on this path was to kill the variable. d- :- possibly anomalous. The variable was defined and not used on this path. But this could be a global definition. u- :- not anomalous. The variable was used but not killed on this path. Although this sequence is not anomalous, it signals a frequent kind of bug. If d and k mean dynamic storage allocation and return respectively, this could be an instance in which a dynamically allocated object was not returned to the pool after use. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 36

37. Data Flow Anomaly State Graph: Data flow anomaly model prescribes that an object can be in one of four distinct states: K :- undefined, previously killed, does not exist D :- defined but not yet used for anything U :- has been used for computation or in predicate A :- anomalous These capital letters (K, D, U, A) denote the state of the variable and should not be confused with the program action, denoted by lower case letters. Unforgiving Data - Flow Anomaly Flow Graph: Unforgiving model, in which once a variable becomes anomalous it can never return to a state of grace. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 37

38. Data Flow Anomaly State Graph: Assume that the variable starts in the K state - that is, it has not been defined or does not exist. If an attempt is made to use it or to kill it (e.g., say that we're talking about opening, closing, and using files and that 'killing' means closing), the object's state becomes anomalous (state A) and, once it is anomalous, no action can return the variable to a working state. If it is defined (d), it goes into the D, or defined but not yet used, state. If it has been defined (D) and redefined (d) or killed without use (k), it becomes anomalous, while usage (u) brings it to the U state. If in U, redefinition (d) brings it to D, u keeps it in U, and k kills it. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 38

39. Forgiving Data - Flow Anomaly Flow Graph Forgiving model is an alternate model where redemption (recover) from the anomalous state is possible. This graph has three normal and three anomalous states and he considers the kk sequence not to be anomalous. A proper action from any of the three anomalous states returns the variable to a useful working state. The point of showing you this alternative anomaly state graph is to demonstrate that the specifics of an anomaly depends on such things as language, application, context, or even your frame of mind. In principle, you must create a new definition of data flow anomaly (e.g., a new state graph) in each situation. You must at least verify that the anomaly definition behind the theory or imbedded in a data flow anomaly test tool is appropriate to your situation. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 39

40. Static Vs Dynamic Anomaly Detection: Static analysis is analysis done on source code without actually executing it. For example: source code syntax error detection is the static analysis result. Dynamic analysis is done on the fly as the program is being executed and is based on intermediate values that result from the program's execution. For example: a division by zero warning is the dynamic result. If a problem, such as a data flow anomaly, can be detected by static analysis methods, then it doesn’t belong in testing - it belongs in the language processor. There is actually a lot more static analysis for data flow analysis for data flow anomalies going on in current language processors. For example, language processors which force variable declarations can detect (-u) and ( ku ) anomalies. But still there are many things for which current notions of static analysis are INADEQUATE. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 40

41. Data Flow Model: The data flow model is based on the program's control flow graph - Don't confuse that with the program's data flow graph. Here we annotate each link with symbols (for example, d, k, u, c, p) or sequences of symbols (for example, dd, du, ddd ) that denote the sequence of data operations on that link with respect to the variable of interest. Such annotations are called link weights. The control flow graph structure is same for every variable: it is the weights that change. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 41

42. Data Flow Model: Data flow testing is a family of test strategies based on selecting paths through the program's control flow in order to explore sequences of events related to the status of variables or data objects. Dataflow Testing focuses on the points at which variables receive values and the points at which these values are used. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 42

43. Flow Graph in Software Testing Flow Graph is defined as a function in a program that can be represented as a control flow graph and the nodes in the flow graph are defined as program statements while the directed edges are the flow of control. A Flow Graph consists of nodes and edges. The two nodes in the Flow Graph can be either unconnected or connected by an edge in either direction or connected by an edge in all directions. While tracing a path from a source to a sink a back edge is an edge that leads back to a node that has already been visited. The Flow Graph contains one source node and one sink. A source node is the node that has no incoming edges while a sink node is the node with no outgoing edges. A program's function may contain more than one sink node, but this graph can be converted into a graph with only one sink. There are some languages that allow more than one source. This construct is very rare and not used in Structured Programming. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 43

44. Data Flow Anomaly State Graph: Used as a main tool for test case identification. Represents the relationship between program segments, that is the sequence of statements having the property that if the first member of the sequence is executed then all other statements in that sequence will also be executed. Nodes represent one program segment. The area bounded by edges and nodes are called regions. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 44

45. Control Flow Testing Control flow testing is a testing technique that comes under white box testing. The aim of this technique is to determine the execution order of statements or instructions of the program through a control structure. The control structure of a program is used to develop a test case for the program. In this technique, a particular part of a large program is selected by the tester to set the testing path. It is mostly used in unit testing. Test cases represented by the control graph of the program. Control Flow Graph is formed from the node, edge, decision node, junction node to specify all possible execution path. Notations used for Control Flow Graph 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 45

46. Notations used for Control Flow Graph Node Edge Decision Node Junction node 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 46

47. Data Flow Anomaly State Graph: Node Nodes in the control flow graph are used to create a path of procedures. Basically, it represents the sequence of procedures which procedure is next to come so, the tester can determine the sequence of occurrence of procedures. We can see below in example the first node represent the start procedure and the next procedure is to assign the value of n after assigning the value there is decision node to decide next node of procedure as per the value of n if it is 18 or more than 18 so Eligible procedure will execute otherwise if it is less than 18 Not Eligible procedure executes. The next node is the junction node, and the last node is stop node to stop the procedure. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 47

48. Edge Edge in control flow graph is used to link the direction of nodes. We can see below in example all arrows are used to link the nodes in an appropriate direction. Decision node Decision node in the control flow graph is used to decide next node of procedure as per the value. We can see below in example decision node decide next node of procedure as per the value of n if it is 18 or more than 18 so Eligible procedure will execute otherwise if it is less than 18, Not Eligible procedure executes. Junction node Junction node in control flow graph is the point where at least three links meet. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 48

49. Diagram - control flow graph STM(Unit 2):-Dr. B.Rajalingam 04-05-2021 49

50. control flow graph The above example shows eligibility criteria of age for voting where if age is 18 or more than 18 so print message "You are eligible for voting" if it is less than 18 then print "You are not eligible for voting." Program for this scenario is written above, and the control flow graph is designed for the testing purpose. In the control flow graph, start, age, eligible, not eligible and stop are the nodes, n>=18 is a decision node to decide which part (if or else) will execute as per the given value. Connectivity of the eligible node and not eligible node is there on the stop node. Test cases are designed through the flow graph of the programs to determine the execution path is correct or not. All nodes, junction, edges, and decision are the essential parts to design test cases. 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 50

51. Flow Graph Symbols Standard notations used in constructing a flow graph are as in the following. To indicate a Sequence: To indicate "IF-THEN-ELSE": To indicate a "WHILE" Loop: To indicate a "Repeat-Until" Loop: To indicate a "CASE" Statement: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 51

52. To indicate a Sequence: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 52

53. To indicate "IF-THEN-ELSE": 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 53

54. To indicate a "WHILE" Loop: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 54

55. To indicate a "Repeat-Until" Loop: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 55

56. To indicate a "Repeat-Until" Loop: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 56

57. On a Flow Graph: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 57 Arrows called edges indicates flow of control. Circles called nodes indicates one or more actions. Areas bounded by edges and nodes are called regions. A predicate node is a node containing a condition.

58. STRATEGIES OF DATA FLOW TESTING: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 58 Data Flow Testing Strategies are structural strategies. In contrast to the path-testing strategies, data-flow strategies take into account what happens to data objects on the links in addition to the raw connectivity of the graph. In other words, data flow strategies require data-flow link weights ( d,k,u,c,p ). Data Flow Testing Strategies are based on selecting test path segments (also called sub paths) that satisfy some characteristic of data flows for all data objects. For example, all subpaths that contain a d (or u, k, du, dk). A strategy X is stronger than another strategy Y if all test cases produced under Y are included in those produced under X - conversely for weaker.

59. TERMINOLOGY: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 59 Definition-Clear Path Segment , with respect to variable X, is a connected sequence of links such that X is (possibly) defined on the first link and not redefined or killed on any subsequent link of that path segment. Loop-Free Path Segment  is a path segment for which every node in it is visited atmost once. Simple path segment  is a path segment in which at most one node is visited twice. A simple path segment is either loop-free or if there is a loop, only one node is involved. A  du path  from node i to k is a path segment such that if the last link has a computational use of X, then the path is simple and definition-clear; if the penultimate (last but one) node is j - that is, the path is ( i,p,q ,..., r,s,t,j,k ) and link ( j,k ) has a predicate use - then the path from i to j is both loop-free and definition-clear.

60. STRATEGIES 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 60 The structural test strategies discussed below are based on the program's control flowgraph. They differ in the extent to which predicate uses and/or computational uses of variables are included in the test set. Various types of data flow testing strategies in decreasing order of their effectiveness are:

61. STRATEGIES 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 61 All - du Paths (ADUP) All Uses Startegy (AU) All p-uses/some c-uses strategy (APU+C) All c-uses/some p-uses strategy (ACU+P) All Definitions Strategy (AD) All Predicate Uses (APU), All Computational Uses (ACU) Strategies

62. All - du Paths (ADUP): 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 62 The all-du-paths (ADUP) strategy is the strongest data-flow testing strategy discussed here. It requires that every du path from every definition of every variable to every use of that definition be exercised under some test. For variable Z: The situation for variable Z (Figure 3.10) is more complicated because the variable is redefined in many places. For the definition on link (1,3) we must exercise paths that include subpaths (1,3,4) and (1,3,5). The definition on link (4,5) is covered by any path that includes (5,6), such as subpath (1,3,4,5,6, ...). The (5,6) definition requires paths that include subpaths (5,6,7,4) and (5,6,7,8). Because V has a predicate use at node 12 and the subsequent path to the end must be forced for both directions at node 12, the all-du-paths strategy for this variable requires that we exercise all loop-free entry/exit paths and at least one path that includes the loop caused by (11,4). Note that we must test paths that include both subpaths (3,4,5) and (3,5) even though neither of these has V definitions. They must be included because they provide alternate du paths to the V use on link (5,6). Although (7,4) is not used in the test set for variable V, it will be included in the test set that covers the predicate uses of array variable V() and U. The all-du-paths strategy is a strong criterion, but it does not take as many tests as it might seem at first because any one test simultaneously satisfies the criterion for several definitions and uses of several different variables.

63. All Uses Startegy (AU): 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 63 The all uses strategy is that at least one definition clear path from every definition of every variable to every use of that definition be exercised under some test. Just as we reduced our ambitions by stepping down from all paths (P) to branch coverage (C2), say, we can reduce the number of test cases by asking that the test set should include at least one path segment from every definition to every use that can be reached by that definition. For variable V:ADUP requires that we include subpaths (3,4,5) and (3,5) in some test because subsequent uses of V, such as on link (5,6), can be reached by either alternative. In AU either (3,4,5) or (3,5) can be used to start paths, but we don't have to use both. Similarly, we can skip the (8,10) link if we've included the (8,9,10) subpath . Note the hole. We must include (8,9,10) in some test cases because that's the only way to reach the c use at link (9,10) - but suppose our bug for variable V is on link (8,10) after all?

64. All p-uses/some c-uses strategy (APU+C) : 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 64 For every variable and every definition of that variable, include at least one definition free path from the definition to every predicate use; if there are definitions of the variables that are not covered by the above prescription, then add computational use test cases as required to cover every definition. For variable Z for APU+C we can select paths that all take the upper link (12,13) and therefore we do not cover the c-use of Z: but that's okay according to the strategy's definition because every definition is covered. Links (1,3), (4,5), (5,6), and (7,8) must be included because they contain definitions for variable Z. Links (3,4), (3,5), (8,9), (8,10), (9,6), and (9,10) must be included because they contain predicate uses of Z. Find a covering set of test cases under APU+C for all variables in this example - it only takes two tests. Note that the c-use at (9,10) need not be included under the APU+C criterion.

65. All c-uses/some p-uses strategy (ACU+P) : 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 65 The all c-uses/some p-uses strategy (ACU+P) is to first ensure coverage by computational use cases and if any definition is not covered by the previously selected paths, add such predicate use cases as are needed to assure that every definition is included in some test. For variable Z: ACU+P coverage is achieved for Z by path (1,3,4,5,6,7,8,10, 11,12,13[lower], 2), but the predicate uses of several definitions are not covered. Specifically, the (1,3) definition is not covered for the (3,5) p-use, the (7,8) definition is not covered for the (8,9), (9,6) and (9, 10) p-uses. The above examples imply that APU+C is stronger than branch coverage but ACU+P may be weaker than, or incomparable to, branch coverage.

66. All Definitions Strategy (AD) : 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 66 The all definitions strategy asks only every definition of every variable be covered by atleast one use of that variable, be that use a computational use or a predicate use. For variable Z: Path (1,3,4,5,6,7,8, . . .) satisfies this criterion for variable Z, whereas any entry/exit path satisfies it for variable V.

67. All Predicate Uses (APU), All Computational Uses (ACU) Strategies : 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 67 The all predicate uses strategy is derived from APU+C strategy by dropping the requirement that we include a c-use for the variable if there are no p-uses for the variable. The all computational uses strategy is derived from ACU+P strategy by dropping the requirement that we include a p-use for the variable if there are no c-uses for the variable. It is intuitively obvious that ACU should be weaker than ACU+P and that APU should be weaker than APU+C.

68. SLICING AND DICING: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 68 A (static) program slice is a part of a program (e.g., a selected set of statements) defined with respect to a given variable X (where X is a simple variable or a data vector) and a statement i: I t is the set of all statements that could (potentially, under static analysis) affect the value of X at statement i - where the influence of a faulty statement could result from an improper computational use or predicate use of some other variables at prior statements. If X is incorrect at statement i , it follows that the bug must be in the program slice for X with respect to i A program dice is a part of a slice in which all statements which are known to be correct have been removed. dice is obtained from a slice by incorporating information obtained through testing or experiment (e.g., debugging). The debugger first limits her scope to those prior statements that could have caused the faulty value at statement i (the slice) and then eliminates from further consideration those statements that testing has shown to be correct. Debugging can be modeled as an iterative procedure in which slices are further refined by dicing, where the dicing information is obtained from ad hoc tests aimed primarily at eliminating possibilities. Debugging ends when the dice has been reduced to the one faulty statement. Dynamic slicing is a refinement of static slicing in which only statements on achievable paths to the statement in question are included.

69. 69 Sub Topic No’s Sub Topic name Lecturer No Slide No’s 1 Introduction L1 3 2 Domains & Paths L2 22 3 Nice Domains L3 28 4 Ugly Domains L4 42 5 Domain Testing L5 51 6 Domains & Interfaces Testing L6 65 7 Domains & Testability L7 70 4 May 2021 STM(Unit 2): Dr. B.Rajalingam

70. What is Domain Testing? 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 70 Domain Testing is a Software Testing process in which the application is tested by giving a minimum number of inputs and evaluating its appropriate outputs. The primary goal of Domain testing is to check whether the software application accepts inputs within the acceptable range and delivers required output. It is a Functional Testing technique in which the output of a system is tested with a minimal number of inputs to ensure that the system does not accept invalid and out of range input values. It is one of the most important White Box Testing methods. It also verifies that the system should not accept inputs, conditions and indices outside the specified or valid range.

71. What is Domain Testing? 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 71 Domain: In mathematics, domain is a set of possible values of an independant variable or the variables of a function. Programs as input data classifiers: domain testing attempts to determine whether the classification is or is not correct. Domain testing can be based on specifications or equivalent implementation information. If domain testing is based on specifications, it is a functional test technique. If domain testing is based implementation details, it is a structural test technique. For example, you're doing domain testing when you check extreme values of an input variable.

72. THE MODEL: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 72 Before doing whatever it does, a routine must classify the input and set it moving on the right path. An invalid input (e.g., value too big) is just a special processing case called 'reject'. The input then passses to a hypothetical subroutine rather than on calculations. In domain testing, we focus on the classification aspect of the routine rather than on the calculations. Structural knowledge is not needed for this model - only a consistent, complete specification of input values for each case. We can infer that for each case there must be atleast one path to process that case.

73. THE MODEL: STM(Unit 2):-Dr. B.Rajalingam 5/4/2021 73

74. A DOMAIN IS A SET: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 74 An input domain is a set. If the source language supports set definitions (E.g. PASCAL set types and C enumerated types) less testing is needed because the compiler does much of it for us. Domain testing does not work well with arbitrary discrete sets of data objects. Domain for a loop-free program corresponds to a set of numbers defined over the input vector.

75. DOMAINS, PATHS AND PREDICATES: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 75 n domain testing, predicates are assumed to be interpreted in terms of input vector variables. If domain testing is applied to structure, then predicate interpretation must be based on actual paths through the routine - that is, based on the implementation control flowgraph. Conversely, if domain testing is applied to specifications, interpretation is based on a specified data flowgraph for the routine; but usually, as is the nature of specifications, no interpretation is needed because the domains are specified directly. For every domain, there is at least one path through the routine. There may be more than one path if the domain consists of disconnected parts or if the domain is defined by the union of two or more domains. Domains are defined their boundaries. Domain boundaries are also where most domain bugs occur. For every boundary there is at least one predicate that specifies what numbers belong to the domain and what numbers don't.

76. A DOMAIN CLOSURE: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 76 A domain boundary is closed with respect to a domain if the points on the boundary belong to the domain. If the boundary points belong to some other domain, the boundary is said to be open.

77. DOMAIN DIMENSIONALITY: 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 77 Every input variable adds one dimension to the domain. One variable defines domains on a number line. Two variables define planar domains. Three variables define solid domains. Every new predicate slices through previously defined domains and cuts them in half. Every boundary slices through the input vector space with a dimensionality which is less than the dimensionality of the space. Thus, planes are cut by lines and points, volumes by planes, lines and points and n-spaces by hyperplanes.

78. STM(Unit 2): Dr. B.Rajalingam 78 Domain Testing - Domains & Paths Domain Testing Model INPUT CLASSIFY DO CASE 1 OUTPUT DO CASE 2 DO CASE 3 DO CASE n D1 D3 (x,y,z,…) (1, 2, 3, 4, 5,…) { Outcome } D2 Dn 4 May 2021

79. STM(Unit 2): Dr. B.Rajalingam 79 Domain Testing Domain Testing Views Programs as input data classifiers Verifies if the classification is correct 4 May 2021

80. STM(Unit 2): Dr. B.Rajalingam 80 Domain Testing - Domains & Paths Domain Testing Model Two Views Based on Specs Functional Testing Based on Implementation information Structural Technique 4 May 2021

81. STM(Unit 2): Dr. B.Rajalingam 81 Domain Testing - Domains & Paths Domain Testing Model Variables Simple combinations of two variables Numbers from -  to + Input variables as numbers Loop-free Programs 4 May 2021

82. STM(Unit 2): Dr. B.Rajalingam 82 Domain Testing - Domains & Paths Domain Testing Model Structural Knowledge is not needed. Only Specs. For each Input Case, A Hypothetical path for Functional testing An Actual path for Structural testing 4 May 2021

83. STM(Unit 2): Dr. B.Rajalingam 83 Domain Testing - Domains & Paths Domain (simplified) A Single Connected Set of numbers No arbitrary discrete sets Defined by the boundaries One or more boundaries Specified by predicates Bugs likely at the boundaries One or more variables D1 4 May 2021

84. STM(Unit 2): Dr. B.Rajalingam 84 Domain Testing - Domains & Paths Predicates Interpretation Structural Testing - CFG Functional Testing - DFG Specifies the Domain Boundary n Predicates in Sequence  2 n domains Or, just two domains A .AND. B .AND. C 4 May 2021

85. STM(Unit 2): Dr. B.Rajalingam 85 Domain Testing - Domains & Paths Paths At least One PATH thru the Program More paths for disconnected domains 4 May 2021

86. STM(Unit 2): Dr. B.Rajalingam 86 Domain Testing - Domains & Paths Summary: Domain for a loop-free program corresponds to a set of numbers defined over the input vector For every domain, there is at least one path thru the routine, along which that domain’s processing is done The set of interpreted predicates traversed on that path (ie., the path’s predicate expression ) defines the domain’s boundaries. 4 May 2021

87. STM(Unit 2): Dr. B.Rajalingam 87 Domain Testing - Domains & Paths - Domain Closure Boundary: Closed / Open MIN MAX D1 D2 D3 X < MAX X >= MIN MIN MAX D1 D2 D3 X >= MIN X <= MAX Closed Closed Open 4 May 2021

88. STM(Unit 2): Dr. B.Rajalingam 88 Domain Testing - Domains & Paths - Domain Closure Boundary: Closed / Open MIN MAX D1 D2 D3 X > MIN X < MAX Open 4 May 2021

89. STM(Unit 2): Dr. B.Rajalingam 89 Domain Testing - Domains & Paths - Domain Dimensionality One dimension per variable At least one predicate Slices thru previously defined Domain Slicing Boundary N-spaces are cut by Hyperplanes 4 May 2021

90. STM(Unit 2): Dr. B.Rajalingam 90 Domain Testing - Domains & Paths – Bug Assumptions Processing is OK. Domain definition may be wrong.  Boundaries are wrong.  Predicates are wrong. Once input vector is set on the right path, it’s correctly processed. More bugs causing domain errors … 4 May 2021

91. STM(Unit 2): Dr. B.Rajalingam 91 Domain Testing - Domains & Paths – Bug Assumptions .. Double-zero representation Floating point zero check Contradictory domains Ambiguous domains defined undefined 4 May 2021

92. STM(Unit 2): Dr. B.Rajalingam 92 Domain Testing - Domains & Paths – Bug Assumptions .. Over-specified domains Boundary errors Boundary closure Shifted X > 3 .AND. X < 2 .AND. Y > 3 4 May 2021

93. STM(Unit 2): Dr. B.Rajalingam 93 Domain Testing - Domains & Paths - Bug Assumptions Boundary errors…. T ilted Missing Extra boundary 4 May 2021

94. STM(Unit 2): Dr. B.Rajalingam 94 U3 Closure Reversal Faulty Logic Simplification of compound predicates X >= 3 Domain Testing - Domains & Paths - Bug Assumptions 4 May 2021

95. STM(Unit 2): Dr. B.Rajalingam 95 Domain Testing - Domains & Paths - Bug Assumptions Strategy for domain testing in 2-dim 4 May 2021

96. STM(Unit 2): Dr. B.Rajalingam 96 Domain Testing - Domains & Paths - Restrictions In General… Coincidental Correctness DT cannot detect Example Representative outcome Partition testing Input Equivalence D1 D2 F1(x) : +1 F2(x) : -1 4 May 2021

97. STM(Unit 2): Dr. B.Rajalingam 97 Domain Testing - Domains & Paths Domain Testing Model INPUT CLASSIFY DO CASE 1 OUTPUT DO CASE 2 DO CASE 3 DO CASE n D1 D3 (x, y, z, …) (1, 2, 3, 4, 5,…) { Outcome } D2 Dn Function f1 f2 f3 f4 4 May 2021

98. STM(Unit 2): Dr. B.Rajalingam 98 Domain Testing - Domains & Paths - - Restrictions Simple boundaries & Compound predicates X 16 X >=0 .AND. X <= 16 Y = 1 .AND. X >=0 .AND. X <= 16 X 16 Y D1 D1 4 May 2021

99. STM(Unit 2): Dr. B.Rajalingam 99 Domain Testing - Domains & Paths - - Restrictions Compound predicates…. Impact of .OR. Concave, Disconnected Adjacent domains with same function Example A B C + D E F Eliminate compound predicates 4 May 2021

100. STM(Unit 2): Dr. B.Rajalingam 100 Domain Testing - Domains & Paths - Restrictions Functional Homogeneity of Bugs Functional form still Retained a x + b y >= c Bugs are only in a, b, c 4 May 2021

101. STM(Unit 2): Dr. B.Rajalingam 101 Domain Testing - Domains & Paths - - Restrictions Linear Vector Space Linear boundary predicate, Interpreted Simple relational operators Conversion to linear vector space 2-d Polar co-ordinates Polynomials Problems with Non-linear Boundaries 4 May 2021

102. STM(Unit 2): Dr. B.Rajalingam 102 Domain Testing - Domains & Paths - Restrictions Loop-free Software Predicate for each iteration Loop over the entire transaction Definite loop 4 May 2021

103. STM(Unit 2): Dr. B.Rajalingam 103 Domain Testing - Domains & Paths – Nice & Ugly domains Nice Domains Requirements Bugs  ill-defined domains Before DT Analyze specs Make the Boundary Specs Consistent & Complete 4 May 2021

104. STM(Unit 2): Dr. B.Rajalingam 104 Domain Testing - Domains & Paths – Nice domains Implemented Domains Complete, Consistent & Process all inputs Specified Domains Incomplete, Inconsistent Programmer’s / Designer’s Effort 4 May 2021

105. STM(Unit 2): Dr. B.Rajalingam 105 Domain Testing - Domains & Paths – Nice domains Nice Domains Linear, Complete, Systematic, Orthogonal, Consistently Closed, & Convex U1 U2 V1 V2 D11 D12 D21 D22 4 May 2021

106. STM(Unit 2): Dr. B.Rajalingam 106 Domain Testing - Domains & Paths – Nice domains Nice Domains Advantages Ease of DT Fewer Bug Occurrences 4 May 2021

107. STM(Unit 2): Dr. B.Rajalingam 107 Domain Testing - Domains & Paths – Nice domains Nice Domains Boundaries are 1. Linear 2. Complete 3. Systematic 4. Orthogonal Closure consistency Convex Simply connected 4 May 2021

108. STM(Unit 2): Dr. B.Rajalingam 108 Domain Testing - Domains & Paths – Nice domains Linear Boundaries Interpreted linear inequalities n-dim Hyperplane: n+1 Points n+1 + 1 Test Cases Non-Linear Transform 4 May 2021

109. STM(Unit 2): Dr. B.Rajalingam 109 Domain Testing - Domains & Paths – Nice domains Complete Boundaries Span the total number space (- , +) One set of Tests Incomplete… Reasons Tests 4 May 2021

110. STM(Unit 2): Dr. B.Rajalingam 110 Domain Testing - Domains & Paths - Nice domains Systematic Boundaries Linear Inequalities differing by a constant f j (X) ≥ k j or, f j (X) ≥ g (j, c) g (j, c) = j + k * c Parallel lines Identical Sectors in a Circle DT Test a domain  Tests for other Domains 4 May 2021

111. STM(Unit 2): Dr. B.Rajalingam 111 Domain Testing - Domains & Paths - Nice domains Orthogonal Boundaries Two boundaries or, boundary sets Parallel to axes DT Each Set Independently # Tests  O (n) Uj Vj 4 May 2021

112. STM(Unit 2): Dr. B.Rajalingam 112 Domain Testing - Domains & Paths - Nice domains Orthogonal Boundaries Tilted sets transformation Test cases: O(n) Concentric circles with radial lines Rectangular coordinates Polar r ≥ a j .AND. r < a j+1 .AND. ≥  j .AND.  <  j+1 4 May 2021

113. STM(Unit 2): Dr. B.Rajalingam 113 Domain Testing - Domains & Paths - Nice domains Non-Orthogonal Boundaries Test Intersections  O ( n 2 ) + O (n) 4 May 2021

114. STM(Unit 2): Dr. B.Rajalingam 114 Domain Testing - Domains & Paths - Nice domains Closure Consistency A Simple pattern in all boundary closures Example Same relational operator for systematic boundaries D1 D2 D3 D4 4 May 2021

115. STM(Unit 2): Dr. B.Rajalingam 115 Domain Testing - Domains & Paths - Nice domains Convex Domain Line joining any two points lies with in the domain DT n on-points & 1 off-pt Concave “ But, However, Except, Or … “ in Specs Handle with special care 4 May 2021

116. STM(Unit 2): Dr. B.Rajalingam 116 Domain Testing - Domains & Paths - Nice domains Simply Connected Domain In a single piece 2 complementary domains D1: Convex  D2: Concave, not-Connected Programmer / Designer Convex part First D1 D2 D1 D2 D3 4 May 2021

117. STM(Unit 2): Dr. B.Rajalingam 117 Domain Testing - Domains & Paths – Ugly Domains Generally, From Bad Specs Programmer / Designer Simplifies => Ugly to Good possibility of Introduction of more bugs ?!? 4 May 2021

118. STM(Unit 2): Dr. B.Rajalingam 118 Domain Testing - Domains & Paths – Ugly Domains Causes Non-linear Boundaries Ambiguities & Contradictions Simplifying the topology Rectifying boundary closures 4 May 2021

119. STM(Unit 2): Dr. B.Rajalingam 119 Domain Testing - Domains & Paths – Ugly Domains Non-linear Boundaries Transform 4 May 2021

120. STM(Unit 2): Dr. B.Rajalingam 120 Domain Testing - Domains & Paths – Ugly Domains Ambiguities Holes in input vector space. Missing boundary Detected by Specification languages & tools. 4 May 2021

121. STM(Unit 2): Dr. B.Rajalingam 121 Domain Testing - Domains & Paths – Ugly Domains Contradictions.. Overlapping of Domain Specs Closure Specs D1 D2 D3 4 May 2021

122. STM(Unit 2): Dr. B.Rajalingam 122 Domain Testing - Domains & Paths – Ugly Domains Simplifying the Topology…. Complexity ! Concavity, Holes, Disconnectedness 4 May 2021

123. STM(Unit 2): Dr. B.Rajalingam 123 Domain Testing - Domains & Paths – Ugly Domains Simplifying the Topology…. Smoothing out concavity Filling in Holes 4 May 2021

124. STM(Unit 2): Dr. B.Rajalingam 124 Domain Testing - Domains & Paths – Ugly Domains Simplifying the Topology…. Joining the pieces Correct: Connect disconnected boundary segments Extend boundaries to infinity 4 May 2021

125. STM(Unit 2): Dr. B.Rajalingam 125 Domain Testing - Domains & Paths – Ugly Domains Rectifying Boundary Closures. make closures in one direction for parallel boundaries with closures in both directions Force a Bounding Hyperplane to belong to the Domain. Consistent Direction Inclusion / Exclusion Consistency 4 May 2021

126. STM(Unit 2): Dr. B.Rajalingam 126 Domain Testing - Domains & Paths – Domain Testing General DT Strategy Select test points near the boundaries. Define test strategy for each possible bug related to boundary Test points for a domain useful to test its adjacent domain. Run the tests. By post test analysis determine if any boundaries are faulty & if so how? Run enough tests to verify every boundary of every domain 4 May 2021

127. STM(Unit 2): Dr. B.Rajalingam 127 Domain Testing - Domains & Paths – Domain Testing DT for Specific Domain Bugs Generally, Interior point Exterior point Epsilon neighborhood Extreme point On point 4 May 2021

128. STM(Unit 2): Dr. B.Rajalingam 128 Domain Testing - Domains & Paths – Domain Testing DT for Specific Domain Bugs Domain D1 Epsilon neighborhood Boundary point Extreme point On Points Off Points 4 May 2021

129. STM(Unit 2): Dr. B.Rajalingam 129 Domain Testing - Domains & Paths – Domain Testing 1-d Domains 2-d Domains Equality & inequality Predicates Random Testing Testing n-dimensional Domains 4 May 2021

130. STM(Unit 2): Dr. B.Rajalingam 130 Domain Testing - Domains & Paths – Domain Testing Testing 1-d Domains : Bugs with open boundaries A B x A B x A B x x1 A B x x1 Closure Bug Shift left Bug Shift Right Bug 4 May 2021

131. STM(Unit 2): Dr. B.Rajalingam 131 Domain Testing - Domains & Paths – Domain Testing A B x Missing Boundary A B x x Extra Boundary A B x1 x C x x Testing 1-d Domains : Bugs with open boundaries Bugs with Closed Boundaries : Similar to the above 4 May 2021

132. STM(Unit 2): Dr. B.Rajalingam 132 Domain Testing - Domains & Paths – Domain Testing Testing 2-d Domains Closure bug Boundary Shift : up / down Tilted Boundary Extra Boundary Missing Boundary 4 May 2021

133. STM(Unit 2): Dr. B.Rajalingam 133 Domain Testing - Domains & Paths – Domain Testing Strategy for domain testing in 2-dim 2 n : Domains share tests 3 n : no sharing of tests by domains 4 May 2021

134. STM(Unit 2): Dr. B.Rajalingam 134 Domain Testing - Domains & Paths – Domain Testing Equality & Inequality Predicates An Equality predicate defines a line in 2-d c’ c c A B a d b To avoid bugs 4 May 2021

135. STM(Unit 2): Dr. B.Rajalingam 135 Domain Testing - Domains & Paths – Domain Testing Random Testing A Point in the center : verifies computation 4 May 2021

136. STM(Unit 2): Dr. B.Rajalingam 136 Domain Testing - Domains & Paths – Domain Testing Testing n-Dimensional Domains (strategy) n-dimensions, p boundary segments (n+1)*p test cases : n on points & 1 off point Extreme pt shared : 2 * p points Equalities over m-dimensions create a subspace of n-m dimensions Orthogonal domains with consistent boundary closures, orthogonal to the axes & complete boundaries Independent testing 4 May 2021

137. STM(Unit 2): Dr. B.Rajalingam 137 Domain Testing - Domains & Paths – Domain Testing L5 Procedure for solving for values Simple procedure. Need tools. Identify input variables Identify variables which appear in domain-defining predicates, such as control-flow predicates 4 May 2021

138. STM(Unit 2): Dr. B.Rajalingam 138 Domain Testing - Domains & Paths – Domain Testing L5 Procedure Interpret all domain predicates in terms of input variables: Transform non-linear to linear Find data flow path Predicate expression with p # predicates. Find # domains : < 2 p Solve inequalities for extreme points Use extreme points to solve for nearby on points … 4 May 2021

139. STM(Unit 2): Dr. B.Rajalingam 139 Domain Testing L5 Effectiveness Cost effective Bugs on boundaries, extreme points Hardware logic testing – tool intensive 4 May 2021

140. STM(Unit 2): Dr. B.Rajalingam 140 Domain Testing L6 Domains & Interface Testing Domain Range Function / Routine Classify Domain Variable Range 4 May 2021

141. STM(Unit 2): Dr. B.Rajalingam 141 Domain Testing L6 Domains & Interface Testing Span compatibility Routine 2 Routine 1 Domain Variable Range for Routine2 Domain for Routine2 Range for Routine1 4 May 2021

142. STM(Unit 2): Dr. B.Rajalingam 142 Domain Testing L6 Interface Range/Domain Compatibility Testing Test each var independently Find an inverse function Build a super domain 4 May 2021

143. STM(Unit 2): Dr. B.Rajalingam 143 Domain Testing L7 Domains and Testability Linearizing transformations Polynomial Rectangular to polar Generic & rational => Taylor series 4 May 2021

144. STM(Unit 2): Dr. B.Rajalingam 144 Domain Testing L7 Domains and Testability Perform transformations for better testing. Co-ordinate transformations 4 May 2021

145. STM(Unit 2): Dr. B.Rajalingam 145 Domain Testing L7 Domains and Testability Canonical Program Form 4 May 2021

146. Thank you 04-05-2021 STM(Unit 2):-Dr. B.Rajalingam 146