테스트 개념 ② — 기본 용어 여섯 개와 테스트 분류의 세 축

개념

기본 용어 여섯 개 — 한 장의 그림으로

동적 테스트(프로그램을 실행하는 테스트)를 하려면 최소한 여섯 가지가 갖춰져야 한다. 이 여섯 단어의 관계를 그릴 수 있으면 기본등급 용어 문제의 절반은 풀린다.

                     테스트 대상 (무엇을)
                          │ 1 : 여러 개
                        피처 (어떤 관점에서)  ──→  테스트 유형 (기능·성능·보안…)
                          │
               테스트 설계 기법 (어떻게 고르나)
                          │
   테스트 케이스 (입력 + 예상 결과)  ──여러 개를 순서대로──→  테스트 절차
                          │                                        │
                          └──────────── 테스트 환경에서 실행 ──────┘
                                          │
                              실행 결과 ↔ 예상 결과 비교 → 테스트 결과

관계에서 자주 나오는 문장 세 개를 외워 둔다.

• 하나의 테스트 대상에는 여러 피처 가 있을 수 있고, 피처마다 테스트가 수행된다. 피처에 초점을 둔 테스트를 유형 테스트 라고 부른다.
• 테스트 케이스 여러 개를 특정 환경에서 실행할 순서로 묶은 것이 테스트 절차 다.
• 하나의 테스트 케이스는 여러 테스트 절차에서 쓰일 수 있다.

예전 판의 용어 관계 그림에는 "테스트 설계 케이스"라는 칸이 있었는데, 정오표에서 "테스트 케이스"로 바로잡혔다. "테스트 설계 케이스"라는 용어는 없다.

왜 예상 결과가 반드시 있어야 하나

이차방정식 프로그램에 (a=1, b=2, c=1)을 넣으면 중근 -1이 나와야 한다. 실행했는데 1이 나왔다면 결함이 있다고 판단할 수 있다. 그런데 예상 결과를 미리 정하지 않았다면 1이 나와도 맞는지 틀리는지 판단할 근거가 없다. 그래서 테스트 케이스의 정의에 예상 결과가 들어간다. 입력만 있고 예상 결과가 없는 것은 테스트 케이스가 아니라 "입력값 목록"이다.

테스트 절차가 결함 재현에 쓰인다

테스트 절차는 실행을 위한 것이기도 하지만, 결함을 다시 만들어 내는(재현) 근거 이기도 하다. 개발자가 디버깅하려면 같은 결함이 나는 상황을 재연해야 하는데, 그때 쓰는 것이 테스트 절차다. 절차가 모호하면 같은 테스트를 해도 사람마다 결과가 달라지고, 결함을 재현하지 못해 "재현 불가"로 닫히는 일이 생긴다.

테스트 환경은 실제 운영 환경과 비슷해야 한다

테스트 환경과 실제 운영 환경의 차이가 클수록, 테스트에서 통과한 케이스가 운영에서 실패할 가능성이 커진다. 내비게이션 소프트웨어라면 GPS·DMB 수신기까지, 자동차 소프트웨어라면 안전한 시험 도로까지 환경에 포함된다. 컴포넌트 테스트에서는 대상 컴포넌트가 혼자 실행될 수 없으므로 드라이버와 스텁도 테스트 환경에 포함 된다 (레슨 4에서 자세히 다룬다).

테스트 분류의 세 축

가이드는 테스트를 세 가지 서로 독립인 기준 으로 나누고, 이를 3차원 축으로 그린다.

축이 독립이라는 말은, 한 테스트를 세 축 위의 한 점으로 표현할 수 있다는 뜻이다. 예를 들어 "결제 시스템 전체를 대상으로, 응답 시간을, 요구 명세의 부하 조건으로 케이스를 만들어 테스트한다"는 시스템 레벨 · 성능 효율성 유형 · 명세 기반 기법 이다.

축 1 — 테스트 레벨

시스템 테스트와 인수 테스트는 대상이 같고(전체 시스템) 관점이 다르다. 앞쪽은 개발 조직이 명세 기준으로, 뒤쪽은 고객·사용자 관점에서 본다. 이 차이는 레슨 4에서 더 다룬다.

축 2 — 테스트 유형과 ISO 25010 품질 특성

