PE Notes · SW
회귀 테스트
변경 뒤 예전 기능이 깨지지 않았는지 재확인하는 회귀를 정의하고, 전수·선택·우선순위 전략과 스모크·CI 자동화 자리를 비교합니다.
결제 한 줄을 고쳤더니 로그인이 실패합니다. 예전에 통과하던 길이 코드 변경 뒤에 되돌아간 상태가 가 잡는 대상입니다. 회귀 테스트는 결함 수정·기능 추가·리팩토링 뒤에 이미 있던 동작이 그대로인지를 다시 칩니다. 신규 기능을 증명하는 시험과 목적이 다릅니다. 부작용을 찾는 재검증입니다.
변경에서 다시 돌리기까지
절차는 짧습니다. 무엇이 바뀌었는지 보고, 영향 모듈을 짚고, 어떤 케이스를 다시 돌릴지 고르고, 파이프라인에서 실행한 뒤 실패를 회귀 결함으로 분류합니다. 고치면 같은 세트를 한 번 더 돕니다. 테스트 기법이 처음 케이스를 디자인하는 일이면, 회귀는 그 세트를 변경마다 되살리는 일입니다.
선택 전략은 셋입니다. 은 가진 케이스를 모두 다시 돌립니다. 빈칸이 가장 적고, 규모가 커지면 비용이 먼저 갑니다. 중요 릴리스·작은 제품에 맞습니다. 는 의존·변경 파일에 묶인 케이스만 고릅니다. 피드백은 빠르고, 영향 분석이 틀리면 구멍이 납니다. 는 최근 실패, 핵심 업무(인증·결제), 변경 인접, 커버가 넓은 순으로 앞에 둡니다. 제한 시간 안에 위험 높은 것부터 칩니다.
| 전략 | 범위 | 대가 |
|---|---|---|
| 전수 | 기존 스위트 전부 | 가장 두껍고 느리다 |
| 선택 | 영향으로 고른 부분집합 | 분석 실수가 미탐이 된다 |
| 우선순위 | 같은 집합을 순서만 재배열 | 뒤쪽은 잘릴 수 있다 |
자동화는 반복 때문에 전제에 가깝습니다. 단위는 커밋마다, API는 계약·통합, UI는 드문 스모크·핵심 시나리오입니다. 가 병합마다 트리거합니다. 화면 픽셀을 이전 스냅샷과 비교하는 시각 회귀는 CSS·디자인 토큰이 바뀐 자리에 둡니다.
스모크와 재료 목록
는 빌드가 기본 경로를 여는지 짧게 봅니다. 회귀의 부분집합인 경우가 많고, 길이는 분 단위입니다. 인수는 고객 시나리오의 수락이고, 회귀는 변경 영향과 기존 핵심입니다. 세 시험을 한 문장에 섞지 않습니다.
| 비교축 | 회귀 | 스모크 | 인수 |
|---|---|---|---|
| 질문 | 예전 기능이 깨졌나 | 빌드가 기본을 하나 | 고객이 받겠나 |
| 때 | 변경 후마다 | 배포·빌드 직후 | 릴리스 전 |
| 두께 | 영향 + 핵심 | 최소 경로 | 업무 시나리오 |
라이브러리 한 칸이 바뀌어도 회귀가 필요합니다. 이 구성·버전을 적으면 “무엇이 바뀌었는지”가 보이고, 그다음 스위트가 “그래서 동작이 같은지”를 칩니다. 커버리지가 낮은 유산 코드를 손보면, 회귀 없이 한 리팩토링은 원금을 이자로 바꿉니다. 살충제 역설은 같은 케이스만 반복하면 새 결함을 못 본다는 경고입니다. 회귀 세트도 가끔 보강하고, 죽은 케이스는 뺍니다.