소프트웨어 관리 2: 애플리케이션 테스트

22 Jul 2024     #cs

애플리케이션 테스트 (Application Testing)

개발된 SW 애플리케이션에 잠재된 결함을 찾아내는 행위 또는 절차입니다.

애플리케이션 테스트의 기본 원리

• 파레토 법칙 (Pareto Princlple): 20%의 코드에서 전체 결함의 80%가 발견된다는 법칙
• 살충제 패러독스 (Pesticide Paradox): 동일한 테스트 케이스로 테스트를 반복하면 결함이 더 이상 발견되지 않는 현상
• 오류-부재의 궤변 (Absence of Errors Fallacy): SW의 결함을 모두 제거해도 요구사항을 만족하지 못하면, 해당 SW는 품질이 높다고 할 수 없는 것

애플리케이션 테스트의 분류

시각에 따른 분류

• 검증 테스트 (Verification): 개발자의 시각에서 제품의 생산 과정을 테스트, 제품이 명세서대로 완성되었는지를 테스트합니다.
• 확인 테스트 (Validation): 사용자의 시각에서 제품의 결과를 테스트, 제품이 요구사항대로 완성되었는지, 정상적으로 동작하는지를 테스트합니다.

목적에 따른 분류

• 회복 테스트 (Recovery): 여러 결함을 주어 실패하게 한 후, 잘 복구되는지를 테스트합니다.
• 안전 테스트 (Security): 시스템 내 시스템 보호 도구가 불법 침입을 잘 보호하는지를 테스트합니다.
• 강도 테스트 (Stress): 과도한 정보량 등으로 과부하를 주어도 정상적으로 실행되는지를 테스트합니다.
• 성능 테스트 (Performance): 효율성이나 실시간 성능을 진단하는 것으로, 처리량 및 응답 시간 등을 테스트합니다.
• 구조 테스트 (Structure): SW 내부의 논리적 경로, 코드의 복잡도 등을 테스트합니다.
• 회귀 테스트 (Regression): SW가 변경/수정된 경우 새로운 결함이 없다는 것을 확인하는 테스트입니다.
• 병행 테스트 (Parallel): 변경된 SW와 기존 SW에 동일 데이터를 입력하여 결과를 비교하는 테스트입니다.

애플리케이션 성능 측정 지표

• 처리량 (Throughput): 일정 시간 내 애플리케이션이 처리하는 일의 양
• 응답 시간 (Response Time): 애플리케이션에 요청한 시간부터 응답 받은 시간까지 걸린 시간
• 경과 시간 (Turn Around Time): 애플리케이션이 작업을 요청 받고 처리 완료할 때까지 걸린 시간
• 자원 사용률 (Resource Usage): 애플리케이션이

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

• 정적 테스트: 프로그램을 실행하지 않고 명세서나 코드를 대상으로 분석하는 테스트입니다. 코드의 코딩 표준, 스타일, 복잡도, 결함 등을 발견합니다.
  • 종류: 코드 검사, 워크스루, 인스펙션 등
• 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트로, 개발의 모든 단계에서 수행합니다.
  • 종류: 화이트박스 테스트, 블랙박스 테스트

개발 단계에 따른 분류

• 테스트 레벨: SW 개발 단계에 따라 분류된 테스트 단계
• V-모델: SW 개발 단계와 애플리케이션 테스트를 연결하여 표현한 모델

화이트박스 테스트와 블랙박스 테스트

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

SW 소스 코드의 논리적인 모든 경로를 테스트하는 방법입니다. 코드 내 모든 문장을 실행하여 수행하고, 실행함으로써 모듈 내 작동을 직접 관찰합니다.

화이트박스 테스트의 종류

• 기초 경로 검사 (Base Path Testing): 대표적인 화이트박스 테스트 기법으로, 테스트 케이스 설계자가 설계의 복잡성을 측정할 수 있게 해줍니다.
• 제어 구조 검사 (Condition Structure Testing):
  • 조건 검사 (Conditon Testing): 모듈 내 논리적 조건을 테스트하기 위한 테스트 케이스 설계 기법
  • 루프 검사 (Loop Testing): 반복(Loop) 구조에 초점을 두어 실시하는 테스트 케이스 설계 기법
  • 데이터 흐름 검사 (Data Flow Testing): 변수의 정의와 사용 위치에 초점을 두어 실시하는 테스트 케이스 설계 기법

화이트박스 테스트의 검증 기준

