정적 테스트 — IEEE 1028 리뷰 5종·8단계 프로세스·인스펙션 역할, 순환 복잡도와 자료 흐름 이상

개념

정적 테스트의 범위

정적 테스트는 프로그램을 실행하지 않고 결함을 찾는다. 사람이 하는 리뷰 와 도구가 하는 정적 분석 두 갈래다. 대상은 코드에 한정되지 않는다 — 요구사항 명세서, 설계서, 테스트 계획서, 매뉴얼 등 모든 개발 산출물 이 대상이다. 그래서 결함이 생긴 단계에서 바로 잡을 수 있고, 결함 비용 곡선(레슨 2)에서 가장 싼 구간을 공략한다.

리뷰 5종 — 목적과 주재자로 구분한다

IEEE 1028-2008은 리뷰를 다섯 가지로 나눈다.

관리 리뷰와 감사가 헷갈리면 이렇게 가른다 — 관리 리뷰는 내부의 계획 조정, 감사는 외부 기준 대비 독립 평가 다.

리뷰 프로세스 8단계

IEEE 1028은 Fagan의 인스펙션에서 출발한 공통 프로세스를 정의한다. 순서 문제가 자주 나온다.

1. 경영진 준비 — 인력·설비·예산·교육 등 자원 제공
2. 리뷰 계획 — 리뷰 리더가 목적 파악, 팀 구성, 책임 할당, 자료 배포, 일정 공지
3. 리뷰 절차 개요 설명 — 리더 요청 시, 목적과 절차 설명
4. 작업물 개요 설명 — 리더 요청 시, 검토 대상을 친숙하게(인스펙션에서는 작성자 가 수행)
5. 개별 준비 — 각자 검토, 발견한 문제를 문서화해 리더에게
6. 그룹 검토 — 회의에서 결과를 모아 작업물 상태에 합의
7. 재작업 — 문제 목록을 작성자·책임자에게 전달해 해결
8. 후속 작업 — 리더가 모든 조치 항목이 완료(Close)됐는지 확인

유형마다 적용 수준이 다르다. 예를 들어 관리 리뷰는 ④ 작업물 개요 설명을 하지 않는다. 워크쓰루는 ③·④를 회의의 일부로 다룰 수 있다. 진입 조건 확인과 종료 후 점검도 필요하다.

인스펙션의 다섯 역할과 겸직 제약

팀 규모는 최소 2명(작성자 외 검토자·주재자)이고, 3~6명이 일반적이며 4명이 가장 이상적 이라는 자료가 있다. 6명을 넘으면 관리가 어렵다. 모든 구성원은 검토자 역할도 겸한다. 인스펙션의 목적은 작업물의 결함 발견이지 작성자 평가가 아니다.

인스펙션 고유 단계로는 주재자가 참가자에게 최소 준비 시간·희망 인스펙션 수행률(Inspection rate) ·유사 프로젝트의 문제 수를 알려 주는 절차 개요 설명이 있고, 작성자의 작업물 개요 설명 단계에서는 해결책 제안이나 결함 수정을 하지 않는다.

정적 분석 ① 코딩 표준

코딩 표준(코딩 지침)은 개발자가 지킬 규약이다. MISRA C·MISRA C++·JSF AV C++·CERT C 등이 있고, 정적 분석 도구가 위반을 자동 탐지한다. 예: 초기화되지 않은 변수 사용, 동적 메모리 할당 금지, goto 금지, 하나의 함수 출구. 안전 필수 분야(자동차·항공)에서 특히 엄격하다(s2-m35 모듈).

정적 분석 ② 순환 복잡도 (McCabe, 1976)

제어 흐름 그래프에서 선형적으로 독립인 기본 경로의 개수 다. 계산식은 세 가지이고 모두 같은 값을 낸다.

