AI 테스트 케이스 만들기: 정상·경계·실패 조건 설계

AI에게 “테스트 케이스를 만들어 줘”라고 하면 정상적인 입력을 여러 번 바꾼 목록이 나올 때가 있습니다. 개수는 많아도 중요한 실패 조건이 빠지거나, 기대 결과가 “정상 작동”처럼 모호하면 실제 검증에 쓰기 어렵습니다.
좋은 테스트 케이스에는 어떤 상태에서 무엇을 입력하고, 어떤 결과가 나와야 하는지가 들어갑니다. 이 글에서는 코드를 수정하기 전에도 준비할 수 있는 정상·경계·실패 조건 설계를 가상의 예약 수량 입력 기능으로 살펴봅니다.

1. 테스트보다 먼저 통과 기준을 정하기

첫 단계는 기능의 규칙을 확인하는 것입니다. 입력 범위, 필수값, 허용 형식, 처리 후 남아야 할 상태를 적습니다. 규칙이 불분명한데 케이스부터 만들면 AI가 제품 정책을 임의로 정하기 쉽습니다.

요구사항을 바탕으로 정상·경계·실패 입력과 기대 결과를 나누는 과정을 설명하는 그림입니다.
“수량은 적절해야 한다”보다 “수량은 1부터 5까지의 정수이며, 잘못된 값이면 저장하지 않고 안내한다”가 테스트하기 좋습니다. 다만 빈칸을 기본값으로 채울지, 이전 값을 유지할지는 추가로 정해야 합니다. 문서에 없는 정책은 미정 항목으로 남겨 담당자에게 확인합니다.
케이스 한 개는 사전조건, 입력과 행동, 기대 결과로 구성합니다. 예약 전 기록이 0개인지, 같은 사용자의 예약이 이미 있는지도 결과에 영향을 줄 수 있습니다. 실행 뒤 데이터를 초기화하는 방법까지 적어 두면 앞선 테스트가 다음 테스트에 영향을 주는 일을 줄일 수 있습니다.

2. 정상 조건과 경계값을 나누기

정상 조건에서는 대표적인 유효 입력이 의도대로 처리되는지 봅니다. 1부터 5까지 허용한다면 가운데 값인 3을 넣고 저장 결과를 확인하는 것이 한 예입니다. 비슷한 정상값만 늘리는 대신, 다른 규칙을 확인하는 입력을 고르는 편이 낫습니다.
경계값은 허용 범위가 바뀌는 지점입니다. 최소값 1 주변의 0·1·2와 최대값 5 주변의 4·5·6을 보면 범위 검사에서 한 칸씩 어긋난 문제를 찾는 데 도움이 됩니다. 경계 근처라도 1과 5는 허용되고, 0과 6은 거절되어야 합니다.

허용 범위의 양쪽 경계와 바로 바깥 값을 따로 확인하는 경계값 점검 그림입니다.
정상·경계·실패라는 이름은 점검 관점을 나누는 데 쓰면 됩니다. 경계에 놓인 유효값처럼 관점이 겹칠 수도 있습니다. 중요한 것은 분류표를 예쁘게 채우는 것보다, 각 입력에 어떤 결과를 기대하는지 분명하게 쓰는 것입니다.

3. 실패했을 때 남아야 할 상태까지 적기

실패 조건에는 빈 입력, 허용하지 않는 값, 사용할 수 없는 연결, 필요한 권한 부족 등이 포함될 수 있습니다. 모든 기능에 모든 조건을 넣기보다 실제 처리 흐름과 위험에 맞게 선택합니다. 실패를 의도적으로 만드는 시험은 안전한 테스트 환경에서 진행합니다.

연결 실패 상황에서 오류 안내와 중복 저장 방지를 확인하는 과정을 설명하는 그림입니다.
“에러가 뜬다”만으로는 기대 결과가 충분하지 않습니다. 사용자가 이해할 안내가 나오는지, 저장이 일부만 이뤄지지는 않는지, 다시 눌러도 중복 기록이 생기지 않는지처럼 관찰할 대상을 적습니다. 각 항목은 해당 기능의 요구사항과 맞아야 합니다.
또한 기능의 실패와 테스트의 실패를 구분해야 합니다. 잘못된 수량을 거절하도록 정했다면, 그 입력이 거절되고 기록이 늘지 않는 결과는 테스트 통과입니다. 오류 처리가 예상대로 동작했는지 확인하는 시험이기 때문입니다.

