시스템 테스트

시스템 테스트는 다 조립한 소프트웨어를 한 덩어리로 돌려 보며 요구한 대로 움직이는지 확인합니다. 부분끼리 잘 붙었는지가 아니라 전체가 해야 할 일을 하는지를 봅니다. 응답 속도나 장애를 견디는 힘처럼 전체를 띄워야만 잴 수 있는 것도 이때 봅니다. 사용자에게 넘기기 전에 만든 쪽이 하는 마지막 큰 검사입니다.

쉽고 빠른 이해

무슨 일을 하나 — 조립을 마친 시스템을 사용자처럼 바깥에서 써 보는 검사입니다. 요구사항대로 움직이는지 확인합니다. 주문 시스템이라면 재고가 없는 상품을 주문했을 때 거절되는지를 봅니다.

왜 하나 — 부분마다 검사를 통과해도 전체가 요구를 채운다는 보장은 없습니다. 설계에서 요구 하나가 빠졌다면 그 설계로 짠 테스트에서도 빠집니다. 응답 속도나 서버 하나가 죽었을 때의 동작은 전체를 띄워야 잴 수 있습니다.

어떻게 도나

요구사항에서 확인할 경우를 뽑아 테스트 케이스로 적습니다
조립한 시스템을 운영과 비슷하게 꾸린 환경에 올립니다
바깥에서 요청을 넣고 결과가 기대와 같은지 봅니다

대가 — 시스템 전체를 띄우고 데이터를 준비하느라 오래 걸립니다. 깨졌을 때 원인이 어느 부분에 있는지 다시 찾아야 합니다. 그래서 전체를 띄워야 확인되는 것에만 씁니다. 부분 하나로 확인되는 것은 단위 테스트에 맡깁니다.

상세

이 절은 쇼핑몰의 주문 시스템 하나를 가지고 시스템 테스트를 봅니다. 주문 시스템은 주문 서비스, 재고 서비스, 주문을 저장하는 데이터베이스로 이루어집니다. 결제는 바깥 회사가 운영하는 결제 서버에 맡깁니다.

시스템 테스트는 자동차의 시험 주행과 닮았습니다. 엔진과 브레이크는 부품 단계에서 이미 검사를 마쳤습니다. 그래도 완성차를 시험 주행로에서 직접 몰아 봅니다. 주문한 사람이 요구한 속도와 제동 거리가 나오는지를 차 한 대 전체로 확인합니다.

시스템 테스트는 부분을 전부 이어 붙인 시스템 전체를 놓고, 그 시스템이 요구사항을 채우는지 확인하는 테스트입니다. 요구사항은 시스템이 무엇을 해야 하는지 적어 둔 약속입니다. 주문 시스템이라면 「재고가 없는 상품은 주문할 수 없다」가 요구사항 하나입니다. 시스템 테스트는 재고가 0개인 상품을 주문해 보고 거절되는지를 봅니다.

앞 단계의 테스트는 시스템의 일부만 봅니다. 단위 테스트는 함수나 클래스 하나를 떼어 검사합니다. 통합 테스트는 부분 둘 이상을 이어 붙인 이음매를 검사합니다.

두 테스트는 개발자가 짠 설계에 비춰 기대한 값을 정합니다. 설계에서 요구사항 하나가 빠졌다면 테스트에서도 빠집니다. 주문 서비스가 재고를 묻지 않고 주문을 받도록 설계됐다면 단위 테스트와 통합 테스트는 전부 통과합니다. 시스템 전체를 요구사항에 비춰 봐야 재고 0개인 상품이 팔린다는 것이 드러납니다.

전체를 띄워야만 잴 수 있는 것도 있습니다. 주문 한 건에 몇 초가 걸리는지, 주문이 한꺼번에 몰리면 버티는지, 재고 서비스가 죽으면 주문 서비스가 어떻게 구는지가 그렇습니다. 부분 하나를 떼어서는 이런 값이 나오지 않습니다.

테스트 수준 속 시스템 테스트

테스트는 흔히 한 번에 검사하는 넓이에 따라 네 단계로 나눕니다. 이 단계를 테스트 수준이라고 부릅니다. 아래 표는 네 수준을 좁은 것부터 차례로 놓습니다.

수준	검사 대상	무엇에 비춰 보나	주로 하는 사람
단위 테스트	함수나 클래스 하나	개발자가 짠 설계	개발자
통합 테스트	이어 붙인 부분 둘 이상	부분 사이의 약속	개발자
시스템 테스트	조립을 마친 시스템 전체	요구사항	만든 쪽의 테스터
인수 테스트	조립을 마친 시스템 전체	요청한 쪽의 기대	요청한 쪽과 사용자

