[SW Testing] 1일차

CS·2025년 7월 20일

SW Testing

목록 보기

1/3

교육 목표

V&V에 대한 이해
소프트웨어 제품 품질을 검증하기 위한 주요 테스트 설계 기법에 대한 이해
- ISO26262 Part 6기반의 주요 소프트웨어 테스트 기법
A-SPICE 기반의 소프트웨어 테스트 프로세스 요건의 이해
- SWE.4 Software Unit Vertification
- SWE.5 Software Componenet Vertification and Integration Vertification
- SWE.6 Software Vertification

중요 내용 - 프로젝트 적용법

기능별 우선순위 정해서 선정하기

기능별 중요도를 1,2,3으로 나눈다. ex) 원격 주행이라면 remote가 3, UI가 1의 중요도를 가진다 설정한다.
일정 - 얼마나 걸릴 것인지를 구분한다.
기술적 난이도 - 얼마나 어려울지를 구분한다.
중요도, 일정, 난이도를 합쳐서 7~9는 중요도 상 이런식으로 체계를 가지고 우선순위를 나눠 프로젝트 계획서에 기입한다.

차량용 소프트웨어 모음

A-SPICE : 차량용 소프트웨어 개발 프로세스 - 구체적
ISO 26262 : 기능 안전, 오동작 방지 - 추상적
SOTIF : 오동작 외에도, 예상치 못한 상황이 발생했을 때에도 안전하게 작동하도록 하는 표준
Cyber-Security : 보안 안정성, 신뢰성
Agile-SPICE : 반복적, 점진적 ⇒ Agile 기반으로 V모델을 돌릴 수도 있다.

면접 질문 대비용 : 이 프로젝트 끝나고 추가로 뭐해봤어요?

프로젝트 종료 후, 방학 기간 동안 팀원들과 함께 ISO 26262와 A-SPICE 강의를 수강했습니다.

실차나 장비가 없어 추가 실험은 어려웠지만, 강의에서 배운 기준에 따라 저희 소프트웨어를 스스로 평가해보았습니다.

평가 기준은 기능성, 신뢰성, 사용성, 이식성, 효율성이었고, 그 결과 Replay Attack의 탐지 정확도가 0.96으로 약간 부족했고, 제네시스 G80 전용이라 이식성이 낮다는 문제가 확인되었습니다.

이에 정확도를 높이기 위해 연속으로 들어오는 CAN 신호의 간격에 임계값을 두고, 너무 짧으면 비정상으로 판단하는 feature를 추가해보았습니다.

이 feature를 적용한 결과, f1 score가 0.99까지 향상되었습니다.

다만, 이식성 문제는 차량마다 신호 패턴이 달라 단순히 수정하는 것으로는 어려울 것 같아 실제 적용은 하지 못했습니다.

그래서 향후에는 차량별 데이터셋 확보나 패턴 일반화를 고민해볼 필요성을 느꼈습니다.

SDV(Software-Defined Vehicle)

SW가 차량 기능(feature, function) 정의
SW를 개발하듯 자동차를 개발해야 한다.

차량 내부 E/E Architecture의 변화

Multi-bus gateway ⇒ Functional Domain controller ⇒ Zonal

Multi-bus gateway architecture(기능별 ECU)
Functionl domain controller architecture(domain별 ECU 모음)
Zonal architecture with centralized compute(자동차 위치에 따라 Zone을 만들어 Zonal architecture)

Toyota 급발진 사고

⇒ 소프트웨어 설계 시 순환복잡도 및 전역변수와 같은 부분들을 신경 써야겠다는 계기가 됨.

소프트웨어 설계 사양서 부재
소프트웨어 코딩 규칙 위반
전역변수 남용 (2272개)- 유지보수 어려움, 예측하기 어려운 바그 발생 가능성 증가, 디버깅 어려움
순환복잡도가 높았음 - if,while,switch처럼 경로를 발생시키는 케이스들이 얼마나 복잡하게 개발되어 있는 거 ⇒ 업계 목표는 10

자동차 내 소프트웨어 규모와 결함 발생률

아무리 잘 짠 코드라도 1000줄에 8줄~12줄은 결함이 있다고 한다.

R(Requirement) → D(Do) → C(Check) → T(Test)

맨 앞 단에서 결함 수정 시보다 현장 운영할 때 결함 수정을 하려하면 1000배 이상의 비용이 소요된다.

