[2권] 7장. 애플리케이션 테스트 관리

[애플리케이션 테스트]

app에 잠재되어 있는 결함을 찾아내는 행위 또는 절차
개발된 sw가 고객의 요구사항을 만족시키는지 확인(validation)
sw가 기능을 정확히 수행하는지 검증(verification)
개발한 sw의 유형을 분류하고 특성을 정리해 중점적으로 test사항 정리

[app test 필요성]

프로그램 실행 전에 오류를 발견해 예방
제품의 신뢰도 향상, 새로운 오류 유입 예방

[테스트의 기본 원리]

완벽한 테스트 불가능
결함 집중 - 결함은 특정 모듈에 집중 (app의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다고 하여 파레토법칙을 적용하기도 한다)
살충제 패러독스 - 동일한 테스트케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 '살충제패러독스' 현상이 발생, 방지하기 위해 테스트케이스를 지속적으로 보완 및 개선해야 함
테스팅은 정황의존 - 정황에 따라 테스트를 다르게 수행해야 한다.
오류-부재의 궤변 - 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 sw는 품질이 높다고 말할 수 없다.
테스트와 위험은 반비례
테스트의 점진적 확대 - 작은 부분에서 시작해서 점점확대
테스트의 별도 팀 수행 - 개발자와 관계없는 팀에서 수행

[테스트의 분류]

프로그램 실행 여부 ?
1. 정적 테스트
프로그램 실행 X, 명세서나 소스코드를 대상으로 분석
sw개발 초기에 결함발견 가능 -> sw개발비용 낮춤
ex) 워크스루, 인스펙션, 코드검사
2. 동적 테스트
프로그램 실행 O, 오류를 찾는 test, sw개발의 모든단계에서 실행 가능
ex) 블랙박스 테스트, 화이트박스 테스트

무엇을 기반으로 수행 ?
1. 명세 기반 테스트
사용자의 요구사항에 대한 명세를 빠짐 없이 테스트케이스로 만들어 구현하고 있는지 확인
ex) 동등분할, 경계 값 분석
2. 구조 기반 테스트
sw내부의 논리흐름에 따라 테스트케이스를 작성하고 확인
ex) 구문기반, 결정기반, 조건기반
3.경험 기반 테스트
유사한 sw나 기술에 대한 테스터의 경험을 기반으로 수행하는 test
사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행시 효과적
ex) 에러추정, 체크리스트, 탐색적 테스팅

테스트 시 누구를 기준으로 ?
1. 검증(verification)테스트
개발자의 시각에서 제품의 생산 과정을 test
제품이 명세서대로 완성되었는지 테스트
2. 확인(validation)테스트
사용자의 시각에서 생산된 제품의 결과 test
요구한대로 제품이 완성되었는지, 정상적으로 동작하는지 테스트

무엇을 목적으로 테스트 진행?
회복, 안전, 강도, 성능, 구조, 회귀, 병행

[화이트박스 테스트]

모듈의 원시코드를 오픈시킨 상태에서 원시코드의 논리적인 모든 경로를 테스트해 테스트 케이스를 설계하는 방법
설계된 절차에 초점, 테스트 과정의 초기에 적용
모듈 안의 작동을 직접 관찰, 모든 문장을 한번 이상 수행

1. 기초 경로 검사 : 대표적인 화이트박스 테스트 기법, 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해줌, 테스트 측정 결과는 실행경로의 기초를 정의하는 데 지침으로 사용
2. 제어 구조 검사 : 조건검사, 루프검사, 데이터 흐름검사

검증기준 : 문장, 분기, 조건, 분기/조건
검증 기준 종류 : 기능 기반 커버리지, 라인 커버리지, 코드 커버리지

[블랙박스 테스트]

sw가 수행할 특정 기능을 알기위해 각 기능이 완전히 작동되는지 입증하는 test
요구사항 명세 보면서 test, 주로 구현된 기능을 테스트
sw 인터페이스에서 실시, 테스트 과정의 후반부에 적용

