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

01. 애플리케이션 테스트

     : 애플리케이션에 결함을 찾아내는 일련의 행위 또는 절차

     (요구사항 만족시키는지 확인하고 정확히 수행하는지 검증)

 

     # 필요성 : 예방 / 신뢰도 향상 / 새로운 오류 유입 예방 / 최소한의 시간과 노력으로 많은 결함 발견

     # 기본 원리 : 완벽한 테스트 불가능 / 결합 집중(파레토 법칙) / 살충제 패러독스 / 테스팅은 상황 의존 /

                       오류-부재의 궤변 / 테스트와 위험은 반비례 / 테스트의 점진적 확대 / 테스트의 별도팀 수행

        - 완벽한 테스트 불가능 : SW의 잠재적 결함은 줄일 수 있지만 없다고 증명할 수는 없음.

        - 결합 집중 : 개발자 특성이나 애플리케이션 기능적 특징 때문에 특정 모듈에 집중, 파레토 법칙 적용

           (파레토 법칙 : 애플리케이션의 20%에 해당하는 코드에서 전체 결함 80%가 발생)

        - 살충제 패러독스 : 동일한 테스트 케이스로 동일한 테스트 반복하면 더 이상 결함이 발견되지 않음.

           (테스트 케이스를 지속적으로 보완 및 개선해야 함)

        - 테스팅은 정황 의존 : SW 특징, 테스트 환경, 테스트 역량 등 정황에 따라 테스트 결과가 달라질 수 있음.

           (정황에 따라 테스트 다르게 수행)

        - 오류-부재의 궤변 : SW 결함을 모두 제거해도 요구사항을 만족시키지 못하면 SW 품질이 높다 할 수 없음.

 

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

 

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

     # 정적 테스트 : 프로그램 실행 X / 명세서나 소스코드 분석

     # 동적 테스트 : 프로그램 실행 O / SW 개발의 모든 단계에서 테스트

 

     테스트 기반에 따른 테스트

     # 명세 기반 테스트 : 사용자 요구사항에 대한 명세(동등 분할, 경계값 분석 등)

     # 구조 기반 테스트 : SW 내부 논리 흐름에 따라(구문 기반, 결정 기반, 조건 기반, 결정 기반 등)

     # 경험 기반 테스트 : 테스터의 경험 기반(에러 추정, 체크리스트, 탐색적 테스팅)

 

     시각에 따른 테스트

     # 검증 테스트 : 개발자 시각 / 제품의 생산 과정 / 명세서대로 완성됐는지 테스트

     # 확인 테스트 : 사용자 시각 / 생산된 제품의 결과 / 사용자 요구사항대로 정상적 동작하는지 테스트

 

     목적에 따른 테스트

     # 회복 테스트 : 올바르게 복구되는지

     # 안전 테스트 : 불법적 침입으로 보호할 수 있는지

     # 강도 테스트 : 과부하시에도 정상적 실행되는지

     # 성능 테스트 : 실시간 성능, 전체적인 효율성 테스트 / 응답시간, 처리량

     # 구조 테스트 : 내부의 논리적 경로, 소스 코드 복잡도 평가

     # 회귀 테스트 : 변경 또는 수정된 코드에 새로운 결함 없는지

     # 병행 테스트 : 변경된 SW와 기존 SW에 동일 데이터로 비교

 

03. 화이트박스 테스트

     : 원시코드의 논리적인 모든 경로 테스트 / 설계된 절차에 초점(구조적 테스트) / 초기 적용

 

     # 종류

     - 기초 경로 검사 : 논리적 복합성 측정

     - 제어 구조 검사 :

       (조건 검사: 논리적 조건 테스트 / 루프 검사: 반복 구조에 초점 / 데이터 흐름 검사: 변수의 정의, 변수 사용의 위치)

     # 검증 기준

     - 문장 검증 기준 : 모든 구문 한 번 이상 수행

     - 분기 검증 기준 : 모든 조건문 한 번 이상 수행

     - 조건 검증 기준 : 모든 조건문 조건이 True/False 한 번 이상 수행

     - 분기/조건 기준 : 모든 조건문 개별 조건식 결과가 True/False 한 번 이상 수행

 

