회귀 테스트, 테스트 유지 관리 및 취약한 테스트 방지 — 소프트웨어 테스팅 및 QA의 인공 지능

이득:

회귀 테스팅의 목적을 이해하고, 인공지능을 활용하여 변화에 따른 테스트 선택 및 회귀 케이스 생성 가능
취약한 테스트(타이밍, 순서 종속성, 공유 상태, 외부 종속성)의 근본 원인을 진단하고 증상을 억제하지 않고 영구적인 솔루션을 적용하는 능력
중복 테스트를 제거하여 회귀 제품군을 빠르고 독립적이며 안정적으로 유지하면서 전체 패키지 시험판을 실행하는 규율을 유지하는 기능

소프트웨어는 지속적으로 변경됩니다. 모든 새로운 기능, 모든 수정으로 인해 이전에 작동했던 기능이 중단될 수 있습니다. 이전에 작동하던 기능이 이후에 중단되는 것을 회귀라고 합니다. 회귀 테스트는 이러한 성능 저하를 파악하기 위해 각 변경 사항으로 기존 기능을 다시 테스트합니다. 시간이 지남에 따라 이러한 테스트 스위트는 수천 개의 테스트로 더 커지고 두 가지 큰 문제가 발생합니다. 스위트의 속도가 느려지고 불안정한 테스트(동일한 코드에서 때로는 통과하고 때로는 실패하는 신뢰할 수 없는 테스트)가 테스트 결과에 대한 팀의 신뢰를 파괴합니다. 인공 지능(AI)은 회귀 스위트를 잘 유지 관리되고 빠르고 안정적으로 유지하는 데 강력한 도움이 됩니다. 그러나 핵심 주의 사항은 여전히 남아 있습니다. AI는 취약한 테스트를 "통과"할 수 있지만 실제 버그를 덮는 패치를 생성할 수도 있습니다. 당신의 임무는 증상을 억제하는 것이 아니라 불안정의 근본 원인을 찾는 것입니다.

취약한 테스트의 근본 원인

깨지기 쉬운 테스트는 가장 교활한 테스트 문제입니다. 성공할지 실패할지 신뢰할 수 없기 때문에 팀은 "또 막혔나 봐, 다시 실행해야 해"라는 습관을 갖게 됩니다. 이러한 습관은 언젠가 실제 버그를 "불안정함"으로 무시하게 될 것입니다. 주요 근본 원인:

타이밍/경합 조건: 테스트는 작업이 완료될 때까지 기다리지 않고 결과를 확인합니다. 가장 일반적인 이유.
순서 종속성: 테스트는 서로 남겨진 데이터에 따라 달라집니다. 순서가 바뀌면 깨집니다.
공유 사례: 여러 테스트가 동일한 테스트 데이터/사용자를 사용하여 충돌합니다.
외부 종속성: 실제 네트워크, 타사 서비스, 시스템 시간, 임의 값.
환경 차이: 로컬로 전환하고 CI(지속적 통합 환경)에 유지됩니다.

주의: "몇 번 다시 시도"하여 취약한 테스트를 통과하면 실제 동시성 오류가 가려지는 경우가 많습니다. 재시도는 치료가 아닌 진단 도구입니다. 먼저 근본 원인을 찾으십시오. 문서화된 실제 외부 불안정에 대한 최후의 수단으로만 재시도를 사용하십시오.

테스트 유지 관리: 패키지를 건강하게 유지

회귀 스위트는 정원과 같습니다. 관리하지 않으면 잡초가 차지하게 됩니다. AI는 세 가지 유지 관리 작업을 지원합니다.

1. 중복/불필요한 테스트 청소. 시간이 지남에 따라 동일한 것을 테스트하는 사례가 많이 누적됩니다. AI는 유사한 테스트를 그룹화하고 병합할 것을 제안합니다.

2. 취약한 테스트 진단. AI에 테스트 코드와 불안정 패턴을 제공합니다. 가능한 근본 원인과 영구적인 해결책을 제안합니다.

3. 테스트 선택/우선순위 지정. 변경할 때마다 전체 패키지를 실행하는 데 비용이 많이 듭니다. 테스트 영향 분석(변경된 코드를 기반으로 관련 테스트만 선택)을 통해 AI는 어떤 테스트를 먼저 실행해야 할지 추천합니다. 그러나 전체 시험판 패키지가 필수입니다.

Quarantine: 취약한 테스트 권한 관리

