로봇 소프트웨어 구조설계로봇 시스템 통합로봇 시스템 시험평가
출제기준 좌표2·2·2·1
2과목 · 로봇 소프트웨어 구조설계

로봇 시스템 평가절차

로봇 시스템 통합로봇 시스템 시험평가
# 로봇소프트웨어구조설계
01

📌 개요

  • 요구 만족 여부는 "돌려 보니 잘 되더라"가 아니라 계획된 절차로 확인
  • 이 노트 = 평가의 프로세스(어떤 순서와 문서로 진행하나) — 구체적 시험 항목·측정 방법은 로봇 시스템 시험평가에서
  • 핵심 출제 포인트 = 검증(Verification)과 확인(Validation)의 구분, 시험 레벨 4단계의 순서, 평가 절차 5단계, 블랙박스/화이트박스 시험
02

📖 핵심 개념

검증과 확인 — V&V (시험 단골)

  • 검증(Verification): "제품을 올바르게 만들었는가?" — 설계·사양서대로 만들어졌는지 확인. 각 개발 단계의 산출물을 이전 단계 기준과 대조
  • 확인(Validation): "올바른 제품을 만들었는가?" — 사용자의 실제 요구·사용 환경을 만족하는지 확인. 최종 제품을 실제 조건에서 평가

사양서에는 완벽히 맞지만(검증 통과) 정작 현장에서 쓸모없는(확인 실패) 제품이 있을 수 있다 — 그래서 둘 다 필요하며, 합쳐서 V&V라 부른다.

시험 레벨 4단계

V-모델의 오른쪽 오르막이 곧 시험 레벨의 순서다.

  1. 단위 시험(Unit Test): 모듈 하나를 격리해 시험 — 함수·클래스 수준, 개발자가 수행
  2. 통합 시험(Integration Test): 모듈을 결합하며 인터페이스를 시험 — 메시지가 제대로 오가는가
  3. 시스템 시험(System Test): 완성된 전체 시스템을 요구사항 명세 기준으로 시험 — 기능 + 비기능(성능·신뢰성·안전)
  4. 인수 시험(Acceptance Test): 사용자·발주자 관점에서 실사용 환경 기준으로 최종 확인 — 확인(Validation)의 성격

평가 절차 5단계

체계적인 평가는 다음 순서로 진행된다.

  1. 시험 계획(Plan): 시험 범위·목적, 일정·자원·책임, 합격 판정 기준(Pass/Fail Criteria) 을 미리 정의 — 기준을 시험 후에 정하면 평가의 객관성이 무너진다
  2. 시험 설계(Design): 요구사항으로부터 시험 항목을 도출하고 시험 케이스와 절차서 작성
  3. 환경 구축(Setup): 시험 장비(측정기·지그)·시뮬레이터·시험장 준비, 계측기 교정(calibration)
  4. 수행·기록(Execute): 절차서대로 수행하고 결과를 있는 그대로 기록 — 실패도 데이터다
  5. 분석·보고(Report): 결과 분석, 결함 등록·수정 후 재시험과 회귀 시험, 시험 성적서 작성 (→ 제어기 시험평가 결과 성능 분석)

시험 케이스(Test Case)의 구성

  • 시험 케이스 구성 = 식별자, 목적, 사전 조건, 입력(자극), 수행 절차, 기대 결과, 판정 기준
  • 핵심 = "기대 결과가 미리 적혀 있다" — 결과를 보고 나서 판단을 만들면 안 됨

블랙박스 시험과 화이트박스 시험

  • 블랙박스(명세 기반): 내부 구조를 모른 채 입력–출력만으로 시험. 기법: 동등 분할(입력을 대표값 그룹으로 나눔), 경계값 분석(오류가 몰리는 경계 ±1을 집중 시험)
  • 화이트박스(구조 기반): 내부 코드 구조를 보며 시험. 기법: 구문(statement)·분기(branch) 커버리지 — 코드가 얼마나 실행되었는지의 비율

시스템·인수 시험은 주로 블랙박스, 단위 시험은 화이트박스를 병용한다.

요구사항 추적성

  • 추적표(Traceability Matrix) 로 "요구사항 ↔ 시험 케이스" 연결
  • 모든 요구사항에 최소 하나의 시험 대응 → 시험 누락 없음
  • 반대로 어떤 시험이 실패하면 어떤 요구가 미충족인지 즉시 파악

단계적 평가와 인증

로봇은 위험·비용 때문에 한 번에 실환경에 내보내지 않는다.

  • 시뮬레이션 → 실험실(제한 환경) → 실증(필드 시험) 순으로 위험을 낮추며 평가
  • 제품화 단계에서는 공인 시험기관의 시험 성적서와 인증(국내 KC 등 강제 인증, KS 등 표준 인증, 수출 시 CE 등)이 요구될 수 있다 — 관련 국제 표준은 로봇 시스템 시험평가 참조
03

📊 다이어그램 · 수식

시험 레벨과 V&V

