애플리케이션 테스트 수행

애플리케이션 테스트 수행하기

• 애플리케이션 테스트 수행하기
  • 테스트 수행
    • 애플리케이션 테스트의 기본 원리
    • 애플리케이션 테스트의 개념
    • 테스트의 개요
      • 단위 테스트
      • 통합 테스트
      • 시스템 테스트
      • 인수 테스트
    • 테스트 기반에 따른 테스트 종류
    • 테스트 자동화 도구
      • 배경
      • 테스트 자동화의 개념
      • 테스트 도구의 장점
      • 테스트 도구의 단점
      • 테스트 자동화 수행 시 고려사항
      • 테스트 도구 평가방법 및 요소
      • 테스트 단계를 지원하는 도구의 종류
      • 테스트 수행 절차
  • 결함 관리
    • 결함의 정의
    • 결함 관리 프로세스
      • 1. 결함 관리 계획
      • 2. 결함 기록
      • 3. 결함 검토
      • 4. 결함 수정
      • 5. 결함 재확인
      • 6. 결함 상태 추적 및 모니터링 활동
      • 7. 최종 결함 분석 및 보고서 작성
    • 결함의 상태 및 추적
      • 1. 결함 등록 (Open)
      • 2. 결함 검토 (Reviewed)
      • 3. 결함 할당 (Assigned)
      • 4. 결함 수정 (Resolved)
      • 5. 결함 조치 보류 (Deferred)
        • 6. 결함 종료 (Closed)
        • 7. 결함 해제 (Clarified)
    • 결함 분류
      • 시스템 결함
        • 비정상적인 종료/중단
        • 응답 시간 지연
        • 데이터베이스 에러
      • 기능 결함
        • 요구사항 미반영/불일치
        • 부정확한 비즈니스 프로세스
        • 스크립트 에러
        • 타 시스템 연동 시 오류
      • GUI 결함
        • 응용 프로그램 UI 비일관성
        • 부정확한 커서/메시지
        • 데이터 타입의 표시 오류
      • 문서 결함
    • 결함 심각도
      • High
      • Medium
      • Low
    • 결함에 대한 원인과 개선 방안 도출
      • 1. 발생한 결함에 대하여 결함 원인을 분석
      • 2. 분석한 원인을 근거로 개선 방안을 도출
• 애플리케이션 결함 조치하기
  • 조치 우선순위 결정
    • 소프트웨어 테스트 기법
      • 단위 테스트 기법
      • 통합 테스트 기법
        • 1. 테스트 설계 기법
        • 2. 테스트 설계 방법
      • 시스템 테스트 기법
        • 부하 및 성능테스트
        • 장애 복구 테스트
        • 보안 테스트
      • 인수 테스트 기법
    • 결함 관리의 이해
      • 결함 관련 용어
        • 결함의 판단 기준
  • 결함 조치 관리
    • 프로그램 코드 검토 기법
      • 소프트웨어 인스펙션 ( Software Inspection ) 의 개요
      • 코드 인스펙션의 프로세스와 수행 내용
      • 인스펙션과 워크스루 비교
  • 형상 관리 및 구성 요소
    • 소프트웨어 형상 관리의 정의
    • 기준선과 소프트웨어 형상 항목
      • 기준선
      • 소프트웨어 형상 항목 ( SCI )
    • 형상 관리의 주요 활동
      • 형상 관리 기능
      • 형상 식별
      • 버전 관리
      • 변경 통제에 대한 업무별 활동

테스트 수행

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

1. 완벽한 테스트 불가능

2. 결함 집중 ( 파레토 법칙 ): 애플리케이션의 20% 에 전체 결함의 80% 가 집중되어 있다.

3. 살충제 패러독스 : 동일한 테스트케이스로 동일한 테스트를 반복하면 더 이상 결함이 반복되지 않는 현상

4. 테스팅 정황 의존 : 소프트웨어의 특징, 테스트 환경, 테스터의 역랑 등의 정황에 따라 테스트 결과가 달라질 수 있다.

5. 오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도 사용자의 요구 사항을 만족시킬 수 없으면 소프트웨어의 품질이 높다고 할 수 없다.