요구사항 명세는 기능 요구사항 과 품질 요구사항 을 함께 담는다. 기능 요구사항을 보는 테스트가 기능 테스트, 품질 요구사항을 보는 테스트가 비기능 테스트다. 29119는 기능 테스트와 각각의 비기능 테스트를 통틀어 유형 테스트(Type test) 라고 부른다.

비기능 테스트의 기준이 되는 것이 ISO 25010의 품질 모델이다. 여덟 가지 주특성과 부특성을 표로 정리한다.

헷갈리는 쌍 몇 개를 짚어 둔다.

• 가용성은 신뢰성의 부특성 이다(보안성이 아니다). 사용하려 할 때 쓸 수 있는 정도.
• 테스트 용이성은 유지보수성의 부특성 이다. 옛 판 표 4.6에는 이 주변 표기에 "안전성" 오타가 있어 "안정성"으로 정정되었다.
• 공존성 (다른 SW에 나쁜 영향 없이 자원을 공유)과 상호운영성 (정보를 교환하고 쓴다)은 둘 다 호환성 아래에 있다.
• 수용성(Capacity) 은 동시 사용자 수·처리량 같은 매개 변수의 최대 한계가 요구를 만족하는 정도로, 성능 효율성 아래에 있다.

참고로 ISO/IEC 25010은 2023년에 개정되어 주특성이 아홉 개(안전성 추가, 사용성은 상호작용 능력, 이식성은 유연성으로 개칭)가 되었다. 하지만 CSTS 가이드와 시험은 2011년판의 여덟 주특성을 기준 으로 하므로, 시험에서는 위 표대로 답한다. 실무 문서에서 새 이름을 만나면 같은 개념의 개정판 표기라는 것만 알아 두면 된다.

축 3 — 테스트 설계 기법: 정적과 동적

정적 테스트 는 대상을 실행하지 않고 결함을 찾는다.

• 리뷰 — 사람이 산출물(요구사항서, 설계서, 코드)을 읽고 검토한다.
• 정적 분석 — 도구가 주로 소스 코드의 구조를 자동으로 분석한다. 코딩 표준(MISRA C 등) 준수 검사, 복잡도 측정(사이클로매틱 복잡도), 자료 흐름 이상 분석이 대표적이다.

정적 테스트의 장점은 두 가지로 외운다. 첫째, 실행 환경이 필요 없다. 둘째, 코드가 생기기 전의 산출물(요구사항서·설계서)도 테스트할 수 있다. 앞 레슨의 결함 비용 곡선을 떠올리면 이것이 왜 경제적인지 알 수 있다. 단점으로는 정적 분석 도구의 오검지(False positive) — 결함이 아닌 것을 결함으로 보고하는 것 — 가 있다. 오검지가 많아지면 개발자가 도구 결과 자체를 믿지 않게 된다.

동적 테스트 는 대상을 실행해서 결함을 찾는다. 케이스를 정하는 방법에 따라 셋으로 나뉜다.

동적 테스트의 특징도 짝으로 외운다. 소스 코드가 없어도 할 수 있다 (외주 컴포넌트를 실행 파일로만 받은 경우). 대신 실행 환경이 반드시 필요하다. 그리고 "USB를 꽂으면 1초 안에 재생" 같은 성능 요구, 가용성·확장성·신뢰성 같은 품질 요구는 코드를 읽어서는 확인하기 어렵고 실행해야 확인할 수 있다.

명세 기반은 명세만 있으면 모든 레벨 (컴포넌트·통합·시스템·인수)에 쓸 수 있다. 무작위로 입력을 만드는 랜덤 테스트도 코드를 보지 않으므로 명세 기반으로 분류된다는 점이 함정 문제로 나온다.

경험 기반 두 기법의 차이

오류 추정(Error guessing) 은 개발자가 저지를 만한 실수를 떠올리고 그 실수가 드러나도록 케이스를 만든다. tan(x)에서 무한대가 되는 90°, 0 값 처리, 크기 0인 입력, 일치하는 값이 없는 검색, 이미 정렬된 목록 같은 것이다. 필수 입력 누락, 길이 제약 위반, 형식 위반, 명시적 범위 위반, 상식적으로 가정되는 범위(묵시적 제약) 위반이 대표 상황이다. 오류 추정은 동등 분할과 함께 쓸 수 있는데, 명세가 분명히 정하지 않는 유효하지 않은 분할 을 정할 때 특히 쓸모가 있다.