테스트가 취약하다는 사실을 발견했지만 근본 원인을 즉시 수정할 시간이 없습니다. 무엇을 해야 할까요? 두 가지 잘못된 방법이 있습니다. 테스트를 완전히 삭제하는 것(해당 동작은 더 이상 전혀 유지되지 않음) 또는 재시도를 통해 테스트를 침묵시키는 것(실제 버그를 은폐하는 것)입니다. 올바른 방법은 격리하는 것입니다(취약한 테스트를 주요 패키지에서 일시적으로 분리하고 별도의 목록에서 추적). 격리된 테스트는 버전 병합을 방지하지 않지만 눈에 띄는 부채로 남아 있으며 정기적으로 해결됩니다. 중요한 점은 격리는 쓰레기통이 아니라 대기실이라는 것입니다. 격리 목록이 늘어나고 있다면 팀의 테스트 상태가 악화되고 있다는 경보입니다. AI는 정기적으로 격리 목록을 검토하고 근본 원인 패턴별로 그룹화할 수 있습니다. "6개 테스트가 모두 동일한 공유 테스트 사용자에게 연결되어 있다"는 등 공통 원인을 밝혀 집단적 해결을 가능하게 한다.

팁: 각 격리 기록에 "소유자"와 "마지막 검토 날짜"를 추가하세요. 버려진 격리소는 영구 쓰레기장이 됩니다. 취약한 테스트는 아무도 신경 쓰지 않기 때문에 영원히 존재합니다.

회귀 전략 테이블

상태

전략

AI의 역할

사소한 수정

영향을 받는 부위 + 연기 테스트

약한 프롬프트 / 강한 프롬프트

약함: "이 테스트는 가끔 실패합니다. 수정하세요."

Strong: "이 테스트는 10번 중 3번 실행에 실패하고 코드는 변경되지 않습니다. 불안정성의 근본 원인을 진단하십시오: 타이밍/경합, 순서 종속성, 공유 상태, 외부 종속성 또는 환경 차이일 수 있습니다. 테스트에서 가능한 각 원인을 가리키는 줄을 표시하십시오. 영구적인 해결책을 제안하십시오. '재시도 추가'와 같은 증상 억제 해결책을 제안하지 마십시오. 불가피한 경우 이유를 명확하게 작성하십시오. 테스트: [코드]. 오류 추적: [로그]."

강력한 프롬프트; 근본 원인을 진단하고 증상 억제를 명시적으로 금지합니다.

복사 가능한 템플릿 4개

1) 깨지기 쉬운 테스트 진단:

이 테스트 코드는 변경 없이 통과할 때도 있고 실패할 때도 있습니다. 근본 원인 후보(인종, 순서 종속성, 공유 상태, 외부 종속성, 시계/무작위, 환경 차이)를 나열하고 각각에 대한 테스트의 증거 라인을 표시합니다. 영구적인 솔루션을 제안합니다. 최후의 수단으로 재시도와 같은 억제 솔루션을 정당화하고 표시합니다. 테스트: [코드] / 불안정성 패턴: [몇 번 실행했는지]

2) 회귀 사례 제안:

다음 변경 사항이 적용되었습니다: [변경/PR 요약]. 이 변경 사항으로 인해 중단될 현재 동작을 나열하고 각각에 대한 회귀 테스트 사례를 제안합니다. 특히 부작용 및 공유 종속성 영역을 강조합니다.

3) 중복 테스트 정리:

아래 테스트 스위트를 확인해 보세요. 동일한 동작을 테스트하는 중복되거나 중복되는 사례를 그룹화합니다. 그룹별로 어떤 것을 유지하고 어떤 것을 결합해야 하는지 제안해 보세요. 보장 상실의 위험이 있는 경우 경고하십시오. 테스트: [목록/코드]

4) 테스트 효과 선택:

다음 파일/함수가 변경되었습니다: [list]. 기존 테스트 모음에서 먼저 실행해야 하는 테스트(변경된 코드에 직간접적으로 연결된 테스트)를 선택하고 정당화합니다. 참고: 아직 전체 시험판 제품군을 실행할 것임을 상기시켜 주세요.

세 개의 미니 케이스

