Software Unit Test Coverage and Adequacy 김의섭

Size: px

Start display at page:

Download "Software Unit Test Coverage and Adequacy 김의섭"

서우 노
5 years ago
Views:

1 Software Unit Test Coverage and Adequacy 김의섭

2 목차 0. Abstract 1. Introduction 2. Structural Testing 3. Error Seeding 4. Error-base adequacy criteria and domain analysis 5. Comparison of test data adequacy criteria 6. Conclusion

3 0. Abstract Software testing 에서 Test quality 의객관적인측정은의중요한부분이다. 객관적인측정을위해 criteria 라는개념이나왔다 앞으로 criteria 에대해서체계적으로설명하고, 비교, 평가를하겠다.

4 1. Introduction program testing can be used to show the presence of bugs, but their absence dijkstra 이런 bugs 를없애기위해 test criterion 이라는개념이나왔다. 이후 test criteria 는중요한 focus 가되었고, 많은수의 criteria 가제안, 연구되었다. 그많고다른 criteria 들을어떻게이해할수있을까? 그중, 무엇이미래에진행될방향인가? test adequacy criteria 은실제사용에서비용적인가치가얼마나있나?

5 1.1 The Notion of test Adequacy Adequacy criteria 를이해하기위한기본적인개념 Statement coverage Adequacy Criterion : 모든 statement 가실행되어야한다. Statement coverage criterion 에의하면이런 requirements 를만족하는 test set 은 adequate 하다고여겨진다. Test set : test case 의집합, test case : testing 의 input Percentage of executed statements 는얼마나적절하게 testing 이수행되는지로계산된다.

6 1.1 The Notion of test Adequacy Branch coverage The branch coverage criterion : 모든 control transfer 가실행되어져야한다는것 Percentage 는 test adequacy 의측정 Path coverage The path coverage criterion : 모든 execution paths from the program s entry to its exit 은실행되어져야한다는것

7 1.1 The Notion of test Adequacy Mutation adequacy Mutant : 정상적인코드에인위적으로 fault 를넣은 program Original program 과 mutant 를 testing 하여 Fault 가검출되면 dead mutant, 그렇지않으며 alive mutant Mutant score : Dead mutant 의수와처음 mutant 의수를비교한것

8 1.1 The Notion of test Adequacy 1) Test Data Adequacy Criteria as Stopping Rules 충분한 testing 이이루어졌다면 testing 을멈출수있다. Ex) statement coverage criterion 을사용한다면, 모든 statement 를 testing 하였을때 testing 을멈출수있다. 2) Test Data Adequacy Criteria as Measurements test quality 에대해 measurements 를할수있다. 하지만이것은 good or bad 로정확히떨어지는것은아니다. EX) percent of code coverage 의경우 adequacy measurement 로사용된다.

9 1.1 The Notion of test Adequacy

10 1.1 The Notion of test Adequacy adequacy criterion 의역할 test case 결정 test case 를선택하는 guideline 을제공해줄수있다. 이러한것을 Test case selection criterion 라고한다. 이것을사용하면, testing method 는 test 중에있는 software 나 specification 에서 test set 을생성하는 algorithm 을체계적으로 정의할수있다. 이렇게생성된 test case 는 adequate 하다. test set 측정 주어진 test set 이 adequate 한지를결정하는것과, test set 의 adequacy 를측정할수있다. 테스트집합이 adequate 여부를결정하는규칙은일반적으로 test data adequacy criterion 이라고한다.

11 1.1 The Notion of test Adequacy

12 1.1 The Notion of test Adequacy 2) adequacy criterion 은 observation 을결정하는역할을한다. statement coverage 의경우모든 statement 가실행되고있는지 tester 또는 testing system 이관찰을해야하고, Path coverage 의경우는 statement 가아닌 execution path 가잘실행되고있는지를관찰해야한다. Mutant score 의경우관찰은필요하지않다. 단지 original program 과 mutant program 의 output 을비교를해야한다.

13 1.2 The Uses of Test Adequacy Criteria Software testing 을 management 할수있다 testing 은 test case 들을계속적으로실행하는 process stopping rule 을사용하여 test objective 를달성했다고생각된다면, 더이상의 test 를중단할수있다. 그렇지않으면더많은 test 가실행되어야하고, 이경우, adequacy criterion 은추가적인 test case 를선택하는 guideline 을제공해줄수있다. tester 들이 software testing process 를 management 할수있게도와준다. 충분한 test case 를실행함으로써 software quality 를보장할수있게한다.