6. 테스트와 위험은 반비례한다.

7. 테스트의 점진적 확대

8. 테스트의 별도 팀 수행

---

애플리케이션 테스트의 개념

• Validation : 사용자 입장 에서 개발한 소프트웨어가 고객의 요구사항에 맞게 구현되었는지를 확인하는 것
• Verification : 개발자 입장에서 개발한 소프트웨어 명세서에 맞게 만들어졌는지 점검하는 것

---

테스트의 개요

테스트 과정에 필요한 역할은 소프트웨어 아키텍트 와 테스트 매니저 이다.

단위 테스트

컴포넌트 또는 모듈 테스트, 개발자가 개발 과정 중 수행
테스트 가능한 단위로 작게 분리된 소프트웨어 내에서 결함을 찾고 기능을 점검하는 행동
구조적 테스트, 기능성 테스트, 리소스 관련 테스트, 강건성 테스트 등 특정 비기능성 테스트 포함
컴포넌트 명세, 소프트웨어 상세 설계, 데이터 모델 명세 등을 이용하여 테스트

테스트 방법	테스트 내용	테스트 목적
구조 기반	프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트	제어흐름, 조건 결정
명세 기반	목적 및 실행 코드 기반의 실행을 통한 블랙박스 테스트	동등분할, 경계값 분석

통합 테스트

모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 테스트, 하나의 프로세스가 완성된 경우 부분적으로 통합 테스트 수행
컴포넌트 간 인터페이스 테스트를 하고 운영체제, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 각각 다른 부분과 상호 연동이 정상적으로 작동하는지 여부를 테스트

• 빅뱅 방식 ( Big Bang ) : 모듈을 한 번에 결합하여 수행, 소규모 프로그램이나 프로그램의 일부를 테스트하는데 적합하다.
• 상향 방식 ( Bottom up ) : 시스템 모듈의 계층 구조의 하위 모델부터 시작하여 상향 모듈로 통합하는 방법, 각각의 기능이 정밀하게 수행되는지 테스트할 때 적합하다. 드라이버가 필요
• 하향 방식 ( Top down ) : 상위 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법, 모델 간의 인터페이스와 시스템의 동작이 정상적으로 동작되는지 빠르게 파악할 때 적합하다. 스텁이 필요
• 샌드위치 방식 : 상향식과 하향식의 장점을 이용하는 방식, 대규모 프로젝트에 적합, 병렬 테스트가 가능하고 시간이 절약, 스텁과 드라이버 모두 필요
• Central, Collaboration, 레이어 통합 등

스텁 ( Stub ) : 테스트 중인 모듈이 호출하는 다른 모듈을 일시적으로 대체하는 모듈
드라이버 ( Driver ) : 모듈이나 시스템을 제어하거나 호출하는 모듈을 대체하는 모듈

시스템 테스트

통합된 단위 시스템의 기능이 시스템적으로 정상적으로 수행되는지 테스트, 성능 테스트 및 장애 테스트 포함
시스템을 완벽하게 검사하기 위한 목적 또는 성능 목표를 가지고 테스트한다.
실제의 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능, 비기능적인 요구 사항 등이 완벽하게 수행되는지 테스트

테스트 방법	테스트 내용
기능적 요구사항	요구사항 명세서, 비즈니스 절차, 유스케이스 등 명세서 기반의 블랙박스 테스트
비기능적 요구사항	성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템의 메뉴 구조, 웹페이지의 네비게이션 등의 구조적 요소에 대한 화이트박스 테스트

인수 테스트

최종 사용자와 업무의 이해관계자 등이 수행하는 테스트
시스템의 일부 또는 특정한 비기능적 특성에 대해 인수테스트를 통해 확인

테스트 종류	테스트 내용
사용자 인수 테스트	비즈니스 사용자가 시스템 사용의 적절성 여부를 확인
운영상의 인수 테스트	시스템 관리자가 시스템 인수 시 수행하는 테스트 활동으로 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인
계약 인수 테스트	계약 상의 인수/점검 조건을 준수하는지 여부를 확인
규정 인수 테스트	정부 지침, 법규, 규정 등 규정에 맞게 개발하였는지 확인
알파 테스트	개발하는 조직 내 잠재 고객에 의해 테스트 수행
베타 테스트	실제 환경에서 고객에 의해 테스트 수행

