CSTS_FL-9 테스트실행 (4문제)

violet·2024년 5월 26일

CSTS_FL

목록 보기
9/11

28. 테스트환경구축


28-1. 테스트 환경 구축 개요

  • 테스트 환경 구축

    • 테스트 환경 요건 명세서에 명시된 각 테스트 환경 항목을 구축하는 작업
  • 테스트 데이터 준비

    • 테스트 데이터 요건 명세서에 명시된 테스트 데이터를 준비



28-2. 테스트 데이터 준비


테스트 데이터 요건 명세서에 명시된
요구사항을 충족할 데이터를 확보하여
테스트 케이스가 실행되도록 지원

  • 준비된 테스트 데이터가 주어진 요구사항을 충족하는지 검토

  • 테스트 데이터의 접근 방법

  • 테스트 데이터의 위치

  • 테스트 데이터의 접근 권한



28-3. 테스트 환경 구축

  • 테스트 환경 요건 명세서에 명시된 테스트 환경 항목을 구축하여 테스트 대상의 실행 환경 지원

    • 명시된 하드웨어 준비

    • 시스템 소프트웨어공존 소프트웨어 설치

    • 테스트 도구 설정

    • 환경 요건 명세서에 명시한 요구사항을 충족하는지 확인

  • 테스트 환경 요건 명세서에 명시한 준비 상황 기술이 아직 준비가 부족하다면
    그 원인을 기술하고 적용할 해결 방법, 예정 완료 일자 등으로 기술



28-4. 테스트 환경 구축 산출물


  • 산출물

    • 테스트 환경 준비 보고서

    • 테스트 데이터 준비 보고서



29 테스트실행



29-1. 테스트 실행 개요

  • 테스트 절차를 실행

  • 테스트 절차를 실행하였을 때
    테스트 대상의 실제 수행 결과와 예상 결과를 비교하여
    테스트 결과를 기록

    1. 주어진 테스트 절차 중에서 우선순위를 고려하여 테스트 절차를 선정

    2. 선택된 테스트 절차를 실행하여 관찰된 실제 결과와 예상 결과를 비교

    3. 테스트 실행 로그에 기록



29-2. 테스트 절차 선정


  • 우선순위 전략

    • 피처 집합 우선순위

    • 테스트 케이스 우선순위

    • 테스트 절차 우선순위

  • 테스트 완료 기준 전략

    • 테스트 완료 기준 달성에 가장 큰 기여를 할 수 있는 테스트 절차를 먼저 실행



29-3. 테스트 절차 실행


테스트 실행 주체는 테스트 레벨마다 다름.

  • 테스트 실행 주체

    • 컴포넌트 테스트는 개발자가 테스트

      • 테스트 환경 구축 비용을 줄이고, 정확하고 신속하게 테스트 결과를 이해 가능

      • 역할이 매우 중요한 모듈은 테스터가 참여하여 컴포넌트 테스트를 수행

    • 시스템 테스트는 테스터가 주도적으로 중요한 역할

    • 테스터가 수행하는 경우 더 전문적인 기술을 이용해서 객관적인 관점에서 체계적으로 테스트가 가능



29-4. 테스트 결과 비교

  • 각 테스트 케이스에 대하여
    예상 결과와 실행 결과를 비교

    • 예상 결과를 구체적으로 기술
    • 테스트 케이스에 따라서 비교될 결과는 화면뿐만 아니라
      소리, 진동, 파일, 데이터베이스 테이블, 네트워크 등의 다양한 형태
      • 비교 값의 형태에 따라서 적합하게 예상 결과를 정의



29-5. 테스트 실행 기록

  • 테스트 절차를 실행하는 과정에서 실제로 수행한 구체적인 작업과
    목격된 이벤트들을 시간대별로 기록한 로그 문서
  • 테스트 실행 로그



29-6. 테스트 실행 산출물

  • 테스트 실행 로그

  • 테스트 실행을 수행한 테스터와 테스트 컨텍스트 측면에서 테스트 대상, 테스트 환경 등을 설명

  • 시간대별로 실제 수행된 테스트 작업과 그 결과를 기술


30 결함보고


30-1. 결함 보고 개요


테스트 실행 활동에서
적절한 조치가 필요한 이슈를 발견하면
결함으로 보고

  • 결함 보고

    • 테스트 실행 로그 → 테스트 결과 분석(결함의 구체화, 고립화, 일반화) → 결함 기록 → 결함 보고서



30-2. 테스트 결과 분석


테스터는 테스트 절차 실행을 통하여 발견된 결함을 추가적으로 분석하여 결함 발생 상황을 더욱 명확하게 파악
결함 발생 상황이 구체적이고 명확히 정의되어야만 개발자가 효율적으로 해결 가능

  • 결함의 구체화
    • 개발자는 보고된 결함의 원인을 찾기 위하여 결함을 재연
    • 발견된 결함을 재연(Reproduce) 가능할 정도로
      결함 관련 테스트 데이터, 테스트 절차, 테스트 환경
      명확히 파악
  • 결함의 고립화
    • 결함의 발생에 직접적인 영향을 미치는 구체적인 상황이 효과적인 디버깅에 도움을 줄 수 있음.
    • 어떤 요소가 결함 발생에 영향을 미치는지 체계적이고 자세하게 분석
  • 결함의 일반화
    • 결함의 발생에 영향을 주는 요소를 최대한 일반적으로 기술



