[Effective Software Testing] chapter_2

프로그램(기능)의 요구사항(기획서?)을 바탕으로 정의된 명세를 기반으로 테스트를 진행한다.
기능 구현 후, 요구사항에 맞게 잘 구현되었는지 확인하기 위해 먼저 시도해볼 수 있다.

1. 요구사항과 입출력에 대해 이해하기

프로그램(method)을 3단계로 분석한다.

• 메서드가 무엇을 수행하는가? (비즈니스 로직)
• 메서드가 무엇을 입력으로 받는가?
• 메서드가 무엇을 출력하는가?

2. 여러 입력값에 대해 프로그램이 수행하는 바를 탐색하기

이 메서드가 어떤 기능을 구현했는가를 탐색하는 단게이다. (비즈니스 로직 분석 단계)
내가 작성한 코드라면 skip 해도 되지만, 남이 작성한 코드를 테스트할 때 거치는 단계이다.

• 예상할 수 있는 입력값들을 통해 해당 메서드를 파악하면 된다.

처음 구매한 기기를 탐색해보는 과정으로 느껴진다

3. 테스트 가능한 입출력과 구획을 탐색하기

효율적인 입/출력 테스트를 위해 구획화 하는 단계이다.
간단한 예시로, 장바구니 기능을 구현하였다고 해보자. 최대 10개까지만 담을 수 있는 장바구니라면, 3개를 담아보는 입력과 4개를 담아보는 입력은 동등한 입력이므로 작성할 필요가 사라진다.

• 내가 전달하는 입력은 어떤 부류인가?
• 각 입력들의 조합에 대해 무엇이 가능한가?
• 어떠한 출력들이 가능한가?

4. 경계 분석하기

소프트웨어의 버그는 경계에서 흔하게 발생한다.
최대 10개 까지의 장바구니 였다면, 10이라는 값이 경계라고 볼 수 있다.

• 접점: on point 경계 위에 있는 점
• 거점: off point 다른 구획에 있으면서, 접점과 가장 가까운 점
  접점은 10 이다. 거점은 11 이라고 보는데 1 ~ 10은 정상동작, 11부터는 비정상동작으로 보이므로 다른 구획(?)에 존재하면서 10과 가장 가까운 점이다.
• 내점: in point 항상 참인 점
• 외점 out point 항상 거짓인 점

5. 테스트 케이스 고안하기

각 입력을 조합하는 단계이다
위는 간단한 구현이므로 조합이 많지 않지만, 해당 메서드가 복잡하다면 예를 들어 가격은 30_000₩ 까지만, 각 품목은 5개까지만, 카테고리는 음식만 등의 요구사항 또는 파라미터가 생기게 되면 조합은 더욱 많아진다. 따라서 필요없는 조합은 제거한다.

• 예외 케이스 구획화 (가격이 0원, 품목의 갯수가 0개, 존재하지 않는 카테고리 등)
• 각 요구사항 구획화 ( 가격 유효성, 품목 유효성 등)
  • 카테고리가 음식이 아닌 경우
  • 가격이 30_000₩이 넘는 경우
  • 품목의 갯수가 5개 넘는 경우
• 총 갯수가 10개 초과 일 때 여러 품목의 합이 10개 초과
• 총 갯수 10개 이하

6. 테스트 케이스 자동화하기

자동화 라고 해서 거창해보이지만, JUnit 과 같은 테스트 프레임워크로 테스트를 작성함을 말한다.
각 테스트 케이스에 맞는 입력을 만들어 테스트를 작성하면 된다.

7. 창의성과 경험을 발휘해서 테스트 스위트를 강화하기

우리가 작성했던 테스트 케이스에 빠진 부분이 있는지 검사하는 단계이다
위 장바구니 예제에서 빠진 부분을 찾으면 되는데, 아직 보이지는 않는다. 굳이 만들어보자면, 해외 상품을 장바구니에 담는 경우가 있을 것 같다.
해외($)라면, 매일 환율에 영향을 받으므로 오늘 환율에서는 통과가 되었지만 환율 변동으로 인해 30_000₩ 이라는 요구사항을 만족하지 못하는 테스트 케이스가 있을 것 같다.