---

테스트 기반에 따른 테스트 종류

테스트 종류	테스트 내용	세부 기법
구조기반	소프트웨어 내부의 논리 흐름에 따른 테스트 케이스 작성 및 결함 발견 활동	구문 기반, 결정 기반, 조건 기반, 조건결정 기반, 변경 조건 기반, 멀티 조건 기반 커버리지
명세기반	사용자의 요구사항 분석서에 주어진 명세를 빠뜨리지 않고 테스트 케이스화	동등 분할, 경계값 분석, 결정 테이블, 상태 전이 테스팅, 유스케이스 테스팅
경험기반	유사 소프트웨어나 기술에서의 테스터의 경험, 직관, 기술, 능력을 바탕으로 하는 테스트 기법	탐색적 테스팅, 리스크 기반 테스팅

---

테스트 자동화 도구

배경

테스트의 정확성을 유지하면서 시간과 비용을 줄일 수 있는 자동화 도구가 매우 중요

테스트 자동화의 개념

사람이 하던 반복적인 테스트 절차를 자동화 도구를 활용하여 준비, 구현, 수행, 분석 등을 스크립트 형태로 구현함으로써, 시간과 인력 투입의 부담을 최소화하면서 운영 중인 시스템의 모니터링 또는 UI가 없는 서비스의 경우 정밀한 테스트가 가능하도록 하는 것

테스트 도구의 장점

1. 테스트 인력과 시간을 최소화
2. 향상된 요구사항 정의, 성능 및 스트레스 테스트, 품질 측정을 최적화
3. 빌드확인, 회귀, 다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트의 향상된 테스트 품질을 보장

테스트 도구의 단점

1. 도입 후 테스트 도구 전문가를 양성 또는 고용이 필요, 초기 프로세스 적용에 대한 시간, 비용, 노력에 대한 추가 투자가 필요
2. 비공개 상용 소프트웨어의 경우 고가이며, 인력과 교육에 대한 유지관리 비용이 높음

테스트 자동화 수행 시 고려사항

1. 테스트 절차를 고려하여 재사용 및 측정이 불가능한 테스트 프로그램은 제외
2. 설계기준을 고려하여 반복적인 빌드에서 스크립트 재사용성이 가능해야 한다.
3. 도구의 한계성으로 모든 수동 테스트 과정을 자동화할 수 있는 도구는 없다. 따라서 용도에 맞는 적절한 도구 사용이 필요하다.
4. 도구 환경 설정과 도구 습득 기간을 고려하여 프로젝트 지연을 방지해야 한다.
5. 테스트 엔지니어의 적절한 투입 시기와 계획을 프로젝트 초기에 수립해야 한다.

테스트 도구 평가방법 및 요소

1. 테스트 도구 평가방법
   테스트 도구가 지원하는 모든 사항에 대해 종류별로 나열하고 기록해야 한다.
   또한, 테스트에 해당하는 요소에 대한 목표 또는 평균값을 설정하고 설정된 기준 으로 평가한다. 비용을 최소화하기 위해 필수적인 몇 가지 요소만을 고려해야 할 경우 최소한의 요구사항을 만족하는 도구를 선정

2. 테스트 도구 평가요소
   테스트 도구의 사용 편의성, 다중 사용자 접속, 결함 추적, 도구 기능성, 보고 능력, 성능 및 스트레스 테스트, 버전 제어, 테스트 계획과 관리, 가격, 테스트 도구 제조사의 지원 능력 등의 객관적이고 수치화되는 항목을 이용하여 평가

테스트 단계를 지원하는 도구의 종류

간트차트 : 프로젝트 일정관리를 위한 바(bar)형태의 도구

테스트 수행 절차

1. 테스트 계획서 확인

