테스트 검증 활동이 오래 걸리는 이유?

이번엔 ISO26262적용 프로젝트 내의 범위에 대한 질문이지만 이전 질문과는 직접적인 연결이 되지는 않는 질문인데, 검증팀에서 검증을 하기 위한 행동을 크게 둘로 나눈다면 테스트 케이스를 만들고 검증 툴에 돌려서 결과를 얻는 거자나, 그리고 이 과정에서 엄청나게 많은 시간이 소모되는 것으로 알고 있는데, 여기서 테스트 케이스를 만드는데 시간이 많이 걸리는 거야 아니면 검증 툴에 만든 테스트 케이스를 넣고 기계가 돌리는 시간이 오래 걸리는거야?

 

 

ISO 26262 프로젝트에서 검증팀의 활동을 크게 두 가지로 나눌 때, 테스트 케이스를 만드는 데 시간이 더 많이 소모됩니다.

---

시간 소모 원인

테스트 케이스를 만드는 과정은 단순히 코드를 확인하는 것을 넘어, 요구사항 분석, 설계, 그리고 안전 목표를 만족하는지 검증하기 위한 시나리오를 구상하는 복잡한 지적 작업입니다. 이 작업에 시간이 많이 걸리는 이유는 다음과 같습니다.

• 요구사항 분석: 기능 안전 요구사항(Functional Safety Requirements)과 기술 안전 요구사항(Technical Safety Requirements)을 명확히 이해해야 합니다. 모호하거나 불완전한 요구사항을 발견하고 개발팀과 소통하며 수정하는 과정이 필요합니다.
• 테스트 시나리오 설계: 단순한 정상 동작뿐만 아니라, 잠재적인 오류 조건, 예외 상황, 고장 주입(Fault Injection) 시나리오 등 다양한 경우를 고려해야 합니다. ISO 26262에서는 고장 주입 테스트가 필수적이며, 이는 매우 복잡한 시나리오를 요구합니다.
• 커버리지 분석: 요구사항 및 코드 커버리지(예: Statement, Branch, MC/DC 커버리지)를 만족시키기 위해 최적의 테스트 케이스 집합을 설계해야 합니다. 불필요한 테스트를 줄이면서도 충분한 커버리지를 확보하는 것은 전문적인 지식을 필요로 합니다.
• 테스트 환경 및 데이터 준비: 테스트 케이스를 실행하기 위한 특정 입력 데이터, 환경 설정 등을 준비하는 데 시간이 소요됩니다.

반면, 테스트 케이스를 검증 툴에 넣고 돌리는 실행 시간은 상대적으로 짧습니다. 대부분의 검증 툴(예: 정적 분석 툴, 동적 분석 툴)은 이미 준비된 스크립트나 설정에 따라 빠르게 결과를 도출합니다. 물론 테스트 대상 시스템의 복잡도나 검증 대상의 크기에 따라 실행 시간이 길어질 수 있지만, 일반적으로 테스트 케이스를 설계하는 인적 공수(man-hours)에 비하면 훨씬 적습니다.

결론적으로, ISO 26262와 같은 고신뢰성 시스템 개발에서 검증팀의 가장 큰 병목(bottleneck)은 테스트 케이스의 설계 및 준비 단계에 있다고 볼 수 있습니다.

 

그러면 시스템 통합 같은 경우 실제로 단품을 가지고 검증을 하는 경우가 있자나 이건 툴에 테스트 케이스가 들어가서 컴퓨터로 연산이 되어서 나오는게 아니라 인간이 하나 하나 단품과 측정기계 사이에 연결을 해서 수행하는거자나? 맞니? 그리고 이 말이 맞다면 이건 테스트 케이스 작성 만큼 테스트 케이스를 검증을 하는 시간이 오래 걸리겠네?

 

네, 맞습니다. 시스템 통합 테스트 단계에서 실제로 단품(부품)을 사용해 검증하는 경우, 이는 컴퓨터 연산만으로 이루어지지 않고 인간의 수작업이 많이 들어갑니다. 따라서 이 경우, 테스트 케이스를 작성하는 시간만큼이나 테스트를 수행하는 데도 상당한 시간이 소요될 수 있습니다.

---

시스템 통합 테스트의 특징

시스템 통합 테스트는 소프트웨어와 하드웨어가 결합된 실제 시스템(단품)을 대상으로 진행됩니다. 이 과정은 다음과 같은 이유로 시간이 많이 소요됩니다.

