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

2021 시나공 정보처리기사 실기책 참고

주의! 중요도가 낮은 항목(C, D)은 일부 제외

1. 애플리케이션 테스트 – B

• 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
• 고객의 요구사항을 만족시키는지 확인(Validation, 사용자 입장)
• 소프트웨어가 기능을 정확히 수행하는지 검증(Verification, 개발자 입장)

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

• 완벽한 테스트 불가능
• 파레토 법칙 : 20%에 해당하는 코드에서 전체 결함의 80%가 발견됨
• 살충제 패러독스 : 동일한 테스트케이스로 반복하면 더 이상 결함이 발견되지 않음
• 오류-부재의 궤변 : 결함을 모두 제거해도 요구사항을 만족하지 못하면 품질이 높다고 할 수 없음
• 테스팅은 정황 의존 : 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함
• 테스트와 위험은 반비례
• 테스트의 점진적 확대
• 테스트의 별도 팀 수행

2. 애플리케이션 테스트의 분류 – B

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

• 정적 테스트
  • 명세서나 소스 코드를 대상으로 분석
  • 워크스루, 인스펙션, 코드 검사 등
• 동적 테스트
  • 프로그램을 실행하여 오류를 찾는 테스트
  • SW 개발의 모든 단계에서 수행
  • 블랙박스 테스트, 화이트박스 테스트

- 테스트 기반에 따른 테스트

• 명세 기반 테스트
  • 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인
  • 동등 분할, 경계 값 테스트
• 구조 기반 테스트
  • 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인
  • 구문 기반, 결정 기반, 조건 기반
• 경험 기반 테스트
  • 유사 SW나 기술 등에 대한 테스터의 경험을 기반으로 수행
  • 에러 추정, 체크 리스트, 탐색적 테스팅

- 시각에 따른 테스트

• 검증 테스트
  • 개발자의 시각에서 테스트
• 확인 테스트
  • 사용자의 시각에서 테스트

- 목적에 따른 테스트

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

3. 테스트 기법에 따른 애플리케이션 테스트 – A

- 화이트박스 테스트

• 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법

- 화이트박스 테스트의 종류

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

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

• 문장 검증 기준 : 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계
• 분기 검증 기준 : 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계
• 조건 검증 기준 : 모든 조건문에 대해 조건이 True, False인 경우가 한 번 이상 수행되도록 설계
• 분기/조건 기준 : 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True, False인 경우가 한 번 이상 수행되도록 설계

- 블랙박스 테스트

• 각 기능이 완전히 작동되는 것을 입증하는 테스트
• 요구사항 명세서를 보면서 테스트
• 구현된 기능을 테스트
• SW 인터페이스를 통해 실시

- 블랙박스 테스트의 종류

• 동치 분할 검사
  • 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트
  • 동등 분할 기법이라고도 함
• 경계값 분석
  • 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용
• 원인-효과 그래프 검사
  • 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사
• 오류 예측 검사
  • 경험이나 확인자의 감각으로 테스트
• 비교 검사
  • 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트

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

• 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
• V-모델 : 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것

- 단위 테스트

• 모듈이나 컴포넌트에 초점을 맞춰 테스트
• 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선 수행
• 주로 구조 기반 테스트 시행

- 통합 테스트

• 단위 테스트가 완료ㅚㄴ 모듈들을 결합하여 하나의 시스템으로 완성시키는 테스트
• 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사

- 시스템 테스트

• 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
• 기능적 요구사항과 비기능적 요구사항으로 구분하여 각각을 만족하는지 테스트

- 인수 테스트

• 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
• 개발한 SW를 사용자가 직접 테스트
• 사용자 인수 테스트
• 운영상의 인수 테스트
• 계약 인수 테스트
• 규정 인수 테스트
• 알파 테스트
  • 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트
  • 통제된 환경에서 실행
• 베타 테스트
  • 사용자가 여러 명의 사용자 앞에서 행하는 테스트
  • 실업무를 가지고 사용자가 직접 테스트

5. 통합 테스트 – A

• 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트
• 비점진적 통합 방식
  • 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트
  • 빅뱅 통합 테스트
• 점진적 통합 방식
  • 모듈 단위로 단계적으로 통합하면서 테스트
  • 하향식, 상향식, 혼합식 통합 테스트

- 하향식 통합 테스트

• 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
• 주요 제어 모듈의 종속 모듈은 스텁으로 대체

- 상향식 통합 테스트

• 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
• 하위 모듈들을 클러스터로 결합
• 더미 모듈인 드라이버 작성

- 혼합식 통합 테스트

• 하위 수준에서는 상향식, 상위 수준에서는 하향식 통합 사용
• 샌드위치식 통합 테스트

- 회귀 테스팅

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