1. 테스트 목적과 범위 확인.

   테스트 목적은 정보시스템 개발 중에 프로그램 기능의 정확성 및 완전성을 검증하고, 예외 상황 처리의 적절성, UI 및 개발 표준 준수 여부를 확인하여 시스템 품질을 확보하기 위함

   테스트 전략 문서: 정렬(Align)된 테스트의 목적이 상세하게 기술되어 있다. 테스트 전략 문서가 없는 경우에는 프로젝트의 품질 목표 가운데 테스트를 통해 달성 여부를 평가할 수 있는 항목을 기술하고, 그 외에 사용자 요구사항에 대한 테스트를 통해 특별히 요구되는 목적을 확인한다.

2. 테스트 실행 계획을 확인

   시작 기준과 종료 기준을 확인한다
   테스트 수행 절차를 확인한다

   
3. 테스트 케이스를 확인

   테스트 시나리오를 확인하고, 테스트 케이스를 확인

4. 테스트 케이스 데이터를 확인

5. 테스트 환경을 확인

2. 기능 단위 테스트 수행

1. 서버모듈, 화면 모듈, 데이터입출력, 인터페이스 등의 연계를 통해 업무별 기능을 정의한다.

   1. 서버 모듈 정의 : 화면 모듈과 인터페이스에서 받은 데이터를 이용하여 업무 처리를 수행한다
   2. 화면 모듈 정의 : 화면 설계서와 사용자의 요구사항에 따라 화면에서 등록, 수정, 삭제, 조회된 내용 확인
   3. 데이터 입출력 정의 : 화면 모듈, 인터페이스, 서버 모듈에서 전달받은 데이터를 가공 및 저장 등
   4. 인터페이스 : 타 시스템 인터페이스에 따른 데이터 및 엔티티 변환의 정확성 확인
2. 기능 단위 테스트를 통합하여 테스트 항목을 정의
3. 단위테스트 수행
   1. 테스트 환경 관련 사항 준비
   2. 입출력 확인
   3. 산술식 또는 단순 계산 결과 확인
   4. 연동 시스템 확인
   5. 배치처리와 인터페이스 확인
   6. 인쇄 및 보고서 확인
4. 통합테스트 수행
   1. 통합 테스트 환경 구성
   2. 테스트 실행 및 결과 기록
   3. 통합 테스트 종료 여부 평가
5. 성능 테스트 수행
   1. 성능 테스트 계획서 확인
   2. 성능 테스트 수행 후 결과 보고서 작성

---

결함 관리

결함의 정의

1. 프로그램과 명세서의 차이, 업무 내용 불일치
2. 기대 결과와 실제 관찰 결과 간의 차이
3. 시스템이 사용자가 기대하는 타당한 기대치를 만족시키지 못할 때 변경이 필요한 모든 것

결함 관리 프로세스

1. 결함 관리 계획

전체 프로세스에서 결함관리에 대한 일정, 인력, 업무 프로세스를 확보하여 계획을 수립한다

2. 결함 기록

테스터는 발견된 결함에 대한 정보를 결함관리 DB에 기록한다.

3. 결함 검토

등록된 결함에 있어서 주요 내용을 검토하고 결함을 수정할 개발자에게 전달한다.

4. 결함 수정

개발자는 할당된 결함의 프로그램을 수정한다.

5. 결함 재확인

테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행한다.

6. 결함 상태 추적 및 모니터링 활동

결함관리 팀장은 결함관리 데이터베이스를 이용하여 대시보드 또는 게시판 형태의 서비스를 제공한다.

7. 최종 결함 분석 및 보고서 작성

발견된 결함에 대한 내용과 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료한다.

결함의 상태 및 추적

1. 결함 등록 (Open)

테스터와 QA(품질관리) 담당자에 의해 결함이 처음 발견되어 등록되었지만, 아직 분석이 되지 않은 상태

2. 결함 검토 (Reviewed)

등록된 결함을 담당 모듈 개발자, 테스터, 프로그램 리더, 품질 관리(QA) 담당자와 검토하는 상태

3. 결함 할당 (Assigned)

결함의 영향 분석 및 수정을 위해 개발자와 문제 해결 담당자에게 할당된 상태

4. 결함 수정 (Resolved)

개발자에 의해 결함의 수정이 완료된 상태

5. 결함 조치 보류 (Deferred)

