코드 적용 범위
Code coverage| 프로그램 실행 |
|---|
| 일반개념 |
| 코드 종류 |
| 컴파일 전략 |
| 주목할 만한 런타임 |
| 주목할 만한 컴파일러 및 공구 체인 |
|
컴퓨터 과학에서 시험 적용 범위는 특정 시험 그룹을 실행할 때 프로그램의 소스 코드가 실행되는 정도의 척도(퍼센트 단위)이다.시험 적용범위가 높은 프로그램은 시험 중 실행되는 소스 코드가 많아 시험 적용범위가 낮은 프로그램에 비해 탐지되지 않은 소프트웨어 버그를 포함할 확률이 낮음을 시사한다.[1][2]시험 적용범위를 계산하는 데 많은 다른 측정기준을 사용할 수 있다.가장 기본적인 것 중 일부는 프로그램 서브루틴의 백분율과 테스트 제품군의 실행 중에 호출된 프로그램 문장의 백분율이다.
시험 적용 범위는 체계적인 소프트웨어 테스트를 위해 개발된 첫 번째 방법 중 하나이다.첫 번째 발표된 언급은 1963년 ACM의 통신에서 밀러와 말로니가 했다.[3]
커버리지 기준
테스트 제품군에 의해 실행된 코드 백분율을 측정하기 위해 하나 이상의 적용 범위 기준을 사용한다.이것들은 보통 규칙이나 요구 사항으로 정의되며, 시험 제품군은 이를 충족시켜야 한다.[4]
기본적 적용 기준
여러 가지 적용 기준이 있지만, 주요 적용 기준은 다음과 같다.[5]
- 기능 범위 – 프로그램의 각 기능(또는 서브루틴)이 호출되었는가?
- 진술 포함 범위 – 프로그램의 각 진술이 실행되었는가?
- 모서리 범위 – 제어 흐름 그래프의 모든 모서리 실행 여부
- 조건 범위 – 각 부울 하위 표현이 참과 거짓으로 평가되었는가?( 술어 커버리지라고도 함)
예를 들어 다음 C 함수를 고려하십시오.
인트로 foo (인트로 x, 인트로 y) { 인트로 z = 0; 만일 ((x > 0) && (y > 0)) { z = x; } 돌아오다 z; } 이 기능이 더 큰 프로그램의 일부라고 가정하고 이 프로그램은 테스트 제품군과 함께 실행되었다.
- 이 실행 중에 기능이 충족되는 경우 기능 적용 범위가 충족
foo적어도 한 번은 불려갔지 - 이 기능에 대한 진술 범위는 예를 들어 다음과 같이 호출된 경우 충족될 것이다.
foo(1,1), 이 경우 함수 내의 모든 라인이 실행될 것이기 때문이다(포함).z = x;. - 지점 호출로 지점 커버리지가 충족됨
foo(1,1)그리고foo(0,1)첫 번째 경우에는 둘 다if조건이 충족되고z = x;두 번째 경우에는 첫 번째 조건인(x>0)이 만족되지 않아 의 실행이 방지됨z = x;. - 조건 적용 범위는 전화를 거는 테스트로 충족될 것이다.
foo(1,0)그리고foo(0,1)이런 것들이 필요한 이유는 첫 번째 사건에서(x>0)로 평가하다.true, 2번째에 있는 동안 , 그것은 평가한다.false. 동시에 첫 번째 경우는(y>0)false, 두번째가 만드는 동안true.
조건 적용범위가 반드시 분기 적용범위를 의미하는 것은 아니다.예를 들어 다음 코드 조각을 고려하십시오.
만일 a 그리고 b 그때 조건 적용 범위는 다음 두 가지 테스트로 충족될 수 있다.
a=true,b=falsea=false,b=true
그러나 이 테스트 세트는 두 가지 경우 모두 다음 항목을 충족하지 못하므로 분기 커버리지를 충족하지 못한다.if조건을 달다
시험 중 예외 취급 코드의 모든 조건과 분기에 적절한 적용범위가 있는지 확인하기 위해 결함 주입이 필요할 수 있다.
수정된 조건/결정 적용 범위
기능 적용범위와 분기 적용범위의 결합을 의사결정 적용범위로 부르기도 한다.이 기준은 프로그램의 모든 출입국 지점이 적어도 한 번은 호출되고, 프로그램의 모든 결정은 최소한 한 번은 가능한 모든 결과에 대해 취하도록 요구한다.이 맥락에서 결정은 조건과 0개 이상의 부울 연산자로 구성된 부울식이다.그러나 이 정의는 지점 커버리지와 동일하지 않지만, 의사결정 커버리지라는 용어는 때때로 그것과 동의어로 사용된다.[6][7]
조건/결정 적용범위는 결정과 조건 적용범위가 모두 충족되어야 한다.단, 안전에 중요한 애플리케이션(예: 항전 소프트웨어)의 경우 수정된 조건/결정 적용범위(MC/DC)를 충족해야 하는 경우가 많다.이 기준은 각 조건이 의사결정 결과에 독립적으로 영향을 미쳐야 한다는 요건과 함께 조건/결정 기준을 확장한다.
예를 들어 다음 코드를 고려하십시오.
만일 (a 또는 b) 그리고 c 그때 조건/결정 기준은 다음과 같은 시험 세트로 충족된다.
- a=true, b=true, c=true
- a=거짓말, b=거짓말, c=거짓말
그러나 위의 시험 세트는 첫 번째 시험에서 'b'의 값과 두 번째 시험에서 'c'의 값이 출력에 영향을 미치지 않기 때문에 수정된 조건/결정 적용범위를 만족시키지 못할 것이다.따라서 MC/DC를 만족시키기 위해서는 다음과 같은 시험 세트가 필요하다.
- a=거짓말, b=참말, c=거짓말
- a=허위, b=true, c=true
- a=거짓, b=거짓, c=참.
- a=true, b=false, c=true
다중 조건 적용 범위
이 기준은 각 결정 내부의 모든 조건 조합을 시험할 것을 요구한다.예를 들어 이전 섹션의 코드 조각은 다음과 같은 8가지 테스트를 필요로 한다.
- a=거짓말, b=거짓말, c=거짓말
- a=거짓, b=거짓, c=참.
- a=거짓말, b=참말, c=거짓말
- a=허위, b=true, c=true
- a=true, b=false, c=false
- a=true, b=false, c=true
- a=true, b=true, c=false
- a=true, b=true, c=true
매개 변수 값 적용 범위
매개 변수 값 적용범위(PVC)는 매개 변수를 사용하는 방법에서 해당 매개 변수에 대한 모든 공통 값을 고려해야 한다.그 아이디어는 매개변수에 대해 가능한 모든 공통의 값을 시험한다는 것이다.[8]예를 들어, 문자열의 공통 값은 1) null, 2) 비워짐, 3) 공백(공백, 탭, 새 줄), 4) 유효한 문자열, 5) 유효 문자열, 6) 단일 바이트 문자열, 7) 더블바이트 문자열이다.또한 매우 긴 줄을 사용하는 것이 적절할 수 있다.가능한 각 매개변수 값을 테스트하지 않으면 버그가 발생할 수 있다.이 중 하나만 테스트하면 각 라인이 커버되는 대로 100% 코드 적용이 가능하지만 7개 옵션 중 하나만 테스트되므로 PVC가 14.2%에 불과하다.
기타 적용 기준
추가 적용 기준들이 있으며, 이러한 기준들은 덜 자주 사용된다.
- LCSAJ(Linear Code Sequence and Jump) 커버리지 a.k.a. JJ 경로 커버리지 - 모든 LCSAJ/JJ 경로가 실행되었는가?[9]
- 경로 범위 – 코드의 특정 부분을 통과하는 가능한 모든 경로가 실행되었는가?
- 진입/출구 범위 – 가능한 모든 통화 및 기능 반환이 실행되었는가?
- 루프 커버리지 – 모든 가능한 루프가 0회, 1회, 2회 이상 실행되었는가?
- 주 범위 – 유한 상태 기계의 각 주(州)에 도달하여 조사하였는가?
- 데이터 흐름 범위 – 각 변수 정의와 그 용도에 도달하고 탐구하였는가?[10]
안전성에 중요하거나 신뢰할 수 있는 애플리케이션은 종종 어떤 형식의 시험 적용범위를 100% 입증하기 위해 필요하다.예를 들어, ECSS-E-ST-40C 표준은 4가지 중요도 수준 중 2가지에 대해 100% 명세서와 의사결정 적용범위를 요구한다. 다른 하나는 목표 적용범위가 공급자와 고객 사이의 협상에 달려 있다.[11]그러나 특정 목표값(특히 100%)을 설정하는 것은 여러 가지 이유로 실무자들로부터 비난을 받아왔다.[12][13]
위의 커버리지 기준 중 일부는 연결되어 있다.예를 들어, 경로 적용범위는 결정, 진술, 진입/출입 범위를 의미한다.모든 진술은 지부의 일부분이기 때문에 의사결정 적용범위는 진술 포함을 의미한다.
위에서 설명한 유형의 전체 경로 적용 범위는 대개 비실용적이거나 불가능하다.그 안에 의n {\개의 결정이 있는 모듈은 그 안에 최대 개의 경로를 가질 수 있으며, 루프 구조는 무한히 많은 경로를 초래할 수 있다.시험 중인 프로그램에 특정 경로를 실행하게 할 수 있는 입력이 없다는 점에서 많은 경로도 실현 불가능할 수 있다.그러나 실현 불가능한 경로를 식별하기 위한 범용 알고리즘은 불가능하다는 것이 입증되었다(이러한 알고리즘은 정지 문제를 해결하기 위해 사용될 수 있다).[14]기본 경로 테스트는 예를 들어 완전한 경로 적용 범위를 달성하지 않고 완전한 분기 적용 범위를 달성하는 방법이다.[15]
대신에 실제 경로 범위 테스트를 위한 방법은 루프 실행 횟수에서만 다른 코드 경로의 클래스를 식별하고 "기본 경로" 범위를 달성하기 위해 검사자가 모든 경로 클래스를 포함해야 한다.[citation needed][clarification needed]
실제로
대상 소프트웨어는 특별한 옵션이나 라이브러리로 구축되어 제어된 환경에서 실행되며, 실행된 모든 기능을 소스 코드의 기능 포인트에 매핑하기 위해 실행된다.이를 통해 정상 조건에서 거의 또는 전혀 접근하지 못하는 대상 소프트웨어의 테스트 부품을 사용할 수 있으며, 가장 중요한 조건(기능 지점)이 테스트되었음을 안심시킬 수 있다.그런 다음 결과 출력물을 분석하여 어떤 코드 영역이 행사되지 않았는지 확인하고 필요에 따라 이러한 영역을 포함하도록 시험을 업데이트한다.다른 시험 적용 범위 방법과 결합하여, 목적은 엄격하지만 관리가 용이한 회귀 테스트 세트를 개발하는 것이다.
소프트웨어 개발 환경 내에서 시험 적용 범위 정책을 이행할 때 다음 사항을 고려해야 한다.
- 최종 제품 인증에 대한 적용 범위 요구사항은 무엇이며, 그렇다면 어느 수준의 테스트 적용 범위가 필요한가?대표적인 엄격한 진행 수준은 다음과 같다.문장, 분기/결정, 수정된 조건/결정 범위(MC/DC), LCSAJ(선형 코드 시퀀스 및 점프)
- 시험 대상 시스템에 부과된 요건을 검증하는 시험(DO-178B)에 대해 적용범위를 측정해야 하는가?
- 생성된 객체 코드가 소스 코드 문으로 직접 추적 가능한가?특정 인증(예:[16] DO-178B 레벨 A)은 "이러한 생성 코드 시퀀스의 정확성을 확립하기 위해 객체 코드에 대해 추가 검증을 수행해야 한다"(DO-178B) 6.4.2항.
소프트웨어 작성자는 시험 적용범위 결과를 검토하여 추가 시험과 필수 기능에 대한 적용범위를 증가시키기 위한 입력 또는 구성 집합을 고안할 수 있다.시험 적용 범위의 두 가지 일반적인 형태는 문장(또는 선) 적용 범위와 가지(또는 가장자리) 적용 범위다.라인 적용 범위는 테스트를 완료하기 위해 실행된 코드 라인의 측면에서 테스트 실행 풋프린트에 대한 보고서.가장자리 커버리지는 테스트를 완료하기 위해 어떤 분기 또는 코드 결정 지점이 실행되었는지 보고한다.그들은 모두 백분율로 측정된 적용범위 측정지표를 보고한다.지점 커버리지가 67%인 경우, 지점 커버리지가 67%인 경우보다 더 포괄적이기 때문에, 이것의 의미는 커버리지를 어떤 형태로 사용했는지에 따라 달라진다.
일반적으로 시험 범위 도구는 실제 프로그램 외에 연산 및 로깅이 발생하여 응용 프로그램의 속도가 느려지기 때문에 일반적으로 이 분석은 생산에서 수행되지 않는다.예상할 수 있듯이, 직접적인 시험이 아닌 분석을 통해 범위 매핑의 정도를 대략적으로 추정할 수 있지만, 이러한 범위 시험을 실행할 수 없는 소프트웨어 종류가 있다.
또한 그러한 도구의 영향을 받는 결함의 종류도 있다.특히, 일부 경기 조건이나 유사한 실시간 민감 연산은 시험 환경에서 실행될 때 가려질 수 있다. 반대로, 이러한 결함의 일부는 시험 코드의 추가 오버헤드로 인해 찾기 더 쉬워질 수 있다.
대부분의 전문 소프트웨어 개발자들은 C1과 C2 커버리지를 사용한다.C1은 진술서 적용범위, C2는 지점 또는 조건 적용범위를 의미한다.C1과 C2의 조합으로 대부분의 문장을 코드 베이스에서 커버할 수 있다.또한 문장 적용범위는 기능 적용범위를 출입구, 루프, 경로, 상태 흐름, 제어 흐름 및 데이터 흐름 포함시킬 수 있다.이러한 방법으로 대부분의 소프트웨어 프로젝트에서 거의 100% 코드 커버리지를 달성할 수 있다.[17]
산업용도
시험 적용 범위는 항전 장비의 안전 인증에서 한 가지 고려사항이다.항전 기어가 연방항공청(FAA)에 의해 인증되는 지침은 DO-178B[16] 및 DO-178C에 문서화된다.[18]
시험 적용 범위는 또한 자동차 안전 표준 ISO 26262 도로 차량 - 기능 안전의 파트 6의 요건이다.[19]
참고 항목
- 사이클로믹스
- 지능형 검증
- 선형 코드 시퀀스 및 점프
- 수정된 조건/결정 적용 범위
- 돌연변이 검사
- 회귀 검정
- 소프트웨어 메트릭
- 정적 코드 분석
- 화이트 박스 테스트
- Java 코드 적용 도구
참조
- ^ Brader, Larry; Hilliker, Howie; Wills, Alan (March 2, 2013). "Chapter 2 Unit Testing: Testing the Inside". Testing for Continuous Delivery with Visual Studio 2012. Microsoft. p. 30. ISBN 1621140180. Retrieved 16 June 2016.
- ^ Williams, Laurie; Smith, Ben; Heckman, Sarah. "Test Coverage with EclEmma". Open Seminar Software Engineering. North Carolina State University. Archived from the original on 14 March 2016. Retrieved 16 June 2016.
- ^ Joan C. Miller, Clifford J. Maloney (February 1963). "Systematic mistake analysis of digital computer programs". Communications of the ACM. New York, NY, USA: ACM. 6 (2): 58–63. doi:10.1145/366246.366248. ISSN 0001-0782.
- ^ Paul Ammann, Jeff Offutt (2013). Introduction to Software Testing. Cambridge University Press.
- ^ Glenford J. Myers (2004). The Art of Software Testing, 2nd edition. Wiley. ISBN 0-471-46912-2.
- ^ 용지 CAST-10(2002년 6월)을 배치하십시오.수정된 조건/결정 적용범위(MC/DC)와 의사결정 적용범위(DC)의 "결정"이란?
- ^ 매트릭웍스.모델 적용 범위 유형.
- ^ "Unit Testing with Parameter Value Coverage (PVC)".
- ^ M. R. Woodward, M. A. Hennell, "모든 JJ 경로와 MCDC, 두 제어 흐름 적용 기준 간의 관계에 대하여" 정보 및 소프트웨어 기술 48페이지 433-440
- ^ 팅수, 커우, 웨이카이 먀오, 게광푸, 지펑허, 유팅첸, 전동수. "데이터 흐름 테스트에 관한 조사"ACM Compute.생존. 50조 1항 5호(2017년 3월), 35쪽.
- ^ ECSS-E-ST-40C: 우주 공학 - 소프트웨어.ECSS 사무국, ESA-ESTEC.2009년 3월
- ^ C. Prause, J. Werner, K.Hornig, S. Bosecker, M. Kuhrmann(2017):100% 테스트 적용 범위가 타당한 요구 사항인가? 우주 소프트웨어 프로젝트에서 얻은 교훈.인: PROFES 2017.스프링거.마지막 액세스: 2017-11-17
- ^ 마틴 파울러의 블로그:TestCoverage.마지막 액세스: 2017-11-17
- ^ 도프, 리처드 C:컴퓨터, 소프트웨어 엔지니어링 및 디지털 장치, 12장, 페이지 15. CRC 프레스, 2006.ISBN 0-8493-7340-9, ISBN 978-0-8493-7340-4; 구글 북 검색을 통해
- ^ Y.N. Srikant; Priti Shankar (2002). The Compiler Design Handbook: Optimizations and Machine Code Generation. CRC Press. p. 249. ISBN 978-1-4200-4057-9.
- ^ a b RTCA/DO-178B, 항공 시스템 및 장비 인증에서의 소프트웨어 고려사항, 1992년 12월 1일 항공 무선 기술 위원회
- ^ Boris beizer (2009). Software testing techniques, 2nd edition. Dreamtech press. ISBN 978-81-7722-260-9.
- ^ RTCA/DO-178C, 항공 무선 기술 위원회, 2012년 1월.
- ^ ISO 26262-6:2011(en) Road vehicles -- Functional safety -- Part 6: Product development at the software level. International Standardization Organization.
