[소프트웨어 테스트] 02. 명세 기반 테스트
[소프트웨어 테스트] 02. 명세 기반 테스트
소프트웨어 테스트 시리즈의 글입니다.
요구사항 = 어떤 기능이 무엇을 해야하는가. 비즈니스 규칙.
명세기반 테스트 = 요구사항을 테스트의 입력으로 사용하는 테스트.
2.1 요구사항이 모든 걸 말한다
요구사항 : 두 태그 사이에 존재하는 모든 부분 문자열을 반환한다.
→ 이것을 기반으로 구현. substringsBetween()
우리는 이제 가능한 입출력 조합을 테스트해야한다.
어떻게 하면 실용적으로 테스트를 짤 수 있을까
2.1.1 요구사항과 입출력에 대해 이해하기
요구사항의 구성요소
- 프로그램 또는 메서드는 무엇을 수행하는가
- 비즈니스 규칙
- 출력에 대한 추론
substringsBetween() 의 경우
- 목표 : 문자열에서 open / close 태그로 구분된 모든 부분 문자열을 모은다.
- 프로그램은 세 종류의 매개변수를 받는다
- str
- open
- close
- 찾아낸 모든 부분 문자열을 반환한다
2.1.2 여러 입력값에 대해 프로그램이 수행하는 바를 탐색하기
메서드가 수행하는 작업을 탐색하면 메서드를 잘 이해할 수 있다. ex. abcd / a / d 입력 ⇒ bc 출력
2.1.3 테스트 가능한 입출력 구획을 탐색
중요한 입출력에 대해 우선순위를 매기고 그 일부를 선택해서 테스트해야함.
- 어떤 부류의 입력인지 탐색
- 각 입력과 다른 입력의 조합에 대해 탐색
- 어떤 부류의 출력인지 탐ㅅ핵
2.1.4 경계 분석하기
버그 = 도메인의 경계에서 발생.
- on point (접점) : 구획을 나누는 경계 위에 있는 점
- off point (거점) : 접점이 속해있지 않은 구획에 있으면서 경계에 가장 가까운 점 접점과 거점 외에 추가적인 조건
- in point (내점) : 조건이 참인 점
- out point (외점) : 조건이 거짓인 점
모든 구획을 살펴보고 구획 사이의 입력을 생각해보고 테스트할만한 대상을 찾을때마다 테스트.
2.1.5 테스트 케이스 고안
구획 조합을 어떻게할지 실용적으로 결정. ex. 예외적인 경우는 한번만 수행하고 조합하지않음. (빈문자열, 널문자열)
2.1.6 테스트 케이스 자동화
단언문을 묶기 ParameterizedTest 사용하기 등등..
2.1.7 창의성, 경험을 발휘해서 테스트 스위트 강화
우리의 경험과 창의성을 발휘해서 구획을 살펴보고 변형을 찾아내어 좋은 테스트케이스를 추가하자.
2.2 간략히 살펴보는 명세 기반 테스트
명세기반 테스트 7단계
- 요구사항과 입출력에 대한 이해
- 프로그램 탐색
- 구획 식별
- 경계 분석
- 테스트 케이스 고안
- 테스트 자동화
- 강화
( 2.1 에서 한말 요약이긴함)
또한 순차 프로세스라기보다 단계별 반복될수잇음을 유의
2.3 명세 테스트로 버그 찾기
잘 작성했다면, 버그를 파악할 수 있다
2.4 현업에서의 명세 테스트
- 프로세스는 연속적이 아니라 반복적
- 명세테스트는 비용을 보고, 중요하다면 빡세게. 아니라면 덜 꼼꼼해도 ok.
- 구획, 경계를 찾음에서 중요한건 버그가 스며들지 않게하는것
- 접점, 거점 테스트로 충분하지만 내점, 외점 테스트도 추가하면 good
- 이해를 높이기 위해 입력을 변경해서 사용
- 조합의 수가 너무 많다면 실용적으로.
- 입력은 간단한게 기본적으로 좋음
- 관심없는 입력은 합리적으로 선택.
- 예외케이스는 의미가 있을때만 사용
- 테스트가 동일한 skeleton을 가지면 ParameterizedTest 활용하기
- 요구사항은 잘게 쪼개는게 굿.
- 클래스상태에서도 동일하게 적용 가능.
- 경험, 창의성은 합리적인 테스트를 작성할때 필요.