7장 애플리케이션 테스트 관리 (화이트박스, 블랙박스)

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

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

 

 

프로그램 실행 여부에 따른 테스트

• 정적 테스트: 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석
  • 워크스루, 인스펙션, 코드 검사 등
• 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트
  • 블랙박스 테스트, 화이트박스 테스트

 

화이트박스 테스트 종류

• 기초 경로 검사: 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
• 제어 구조 검사:
  • 조건 검사: 프로그램 모듈 내에 있는 논리적 조건을 테스트
  • 루프 검사: 프로그램의 반복 구조에 초점을 맞춰 실시
  • 데이터 흐름 검사: 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시

 

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

• 문장 검증 기준: 모든 구문이 한 번 이상 수행
• 결정 검증 기준: 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우 한 번 이상 수행
  • 분기(Branch) 검증 기준이라고도 함
• 조건 (Condition) 검증 기준: 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행
• 조건/결정 (Condition/Desicion) 검증 기준: 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분
  • 결정 검증 기준과 조건 검증 기준 모두 만족
• 변경 조건/결정 (Modified Condition/Decision) 검증 기준: 개별 조건식이 다른 개별 조건식의 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 설계
  • 조건/결정 검증 기준을 향상
• 다중 조건 검증 기준: 조건문에 포함된 모든 개별 조건식의 모든 조합을 고려

 

블랙박스 테스트

• 각 기능이 완전히 작동되는 것을 입증하는 테스트
• 사용자의 요구사항 명세를 보며 테스트
• 주로 구현된 기능을 테스트
• 소프트웨어 인터페이스를 통해 실시

 

블랙박스 테스트 종류

• 동치 분할 (Equivalence Partitioning) 검사: 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트
• 경계값 (Boundary Value) 분석: 경계값에서 오류가 발생될 확률이 높다는 점을 이용
• 원인-효과 (Cause-Effect) 그래프 검사: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스 선정해 검사
• 오류 예측 (Error Guessing) 검사: 과거의 경험이나 확인자의 감각으로 테스트
• 비교 (Comparison) 검사: 여러 버전의 프로그램에 동일한 테스트 자료 제공

 

개발 단계에 따른 애플리케이션 테스트

• 단위 테스트: 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
• 통합 테스트: 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
• 인수 테스트: 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
  • 알파 테스트: 사용자가 개발자 앞에서 행하는 테스트 기법
  • 베타 테스트: 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법

 

하향식/상향식 통합 테스트

• 하향식 통합 테스트: 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
  • 스텁: 제어 모듈이 호출하는 타 모듈의 기능을 수행하는 도구, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
• 상향식 통합 테스트: 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
  • 테스트 드라이버: 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구

 

회귀 테스트

• 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트

 

테스트 오라클

• 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법
• 참 오라클: 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공
  • 발생된 모든 오류 검출 가능
• 샘플링 오라클: 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공
  • 전수 테스트가 불가능한 경우 사용
• 추정 (Heuristic) 오라클: 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리
• 일관성 (Consistent) 오라클: 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인

 

소스 코드 품질 분석 도구

• 정적 (Static) 분석 도구: 작성한 소스 코드 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인
  • pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
• 동적 (Dynamic) 분석 도구: 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석
  • Avalanche, Valgrind 등