04. 블랙박스 테스트

     : 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증(기능 테스트)

 

     # 종류

     - 동치 분할 검사 : 입력 자료에 초점(=동등 분할 기법)

     - 경계값 분석 : 동치 분할 기법 보완 / 중간값보다 경계값에 오류 확률↑

     - 원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황 분석 후 효용성 높은 케이스 선정

     - 오류 예측 검사 : 과거의 경험이나 감각으로 테스트 / 보충적 검사 기법(=데이터 확인 기법)

     - 비교 검사 : 동일한 테스트 자료 제공하여 동일한 결과 출력되는지

 

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

     : 요구사항 -> 분석 -> 설계 -> 구현 --> 단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트

       -----------SW 개발 단계-----------       ---------------------------테스트 단계---------------------------

 

     단위 테스트 : 모듈이나 컴포넌트에 초점

     # 구조 기반 테스트 : 화이트 박스 테스트 (제어흐름, 조건 결정)

     # 명세 기반 테스트 : 블랙 박스 테스트 (동등 분할, 경계값 분석)

 

     통합 테스트 : 단위 테스트 완료된 모듈 결합하여 완성 / 상호작용 오류 검사

 

     시스템 테스트 : 완벽하게 수행되는지 / 실제 사용 환경과 유사하게

     # 기능적 요구사항 : 명세서 기반(블랙박스 테스트)

     # 비기능적 요구사항 : 구조적 요소(화이트박스 테스트)

 

     인수 테스트 : 요구사항 충족하는지 / 사용자가 직접 테스트

     # 사용자 인수 테스트 : 시스템 사용 적절성 여부 확인

     # 운영상 인수 테스트 : 시스템 인수 시 수행

     # 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지

     # 규정 인수 테스트 : 규정에 맞게 개발되었는지

     # 알파 테스트 : 사용자가 개발자 앞에서

     # 베타 테스트 : 최종 사용자가 여러 사용자 앞에서

 