코드에서 바로 세는 규칙은 if·while·for·&&·|| 마다 +1, switch 의 각 case 마다 +1, 시작값 1 이다. 복합 조건 if (x > 0 && y > 0) 은 단축 평가를 반영해 두 개의 분기로 보면 2가 아니라 3 이 된다(조건 하나당 +1). 도구에 따라 switch 를 통째로 +1 하기도 하니 문제의 가정을 읽는다.

연습 — 다음 코드의 순환 복잡도는?

int grade(int score, int bonus) {
  int g = 0;
  if (score >= 90 || bonus > 0)   // if +1, || +1
    g = 1;
  for (int i = 0; i < 3; i++)     // for +1
    if (i == score)               // if +1
      g++;
  return g;
}

1 + 4 = 5 다. 기본 경로 테스트라면 독립 경로 5개를 덮는 TC가 필요하다는 뜻이다.

기준값도 나온다. Walsh(1979)는 10 이상에서 결함률이 크게 늘었다고 했고, HIS(독일 자동차 제조사 연합)는 10, MISRA Report 5는 15 이하, JSF AV C++ 규칙 3은 20 이하를 권한다. RIAC 표는 10 이하 수용 가능, 30 이상 의심, 50 이상 테스트 불가, 75 이상이면 고치는 작업이 새 결함을 만든다(bad fix).

정적 분석 ③ 자료 흐름 이상(Anomaly)

변수에 일어나는 일을 세 글자로 적는다 — d 정의(define, 값 할당), u 사용(use, 읽기), k 소멸(kill, 해제·범위 종료). ~ 는 "아무것도 없음"이다(~u 는 앞에 아무 일 없이 바로 사용). 연속된 두 사건을 보고 이상 여부를 판정한다.

시험 함정: "dd, kk, ~u, du 는 이상 패턴이다"(X — du는 정상). 단답형에서는 자료 흐름도를 주고 변수 하나의 이상 패턴을 쓰라고 한다. 경로를 따라 d·u·k를 순서대로 적은 뒤 연속 두 글자씩 끊어 보면 된다.

int x;              // 선언만 — x 는 아직 정의되지 않음
if (flag) x = 1;    // d
x = 2;              // d   → flag 가 참이면 dd
printf("%d", y);    // y: ~u (정의 없이 사용)
free(p); free(p);   // p: kk

실무에서 왜 필요한가

리뷰를 유형으로 구분해 쓰면 회의가 짧아진다. "요구 명세 인스펙션"이라 공지했는데 회의가 대안 토론으로 흘러가면 그것은 워크쓰루다 — 목적을 섞으면 결함 목록도, 결정 사항도 남지 않는다. 인스펙션 역할 제약(작성자는 주재자·기록자 불가, 관리자 배제)은 심리적 안전 을 위한 것이다. 관리자가 앉아 있으면 검토자가 작성자의 결함을 덜 말하고, 작성자가 기록하면 불리한 지적이 누락된다.

순환 복잡도는 단위 테스트 범위를 협상하는 숫자다. "이 함수는 복잡도 23이라 독립 경로만 23개다, 리팩터링 없이는 단위 테스트로 덮기 어렵다"는 말은 정적 분석 리포트 한 장으로 근거가 생긴다. 자료 흐름 이상(~u, ku)은 초기화 누락·해제 후 사용 결함으로, 보안 취약점(CWE-457, CWE-416)과 직결된다(s3-m53-l04).

실습 과제

과제 1 — 리뷰 유형 판별 (7분)

① 출시 일정을 2주 미루는 결정을 위해 진행 보고서를 검토한다 ② 작성자가 설계서를 화면에 띄우고 신입들에게 설명하며 의견을 받는다 ③ 체크리스트를 들고 훈련된 주재자 아래 4명이 요구 명세의 결함을 기록한다 ④ 외부 기관이 의료기기 소프트웨어의 IEC 62304 준수 여부를 평가한다 ⑤ 대표 엔지니어가 API 명세가 사내 설계 표준을 따르는지 검토하고 대안을 추천한다 정답: 관리 리뷰 / 워크쓰루 / 인스펙션 / 감사 / 기술 리뷰.