DIAGRAM
flowchart LR
    UT["단위 시험
(모듈)"] --> IT["통합 시험
(인터페이스)"] --> ST["시스템 시험
(전체·비기능 포함)"] --> AT["인수 시험
(사용자·실환경)"] V1["검증 Verification
사양대로 만들었나"] -.-> UT & IT & ST V2["확인 Validation
올바른 제품인가"] -.-> AT

평가 절차 5단계

DIAGRAM
flowchart LR
    P["① 계획
합격 기준 정의"] --> D["② 시험 설계
케이스 작성"] --> S["③ 환경 구축"] --> E["④ 수행·기록"] --> R["⑤ 분석·보고"] R -- 결함 수정 후 재시험·회귀 시험 --> E
04

🎯 핵심 요약 · 암기 포인트

익힘 0 / 10카드를 눌러 뒤집고, 앞면에서 아는지 표시하세요.
Q · 1
검증(Verification)이란?
A
"제품을 올바르게 만들었는가" — 설계·사양서대로 만들어졌는지 확인
Q · 2
확인(Validation)이란?
A
"올바른 제품을 만들었는가" — 사용자의 실제 요구와 사용 환경을 만족하는지 확인
Q · 3
시험 레벨 4단계의 순서는?
A
단위 시험 → 통합 시험 → 시스템 시험 → 인수 시험
Q · 4
통합 시험의 초점은?
A
모듈 간 인터페이스 — 결합했을 때 메시지·호출이 올바른가
Q · 5
시스템 평가 절차 5단계는?
A
시험 계획 → 시험 설계(케이스 작성) → 환경 구축 → 수행·기록 → 분석·보고
Q · 6
합격 판정 기준은 언제 정하나?
A
시험 계획 단계에서 미리 — 시험 후에 정하면 객관성 상실
Q · 7
블랙박스 시험의 대표 기법 2가지는?
A
동등 분할, 경계값 분석 (내부 구조를 모른 채 입출력으로 시험)
Q · 8
화이트박스 시험의 대표 지표는?
A
커버리지(구문·분기) — 코드가 실행된 비율
Q · 9
요구사항 추적표(Traceability Matrix)의 역할은?
A
요구사항↔시험 케이스를 매핑해 시험 누락 방지, 실패 시 미충족 요구 즉시 식별
Q · 10
로봇의 단계적 평가 순서는?
A
시뮬레이션 → 실험실(제한 환경) → 실증(필드 시험)
05

✏️ 예상문제

1. "올바른 제품을 만들었는가"를 사용자 요구와 실사용 환경 관점에서 평가하는 활동은?

① 검증(Verification) ② 확인(Validation) ③ 단위 시험 ④ 프로파일링

정답 및 해설

정답: ② 확인(Validation)은 사용자의 실제 요구 충족 여부를, 검증(Verification)은 사양서 준수 여부("올바르게 만들었는가")를 평가한다. 두 질문의 문구를 바꿔 내는 문제가 단골이다.

2. 시험 레벨을 수행 순서대로 옳게 나열한 것은?

① 통합 → 단위 → 시스템 → 인수 ② 단위 → 통합 → 시스템 → 인수 ③ 단위 → 시스템 → 통합 → 인수 ④ 인수 → 시스템 → 통합 → 단위

정답 및 해설

정답: ② 작은 것부터 큰 것으로 — 모듈(단위), 모듈 결합(통합), 전체(시스템), 사용자 관점(인수) 순이다. V-모델의 오른쪽 오르막 순서와 같다.

3. 입력을 유효/무효 그룹으로 나누어 각 그룹의 대표값을 시험하고, 오류가 잦은 경계 근처 값을 집중적으로 시험하는 기법이 속하는 것은?

① 화이트박스 시험 ② 블랙박스 시험 ③ 회귀 시험 ④ 부하 시험

정답 및 해설

정답: ② 동등 분할과 경계값 분석은 내부 구조를 보지 않고 명세(입력–출력)만으로 케이스를 만드는 블랙박스 기법이다. 화이트박스는 코드 구조 기반(커버리지)이다.

4. 시험 평가 절차에 대한 설명으로 옳지 않은 것은?

① 합격 판정 기준은 시험 계획 단계에서 미리 정한다 ② 시험 케이스에는 기대 결과가 사전에 명시되어야 한다 ③ 결함 수정 후에는 수정 부분만 다시 시험하면 충분하다 ④ 시험 결과는 실패를 포함해 있는 그대로 기록한다

정답 및 해설

정답: ③ 수정이 다른 기능을 망가뜨릴 수 있으므로(부작용), 수정 부분의 재시험과 함께 기존 기능이 여전히 동작하는지 회귀 시험을 수행해야 한다.

5. 요구사항 추적표(Traceability Matrix)를 사용하는 주된 목적은?

① 코드의 실행 커버리지를 계산하기 위해 ② 모든 요구사항이 시험으로 확인되는지 누락을 방지하기 위해 ③ 시험 장비의 교정 주기를 관리하기 위해 ④ 개발 일정을 단축하기 위해

정답 및 해설

정답: ② 추적표는 요구사항과 시험 케이스를 1:N으로 연결한 표다. 대응되는 시험이 없는 요구사항(시험 누락)을 드러내고, 시험 실패가 어느 요구의 미충족인지 역추적하게 해 준다.

06

🔗 관련 노트

로봇소프트웨어개발기사 필기 · 학습 교재출제기준 2025.1.1 – 2027.12.31