Shift Left해라(왼쪽에서부터 해라)!

Test 단계를 앞으로 땡겨라~. 앞 단계에서부터 결함을 찾고 예방하려는 노력을 수행해라

[참고] 소프트웨어 결함의 영향(Fault Propagation)

만약 코드의 결함을 테스트 단계에서 발견하지 못한다면 어떻게 될까?

Fail Safe 기능이 찾기 힘든 경우가 있다. 사고 날 때 발생하는 코드이기 때문에 이후 사고로 연결될 수 있다.

Mistake → Fault → Error → Failure → Hazard(위협) ⇒ Accident → Harm

소프트웨어 안전 확보 컨셉

Fault Prevention(결함 예방) : 사람이 실수하지 않도록 방지
Fault Detection(결함 검출) : 결함을 검출
Fault Removal(결함 제거) : 검출된 결함을 제거
Fault Tolerance(결함 허용) : 런타임시 결함이 발생해도 오류를 유발하지 않도록 하거나 오류가 발생해도 고장이 발생하지 않도록 하기 위한 방법

ISO 26262는 어떻게(How)의 관점에서

A-SPICE는 무엇을(What)의 관점에서 바라본다.

시스템 검증 vs 소프트웨어 검증

시스템 : 하드웨어와 소프트웨어, 서브 시스템과 서브 시스템의 통합 환경
소프트웨어 : 테스트 보드, 에뮬레이터(실제 하드웨어 부품 시험), 가상 환경 활용,
소프트웨어 입력에 대한 (SIL/PIL/HIL)과 같은 환경 적극 활용

소프트웨어 품질

품질(Quality) 정의 : 명시적, 묵시적 요구 만족시키는 제품 또는 서비스 능력에 관한 특성

명시적 : 고객의 직접적 요구

묵시적 : 고객이 말하지 않아도 갖춰야 할 조건

소프트웨어 품질의 정의

명시된 요구사항 및 내재된 요구사항을 얼마나 충족하는가를 나타내는 소프트웨어 특성의 총체

품질 높은 소프웨어란?

사용자가 원하고, 정상 동작하고, 완성도가 높은 소프트웨어

소프트웨어 품질 확보 방법 유형

프로세스 품질 vs 제품 품질

프로세스 품질
- 소프트웨어 개발을 위해 필요한 개발 활동이 계획/표준 준수하여 개발하였는가를 나타냄
- 심사(Assessment) 및 감사(Audit) 등을 통해 확인
제품 품질
- 소프트웨어 자체가 가지는 품질
- 완성된 소프트웨어가 소비자가 요구하는 바에 얼마나 부합하는지를 나타내는 품질
- 정적/동적 테스팅을 통해 확인
  채용 공고 :

QA(프로세스 품질 테스트) ⇒ 테스트 케이스 작성이 아닌 A-SPICE 대로 계획을 세워서 진행 중인지 심사하고 검토,

테스터(QC(Quality Controller), 제품 품질) ⇒ 테스트 케이스를 작성하며 실제로 테스팅하는 사람 ⇒ V&V

소프트웨어 제품 품질이 가져야하는 세부 속성

ISO25010(과거 ISO 9126)에 소프트웨어 품질 특성 정의
기능성(요구되는 기능 만족하는가), 신뢰성(결함 없이 의도된 기능 및 작업 수행하는가), 사용성(사용자가 쓰기 편한가), 효율성(적절한 자원에 적정한 반응시간인가), 유지보수성(수정 및 변경이 용이한가), 이식성(지원하는 다양한 환경에서 운영될 수 있는가), 상호운영성(다른 시스템과 상호 연동 가능한가), 보안성(정보 및 데이터를 보호 가능한가)

⇒ CAN통신 기반 IDS 제작 프로젝트에서 추가적으로 뭘 해봤냐고 했을 때 방학이라 다 같이 ISO26262 및 A-SPICE 강의를 듣고 있었다. 방학 기간이었기에, 차량을 대상으로 우리의 모델을 수정해보기에는 기기도 없었고, 자원이 없었다. 그렇기에, 우리의 소프트웨어를 배운 내용을 토대로 평가해보는 작업을 진행해봤다. 평가는 기능성, 신뢰성, 사용성, 이식성, 효율성을 기준으로 진행하였고, 평가 결과 Replay attack의 정확도가 0.96으로 부족한 면을 보였고, 제네시스 G80 차량 대상으로만 적용되기에 이식성이 낮다는 문제가 있었다. 그렇기에, 이 부분만 간단하게 수정을 해보려 하였고, 이를 위해 feature를 추가했다. feature는 ~~한 faeture였고, 적용 결과 f1 score가 0.99로 상당히 증가한 모습을 보였다. 하지만, 이식성은 어떻게 해결해야 할지 몰라서 실제로 해보지는 못했다.