탐색적 테스트 는 대상의 이해·케이스 설계·실행을 동시에 진행한다. 사전에 테스트 명세서를 쓰지 않고, 앞 테스트의 결과로 다음 테스트를 정한다. 무엇을 탐색할지 적은 짧은 테스트 차터 를 쓸 수 있다. 개발 주기가 짧은 애자일 웹 시스템에 잘 맞는다. 단점은 목표 없이 헤매는 시간, 여러 사람이 같은 곳을 중복 탐색하는 문제, 범위를 문서화하지 않아 커버리지를 판단할 수 없다 는 점이다.

리뷰의 다섯 유형 — 목적으로 구분한다

리뷰 절차의 순서도 나온다. 경영진 준비 → 리뷰 계획 → 리뷰 절차 개요 설명(Overview of review procedures) → 작업물 개요 설명 → 개별 준비 → 그룹 검토 → 재작업 → 후속 작업.

실무에서 왜 필요한가

세 축 분류는 테스트 계획을 빠뜨림 없이 짜는 체크리스트다. 레벨 축만 보고 "단위·통합· 시스템 다 했다"고 해도, 유형 축에서 보안성과 호환성이 비어 있을 수 있다. 실제로 국내 SI 검수에서 지적이 많이 나오는 것은 기능 테스트 결과는 두꺼운데 비기능 테스트 결과가 한두 쪽뿐인 경우다. 계획서를 쓸 때 레벨 × 유형 표를 만들어 칸마다 "한다/안 한다/이유"를 적으면 이런 구멍이 보인다.

ISO 25010 표는 품질 요구사항을 끌어내는 도구이기도 하다. 기획서에 성능 요구가 없다면 "응답 시간 기준이 없는데 몇 초까지 허용하나요?"라고 물을 근거가 된다. 요구가 없으면 테스트 기준도 없고, 기준이 없으면 어떤 결과가 나와도 결함이라고 말할 수 없다.

테스트 케이스와 테스트 절차를 구분해 관리하면 재사용이 쉬워진다. 같은 "결제 승인" 케이스를 신용카드 절차, 간편결제 절차, 리그레션 절차에서 함께 쓰는 식이다. 테스트 관리 도구에서 케이스와 실행(Run)을 따로 두는 이유가 이것이다.

채용시장에서의 위치

공공·금융 SI의 테스트 직무 공고에는 "단위·통합·시스템 테스트 수행 경험", "비기능 (성능·보안) 테스트 경험"이 거의 빠지지 않는다. 이 문장이 바로 레벨 축과 유형 축이다. 면접에서 "어떤 테스트를 해 봤나요?"라는 질문에 "기능 테스트요"라고만 답하면 약하고, "시스템 레벨에서 기능과 사용성 위주로 명세 기반 케이스를 설계했고, 성능은 별도 팀이 맡았습니다"처럼 세 축으로 답하면 경험의 범위가 정확히 전달된다.

실습 과제

과제 1 — 세 축 위에 점 찍기

다음 테스트를 레벨 · 유형 · 설계 기법의 세 값으로 적어 본다.

1. 개발자가 할인 계산 함수의 모든 분기를 한 번씩 실행하도록 단위 테스트를 만들었다.
2. 테스터가 회원가입 화면 전체를 대상으로, 명세서의 입력 규칙에서 경계값을 뽑아 테스트했다.
3. 고객사 담당자들이 실제 업무 시나리오대로 새 시스템을 써 보고 인수 여부를 판단했다.
4. 도구로 소스 코드의 MISRA C 규칙 위반을 검사했다.

과제 2 — 품질 특성 매칭

다음 요구를 ISO 25010의 주특성과 부특성으로 분류해 본다.

1. 서버 한 대가 죽어도 서비스가 계속되어야 한다.
2. 동시 접속 1만 명까지 처리해야 한다.
3. 결제 내역에 대해 사용자가 "내가 한 거래가 아니다"라고 부인할 수 없어야 한다.
4. 처음 쓰는 사용자도 10분 안에 주요 기능을 익혀야 한다.
5. 기존 회계 시스템과 데이터를 주고받아야 한다.

과제 3 — 연습 문제 (4지선다)