06. 통합 테스트

     비점진적 통합 방식 : 단계적 절차 X (빅뱅 통합 테스트 방식 / 규모↓ / 단시간 / 오류 발견 및 수정 어려움

     점진적 통합 방식 : 모듈 단위 단계적 통합 / 오류 수정 용이 / 완전한 테스트 가능성↑

     # 하향식 통합 테스트 : 길이 우선 통합법, 넓이 우선 통합법

     (주요 제어 모듈의 종속 모듈은 스텁으로 대체 -> 하위 모듈 스텁 하나씩 실제 모듈로 교체

       -> 모듈 통합 때마다 테스트 ->  회귀 테스트 실시)

     # 상향식 통합 테스트 : 스텁 필요 X, But 종속 모듈 그룹인 클러스터 필요

     (클러스터로 결합 -> 더미 모듈인 드라이버 작성 -> 클러스터 단위로 테스트

      -> 클러스터는 상위로 이동, 결합, 드라이버는 실제 모듈로 대체)

             [드라이버]                                   [스텁]

     상위 모듈 X, 하위 모듈 O            상위 모듈 O, 하위 모듈 X

           상향식 테스트                            하향식 테스트

                  M1                                         M1

              ↗      ↖                                  ↗     ↖  

            D1         D2                             M2        S3

        ↗     ↖    ↗    ↖                      ↗    ↖          ↖

      M2      M3 M4      M5                M4      S5          S6

   하위 모듈/상위 모듈 인터페이스             가짜 모듈 역할

         본래 모듈로 교체                     드라이버보다 작성 쉬움

 

     # 혼합식 통합 테스트 (=샌드위치식 통합 테스트 방법)

     : 하위 수준 ->  상향식 통합 / 상위 수준 -> 하향식 통합 최적 테스트 지원

     # 회귀 테스팅

     : 이미 테스트 된 프로그램의 테스팅을 반복

 

07. 애플리케이션 테스트 프로세스

     : 테스트 계획 -> 테스트 분석 및 디자인 -> 테스트 케이스 및 시나리오 작성 ->

          테스트 수행 -> 테스트 결과 평가 -> 결함 추적 및 관리

     

08. 테스트 케이스

     : 명세 기반 테스트의 설계 산출물에 해당 (오류 방지 / 인력,시간 낭비↓ / 시스템 설계 시 작성)

       테스트 계획 검토 및 자료 확보 -> 위험 평가 및 우선 순위 결정 -> 테스트 요구사항 정의

          -> 테스트 구조 설계 및 테스트 방법 결정 -> 테스트 케이스 정의 -> 테스트 케이스 타당성 확인 및 유지보수

 

09. 테스트 시나리오

     : 여러개의 테스트 케이스들을 묶은 집합 / 구체적 절차 명세한 문서

 

10. 테스트 오라클

     : 테스트 결과 올바른지 판단 / 참 값 대입 후 비교

     

     # 특징 : 제한된 검증 / 수학적 기법 / 자동화 기능

     # 종류 : 참 오라클(모든 오류 검출) / 샘플링 오라클(특정 몇몇 입력값) /

                추정 오라클(특정 몇몇 결과 제공 나머지 추정) / 일관성 검사 오라클(수행 전·후 동일한지)

 

11. 테스트 자동화 도구 유형

     : 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구 적용

     (휴먼 에러↓ / 품질↑ / 정확성 유지)

 

     # 장점 : 인력 및 시간↓ / 향상된 품질 / 일관성 / 객관적 / 결과의 다양한 표시 / 정밀 테스트

     # 단점 : 교육 및 학습 필요 / 시간, 비용, 노력, 필요 / 고가의 추가 비용

     # 유형

     - 정적 분석 도구 : 프로그램 실행 X

     - 테스트 실행 도구 : 스크립트 언어 사용

     - 성능 테스트 도구 : 가상의 사용자

     - 테스트 통제 도구 : 형상 관리 도구, 결함 추적/관리 도구

     - 테스트 하네스 도구 : 시뮬레이션

     (테스트 드라이버 / 테스트 스텁 / 테스트 슈트 / 테스트 케이스 / 테스트 스크립트 / 목 오브젝트)

 

12. 결함 관리

     : 설계와 다르거나 다른 결과 발생

       결함 관리 계획 -> 결함 기록 -> 결함 검토 -> 결함 수정 -> 결함 재확인

          -> 결함 상태 추적 및 모니터링 활동 -> 최종 결함 분석 및 보고서 작성

 

     # 결함 상태 추적 : 결함 분포(특성 속성에 해당하는 결함 수) / 결함 추세(결함 수의 추이 분석)

                              / 결함 에이징( 지속되는 시간)

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

     # 결함 분류 : 시스템 결함 / 기능 결함 / GUI 결함 / 문서 결함

     # 결함 심각도 : High(진행 X) / Medium(시스템 스름에 영향을 미침) / Low(영향 X)

     # 결함 우선 순위 : 결정적 / 높음 / 보통 / 낮음

     # 결함 관리 도구 : Mantis(단위별 작업 내용 기록) / Trac(결함 통합) / Redmin / Bugzilla(지속적)

     * Fixed(고정) : 개발자가 필요한 변경 작업을 수행하여 결함 수정 작업을 완료한 상태

 

13. 애플리케이션 성능

     : 최소한의 자원으로 최대한 기능 신속히 처리 (처리량 / 응답시간 / 경과시간 / 자원사용률)

 

     - 성능 테스트 도구 : JMeter, LoadUI, Open STA

     - 시스템 모니터링 도구 : Scouter, Zabbix

 

14. 소스 코드 최적화

     : 나쁜 코드 배제, 클린 코드 작성

 

    작성 원칙 : 가독성 / 단순성 / 의존성 배제 / 중복성 최소화 / 추상화

    소스코드 최적화 유형 : 클래스 분할 배치(응집도↑, 크기↓) / Loosely Coupled(인터페이스 이용 의존성↓)

                                       / 코딩형식 준수 / 좋은 이름 사용 / 적절한 주석문 사용

    소스 코드 품질 분석 도구

    # 정적 분석 도구 : 프로그램 실행 X / 개발 초기 / 동적으로 어려운 결함 찾기

       (pmd, cppcheck, ccm, checkstyle)

    # 동적 분석 도구 : 프로그램 실행 O

       (Avalanche, Valgrind)