답변.

테스트 데이터 관리는 자동화에서 가장 오래된 문제 중 하나입니다. 자동화 초기(Excel에서의 테스트 스크립트, 매크로, 오래된 QTP)에는 데이터가 종종 테스트 작성자의 머릿속에 저장되거나 코드 내에 직접 저장되었습니다. CI/CD와 병렬 실행의 발전으로 새로운 전략이 필요하게 되었습니다: 여러 테스트가 동시에 동일한 데이터를 사용할 때 경쟁을 피하고 결과의 반복 가능성을 보장하는 방법은 무엇인가요?

문제: 공통(shared) 테스트 데이터는 신속하게 충돌과 예측할 수 없는 결과를 초래합니다. 테스트는 비정상화되며, 디버깅이 어렵고 데이터 조각이 데이터베이스를 "혼잡하게" 만들며, 다중 스레드에서 실행이 오류(data race)를 초래합니다.

해결책 — "테스트당 데이터"(Test Data Per Test) 전략의 도입:

각 테스트에 대해 고유하거나 매개변수화된 테스트 데이터 사용
테스트 전과 후에 데이터 생성/정리(setup/teardown, fixture)
네임스페이스, 테넌트, 사용자 등을 사용하여 테스트 환경을 분리
테스트당 재이니셜라이제이션을 가진 인메모리 데이터베이스 사용

주요 특징:

고유 데이터 생성(UUID, timestamp), 테스트 후 자동 삭제
테스트 데이터 팩토리(Test Data Factories)와 템플릿 사용
격리된 샌드박스 환경 작업

함정 질문.

프로덕션 데이터를 테스트 데이터로 사용하는 것은 괜찮습니까?

아닙니다! 보안과 기밀성에 위험이 있으며, 데이터의 변동성으로 인해 테스트 예측 불가능성을 초래할 수 있습니다.

데이터 정리를 위해 setUp과 tearDown만 사용하는 것으로 충분합니까?

항상 그렇지는 않습니다. 그것은 위험을 최소화하는 데 도움이 되지만, 병렬 실행에서 데이터가 전역적이거나 고유하지 않으면 테스트가 충돌할 수 있습니다.

같은 테스트 데이터를 스모크 테스트와 회귀 시나리오에서 사용할 수 있습니까?

최선의 방법은 — 아닙니다. 스모크 테스트는 최대한 독립적이어야 하며, 회귀 테스트는 데이터 준비가 복잡해야 하므로 잘못된 긍정 결과가 발생할 수 있습니다.

일반적인 오류와 안티패턴

여러 테스트에 우연히 적합한 공통 "마법의" 데이터 사용
테스트 후 정리되지 않은 데이터 유물
모든 테스트에서 동일한 기록을 이중 사용

실제 사례

부정적 사례

한 회사에는 하나의 공통 로그인과 여러 "공유" 사용자 및 주문이 있어 모든 자동화 테스트에 사용되었습니다. 병렬 실행으로 인해 테스트가 서로의 주문을 지우거나 여러 스레드에서 하나의 주문의 상태를 변경하는 상황이 발생했습니다.

장점:

적은 수의 테스트에 대해 빠르고 쉽게 구현 가능
추가 인프라 필요 없음

단점:

애매한 실패, 디버깅의 어려움
테스트를 안전하게 병렬 실행하거나 다양한 환경에서 실행할 수 없음

긍정적 사례

테스트 데이터 팩토리가 도입되었습니다: 테스트를 실행하기 전에 각 시나리오에 대해 고유한 주문과 사용자가 생성되며, 이는 테스트가 완료된 후 삭제되고 샌드박스 환경은 재이니셜라이제이션 되었습니다.