표에서 시스템 테스트와 인수 테스트는 검사 대상이 같습니다. 둘을 가르는 것은 누가 무엇을 위해 하느냐입니다. 시스템 테스트는 만든 쪽이 요구사항을 채웠는지 스스로 확인합니다. 인수 테스트는 요청한 쪽이 넘겨받을지를 정하려고 확인합니다.

네 수준을 개발 단계와 짝지어 놓은 모델이 V 모델입니다. V의 왼쪽 가지는 요구사항 정의, 시스템 설계, 상세 설계 순으로 내려가는 개발 단계입니다. 오른쪽 가지는 단위, 통합, 시스템, 인수 테스트 순으로 올라가는 테스트 수준입니다. 두 가지에서 같은 높이에 놓인 단계끼리 짝을 이룹니다.

요구사항을 정하는 단계는 인수 테스트와 짝을 이룹니다. 시스템 전체를 설계하는 단계는 시스템 테스트와 짝을 이룹니다. 시스템 설계는 요구사항을 시스템이 할 일로 풀어 적는 단계입니다. 그렇게 풀어 적은 요구사항이 시스템 테스트에서 확인할 기준이 됩니다.

바깥에서만 건드리는 검사

시스템 테스트는 시스템 안쪽을 들여다보지 않습니다. 사용자가 쓰는 입구로만 들어가서 결과를 봅니다. 이 소절은 주문 시스템에서 무엇을 진짜로 띄우고 테스트가 어디를 건드리는지를 봅니다.

주문 시스템의 입구는 주문 서비스가 받는 HTTP(HyperText Transfer Protocol) 요청입니다. 테스트는 이 입구로 주문 요청을 보냅니다. 돌아온 응답과 주문 내역을 다시 조회한 결과만 보고 통과를 가립니다.

시스템 안쪽은 전부 진짜로 띄웁니다. 주문 서비스, 재고 서비스, 데이터베이스가 운영과 같은 모양으로 붙어 있습니다. 바깥 회사의 결제 서버만 테스트용 가짜 결제 서버로 바꿉니다. 테스트할 때마다 진짜 돈이 빠져나가면 안 되기 때문입니다.

flowchart TD
    T["시스템 테스트"]
    subgraph S["조립을 마친 주문 시스템"]
        O["주문 서비스"] --> DB[("데이터베이스")]
        O --> I["재고 서비스"]
    end
    P["가짜 결제 서버"]
    T -->|"주문 요청"| O
    O --> P

그림에서 테스트가 닿는 곳은 주문 서비스 하나뿐입니다. 재고 서비스와 데이터베이스는 주문 서비스를 거쳐서만 움직입니다. 가짜 결제 서버는 시스템 바깥에 있으니 진짜 대신 끼워 두어도 시스템 전체를 검사한다는 뜻이 흐려지지 않습니다.

이렇게 속 구조를 모르는 채로 입력을 넣고 결과만 보는 방식을 블랙박스 테스트라고 부릅니다. 시스템 테스트는 대개 이 방식을 따릅니다. 코드를 짠 개발자 말고 따로 둔 테스터가 맡는 일이 많은 것도 같은 까닭입니다. 코드를 모르는 사람이어야 코드가 아니라 요구사항에 비춰 봅니다.

요구사항에서 뽑는 테스트 케이스

시스템 테스트는 요구사항에서 출발합니다. 요구사항 하나마다 확인할 경우를 뽑아 적습니다. 이렇게 적은 경우 하나를 테스트 케이스라고 부릅니다.

테스트 케이스 하나에는 세 가지를 적습니다. 시작할 때의 상황, 넣는 입력, 기대하는 결과입니다. 아래 표는 「재고가 없는 상품은 주문할 수 없다」에서 뽑은 테스트 케이스 셋입니다.

시작할 때의 상황	넣는 입력	기대하는 결과
키보드 재고 1개	키보드 1개 주문	주문 성공, 재고 0개
키보드 재고 0개	키보드 1개 주문	주문 거절, 결제 요청 없음
키보드 재고 1개	두 사람이 동시에 1개씩 주문	한 명만 성공, 재고 0개