V&V(Verficiation(검증) & Validation(확인))
둘 모두 우리의 제품이 요구사항을 얼마나 만족하는가를 확인하기 위한 것
고객 요구사항은 SRS와 100% 일치할 수가 없다.
명세서를 기준으로 올바르게 만들고 있는가? 완성도가 높게 정상 동작하는가? Vertification
고객의 요구사항을 기준으로 올바르게 만들고 있는가? 사용자가 원하는 제품이 되어가고 있는가? Validation

요구사항(Requirement)의 분류

고객 요구사항(Customer Requirement) : 고객이 개발 대상 제품에 대해 원하는 기대사항(Needs)
제품 요구사항(Product Requirement) : 고객 요구사항 만족하기 위해 제품이 수행해야 하는 개발 관점의 구체적인 요구사항(Solution)

요구사항 분석 - SRS(SW) , 테스팅 - SWE(test)

SW 테스트

넓은 의미 : 결함의 발견을 목적으로 소프트웨어를 분석하는 활동
좁은 의미 : 보통 SW 테스팅을 한다고 하면 동적 테스팅 과정을 말하는 경우가 있어서 그렇다.

Error, Defect, Failure 용어 정의

일반적인 소프트웨어 공학

Mistake : 실수로 잘못 짠 코드, 실수
Error(= Mistake) : 주로 휴먼 에러를 나타냄. 개발자에 의한 원인으로 오타와 같은 단순 실수
Defect/Fault, Bug : 찾지 못한 에러가 소스 코드에 포함된 상태, 실패 또는 고장의 원인이 됨
실패/고장(Failure), 문제(Problem) : 찾지 못한 에러를 해결하지 못하고 소스 코드를 실행해서 고장이 난 상태, 정상과 갭이 있는 상황, 문제가 있다

ISO 26262 : SW 수준의 Mistake, Fault, Failure 용어 정의

Mistake : 실수로 잘못 짠 코드, 실수, 단순 오타
Fault : 찾지 못한 에러가 소스 코드에 포함된 상태, 오류를 일으킬 수 있는 비정상적인 상태/조건
Error : 명세된 상세 설계와 처리 결과 사이의 괴리가 있는 상태
실패/고장(Failure), 문제(Problem) : 찾지 못한 에러를 해결하지 못하고 소스 코드를 실행해서 고장이 난 상태, 정상과 갭이 있는 상황, 문제가 있다

정적(Static) 방법

소프트웨어 실행하지 않고 결함을 발견
휴먼 에러를 최대한 예방하여 코드에 Fault를 줄이겠다.
산출물 review
정적 분석(tool 사용)
요구사항 정의부터 코딩까지의 단계에서 시행

동적(Dynamic) 방법

소프트웨어를 실행하여 결함을 발견
고장을 기준으로 defect를 발견하고 해결하겠다
Black Box Testing() : 소스 코드 자체의 로직은 제외하고, 출력값에만 초점을 두고 테스팅하는 방법(코드는 고려하지 않는다)
White Box Testing() : 소스 코드 내 모든 독립적인 경로를 수행하여 봄으로써 결함을 찾아내는 방법
단위 테스팅부터 인수 테스팅까지 과정에서 시행

V-Model (SYS, SWE, HWE)

