2025.09.17 - [빅데이터 학습자료/02. CSTS] - CSTS 2025 공략 (1편) : 예제 분석으로 본 '합격을 결정하는 5가지 개념'
1편에 이어 2편을 진행하고자 합니다.
많은 분들이 어려워하시는 '테스트 설계 기법'과
처음 마주하는 '단답형' 문제에 어떻게 접근해야 할지에 대해 정리해보도록 할게요.
1. 효율성의 함정: '동등 분할'과 '경계값'은 한 몸이다
많은 분들이 '동등 클래스 분할'과 '경계값 분석'을 별개의 것으로 암기합니다.
하지만 이 둘은 '효율적인 테스트'라는 하나의 목표를 위해 함께 학습하는 것이 좋습니다.
기출 예제 28번. 다음은 자동 온도 조절 장치에 관한 설명이다.
동등 클래스 분할 기법을 사용하여 선정할 수 있는 최소의 테스트 입력값들은 무엇인가?온도가 20도 아래로 떨어지면 히터 세기를 강으로 작동시키고,
온도가 25도 이상이 되면 히터의 작동을 중단시킨다.① 17, 23, 32
② 18, 19, 20, 25
③ 20, 23, 25, 30
④ 23, 25
정답은 ①번입니다. 이 문제를 통해 두 기법의 관계를 이해할 수 있습니다.
- 1단계 (동등 분할): 먼저 '동등 클래스 분할'로 전체 입력 범위를 비슷한 결과를 낼 것으로 예상되는 그룹으로 나눕니다.
- 유효 클래스 1: ~ 19도 (히터 강)
- 유효 클래스 2: 20 ~ 24도 (히터 약, 명시되지 않았지만 정상 범위)
- 유효 클래스 3: 25도 ~ (히터 중단)
- (필요하다면) 무효 클래스: 숫자가 아닌 값 등
- 2단계 (대표값 선정): 각 클래스에서 아무 값이나 하나씩 대표로 뽑습니다.
- 유효 클래스 1의 대표: 17
- 유효 클래스 2의 대표: 23
- 유효 클래스 3의 대표: 32
'동등 분할'은 무한한 테스트 케이스를 단 3개로 줄여주는 효율적인 도구입니다.
하지만 이것만으로는 부족한 이유는 버그가 각 클래스의 '경계'에서 자주 발생하기 때문입니다.
그래서 '경계값 분석'으로 이 경계들을 집중 공략하는 것입니다.
즉, 이 둘은 분리된 기법이 아니라, 넓게 범위를 나누고(동등 분할),
그중 가장 위험한 곳을 집중적으로 분석해야합니다(경계값 분석).
2. 관계의 시각화, '상태 전이'로 시스템 구체화
다양한 맥락에서 어떤 테스트 기법을 써야 할지 막막할 때가 있습니다.
기출 예제 34번. 어느 시스템에서 버튼이 눌러졌을 때의 액션은 시스템이 현재 어떤 기능을 수행하고 있는지에 따라 달라진다고 한다면 이를 테스트하는데 가장 적합한 테스트 방법은 무엇인가?
① 리그레션 테스트
② 상태 전이 테스트
③ 결정 테이블 테스트
④ 페어와이즈 테스트
정답은 ②번입니다. 이 문제의 핵심 키워드는 "시스템이 현재 어떤 기능을 수행하고 있는지에 따라 달라진다"입니다.
이는 시스템이 과거의 '상태(State)'를 기억하고 있다는 뜻입니다.
'상태 전이 테스트'는 단순히 기능을 테스트하는 것을 넘어, 시스템의 '생애 주기'를 테스트하는 기법입니다.
예를 들어, 온라인 강의 영상 플레이어는 '재생 중', '일시정지', '종료'라는 상태를 가집니다.
- '재생 중' 상태에서 재생 버튼을 누르면 아무 일도 일어나지 않아야 합니다.
- '일시정지' 상태에서 재생 버튼을 누르면 영상이 다시 재생되어야 합니다.
이처럼 동일한 '재생 버튼 클릭'이라는 이벤트가 현재 '상태'에 따라 다른 결과를 낳을 때, 상태 전이 다이어그램을 그려 모든 상태와 전이 과정을 누락 없이 테스트하는 것이 바로 상태 전이 테스트입니다.
이것은 시스템의 숨겨진 로직과 예외 상황을 발견하는 데 매우 효과적입니다.
3. 단답형 접근법 (1): '회귀 테스트'는 왜 필수인가?
단답형이 많이 걱정되시죠?
단답형은 개념의 핵심을 정확히 알고 있는지를 묻고 있기 때문에 중요한 내용들 위주로 정확히 암기해야합니다.
기출 예제 62번. 다음의 설명에 해당하는 테스트 유형을 기재하시오.
- 오류를 수정한 후 오류가 정상적으로 수정되었는지 확인한다.
- 오류 수정 중 발생된 코드 변경으로 인해, 새로운 오류가 발생하지 않았는지 확인한다.
정답은 회귀(Regression) 테스트입니다.
많은 분들이 '수정된 오류를 확인하는 테스트'라고만 알고 있지만, 이 테스트의 진짜 핵심은 두 번째 설명에 있습니다.
"새로운 오류가 발생하지 않았는지 확인한다."
개발은..하나의 버그를 잡았더니, 멀쩡하던 다른 기능 두 개가 망가지는 일은 비일비재합니다.
'회귀 테스트'는 이처럼 코드 수정이 의도치 않은 부작용(Side Effect)을 일으키지 않았는지,
즉 시스템이 과거의 안정적인 상태로 '퇴보(Regression)'하지 않았음을 확인하는 테스트입니다.
특히 요즘처럼 하루에도 몇 번씩 배포가 일어나는 애자일 환경에서는, 회귀 테스트 자동화가 곧 제품 품질의 생명선이 됩니다.
2편에서는 테스트 설계와 단답형 접근법에 대해 다뤄봤습니다.
3편에서는 '테스트 자동화', '위험 기반 테스트', 그리고 실제 커버리지를 계산하는 문제 등 조금 더 심화된 주제를 다뤄볼게요~
이 글에 공감하고, 단순히 답을 외우는 것을 넘어 이러한 부분을 이해하고 싶으신 분들은
아래 댓글로 이 글에서 가장 도움이 되었던 부분이나, 현재 가장 답답하게 느끼는 파트를 남겨주세요.
제가 직접 정리한 추가 자료를 보내드리겠습니다.
모두들 화이팅입니다. :-)