수정이 필요한 결함이지만 현재 수정이 불가능해서 연기된 상태,
우선순위, 일정 등을 고려하여 재오픈을 준비하는 상태

6. 결함 종료 (Closed)

발견된 결함이 해결되고 테스터와 품질관리(QA) 담당자에 의해 종료 승인을 한 상태

7. 결함 해제 (Clarified)

테스터, 프로그램 리더, 품질관리(QA) 담당자가 결함을 검토한 결과, 결함이 아니라고 판명된 경우

결함 분류

시스템 결함

비정상적인 종료/중단, 응답시간 지연, 데이터베이스 에러 등 주로 애플리케이션 환경과 데이터베잇 처리에서 발생하는 결함

비정상적인 종료/중단

특정 기능 실행 시 응용 프로그램의 작동 정지, 종료, 시스템 다운이 되는 경우

응답 시간 지연

응용 프로그램 작동 후 조회 또는 보고서 출력 시 지연되는 경우와 메모리 부족, 하드웨어와 소프트웨어의 비일관성으로 발생되는 경우

데이터베이스 에러

응용 프로그램 작동 후 사용자 데이터의 등록, 수정, 삭제, 조회가 정상적으로 작동하는 않은 경우

기능 결함

사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러, 타 시스템 연동 시 오류 등 기획, 설계, 업무 시나리오 단계에서 발생된 결함

요구사항 미반영/불일치

요구사항에 명시된 기능이 응용 프로그램에 구현되지 않은 경우와, 다르게 구현되어 작동하는 경우

부정확한 비즈니스 프로세스

기능 자체는 수행되나 내부 프로세스 로직의 문제로 부정확한 결과를 내는 경우

스크립트 에러

특정 기능 실행 시 웹 브라우저에서 스크립트 오류가 발생하는 경우

타 시스템 연동 시 오류

기존 시스템과의 연동을 통해 데이터를 주고받는 과정에서 오류가 발생하는 경우

GUI 결함

응용 프로그램의 UI 비일관성, 부정확한 커서/메시지, 데이터 타입의 표시 오류 등으로 사용자 화면 설계에서 발생된 결함

응용 프로그램 UI 비일관성

프로젝트에서 정의한 UI 표준과 상이하게 구현된 경우

부정확한 커서/메시지

커서의 위치가 입력 대상의 첫 번재 필드에 위치해 있지 않거나, 탭 시퀀스가 순차적으로 동작하지 않는 경우, 각 기능에서 제공하는 메시지 내용이 부정확한 내용을 보여주는 경우

데이터 타입의 표시 오류

입력 필드에 지정된 형식과 다르기 입력해도 저장이 되는 경우와 입력 필드에 유효하지 않은 데이터를 입력했을 때 오류가 나는 경우

문서 결함

사용자의 온라인/오프라인 매뉴얼의 불일치, 요구사항 분석서와 기능 요구사항의 불일치로 인한 불완전한 상태의 문서의 경우

결함 심각도

High

시스템이 중단되어 더 이상 프로세스를 진행할 수 없게 만드는 결함

• 시스템 핵심 요구사항 미구현
• 시스템 다운
• 장시간 시스템 응답 지연
• 시스템 복구 후 데이터 왜곡

Medium

시스템의 흐름에 영향을 미치는 결함

• 부정확한 기능
• 부정확한 업무 프로세스
• 데이터 필드 형식의 오류
• 데이터베이스 에러
• 보안 관련 오류

Low

시스템의 흐름에는 영향을 미치지 않는 결함이나 상황에 맞지 않는 용도와 화면 구성 결함

• 부정확한 GUI 및 메시지
• 에러 시 메시지 미출력
• 화면 상의 문법 / 철자 오류

---

결함에 대한 원인과 개선 방안 도출

테스트 수행 시 발견된 결함에 대한 원인을 유형별로 통합하고 분류
분류된 결함에 대해 통계적 분석 기법을 적용하여 분석하고 개선 방안을 도출

1. 발생한 결함에 대하여 결함 원인을 분석

1. 테스트 종류 후 결함 데이터 통합
2. 통합된 결함 데이터를 분석하여 유사한 결함 상태로 정리
3. 프로젝트 영역별로 결함 원인을 정의
   

