애플리케이션 테스트 관리

테스트 케이스

소프트웨어 테스트

• 소프트웨어 개발 단계에서 사용자 요구사항에 서술된 동작과 성능, 사용성, 안정성 등을 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아내는 활동으로 품질 향상, 오류 발견, 오류 예방 관점에서 수행하는 행동
• 품질 향상 관점 : 반복적인 테스트를 거쳐 제품의 신뢰도를 향상하는 품질 보증 활동
• 오류 발견 관점 : 잠재된 오류를 발견하고 이름 수정하여 올바른 프로그램을 개발하는 활동
• 오류 예방 관점 : 코드 리뷰, 동료 검토, 인스펙션 등을 통해 오류를 사전에 발견하는 활동

소프트웨어 테스트의 원리

테스팅은 결함이 존재함을 밝히는 활동이다	소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타냄
완벽한 테스팅은 불가능하다	무한 경로, 무한 입력값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중하는 것을 의미
테스팅은 개발 초기에 시작해야 한다	애플리케이션의 개발 단계에 테스트를 계획하고 SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻
결함 집중 (Defect Clustering)	애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재함. 파레토 법칙이 좌우함
살충제 패러독스 (Pesticide Paradox)	동일한 테스트 케이스로 반복 테스트 시 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 함
테스팅은 정황(Context)에 의존한다	정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 함
오류-부재의 궤변 (Absence of Errors Fallacy)	사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다 해도, 해당 애플리케이션의 품ㅁ질이 높다고 말할 수 없음

파레토의 법칙(Law of Pareto)

• '80 대 20 법칙'  또는 2 대 8 법칙'이라고도 함
• 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상
• 예를 들어, 20%의 VIP 고객이 백화점 전체 매출의 80%에 해당하는 만큼 쇼핑하는 현상을 의미

테스트 케이스(Test Case)

• 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서를 의미
• 명세 기반 테스트의 설계 산출물임
  • 명세 기반 테스트 : 테스트 수행의 증거로도 활용되며, 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인
• 테스트 케이스를 설계 단계에 작성하면 테스트 시 오류를 방지하고, 테스트 수행에 있어 낭비를 줄일 수 있음
• 표준 테스트 케이스 형식

ID

시나리오

테스트 단계

테스트 데이터

예상 결과

실제 결과

통과 실패

테스트 케이스 작성 절차

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

테스트 케이스의 구성 요소(ISO/IEC/IEEE 29119-3)

• 식별자(Identifier), 테스트 항목(Test Item), 입력 명세(Input Specification), 출력 명세(Output Specification), 환경 설정(Environmental Needs), 특수 절차 요구(Special Procedure Requirement), 의존성 기술(Inter-case Dependencies)

테스트 프로세스(Test Process)

• 계획  및 제어 → 분석 및 설계 → 구현 및 실현 → 평가 → 완료

테스트 커버리지(Test Coverage)

• 테스트 수행 정도로서 구문 커버리지, 결정 커버리지, 조건 커버리지, 조건/결정 커버리지, 변경 조건/결정 커버리지, 다중 조건 커버리지로 구분

테스트 오라클(Test Oracle)

• 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참(True)값을 입력하여 비교하는 기법 및 활동

참(True) 오라클	모든 입력값에 대하여 적합한 결과를 생성하여, 발생한 오류를 모두 검출할 수 있는 오라클
일관성 검사(Consistent) 오라클	애플리케이션 변경이 있을 때, 수행 전과 후의 결과값이 동일한지 확인하는 오라클
샘플링(Sampling) 오라클	임의로 선정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공
휴리스틱(Heuristic) 오라클	샘플링 오라클을 개선한 오라클로, 임의 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리

 

V-모델과 테스트

테스트 레벨

• 애플리케이션 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 설치 테스트로 분류함
• 애플리케이션을 총체적으로 관리하기 위한 테스트 활동의 묶음
• 각각의 테스트 레벨은 서로 독립적, 각각 다른 테스트 계획과 전략이 필요함

시각에 따른 테스트

• 검증(Verification) 테스트 : 제품이 명세서대로 완성되었는지 검증하는 단계. 개발자의 시각에서 제품의 생산 과정을 테스트하는 것을 의미
• 확인(Validation) 테스트 : 사용자의 요구사항을 잘 수행하고 있는지 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것을 의미