14 1.3 Categories of Test Data Adequacy Criteria specification-based criteria Software 의 requirements 나 specification 의확인된기능측면에서 required testing 을구체적으로명시한다. 만약이확인된기능이전부실행된다면, 그 test set 은 adequate 하다하고말할수있다. program-based criteria Test 중인 program 에대해서 Test requirement 를명시한다. 그리고 program 이완전히실행된다며그 test set 은 adequate 하다고결정할수있다. Combined specification and program-based criteria specification and program-based criteria 의생각을모두사용한다.

15 1.3 Categories of Test Data Adequacy Criteria Specification 과 program 을쓰지않고 testing requirements 를명시하는 test adequacy criteria 가있다. Random testing, statistical selecting Test case 를 input space 에서확률적인분포를가지고 random 하게선택한다. Interface-based criteria Software 의 input 의 type 이나 range 의정보만보고 testing requirement 를명시하는것

16 1.3 Categories of Test Data Adequacy Criteria Block box testing Tester 는 program 실행에관해어떤지식도없다. Specification-based criteria, interface-based criteria White box testing Tester 는 program 의실행에관해 detail 하게알고있다. Program-based criteria, combined specification and programbased criteria

17 1.3 Categories of Test Data Adequacy Criteria Testing approach structural testing elements 의 set 의 coverage 에관한 Testing requirement 를명시한다. fault-based testing Fault 를찾기위해사용한다. Test set 이 fault 를찾는능력을측정한다. error-based testing Error-prone 한지점에관하여체크할 test case 를확인한다.

18 2. Structural Testing

19 2.1.1 Control Flow Adequacy Criteria 절차적언어라면 flow-graph 를자동적으로생성할수있다.

20 2.1.1 Control Flow Adequacy Criteria 그렇다면 flow-graph model 과 test cases 의 set 을이용하여어떻게 testing adequacy 를측정할수있을까? 기본적인방법중의하나는모든 statements 가실행되는지확인해보는것이다. Statement coverage criteria Statement 는 node 와연관된다. Node 에 execution path 인 edge 가있는지학인해본다. 정의 ) 적어도하나의 Execution path p 가존재해야하고, node n 은그 p 와연결되어야한다. 하지만몇몇 control transfer 는실행되지않을수도있다.

21 2.1.1 Control Flow Adequacy Criteria Branch coverage Slightly strong requirement of adequacy criteria 모든 edge 는 execution path 안에포함되는지확인해본다. 정의 ) 적어도하나의 Execution path p 가존재해야하고, p 는 edge e 를포함해야한다. Branch coverage 가 statement coverage 보다 strong 하다. 왜냐하면모든 edge 가 cover 되면모든 node 도 cover 되는것이기때문이다. 이러한관계를 subsumes relation 이라고한다.

22 2.1.1 Control Flow Adequacy Criteria 하지만모든 branch 가실행되었다고해서 control transfers 의 combination 이만족되었다고볼수없다. 모든 branch 의 combination 까지확인해봐야한다. 이것을 path coverage criterion, path testing 이라고부른다. path coverage criterion 정의 )Flow graph 의 begin 부터 end node 사이의모든 edge 를 Execution path 의 set 인 P 가모두포함하고있어야한다.

23 2.1.1 Control Flow Adequacy Criteria 하지만 path coverage criterion 는실제사용하기에는너무 strong 하다. Loop 와같은무한한 path 가있기때문이다. 이경우무한한시간이걸릴수있다. Testing 은정해진시간안에끝내야하기때문에 test set 은 finite 해야한다. 이런 requirement 를만족하는속성을 Finite applicability 라고부른다.

24 2.1.1 Control Flow Adequacy Criteria 하지만 Statement coverage criteria 와 branch coverage criteria 는 finite applicability 가아니다. 그들은실행불가능한 element 를요구할수도있기때문이다. Ex) statement coverage criteria 는모든 statement 를실행해야한다. 하지만 program 에는 dead code 라고부르는실행되지않는 statement 가존재할수있다. 어떤 input data 도이 statement 를실행시킬수없다. 이러한경우에는 statement coverage 를만족시키는 adequacy test set 은없게된다.

