7장. 애플리케이션 테스트 관리

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

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

1. 소프트웨어 테스트의 이해

 

■ 소프트웨어 테스트 개념

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

 

■ 소프트웨어 테스트 필요성 (발예향)

- 오류 발견 관점 : 잠재된 오류를 발견하고 이를 수정하여 올바른 프로그램을 개발하기 위해 필요

- 오류 예방 관점 : 프로그램 실행 전에 동료 검토, 워크스루, 인스펙션 등을 통해 오류를 사전에 발견하는 예방 차원의 필요

- 품질 향상 관점 : 사용자의 요구사항 및 기대 수준을 만족하도록 반복적인 테스트를 거쳐 제품의 신뢰도를 향상하는 품질 보증을 위해 필요

 

■ 소프트웨어 테스트의 기본 원칙 (결완초집 살정오)

- 테스팅은 결함이 존재함을 밝히는 것

- 완벽한 테스팅은 불가능

- 개발 초기에 테스팅 시작

- 결함 집중 : 20% 모듈에서 80% 결함이 발견된다.

- 살충제 페러독스 : 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함

- 테스팅은 정황에 의존적 : 소프트웨어 성격에 맞게 테스트 실시

- 오류-부재의 궤변 : 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없다.

 

■ 소프트웨어 테스트 산출물 (결시계케)

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

- 테스트 시나리오 : 테스트 수행을 위한 여러 개의 테스트 케이스 집합. 테스크 케이스의 동작 순서를 기술한 문서이며, 테스트 절차를 명세한 문서

- 테스트 계획서 : 테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행 절차, 일정, 종료 조건 등 테스트 수행을 계획한 문서

- 테스트 케이스 : 테스트를 위한 설계 산출물. 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서

 

 

2. 소프트웨어 테스트 유형

 

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

• 정적 테스트 : 프로그램 실행 없이 구조를 분석하여 논리성을 검증하는 테스트 

  • 동료 검토, 워크스루, 인스펙션

• 동적 테스트 : 프로그램 실행을 요구하는 테스트

  • 화이트박스 테스트, 블랙박스 테스트

• • 화이트박스 테스트 (제루) : 제어구조 테스트, 루프 테스트

• 블랙박스 테스트 : 프로그램 외부 사용자의 요구사항 명세를 보면서 수항하는 테스트(기능 테스트)

  • 블랙박스 테스트 유형 (동경결상 유분페) : 동등 분할 테스트, 경계 값 분석 테스트, 결정 테이블 테스트, 상태전이 테스트, 유스케이스 테스트, 분류트리 테스트, 페어와이즈 테스트

■ 테스트 시각에 따른 분류

• 검증(Verification) : 소프트웨어 과정을 테스트. 개발자 혹은 테스터의 시각으로 소프트웨어가 기능을 올바로 수행하는지 알아보는 과정

• 확인(Validation) : 소프트웨어 결과를 테스트. 사용자 시각으로 올바른 소프트웨어가 개발되었는지 입증하는 과정

■ 테스트 목적에 따른 분류 (회안강성 구회병)

- 회복 테스트 : 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트

- 안전 테스트 : 불법 소프트웨어가 시스템을 파괴하지 못하도록 소스 코드 내의 보안결함을 미리 점검하는 테스트

- 강도 테스트 : 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지 검증하는 테스트

- 성능 테스트 : 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 측정하는 테스트

- 구조 테스트 : 시스템 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 

- 회귀 테스트 : 오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트

- 병행 테스트 : 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트

 

■ 테스트 종류에 따른 분류 (명구경)

- 명세 기반 테스트

- 구조 기반 테스트

- 경험 기반 테스트

 

 

3. 테스트 케이스

 

■ 테스트 케이스 개념

특정 요구사항에 준수하는 지를 확인하기 위해 개발된 입력값, 실행 조건 , 예상된 결과의 집합이다.

 

 

4. 테스트 오라클

 

■ 테스트 오라클 개념

테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법이다.

 

■ 테스트 오라클 종류 (참샘휴일)

- 참 오라클 : 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클

- 샘플링 오라클 : 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클

- 휴리스틱 오라클 : 샘플링 오라클을 개선한 오라클로, 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클

- 일관성 검사 오라클 : 애플리케이션 변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클

 

애플리케이션 테스트 시나리오 작성

1. 테스트 레벨

 

■ 테스트 레벨 개념

함께 편성되고 관리되는 테스트 활동의 그룹이다. 테스트 레벨은 프로젝트에서 책임과 연관되어 있다. 각각의 테스트 레벨은 서로 독립적이다.

 

■ 테스트 레벨 종류 (단통시인)

- 단위 테스트 : 단위 모듈, 서브루틴 등을 테스트하는 단계

- 통합 테스트 : 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계

- 시스템 테스트 : 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지 검증하는 테스트 단계 

- 인수 테스트 : 계약상 요구사항이 만족되었는지 확인하기 위한 테스트 단계

 

 

2. 테스트 시나리오

 

■ 테스트 시나리오 개념

