SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Professor SRM University, Kattankulathur

Transcription

1 SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Professor SRM University, Kattankulathur School of Computing, Department of IT 1

2 School of Computing, Department 2 SOFTWARE TESTING What is it? Who does it? Why is it important? What are the steps? What is the work product?

3 Intention of testing is finding error A good test case has a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an asyet undiscovered error. School of Computing, Department 3 TESTING OBJECTIVES

4 School of Computing, Department 4 TESTING PRINCIPLES All tests should be traceable to customer requirements Tests should be planned long before testing begins The Pareto principle applies to software testing. Testing should begin in the small and progress toward testing in the large. Exhaustive testing is not possible. Independent third party testing

5 School of Computing, Department 5 TESTABILITY CHECKLISt Operability Observability Controllability Decomposability Simplicity Stability

6 School of Computing, Department 6 WHITE BOX TESTING Exercise all independent paths Exercise all logical decisions on their true and false sides Execute all loops at their boundaries and within their operational bounds Exercise internal data structures to

7 School of Computing, Department 7 WHY WHITE BOX TESTING? Logic errors/incorrect assumptions are inversely proportional to the probability that a program path will be executed. A logical path that is assumed as not likely to be executed in fact, may be executed on a regular basis. Typographical errors are random

8 School of Computing, Department 8 BASIS PATH TESTING Basis path testing is a white box testing technique first proposed by Tom McCabe Helps derive a logical complexity measure of a procedural design. Use this measure as a guide for defining a basis set of execution paths.

9 School of Computing, Department 9 FLOW GRAPH NOTATION Graphical representation of Logical Control Flow

10 statements or a new condition. School of Computing, Department 10 CYCLOMATIC COMPLEXITY Value computed for cyclomatic complexity defines the number of independent paths and an upper bound for the number of tests for coverage of all statements. An independent path is any path that introduces at least one new set of processing

11 EXAMPLE School of Computing, Department 11

