Software Engineering Chapter 23 Software Testing Ku-Yaw Chang Assistant Professor Department of Computer Science and Information Engineering Da-Yeh University

2Ku-Yaw ChangSoftware Testing Objectives Understand the distinctions between validation testing and defect testing; Understand the principles of system testing and component testing; Understand three strategies that may be used to generate system test cases; Understand the essential characteristics of software tools that support test automation

3Ku-Yaw ChangSoftware Testing Preamble Two distinct goals To demonstrate to the developer and the customer that the software meets its requirements. To demonstrate to the developer and the customer that the software meets its requirements. Validation test To discover faults or defects in the software where the behavior of the software is incorrect, undesirable or does not conform to its specification. To discover faults or defects in the software where the behavior of the software is incorrect, undesirable or does not conform to its specification. Defect testing Testing can only show the presence of errors, not their absence – Edsger Dijkstra

4Ku-Yaw ChangSoftware Testing Preamble An abstract view of software testing Component testing Component testing Testing the parts of the system System testing System testing Testing the system as a whole

5Ku-Yaw ChangSoftware Testing A Model of the Software Testing Processing

6Ku-Yaw ChangSoftware Testing Preamble Exhaustive testing is impossible Every possible program execution sequence is tested Every possible program execution sequence is tested

7Ku-Yaw ChangSoftware Testing Contents 23.1 System testing 23.2 Component testing 23.3 Test case design 23.4 Test automation

8Ku-Yaw ChangSoftware Testing System Testing Integrate two or more components Testing this integrated system Testing this integrated system Two distinct phases Integration testing Integration testing Access to the source code Find the source of the problem Identify the components Identify the components Find defects in the system Release testing Release testing Validating that the system meets its requirements Black-box testing Black-box testing Also called acceptance testing, if customers are involved

9Ku-Yaw ChangSoftware Testing Integration Testing A major problem - localizing errors Hard to identify where the error occurred Hard to identify where the error occurred An incremental approach Initially, integrate a minimal system configuration and test this system Initially, integrate a minimal system configuration and test this system Add components and test after each added increment Add components and test after each added increment Regression testing Rerun an existing set of tests Rerun an existing set of tests

10Ku-Yaw ChangSoftware Testing Incremental Integration Testing

11Ku-Yaw ChangSoftware Testing Release Testing Primary goal Increase the supplier’s confidence that the system meets its requirements Increase the supplier’s confidence that the system meets its requirements A black-box testing System behavior can be determined by studying its inputs and related outputs System behavior can be determined by studying its inputs and related outputs Also called functional testing Also called functional testing

12Ku-Yaw ChangSoftware Testing Black-box Testing

13Ku-Yaw ChangSoftware Testing Guidelines Choose inputs that force the system to generate all error messages Design inputs that cause input buffers to overflow Repeat the same input or series of inputs numerous times Force computation results to be too large or too small

14Ku-Yaw ChangSoftware Testing Performance Testing Test the system for emergent properties after completely integrated Performance Performance Reliability Reliability Performance tests Ensure the system can process its intended load Ensure the system can process its intended load

15Ku-Yaw ChangSoftware Testing Performance Testing Construct an operational profile A set of tests that reflect the actual mix of work A set of tests that reflect the actual mix of work Stress testing Making demands that are outside the design limits of the software Making demands that are outside the design limits of the software Be particular relevant to distributed systems based on a network of processors Be particular relevant to distributed systems based on a network of processors

16Ku-Yaw ChangSoftware Testing Performance Testing Two functions of the stress testing It tests the failure behavior of the system It tests the failure behavior of the system It stresses the system and may cause defects of come to light that would not normally be discovered. It stresses the system and may cause defects of come to light that would not normally be discovered.

17Ku-Yaw ChangSoftware Testing Contents 23.1 System testing 23.2 Component testing 23.3 Test case design 23.4 Test automation

18Ku-Yaw ChangSoftware Testing Component Testing The process of testing individual components in the system Also called unit testing Also called unit testingGoal To expose faults in these components To expose faults in these components For most systems Developers are responsible for component testing Developers are responsible for component testing

19Ku-Yaw ChangSoftware Testing Component Testing Three types of components Individual functions or methods within an object Individual functions or methods within an object Object classes that have several attributes and methods Object classes that have several attributes and methods Composite components made up of several different objects or functions. Composite components made up of several different objects or functions.

20Ku-Yaw ChangSoftware Testing Contents 23.1 System testing 23.2 Component testing 23.3 Test case design 23.4 Test automation

21Ku-Yaw ChangSoftware Testing Test Case Design Design test cases (inputs and predicted outputs) to test the system System testing System testing Component testing Component testingGoal Create a set of test cases Create a set of test cases Discover program defects Show that the system meets its requirements

22Ku-Yaw ChangSoftware Testing Test Case Design Approaches to test case design Requirement-based testing Requirement-based testing Test the system requirement Mostly at the system-testing stage Mostly at the system-testing stage Partition testing Partition testing Identify input and output partitions Execute inputs from all partitions Execute inputs from all partitions Generate outputs in all partitions Generate outputs in all partitions Structured testing Structured testing Exercise all parts of the program

23Ku-Yaw ChangSoftware Testing Requirement-based Testing Testing a requirement does not mean just writing a single test Normally several tests are required Normally several tests are required e.g. The user shall be able to search either all of the initial set of databases or select a subset from it. e.g. The user shall be able to search either all of the initial set of databases or select a subset from it. One database Two databases More than two databases A validation test Rather than a defect testing Rather than a defect testing

24Ku-Yaw ChangSoftware Testing Partition Testing The input data and output results fall into a number of different classes Positive numbers Positive numbers Negative numbers Negative numbers Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member Test cases should be chosen from each partition Test cases should be chosen from each partition

25Ku-Yaw ChangSoftware Testing Partition Testing

26Ku-Yaw ChangSoftware Testing Partition Testing Identify partitions by using the program specification or user documentation A program accepts 4 to 10 inputs that are five-digit integers greater than 10,000 A program accepts 4 to 10 inputs that are five-digit integers greater than 10,000 A good rule of thumb A good rule of thumb Boundaries of the partitions Cases close to the mid-point of the partition

27Ku-Yaw ChangSoftware Testing Partition Testing

28Ku-Yaw ChangSoftware Testing Structural Testing To exercise all program statements not all path combinations not all path combinations Test case design Derived from knowledge of the software’s structure and implementation Derived from knowledge of the software’s structure and implementation Also called Also called ‘white-box’ testing ‘glass-box’ testing ‘clear-box’ testing

29Ku-Yaw ChangSoftware Testing Contents 23.1 System testing 23.2 Component testing 23.3 Test case design 23.4 Test automation

The End