Documents

7 views

structural_testing.pdf

Download structural_testing.pdf
of 65

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Tags
Transcript
  4 Structural Testing Structural testing is considered more technical than functional testing. It attempts to design test cases from the source code and not from the specifications. The source code becomes the base document which is examined thoroughly in order to understand the internal structure and other implementation details. It also gives insight in to the source code which may be used as an essential knowledge for the design of test cases. Structural testing techniques are also known as white box testing techniques due to consideration of internal structure and other implementation details of the program. Many structural testing techniques are available and some of them are given in this chapter like control flow testing, data flow testing, slice based testing and mutation testing. 4.1 CONTROL FLOW TESTING This technique is very popular due to its simplicity and effectiveness. We identify paths of the  program and write test cases to execute those paths. As we all know, path is a sequence of statements that begins at an entry and ends at an exit. As shown in chapter 1, there may be too many paths in a program and it may not be feasible to execute all of them. As the number of decisions increase in the program, the number of paths also increase accordingly.Every path covers a portion of the program. We define ‘coverage’ as a ‘percentage of source code that has been tested with respect to the total source code available for testing’. We may like to achieve a reasonable level of coverage using control flow testing. The most reasonable level may be to test every statement of a program at least once before the completion of testing. Hence, we may write test cases that ensure the execution of every statement. If we do so, we have some satisfaction about reasonable level of coverage. If we stop testing without achieving this level (every statement execution), we do unacceptable and intolerable activity which may lead to dangerous results in future. Testing techniques based on program coverage criterion may provide an insight about the effectiveness of test cases. Some of such techniques are discussed which are part of control flow testing. https://www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9781139196185.005 Downloaded from https://www.cambridge.org/core. IP address: 115.249.244.195, on 14 Sep 2017 at 05:22:19, subject to the Cambridge Core terms of use, available at  166Software Testing 4.1.1 Statement Coverage We want to execute every statement of the program in order to achieve 100% statement coverage. Consider the following portion of a source code along with its program graph given in Figure 4.1. #include<stdio.h>#include<conio.h> 1. void main() 2. { 3. int a,b,c,x=0,y=0; 4. clrscr(); 5. printf( Enter three numbers: ); 6. scanf( %d %d %d ,&a,&b,&c); 7. if((a>b)&&(a>c)){ 8. x=a*a+b*b; 9. } 10. if(b>c){ 11. y=a*a-b*b; 12. } 13. printf( x= %d y= %d ,x,y); 14. getch(); 15. } Figure 4.1. Source code with program graph If, we select inputs like:a=9, b=8, c=7, all statements are executed and we have achieved 100% statement coverage  by only one test case. The total paths of this program graph are given as:1–7, 10, 13–15(i)1–7, 10–15(ii)1–10, 13–15(iii)1–15(iv)The cyclomatic complexity of this graph is:V(G) =e – n + 2P = 16 – 15 + 2 = 3V(G) =no. of regions = 3V(G) = + 1 = 2 + 1 = 3Hence, independent paths are three and are given as:1–7, 10, 13–15(i)1–7, 10–15(ii)1–10, 13–15(iii)Only one test case may cover all statements but will not execute all possible four paths and not even cover all independent paths (three in this case). https://www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9781139196185.005 Downloaded from https://www.cambridge.org/core. IP address: 115.249.244.195, on 14 Sep 2017 at 05:22:19, subject to the Cambridge Core terms of use, available at  Structural Testing167 The objective of achieving 100% statement coverage is difficult in practice. A portion of the  program may execute in exceptional circumstances and some conditions are rarely possible, and the affected portion of the program due to such conditions may not execute at all. 4.1.2 Branch Coverage We want to test every branch of the program. Hence, we wish to test every ‘True’ and ‘False’ condition of the program. We consider the program given in Figure 4.1. If we select a = 9, b = 8, c = 7, we achieve 100% statement coverage and the path followed is given as (all true conditions):Path = 1–15We also want to select all false conditions with the following inputs:a = 7, b = 8, c = 9, the path followed is Path = 1–7, 10, 13–15These two test cases out of four are sufficient to guarantee 100% branch coverage. The  branch coverage does not guarantee 100% path coverage but it does guarantee 100% statement coverage. 4.1.3 Condition Coverage Condition coverage is better than branch coverage because we want to test every condition at least once. However, branch coverage can be achieved without testing every condition.Consider the seventh statement of the program given in Figure 4.1. The statement number 7 has two conditions (a>b) and (a>c). There are four possibilities namely:Both are true(i)First is true, second is false(ii)First is false, second is true(iii)Both are false(iv)If a > b and a > c, then the statement number 7 will be true (first possibility). However, if a < b, then second condition (a > c) would not be tested and statement number 7 will be false (third and fourth possibilities). If a > b and a < c, statement number 7 will be false (second  possibility). Hence, we should write test cases for every true and false condition. Selected inputs may be given as:a = 9, b = 8, c = 7 (first possibility when both are true)(i)a = 9, b = 8, c = 10 (second possibility – first is true, second is false)(ii)a = 7, b = 8, c = 9 (third and fourth possibilities- first is false, statement number 7 is (iii)false)Hence, these three test cases out of four are sufficient to ensure the execution of every condition of the program. 4.1.4 Path Coverage In this coverage criteria, we want to test every path of the program. There are too many paths in any program due to loops and feedback connections. It may not be possible to achieve this https://www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9781139196185.005 Downloaded from https://www.cambridge.org/core. IP address: 115.249.244.195, on 14 Sep 2017 at 05:22:19, subject to the Cambridge Core terms of use, available at  168Software Testing goal of executing all paths in many programs. If we do so, we may be confident about the correctness of the program. If it is unachievable, at least all independent paths should be executed. The program given in Figure 4.1 has four paths as given as:1–7, 10, 13–15(i)1–7, 10–15(ii)1–10, 13–15(iii)1–15(iv)Execution of all these paths increases confidence about the correctness of the program. Inputs for test cases are given as: S.No.Paths Id.PathsInputsExpected Outputabc 1.Path-11–7,10, 13–15789x=0 y=02.Path-21–7, 10–15786x=0 y=–153.Path-31–10, 13–15978x=130 y=04.Path-41–15987x=145 y=17 Some paths are possible from the program graph, but become impossible when we give inputs as per logic of the program. Hence, some combinations may be found to be impossible to create.Path testing guarantee statement coverage, branch coverage and condition coverage. However, there are many paths in any program and it may not be possible to execute all the paths. We should do enough testing to achieve a reasonable level of coverage. We should execute at least (minimum level) all independent paths which are also referred to as basis paths to achieve reasonable coverage. These paths can be found using any method of cyclomatic complexity.We have to decide our own coverage level before starting control flow testing. As we go up (statement coverage to path coverage) in the ladder, more resources and time may be required. Example 4.1: Consider the program for the determination of the division of a student. The  program and its program graph are given in Figure 3.15 and 3.16 of chapter 3 respectively. Derive test cases so that 100% path coverage is achieved. Solution: The test cases are given in Table 4.1. Table 4.1. Test cases S.No.mark1mark2mark3Expected outputPaths 1.30–120Invalid marks1–14, 33, 342.402045Fail1–12, 15–19, 32, 33,343.454750Third division1–13, 15–17, 20–22, 32–344.556057Second division1–12, 15–17, 20, 23, 26–28, 32–345.657075First division1–12, 15–17, 20, 23, 26–28,32–346.808590First division with distinction1–12, 15–17, 20, 23, 26, 29–34 https://www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9781139196185.005 Downloaded from https://www.cambridge.org/core. IP address: 115.249.244.195, on 14 Sep 2017 at 05:22:19, subject to the Cambridge Core terms of use, available at
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks