(기능안전 23강) 유닛 테스트 / 통합 테스트의 기능안전 포인트

🔍 23강: 유닛 테스트 / 통합 테스트의 기능안전 포인트

안녕하세요, 기능안전 실무자 여러분!
오늘은 개발자라면 누구나 하는 유닛(Unit) 테스트와 통합(Integration) 테스트에
기능안전이 어떻게 녹아들어야 하는지 콕 짚어보겠습니다.

테스트, 그냥 잘 돌면 되는 거 아니냐고요?
그 생각, 오늘부로 완전히 바꿔드릴게요! 😎

“테스트 했으니까 됐죠?”
그렇게 말하고 싶은 마음, 이해하지만!
기능안전은 그냥 테스트가 아닌, 근거 있는 안전 테스트를 요구합니다.
그럼 오늘도 가볍고 즐겁게, 하지만 알차게 출발해볼까요? 😎

---

🧪 유닛 테스트 vs 통합 테스트: 기능안전 관점에서 보면?

항목	유닛 테스트 (Unit Test)	통합 테스트 (Integration Test)
목적	SW 단위 기능의 정확성 검증	모듈 간 연동과 인터페이스 검증
범위	함수, 클래스, 알고리즘	SW-SW, SW-HW 인터페이스
대표 도구	CppUTest, VectorCAST	CANoe, Tessy, LDRA
기능안전 포인트	요구사항 기반 테스트, 커버리지 (MC/DC)	데이터 전파, Fault 전파 확인
실수 사례	assert만 있는 테스트, 조건 빠진 커버리지	타이밍 미확인, 오류 핸들링 누락

기능안전은 그냥 "잘 되냐?"가 아니라 "고장 나도 괜찮냐?"를 테스트하는 겁니다!

---

✅ 유닛 테스트, 왜 중요할까?

유닛 테스트는 소프트웨어 구성요소(함수, 모듈 등) 단위에서 수행하는 테스트로,
요구사항 충족 여부 + 에러 발생 가능성을 미리 잡는 역할을 합니다.

🔍 기능안전 포인트 in 유닛 테스트

항목	기능안전 고려 포인트
테스트 커버리지	ASIL B 이상에서는 Statement + Branch, ASIL D는 MC/DC까지!
경계값 테스트	"0, -1, Max+1" 꼭 넣어주세요! 버그는 경계에서 춤춥니다 💃
Fault Injection	ASIL C/D에서는 예외 상황 테스트 필수! 예: 센서 미응답 시 동작
정적 분석 연계	MISRA-C, AUTOSAR C++ 체크는 필수!

💡 팁: 유닛 테스트에도 traceability! SSR(Software Safety Requirement)과 어떻게 연결되는지 명확하게!

---

✅ 유닛 테스트의 기능안전 포인트

1. ASIL 등급에 따라 커버리지 수준이 달라요!
   • ASIL A: Statement or Branch Coverage
   • ASIL D: MC/DC (Modified Condition / Decision Coverage) 필수!
2. 단위 기능은 독립적 테스트 가능해야 해요!
   • 하드웨어 의존적인 테스트를 mock 처리하지 않으면 안 돼요.
3. 테스트 케이스는 요구사항 기반이어야 해요
   • “걍 돌려봤는데 되던데요?”는 ISO26262에서 금지어입니다 😅
4. 테스트 로그는 무조건 남겨야 합니다!
   • 통과/실패 기록, 실패 시 원인 분석 로그 필수

---

🔄 통합 테스트, 그냥 묶어서 테스트하면 끝?

아니죠!
통합 테스트는 두 모듈 이상이 연결되면서 발생하는 인터페이스 문제를 찾아내는 자리입니다.
특히 기능안전에서는 데이터 흐름, 오류 전파, 예외 처리가 포인트!

🛠️ 통합 테스트에서의 기능안전 전략

테스트 전략	기능안전 포인트
Interface Test	안전 관련 신호(예: fault flag)의 전송 여부와 해석 정확도 확인
Error Handling Test	에러 발생 시 모듈 간 책임 분담 및 처리 흐름 확인
Watchdog/Timeout Test	통신 실패, 응답 지연 등 타이밍 관련 실패 조건 검증
상태 전이 테스트	여러 모듈이 협력하여 특정 상태를 유도/차단하는 흐름 검증

📢 특히 ASIL C 이상은 인터페이스 신뢰성이 치명적입니다. "값을 주는 쪽"보다 "받는 쪽"이 더 꼼꼼해야 해요!

---

🛠️ 통합 테스트의 기능안전 포인트

이제 진짜 실무 느낌 납니다!
통합 테스트에서는 ‘모듈 간 연결’이 핵심이고, 기능안전에서는 그 연결이 얼마나 안전하게 이어지는지가 포인트예요.

🔑 핵심 4가지 포인트

포인트	설명
1. 인터페이스 정합성	데이터 타입, 값 범위, 타이밍 체크
2. 오류 전파 방지	한 모듈의 오류가 다른 곳에 영향 안 주도록
3. Fault Injection	일부러 오류 발생시켜 시스템 반응 확인
4. 진단 기능 검증	오류 발생 시 진단 코드가 잘 뜨는지 확인

---

🎯 실제 사례 예시

📍 “브레이크 시스템과 차량속도 정보 연동 오류”

문제: 속도 센서 정보가 NULL 상태인데도 테스트 통과
이유: 유닛 테스트는 다 통과했지만, 통합 시 센서 인터페이스 검증이 없었음!
결과: 안전 요구사항 위반 → 고객사 심사에서 치명적 결함

👉 해결 방법:

• Fault Injection 테스트 포함
• 인터페이스 Null-check 추가
• 통합 테스트 케이스에 진단 검증 추가

---

🛡️ 실무자가 꼭 챙겨야 할 기능안전 체크리스트

✅ 테스트 계획서에 ASIL 반영했나요?
✅ Safety 관련 인터페이스는 통합 테스트에 포함됐나요?
✅ Fault Injection 시나리오는 실현 가능한가요?
✅ 테스트 결과는 traceability로 연결되나요?
✅ 실패한 테스트는 리뷰 후 대응했나요?

📄 테스트도 '기능안전 활동'입니다.
인증 심사에서 가장 먼저 보는 게 테스트 결과라는 거, 알고 계시죠?

---

🔚 오늘의 요약!

✅ 유닛 테스트는 기능 정확성 + ASIL 수준 커버리지
✅ 통합 테스트는 모듈 연동 + 오류 전파 차단
✅ 둘 다 잘해야 진짜 기능안전 테스트!

---

🔜 다음 강의 예고!

“FMEA, FTA, DFA – 고전 기법의 현대적 활용”
오래됐다고 무시하면 안 돼요!
기능안전 분석의 3대장, 실무에서 어떻게 쓰이는지 알려드립니다!

그럼 다음 강의에서 만나요~ 🎉