LLM이 생성한 테스트를 회귀 테스트에 사용할 위험성

소프트웨어는 끊임없이 진화합니다. 개발자들은 지속적으로 기능을 추가하고, 버그를 수정하며, 코드를 리팩토링하며, 이러한 변경 사항 중 어느 것이든 기존 기능의 오작동을 일으킬 수 있습니다. 회귀 테스트(Regression testing)는 테스트 케이스에 예상되는 동작을 포착함으로써 그러한 영향을 방지합니다. LLM 기반 테스트 생성은 테스트 대상 코드로부터 직접 회귀 테스트를 생성하여 이 과정을 자동화하는 것을 목표로 합니다. 이는 구현이 올바를 때는 유익하지만, 코드가 결함을 포함할 때는 문제가 될 수 있습니다. 이때 생성된 테스트는 잘못된 동작을 인코딩하고 보존할 수 있기 때문입니다. 이러한 위험성을 조사하기 위해, 우리는 소프트웨어 프로젝트의 메인 브랜치에 병합된 풀 리퀘스트(pull requests)에 LLM 기반 회귀 테스트 생성을 적용하고, 생성된 테스트가 후속 프로젝트 진화에 미치는 영향을 연구했습니다. 우리는 올바르게 구현된 동작을 단언하는 결함 노출 테스트(fault-revealing tests)와 잘못된 동작을 단언하는 결함 강제 테스트(fault-enforcing tests)를 구별합니다. SciPy, Qiskit, pandas의 145개 풀 리퀘스트에 걸쳐, 생성된 테스트 중 8%~17%가 결함 강제 테스트였으며, 결함을 노출시키는 경우는 단지 2.4%~4.8%였습니다. 결함 강제 테스트는 시간이 지나도 지속됩니다: 몇 번의 후속 커밋(commits) 이후에도 83%~91%가 여전히 관련성이 있고 통과합니다. 또한 이들은 축적되기도 합니다: 모든 풀 리퀘스트의 결함을 하나의 코드베이스에 결합했을 때, 83%~92%가 커밋 히스토리 끝까지 강제적으로 유지되며, 개발자가 작성한 테스트 스위트로는 그중 단지 14%~30%만이 감지됩니다. 우리의 결과는 LLM 생성 회귀 테스트의 근본적인 위험성을 보여줍니다: 수동 검증 없이는 잘못된 동작을 예상되는 동작으로 인코딩할 수 있으며, 이로 인해 버그가 소프트웨어 개정판 전반에 걸쳐 지속되고 개발자가 유지 관리하는 테스트 스위트를 크게 우회하게 만들 수 있습니다. 따라서 LLM 기반 회귀 테스트는 새로운 형태의 기술 부채(technical debt)를 야기할 수 있습니다.