30-3. 결함 기록


테스트 결과 분석을 바탕으로 식별된 결함은
결함 보고서에 기록

  • 결함 보고서 = 버그 보고서 = 테스트 사건 보고서 = 문제 보고서

  • 결함 컨텍스트

    어떤 상황에서 해당 결함이 식별되었는지
    재연 가능하게 기술

    • 개별 테스트

    • 테스트 대상

    • 테스트 환경

    • 테스트 절차 및 테스트 케이스

      • 결함을 발생시킨 구체적인 테스트 데이터 명시

  • 결함 설명

    • 목격된 결함이 재연될 수 있도록 상세하게 기술

    • 실제 관찰된 결과값 기록

      • 결함의 고립화, 일반화
    • 실제 결과와 예상 결과의 차이점에 대한 분석 내용

    • 예상치 않게 발견된 오동작 상황을 기록

  • (심각도) 결함 심각도

    • 결함이 시스템에 미치는 정도를 표현

    • 발견자 관점에서 볼 때
      기술적인 측면과 비즈니스적인 특면을 모두 고려하여
      검출된 결함이 미칠 수 있는 영향의 범위와 크기를 바탕으로 기술

    • 결함 해결에 소요되는 예상 시간도 기술할수 있음

  • 우선 순위
    • 검출된 결함 해결의 긴급성을 기술
    • 3~5단계 정도로 순위 부여

  • 위험 분석
    • 검출된 결함과 관련된 새로운 위험에 대한 분석 결과를 기록
    • 기존 위험의 갱신 상태(발생 가능성, 영향도)에 따른 위험도의 변경점 기술

  • 결함 상태
    • 검출된 결함에 대한 조치 상태를 기록
      • 결함 추적



30-4. 결함 추적

  • 테스트 절차를 실행하여 발견된 결함은 결함 보고서로 기록하며
    발견된 결함은 적절한 개발자를 선정하여 수정을 요청

    1. 개발자는 소프트웨어를 작성한 후 테스터에게 전달

    2. 테스터는 계획된 테스트 전략에 따라 테스트 케이스 및 절차를 생성하고 테스트 수행

    3. 개발자는 요청된 결함을 수정하고 테스터에게 전달

    4. 테스터는 해결이 됐는지 확인 후 새로운 결함이 발생하지 않았는지 점검하기 위해 테스트 수행

  • 결함 생명 주기

    • Open : 테스터가 테스트 절차를 실행하여 발견된 결함을 분석 후 구체화, 고립화, 일반화로 보고 완료

    • Review : open된 결함의 처리 방안을 검토

    • Deferred : open된 결함을 곧바로 수정하지 않고 다음 릴리스에서 해결하기로 연기

    • Assigned : 결함을 해결하기로 결정된 상태에서 수정할 개발자가 결정되고 그 개발자에게 해결이 요구된 상태

    • Resolved : 개발자가 수정 해결 처리 완료

    • Fixed, duplicate, won’t fix, invalid :

      • Fixed
        • 개발자가 결함 수정 완료
      • duplicate
        • 다른 결함과 중복
      • won’t fix
        • 긴급하지 않아 수정하지 않음
      • invalid
        • 결함 보고(테스트 케이스, 절차)에 문제가 있는 경우
    • Verified : 개발자의 결함 처리가 합당한지 정확한지 검증이 된 상태

    • Reopen : 결함이 정확하게 수정되지 않은 경우


  • 결함 처리 시나리오

    • 경미한 결함의 무시 시나리오
      • 매우 경미한 결함이고
        시스템에 미치는 영향이 무시될 수 있는 상황
        “Open” – “Review” – “Closed” 상태
    • 차후에 결함을 처리하는 경우
      • 다음 릴리스에서 적절한 처리
        “Open” – “Review” – “Deferred” 상태로 이동
    • 이번 릴리스에서 결함을 처리하는 경우
      • 이번 릴리스에서 처리하는 것이 바람직하다고 판단
        담당 개발자를 결정하고 수정을 요청
        “Open” – “Review” – “Assigned” 상태로 이동
        ![]

  • 결함 처리 보고서

    • 테스터가 검출한 결함은 개발자를 할당하여 결함을 해결하거나, 미루거나 무시

    • 담당자 할당, 처리 연기, 결함 무시를 기록

    • 결함 추적 보고서는 결함을 발견한 테스터, 해결을 할당받은 개발자, 수정을 검증하는 테스터 공유



30-5. 테스트 결함 보고 산출물

  • 결함 보고서

    • 결함 식별자, 결함을 발견한 테스터와 발견 일시를 기록
      결함을 발견할 때 수행된 구체적인 개별 테스트, 테스트 대상, 테스트 환경, 테스트 케이스 및 테스트 절차 등을
      결함 컨텍스트에 기술

      • 실제 실행 결과 및 발견된 이상 결과를 결함 설명에 기술
        그리고 결함의 심각도, 우선순위, 관련 위험 분석 결과와 현재 결함의 상태를 기술

  • 결함 추적 보고서

    • 추적 대상이 되는 결함의 식별자가 먼저 작성
      결함에 대한 검토 정보, 결함 해결 정보, 결함 해결 검증 정보를 기술하고
      검토 결과를 기술
profile
기억저장소

0개의 댓글