25 2.1.1 Control Flow Adequacy Criteria Statement coverage criteria 와 branch coverage criteria 를 finitely applicable version 으로만들수있다. Testing 은정해진시간안에끝내야하기때문에 finite applicability 속성을가져야한다. Testing 을오직 feasible elements 만 cover 할수있게만들어서 finitely applicable version 을만들수있다.

26 2.1.1 Control Flow Adequacy Criteria feasible version 을만드는가장간단한방법은중요하고필수적인 subset of path 를선택하는것이다. Simple path coverage criteria 모든 path 에반복이없는 execution path 를 simple path 라고한다. 그리고 subset 으로그것을선택하는것이다. Elementary path coverage criteria 모든 node 에반복이없는 execution path 를 elementary path 라고한다. 그리고 subset 으로그것을선택하는것이다. Length-n path coverage criterion 모든 subpath 의길이를 n 보다같거나작게제한한다.

27 2.1.1 Control Flow Adequacy Criteria Level-i path coverage criterion 이 criterion 이처음실행될때, 시작 node 부터끝 node 까지의모든 elementary path 를 testing 한다. 만약실행되지않은 elementary subpath 나 cycle 이존재한다면, 다음 level 에서확인을한다. 모든 node 와 edge 가 cover 될때까지반복한다. Lever-i path coverage criteria 를만족한 test set 은 elementary path coverage criteria 도만족할것이다. Elementary path coverage criteria 는 level-0 path 이기때문이다. Subsume 관계이다.

28 2.1.1 Control Flow Adequacy Criteria Control-flow adequacy criteria 에서 loop 와관련된 criterion Loop count-k criterion Loop 를 K 번까지만반복한다. Cycle combination criterion Adequacy test set 은모든 cycle 을포함하지않는 execution path 를 cover 해야한다. Cyclomatic-number criterion 어떤 execution path 는 linear combination 으로표현될수있는데, 이렇게표현된다면불필요한 path 이다. v(g) = e n p v : cyclomatic number, e : edge, n : node, p : strong connected component v = maximal size of a set of independent path 최소하나의독립적인집합을포함해야한다는 requirement

29 3. Fault-based Adequacy Criteria Fault-base Adequacy criteria 는결함을감지하는효율성이나능력에따라 test set 의 quality 를측정한다. 1) Error Seeding 2) Program Mutation testing 3) Variants of program Mutation testing

30 3.1 Error Seeding Error Seeding? 원래 software 에있는 faults 를확인하기위해제안된 technique 이다. 인공적인 faults 를 program 에삽입한다. 이러한인공적인 faults 는 program 에내재하고있지만찾아내기어려운 faults 라고생각할수있다. r 은발견된인공결함의개수 / 총인공결함의개수의비율이다. f 는 testing 중에발견된 inherent faults 의개수있다. f/r 는통계적인 inherent faults 의개수이다. r = 10/100 = 0.1, f = 1, f/r = 1/0.1 = 10 개 r 은 test adequacy 의척도라고볼수있다. r = 10/100 = 0.1 (bad), R = 100/100 = 1 (good)

31 3.1 Error Seeding 장점 test quality for dynamic testing 를측정하는데제약이없다는것이다. Error, fault 를검출하는모든 testing method 에적용된다. 단점 측정에대한 adequacy 는인공적인 fault 를어떻게심느냐에따라달라진다. Inherent faults 와비슷한 faults 를만드는것은어렵다. 일반적으로인공적인 faults 는 inherent faults 보다찾기가쉽다. 이런문제를극복하기위해서 mutation testing 이나왔다.

32 3.2.1 Principles of Mutation Adequacy Analysis. Mutant : original program 에인공적인 error 를넣어놓은것 기본적으로 Mutant 와 original program 은서로다른 output 을내보내야한다. Mutant 가 dead 하다. 두 program 이서로다른 output 을내보냈다. Mutant 가 alive 하다. 두 program 이같은 output 을내보냈다. Mutant 가 alive 하다라는것은많은의미를주게된다.