• 문장 검증 기준 (Statement Coverage): 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계합니다.
• 분기 검증 기준 (Branch Coverage): 모든 조건문에 대해 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계합니다. 결정 검증 기준 (Decision Coverage)이라고도 합니다.
• 조건 검증 기중 (Condition Coverage): 조건문 내 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계합니다.
• 분기/조건 기준 (Branch/Condition Coverage): 분기 검증과 조건 검증 기준을 모두 만족하는 설계입니다. 분기 검증에 따라 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계합니다.

블랙박스 테스트 (Black Box Test)

SW의 각 기능이 완전히 작동되는 것을 입증하는 테스트입니다. 요구사항 명세를 보면서, 인터페이스를 통해 실시합니다. 구현된 기능을 테스트 하므로 기능 테스트라고도 합니다.

블랙박스 테스트의 종류

• 동치 분할 검사 (Equivalent Partitioning Testing): 입력 조건에 타당한 입력과 타당하지 않은 입력의 개수를 균등하게 하여 테스트 케이스를 설계하고, 입력에 맞게 결과가 출력되는지 확인하는 방법입니다. 동등 분할 기법 혹은 동치 클래스 분해라고도 합니다.
• 경계값 분석 (Boundary Value Analysis): 입력 조건의 경계값을 테스트 케이스로 선정하는 방법입니다. 입력 조건의 중간보다 경계에서 오류가 발생할 확률이 높다는 것을 이용합니다
• 원인-효과 그래프 검사 (Cause-Effect Graphing Testing): 입력 간 관계와 출력에 영향을 미치는 상황을 분석하여 효용성 높은 테스트 케이스를 선정하는 방법입니다.
• 오류 예측 검사 (Error Guessing): 과거 경험이나 감각으로 테스트하는 방법입니다.
• 비교 검사 (Comparison Testing): SW의 여러 버전이 있을 때, 여러 버전에 동일한 테스트를 하여 동일한 결과가 출력되는지 보는 기법입니다.

단위, 통합, 시스템, 인수 테스트

단위 테스트 (Unit Test)

코딩 직후 SW의 최소 단위인 모듈이나 컴포넌트를 대상으로 하는 테스트입니다.

• 검사 항목: 인터페이스, I/O, 자료구조, 기초 경로, 오류 처리 경로, 경계 조건 등
• 기능성 테스트를 최우선으로 수행: 요구사항을 기반으로 테스트
• 분류: 구조 기반 테스트, 명세 기반 테스트. 주로 구조 기반 테스트를 합니다.

통합 테스트 (Integration Test)

모듈을 결합하여 시스템으로 완성하는 과정에서 하는 테스트입니다. 모듈 또는 통합된 컴포넌트 간 상호 작용 오류, 즉 인터페이스가 정상적으로 실행되는지 검사합니다.

• 통합 방식의 분류: 비점진적 통합, 점진적 통합
  • 비점진적 통합 방식: 모든 모듈이 미리 결합된 상태의 프로그램 전체를 테스트하는 방법. 빅뱅 통합 테스트 등이 있습니다.
  • 점진적 통합 방식: 모듈을 단계적으로 통합하면서 테스트하는 방법. 하향식, 상향식, 혼합식 통합 테스트 등이 있습니다.

하향식 통합 테스트 (Top Down Integration Test)

상위 모듈에서 하위 모듈 방향으로 통합하며 테스트하는 방법입니다.

1. 주요 제어 모듈(상위 모듈)은 작성된 것을 사용하고, 종속 모듈은 스텁(Stub)으로 대체
2. 통합 방식(깊이 우선, 넓이 우선 등)에 따라 스텁을 하나씩 실제 모듈로 교체
3. 모듈이 통합될 때마다 테스트 실시
4. 회귀 테스트를 실시해 새로운 오류가 발생하지 않음을 보증

• 스텁 (Stub): 제어 모듈이 호출하는 모듈의 기능을 단순히 수행하는 일시적 시험용 모듈

상향식 통합 테스트 (Bottom Up Integration Test)

하위 모듈에서 상위 모듈 방향으로 통합하며 테스트하는 방법입니다.

1. 하위 모듈을 클러스터(Cluster)로 결합
2. 드라이버(Driver)를 작성해 상위 모듈의 데이터 입/출력을 확인
3. 통합된 클러스터 단위로 테스트
4. 테스트가 완료되면 클러스터를 구조 상 상위로 이동하고, 드라이버를 실제 모듈로 교체

• 테스트 드라이버 (Test Driver): 테스트 대상인 하위 모듈 호출, 파라미터 전달, 테스트 결과를 도출하는 도구

회귀 테스트 ()