심사를 하다 보면, 빅뱅(Big bang) 통합을 수행하는데 왜 통합 및 통합 테스트 프로세스가 충족이 되지 않느냐고 물어보는 조직이 있습니다. 또, 소프트웨어 단위와 단위 테스트 내용에 대해 혼란과 수행에 어려움을 겪는 경우도 종종 목격하게 됩니다. 여기서는 Automotive SPICE® 관점에서 통합, 단위 테스트를 중심으로 테스트 레벨에 대해 논의해 보고자 합니다.
우선 논의를 쉽게 하기 위하여 다음과 같은 약어를 정리합니다.
UT: Unit Test, IT: Integration Test, QT: Qualification Test, AD: Architecture Design, DD: Detailed Design
통합 테스트 (Integration Test)
먼저, 통합과 통합 테스트를 분리해서 생각해야 합니다. 통합된 상태에서 각 구성요소 간의 상호작용과 그것들의 설계된 거동을 테스트할 수 있다면 빅뱅 통합이라도 통합 테스트를 수행하는 것입니다. 그렇지 않다면 통합 테스트는 수행되지 않는 것입니다. 빅뱅으로 한 번에 통합하니까 통합 및 통합 테스트가 (심사 범위에) 해당되지 않는다는 말은 적절하지 않습니다.
한편, 통합 테스트가 그다지 필요하지 않아 수행하지 않는다고 하면, 심사의 목적과 범위를 명확하게 할 필요가 있습니다.
자체적인 프로세스 개선을 목적으로 하는 것이면 심사 범위에서 제외하면 됩니다. 경우에 따라 통합 및 통합 테스트에 대한 심사원의 피드백을 얻기 위해 심사 범위에 넣어 보는 것도 좋습니다. (이왕에 돈과 시간을 들여 심사를 받는 것이므로 하나라도 더 측정해 보면 나쁠 것이 없겠습니다.)
만약, 고객의 요구 등으로 프로세스 관련하여 제품의 품질 리스크를 평가하는 측면에서 하는 심사라면 이제 통합 테스트를 하지 않는 것이 품질 리스크를 증가시키지 않는다는 것을 증명할 필요가 있습니다.
논리적으로 통합 테스트가 필요 없는 경우는 크게 두 가지가 있을 수 있습니다.
첫째는 테스트 대상이 내부 구성요소들을 파악할 필요가 없을 정도로 간단하면 필요 없습니다. 이것은 사실 대상 자체가 ‘단위’가 됨을 의미하므로 이 기사의 논지에 맞지 않습니다.
둘째는 구성요소들이 통합된 상태에서, 요구사항에 대해 테스트(QT)를 수행하면서, 모든 구성요소 간의 상호작용을 충분히 포함하도록 테스트되었음을 밝힐 수 있으면 통합 테스트가 필요 없습니다.
대체로 통합된 상태에서의 기능이 수행된다면 각 구성요소가 제 기능을 한다고 인정을 할 수는 있겠지만 구성요소들 간의 거동이 완전하다고 보장하기는 어려울 것입니다. 이론적으로는 각각의 거동과 거동들의 묶음을 모두 봐야 합니다. 특히, 설계에 구성요소 간의 Timing 요건 등이 있으면 더욱 그럴 것입니다.
개발하고 있는 제품(시스템이건 소프트웨어이건)을 QT하면서 위에 언급한 내용을 수행하고 밝힐 수 있으면 결국, 빅뱅 통합 전략을 사용한 것이고 통합 테스트가 된 것으로 볼 수 있습니다. (심사원은 QT활동에서 IT가 수행되고 있음을 인정할 것입니다.)
구성요소(Component)와 단위(Unit)
시스템 공학에서 시스템 계층 원리는 이미 알려져 있는 사실입니다. 시스템의 시스템, 또 그 시스템의 시스템 등… 높은 수준으로 올라가는 데는 끝이 없으므로 컨텍스트 경계(Context Boundary)와 시스템 경계(System Boundary)로 개발할 시스템을 한정하는 것이 필요합니다. 아래로 내려가는 것도 사실은 분자, 원자, 쿼크, 기본입자 등등 끝이 없지만 더 이상 그 내부의 구성요소를 파악할 필요가 없는 수준의 것을 최하위 시스템 요소로 보면 되겠습니다. 소프트웨어 공학에서는 아래로 내려가는 한계를 ‘단위’라는 것으로 제한해 놓았습니다. 예를 들면, Automotive SPICE®에서는 소프트웨어의 가장 작은 요소가 컴포넌트이고 하나의 컴포넌트는 한 개 또는 그 이상의 단위(Unit)로 구성된다고 설명하고 있습니다.
위 그림은 간단한 시스템의 계층적 분해도 입니다. 이 시스템의 계층 중간 쯤에서 하나의 일반화된 요소(구현물, Sn)를 선택해 봅니다. 무엇을 선택하든 그 요소에는 요구사항, 설계가 있고 그것들 간의 삼각관계가 있습니다. 아래 그림에서 보는 바와 같이 요구사항(Requirements) – 설계(Design) – 구현물(Sn)과 점선으로 나타난 관계들입니다.
- 요구사항 – 구현물 간의 관계: 구현물이 요구사항을 충족하는 관계입니다. 이것은 대개 QT로 검증합니다.
- 설계 – 구현물 간의 관계: 설계대로 구현물이 만들어져야 합니다. 이것은 보통 IT로 검증합니다. (구성요소들이 설계한 대로 통합되었는지)
- 요구사항 – 설계 간의 관계: 설계는 요구사항을 만족해야 합니다. 이것은 ‘?’로 표현된 활동으로 검증합니다. 즉, 설계 검증(Design Verification, DV) 입니다.
그런데, 어느 정도 복잡한 시스템(요소)이라면 그것의 설계가 요구사항을 만족하는지 설계 정보만 갖고는 완전하게 알기 어렵습니다. 즉, 만들어서(구현하여) 시험(IT, QT)을 해봐야 합니다. 또, 이론적으로는 3가지 관계 중 2가지가 확실하면 (마치 삼단논법처럼) 나머지도 믿을 수 있습니다. 그러므로 설계를 직접 검증하지 않더라도 IT와 QT를 통해 설계가 요구사항을 만족하는 것을 간접 입증할 수 있습니다. 설계 대로 만든 구현물이 요구사항을 정확하게 만족한다면, 설계가 검증된 것이고 이럴 경우, 설계는 요구사항을 빼놓지 않고 모두 만족한다고 말할 수 있습니다.
단위 테스트 (Unit Test)
위의 요구사항 – 설계 – 구현물 관계를 포함하여 아래와 같이 계층 구조를 다시 그려보고 이제 가장 하위 수준으로 가보겠습니다.
위 그림에서 단위(S11)는 더 이상 그 내부구성요소를 파악할 필요가 없습니다. 따라서, 설계(DD_s11)에 대해 구현된 단위를 테스트할 때 그것은 더 이상 IT라 하지 않고 UT라고 합니다.
그럼 여기서 활동A(S11이 REQ_s11을 만족하는지 검증)가 필요할까요? 이상적으로, UT는 설계에 기반하여 테스트케이스를 생성하고 수행하면 됩니다. “어! 그래도 되나?”하는 의문이 든다면 실무를 해본 사람입니다. ISO 26262 자동차 기능안전 규격도 소프트웨어 단위 테스트에 요구사항에 기반한 테스트를 강하게 권고하고 있습니다. 그렇지만, 추가적인 논의를 위해 잠시 더 현실을 떠나서 이야기해 봅시다.
만약, 활동B(DD_s11이 REQ_s11에 일치 하는지 검증)를 완벽하게 수행할 수 있다면?
즉, 설계가 (단순하여) 구현물 없이 설계만으로 요구사항의 만족 여부를 검증할 수 있다면, 어떻게 될까요? 삼단논법처럼 활동B와 UT를 통해 그 관계들이 확실하면 활동 A가 반드시 필요하다고 할 수는 없습니다.
소프트웨어 단위라는 것은, 첫째, 소프트웨어 아키텍처의 최소 수준(atomic level)의 구성요소로서 더 이상 그것의 하위 구성요소들을 파악할 필요가 없는 것입니다. 둘째, 모든 것이 결정되어 있어 설계 만으로 구현을 할 수 있는 요소입니다. 세째, 단위에 부과된 요구사항을 따르는 지 설계만으로 검증할 수 있으며 독립적(stand-alone)으로 검증할 수 있는 것입니다.
그러므로 구현된 단위를 테스트할 때는 설계대로 되었는지만 검증하면 됩니다. 즉, 설계를 이용한 테스트면 됩니다. (White box testing) 이것은 대개 완전한(Exhaustive) 테스트가 가능하므로 단위 테스트를 거친 단위는 결점이 없다고 보는 것입니다. 이후 발생하는 문제는 통합 상의 문제일 것입니다.
이상적으로 소프트웨어 단위 설계는 내부 구성요소를 다루지 않아야 하고, 구현 가능해야 하며, 구현 없이 설계만으로 대상의 요구사항이 충족되었는지 알 수 있을 정도로 기술되어야 합니다.
Automotive SPICE® V3.1 SWE.4 Software Unit Verification(소프트웨어 단위 검증)의 Process purpose(프로세스 목적)을 보면 아래와 같습니다.
The purpose of the Software Unit Verification Process is to verify software units to provide evidence for compliance of the software units with the software detailed design and with the non-functional software requirements.
NOTE 1: Possible techniques for unit verification include static/dynamic analysis, code reviews, unit testing etc.
Automotive SPICE®에서 소프트웨어 단위 테스트를 포함한 단위 검증은 구현된 단위가 상세 설계를 준수한 증거를 제공하는 것이 목적입니다. 그러므로 설계를 이용한 테스트면 족하지만 어디까지나 이상적인 것입니다. (여기서, 비기능 요구사항은 예를 들면, MISRA rule 같은 것입니다.)
Conclusions
빅뱅 통합이라 IT를 수행하지 않는다고 할 때 아래 조건에 하나라도 해당이 된다면 품질 리스크가 증가된다고 봐야 합니다.
- QT를 수행하면서 구성요소들의 모든 상호작용이나 거동을 충분히 다루었다고 입증하기 어려운 경우
- 단위 설계 명세가 완전하지 않거나 단위의 식별 수준이 상대적으로 높아 설계에 의한 검증이 실효적이지 않은 경우
품질 리스크를 줄이려면 적절한 통합 및 통합 테스트 전략이 수립되고 수행되어야 하며 그러한 전략은 단위에 대한 요구사항 개발과 그에 대한 QT도 적절히 포함하게 될 수 있습니다.
참고 문헌
- Automotive SPICE® V3.1
- CMMI® V2.0
- ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes
- ISO 26262-6 Road vehicles — Functional safety — Part 6: Product development at the software level