테스트 수행을 위한 여러 테스트 케이스의 집합으로, 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세한 문서이다.

 

#2 애플리케이션 통합 테스트

애플리케이션 통합 테스트 수행

1. 통합 테스트 

 

■ 통합 테스트 개념

애플리케이션 통합 테스트는 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법이다. 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 테스트이다.

 

■ 하향식 통합 개념

메인 제어 모듈(프로그램)로 부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트를 진행하며, 메인 제어 모듈에 통합되는 하위 모듈과 최하위 모듈은 '깊이-우선' 또는 '너비-우선' 방식으로 통합된다. (더미 모듈 스텁 개발 및 사용)

 

■ 상향식 통합 개념

애플리케이션 구조에서 최하위 레벨의 모듈 또는 컴포넌트로부터 위쪽 방향으로 제어의 경로를 따라 이동하면서 구축과 테스트를 수행한다. (더미 모듈 드라이버 작성 및 사용)

 

 

2. 테스트 자동화 도구

 

■ 테스트 자동화 도구 유형 (정실성통)

- 정적 분석 도구

- 테스트 실행 도구

- 성능 테스트 도구

- 테스트 통제 도구

 

■ 테스트 하네스 개념

애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터를 말하며, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성한다.

 

■ 테스트 하네스 구성요소 (드 스슈케 스목)

- 테스트 드라이버 : 테스트 대상 하위 모듈을 호출, 파라미터 전달, 테스트 수행 후 결과 도출 등 상향식 테스트에 필요

- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 하향식 테스트에 필요

- 테스트 슈트 : 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합

- 테스트 케이스 : 입력값, 실행 조건, 기대 결과 등의 집합

- 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세

- 목 오브젝트 : 사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체

 

애플리케이션 개선 조치사항 작성

1. 테스트 커버리지

 

■ 테스트 커버리지 개념

주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이며, 테스트의 정확성과 신뢰성을 향상시키는 역할을 한다.

 

■ 테스트 커버리지 유형 (기라코)

- 기능 기반 커버리지 : 테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정하는 방법 

- 라인 커버리지 : 애플리케이션 전체 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수를 측정하는 기법

- 코드 커버리지 : 소프트웨어 테스트 충분성 지표 중하나로 구조 코드 자체가 얼마나 테스트되었는지를 측정하는 방법

 

■ 코드 커버리지 유형 (구결조 조변다)

- 구문 커버리지

- 결정 커버리지

- 조건 커버리지

- 조건/결정 커버리지

- 변경 조건/결정 커버리지

- 다중 조건 커버리지

 

 

2. 결함의 식별 및 관리

 

■ 결함 심각도 분류 (치주 보경단)

- 치명적 결함

- 주요 결함

- 보통 결함

- 경미한 결함

- 단순 결함

 

#3 애플리케이션 성능 개선

애플리케이션 성능 분석

1. 애플리케이션 성능 점검 개요

 

■ 애플리케이션 성능 측정 지표 (처응경자)

- 처리량 : 주어진 시간에 처리할 수 있는 트랜잭션 수

- 응답 시간 : 사용자 입력이 끝난 후, 응답 출력이 개시될 때까지의 시간

- 경과 시간 : 입력 시점부터 트랜잭션을 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간

- 자원 사용률 : 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량

 

 

2. 애플리케이션 성능 저하 원인

 

■ 데이터베이스 관련 성능 저하 원인 (락페릭사커)

- DB Lock : 대량의 데이터 처리시 발생

- DB Fetch : 실제 필요한 데이터보다 많은 데이터 요청이 들어올 경우 응답시간 저하 현상 발생

- Connection Leak : DB 연결과 관련한 JDBC 객체를 사용 후 종료하지 않을 경우 발생

- Connection Pool Size : 너무 작거나 크게 설정한 경우 성능 저하 현상이 발생할 가능성 존재

- Commit : 불필요한 Commit이 자주 발생하는 경우 성능저하

 

3. 애플리케이션 성능 테스트 프로세스

 

■ 애플리케이션 성능 테스트 수행 절차 (도환시성)

- 성능 테스트 도구 설치

- 테스트 환경 설정

- 시나리오 생성

- 성능테스트 실행 및 모니터링

 

애플리케이션 성능 개선

1. 소스 코드 최적화의 이해

 

■ 나쁜 코드 유형 (오문이 결침)

- 오염 : 기능을 수행하지 못하는 많은 컴포넌트들이 존재

- 문서부족 : 현재 코드와 문서가 일치하지 않아 개발자의 지식부족 초래

- 의미 없는 이름 : 클래스, 함수, 컴포넌트 이름들이 명확한 의미를 갖지 못하거나 실제 작동과 불일치

- 높은 결합도 : 데이터와 컨트롤 흐름이 복잡하게 연결

- 아키텍처 침식 : 아키텍처상 변형들로 인해 시스템 품질이 떨어짐

 

■ 클린 코드 유형 (이주배 함제오)

- 의미 있는 이름

- 간결한 주석

- 보기 좋은 배치

- 작은 함수

- 읽기 쉬운 제어 흐름

- 오류 처리