1. 동치 분할 검사 : 입력 자료에 초첨을 맞춰 테스트 케이스를 만들고 검사, 해당 입력 자료에 맞는 결과가 출력되는지 확인
2. 경계값 분석 : 입력 자료에만 치중한 동치분할 보완 기법, 입력 조건의 경계값을 테스트 케이스로 선정해 검사
3. 원인-효과 그래프 검사
4. 오류 예측 검사 : 과거의 경허이나 감각으로 테스트
5. 비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

[테스트 단계]

sw의 개발단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류
app 테스트와 sw 테스트 단계를 연결하여 표현 한 것을 V-모델 이라고 함
(v-모델 그리기)

[단위 테스트]

코딩 직후 sw 설계의 최소단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선
구조 기반 테스트 - 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트(제어흐름, 조건결정)
명세 기반 테스트 - 목적 및 코드 기반의 블랙박스 테스트(동등분할, 경계 값 분석)

[통합 테스트]

단위 테스트가 완료된 모듈들을 결합 해 하나의 시스템으로 완성시키는 과정에서 오류 및 결함을 찾는 테스트 기법

비점진적 통합방식
모든 모듈이 미리 견합되어있는 프로그램 전체를 테스트, 작은 sw유리, 빅뱅통합테스트, 전체 프로그램을 대상으로 해 오류 발견 및 장애 위치 파악 및 수정이 어렵다.

점진적 통합방식
모듈 단위로 단계적으로 통합하면서 테스트, 오류수정 용이

1. 하향식 통합 테스트
   프로그램의 상위 모듈에서 하위 모듈 방향으로 통합 하면서 테스트 하는 기법, 깊이 우선이나 넓이 우선 통합법 사용, 시스템 구조 보여주기 가능, 상위 모듈에서는 테스트 케이스 사용이 어려움
   스텁으로 대체 - 깊이나 넓이우선 탐색 방식에 따라 하위 모듈인 스텁들이 실제 모듈로 교체 - 통합될때마다 테스트 실시 - 새로운 오류 발생안함을 보증하기 위해 회귀테스트 실행
2. 상향식 통합 테스트
   하위모듈에서 상위모듈 방향으로 통합
   하위모듈을 클러스터로 결합 - 상위 모듈에서 입출력 확인 위해 드라이버 작성 - 클러스터 단위로 테스트 - 완료시 클러스터는 구조의 상위로 이동해 결합하고 드라이버는 실제 모듈로 대체

• 드라이버와 스텁의 차이점(적기)
  
  
  
  

혼합식 통합 테스트 - 하위 수준에서는 상향식, 상위수준에서는 하향식 통합을 사용해 최적의 테스트를 지원, 샌드위치식 통합이라고 함

회귀 테스트 - 테스팅 반복, 새로운 오류가 있는지 확인, 기존의 케이스 중 변경된 부분을 테스트 할 수 있는 테스트 케이스만을 선정해 수행

[시스템 테스트]

개발된 sw가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
실제 사용 환경과 유사하게 만든 테스트 환경에서 수행

[인수 테스트]

개발한 sw가 사용자의 요구사항을 충족시키는지에 중점을 두고 테스트 하는 방법, 사용자가 직접 테스트
알파 테스트 : 새발자의 방소에서 사용자가 개발자 앞에서 test, 통제된 환경에서 수행, 사용자와 개발자가 함께 확인
베타 테스트 : 선정된 사용자가 여러명의 사용자 앞에서 테스트

[애플리케이션 프로젝트]

개발된 sw가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차

1. 테스트 계획
   프로젝트 계획서, 요구 명세서 등을 기반으로 테스트목표를 정의하고 테스트 대상 및 범위 결정, 테스트 대상 시스템의 구조를 파악, 투입되는 조직 및 비용을 산정, 테스트 시작 및 종료 조건을 정의 (시작 : 모든조건 만족안해도 시작가능, 종료 : 업무 기능의 중요도에 따라 종료 조건을 다르게 지정가능), 테스트 계획서 작성

