Test Coverage의 정도 (How much?)

소프트웨어 및 시스템의 Quality improvement의 주요 활동인 Testing은 , 기존의 시스템 및 소프트웨어 개발영역에 포함된 활동으로 인식되어 오다, 현재는 시스템 및 소프트웨어가 복잡해 지면서, 주요한 영역으로 Spotlight를 받고 있다.

그럼 이러한 테스팅에서 커버리는 주요한 이슈이다. 얼마만큼 테스트를 수행을 해야 하냐는 테스팅의 Entry 또는 Exit Criteria로 많이 활용되고 있다.

커버리지 종류에는 간략하게 다음과 같이 분류 할 수 있다.

• 요구사항 커버리지(Requirement Coverage) - 소프트웨어, 시스템의 사양서 기반의 기능/비기능 등의 충족 정도
• 구조 커버리지 (Structure Coverage) - 소프트웨어 Control flow 등 기반의 구문관련 커버리지(Statement, Branch 등)

   -> 일반적으로 소프트웨어 에서 가장 많이 논의되고 있는 테스트 충족도(P-use, C-use, Path, MD/DC, MCC 등)

• 진단 커버리지 (Diagnosis Coverage) - 하드웨어나 시스템의 주요 안전 소자 및 기능에 대한 모니터링 하는 범위로 Safety 분야에서 많이 사용하면, 기능안전에서는 HAM(Hardware Architecture Metric), PMHF 등
• 모델 커버리지 (Model Coverage) - 제어모델, sysML, UML 등의 모델깅 기반의 Structure Coverage를 적용

    Truth table : 모든 decision과 모든 action들의 수행되었는지 판단, 

    Signal range : Min and Max values by a variable during simulation

    안전요구사항의 redundancy를 위한 Switching Mode 및 Decision Mode를 다 만족하는 Coverage는 MC/DC가 가장 유효 하다

   

이 글에서는 주로 구조 커버리지를 기반으로 기술하고, 다음은 요구사항 및 모델 커버리지에 대해 따로 정리한다. 진단 커버리지는 기능안전(ISO 26262)에서 기술하고 있다.

 

 

여하튼 일반적으로 70%~80%가 적정선으로 연구된 논문들이 많다. Empirical Study와 같은 실증적인 논문들에 대한 제안(Proposal)으로 하지만, 이러한 제안(Proposal)도 사실 몇가지 제안된 실험을 통해 제안하고 있다. 그러나, 80%이상의 커버리지를 달성하기 위해서 실제 투입되는 테스트 공수(Testing Costs)대비 산출되는 효과는 작아진다.

즉 80%~90%이상의 커버리지를 달성하기 위해서 소요되는 테스트케이스 개발, Driver 및 Stub 개발, 테스트 수행 및 분석/리포터 비용이 상상을 초월한다.

 

//하지만 아쉽게도 국내 자동차 전장분야는 커버리지 100%가 되어야 한다고 요구를 하고 있다. 이 부분의 가장 큰 문제는 OEM의 정확한 엔지니어링 지식의 부족 및 가이드의 부족으로 발생하는 웃지 못할 현상이다.//