테스트 설계 방법
소프트웨어 테스트케이스 개발 기법
명세기반기법 TC 90% 이상 도출 -> 도구를 도입하여 구조기반기법 사용 고려
도구담당자는 최소 3년 이상 도구를 꾸준히 사용하면서 사용 Skill을 늘리고 문서화 해야한다
경험기반기법은 회새 나 Testing 전문인력이 있을경우 명세기반 OR 구조기반과 병행 사용
명세기반 기법
구조기반 기법
경험기반 기법
일반적으로 공식적/비공식적 모델의 명세화를 위해 사용
테스트 케이스를 모델 및 사양서 기반으로부터 체계적으로 도출
일반적으로 문서(사양서 및 설계서)기반 테스트로 커버리지 측정이 제한적임
시스템에 영향을 주는 이벤트, 입력값, 조건을 기반으로 테스트 수행
동작, 출력값과 시스템이 보여주는 행위를 점검
명세, 사양 등 Specification에 기반한 테스트 설계 기법
Unit Test의 경우 단위 설계 명세서, Integration Test의 경우 아키텍처 설계서가 테스트 베이시스가 된다.
단점
명세/사양서 등의 Specification이 존재하지 않을 경우 테스트 케이스 설계 불가
명세/사양서와 소스코드 사이의 불일치가 발생할 경우 테스트 수행 결과가 부정확 할 수 있다
코드나 개발 설계 등 소프트웨어 구조를 보여주는 정보로부터 테스트 케이스 도출
소프트웨어 커버리지 정도가 기존 테스트 케이스로부터 측정되고 커버리지를 늘리기 위해 추가적 테스트 케이스가 체계적으로 도출
설계 및 구현 세부정보 (소스코드) 를 기반으로 테스트를 수행
제어흐름
데이터 흐름
약점
소프트웨어의 경로, 구조와 구현에 기반한 테스트 설계기법
일반적으로 프로그래밍 스킬이 필요하다
단점
실행 경로가 너무 많아 모든 경우의 수를 고려한 테스트를 진행이 어려움
명세/사양서 자체의 오류를 검증하기 어려움 (내부 구조 상 결함에 집중)
추가적인 테스트 코드 및 수행환경을 설정해야 함
커버리지
Function Coverage
Statement Coverage
(?). Path Coverage
테스터, 개발자, 사용자 등의 전문지식 활용
소프트웨어에서 발생 가능한 결함과 그 분포등에 대한 지식
이전에 테스터가 다루었던 유사 어플리케이션이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스 도출
탐색적 테스팅 접근법, 분류 트리 기법, 체크리스트, 특성 테스팅
문서화 필요
빠른 시간안에 많은 결함을 찾는데 유용 -> 인력의존도(숙련된 전문인력)가 높은부분이 단점이다.
탐색적 테스팅?
사전에 준비, 디자인 X => 수행과 동시에 계획, 디자인, 실행
명확 + 암묵적 요구사항 테스트
시스템의 동작 or 동작하지 않는 증거를 찾기위한 추론에 집중
=> 탐색적 테스팅은 테스트 설계, 테스트 수행, 테스트 계획, 테스트 기록 및 학습을 동시에 수행하는 휴리스틱한 테스팅 접근법이다.
TC 작성시간 최소화
Checklist 최소화
전문가의 휴리스틱한 지적능력 활용
1-2시간 동안 집중수행 및 기록 -> 요약보고 작성
탐색적테스팅 <-> TC기반 공식 테스팅 (서로 상반되는 개념)
기술적 한계
탐색적 테스트 엔지니어의 기술과 능력에 심히 의존한다.
자동적인 회귀 테스트에 대한 근거를 적게 제공한다.
수행된 테스트 범위에 제한된 증거를 이해당사자들에게 준다.
탐색적 테스트 장점
명세가 거의 없고 시간이 부족한 경우, 공식적인 기법을 보충할 경우에 유용하다
Ad-hoc, 게릴라, 직관적 테스트와 형태는 유사하나, 정해진 임무와 목표, 결과물이 존재한다
탐색적 테스트는 초보자가 아닌 전문가에 의해 수행된다
회사가 보유하고 있는 경험치 높은 인력의 활용과 데이터를 기반으로 객관성 확보 및 최적화가 가능하다
개념
테스트 중인 컴포넌트나 시스템에서 유입된 오류의 결과
어떤 결함이 발생할 것인지를 테스터의 경험을 통해 예측
해당 결함을 집중적으로 검출할 수 있는 테스트를 설계
특징
이 기법만 단독적으로 사용되는 것 X, 다른 기법들과 접목되어 사용될 때 효과적
테스터의 유사 어플리케이션 or 기술에서의 경험, 직관, 기술능력으로부터 TC를 추출
구조적으로 에러추정기법을 사용하려면 기대되는 결함과 오류를 모두 나열한 후
이들을 공격할 수 있는 테스트를 디자인 해야한다
여기서 기대되는 결함과 오류는 상식, 기존경험, 결함과 장애 데이터, 왜 소프트웨어가 실패하 는지에 대한 일반적인 지식을 통해 도출이 가능하다
테스트 관리
(4주차 내용 중복)
소프트웨어 관리