33 3.2.1 Principles of Mutation Adequacy Analysis. Mutant 가살아있게되는이유 (1) The test data are inadequate Mutant 의대부분이 live 인경우더이상 program p 를믿을수없다고생각해야한다. 그렇지않으면대부분의 mutant 가옳다라고생각해한다. mutation analysis 는제시된 test data 에의해실행되지않는프로그램을특정부분을보여줌으로써 test data 의약점을드러낼수있다. 예를들어, 제시된 test data 는 program 의 mutated 된부분은실행하지않았다는것이다.

34 3.2.1 Principles of Mutation Adequacy Analysis.

35 3.2.3 mutation Transformations 이제고려해보아야할것은주어진 program 에서어떻게 mutant 를생성해내는가이다. 좋은방법은 mutant operation 을사용하는것이다. Mutant operation 은 syntactic transformation 이다.

36 3.2.4 The Pros and Cons (1) Mutation analysis 는자동화가쉽다. Mutants 는 mutation operator 를사용하여생성되고컴파일되고실행된다. Mutant 와 original program 의 output 은비교되고 adequacy score 도계산된다. (2) Error 를찾거나제거하기쉬운환경을제공한다. Mutation operator 를적용하고 mutation operator 가적용된지점을찾으면된다. (3) 아직 Alive 인 mutant 를조사한다. tester 는 mutant 가 original 과 equivalent 하다고확정짓거나 또는, mutant 를 dead 상태로만들다른 test data 를추가적으로생성하여 kill 할노력을할수있다.

37 3.3 Variants of Program Mutation Testing Firm mutation testing Mutation testing 는 original version 의작은변화이다. 이변화는 parameter 의 set 으로정의할수있고, 이런 parameter 를명확하게하고쉽게변경할수있게하는것이기본목적이다. Strong-mutation testing 보다 expensive 가낮고 weakmutation testing 보다는높다. Fault 삽입과, result 를비교하는 Mechanism 을제공 단점은 Parameter 를선택하기위한체계적인기초가없다.

38 3.3 Variants of Program Mutation Testing

39 3.5 The Relay Model Fault 가 error 를발생시키지않을수도있다. Potential fault : node n 과이에대응하는 node n* 의불일치 Potential error : fault 를포함하고있는 expression 이실행될때 Output error : potential fault 의실행이 incorrect 한 output 나올때까지지속될때 Context error : Node 의각연산자를통해 potential error 가계산되어졌을때 Data flow transfer : potential error 가 value 로반영되고, 다른 node 가이것을참조하였을때발생한다

40 4. Error-based Adequacy Criteria And Domain Analysis Error-based testing methods 는 program 에서 error 가발생하기쉬운지점 (border) 을체크하는 test case 를만드는것이다. 먼저 Input-output behavior space 를 subdomain 으로나눈다. Software 는 subdomain 내에서한 test case 에대해올바르게작동을했다면, 그 subdomain 내에서다른 data 에대해서도올바르게작동할것이라고추측할수있다.

41 4.1 Specification-Based Input Space Partitioning 예 ) DISCOUNT INVOICE 한회사에서 x, y 라는물건을판다. x = 5 원, y = 10 원 총금액 >= 200 원 = 5% 할인, 총금액 >= 1000 원 = 20% 할인 x 의구매개수 > 30 개 = 10% 할인. Subset : {(x, y) x <= 30, 5x + 10y <= 200}

42 4.1 Specification-Based Input Space Partitioning Region A border

43 4.2 Program-Based Input-Space Partition Program 은 path 로 input space 를나눈다. 두개의 input 이똑같은 subdomain 에속해있다면똑같은 computation 을발생할것이다. 일반적으로 program 에서같은 execution path 라며같은 computation 을출력한다. 그러므로 subdomain 은 program 의 path 에대응해야한다. 만약 loop 이라도있는경우가있다면, path 를선택하기위해적당한 criterion 을선택해야한다. Level-i path coverage, Cyclomatic-number criterion

44 4.2 Program-Based Input-Space Partition DISCOUNT INVOICE

45 4.2 Program-Based Input-Space Partition 6 개의 path 가존재한다. 이것은각각 subdomain 이될수있다. Border 가사라졌다. Error-based testing 에서는 subdomain 에서만 test case 를선택하지않고, boundaries 에서도 test case 를선택한다. Boundaries 가 error-prone 한곳이기때문이다.