SYS1 ⇒ SYS2 , SWE.1 ⇒ SYS3 , SWE.2 ⇒ (SWE(SWE.3(상세설계 + 구현), + HWE), 단위 테스팅 SWE.4 ⇒ SYS4, SWE.5 ⇒ SYS5, SWE.6 ⇒ VAL1

프로세스란?

절차, 도구, 인력의 통합

소프트웨어 테스트 프로세스

소프트웨어 테스트를 수행하기 위한 절차/방법, 도구/장비, 인력의 통합

“”ISTQB (국제 test 자격증) ⇒ ISO/IEC/IEEE 29119 자격증, CSTS( 국내 cs 자격증)””

SW 테스트 프로세스

테스트 계획(Test Plan)

테스트 목표 정의, 대상 및 범위 결정, 계획성 작성 검토
능력 수준 1에서는 대상, 범위, 방법, 설계 기법, 테스트 결과물 등이 필요하고
능력 수준 2에서는 목표, 목표 달성 방안, 계획 작성 책임자 등 관리 측면에서 항목이 추가된다.
review에 관련된 내용은 Review plan을 따로 세우거나, 프로젝트 계획서, QA(품질보증) 계획서에 포함되기도 한다. ⇒ review는 모든 산출물, 모든 활동에 대해서 기본적으로 하게 된다.

“JIRA에서 테스트를 어떻게 관리할지? ⇒ 뒤에 간략하게 있다고 한다”

“JIRA를 잘 사용하는 걸 추천한다. 그냥 이슈 올려서 결함 처리하는 것이 아닌, 일정에 대한 이슈, 테스트에 대한 이슈 등 여러 이슈가 있는데 이슈 문제 유형을 나눠서 워크플로우를 잘 정리해서 템플릿 잘 정리해서 등록하는 것이 좋을 것 같다는 의견이 있다”

테스트 베이시스(Test Basis)

테스트 케이스를 작성하기 위한 근거 산출물(기반 문서)
- 어떤 활동/산출물을 근거로 테스트를 수행할 것인가?
A-SPICE에서 가장 중요한 건 양방향 추적성, 각각의 테스트 산출물 작성할 때 테스트 베이시스가 명확하게 작성되어있도록 해라.(일관성)

테스트 케이스(Test Case)

특정한 요구사항이 제대로 구현되었는지 검증하기 위하여 테스트 조건, 입력 값, 예상 출력 값, 실제 수행한 결과를 기록하는 것 ⇒ “테스트 수행을 위한 정보”와 “테스트 결과”를 포함
필수 항목 : ”입력값, 테스트 절차, 예상출력값”
단위보다는 위로 올라갈수록 더욱 디테일하게 작성해야 한다.
금융앱에서 로그인을 할 때 아디/비번을 5번 이상 실패했을 때 락이 걸리는 가, 안 걸리는 가 해서, 만약 락이 걸린다면 그때 테스트 케이스를 따로 작성해야 한다.
요구사항 작성할 때 테스트를 어떻게 할지도 미리 생각해둬야 한다.
언제 작성해야 할까? ⇒ 테스트 베이시스(근거 문서)를 작성할 때 테스트 케이스를 함께 작성하는 걸 권고한다. 근데 대부분은 테스트 전에 작성하는 것이 일반적이다. 테스트 케이스 작성을 통해 테스트 베이시스의 품질을 개선한다.
테스트 케이스를 작성하면서 테스트 베이시스가 잘 작성되었는지 검토할 수 있게 한다.
source code를 작성할 때에도 테스트 케이스를 고려해서 작성해야 한다. 예를 들어 void 함수를 만든다면 void는 return이 없기 때문에, 테스트 가능하게 끔 bool, int, char로 바꿔주는 것이 좋다. 아니라면 bool type으로 받아서 실행할 경우 true, 실패할 경우 false로라도 나올 수 있도록 해라.
어떤 절차로 어떻게 실험을 했을 때 어떤 결과가 나올지 예상 출력 값이 필요하다.
그 후 실제 테스트 수행하고 실행 결과와 결함에 대한 내용 그리고 디버깅한 내용이 필요하다

“원격 시동 ⇒ 블루투스”

“테스트 케이스 작성해보기”

사전 조건 : 차량이 정차 중인 상태, 파킹 모드, 블루투스와 연결되어 있어야 함

절차 : 1. 차량과 나의 거리 10m이내 2. 3초 이내에 버튼을 눌러서

테스트 주요 용어

테스트웨어(Testware)

소프트웨어 테스트를 수행하는데 필요한 모든 산출물
- 문서, 도구, 데이터, 환경 포함

테스트스위트(TestSuite)

특정 테스트 목표를 달성하기 위해 함께 실행되는 테스트 케이스의 집합
- 회원가입(ID/PW, 간편 회원가입 등) 기능 테스트하기 위한 테스트 케이스의 집합

테스트 시나리오(Test Scenario)

사용자의 실제 행동을 기반으로 여러 개의 테스트 케이스를 묶은 것
- 신규 사용자가 회원가입 → 로그인 → 결제까지 진행하는 시나리오를 테스트하기 위한 테스트 케이스의 집합
  
  정해진 시나리오를 기준으로 관련된 테스트 케이스를 묶어서 완성시키는게 테스트 시나리오.

관련된 flow끼리 묶어서 테스트를 실행

(TC1 - TC2), (TC1, TC4 )

TC1. 원격 시동

TC2. 원격 전진

TC3. 원격 후진

TC4. 원격 전진

테스트 데이터(Test Data)

테스트 중에 사용되는 데이터
- 테스트 입력값, 예상 결과, 파일, 데이터베이스 등 다양한 형태를 포함한 데이터

테스트 종료 조건(Test eXit Criteria)

수행된 작업의 완료 기준(완료하기 위해 요구되는 업무, 정보 등)

프로세스 정의 방법 : ETVX

E(Entry Criteria) : 수행할 작업의 착수 기준(착수하기 위해 요구되는 업무, 정보 등)
T(Task) : 유닛 테스트에서 어떤 활동을 수행해야 하는지, 뭘 해야 할까
V(Verification) : 완료된 작업의 검증 기준(작업 수행 여부, 산출물 검증 기준 등)
X(eXit Criteria) : 수행된 작업의 완료 기준(완료하기 위해 요구되는 업무, 정보 등) ⇒ 테스트 커버리지

테스트 커버리지(Coverage)

테스트 케이스 수행 시 테스트 대상을 몇 %나 실행했는지 알려주는 지표
요구사항 커버리지
- 테스트 케이스가 요구사항을 얼마만큼 실행했는가?
- 블랙박스 테스트 기법
소스코드 커버리지
- 테스트 케이스가 소스코드를 얼마만큼 실행했는가?
- 화이트박스 테스트 기법
  
  SO 26262의 테스트 결과 평가
테스트 성공과 요구사항 커버리지 측정
테스트 단계 별로 꼭 해야 하는 것
- Test Basis에 적혀있는 모든 내용을 테스트해야 함

테스트 원리

테스트는 결함이 존재함을 밝히는 활동 ⇒ 소스 코드의 완성이 아닌, 비평하고 비판하는 관점에서 바라보기, 결함이 없음은 증명할 수 없다.
완벽한 테스트는 불가능 ⇒ 전수 테스트 불가능, 모든 시나리오, 모든 환경, 모든 데이터 고려는 불가
테스트는 개발 초기에 시작 ⇒ 테스트 베이시스 및 테스트 케이스를 초기부터 작성하라
결함에 집중 ⇒ 결함이 많이 발견되는 곳에 집중해라. 8:2 법칙에 따라라(버그의 80%는 주요 코드 20%에서 발생)
살충제 패러독스 ⇒ 동일한 테스트케이스를 사용하지 마라. 기존 프로젝트를 이어 받는다고 케이스를 동일하게 사용해서는 안된다.
테스트는 정황(Context)에 의존적 ⇒ 테스트를 수행하는 환경·조건·목적 등에 따라 달라진다 ⇒ error guessing 같은 경우에도 적용 가능한 경우가 있고, 아닌 경우가 있다.
오류 부재의 궤변 ⇒ 결함이 0가 나온다면 , 의심해볼 필요가 있다. Validation을 강조, 고객을 만족시켜야 한다.

“” 중요 : A-SPICE 시스템 별 구성 “”

A-SPICE : 차량용 소프트웨어 개발 프로세스

ISO 26262 : 기능 안전, 오동작 방지
SOTIF : 오동작 외에도, 예상치 못한 상황이 발생했을 때에도 안전하게 작동하도록 하는 표준
Cyber-Security : 보안 안정성, 신뢰성
Agile-SPICE : 반복적, 점진적 ⇒ Agile 기반으로 V모델을 돌릴 수도 있다.

VDA Scope ⇒ ASPICE 평가 시 필수로 포함되어야 할 프로세스 그룹 목록

SUP1/ SUP8 / SUP9/ SUP10 은 필수
SYS , SWE, HWE 셋 중 하나 이상은 필수
MAN.3, MAN.5, MAN.6은 필수

나머지는 시스템 별로 추가해서 더해주면 되는 것이다.

if) LKAS ⇒ MLE(Machine Learning Engineering) 과정 추가