과제 2 — 인스펙션 팀 편성 (5분)

작성자 A, 팀장 B, 개발자 C·D, QA E가 있다. 인스펙션 팀을 편성하고 각 역할을 배정한다. B를 넣을 수 없는 이유와, A가 맡을 수 없는 역할 두 가지를 적는다.

과제 3 — 순환 복잡도 세 가지 방법으로 (10분)

위 grade 함수의 제어 흐름 그래프를 직접 그려 노드·간선을 세고 E − N + 2로 구한다. 닫힌 영역을 세어 +1 한 값, 분기 노드 +1 한 값과 모두 5가 나오는지 확인한다. 다르게 나오면 || 를 분기 하나로 그렸는지 둘로 그렸는지 점검한다.

과제 4 — 자료 흐름 이상 찾기 (8분)

다음 코드에서 변수 t 의 경로별 d·u·k 순서를 적고 이상 패턴을 모두 찾는다.

int t;
if (a > 0) { t = a; }
if (b > 0) { t = b; }
use(t);

힌트: a ≤ 0 이고 b ≤ 0 인 경로에서 t 는 무엇인가? a > 0 이고 b > 0 이면? 정답: ~u (두 조건 모두 거짓), dd (두 조건 모두 참).

자가 체크리스트

• 리뷰 5종의 목적과 주재자를 표 없이 쓸 수 있다
• 리뷰 프로세스 8단계를 순서대로 쓸 수 있다
• 관리 리뷰가 생략하는 단계를 안다
• 인스펙션 다섯 역할과 겸직 제약 세 가지(작성자 ≠ 주재자, 작성자 ≠ 기록자, 관리자 배제)를 안다
• 순환 복잡도 세 공식과 코드에서 세는 규칙을 안다
• 복합 조건이 복잡도를 올리는 이유를 설명할 수 있다
• d·u·k 두 글자 패턴 중 정상과 이상을 구분할 수 있다

흔한 실수

• 워크쓰루를 "가벼운 인스펙션"으로만 기억한다. 핵심 차이는 작성자가 주재 하고 학습·대안 이 목적에 들어간다는 점이다
• 감사를 리뷰가 아니라고 생각한다. IEEE 1028은 감사를 리뷰 5종에 포함한다
• E − N + 2에서 시작·종료 노드를 빼먹는다. 그래프를 그릴 때 진입·종료 노드도 노드다
• du 를 이상으로 고른다. "d 다음 u"는 가장 정상적인 흐름이다
• 정적 분석이 모든 결함을 찾는다고 본다. 실행 시에만 드러나는 성능·타이밍 결함은 동적 테스트의 몫이다

참고 자료

• TTA, 『CSTS 가이드 — 일반등급』 8장 정적 테스트 — 리뷰 프로세스, 관리·기술 리뷰, 인스펙션 역할과 과정, 워크쓰루, 감사, 코딩 표준, 복잡도 분석
• IEEE Std 1028-2008 — IEEE Standard for Software Reviews and Audits
• Fagan, M. E., "Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal 15(3), 1976
• McCabe, T. J., "A Complexity Measure", IEEE Transactions on Software Engineering SE-2(4), 1976
• Beizer, B., Software Testing Techniques, 2nd ed., Van Nostrand Reinhold, 1990 — 자료 흐름 이상(d·u·k) 분류
• MISRA C:2023 — 코딩 표준
• CWE-457 Use of Uninitialized Variable, CWE-416 Use After Free
• 이 커리큘럼 안: s1-m03-l10 「순환 복잡도로 최소 테스트 케이스 수 계산하기」, s3-m53-l02 「경로 테스트와 데이터 흐름 테스트」, s3-m53-l05 「코드 리뷰를 테스트 활동으로 운영하기」