첫째 줄은 요구사항이 지켜지는 평범한 경우입니다. 둘째 줄은 요구사항이 막으려는 경우입니다. 주문이 거절됐다는 응답에 더해 결제 서버로 요청이 안 갔는지도 봅니다. 가짜 결제 서버가 받은 요청을 세면 확인할 수 있습니다.

셋째 줄은 부분만 떼어서는 잘 안 드러나는 경우입니다. 두 요청이 거의 같은 순간에 재고를 읽으면 둘 다 1개가 남았다고 보고 주문을 받을 수 있습니다. 요청이 겹치는 순서에 따라 결과가 달라지는 이런 결함을 경쟁 상태라고 부릅니다. 전체를 띄우고 요청을 겹쳐 보내야 이 결함이 보입니다.

기능 아닌 요구를 보는 시스템 테스트

요구사항은 두 갈래로 나뉩니다. 시스템이 무엇을 하는지 적은 것이 기능 요구사항입니다. 얼마나 빠르게, 얼마나 안전하게, 얼마나 잘 버티며 하는지 적은 것이 비기능 요구사항입니다.

앞 소절의 재고 확인은 기능 요구사항을 본 것입니다. 비기능 요구사항은 시스템 전체를 띄워야 잴 수 있어서 시스템 테스트에서 주로 봅니다. 아래 표는 흔히 하는 종류를 주문 시스템에 맞춰 놓은 것입니다.

종류	주문 시스템에서 확인하는 것
성능 테스트	주문 한 건의 응답이 정한 시간 안에 오나
부하 테스트	평소보다 많은 주문이 몰려도 버티나
보안 테스트	남의 주문 내역을 조회할 수 없나
복구 테스트	재고 서비스가 죽었다 살아나면 주문이 다시 되나

운영을 닮은 테스트 환경

시스템 테스트는 운영과 최대한 비슷한 환경에서 돌립니다. 운영과 다른 환경에서 통과한 결과로는 운영에서도 된다고 믿을 수 없기 때문입니다. 출시 직전 확인에 쓰려고 운영을 닮게 꾸린 환경을 흔히 스테이징 환경이라고 부릅니다.

환경이 운영과 어긋나는 곳에서 결함이 숨습니다. 데이터베이스 버전이 다르거나, 설정 값 하나가 다르거나, 데이터 양이 운영보다 훨씬 적은 경우가 그렇습니다. 데이터가 백 건일 때 빠르던 조회가 백만 건에서는 느려질 수 있습니다.

테스트 데이터도 미리 준비합니다. 테스트 케이스마다 정해 둔 시작 상황을 만들려면 재고 1개짜리 키보드 같은 데이터를 넣어 둬야 합니다. 테스트가 끝나면 지우거나 처음 상태로 되돌립니다. 앞 테스트가 남긴 데이터가 다음 테스트의 결과를 바꾸지 않게 하려는 것입니다.

다른 테스트와 나뉘는 선

시스템 테스트와 가장 자주 섞이는 이름은 종단 간 테스트입니다. 종단 간 테스트는 사용자가 쓰는 흐름 하나를 처음부터 끝까지 따라가는 테스트입니다. 상품을 담고, 결제하고, 주문 내역을 확인하기까지를 한 번에 돌립니다.

두 이름은 붙은 기준이 다릅니다. 시스템 테스트는 테스트 수준에 붙은 이름이라 검사 대상이 시스템 전체라는 뜻입니다. 종단 간 테스트는 흐름을 따라가는 방식에 붙은 이름입니다.

기준이 다르니 한 테스트가 두 이름을 같이 가질 수 있습니다. 시스템 테스트 안에서 종단 간 흐름을 돌리는 일이 흔합니다. 팀에 따라 두 이름을 거의 같은 뜻으로 쓰기도 합니다.

테스트 수준은 넓이에 더해 무엇에 비춰 보나와 누가 하나까지 함께 가릅니다. 이와 달리 좁음과 넓음 같은 크기 하나로만 테스트를 가르는 팀도 있습니다. 이런 팀은 시스템 전체를 띄우는 테스트를 넓은 범위 테스트로 묶어 부릅니다. 시스템 테스트는 그 묶음에 드는 이름 가운데 하나입니다.

회귀 테스트와도 겹칩니다. 회귀 테스트는 코드를 바꾼 뒤 이미 통과한 테스트를 다시 돌려, 되던 기능이 안 되는지 보는 쓰임입니다. 시스템 테스트 케이스도 남겨 두었다가 새 버전마다 다시 돌리면 회귀 테스트 노릇을 합니다.