소프트웨어 테스트의 목적
• 잠재적 오류와 결함의 발견
• 요구사항의 준수 여부(기능/비기능) 확인
• 소프트웨어 신뢰성 등 품질 확인
오류를 발견하기 위한 활동으로, 테스팅이 오류가 없음을 확인시켜 주지는 않음
테스팅의 원칙
- 개발자가 자신의 프로그램을 직접 테스팅하지 않음
- 테스팅의 목적은 결함이 존재함을 밝히는 것
- 완벽한 테스팅은 불가능
- 개발 초기에 테스팅 시작
살충제 패러독스
동일한 테스트를 반복하면 새로운 결함을 찾기 어려워, 테스트 케이스를 주기적으로 개선해야 한다.
테스트에 대한 시각
검증: 개발 단계의 산출물이 설정된 조건을 만족하는 지 평가 (소프트웨어 프로세스가 잘 진행되는 지 평가)
확인: 요구사항들을 만족하는 지 평가
테스트의 목적
회복 테스트: 고의적 실패 유도
보안 테스트: 불법적인 침해
스트레스 테스트: 과부하 테스트
성능 테스트: 응답시간, 처리량, 속도
회귀 테스트: 변경이 새로운 오류를 발생시키지 않음을 확인
V-모델: 개발 단계와 테스트 단계를 대응시켜 검증과 추적성을 강조하는 모델
단위 테스팅: 개발자가 각 모듈 완성 후 독립된 환경에서 모듈 단위로 기능을 검증하는 테스트
- 화이트박스 / 블랙박스 테스팅 모두 가능
- 스텁: 테스팅 대상 모듈이 호출하는 모듈
- 드라이버: 테스팅 대상 모듈을 호출하는 환경
통합 테스팅: 모듈을 통합하는 과정에서 모듈 간 상호작용을 검사하는 테스팅
빅뱅 기법: 모듈을 한꺼번에 통합해 테스트하나, 오류 위치 파악이 어렵다.
하향식 기법: 상위 모듈부터 순차적 통합, 하위 모듈은 스텁 사용한다.
상향식 기법: 하위 모듈부터 순차적 통합, 상위 모듈은 테스트 드라이버가 필요하다.
시스템 테스팅: 통합 완료된 시스템이 사용자 기능 및 비기능 요구사항을 충족하는지 검증하는 개발 조직 주체의 최종 테스트
인수 테스팅: 시스템이 사용자에게 인도되기 전, 사용자에 의해 실시되는 테스팅
알파 테스팅: 개발자 환경에서 사용자가 실시 (완료 시, 알파 버전)
베타 테스팅: 실제 사용자 환경에서 사용자가 실시 (완료 시, 베타 버전)
인수 테스팅을 통과해야지만, 시스템이 사용자에게 인도되고 프로젝트는 종료됨
Selenium
다양한 브라우저와 언어를 지원한다
사용자처럼 동작을 재현해 정확한 테스트가 가능
코드 수정 시 자동으로 테스트하고 배포까지 연결되어 효율적 사용이 가능하다
블랙박스 테스팅 (Black-Box Testing)
소스 코드 자체의 로직에는 관심이 없고 입출력 값에만 관심이 있음
- 사용자 관점의 테스트 가능
- 코드 지식이 불필요하기 때문에 비기술적 테스트도 참여 가능
- 입출력 관계를 중심으로 테스트하기 때문에,인터페이스 검증에 적합하다
구문 테스팅 (Syntax Testing)
입력 값을 적합(Valid)과 부적합(Invalid)으로 분류한 뒤 예상되는 결과를 검증하는 방법
동등 분할 (Equivalence Partitioning)
입력값 각 범위의 대표값을 이용하여 테스팅
경계 값 분석 (Boundary Value Analysis)
입력 값의 주요 오류 대상인 경계 값을 입력 값으로 하는 테스트 케이스로 테스팅
(같은 구간 포함 시 중복을 제거한다)
(가령, 1~50, 50~100이 범위 일때, 50은 중복이므로 한 번만 사용한다는 것)
의사결정 테이블 (Decision Table)
입/출력 값이 True, False로 결정될 수 있는 경우, 테이블로 모든 경우의 수를 확인해보는 방법
- 입력. 출력 값이 Yes, No로 결정될 수 있는 경우
- 적은 수의 조건을 가진 입력 값에 유용
화이트박스 테스팅 (White-Box Testing)
소스 코드를 직접 참조하면서 수행하는 테스팅
(커버리지: 테스트 케이스가 얼마나 많은 상황들을 커버할 수 있는 지 나타내는 척도)
(소프트웨어 목적성에 맞는 구조를 잘 정리한 후 테스트)
- 철저한 검증이 가능하다
- 로직의 논리적 결함을 찾기에 유리하다
- 테스트를 진행하면서 비효율 부분을 개선할 가능성이 있다
문장 커버리지 (Statement Coverage)
프로그램을 구성하는 문장들이 최소 한번은 실행될 수 있는 입력 값을 테스트 케이스로 선정
분기 커버리지 (Branch Coverage)
프로그램에 있는 분기를 최소한 한번은 실행하게 하는 테스팅 방법
(yes / no를 한 번씩은 거쳐야 한다)
조건 커버리지 (Condition Coverage)
&&, || 등의 조건을 가진 분기문이
전체 조건식의 결과와 관계없이,
&& 나 || 전후의 각 개별 조건식이 참 한 번, 거짓 한 번을 갖도록 테스트 케이스를 만드는 방법
(개별 조건 컴럼 당 참, 거짓 하나씩만 있으면 됨, 가령 TF. FT만 해도 각 개별 조건이 한 번씩은 가지게 된 것)
다중 조건 커버리지 (Multiple Condition Coverage)
다중 조건 커버리지는 전체 조건식의 모든 경우의 조건을 검사하는 테스트 케이스를 만드는 방법
(모든 개별 조건의 조합을 다 테스트 해야한다)
기본 경로 테스팅 (Basic Path Testing)
1. 테스팅 대상의 플로우 그래프를 그린다
2. 순환복잡도(Cyclomatic Complexity)를 계산한다.
▪ 프로그램 내부구조를 시험 할 수 있는 독립적인 경로의 수를 계산
▪ 프로그램의 논리적인 복잡도를 나타냄
• CC = R의 수
• CC = E - N + 2
• CC = P + 1
✓ CC(Cyclomatic Complexity): 순환복잡도
✓ R(Region): 노드로 둘러싸인 영역과 그래프 밖 영역의 수
✓ E(Edge): 화살표의 수
✓ N(Node): 노드의 수
✓ P(Predicate): 분기 노드의 수
3. 독립적인 경로들을 정의한다.
▪ 순환복잡도를 통해 계산된 횟수를 기반으로 독립적인 경로들을 정의
▪ 단계 1: 조건 노드를 최대한 많이 거쳐 가도록 하는 기본 경로를 하나 선택
▪ 단계 2: 기본 경로의 첫번째 분기를 바꾸어 새로운 기본 경로를 생성
▪ 단계 3: 단계 2에서 생성된 기본 경로의 노드 중 다음 결정 구조의 분기를 기본 경로와 다르게하여 생성
▪ 단계 4: 기본경로로부터 첫번째 결정구조에 관하여 더 이상 새로운 경로가 없으면
두번째 결정구조에 관하여 같은 방법으로 기본 경로를 구함
▪ 단계 5: 더 이상 기본 경로 중 결정구조가 없으면 기본 경로 생성을 중지
4. 정의된 각 경로의 테스트 케이스를 작성한다
예) 국어, 영어, 수학 점수를 입력받아 평균 점수가 70점 이상이면 PASS를 미만이면 FAIL을 출력한다
✓경로 1: 1 - 2 - 3 - 2 - 4 - 5 - 6 - 8
✓경로 2: 1 - 2 - 3 - 2 - 4 - 5 - 7 - 8
✓경로 3: 1 - 2 - 4 - 5 - 6 - 8
예)
• 휴대폰 배터리 표시 기능 예
• 2.5 V 이상 2.8 V 미만: 배터리 0칸
• 2.8 V 이상 3.3 V 미만: 배터리 1칸
• 3.3 V 이상 3.8 V 미만: 배터리 2칸
동등 분할, 경계 값 분석로 테스트 케이스를 작성하시오
• 모바일 은행 어플리케이션
• 사용자는 은행으로부터 발급받은 공인인증서 칩을 넣은 상태에서 해당은행에서 제공한 소프트웨
어를 이용하여 은행업무를 볼 수 있다.
• 폰에 칩이 없을 경우 칩이 필요하다는 경고를 보여준다.
• 칩이 있을 경우, 칩이 유효한지 검사한다. 칩이 유효하지 않다면 유효하지 않다는 경고를 보여준다.
• 칩이 유효한 경우, 해당 칩을 발행한 은행에서 제공한 소프트웨어가 폰에 다운로드 되었는지 검사
하는데, 소프트웨어가 없다면 다운로드를 시도한다. 이 때 폰에 다른 은행의 소프트웨어가 이미 저
장되어 있다면 둘 중 하나를 지울 것을 사용자에게 요청한다.
• 해당 은행 소프트웨어 다운로드가 확인되면 은행 업무 메뉴를 보여준다.
의사 결정 테이블 테스트 케이스를 작성하시오
