Code Coverage는 소프트웨어 테스트가 어느 정도 수행됐는지를 의미합니다.

Coverage의 종류로는 Statement, Branch, MC/DC, Function, Function Call 등이 있으며,

Coverage Test는 국제 표준인 ISO 26262에서 규정하고 있습니다.

​

ISO 26262 Part 6의 Table 9와 Table 12를 보면 Branch, MC/DC, Function, Call은 ASIL D에서 ‘++’ 표시가 된 것을 확인할 수 있습니다. 여기서 ‘++’는 필수적으로 수행해야 하는 것을 의미하는 표시로, Coverage Test가 매우 중요한 검증 과정이란 것을 알 수 있습니다.

​

[그림 2]는 BTC社 EmbeddedPlatform을 활용하여 Coverage Test를 수행한 결과입니다.

Condition Coverage를 보면 테스트 결과가 75%인 것을 확인할 수 있으며, 여기서 75%는 Test Case로 전체 분기문 중에서 75%만 수행했다는 것을 의미합니다. 즉, 추가적인 작업을 통해서 Condition Coverage를 높일 필요가 있습니다.

​

Coverage를 높이기 위해서는 Stimuli vector generation 속성을 변경하여 추가적으로 stimuli vector를 생성해야 합니다.

여기서 “Stimuli vector”는 다른 Tool에서 사용하는 Test case에 해당됩니다. 생성 기준 없이 Stimuli vector를 추가하는 것은 무의미하지만, PLL(Property Location Language) 기능을 활용하면 효율적으로 Coverage를 높이는 Stimuli vector를 생성할 수 있습니다.

​

PLL(Property Location Language)은 Coverage goal에 해당되는 지점을 알려주는 기능입니다. PLL 값을 활용하여 Stimuli vector를 생성하면 해당되는 Coverage goal을 만족시키도록 분석이 가능합니다.

​

[그림 3]은 Code Coverage의 Unknown을 나타내는 화면입니다. “Unknown”은 생성한 Stimuli vector로 해당 구문을 수행할 수 있는지 없는지를 판단할 수 없는 상태를 말합니다. 이러한 문제를 해결하기 위해 추가적으로 Stimuli vector를 생성하여 수행 가능한 구문인지 Dead code 인지 판별해야 합니다.

​

[그림 3]의 C:160(PLL)을 보면 코드상 1854 line에서 Unknown이 발생한 것을 확인할 수 있습니다.

이는 [그림 4]와 같이 Source Code에서도 직접 확인이 가능합니다.

​

​

​

[그림 3], [그림 4]의 정보를 바탕으로 [그림 5], [그림 6]과 같이 Coverage goal, Step, Timeout 등을 설정하면 코드를 자세히 분석할 수 있습니다.

[그림 7]을 보면 PLL을 통해 적절한 Stimuli vector를 생성하여 커버리지가 증가한 것을 확인할 수 있습니다.

​

​

[그림 7]에서 “Condition Coverage가 100%”라는 것은 소프트웨어가 결함이 없는 상태임을 의미하는 것은 아닙니다. 다시 말해 요구 사항에 맞게 소프트웨어가 동작하는 것이 아니라, 단순히 코드상에 있는 모든 분기문을 수행했다는 의미입니다.

​EmbeddedPlatform을 활용하면 ISO 26262에서 요구하는 Coverage Test가 가능하며 PLL 기능으로 커버리지를 손쉽게 증가시킬 수 있습니다.

▶ BTC EmbeddedPlatform 자세히 보기

▶ 출처:자동차 SW 블로그