if) OTA ⇒ Cyber Security 필수

if) ADAS ⇒ SOTIF 필수 ,

1. 개념 정리

1) 소프트웨어 개발 단계와 아키텍처

SWE.4 (Unit Verification)
- Unit 단위로 테스트 수행
- 검토, 정적분석, 테스트 방법 활용
SWE.5 (Component Verification)
- 여러 Unit이 모여 Component가 될 때
- Unit 간 인터페이스 및 통합 상태 검증
SWE.6 (Software Integration Test)
- ECU 환경에서 실제 동작 테스트
- 기능 요구사항 충족 여부 확인
VAL (Validation)
- 최종 사용환경에서 요구사항 충족 확인
  
  2) 전장 시스템 정의
System = Sensor + ECU + Actuator
- 센서로 정보 수집
- ECU에서 제어 및 판단
- 액추에이터로 물리적 동작
  
  3) ISO 26262 용어 정리
ITEM : 차량 수준 기능을 구현하는 시스템 or 시스템 조합
System : HW + SW + 최소 1개 이상의 센서, ECU, 액추에이터
Interface : 상호작용을 위한 접점 (ex. API)
Component : HW 또는 SW의 모듈화된 부분 (아키텍처 구성 요소)
Unit : 더 이상 쪼갤 수 없는 소프트웨어의 최소 단위
Standalone : 독립 실행 가능