4. 가상 예시: 예약 수량 1개부터 5개까지

가상의 규칙을 정해 보겠습니다. 예약 수량은 1부터 5까지의 정수만 허용하고, 유효하면 입력한 수량으로 예약 기록 한 개를 저장합니다. 빈칸·소수·범위 밖 값은 안내 후 저장하지 않습니다. 각 시험은 예약 기록이 없는 상태에서 시작합니다.
정상 케이스는 3을 입력하고 저장하는 것입니다. 기대 결과는 수량 3이 담긴 기록이 한 개 생기는 것입니다. 경계 케이스인 1과 5도 각각 입력값 그대로 한 개의 기록을 만들어야 합니다. 2와 4는 경계 안쪽 값이 정상 처리되는지 확인합니다.
0과 6, 빈칸, 2.5는 각각 별도 케이스로 만듭니다. 기대 결과는 입력 안내가 표시되고 기록 수가 0개로 유지되는 것입니다. 한 케이스에 잘못된 조건을 여러 개 섞으면 어떤 검사가 작동했는지 알기 어려우므로 먼저 하나씩 확인합니다.
이 예시는 화면 입력을 대상으로 합니다. 내부 함수나 API를 시험할 때는 입력의 자료형과 변환 규칙까지 별도로 정해야 합니다. 화면에 숫자를 썼다는 이유만으로 모든 단계에서 숫자형으로 전달된다고 가정하지 않습니다.

5. AI에게 테스트 목록을 요청하는 방법

AI에게는 규칙을 먼저 주고 다음과 같이 요청할 수 있습니다. “아래 예약 수량 규칙을 기준으로 테스트 케이스를 만들어 줘. 각 케이스에 목적, 사전조건, 입력, 행동, 기대 결과, 정리 방법을 적어 줘. 정상·경계·실패 관점의 누락을 찾고, 규칙에 없는 기대 결과는 추정하지 말고 질문으로 남겨 줘.”
완성된 목록에서는 기대 결과가 실제로 관찰 가능한지 검토합니다. “잘 저장됨”이라는 문장은 저장된 수량과 기록 개수로 바꿉니다. 시간이 중요한 기능이라면 어느 시점까지 기다린 뒤 확인하는지도 정하되, 기준 시간을 AI가 임의로 만들게 하지 않습니다.
케이스가 너무 많다면 실패 시 영향이 큰 규칙과 자주 쓰는 흐름부터 우선순위를 정합니다. 같은 이유로 같은 결과를 확인하는 중복은 줄이고, 입력이 달라졌을 때 기대 결과가 달라지는 지점을 남깁니다. 조합 조건이 중요하다면 개별 입력 시험 뒤에 별도로 추가합니다.

6. 만든 케이스와 실행 결과를 구분하기

케이스 작성은 검증 준비입니다. 실제 실행 전에는 통과로 표시하지 않고 미실행 상태로 둡니다. 실행했다면 사용한 버전과 환경, 실제 결과, 기대 결과와의 차이를 기록합니다. 환경 문제로 진행하지 못한 항목도 통과나 실패와 구분해 남깁니다.

기대 결과와 실제 결과를 대조하고 통과·실패·미실행 상태를 구분하는 그림입니다.
자동화할 때도 입력과 기대값을 함께 다룹니다. 예를 들어 pytest의 매개변수화 기능은 여러 입력·기대값 묶음으로 같은 테스트를 반복하도록 도와줍니다. 자동 실행을 붙이기 전에 기대값 자체가 요구사항과 맞는지 검토하는 과정은 여전히 필요합니다.
AI는 놓치기 쉬운 조건을 확장하고 목록을 정리하는 데 유용합니다. 최종적으로는 요구사항에 근거한 기대 결과와 실제 실행 증거를 대조해야 합니다. 통과한 케이스의 수보다 어떤 위험을 확인했고 무엇이 남았는지 설명할 수 있는 목록을 목표로 삼아 보세요.