• 하드웨어 설정 및 연결: 테스트를 시작하기 위해 측정 장비(오실로스코프, 멀티미터 등), 전원 공급 장치, 신호 발생기 등을 테스트 대상 부품과 물리적으로 연결하고 설정해야 합니다. 이 과정은 수작업이므로 많은 시간이 필요합니다.
• 수동 검증 작업: 복잡한 시스템의 경우, 테스트 스크립트만으로 모든 것을 자동화하기 어렵습니다. 특정 동작을 유도하고 그 결과를 육안으로 확인하거나, 계측기를 통해 측정된 데이터를 사람이 직접 기록하고 분석해야 하는 경우가 많습니다.
• 환경 설정 및 재현성 문제: 온도, 습도, 진동 등 다양한 환경 조건에서 테스트를 진행해야 할 수 있으며, 특정 고장 상황을 재현하는 것이 매우 까다로울 수 있습니다. 이러한 작업은 자동화가 어렵고 많은 시간이 걸립니다.
• 문제 발생 시 디버깅: 테스트 중 예상치 못한 문제가 발생하면, 단순히 재실행하는 것이 아니라 하드웨어와 소프트웨어 양쪽을 모두 고려하여 문제의 원인을 파악하고 해결해야 합니다. 이 디버깅 과정은 매우 복잡하고 시간이 많이 소요됩니다.

결론

따라서 시스템 통합 테스트, 특히 하드웨어-소프트웨어 통합 검증은 순수한 소프트웨어 검증과는 달리 테스트 실행(수행) 시간의 비중이 훨씬 더 크며, 이는 테스트 케이스를 설계하는 시간만큼이나 중요한 요소가 됩니다.

 

그렇구나 혹시 너가 "수동 검증 작업"을 설명할 때 말한 테스트 스크립트가 뭐야?

 

네, "테스트 스크립트"는 테스트를 실행하기 위한 일련의 지침을 담은 문서나 프로그램입니다.

---

테스트 스크립트의 의미와 역할

테스트 스크립트는 자동화된 테스트와 수동 테스트 모두에 사용될 수 있습니다.

1. 자동화된 테스트 스크립트:
   • 이는 컴퓨터가 자동으로 실행할 수 있는 프로그래밍 코드입니다.
   • 예를 들어, 파이썬(Python) 같은 언어로 작성된 스크립트는 특정 함수를 호출하고, 예상 결과를 검증하며, 그 과정을 자동으로 기록합니다.
2. 수동 테스트 스크립트:
   • 이는 사람이 직접 읽고 따라할 수 있는 문서화된 절차입니다.
   • 테스트 엔지니어가 특정 순서대로 부품을 연결하고, 스위치를 조작하고, 측정기기의 값을 읽고, 예상 결과와 비교하는 모든 단계를 상세하게 기록해 둔 것입니다.

결론적으로, 제가 "수동 검증 작업"을 언급할 때 말한 테스트 스크립트는 사람이 직접 수행해야 하는 테스트 단계를 상세하게 서술한 문서를 의미합니다. 이는 테스트의 재현성과 일관성을 보장하기 위해 사용됩니다.

 

잠깐만, 자동화된 테스트 스크립트라는 게 컴퓨터가 뭘 자동으로 실행한다는 거야? 즉, 자동으로 테스트 케이스를 만드는 다는 거야? 아니면 인간이 수기로 만든 테스트 케이스를 기반으로 컴퓨터를 통해 단품이랑 연결해서 검증을 한다는거야?

 

자동화된 테스트 스크립트는 인간이 만든 테스트 케이스를 기반으로 컴퓨터가 자동으로 테스트를 실행하는 것입니다.

테스트 케이스를 자동으로 만드는 것이 아니라, 사람이 설계한 테스트 시나리오와 절차를 기계가 자동으로 수행하도록 하는 도구라고 생각하시면 됩니다.

---

인간의 역할: 테스트 케이스 설계

테스트 케이스를 만드는 것은 인간의 고유한 지적 작업입니다. 이 단계에서는 다음과 같은 작업이 포함됩니다.

• 요구사항 분석: 시스템이 어떻게 작동해야 하는지 분석합니다.
• 테스트 시나리오 구상: 정상 작동, 예외 상황, 고장 상황 등 다양한 시나리오를 설계합니다.
• 입력값, 조건, 예상 결과 정의: 각 시나리오에 필요한 입력 데이터와 예상되는 출력 결과를 정의합니다.

이 과정은 시스템의 복잡성을 이해하고, 잠재적인 오류를 예측하는 창의적이고 분석적인 과정이므로 자동화하기 매우 어렵습니다.

---

자동화 스크립트의 역할: 테스트 실행

자동화된 테스트 스크립트는 사람이 만든 테스트 케이스를 컴퓨터가 이해할 수 있는 언어(예: Python, C++)로 구현한 프로그램입니다. 이 스크립트는 사람이 정의한 단계를 자동적으로 반복 수행하며 다음과 같은 작업을 처리합니다.

• 명령어 전달: 테스트 대상 시스템(단품)에 특정 신호나 데이터를 자동으로 보냅니다.
• 결과 측정: 시스템의 응답이나 출력 값을 자동으로 측정하고 기록합니다.
• 결과 비교: 측정된 값이 사람이 정의한 예상 결과와 일치하는지 자동으로 비교하고, 일치하지 않을 경우 오류를 보고합니다.

쉽게 말해, 사람이 작성한 레시피를 보고 로봇이 정확하게 재료를 넣고 요리를 만드는 것에 비유할 수 있습니다. 로봇은 레시피를 만드는 것이 아니라, 레시피에 따라 요리를 실행하는 역할을 하는 것이죠.