테스크 케이스 자동 생성

• 자료 흐름도 → 테스트 경로 관리, 입력 도메인 분석 → 테스트 데이터 산출, 랜덤 테스트 → 무작위 값 입력, 신뢰성 검사

테스트 레벨의 종류

단위(Unit) 테스트	- 개발자가 원시 코드를 대상으로 각각의 단위를 다른 부분과 연계되는 부분은 고려하지 않고 단위 자체에만 집중하여 테스트함 - 객체지향에서 클래스 테스팅이 여기에 해당함
통합 테스트	단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트 간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트함
시스템 테스트	- 단위/통합 테스트가 가능한 완벽히 완료되어 기능상에 문제가 없는 상태에서 실제 환경과 가능한 유사한 환경에서 진행됨  - 시스템 성능과 관련된 요구사항이 완벽하게 수행되는지를 테스트하기 때문에 사전 요구사항이 명확해야 함 - 개발 조직과는 독립된 테스트 조직에서 수행함
인수 테스트	- 일반적인 테스트 레벨의 가장 마지막 상위 레벨로, SW 제품에 대한 요구사항이 제대로 이행되었는지 확인하는 단계 - 테스팅 환경을 실 사용자 환경에서 진행하며 수행하는 주체가 사용자임 - 알파, 베타 테스트와 가장 밀접한 연관이 있음

알파 테스트(Alpha Test)와 베타 테스트(Beta Test)

알파 테스트	- 개발자 관점에서 수행되며, 사용상의 문제를 반영되도록 하는 테스트 - 개발자의 장소에서 사용자가 개발자 앞에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 검사하는 기법 - 개발자는 사용상의 문제를 기록하여 반영되도록하는 테스트
베타 테스트	- 선정된 다수의 사용자가 자신들의 사용 환경에서 일정 기간 사용하면서 테스트 함 - 문제점이나 개선 사항 등을 기록하고 개발 조직에 통보하여 반영되도록 하는 테스트

 

애플리케이션 테스트

정적 테스트

• 애플리케이션을 직접 실행하지 않고 명세서나 소스코드를 대상으로 분석하는 테스트 방식
• 소프트웨어 개발 초기에 결함 발견이 가능하여, 개발 비용을 낮출 수 있음
• 종류 : Inspection, walk-through, Code Test, Orthogonal Array Testing, Prior Defect History Testing, Risk-Based Testing, Run Chart, Statistical Profile Testing

동적 테스트

• 애플리케이션을 직접 실행하여 오류를 찾는 테스트 방식
• 소프트웨어 개발의 모든 단계에서 테스트를 수행함
• 종류 : 블랙박스 테스트, 화이트박스 테스트

테스트 기반(Test Bases)에 따른 테스트

구분	설명
구조 기반 테스트	- 소프트웨어 내부의 구조(논리 흐름)에 따라 테스트 케이스를 작성하고 확인하는 테스트 방식 - 종류 : 구문 기반, 결정 기반, 조건 기반, 데이터 흐름
명세 기반 테스트	- 사용자의 요구사항에 대한 명세를 기반으로 테스트 케이스를 작성하고 확인하는 테스트 방식 - 종류 : 동등분할, 경계값 분석, 분류 트리, 상태 전이, 결정 테이블, 원인-결과 조합 테스트, 시나리오, 오류 추정
경험 기반 테스트	- 테스터의 경험을 기반으로 수행하는 테스트 방식 - 요구사항에 대한 명세가 미흡하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적 - 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅

목적에 따른 테스트

구분	설명
성능 (Performance)	소프트웨어의 응답 시간, 처리량 등을 테스트함
회복 (Recovery)	소프트웨어에 고의로 부하를 가하여 실패하도록 유도하고 올바르게 복구되는지 테스트함
구조 (Structured)	소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가
회귀 (Regression)	소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
안전 (Security)	소프트웨어가 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인
강도 (Stress)	소프트웨어에 과도하게 부하를 가하여도 소프트웨어가 정상적으로 실행되는지 확인
병행 (Parallel)	변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 두 결과를 비교 확인