1일차 리뷰
V&V
- Verification : 요구사항 명세서 기준 검증
- Validation : 고객 기준 검증
SW 테스트
- 결함의 발견을 목적으로 소프트웨어를 테스트하는 것
에러(Error)
- 결함의 원인으로 사람에 의하여 생성된 실수가 주를 이룸
결함(Defect)
- 실패/고장 또는 문제의 원인으로 제품에 포함된 결점
실패/고장(Failure)
- 결함으로 인해 고장이 난 상황
정적(Static) 방법 vs 동적(Dynamic) 방법
- Static : 소프트웨어 실행 시키지 않고 결함 발견
- Dynamic : 소프트웨어 실행하여 결함 발견
테스트 베이시스
- 테스트 케이스를 작성하기 위한 근거 산출물
테스트 케이스(동적 test 검증을 위해 작성, 정적 test에서는 작성 x)
- 요구사항 검증을 위해 테스트 조건, 입력 값, 예상 출력 값, 실제 수행한 결과 기록
테스트 커버리지(Coverage)
- 테스트 케이스 수행 시 테스트 대상을 몇 %나 실행했는지 알려주는 지표
목표, 대상, 환경, 테스트 수행 방법 ⇒ 이 네 가지를 포커스로 테스트를 진행한다.
- 레고 집을 SW라 한다면, 설명서가 존재하는 데 , 이때 집의 구성 요소인 지붕, 벽, 바닥을 모두 합쳐 아키텍처라고 한다.
- 그렇기에, SW 아키텍처는 우리 SW가 어떻게 구성이 되어있는지 전체가 아키텍처
- 여기서 지붕, 벽, 바닥은 각각 컴포넌트라고 한다. 동일한 기능을 수행하는 애들끼리 묶어둔 것.
- 쪼개다 보면 더 이상 쪼갤 수 없는 레고 파츠까지 갈 것이다. 이를 Unit이라고 한다.
- componenet는 물리적인 단위가 아닌, 개념적인 단위이다. 구성 요소이다.
- Unit은 Componenet가 아닌가? 그건 아니다. Unit도 Component이지만, 더 이상 쪼갤 수 없는 Component일 뿐이다.
RPAS(Remote Parking Assistance System) ⇒ 원격주차지원시스템
시스템 차량
서브시스템 샤시 Body 제어 전자
ADAS
PAS(주차 보조 시스템)
LKAS,RPAS( = Sensor + ECU +Actuator)
( HW, SW) SysRs SysRS
“RPAS는 원격 통신만 하고 구동은 하지 않는다. 구동은 PAS에서 할 것이다.” 라고 시스템의 범위를 정한다.
RPAS에서 원격 통신할 때 이 부분까지는 SW, 이 부분까지는 HW에서 하겠다.
SW가 어떤 기능을 할지 정해둔다.
SwRs / SwA.D
SysRS 기준으로 작성, 스마트폰 앱, 스마트 키를 통해서 RPAS의 입력값을 줌.
그렇기에, 입력값 처리를 위한 기능이 필요(UI 처리)
원격 제어, 신호 해석하기 위한 기능이 필요, ex) “후진” ⇒ 신호를 유지하고 기어를 R로 바꾸고, 뒤로 속도는 10km 정도로 이동하라
PAS 시스템과 연계하여 값을 처리해야 하기에, PAS 시스템과의 연결을 위해 통신값 변환
⇒ 위 과정에서 Component는 블루투스 수신 Unit, 명령 해석 Unit, 통신값 반환 Unit, function 단위로 묶어주면 입력값 처리에는 뭐 블루투스 수신 Unit + 명령 해석 Unit 이런식으로 Component를 기능별로 구성할 수 있다.
⇒ 아키텍처는 전체 설계를 그린다.
전체 소프트웨어는 세 가지 파트로 구성되어 있다.
UI처리 Component, 원격 제어 분석 Component, PAS 시스템과 통신하기 위한 Component
시스템과 시스템 사이 데이터를 주고 받거나 통신을 할 때를 인터페이스라고 한다. 내부에 있으면 내부 인터페이스, 외부와 연결되어 있으면 외부 인터페이스.
상세 설계 : 한 함수에 대한 내부 알고리즘 처리에 대한 명세
구현 : 코드 구현
단위 테스팅 : Unit 별 기능 동작 확인
통합 테스팅 : Component 기능 동작 확인
시스템 테스팅 : Component가 모인 시스템 동작 확인 , RPAS 시스템이 제대로 동작하는지 확인
인수 테스팅 : 차량 동작 확인
SWE.4 Software Unit Verification - 단위 테스트(Unit Test)
-
설계된 모듈(=function), Unit을 대상으로 정확히 구현되었는지 확인, 상세 설계에 작성된 input, output,
-
정상 확인이 목적 ⇒ 다른 테스팅이 결함 발견이 목적인 것과 다름 ⇒ 단위 테스팅은 테스터가 아닌 개발자가 수행한다.
-
input, output이 정상적인가, 알고리즘이 정상 수행되는가를 확인
-
개발자가 더 이상 오류가 없다고 판단할 떄까지 수행 ⇒ ISO26262에서는 coverage가 모두 100%가 될 때까지 수행해야 한다.
-
그렇기에, 이제는 개발자가 단위 테스트 역시 수행 가능해야 한다.
-
테스팅 할 모듈을 단독적으로 실행할 수 있는 환경 필요
- 테스팅 드라이버(테스팅 대상 모듈을 호출하는 환경) ⇒ 스텁(Stub) : 테스팅 대상 모듈에서 호출하는 모듈 ⇒ 우리가 실제로 해보려면 google test에서 gmoc으로 스텁을 만드면서 가능하다.
- 구글 테스트와 같은 테스트 프레임 워크를 사용하면 쉽게 사용 가능하다.
-
상세 설계를 기준으로 소프트웨어 단위(유닛)과 소프트웨어 상세 설계와의 일관성을 검증함
-
SWE.3을 대상으로 진행한다.
-
ISO 26262의 단위 테스팅 실행 환경
- Host(노트북) : 개발하는 환경, Target(ECU) : 실제 개발되는 환경
- 타켓 환경에서의 실행을 고려하되, 불가능한 경우 환경 차이를 분석하여 이후 테스트 단계에서 추가 테스트 수행
- Model-in-the-loop tets(MIL)
- Software-in-the-loop tests(SIL) ⇒ 젤 많이 함
SWE.5 Software Component Verification and Integration Verification - 통합 테스팅(Integration Testing)
- Unit 테스트가 실행되었다 했을 때, 각각의 Unit이 정상적으로 작동하는지는 확인했다.
- 이제는 각 Unit을 Interface를 기준으로 진짜 연결 시켜가면서 테스트하는 게 통합 테스트이다.
- 주 목적은 Interface test. Interface에서 결함이 있는지 없는지 확인한다.
- 순차적으로 통합을 진행한다. 왜? 한 번에 테스팅하면 어느 Interface에서 결함이 발견돼는지 알 수가 없기 때문이다. 언제까지? 하나의 Component가 되어 연관 기능이 모여 하나의 전체 기능이 될 때까지
- 통합과 함께 같이 통합 테스트를 진행한다.
- 개발된 단위 모듈 소프트웨어들을 통합 계획에 따라 통합하여 완전한 소프트웨어 구조를 개발하는 활동이다.
- 3.1과 4.0 차이점 : integration verification , software elements 통합하고, verification 통합, perform software verification
하향식 기법과 상향식 기법은 통합 방향, 지속적 통합은 통합 시기에 집중
- 하향식(Top-Down) 기법 : 가장 상위 모듈부터 하위 모듈로 점진적으로 통합하는 방법
- 상위 모듈에서 내려오니까 “스텁”이 필요할 것이다.
- 상향식(Bottom-Up) 기법 : 하위 모듈부터 테스팅하고 상위 모듈로 점진적으로 통합하는 방법
- 하위 모듈에서 올라가니까 “테스트 드라이버”가 필요할 것이다.
- 지속적 통합(CI/CD) : 지속적 통합은 뭘까? SW 통합 오류를 개발 초기부터 예방하는 것이다. 사람보다는 도구를 기반으로 진행한다.
⇒ 그럼 지속적 통합은 하향식 기법, 상향식 기법과 관계 없이 같이 진행할 수 있는 것인가?
- 통합 오류 : 통합 빌드, 정적 분석, 테스트 커버리지, 함수 복잡도
- 개발 초기 : 코딩 시작한 날
- 예방 : 문제 발생 시 당일 조치
- git의 목적은? 소스 코드 버전 관리 → commit을 통해서 내가 뭘 변경했는지, 다른 사람이 뭘 변경했는지 확인 가능
- 가상환경(VM/Container) 의 존재 이유 : OS가 단종되거나 사라지는 경우를 대비하기 위함도 있고, 기기가 달라지거나 버전이 달라졌다 해도 가상화를 해두면 언제든 build가 가능하므로 예방의 개념으로 구성해둔다 생각하면 될 것 같다.
- ISO26262의 통합 테스팅 실행 환경 : 타켓 위에 통합 테스트는 쉽지 않기에 SIL 혹은 PIL을 사용
- SW Unit간 통합은 Architecture를 기준으로 실행한다.
SWE.6 The purpose of the Software Verification process is to ensure that the integrated software is verified to be consistent with the software requirements →시스템 테스팅(System Testing)
- 모듈이 모두 통합된 후, 사용자의 요구사항이 만족되었는지 검사하는 테스팅
- 고객에게 시스템 전달하기 전, 시스템 개발한 조직이 주체가 되는 마지막 테스팅
- 수행주체 : 테스터(제 3자)
- 형상관리에서 branch 관리 ⇒ dev, 운영 branch를 따로 파서 사용, test branch는 왜 안 쓰는가? test branch는 결함의 발견을 위해 사용하므로 개발자가 JIRA에서 확인
- ECU를 실제 환경에 올려서 테스트를 시행하는 것을 중시함.
- SWE.1 ↔ SWE.6 ⇒ Performances는 CPU, Memory, Service 지연 시간은 어느 정도 되는지 측정 타겟에 올려서 실행할 것을 강력하게 권고함.
- Overview, General SW description, SW functional requirements, SW safety requirements, Quality attribute, Other requirements, Constraints(제약 사항) 이 요구사항에 들어가야 할 요소들이다.
비기능요구사항은 별도의 테스트 케이스보다는 기존 테스트 케이스의 기능을 함께 실험해보는 식으로 작성한다.
- ISO 26262 소프트웨어 테스팅 수행 환경 : 최소 HIL 이상의 테스트 환경을 요구. (Lab car, Mule, Rest of bus)
- Lab car : 실험실에 있는 자동차, 주행은 불가
- Mule : 실험실에 있는 자동차, 실제 주행 가능함, 실제 뼈대까지 존
- Rest of bus : ECU만 HW에 넣고 나머지는 SW로 돌리기, CANoe
인수 테스팅(Acceptance Testing)
- 시스템이 사용자에게 인수되기 전, 사용자에 의해 실시되는 테스팅
- 실제 사용자가 운영하는 환경에서 실시 ⇒ Lab car, mule처럼 실험실 차량이 아닌 실제 도로에서 실제 차량으로 실험을 진행한다.
- 인수 테스팅을 통과해야만 시스템이 정상적으로 사용자에게 인수되고 프로젝트는 종료됨.
- 대표적인 인수 테스트(알파 테스트, 베타 테스트)
- 알파 테스트 : 개발팀이 진행
- 베타 테스트 : 사용자에게 미리 배포
Validatoin test ⇒ 4.0에추가됨
- End product, 사용자가 실제 사용하는 소프트웨어
- 최종 제품이 운영 대상 환경에게 의도된 사용 기대를 충족함을 보장함
동적 테스트
동적(Dynamic) 테스트
- 소프트웨어를 실행하여 결함을 찾아냄
- 발견된 결함은 디버깅 활동으로 확인하여 수정함
- 대표적인 방법 : 테스트 명세기반 테스트(black-box test), 구조기반 테스트(white-box test), 경험기반 테스트( = 최선의 노력과 최신의 기술을 사용했음을 증명하기가 어려움) ⇒ 그렇기에 명세 기반 테스트와 구조 기반 테스트가 주를 이룸
테스트의 목적
- 프로그램이 사용할만 한 것인지 확인하기 위해 “결함을 발견할 목적”으로 프로그램을 실행하는 것
테스트 순서
-
테스팅 : 결함의 발견
-
디버깅 : 결함 수정(해결)
-
재테스팅 : 결함 해결 확인
- 목적 : 발견된 결함이 정상적으로 조치되었는지 확인
- 수행 : 결함 발견자(테스팅 담당자)
- 수행 시기 : 담당 개발자가 결함이 조치되었다고 전달할 때
⇒ 재테스팅의 범위는?
- 결함이 발생한 항목만? or 전체 항목 테스트?
- 결함 발생한 항목만 테스트 = Confirmation(확인) Test
- 전체 항목 테스트 = Regression(회귀) Test
회귀 테스트(Regression Test) 정의
- 정상 동작하던 기능이 SW 수정 후 문제가 발생하는 회귀 결함 유무 확인하기 위해 이전 테스트 케이스 다시 실행하며 확인하는 테스트
회귀 테스트 수행 방법
-
자동화된 테스트 수행 권고
- 자동화된 이전의 테스트 케이스(스크립트)의 실행
- 수동 테스트로 진행하기엔 비용/인력/시간에 대한 제약
-
주기적인 회귀 테스트 수행
- 신규 Commit 시 수행 : 프로젝트 크기가 작은 경우
- 일/주 단위 수행 : 프로젝트 크기가 큰 경우
-
지속적인 통합과의 연계
Myers’ 소프트웨어 테스팅
- 좋은 테스트케이스(test case)란?
- 결함을 많이 발견하는 테스트케이스
- 결함을 하나도 못 발견하는 테스트케이스는?
- 자원의 낭비와 마찬가지이다.
동적 SW 테스트 설계 기법의 종류
명세 기반 테스트(Black-Box)
- 소스 코드 자체 로직(logic)은 제외하고, 출력 값에만 초점을 두고 테스팅
- 요구사항 명세서나 설계서로부터 테스트 케이스 추출 ⇒ 시스템 테스트에서 주로 사용
구조 기반 테스트(White-Box)
- 소스 코드 내의 모든 독립적인 경로 수행
- 내부구조(소스 코드) 기반으로 테스트 케이스 추출 ⇒ 단위(Unit) 테스트에서 주로 사용
ASIL 등급
1. ASIL 결정 기준
기능 고장이 미치는 위험도를 평가하기 위해 세 가지 요소를 Severity(심각도, S), Exposure(노출빈도, E), Controllability(제어가능성, C)로 따져 ASIL을 산정합니다.
- S (Severity)
- S0: 무해
- S1: 경미한 부상
- S2: 치료가 필요한 부상
- S3: 인명 치명적 부상
- E (Exposure)
- E0: 거의 발생하지 않음
- E1: 비정기적으로 발생
- E2: 종종 발생
- E3: 자주 발생
- E4: 거의 항상
- C (Controllability)
- C0: 전혀 위험하지 않음
- C1: 대부분 운전자 제어 가능
- C2: 일부 운전자 제어 어려움
- C3: 운전자 제어 거의 불가능
이 세 값을 조합해 ASIL QM(품질관리) 또는 A~D 중 하나로 결정합니다.
ASIL A vs B vs C vs D 요약
- 프로세스 강도: A→D로 갈수록 안전 계획·검증·도구 활용·조직 독립성 강화
- 검증 범위: A는 주로 단위 수준, D는 통합·시스템·HW까지 포함
- 커버리지 목표: A는 분기 커버리지, D는 100% MC/DC(동적 다변수 결정 조건) 등
- 도구·방법론:
- ASIL A: 표준 빌드·테스트 도구
- ASIL D: ISO 26262 인증된 도구, 형식 기법(Formal Methods) 권장
어떤 테스트를 수행해야 하는가?
- Requirements-based test : 얘가 제일 기본이고 중요함
- Interface Test : 얘도 기본
Inferface Test(인터페이스 테스트)
- 단위 테스트 수준에서 모듈에 대한 입력의 올바른 처리 여부 검증
- 유효 입력값/비유효 입력값
- 테스트 드라이버와 스텁 필요
- 인터페이스에 오류가 없음을 검증하기 위한 테스트
- 통합 테스트 수준에서 다른 모듈과의 연계를 위한 출력 검증
- 테스트 절차 : 테스트 대상 인터페이스 식별 → 인터페이스 입력값 생성 → 테스트 결과 확인
백투백(Back-to-Back) 테스트 ⇒ MBD(Model Based Device)라면 필수적이다.
- MBD는 Model에 설계를 집어넣으면 코드가 자동적으로 생성되는 방식이다.
- 두 개 이상의 테스트 대상 시스템에 동일한 입력값으로 실행하여 결과를 비교 분석하는 테스트 기법
- 두 개 이상의 환경에서 동일한 테스트 케이스를 테스트 했을 때 결과가 모두 동일한가를 비교
- SW 모델과 소스코드, 시뮬레이터와 실제 타겟 보드에서 사용됨
“앞으로는 설계를 어떻게 하는지가 더 중요하다고 한다.”
“AI를 활용해서 코드 작성 잘 해보기” ⇒ Cursor, Claude : 이 둘이 코드를 짜는데는 유용하다고 한다.
결함주입(Fault Injection) 테스트
- 설계의 안전 매커니즘이 올바로 동작하는지 확인하기 위해 임의의 결함을 주입하는 테스트
- 인위적인 결함 발생시켜 예외 상황에서의 시스템 동작 확인하기 위함
- 일반적으로 error handling에 사용된다. 우리가 설정한 Safety Mechanism이 정상적으로 동작하는지 확인하고 싶은 것이다.
- 결합 주입의 2가지 방법
- __.cpp ⇒ (compile) ⇒binary code ⇒ (runtime) ⇒ ECU
- 컴파일 시간 결함 주입 : 변수 값, 소스코드 변경
- 실시간(런타임) 결함 주입 : CPU 레지스터, 메모리 값 변경
⇒ 시스템 테스트 단계에서 ECU에 올릴 때 레지스터 값을 바꿔가면서 에뮬레이터 물려가면서 테스트한다?
“애뮬레이터를 물린다”는 말은 실제 하드웨어 대신 에뮬레이터(또는 디버깅 프로브)를 연결하여 MCU나 ECU의 동작을 검사·제어한다는 뜻
에뮬레이터(Emulator)란?
- 보통 JTAG, SWD 같은 디버그 인터페이스를 통해 MCU 칩에 물리적으로 연결되는 디버깅 장치(로직 프로브)입니다.
- 호스트 PC의 IDE와 통신하며, 내부 레지스터·메모리 접근, 코드 싱글스텝, 브레이크포인트 설정 등을 가능하게 해 줍니다.
SW에서의 이중화
- 복붙 외에도 diversity를 확보해야 함.
- 동일한 기능을 두 명이 각각 개발하게 하거나
- 한 명은 A알고리즘을 사용해서 개발하고, 한 명은 B알고리즘을 사용해서 개발하는 방식
원격 P(주차)
- 주차장 P / 시동 꺼짐 ⇒ 스마트키 ⇒ 인증 ⇒ 원격시동 ⇒ 원격 전진 ⇒ 탑승 ⇒ 정상 동작
구문 테스팅(Syntax Testing)
- 입력 값을 적합(Valid)과 부적합(Invalid) 조건으로 분류한 뒤, 테스트 케이스를 작성하여 예상되는 결과를 테스팅한다.
- 올바른 케이스만이 아닌 올바르지 않은 케이스까지 포함해야함
동등 분할(Equivalence Partitioning) = 동치 클래스(Equivalence Class)
- 같은 결과값을 출력하는 입력값을 분류하고, 대표값으로만 테스트 ex) A, B, C, D, E, ⇒ A = (90 - 100), B = (80 - 90), C = (50 - 79) , D = (30 - 49) , E = (0 - 29) 이런식으로 나눔 이 중에 A를 체크한다면 95, B = 85, C = 65, B = 40, E = 15이런식으로 Output을 기준으로 Input값을 분류하고 그 중 대표값을 선정해서 테스트 케이스를 작성한다.
- 입력값이 범위가 정해져 있을 경우, 각 범위의 대표값을 이용하여 테스팅
- 결함은 어디에서 주로 발생할까? ⇒ 경계값에서 주로 많이 발생할 것이다. 60 이상 80 미만 이런거 잘못 쓸 때 발생하겠지 ⇒ 경계값 분석(Boundary Value Analysis) : 입력값의 주요 오류 대상인 경계값을 입력값으로 테스트 케이스를 작성하여 테스팅 ⇒ 90이 됬을 때 A로 변경이 되는지, 89일 때는 B인지 이런 부분들을 확인