4. 결함 종류를 식별하기 위한 원인 분석 도구 사용

파레토 다이어그램

1) 결함의 모든 요소를 목록으로 작성한다.
2) 결함과 관련된 요소들을 측정한다.
3) 결함 수가 가장 높은 순에서 낮은 순으로 작성한다.
4) 결함 항목에 대한 백분율을 계산한다.
5) 자료 값을 이용하여 각 범주를 나타내는 막대를 그린다.
6) 누적 백분율을 파레토 차트에 표시한다.

피시본 다이어그램

1) 결함의 주요 원인을 확인한다.
2) 결함의 잠재적 원인을 팀원들과 브레인스토밍한다.
3) 결함의 범주를 나누고 항목에 따라 잠재적 원인을 추가한다.
4) 팀원들과 질문을 계속하여 내용을 검증하고, 추가적인 내용을 더 제시하도록 한다.
5) 결함 항목을 검토하고 항목 중에서 가장 가능성이 높은 원인을 팀원들과 브레인스토밍 등의 방법으로 도출하여 작성한다.

5. 원인 분석 보고서 작성
   

2. 분석한 원인을 근거로 개선 방안을 도출

1. 프로젝트 진행에 영향을 주는 항목에 대해 결함 예방 조치 계획을 수립
2. 결함 예방 조치 수립
   
3. 모든 항목이 종결될 때까지 추적 관리를 수행
   
4. QA의 검토를 거쳐 제시된 의견을 전사 품질 관리 조직에게 전달

---

애플리케이션 결함 조치하기

조치 우선순위 결정

소프트웨어 테스트 기법

단위 테스트 기법

1. JUnit을 활용한 테스트

   Java 환경이라면 대부분 JUnit이라는 단위 테스트 프레임워크를 통해 단위 테스트를 할 수 있어야 한다.

2. Mock 테스트

• 단위 테스트 시 Mock 객체를 사용하여 테스트하는 기법
• 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해놓고 테스트
• 특정 모듈이나 기능이 완벽히 개발 완료되지 않은 상태에서도 진행 가능
• 테스트 더블 : 테스트 전용 객체, 테스트를 위해 실제 객체를 대신해서 사용되는 용어
  

통합 테스트 기법

주요 목적 : 전체 시스템이 통합 완료될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인하고, 하드웨어와 소프트웨어 구성 요소 간의 상호 작용을 테스트하는 것

1. 테스트 설계 기법

테스트 설계 : 개발된 소프트웨어나 시스템의 요구사항, 요구사항 명세서, 업무 구조, 시스템 구조 등을 기반으로 소프트웨어의 어떤 부분을 어떻게 접근하여 테스트할지에 대한 테스트 상황과 방법을 파악하는 것
테스트 구현 : 테스트 설계를 체계적으로 구체화시켜 테스트 케이스를 도출하고 작성하는 것
테스트 설계 방법 : 테스트 상황과 방법을 구체화시키기 위한 수단 및 도구

2. 테스트 설계 방법

시스템 테스트 기법

부하 및 성능테스트

동시접속으로 시스템에 많은 요청이 발생될 때 어떻게 가동되는지 확인하는 테스트

• 동시 이용자 수 : TPS 호출간격(응답시간(Sec)) 대기시간(Sec)
• 동시 단말 이용자 : PC 앞에 앉아서 시스템을 이용하는 이용자
• 액티브 이용자 : 동시에 같은 서비스나 업무를 실행하고 나서 응답을 기다리고 있는 이용자
• 처리량 : 단위 시간 당 처리하는 건수, 단위는 tps, tpm, tph 를 사용하고, 관점에 따라 두 가지 유형이 있으며 요청을 받는 입장에서 단위 시간 단 요청 건수와 단위 시간당 처리 건수로 구분되어 표현한다.
• 대기 시간 : 응답을 받은 직후부터 다음 명령 또는 호출할 때까지 사용자가 대기하는 시간

장애 복구 테스트

보안 테스트

인수 테스트 기법

최종 사용자가 요구한 기능이 제대로 반영되었는지, 인수 조건에 만족하는지를 테스트하는 기법

