테스트 데이터가 필요합니까, 아니면 단위 테스트와 수동 테스트에 의존 할 수 있습니까?

우리는 현재 중형 / 대형 PHP / MySQL 프로젝트를 진행하고 있습니다. 우리는 PHPUnit & QUnit을 사용하여 단위 테스트를 수행하고 있으며 수동으로 응용 프로그램을 테스트하는 두 명의 풀 타임 테스터가 있습니다. 테스트 (모의) 데이터는 현재 SQL 스크립트로 생성됩니다.

테스트 데이터의 스크립트를 유지 관리하는 데 문제가 있습니다. 비즈니스 로직은 매우 복잡하며 테스트 데이터에서 "간단한"변경으로 인해 응용 프로그램에서 여러 버그가 발생하는 경우가 많습니다 (실제 버그가 아니라 잘못된 데이터의 결과). 우리는 끊임없이 테이블을 만들고 변경하기 때문에 팀 전체에 큰 부담이되었습니다.

UI를 사용하여 약 5 분 안에 응용 프로그램에 모든 것을 수동으로 추가 할 수 있기 때문에 스크립트에서 테스트 데이터를 유지 관리하는 요점을 실제로 알지 못합니다. PM은 동의하지 않으며 테스트 데이터로 배포 할 수없는 프로젝트를 갖는 것은 나쁜 습관이라고 말합니다.

테스트 데이터로 스크립트 유지 관리를 포기하고 테스터가 데이터없이 응용 프로그램을 테스트 할 수 있도록해야합니까? 가장 좋은 방법은 무엇입니까?

두 가지 개념을 혼합하고 있습니다. 하나는 유닛 테스트 및 피어 리뷰를 기반으로하는 검증 입니다. 테스트 데이터없이 개발자가 직접 수행 할 수 있으며 요구 사항이 충족되는지 확인하는 것이 목적입니다.

두 번째는 validation 이며 이는 QA (테스터)가 수행합니다. 이 단계에서는 테스터가 응용 프로그램의 프로그래밍에 대한 지식이 없어도 의도 된 사용 사례 만 있으므로 테스트 데이터가 필요합니다. 그 목적은 응용 프로그램이 프로덕션 환경에서 의도 한대로 작동하는지 확인하는 것입니다.

고객에게 양질의 제품을 제공하기 위해서는 두 가지 프로세스가 중요하고 필요합니다. 단위 테스트에만 의존 할 수는 없습니다. 파악해야 할 것은 테스트 데이터를 유효하게 처리하는 안정적인 방법입니다.

편집 : 좋아, 나는 당신이 요구하는 것을 얻습니다. 테스터의 일은 테스트 데이터를 생성하는 것이 아니라 응용 프로그램을 테스트하는 것이기 때문에 대답은 그렇습니다. 유지 관리가 쉽고 유효한 데이터가 삽입되도록 스크립트를 작성해야합니다. 테스트 데이터가 없으면 테스터는 테스트 할 것이 없습니다. 그러나 테스트 환경에 액세스 할 수 있다면 스크립트를 사용하는 대신 테스트 데이터를 수동으로 삽입 할 수없는 이유를 알 수 없습니다.

예, 단위 테스트 및 데이터 모형을 사용하는 것이 가장 좋습니다. 프로젝트 관리자가 맞습니다. 테스트 데이터에서 "간단한"변경을 수행하면 종종 버그가 발생하기 때문에 이것이 문제의 핵심입니다.

코드 개선이 필요합니다. 그렇게하지 않는 것 (테스트가 필요 없다고 말하는 것)은 해결책이 아니며 단순히 기술적 부채 를 추가하는 것입니다 . 파손없이 유닛을 식별 할 수없는 것이 문제이므로 코드를 더 작은 테스트 가능한 유닛으로 나누십시오.

리팩터링을 시작하십시오. 개선 사항을 작게 유지하여 관리 할 수 ​​있도록합니다. DRY, 단일 책임 등을 따르지 않는 신 수업 / 방법과 같은 반 패턴을 찾으십시오.

마지막으로 TDD 를 조사 하여 팀에 적합한 지 확인하십시오. TDD는 (먼저 테스트를 작성하기 때문에) 또한 당신이 머물 보장 테스트 수있는 모든 코드를 보장하기 위해 잘 작동 린 테스트를 통과하기 위해 충분한 코드를 작성하여 (엔지니어링을 통해 최소화).

일반적으로 일련의 복잡한 비즈니스 논리 프로세스가 일련의 데이터를 생성하는 경우이를 보고서로 간주합니다. 보고서를 캡슐화하십시오. 보고서를 실행하고 결과 개체를 다음 테스트에 대한 입력으로 사용하십시오.

이것은 매우 일반적인 문제이며 매우 어려운 문제이기도합니다. 데이터베이스 (예 : HSQLDB 와 같은 메모리 내 데이터베이스)에 대해 실행되는 자동화 된 테스트 는 일반적으로 느리고 비 결정적이며 테스트 실패는 코드 또는 데이터의 어딘가에 문제가 있음을 나타 내기 때문에 별로 유익하지 않습니다.

내 경험상 가장 좋은 전략은 비즈니스 로직의 단위 테스트에 집중하는 것입니다. 핵심 도메인 코드를 최대한 많이 다루십시오. 이 부분을 제대로 이해하면 그 자체로 어려운 과제를 겪게되며 자동화 된 테스트를위한 최상의 비용-이익 관계를 달성하게됩니다. 지속성 계층에 관해서는, 나는 보통 자동화 된 테스트에 훨씬 적은 노력을 기울이고 그것을 전용 수동 테스터에게 맡깁니다.

그러나 지속성 테스트를 자동화하기를 원하거나 필요로 하는 경우에는 Guides by Tests를 통해 Growing Object-Oriented Software 를 읽어 보는 것이 좋습니다 . 이 책에는 지속성 테스트 전용 장이 있습니다.