2. 테스트 분석 및 디자인
   테스트의 목적과 원칙을 검토하고 사용자의 요구사항 분석, 테스트에 대한 리스크 분석 및 우선순위 결정, 테스트데이터 테스트 환경 테스트 도구 등을 준비

3. 테스트 케이스 및 시나리오 작성
   테스트 케이스의 설계 기법에 따라 테스트 케이스를 작성하고 검토 및 확인한 후 테스트 시나리오를 작성, 테스트용 스크립트 작성

4. 테스트 수행
   테스트 환경 구축 후 테스트 수행, 실행 결과를 측정하여 기록

5. 테스트 결과 평가 및 리포팅
   테스트 결과를 비교 분석하여 테스트 결과서를 작성

6. 결함 추적 및 관리
   텟트 수행 후 결함이 어디서 발생했는지, 어떤 종류의 결함인지 등 추적하고 관리, 동일한 결함 발견 시 시간단축 및 결함의 재발 방지 가능
   에러오류 : 결함의 원인, sw개발자 등 사람에 의해 발생한 실수
   결함/결점/버그 : 에러 오류로 인해 sw제품에 발생한 결함, 결함제거안하면 sw에 문제발생 가능성 있음

[테스트 케이스]

구현된 sw가 사용자의 요구사항을 준수했는지 확인하기 위해 설계된 입력값, 실행조건, 기대 결과 등으로 구성된 테스트항목에 대한 명세서, 명세기반테스트의 설계 산출물
미리 설계시 테스트 오류방지, 시간낭비 줄일수 있음, 시스템 설계시 작성

작성순서
테스트 계획 검토 및 자료확보 - 위험평가 및 우선순위 결정 - 요구사항 정의 - 구조 설계 및 방법 결정 - 테스트 케이스 정의 - 케이스 타당성 확인 및 유지보수

[테스트 시나리오]

테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합, 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서
테스트 순서를 미리 정해 테스트 항목을 빠짐없이 수행할 수 있음

유의사항
여러 개의 시나리오로 분리하여 작성, 사용자의 요구사항과 설계문서 등을 토대로 작성

[테스트 오라클]

테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동
제한된 검증 - 모든 테스트 케이스에 적용
수학적 기법 - 오라클의 값을 수학적 기법을 이용하여 구할수 있음
자동화 기능 - 자동화 가능

종류
참 오라클 - 모든 케이스의 입력값에 대해 기대하는 결과를 제공하는 오라클, 발생된 모든 오류를 검출가능
샘플링 오라클
추정 오라클
일관성 검사 오라클

[결함]

오류 발생, 작동 실패 등과 같이 sw가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는것, 예상한 결과와 실행 결과 간의 차이나 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분도 모두 결함

결함 관리 프로세스
결함관리계획 - 결함 기록 - 결함 검토 - 결함 수정 - 결함 재확인 - 결함 상태 추적 및 모니터링 활동 - 최종 결함 분석 및 보고서 작성

테스트에서 발견된 결함은 지속적으로 상태변화를 추적하고 관리해야함

결함 추적 순서
결함등록(Open) - 결함 검토(Reviewed) - 결함 할당(Assigned) - 결함 수정(Resolved) - 결함 조치 보류(Deferred) - 결함 종료(Closed) - 결함 해제(Clarified)

결함 분류
시스템결함, 기능결함, GUI결함, 문서결함

결함 심각도
High, Medium, Low

결함 우선순위
신속성읠 나타내는 척도, 심각도가 높으면 우선순위도 높지만 심각도가 높다고 반드시 우선순위가 높은것은 아니다.

결함 관리 도구
Mantis, Trac, Redmine, Bugzilla