결함 관리의 이해

결함 관련 용어

• 에러 ( Error ) : 소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정호가한 결과, 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등
• 오류 ( Fault ) : 프로그램 코드 상에 존재하는 것, 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생한다.
• 실패 ( Failure ) : 정상적인 프로그램과 비정상적인 프로그램의 실행 결과의 차이를 의미, 프로그램 실행 중에 프로그램 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.
• 결합 ( Defect ) : 버그, 에러, 오류, 실패, 프로그램 실행에 대한 문제점, 프로그램 개선 사항 등의 전체를 포괄하는 용어

결함의 판단 기준

• 기능 명세서에 가능하다고 명시된 동작을 수행하지 않는 경우
• 기능 명세서에 불가능하다고 명시된 동작을 수행하는 경우
• 기능 명세서에 명시되어 있지 않은 동작을 수행하는 경우
• 기능 명세서에 명시되어 있지 않지만 수행해야 할 동작을 수행하지 않는 경우
• 테스터의 시각에서 볼 때 문제가 있다고 판단되는 경우

결함 조치 관리

프로그램 코드 검토 기법

소프트웨어 인스펙션 ( Software Inspection ) 의 개요

코드 인스펙션 ( Code Inspection ) 외에도 설계 및 설계 산출물까지 포괄하여 소프트웨어 인스펙션으로 부르기도 한다.

코드 인스펙션은 매우 효과적인 테스트 방법으로서 어떠한 다른 테스트 방법으로 대체할 수 없다. 상당히 시간이 필요한 작업이며, 통계에 따르면 인스펙션을 적절히 잘 수행하면 포함된 에러의 90%까지 찾아낼 수 있다.

코드 인스펙션의 프로세스와 수행 내용

(1) 코드 인스펙션 프로세스

(2) 코드 인스펙션 테스크별 수행 내용

인스펙션과 워크스루 비교

구분	인스펙션	워크스루
목적	결함 파악 및 제거	산출물 평가 및 개선
수행 조건	완성도가 기준 이상일 때	팀이나 관리자의 필요 시
결함 수정 여부	모든 결함은 제거되어야 함	저자 결정
변경 사항 검증	진행자가 재작업 결과 확인	저자 결정
검토자 인원	3 ~ 6명	2 ~ 7 명
참여자	동료	기술 전문가 및 동료
검토 인도자	교육받은 진행자	저자
검토 준비 여부	체크리스트를 이용한 검토	일반적으로 검토 준비하지 않음
검토 분량	상대적으로 적음	상대적으로 적음
검토 속도	상대적으로 느림	빠름
발표자	산출물에 의존도가 높은 사람	저자
지표 수집 여부	모든 검토자들이 기록함	하지 않음
보고서	결함 리스트 및 측정 지표	워크스루 보고서
데이터 측정 여부	필수	권장사항
체크리스트 사용 여부	사용함	사용하지 않음

형상 관리 및 구성 요소

소프트웨어 형상 관리의 정의

1. 소프트웨어 프로세스의 모든 출력물 정보
2. 컴퓨터 프로그램, 컴퓨터 프로그램 설명 문서, 데이터 등
3. 소프트웨어 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동

소프트웨어 형상 관리	소프트웨어 지원
소프트웨어 엔지니어링 프로젝트 게시에서 소프트웨어 소멸 시점까지의 활동	소프트웨어가 고객에게 인도되고 운영되는 시점에 발생하는 소프트웨어 엔지니어링 활동

기준선과 소프트웨어 형상 항목

기준선

변경을 통제하게 도와주는 기준선은 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕으로서, 정식의 변경 통제 절차를 통해서만 변경 가능하다

소프트웨어 형상 항목 ( SCI )

소프트웨어 형상과 개발 도구의 합성으로서, SCI는 개발 단계별로 기준선으로 기준으로 형상 항목을 관리한다.

형상 관리의 주요 활동

형상 관리 기능

형상 식별

소프트웨어 형상 항목에 대해 식별하고 고유한 이름을 부여하는 활동

버전 관리

변경 통제에 대한 업무별 활동