애플리케이션 테스트 관리 테스트 케이스 설계 1/4

애플리케이션 테스트 관리 테스트 케이스 설계

애플리케이션 테스트 케이스 작성

소프트웨어 테스트의 이해

소프트웨어 테스트 개념

• 개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능과 성능, 사용성, 안정성 등을 만족하는지 확인하고, 노출되지 않은 숨어있는 소프트웨어의 결함을 찾아내는 활용

소프트웨어 테스트 필요성

• 오류 발견 관점 : 프로그램에 잠재된 오류를 발견하고 이를 수정하여 올바른 프로그램을 개발하기 위해 필요
• 오류 예방 관점 : 프로그램 실행 전에 동료 검토, 워크 스루, 인스펙션 등을 통해 오류를 사전에 발견하는 예방 차원의 필요
• 품질 향상 관점 : 사용자의 요구사항 및 기대 수준을 만족하도록 반복적인 테스트를 거쳐 제품의 신뢰도를 향상하는 품질 보증을 위해 필요

소프트웨어 테스트의 기본 원칙

소프트웨어 테스트 원리

결함 존재 증명

• 결함이 존재함을 밝히는 활동
• 결함이 없다는 것을 증명할 수는 없음
• 결함을 줄이는 활동

완벽 테스팅은 불가능

• 완벽하게 테스팅하려는 시도는 불필요한 시간과 자원 낭비
• 무한 경로(한 프로그램 내의 내부 조건은 무수히 많을 수 있음), 무한 입력값(입력이 가질 수 있는 모든 값의 조합이 무수히 많음)으로 인한 테스트 어려움

초기 집중

• 조기 테스트 설계 시 장점 : 테스팅 결과를 단시간에 알 수 있고, 테스팅 기간 단축, 재작업을 줄여 개발 기간 단축 및 결함 예방
• SW 개발 초기 체계적인 분석 및 설계가 수행되지 못하면 그 결과가 프로젝트 후반에 영향을 미치게 되어 비용이 커진다는 요르돈의 법칙 적용(눈덩이 법칙, Snowball Effect)

결함 집중

• 적은 수의 모듈에서 대다수의 결함이 발견됨
• 소프트웨어 테스트에서 오류의 0%는 전체 모듈의 20% 내에서 발견
• 파레토 법칙(Pareto Principle)의 내용인 80 대 20 법칙 적용

살충제 패러독스

• 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함
• 테스트 케이스의 정기적 리뷰의 개선 및 다른 시각에서의 접근이 필요

정황 의존성

• 소프트웨어의 성격에 맞게 테스트 시행
• 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행

오류-부재의 궤변

• 요구사항을 충족시켜 주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없음

소프트웨어 테스트 프로세스

테스트 계획

1. 테스트 목적과 범위 정의
2. 대상 시스템 구조 파악
3. 테스트 일정 정의
4. 종료 조건 정의
5. 조직 및 비용 산정

테스트 분석 및 디자인

1. 테스트 목적과 원칙 검토
2. 요구사항 분석
3. 리스크 분석 및 우선순위 결정
4. 테스트 데이터 준비
5. 테스트 환경 및 도구 준비

테스트 케이스 및 시나리오 작성

1. 테스트 케이스 작성
2. 테스트용 스크립트 작성
3. 테스트 케이스 검토 및 확인
4. 테스트 시나리오 작성

테스트 수행

1. 초기 데이터 로딩
2. 테스트 수행
3. 결함 리포팅

테스트 결과 평가 및 리포팅

1. 테스트 결과 정리
2. 테스트 프로세스 리뷰
3. 테스트 결과 평가
4. 테스트 리포팅

소프트웨어 테스트 산출물

테스트 계획서(Test Plan)

• 테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임 정의, 종료 조건 정의 등 테스트 수행을 계획한 문서

테스트 베이시스(Test Basis)

• 분석, 설계 단계의 논리적인 Case로 테스트 설계를 위한 기준이 되는 문서(요구사항 명세서, 관련 기준 또는 표준 등)

테스트 케이스(Test Case)

• 테스트를 위한 설계 산출물로, 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서

테스트 슈트(Test Suites)

• 테스트 케이스를 실행 환경에 따라 구분해 놓은 테스트 케이스의 집합
• 시나리오가 포함되지 않은 단순한 테스트 케이스들의 모음

테스트 시나리오(Test Scenario)

• 애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서
• 하나의 단일 테스트 시나리오가 하나 또는 여러 개의 테스트 케이스들을 포함할 수 있음
• 테스트 시나리오가 테스트 케이스와 일 대 다의 관계를 맺음

테스트 스크립트(Test Script)

• 테스트 케이스의 실행 순서(절차)를 작성한 문서
• 테스트 스텝(Test Step), 테스트 절차서(Test Procedure)라고도 함

테스트 결과서(Test Results)

• 테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰하고, 테스트 결과를 평가하고 리포팅하는 문서

소프트웨어 테스트 유형

프로그램 실행 여부에 따른 분류

정적 테스트

• 테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증하는 테스트
• 리뷰, 정적 분석

동적 테스트

• 소프트웨어를 실행하는 방식으로 테스트를 수행하여 결함을 검출하는 테스트
• 화이트박스 테스트, 블랙박스 테스트, 경험기반 테스트

테스트 기법에 따른 분류

화이트박스 테스트(White-Box Test)

• 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트
• 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는 모듈 내부를 테스트하는 방법
• 소스 코드의 모든 문장을 한 번 이상 수행함으로써 진행되고, 산출물의 기능별로 적절한 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검
• 내부 소스 코드의 동작을 개발자가 추적할 수 있기 때문에, 동작의 유효성뿐만 아니라 실행되는 과정을 확인할 수 있음
• 구조 기반 테스트, 코드 기반 테스트, 로직 기반 테스트, 글래스(Glass) 박스 테스트라고도 부름

화이트박스 테스트 유형

구문 커버리지 = 문장 커버리지(Statement Coverage)

• 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지
• 조건문 결과와 관계없이 구문 실행 개수로 계산

결정 커버리지 = 선택 커버리지(Decision Coverage) = 분기 커버리지(Branch Coverage)

• (각 분기의) 결정 포인트 내의 전체 조건식이 적어도 한 번은 참(T)과 거짓(F)의 결과를 수행하는 테스트 커버리지
• 구문 커버리지를 포함

조건 커버리지(Condition Coverage)

• (각 분기의) 결정 포인트 내의 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 테스트 커버리지
• 구문 커버리지를 포함

조건/결정 커버리지(Condition/Decision Coverage)

• 조건/결정 커버리지는 전체 조건식뿐만 아니라 개별 조건식도 참 한번, 거짓 한 번 결과가 되도록 수행하는 테스트 커버리지

변경 조건/결정 커버리지(Modified Condition/Decision Coverage)

• 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상한 커버리지

다중 조건 커버리지(Multiple Condition Coverage)

• 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 커버리지

기본 경로 커버리지 = 경로 커버리지(Base Path Coverage)

• 수행할 수 있는 모든 경로를 테스트하는 기법

제어 흐름 테스트(Control Flow Testing)

• 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트하는 기법

데이터 흐름 테스트(Data Flow Testing)

• 제어 흐름 그래프에 데이터 사용 현황을 추가한 그래프를 통해 테스트하는 기법

루프 테스트(Loop Testing)

• 프로그램의 반복(Loop) 구조에 초점을 맞춰 시행하는 테스트 기법