1. 테스트 케이스에 대한 설명으로 옳지 않은 것은? ① 입력값과 예상 결과를 묶은 것이다 ② 하나의 케이스는 여러 테스트 절차에서 쓰일 수 있다 ③ 예상 결과는 실행 후 실제 결과를 보고 정한다 ④ 입력을 주는 방법과 결과를 비교하는 방법도 포함한다
2. 정적 테스트의 장점이 아닌 것은? ① 실행 환경이 필요 없다 ② 요구사항 명세서도 대상이 될 수 있다 ③ 응답 시간 같은 성능 요구를 직접 확인할 수 있다 ④ 코드 작성 전에 결함을 찾아 비용을 줄인다
3. 다음 중 구조 기반 테스트 기법은? ① 분류 트리 기법 ② 인과 그래핑 ③ MC/DC ④ 신택스 테스트
4. 문제를 식별하고 대안 조사, 개선, 학습 기회 제공까지 하는 리뷰 유형은? ① 감사 ② 워크쓰루 ③ 관리 리뷰 ④ 기술 리뷰

자가 체크리스트

• 테스트 대상·피처·설계 기법·케이스·절차·환경 여섯 용어를 정의하고 관계를 그릴 수 있다
• 테스트 케이스에 예상 결과가 왜 반드시 들어가야 하는지 설명할 수 있다
• 테스트 절차와 테스트 스크립트의 차이를 말할 수 있다
• 테스트 분류의 세 축(레벨·유형·설계 기법)과 각 축의 값을 말할 수 있다
• 기능 테스트는 모든 레벨에서, 비기능 테스트는 주로 시스템·인수 레벨에서 한다는 점을 안다
• ISO 25010의 여덟 주특성을 외우고, 가용성·테스트 용이성·수용성이 어느 주특성 아래인지 안다
• 정적 테스트와 동적 테스트의 장단점을 두 개씩 말할 수 있다
• 명세 기반·구조 기반·경험 기반의 대표 기법을 두 개씩 댈 수 있다
• 리뷰 다섯 유형을 목적으로 구분할 수 있다

흔한 실수

피처를 "기능"으로만 이해하기. 피처는 테스트하려는 측면·관점 이다. 기능 피처도 있고, 성능·보안 같은 비기능 피처도 있다. "피처 = 기능"으로 외우면 "피처에 초점을 둔 테스트를 유형 테스트라 한다"는 문장을 이해할 수 없다.

테스트 환경에서 드라이버·스텁·테스트 도구를 빼기. 테스트 환경은 하드웨어와 운영체제만이 아니다. 대상을 실행하기 위한 모든 것 — 외부 연동 시스템(또는 시뮬레이터), 공존 SW, 드라이버· 스텁, 결과를 비교하는 도구 — 가 들어간다.

25010 개정판 이름으로 답하기. 2023년 개정판의 "상호작용 능력", "유연성", "안전성"을 시험 답으로 고르면 틀릴 수 있다. CSTS는 2011년판 여덟 주특성을 쓴다.

랜덤 테스트를 경험 기반으로 고르기. 코드를 보지 않고 입력을 만들므로 명세 기반으로 분류된다. 경험 기반은 테스터의 경험·직관이 케이스를 정하는 경우다.

참고 자료

• 한국정보통신기술협회, 『소프트웨어 테스트 전문가(CSTS) 가이드』 개정판 — 1장 1.4~1.5절, 2장 2.2절, 3장 3.1절, 4장 4.1절. 정오표 2번(그림 1.14)·7번(표 4.6) 반영
• ISO/IEC 25010:2011 — System and software quality models — CSTS가 기준으로 쓰는 판
• ISO/IEC 25010:2023 — Product quality model — 개정판(아홉 주특성). 실무 문서에서 만날 수 있는 새 이름
• ISO/IEC/IEEE 29119-4:2021 — Test techniques — 명세 기반·구조 기반·경험 기반 기법의 표준 정의
• IEEE Std 1028-2008 — Software Reviews and Audits — 관리 리뷰·기술 리뷰·인스펙션·워크쓰루·감사의 원전
• 이 커리큘럼 안: 모듈 1 레슨 3·4 「테스트 레벨」「테스트 유형」, 모듈 3 레슨 2 「테스트 설계 기법 지도」, 모듈 3 레슨 8 「경험 기반 기법」, 모듈 5 「탐색적 테스팅」, 모듈 16 「비기능 테스트 종합」