4) A-SPICE SWE.5 용어 변경 의미

SWE.5에서 Test → Verification으로 변경
- 테스트뿐만 아니라 정적 분석, 검토 포함
- 더 포괄적인 검증 활동 강조

5) 모듈화 원칙

응집도(Cohesion) : 관련 있는 기능끼리 묶어라
결합도(Coupling) : 모듈 간 상호의존성은 줄여라
Divide & Conquer : 복잡한 문제를 작은 단위로 나눠 개발

2. 핵심 요점

소프트웨어 개발은 단계별로 구분되고, 단계마다 목표와 검증 방식이 다르다
전장 시스템은 센서, ECU, 액추에이터로 구성
ISO 26262는 시스템과 소프트웨어를 구성하는 요소의 정의를 명확히 한다
SWE.5는 Verification으로 용어가 확장되어, 테스트 + 정적 분석 포함
모듈화는 응집도↑, 결합도↓가 핵심

3. 쉽게 이해하기

시스템 = 사람으로 치면 "감각(센서) + 뇌(ECU) + 근육(액추에이터)"
응집도 = 관련된 친구끼리 팀을 짜는 것
결합도 = 팀 간에 너무 얽히지 않게 역할을 나누는 것

4. 주의할 점

SWE.4, SWE.5, SWE.6은 단계별 테스트 대상과 범위가 다르므로 혼동하지 말 것
SWE.5 Verification은 테스트만이 아니라 분석과 검토까지 포함
모듈화할 때는 무조건 잘게 쪼개기보다는 기능 중심으로 묶고, 필요 최소한만 연결

5. 관련 개념 비교

6. 요약 한 줄

소프트웨어는 단계별로 검증되며, 전장 시스템과 모듈화는 기능 응집과 결합도 관리가 핵심이다.

원격 제어 SW

원격 제어 System 안에 ECU안에 들어가는 Software이다.
원격 제어 SW는 integrated SW or embedded SW라고 한다.
원격 제어 SW 소스 코드는 하나로 이루어져 있지 않다. 안에 들어 있는 내용은 관련된 기능들끼리 모듈화되어서 구성이 되어있다. 예를 들어, remote를 위한 function 집합, login하기 위한 function 집합 이런식으로 같은 기능 수행하는 애들끼리 모듈화해서 소스 코드를 작성한다. 이렇게 모듈화된 것이 Component라고 한다. 파일이 될 수도 있고, 폴더가 될 수도 있다.

테스트 환경 : In-the-loop

⇒ 소프트웨어 모델, 가상 환경 또는 실제 하드웨어와 연계하여 테스트 대상의 동작을 검증하는 방식

MIL(Model-in-the-loop) tests : 모델링 환경 내에서만 test, 시뮬레이션 환경 (mathworks) 내에서 테스트 수행, 하드웨어 같은 것들은 가상 환경으로 처리
SIL(Software-in-the-loop) tests : 실제 환경은 SW, 나머지는 가상 환경으로 만들어 테스팅 (ex. 노트북에서 실행)
PIL(Processor-in-the-loop) tests : ECU를 실제적으로 만들고 테스트하겠다. 아직까지 하드웨어는 가상
HIL(Hardware-in-the-loop) tests : 하드웨어 환경까지도 실제적으로 만들고 테스트

학습

다음 포스트