몇 가지 답변의 측면을 함께 그려 내 2p를 추가하려면 ...
참고 : 내 의견은 특히 데이터베이스 테스트 와 관련이 있으며 UI 테스트는 아닙니다 (물론 비슷한 적용).
데이터베이스는 프런트 엔드 애플리케이션만큼 테스트가 필요하지만 '프론트 엔드와 작동합니까?'에 기초하여 테스트되는 경향이 있습니다. 또는 '보고서가 올바른 결과를 낳습니까?'라고 생각합니다. 이는 데이터베이스 개발 프로세스에서 매우 늦게 테스트되고 있지만 강력하지는 않습니다.
우리는 일반적인 UAT / 성능 / 기타 외에도 데이터웨어 하우스 데이터베이스에 대한 단위 / 통합 / 시스템 테스트를 사용하는 많은 클라이언트를 보유하고 있습니다. 테스트. 그들은 지속적인 통합과 자동 테스트를 통해 전통적인 UAT에 도달하기 전에 많은 문제를 해결함으로써 UAT 시간을 절약하고 UAT 성공 가능성을 높입니다.
데이터베이스 테스트에는 프런트 엔드 또는 보고서 테스트와 비슷한 엄격한 기준을 적용해야한다는 데 동의 할 것입니다.
테스트의 핵심은 복잡한 엔티티 조합으로 진행하기 전에 작은 간단한 엔티티를 테스트하여 정확성을 확인하고 더 넓은 시스템으로 확장하기 전에 정확성을 확인하는 것입니다.
그래서 내 대답에 컨텍스트를 제공합니다 ...
단위 테스트
- 테이블, 뷰, 함수, 저장 프로 시저와 같이 장치가 작동 함을 입증하기위한 테스트 중점
- 외부 의존성을 제거하기 위해 인터페이스를 '스텁'해야합니다
- 자체 데이터를 제공합니다. 데이터의 알려진 시작 상태가 필요하므로 기존의 사전 테스트 데이터가있을 가능성이있는 경우 채우기 전에 절단 / 삭제가 발생해야합니다.
- 자체 실행 컨텍스트에서 이상적으로 실행됩니다.
- 자체적으로 정리하고 사용한 데이터를 제거합니다. 스텁을 사용하지 않는 경우에만 중요합니다.
이 작업의 장점은 테스트에 대한 모든 외부 종속성을 제거하고 정확성을 입증하기 위해 최소량의 테스트를 수행한다는 것입니다. 분명히 이러한 테스트는 프로덕션 데이터베이스에서 실행할 수 없습니다. 다음을 포함하여 단위 유형에 따라 여러 가지 유형의 테스트가 수행 될 수 있습니다.
- 스키마 검사, 일부는 이것을 '데이터 계약'테스트라고 부를 수 있습니다
- 통과하는 열 값
- 함수, 프로 시저, 뷰, 계산 된 열에 대해 서로 다른 데이터 값을 갖는 논리 경로의 운동
- Edge Case Testing-NULL, 잘못된 데이터, 음수, 너무 큰 값
(단위) 통합 테스트
이 SE 게시물이 다양한 유형의 테스트에 대해 도움 이 된다는 것을 알았 습니다 .
- 유닛이 서로 통합됨을 입증하기위한 테스트 초점
- 여러 장치에서 함께 수행
- 외부 의존성을 제거하기 위해 인터페이스를 '스텁'해야합니다
- 외부 데이터 영향의 영향을 제거하기 위해 자체 데이터를 제공합니다.
- 자체 실행 컨텍스트에서 이상적으로 실행됩니다.
- 자체적으로 정리되고 생성 된 데이터를 제거합니다. 스텁을 사용하지 않는 경우에만 중요합니다.
단위 테스트에서 이러한 통합 테스트로 이동할 때 더 광범위한 테스트 사례를 테스트하기 위해 데이터가 약간 더 많습니다. 분명히 이러한 테스트는 프로덕션 데이터베이스에서 실행할 수 없습니다.
그런 다음 데이터 양이 증가하고 범위가 증가하는 시스템 테스팅 , 시스템 통합 테스팅 (일명 엔드 엔드 테스팅)으로 진행됩니다. 이러한 모든 테스트는 회귀 테스트 프레임 워크의 일부가되어야합니다. 이러한 테스트 중 일부 는 사용자가 UAT의 일부로 수행하도록 선택할 수 있지만 UAT는 IT에서 정의한 일반적인 문제가 아니라 사용자가 정의한 테스트입니다 !
이제 실제 질문에 대답하기 위해 몇 가지 맥락을 설명 했습니다.
- 단위 및 통합 테스트를위한 데이터를 미리 채우면 가짜 테스트 오류가 발생할 수 있으므로 피해야합니다.
- 일관된 테스트를 보장하는 유일한 방법은 소스 데이터에 대한 가정을하지 않고 엄격하게 제어하는 것입니다.
- 한 테스터가 다른 소스 제어 데이터베이스 코드 분기에서 동일한 테스트를 수행하는 다른 테스터와 충돌하지 않도록하려면 별도의 테스트 실행 컨텍스트가 중요합니다.