정보처리기사 실기 7장 애플리케이션 테스트 관리

애플리케이션 테스트

애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차.

• Validation (확인): 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 (사용자 위주)
• Verification (검증): 개발된 소프트웨어가 기능을 정확히 수행하는지 (개발자 위주)

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

• 완벽한 소프트웨어 테스팅은 불가능함
• 결함 집중: 결함은 보통 특정 모듈에 집중. 파레토 법칙 (애플리케이션의 20퍼센트에서 80퍼센트의 결함이 발견)
• 살충제 패러독스 (Pesticide Paradox): 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않음. -> 테스트 케이스를 지속적으로 보완 및 개선해주어야 함.
  정황(Context) 의존: 정황에 따라 테스트를 다르게 수행해야 함
  오류-부재의 궤변 (Absence of Errors Fallacy): 소프트웨어에 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 sw의 품질이 높다고 말할 수 없다.

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

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

• 정적 테스트: 프로그램을 실행 X 명세서나 코드를 대상으로 분석하는 테스트 (워크 스루, 인스펙션, 코드 검사 등)
  -> 개발 초기에 결함을 발견할 수 있어 개발 비용을 낮추는 데 도움
  

워크 스루: 개발자의 작업 내역을 개발자가 모집한 전문가들이 검토. 오류의 조기 검출을 목표.
인스펙션: 워크 스루의 발전된 형태. 개발 단계에서 산출된 결과물의 품질을 평가.

• 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트. 소프트웨어 개발의 모든 단계에서 테스트를 수행가능. (블랙박스 테스트, 화이트박스 테스트)

2. 테스트 기반에 따른 분류

• 명세 기반 테스트: 요구사항에 대한 명세를 테스트 케이스로 만들어 구현하고 있는지 확인
• 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인
• 경험 기반 테스트: 테스터의 경험을 기반으로 수행

3. 목적에 따른 분류

• 회복 테스트: 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인
• 안전 테스트: 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인
• 강도 테스트: 시스템이 과부하를 버티고 정상적으로 실행되는지를 확인
• 성능 테스트: 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단
• 구조 테스트: 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가
• 회귀 테스트: 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
• 병행 테스트: 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교

테스트 기법 따른 애플리케이션 테스트

화이트박스 테스트

• 개발자 중심
• Test 과정 초기 적용. 논리적 경로. 프로그램 흐름 점검
• 모듈 안 동작을 직접 관찰
• 모든 문장을 한 번 이상 실행

종류

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

블랙박스 테스트

• 기능, 사용자 중심
• 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
• 사용자의 요구사항 명세를 보면서 주로 구현된 기능을 테스트
• 인터페이스에서 실시
• 테스트 과정의 후반부에서 적용

종류

• 동치 분할 검사: 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사. 입력 데이터의 영역을 유사한 도메인별로 유횻값 / 무횻값을 그룹핑하여 나누어서 검사
• 경계값 분석: 입력 조건의 경계값을 테스트 케이스로 선정.
• 원인-효과 그래프 검사: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 테스트 케이스를 선정.
• 오류 예측 검사: 과거의 경험이나 확인자의 감각으로 테스트.
• 비교 검사: 여러 버전의 프로그램에 동일한 테스트 자료를 제공하고 검사

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

소프트웨어 개발 단계: 요구사항 --> 분석 --> 설계 --> 구현 (요분설구)

테스트 단계: 단위 테스트 --> 통합 테스트 --> 시스템 테스트 --> 인수 테스트 (단통시인)

• 단위 테스트: 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트

• 통합 테스트: 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류, 결함을 찾음

• 시스템 테스트: 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검

• 인수 테스트: 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트 (알파테스트, 베타테스트..)

통합 테스트

• 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법.

• 비점진적 통합 방식: 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트. 단시간에 테스트 but 오류의 위치 파악이 힘듦. (ex) 빅뱅 테스트.

• 점진적 통합 방식: 모듈 단위로 단계적으로 통합하며 테스트. 오류 수정 용이, 인터페이스 오류 테스트의 완전성 높음. (ex)하향식, 상향식, 혼합식 통합 방식.

하향식 통합 테스트: 프로그램의 상위 모듈 -> 하위 모듈 방향으로 통합하며 테스트.
-깊이 우선 통합법, 넓이 우선 통합법
-테스트 초기부터 사용자에게 시스템 구조를 보여줄 있음.
-주요 제어 모듈은 작성된 프로그램 사용. 모르는 모듈들은 스텁(Stub)으로 대체.
-모듈이 통합될 때 마다 테스트 실시.
-새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트 실시.

상향식 통합 테스트: 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트.
-하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster)가 필요.
-상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버(Driver) 작성
-통합된 클러스터 단위로 테스트.

회귀 테스트: 이미 테스트된 프로그램의 테스팅을 반복하는 것

인수테스트

사용자 인수 테스트: 사용자가 시스템 사용의 적절성 여부를 확인
운영상 인수 테스트: 시스템 관리자가 시스템 인수 시 수행
계약 인수 테스트: 계약상의 인수/검수 조건을 준수하는지 확인
규정 인수 테스트: 소프트웨어가 정부 지침, 법규, 규정 등에 맞게 개발되었는지 확인
알파 테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트
베타 테스트: 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트

테스트 케이스 / 테스트 시나리오 / 테스트 오라클

• 테스트 케이스 : SW가 사용자 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서

• 테스트 시나리오: 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합

• 테스트 오라클: 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교

  • 참 오라클: 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클. 발생한 모든 오류를 검출할 수 있다.
  • 샘플링 오라클: 특정 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클.
  • 추정 오라클: 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공, 나머지 입력 값들에 대해서는 추정으로 처리
  • 일관성 검사 오라클: 애플리케이션의 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인.

테스트 자동화 도구

• 테스트 자동화: 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현 (쉽고 효율적으로 테스트 o)

• 테스트 하네스 도구 (Test Harness Tools): 테스트를 지원하기 위해 생성된 코드와 데이터

<테스트 하네스 도구>
-테스트 드라이버: 테스트 대상의 하위 모듈을 호출, 파라미터 전달, 모듈 테스트 수행 후의 결과를 도출
-테스트 스텁: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행
-테스트 슈트: 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
-테스트 스크립트: 자동화된 테스트 실행 절차에 대한 명세서
-목 오브젝트: 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체.

결함 관리

• 결함 (Fault): 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것

• 결함 추적 순서

결함 등록 --> 결함 검토 --> 결함 할당 --> 결함 수정 --> 결함 조치 보류 --> 결함 종료 --> 결함 해제

• 결함 관리 측정 지표

결함 분포: 모듈 or 컴포넌트의 특정 속성에 해당하는 결함 수 측정
결함 추세: 테스트 진행 시간에 따른 결함 수 추이 분석
결함 에이징: 특정 결함 상태로 지속되는 시간 측정

애플리케이션 성능 분석

• 처리량 (Throughput): 일정 시간 내에 애플리케이션이 처리하는 일의 양

• 응답 시간 (Response Time): 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간

• 경과 시간 (Turn Around Time): 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간

• 자원 사용률 (Resource Usage): 애플리케이션이 의뢰한 작업을 처리하는 동안의 자원 사용률

애플리케이션 성능 개선

• 클린 코드 (Clean Code): 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순 명료한 코드.

• 나쁜 코드 (Bad Code): 프로그램의 로직이 복잡하고 이해하기 어려운 코드.

• 클린 코드 작성 원칙 : 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화

• Loosely Coupled (느슨한 결합): 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화

참고
https://jooona.tistory.com/125
https://sujl95.tistory.com/51