소프트웨어 개발 4강. 애플리케이션 테스트
테스트는 결함이 없음을 증명하지 못합니다. 오직 결함이 있음만 증명할 수 있죠. 다익스트라의 이 말이 테스트 원리 일곱 개의 첫 줄입니다.
풀고 시작
테스트가 증명할 수 있는 것은 하나뿐입니다
에츠허르 다익스트라가 남긴 유명한 문장이 있습니다. 테스트는 결함의 존재를 보여 줄 수 있을 뿐 결함이 없음을 보여 주지는 못한다는 말이죠. 모든 입력을 다 넣어 볼 수 없기 때문입니다. 그래서 테스트의 목표는 완벽한 증명이 아니라 결함을 효율적으로 찾아내는 것으로 옮겨 갑니다.
여기서 나오는 소프트웨어 테스트의 원리 일곱 가지 중 셋은 꼭 알아 두셔야 합니다. 완벽한 테스트는 불가능하다는 것, 결함이 특정 모듈에 몰려 있다는 결함 집중(파레토 원칙), 그리고 같은 테스트를 반복하면 더 이상 새 결함을 못 찾는다는 살충제 역설입니다. 살충제를 계속 뿌리면 벌레가 내성을 갖듯, 테스트 케이스도 주기적으로 갱신해야 한다는 뜻입니다.
블랙박스와 화이트박스
테스트 케이스를 설계하는 방식은 크게 둘입니다.
블랙박스 테스트는 내부 구현을 모른 채 명세만 보고 입력과 출력을 확인합니다. 기법으로는 입력 값을 비슷한 그룹으로 나눠 대표값만 넣어 보는 동치 분할, 그룹의 경계에서 오류가 잦다는 사실을 이용하는 경곗값 분석, 여러 조건 조합을 표로 정리하는 결정 테이블, 상태 전이, 원인-결과 그래프 등이 있습니다. 경곗값 분석이 가장 자주 나옵니다. 1부터 100까지 허용하는 입력이라면 0, 1, 100, 101을 넣어 보는 식이죠. 프로그래머가 부등호를 잘못 쓰는 자리가 정확히 거기이기 때문입니다.
화이트박스 테스트는 내부 논리를 보고 설계합니다. 구문 커버리지는 모든 명령문을 한 번씩 실행하는 것, 결정 커버리지는 모든 조건문의 참과 거짓을 각각 한 번씩 거치는 것, 조건 커버리지는 개별 조건식의 참과 거짓을 각각 거치는 것입니다. 이 셋을 합친 것이 조건/결정 커버리지이고, 더 엄격한 것이 변경 조건/결정 커버리지(MC/DC)입니다. 기본 경로 검사와 루프 검사도 화이트박스에 속합니다.
테스트는 V자로 올라갑니다
수행 단계는 넷이고, 개발 단계와 하나씩 대응합니다. 이 대응을 그림으로 그린 것이 V 모델입니다.
| 단계 | 무엇을 확인하나 | 대응하는 개발 단계 |
|---|---|---|
| 단위 테스트 | 함수·모듈 하나가 제대로 동작하는가 | 상세 설계 |
| 통합 테스트 | 모듈을 붙였을 때 인터페이스가 맞는가 | 아키텍처 설계 |
| 시스템 테스트 | 전체 시스템이 요구를 만족하는가 | 시스템 설계 |
| 인수 테스트 | 사용자가 받아들일 수 있는가 | 요구사항 분석 |
인수 테스트에서 갈라지는 두 낱말이 있습니다. 알파 테스트는 개발자가 지켜보는 앞에서 통제된 환경에서 수행합니다. 베타 테스트는 실제 사용자가 자기 환경에서 수행하고 개발자는 그 자리에 없습니다. 개발자가 옆에 있으면 알파라고 기억하시면 뒤집히지 않습니다.
회귀 테스트(regression test)도 중요합니다. 코드를 고친 뒤 그 수정이 멀쩡하던 다른 기능을 망가뜨리지 않았는지 확인하는 테스트입니다. 자동화가 가장 절실한 영역이기도 하죠.
결함 관리와 성능 개선
발견한 결함은 등록하고, 원인을 분석하고, 수정하고, 재확인하고, 결과를 공유하는 절차를 밟습니다. 여기서 용어 셋을 구분하셔야 합니다. 사람이 저지른 실수가 에러(error), 그 결과로 코드에 남은 문제가 결함(defect) 또는 결점, 그 결함이 실행 중에 겉으로 드러난 현상이 실패(failure)입니다. 사람이 틀려서 코드가 잘못되고 그래서 시스템이 넘어진다는 인과의 사슬로 외우시면 됩니다.
성능은 네 지표로 잽니다. 시간당 처리량인 처리량(throughput), 요청 후 응답이 오기까지의 응답 시간(response time), 작업을 마치기까지 걸린 반환 시간(turnaround time), 그리고 자원 사용률입니다.
코드 자체의 문제를 정리하는 활동도 있습니다. 겉으로 드러나는 동작을 바꾸지 않으면서 내부 구조를 개선하는 리팩토링, 그리고 중복 코드나 사용하지 않는 변수처럼 오류를 부르는 코드인 나쁜 냄새(bad smell)를 찾아 없애는 작업이죠. 실행하지 않고 코드만 분석해 결함을 찾는 도구를 정적 분석 도구라고 부릅니다.
다음 강에서는 시스템 사이를 잇는 인터페이스 구현과 그 보안을 봅니다.
인출 문제
생각해볼 질문 (정답 없음)
테스트를 아무리 해도 결함이 없다고는 말할 수 없습니다. 그렇다면 "이제 출시해도 된다"는 판단은 무엇을 근거로 내려야 정당할까요.
이전: 3강 제품 소프트웨어 패키징 · 다음: 5강 인터페이스 구현과 성능 개선