46 4.3 Boundary Analysis

47 5. Comparison of test data adequacy criteria Testing methods 를비교하는것은어렵다. 서로다른 software model 을쓰고, 기본적인이론이다르기때문이다. Testing adequacy criteria 를비교하려면명확한기준이필요하다. 1) fault-detecting ability 2) Software reliability 3) test cost

48 5.1.1 Statistical Experiments Fault-detecting ability Fault-detecting ability 는 test adequacy criteria 의 effectiveness 를직접적으로측정하는한방법이다. Ex 1) Nafos[1984] branch coverage, random testing, and required pair coverage. 14 small programs. Test case 는 a large set of random test cases 에서선택 test sets 에의해 Mutants 가 kill 되는만큼 fault-detection abilities 로여긴다.

49 5.1.1 Statistical Experiments 결과 이러한시도가틀릴수있음을지적하는몇가지잠재적인잠재적인요인알아냈다. 1) program 의특정한부분은반드시실행되어져야한다. 결과를신뢰하기에특정한부분은너무작거나너무독특했다. 2) 특정한 data 가각각의 method 를위해생성되어야한다. 특정 data 는 method 와상관없이그자체로좋거나나쁠수있다. 3) fault 는반드시실행되어져야한다. 인공적으로생성된 fault 는찾기에너무쉽거나너무어려웠다. particular test method 나 adequacy criterion 은특정 type 의 fault 에만좋은능력을보여주기도한다.

50 5.1.1 Statistical Experiments Ex 2) Basili and Selby[1987] Dynamic testing methods (functional testing and statement coverage) A static testing method (code review) 4 programs fault-detection ability 와 fault-detection cost 측정 결과 각각다른 techniques 는각각다른 type 의 fault 를찾는데각각다른 fault-detection 능력을보여주었다. Code reading 은 interface fault 를더많이찾았고, functional testing 은 control fault 를더많이찾았다.

51 5.1.1 Statistical Experiments Ex 3) Frankl and Weiss[1993] branch adequacy and all-uses data-flow adequacy criteria 9 small programs of different subjects. 많은수의 adequate test sets for each criterion Error 를 detect 하는비율을조사 결과 5개의 subjects 에서각각의 criterion 에서 random 하게 test set 이선택이되었을때경우에 all-uses criterion 이 branch coverage 보다더효율적이였다. 4개의 subjects 에서 all-uses criterion 는 branch coverage 보다 error 를찾을확률이더높다. 각각의 adequacy criteria 는다양한특색을가지고있어특정결과를신뢰할수없다. 그래서 Statistical Experiments 방법은문제가있다.

52 5.1.2 Simulation simulation 은두가지로나누어볼수있다. Partition testing 과 random testing Partition testing 은가상적으로 input space 를 partition 하여 test case 를선별하였다. Random testing 은 random 하게 test case 를선별하였다.

53 5.1.2 Simulation 100 random test cases 과 50 partition test cases 를해본결과 random testing 의 fault-detecting ability 가더좋다라는결과를보여주었다. random testing 이 partition testing 보다 cost-effective random testing 이 partition testing 보다 cost-effective 하다는것이이논문의결론을뒷받침하는증거중에하나이다.

54 subsume

55 conclude Software testing 에서 Test criteria 가중요한 focus 였습니다. 많은 criteria 가생겼고, 또그것을 support 하는 criteria 가연속적으로생성되었다. 어떤 criteria 가 true 인지는여전히많은논란이있지만, 중요한것은 criteria 는 fault-detecting ability 이있고, software testing dependability 를준다는것이다. 앞으로는, test adequacy criteria 를사용하여 software 를체계적으로 testing 하는방향으로흐르고있다.

example code are examined in this stage The low pressure pressurizer reactor trip module of the Plant Protection System was programmed as subject for

example code are examined in this stage The low pressure pressurizer reactor trip module of the Plant Protection System was programmed as subject for 2003 Development of the Software Generation Method using Model Driven Software Engineering Tool,,,,, Hoon-Seon Chang, Jae-Cheon Jung, Jae-Hack Kim Hee-Hwan Han, Do-Yeon Kim, Young-Woo Chang Wang Sik, Moon