Presentation is loading. Please wait.

Presentation is loading. Please wait.

Slide 1 การทดสอบโปรแกรม กระบวนการในการทดสอบ กระบวนการในการหาข้อผิดพลาดของ โปรแกรม กลยุทธ์การทดสอบ เครื่องมือช่วยในการทดสอบ แบบต่าง ๆ ของการทดสอบ.

Similar presentations


Presentation on theme: "Slide 1 การทดสอบโปรแกรม กระบวนการในการทดสอบ กระบวนการในการหาข้อผิดพลาดของ โปรแกรม กลยุทธ์การทดสอบ เครื่องมือช่วยในการทดสอบ แบบต่าง ๆ ของการทดสอบ."— Presentation transcript:

1 Slide 1 การทดสอบโปรแกรม กระบวนการในการทดสอบ กระบวนการในการหาข้อผิดพลาดของ โปรแกรม กลยุทธ์การทดสอบ เครื่องมือช่วยในการทดสอบ แบบต่าง ๆ ของการทดสอบ

2 Slide 2 Testing phases

3 Slide 3 The defect testing process

4 Slide 4 Black-box testing

5 Slide 5 Equivalence partitioning

6 Slide 6 l Partition system inputs and outputs into ‘equivalence sets’ If input is a 5-digit integer between 10,000 and 99,999, equivalence partitions are 10, 000 l Choose test cases at the boundary of these sets 00000, 09999, 10000, 99999, Equivalence partitioning

7 Slide 7 Equivalence partitions

8 Slide 8 White-box testing

9 Slide 9 Path testing l The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once l The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control l Statements with conditions are therefore nodes in the flow graph

10 Slide 10 l Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition node l Used as a basis for computing the cyclomatic complexity l Cyclomatic complexity = Number of edges - Number of nodes +2 Program flow graphs

11 Slide 11 l The number of tests to test all control statements equals the cyclomatic complexity l Cyclomatic complexity equals number of conditions in a program l Useful if used with care. Does not imply adequacy of testing. l Although all paths are executed, all combinations of paths are not executed Cyclomatic complexity

12 Binary search flow graph

13 Slide 13 l 1, 2, 3, 8, 9 l 1, 2, 3, 4, 6, 7, 2 l 1, 2, 3, 4, 5, 7, 2 l 1, 2, 3, 4, 6, 7, 2, 8, 9 l Test cases should be derived so that all of these paths are executed l A dynamic program analyser may be used to check that paths have been executed Independent paths

14 Slide 14 Integration testing l Tests complete systems or subsystems composed of integrated components l Integration testing should be black-box testing with tests derived from the specification l Main difficulty is localising errors l Incremental integration testing reduces this problem

15 Slide 15 Incremental integration testing

16 Slide 16 Approaches to integration testing l Top-down testing Start with high-level system and integrate from the top-down replacing individual components by stubs where appropriate l Bottom-up testing Integrate individual components in levels until the complete system is created l In practice, most integration involves a combination of these strategies

17 Slide 17 Top-down testing

18 Slide 18 Bottom-up testing

19 Slide 19 Tetsing approaches l Architectural validation Top-down integration testing is better at discovering errors in the system architecture l System demonstration Top-down integration testing allows a limited demonstration at an early stage in the development l Test implementation Often easier with bottom-up integration testing l Test observation Problems with both approaches. Extra code may be required to observe tests

20 Slide 20 l Takes place when modules or sub-systems are integrated to create larger systems l Objectives are to detect faults due to interface errors or invalid assumptions about interfaces l Particularly important for object-oriented development as objects are defined by their interfaces Interface testing

21 Slide 21 Interface testing

22 Slide 22 Interfaces types l Parameter interfaces Data passed from one procedure to another l Shared memory interfaces Block of memory is shared between procedures l Procedural interfaces Sub-system encapsulates a set of procedures to be called by other sub-systems l Message passing interfaces Sub-systems request services from other sub-systems

23 Slide 23 Interface errors l Interface misuse A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order l Interface misunderstanding A calling component embeds assumptions about the behaviour of the called component which are incorrect l Timing errors The called and the calling component operate at different speeds and out-of-date information is accessed

24 Slide 24 Interface testing guidelines l Design tests so that parameters to a called procedure are at the extreme ends of their ranges l Always test pointer parameters with null pointers l Design tests which cause the component to fail l Use stress testing in message passing systems l In shared memory systems, vary the order in which components are activated

25 Slide 25 Stress testing l Exercises the system beyond its maximum design load. Stressing the system often causes defects to come to light l Stressing the system test failure behaviour.. Systems should not fail catastrophically. Stress testing checks for unacceptable loss of service or data l Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded

26 Slide 26 A testing workbench

27 Slide 27 เครื่องมือช่วยในการทดสอบ เครื่องมือสร้างกรณีทดสอบ เครื่องมือทดสอบการ Coverage เครื่องมือการประมวลผลการทดสอบ เครื่องมือจัดการกับกรณีทดสอบ

28 Slide 28 แบบต่าง ๆ ของการทดสอบ l Unit Test l Integration Test l Functional Test (Features Test, Acceptance Test) l Stress Test l Performance Test l Qualification Test l Loading Test l Compatibility Test l Installation Test l Regression Test


Download ppt "Slide 1 การทดสอบโปรแกรม กระบวนการในการทดสอบ กระบวนการในการหาข้อผิดพลาดของ โปรแกรม กลยุทธ์การทดสอบ เครื่องมือช่วยในการทดสอบ แบบต่าง ๆ ของการทดสอบ."

Similar presentations


Ads by Google