사례 1 - 재시도를 통해 실제 실수가 가려졌습니다. 한 팀은 가끔 남은 지급 테스트에 3번의 재시도를 추가했습니다. 이제 테스트는 항상 "통과"되었습니다. "취약한 테스트 진단"을 적용하면 불안정성이 실제 경쟁 조건에서 비롯된 것으로 나타났습니다. 높은 부하에서 결제 확인이 때때로 이중 처리되는 경우가 있었습니다. 몇 달 동안 Retry는 실시간으로 실제 돈 손실을 초래할 수 있는 버그를 은폐했습니다. 근본 원인이 해결되었습니다. 다시 제거해 보세요.

사례 2 - 패키지가 줄어들고 속도가 빨라졌습니다. 1,400개 테스트의 회귀 분석에는 55분이 걸렸습니다. "중복 테스트 정리"를 통해 380개의 테스트가 중복되거나 포함된 것으로 나타났습니다. 병합. 패키지는 900번의 테스트로 줄어들었고, 시간은 34분으로 단축되었으며, 적용 범위는 눈에 띄게 줄어들지 않았습니다. 더 빠른 피드백으로 인해 팀은 더 자주 테스트할 수 있었습니다.

사례 3 - 주문 종속성. 테스트는 항상 로컬에서는 통과하지만 CI에서는 무작위로 실패합니다. AI 진단에서는 테스트가 다른 테스트에서 생성된 사용자에 따라 달라지는 것으로 나타났으며, CI에서는 테스트가 병렬/다른 순서로 실행되었기 때문에 중단되었습니다. 각 테스트는 자체 데이터를 확립하기 위해 수행되었습니다. 우유부단함은 끝났습니다.

일반적인 실수

재시도로 취약한 테스트를 침묵시킵니다. 근본 원인을 찾지 않고 다시 시도합니다. 진짜 실수를 덮는다.
"다시 갇힌" 문화. 빨간색 결과를 일상적으로 무시합니다. 어느 날, 진짜 실수를 건너뛰었습니다.
패키지를 전혀 가지치기하지 않습니다. 중복 테스트가 쌓여 패키지 속도가 느려집니다.
테스트 간의 종속성. 테스트는 일반적인 조건/순서를 기반으로 합니다. 불확실성의 근원.
변경된 부분만 테스트하고 전체 패키지는 건너뜁니다. 시험판 단축키; 숨겨진 부작용 탈출.
외부 의존성에 의존합니다. 실제 네트워크/클럭/임의 값을 기반으로 테스트합니다. 자연적으로 불안정합니다.

요약하면

회귀 테스트는 이전에 작동했던 기능을 손상시키는 변경 사항을 포착합니다. 그러나 패키지가 커짐에 따라 속도가 느리고 취약한 테스트로 인해 신뢰가 약화됩니다. 취약한 테스트의 근본 원인은 일반적으로 타이밍, 순서 종속성, 공유 상태 및 외부 종속성입니다. AI는 진단, 청소 및 테스트 선택에 강력한 도움을 줍니다. 그러나 재시도를 통해 우유부단함을 억제하면 실제 실수가 가려집니다. 근본 원인을 찾고, 테스트를 독립적이고 결정적으로 만들고, 패키지를 정기적으로 정리하고, 릴리스 전에 전체 패키지를 실행하십시오.

응용과제

취약한(또는 불안정해 보이는) 자신의 프로젝트에서 테스트를 선택하십시오. "취약한 테스트 진단" 템플릿을 사용하여 근본 원인 후보를 추출하고 테스트에서 증거 라인을 확인합니다. 근본 원인을 식별하고 재시도 없이 영구적인 솔루션을 구현합니다. 그런 다음 패키지에서 10개의 테스트를 선택하고 "중복 테스트 정리"와 결합할 수 있는 테스트를 찾으세요. 근본 원인을 해결한 테스트 불안정 수와 제품군에서 제거한 불필요한 사례 수를 보고합니다.

체크리스트

[ ] 취약한 테스트의 근본 원인을 진단했습니다. 나는 증상을 억제하지 않았습니다.
[ ] 나는 재시도를 치료법이 아닌 정당한 최후의 수단으로 생각했습니다.
[ ] 테스트를 독립적이고 결정적(외부 종속성과 격리됨)으로 만들었습니다.
[ ] 회귀 분석 모음에서 중복되거나 불필요한 테스트를 제거했습니다.
[ ] 변경 사항을 기반으로 테스트하기로 선택했지만 전체 패키지 사전 릴리스를 실행했습니다.
[ ] 나는 "다시 붙어도 통과"하는 문화에 반대하여 모든 빨간색을 진지하게 받아들였습니다.