12 edge) between nodes. School of Computing, Department 12 GRAPH MATRICES A graph matrix is a square matrix whose size (i.e., number of rows and columns)is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node Matrix entries correspond to connections (an

13 EXAMPLE School of Computing, Department 13

14 CONNECTION MATRIX School of Computing, Department 14

15 Relational operator error. School of Computing, Department 15 CONDITION TESTING Method that exercises the logical conditions Types of error Boolean operator error (incorrect/missing/extra Boolean operators). Boolean variable error. Boolean parenthesis error.

16 DATA FLOW TESTING Method selects test paths of a program according to the locations of definitions and uses of variables in the program. Example DEF(S) = {X statement S contains a definition of X} USE(S) = {X statement S contains a use of X} Definition use (DU) chain of variable X is of the form [X, S, S'], where S and S' are statement numbers, X is in DEF(S) and USE(S'), and the School of Computing, Department 16

17 School of Computing, Department 17 LOOP TESTING White box testing technique that focuses exclusively on the validity of loop constructs. Complex loop structures are another hiding place for bugs.

18 CLASSIFICATION School of Computing, Department 18

19 BLACK BOX TESTING Also called behavioral testing, focuses on the functional requirements Not an alternative to white box testing Attempts to find errors in five categories Incorrect or missing functions Interface errors Errors in data structures or external data base access, Behavior or performance errors Initialization and termination errors. School of Computing, Department 19

20 School of Computing, Department 20 GRAPH BASED TESTING A graph represents the relationships between data objects and program objects Enables us to derive test cases that search for errors associated with these relationships.

21 GRAPH BASED TESTING School of Computing, Department 21

22 School of Computing, Department 22 GRAPH BASED TESTING Transaction Flow Modeling Finite State Modeling Data Flow Modeling Timing Modeling

23 School of Computing, Department 23 EQUIVALANCE PARTITIONING Black box testing method that divides the input domain into classes of data from which test cases are derived. Test case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition

24 EQUIVALANCE PARTITIONING Guidelines If an input condition specifies a range, one valid and two invalid equivalence classes are defined. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined. If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined. If an input condition is Boolean, one valid and one invalid class are defined. School of Computing, Department 24

25 BOUNDARY VALUE ANALYSIS Test cases that exercise bounding values If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b. If an input condition specifies a number of values, test cases exercise the minimum and maximum numbers and just above and below minimum and maximum. Apply previous two steps to outputs School of Computing, Department 25

26 COMPARISON TESTING When multiple implementations of the same specification have been produced, test cases designed using other black box techniques are provided as input to each version of the software. If the output from each version is the same, it is assumed that all implementations are correct. If the output is different, each of the applications is investigated to determine if a School of Computing, Department 26

27 School of Computing, Department 27 ORTHOGONAL ARRAY TESTING Orthogonal array testing enables you to design test cases that provide maximum test coverage with a reasonable number of test cases.

28 School of Computing, Department 28 UNIT TESTING Verification of smallest unit module or component White box oriented The relative complexity of tests and uncovered errors is limited by the constrained scope established for unit testing.

29 UNIT TESTING CONSIDERATIONS School of Computing, Department 29

30 them. School of Computing, Department 30 UNIT TESTING PROCEDURES Drivers Stubs During situations in which you will not have the resources to do comprehensive unit testing. Select critical modules and those with high cyclomatic complexity and unit test only

31 that has been dictated by design. School of Computing, Department 31 INTEGRATION TESTING Systematic technique for constructing the program structure While at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure

32 School of Computing, Department 32 TOP DOWN INTEGRATION A top module is tested with stubs B F G D C E stubs are replaced one at a time, "depth first" as new modules are integrated, some subset of tests is re-run

33 School of Computing, Department 33 BOTTOM UP INTEGRATION A B F G C drivers are replaced one at a time, "depth first" D E worker modules are grouped into builds and integrated cluster

34 School of Computing, Department 34 REGRESSION TESTING Regression testing is an important strategy for reducing side effects. Run regression tests every time a major change is made to the software (including the integration of new module)

35 The build is integrated with other builds and School of Computing, Department 35 SMOKE TESTING STEPS Software components that have been translated into code are integrated into a build. functions. A series of tests is designed to expose errors that will keep the build from properly performing its function.

36 School of Computing, Department 36 VALIDATION TESTING Focus is at the requirements level on things that will be immediately apparent to the enduser. Configuration Review review all elements of SC.

37 ALPHA AND BETA TESTING The alpha test is conducted at the developer's site by a customer. Alpha tests are conducted in a controlled environment. The beta test is conducted at one or more customer sites by the end user of the software. Unlike alpha testing, the developer is generally not present. T Beta test is a "live" application of the software in an uncontrolled environment. School of Computing, Department 37

38 Ultimately, when software is incorporated with other system elements (e.g., hardware, people, information), a series of system integration and validation tests are conducted. A series of different tests whose primary purpose is to fully exercise the computerbased system School of Computing, Department 38 SYSTEM TESTING

39 Restart School of Computing, Department 39 RECOVERY TESTING System test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. Reinitialization, Check pointing mechanisms, Data recovery,

40 School of Computing, Department 40 SECURITY TESTING Attempts to verify if protection mechanisms built into a system will protect it from improper penetration. System designer should make penetration cost more than information cost.

41 School of Computing, Department 41 STRESS TESTING Executes a system in a manner that demands resources in abnormal quantity, frequency, or volume Sensitivity testing attempts to uncover data combinations within valid input classes that may cause instability or improper processing.

42 Sample machine states on a regular basis. School of Computing, Department 42 PERFORMANCE TESTING Performance tests are often coupled with stress testing and usually require both hardware and software instrumentation. Resource utilization (e.g., processor cycles) Execution intervals Log events (e.g., interrupts) as they occur,

43 School of Computing, Department 43 bibliography Software Engineering, Roger Pressman, Fifth Edition Software Engineering, Ian Sommerville, Sixth Edition

44 School of Computing, Department 44 Review questions What is Pareto principle? Is graph based testing a black box or white box testing technique? What is an independent path? What testing concentrates on identifying only the show stopper defects? Is beta testing done in presence of the customer?