수강 신청 시스템

테스트 계획

 

버전 1.0

개정 히스토리

날짜

버전

설명

작성자

1999년 3월 27일 1.0 릴리스 1 및 2에 대한 테스트 계획 K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

목차

  1. 목표
  2. 범위
  3. 참조
  4. 테스트 요구사항
  5. 테스트 전략
    1. 테스트 유형
      1. 데이터 및 데이터베이스 무결성 테스트
      2. 시스템 테스트
      3. 비즈니스 주기 테스트
      4. 사용자 인터페이스 테스트
      5. 성능 테스트
      6. 로드 테스트
      7. 스트레스 테스트
      8. 볼륨 테스트
      9. 보안 및 액세스 제어 테스트
      10. 장애 복구/복구 테스트
      11. 형상 테스트
      12. 설치 테스트
    2. 도구
  6. 자원
    1. 작업자
    2. 시스템
  7. 프로젝트 이정표
  8. 중간 산출물
    1. 테스트 스위트
    2. 테스트 로그
    3. 결함 보고서
  9. 프로젝트 타스크

테스트 계획

 

1. 목표

이 문서에서는 수강 신청 시스템의 테스트 계획에 대해 설명합니다. 이 테스트 계획 문서의 목표는 다음과 같습니다.

    • 테스트해야 하는 소프트웨어 컴포넌트와 기존 프로젝트 정보를 식별합니다.
    • 권장되는 테스트 요구사항(상위 레벨)을 나열합니다.
    • 수행될 테스트 전략을 권장하고 설명합니다.
    • 필수 자원을 식별하고 예상 테스트 노력을 제공합니다.
    • 테스트 타스크의 중간 산출물 요소를 나열합니다.

2. 범위

    이 테스트 계획은 수강 신청 시스템 릴리스 1 및 2에 대해 수행될 통합 및 시스템 테스트에 적용됩니다. 또한 아키텍처 프로토타입의 테스트 전략에 대해 설명하는 별도 테스트 계획 [17]이 있습니다.

    광범위한 소스 코드 적용 범위를 테스트하고 모든 모듈 인터페이스를 테스트하는 유닛 테스트가 이미 블랙 박스 테스트를 통해 제공된 것으로 가정합니다.

    이 테스트 계획은 비전 문서 [3], 유스 케이스 명세 [5-12] 및 보충 스펙 [13]에 정의된 수강 신청 시스템의 모든 요구사항에 대한 테스트에 적용됩니다.

3. 참조

관련 참조 서적은 다음과 같습니다.

    1. 과정 청구 인터페이스 스펙, WC93332, 1985, Wylie College Press.
    2. 과정 카탈로그 데이터베이스 스펙, WC93422, 1985, Wylie College Press.
    3. 수강 신청 시스템 비전 문서, WyIT387, V1.0, 1998, Wylie College IT.
    4. 수강 신청 시스템 용어집, WyIT406, V2.0, 1999, Wylie College IT.
    5. 수강 신청 시스템 유스 케이스 명세 - 신청 마감, WyIT403, V2.0, 1999, Wylie College IT.
    6. 수강 신청 시스템 유스 케이스 명세 - 로그인, WyIT401, V2.0, 1999, Wylie College IT.
    7. 수강 신청 시스템 유스 케이스 명세 - 교수 정보 유지보수, WyIT407, 버전 2.0, 1999, Wylie College IT.
    8. 수강 신청 시스템 유스 케이스 명세 - 수강 신청, WyIT402, 버전 2.0, 1999, Wylie College IT.
    9. 수강 신청 시스템 유스 케이스 명세 - 개설 과정 선택, WyIT405, 버전 2.0, 1999, Wylie College IT.
    10. 수강 신청 시스템 유스 케이스 명세 - 학생 정보 유지보수, WyIT408, 버전 2.0, 1999, Wylie College IT.
    11. 수강 신청 시스템 유스 케이스 명세 - 성적 제출, WyIT409, 버전 2.0, 1999, Wylie College IT.
    12. 수강 신청 시스템 유스 케이스 명세 - 성적표 보기, WyIT410, 버전 2.0, 1999, Wylie College IT.
    13. 수강 신청 시스템 보충 스펙, WyIT400, V1.0, 1999, Wylie College IT.
    14. 수강 신청 시스템 소프트웨어 개발 계획, WyIT418, V2.0, 1999, Wylie College IT.
    15. 수강 신청 시스템 소프트웨어 아키텍처 문서, WyIT431, V1.0, 1999, Wylie College IT.
    16. 수강 신청 시스템 요구사항 속성 가이드라인, WyIT404, V1.0, 1999, Wylie College IT.
    17. 수강 신청 시스템 아키텍처 프로토타입 테스트 계획, WyIT432, V1.0, 1999, Wylie College IT.

4. 테스트 요구사항

    다음 내용은 테스트 대상으로 식별된 해당 항목(유스 케이스, 기능적 요구사항 및 비기능적 요구사항)을 식별합니다. 이 목록은 테스트 내용을 나타냅니다. 각 테스트에 대한 세부사항은 나중에 테스트 케이스가 식별되고 테스트 스크립트가 개발되면 결정됩니다.

    (참고: 이 테스트 계획의 향후 릴리스에서는 비전 문서, 유스 케이스 문서 및 보충 스펙의 요구사항과 직접 연결되도록 Rational RequisitePro를 사용할 수 있습니다.)

    데이터 및 데이터베이스 무결성 테스트

    과정 카탈로그 데이터베이스 액세스에 대한 검증

    동시 레코드 읽기 액세스에 대한 검증

    과정 카탈로그 갱신 중 잠금 검증

    데이터베이스 데이터 갱신사항에 대한 올바른 검색 검증

    시스템 테스트(예: 기능 테스트)

    로그인 유스 케이스 [6] 검증

    신청 마감 유스 케이스 [5] 검증

    학생 정보 유지보수 유스 케이스 [10] 검증

    교수 정보 유지보수 유스 케이스 [7] 검증

    성적 제출 유스 케이스 [11] 검증

    성적표 보기 유스 케이스 [12] 검증

    수강 신청 유스 케이스 [8] 검증

    개설 과정 선택 유스 케이스 [9] 검증

    보충 스펙, 섹션 4.1: "모든 시스템 오류는 로깅됩니다. 심각한 시스템 오류의 경우에는 시스템이 차례로 종료됩니다."

    보충 스펙, 섹션 4.1: " 시스템 오류 메시지에는 오류에 대한 텍스트 설명, 운영 체제 오류 코드(해당되는 경우), 오류 조건을 발견하는 모듈, 데이터 소인 및 시간소인이 포함됩니다. 모든 시스템 오류는 오류 로그 데이터베이스에 보관됩니다."

    비전 문서, 섹션 12.2: "시스템은 기존 과정 카탈로그 데이터베이스 시스템과 상호작용합니다. 수강 신청 시스템은 [2]에 정의된 데이터 형식을 지원합니다."

    비전 문서, 섹션 12.2: "시스템은 기존 청구 시스템과 상호작용하며 [1]에 정의된 데이터 형식을 지원합니다."

    비전 문서, 섹션 12.2: "시스템의 서버 컴포넌트는 학교 캠퍼스 서버에서 작동하며 UNIX 운영 체제에서 실행됩니다."

    보충 스펙, 섹션 9.3: "시스템의 서버 컴포넌트는 Wylie College UNIX 서버에서 작동합니다."

    비전 문서, 섹션 12.2: "시스템의 클라이언트 컴포넌트는 최소 486 마이크로프로세서가 장착된 개인용 컴퓨터에서 작동합니다."

    보충 스펙, 섹션 9.3: "시스템의 클라이언트 컴포넌트는 최소 486 마이크로프로세서가 장착된 개인용 컴퓨터에서 작동합니다."

    보충 스펙, 섹션 9.1: "시스템은 학교 DEC VAX 메인프레임에서 작동하는 기존 레거시 시스템(과정 카탈로그 데이터베이스)과 상호작용합니다."

    보충 스펙, 섹션 9.2: "시스템은 학교 DEC VAX 메인프레임에서 작동하는 기존 과정 청구 시스템과 상호작용합니다."

    비즈니스 주기 테스트

새 과정 카탈로그를 다운로드한 후 오퍼레이션 검증

여러 학기 및 여러 해 동안의 오퍼레이션 검증

학기가 두 해에 걸쳐 진행되는 경우 올바른 오퍼레이션 검증

    사용자 인터페이스 테스트

    일련의 샘플 화면을 통해 탐색의 용이성 검증

    샘플 화면의 GUI 표준 준수 검증

    비전 문서 섹션 10: "시스템은 사용이 용이하고 학생 및 교수가 컴퓨터를 사용할 수 있는 대상 시장에 적합합니다."

    비전 문서, 섹션 12.1: "데스크탑 사용자 인터페이스는 Windows 95/98을 지원합니다."

    보충 스펙, 섹션 5.1: "데스크탑 사용자 인터페이스는 Windows 95/98을 지원합니다."

    보충 스펙, 섹션 5.2: "수강 신청 시스템의 사용자 인터페이스는 사용하기 쉽게 디자인되어 컴퓨터 사용자라면 시스템에 대한 추가 교육 없이 사용할 수 있습니다."

    보충 스펙, 섹션 5.3: "수강 신청 시스템은 사용자를 위해 각 기능에 대한 온라인 도움말을 기본으로 제공합니다. 온라인 도움말에는 시스템 사용에 대한 단계별 지시사항이 포함됩니다. 또한 용어 및 머리 글자어에 대한 정의가 포함됩니다."

    성능 테스트

    외부 재무 시스템 액세스를 위한 응답 시간 검증

    외부 과정 카탈로그 서브시스템 액세스를 위한 응답 시간 검증

    원격 로그인을 위한 응답 시간 검증

    원격 수강 신청 제출을 위한 응답 시간 검증

    비전 문서, 섹션 12.3: "시스템은 10초 미만의 지연 시간으로 레거시 과정 카탈로그 데이터베이스에 대한 액세스를 제공합니다."

    보충 스펙, 섹션 7.2: "시스템은 10초 미만의 지연 시간으로 레거시 과정 카탈로그 데이터베이스에 대한 액세스를 제공합니다."

    로드 테스트

    200명의 학생이 로그온한 상태에서 시스템 응답 검증

    50명의 학생이 동시에 과정 카탈로그에 액세스하는 상태에서 시스템 응답 검증

    보충 스펙, 섹션 7.1: "시스템은 항상 중앙 데이터베이스에 대해 2000명의 동시 사용자와 로컬 서버에 대해 최대 500명의 동시 사용자를 지원합니다."

    스트레스 테스트

    UNIX 서버의 최대 사용 시간 중에 시스템 응답 검증

    최대 학생 로그인 상태에서 시스템 응답 검증

    볼륨 테스트

    과정 카탈로그 데이터베이스의 용량이 90%일 때 시스템 응답 검증

    보안 및 액세스 제어 테스트

    로컬 PC에서 로그온 검증

    원격 PC에서 로그온 검증

    사용자 이름 및 암호 메커니즘을 통한 로그온 보안 검증

    보충 스펙, 섹션 4.2: "모든 기능은 인터넷 연결을 통해 원격으로 사용할 수 있습니다. "

    장애 복구/복구 테스트

    보충 스펙, 섹션 6.1: "수강 신청 시스템은 일 주일에 7일, 하루 24시간 사용할 수 있으며 중지 시간은 4% 이하입니다."

    보충 스펙, 섹션 6.2: "MTBF(Mean Time Between Failures)는 300시간을 초과합니다."

    형상 테스트

    비전 문서, 섹션 12.2: "시스템의 클라이언트 컴포넌트는 Windows 95, Windows 98 및 Microsoft Windows NT에서 실행됩니다."

    보충 스펙, 섹션 9.4: "수강 신청 시스템의 웹 기반 인터페이스는 Netscape 4.04 및 Internet Explorer 4.0 브라우저에서 실행됩니다.

    보충 스펙, 섹션 9.5: "웹 기반 인터페이스는 Java 1.1 VM 런타임 환경과 호환됩니다.

    설치 테스트

    보충 스펙, 섹션 8.1: "수강 신청 시스템의 PC 클라이언트 부분에 대한 업그레이드는 인터넷을 통해 UNIX 서버에서 다운로드할 수 있습니다."

    서버 부분 설치 검증

    클라이언트 부분 설치 검증

5. 테스트 전략

    테스트 전략은 소프트웨어 응용프로그램 테스트를 위한 권장 접근 방식을 제공합니다. 테스트 내용에 대한 이전 섹션의 테스트 요구사항을 테스트하며 테스트 방법에 대해 설명합니다.

    테스트 전략에서 가장 중요한 고려사항은 사용할 기법과 테스트 완료 시점을 파악하는 기준입니다.

    각 테스트에 대해 제공되는 다음 고려사항 이외에도, 테스트는 알려지고 제어된 데이터베이스를 사용하여 보안 환경에서만 실행되어야 합니다.

    다음 테스트 전략은 일반적인 전략이며 이 문서의 섹션 4에 나열된 요구사항에 적용됩니다.

    1. 테스트 유형

1. 데이터 및 데이터베이스 무결성 테스트

데이터베이스와 데이터베이스 프로세스는 별도 시스템으로서 테스트해야 합니다. 이러한 시스템은 데이터에 대한 인터페이스로서 응용프로그램 없이 테스트해야 합니다. 다음 테스트 방법을 지원하는 도구/기법을 식별하기 위한 DBMS에 대한 추가 연구를 수행해야 합니다.

테스트 목표: 데이터베이스 액세스 방법 및 프로세스가 데이터 손상 없이 올바르게 작동하는지 확인합니다.
기법:
  • 각각 올바른 데이터 및 올바르지 않은 데이터(또는 데이터에 대한 요청)를 제공하여 각 데이터베이스 액세스 방법 및 프로세스를 호출합니다.
  • 데이터베이스를 검사하여 데이터가 원하는 대로 제공되었거나 모든 데이터베이스 이벤트가 올바르게 발생했는지 확인하거나, 리턴된 데이터를 검토하여 올바른 이유로 올바른 데이터가 검색되었는지 확인합니다.
완료 기준: 모든 데이터베이스 액세스 방법 및 프로세스가 데이터 손상 없이 원하는대로 작동합니다.
특수 고려사항:
  • 테스트는 DBMS 개발 환경에서 수행해야 하며 데이터베이스에서 직접 데이터를 입력하거나 수정하려면 드라이버가 필요합니다.
  • 프로세스는 수동으로 호출해야 합니다.
  • 허용 불가능한 이벤트의 가시성을 향상시키려면 소규모 또는 최소 규모의 데이터베이스(레코드 수가 제한됨)를 사용해야 합니다.

2. 시스템 테스트

응용프로그램 테스트는 유스 케이스(또는 비즈니스 기능) 및 비즈니스 규칙에 대해 직접 추적할 수 있는 대상 요구사항에 중점을 두어야 합니다. 이러한 테스트의 목적은 올바른 데이터 허용, 처리 및 검색과 올바른 비즈니스 규칙 구현을 검증하는 것입니다. 이러한 유형의 테스트는 GUI를 통해 응용프로그램과 상호작용하고 결과물(결과)을 분석함으로써 응용프로그램(및 해당 내부 프로세스)을 검증하는 블랙 박스 기법을 기반으로 합니다. 다음은 각 응용프로그램에 대해 권장되는 테스트 방법에 대한 개요입니다.

 

테스트 목표: 응용프로그램 탐색, 데이터 입력, 처리 및 검색이 올바른지 확인합니다.
기법:
  • 올바른 데이터 및 올바르지 않은 데이터를 사용하여 각 유스 케이스, 유스 케이스 플로우 또는 기능을 실행하여 다음 내용을 검증합니다.
  • 올바른 데이터를 사용하면 예상 결과가 발생합니다.
  • 올바르지 않은 데이터를 사용할 때 해당 오류/경고 메시지가 표시됩니다.
  • 각 비즈니스 규칙이 올바르게 적용됩니다.
완료 기준:
  • 계획한 모든 테스트가 실행되었습니다.
  • 식별된 결함이 모두 해결되었습니다.
특수 고려사항:
  • Wylie College UNIX 서버와 기존 과정 카탈로그 시스템 및 청구 시스템에 대한 액세스가 필요합니다.

3. 비즈니스 주기 테스트

비즈니스 주기 테스트는 특정 기간 동안 시스템에서 수행되는 활동을 에뮬레이트해야 합니다. 기간(예: 1년)을 식별해야 하며 해당 1년 동안 발생하는 트랜잭션 및 활동을 실행해야 합니다. 이 테스트에는 모든 일, 주 및 월 단위 주기와 티클러(tickler)와 같이 날짜에 따른 이벤트가 포함됩니다.

 

테스트 목표 필수 비즈니스 모델 및 스케줄에 따라 올바른 응용프로그램 및 백그라운드 프로세스가 수행되는지 확인합니다.
기법:
  • 테스트 시 다음을 수행하여 몇 가지 비즈니스 주기를 시뮬레이션합니다.
  • 응용프로그램 기능 테스트에 사용되는 테스트를 수정/ 강화하여, 지정된 기간 동안 각 기능을 실행하여 몇몇 다른 사용자를 시뮬레이션하는 횟수를 늘립니다.
  • 올바르거나 올바르지 않은 기간(날짜 및 시간)을 사용하여 날짜 또는 시간에 따른 모든 기능을 실행합니다.
  • 주기적으로 발생하는 모든 기능을 적절한 시점에 실행합니다.
  • 테스트에는 올바르거나 올바르지 않은 데이터를 사용한 다음 검증 작업이 포함됩니다.
  • 올바른 데이터를 사용하면 예상 결과가 발생합니다.
  • 올바르지 않은 데이터를 사용할 때 해당 오류/경고 메시지가 표시됩니다.
  • 각 비즈니스 규칙이 올바르게 적용됩니다.
완료 기준:
  • 계획한 모든 테스트가 실행되었습니다.
  • 식별된 결함이 모두 해결되었습니다.
특수 고려사항:
  • 시스템 날짜 및 이벤트에 특수 지원 활동이 필요할 수 있습니다.
  • 해당 테스트 요구사항 및 프로시저를 식별하기 위한 비즈니스 모델이 필요합니다.

4. 사용자 인터페이스 테스트

사용자 인터페이스 테스트는 사용자와 소프트웨어의 상호작용을 검증합니다. UI 테스트의 목적은 사용자 인터페이스가 사용자에게 응용프로그램 기능을 통해 올바른 액세스 및 탐색 기능을 제공하는지 확인하는 것입니다. 또한 UI 테스트를 통해 UI의 오브젝트가 예상 기능을 수행하고 회사 또는 산업 표준을 준수하는지 확인합니다.

 

테스트 목표: 다음 사항을 검증합니다.
  • 응용프로그램을 통한 탐색이 창 대 창, 필드 대 필드 및 액세스 방법 사용(탭 키, 마우스 이동, 단축키)과 같은 비즈니스 기능 및 요구사항을 올바로 반영합니다.
  • 메뉴, 크기, 위치, 상태 및 초점과 같은 창 오브젝트 및 특성이 표준을 준수합니다.
기법:
  • 각 창에 대한 테스트를 작성/수정하여 각 응용프로그램 창 및 오브젝트에 대한 탐색 및 오브젝트 상태가 올바른지 검증합니다.
완료 기준: 각 창이 벤치마크 버전 또는 허용되는 표준에서 일관성을 유지하는 것으로 검증되었습니다.
특수 고려사항:
  • 사용자 정의 및 써드파티 오브젝트에 대한 일부 특성에만 액세스할 수 있습니다.

5. 성능 테스트

성능 테스트는 응답 시간, 트랜잭션 비율 및 기타 시간 관련 요구사항을 측정합니다. 성능 테스트의 목적은 성능 요구사항이 충족되었는지 여부를 검증하는 것입니다. 성능 테스트는 일반적으로 여러 번 실행되며 실행할 때마다 시스템에 대해 다른 "백그라운드 로드"를 사용합니다. 초기 테스트는 대상 시스템에서 발생(또는 예상)하는 정상 로드와 유사한 "명목" 로드로 수행되어야 합니다. 두 번째 성능 테스트는 최대 로드를 사용하여 실행됩니다.

또한 성능 테스트는 시스템 성능을 파악하여 워크로드 또는 하드웨어 구성과 같은 조건의 기능으로서 조정하는 데 사용할 수 있습니다.

참고: 다음 트랜잭션은 "논리 비즈니스 트랜잭션"을 의미합니다. 이 트랜잭션은 시스템 사용자가 특정 계약의 추가 또는 수정과 같이 응용프로그램을 사용하여 수행하는 특정 기능으로 정의됩니다.

 

테스트 목표: 다음 두 가지 조건하에서 지정된 트랜잭션 또는 비즈니스 기능에 대한 시스템 응답 시간의 유효성을 검증합니다.

- 정상 예상 볼륨

- 과도한 예상 볼륨

기법:
  • 비즈니스 모델 테스트(시스템 테스트)용으로 개발된 테스트 스크립트를 사용합니다.
  • 데이터 파일을 수정하여 트랜잭션 수를 늘리거나 스크립트를 수정하여 각 트랜잭션이 발생하는 반복 횟수를 늘립니다.
  • 스크립트는 하나의 시스템에서 실행되어야 하며(가장 좋은 벤치마크 예는 단일 사용자, 단일 트랜잭션) 여러 클라이언트(가상 또는 실제)에서 반복해야 합니다. 다음 특수 고려사항을 참조하십시오.
완료 기준:
  • 단일 트랜잭션/단일 사용자: 트랜잭션당 할당된 예상/필수 시간에 실패 없이 테스트 스크립트가 완료됩니다.
  • 복수 트랜잭션/복수 사용자: 할당된 시간 안에 실패 없이 테스트 스크립트가 완료됩니다.
특수 고려사항:
  • 전체 성능 테스트에는 서버에 대한 "백그라운드" 로드가 포함됩니다. 이를 수행하기 위해서는 다음과 같은 몇 가지 방법을 사용할 수 있습니다.
    • 일반적으로 SQL 호출 형식으로 서버에 직접 "트랜잭션을 구동"시킵니다.
    • "가상" 사용자 로드를 작성하여 많은(일반적으로 수백 개) 클라이언트를 시뮬레이션합니다. 원격 터미널 에뮬레이션 도구를 사용하여 이 로드를 수행합니다. 이 기법은 또한 "트래픽"이 발생한 네트워크를 로드하는 데도 사용될 수 있습니다.
    • 각각 테스트 스크립트를 실행하여 시스템에 로드를 할당하는 여러 실제 클라이언트를 사용합니다.
  • 성능 테스트는 전용 시스템 또는 지정된 시간에 수행해야 완벽한 제어 및 정확한 측정 효과를 얻을 수 있습니다.
  • 성능 테스트에 사용되는 데이터베이스는 실제 크기이거나 규모가 동일해야 합니다.

6. 로드 테스트

로드 테스트는 테스트 중인 시스템에 다양한 워크로드를 제공하여 각기 다른 워크로드에서도 시스템이 계속 올바른 기능을 수행하는지 평가합니다. 로드 테스트의 목적은 예상 최대 워크로드가 초과된 상태에서도 시스템이 올바른 기능을 수행하는지 확인하는 것입니다. 또한 로드 테스트는 응답 시간, 트랜잭션 비율 및 기타 시간 관련 문제와 같은 성능 특성을 평가합니다.

참고: 다음 트랜잭션은 "논리 비즈니스 트랜잭션"을 의미합니다. 이 트랜잭션은 시스템 사용자가 특정 계약의 추가 또는 수정과 같이 응용프로그램을 사용하여 수행하는 특정 기능으로 정의됩니다.

테스트 목표: 다양한 워크로드 조건하에서 지정된 트랜잭션 또는 비즈니스 사례에 대한 시스템 응답 시간을 검증합니다.
기법:
  • 비즈니스 주기 테스트용으로 개발된 테스트를 사용합니다.
  • 데이터 파일을 수정하여 트랜잭션 수를 늘리거나 테스트를 수정하여 각 트랜잭션이 발생하는 횟수를 늘립니다.
완료 기준:
  • 복수 트랜잭션/복수 사용자: 할당된 시간 안에 실패 없이 테스트가 완료됩니다.
특수 고려사항:
  • 로드 테스트는 전용 시스템 또는 지정된 시간에 수행해야 완벽한 제어 및 정확한 측정 효과를 얻을 수 있습니다.
  • 로드 테스트에 사용되는 데이터베이스는 실제 크기이거나 규모가 동일해야 합니다.

7. 스트레스 테스트

스트레스 테스트는 자원 부족으로 인해 발생하는 오류를 찾아내기 위해 수행됩니다. 메모리 또는 디스크 공간이 부족한 경우 정상 조건하에서는 명백하게 나타나지 않는 결함이 소프트웨어에서 발생할 수 있습니다. 데이터베이스 잠금 또는 네트워크 대역폭과 같은 공유 자원의 부족으로 결함이 발생할 수도 있습니다. 스트레스 테스트는 시스템이 처리할 수 있는 최대 로드를 식별합니다.

참고: 다음에서 설명하는 트랜잭션은 논리 비즈니스 트랜잭션을 의미합니다.

테스트 목표: 시스템 및 소프트웨어가 다음과 같은 스트레스 조건하에서 오류 없이 올바른 기능을 수행하는지 확인합니다.
  • 서버에서 사용할 수 있는 메모리(RAM 및 DASD)가 거의 또는 전혀 없습니다.
  • 실제로 사용할 수 있는 최대 수의 클라이언트가 연결 또는 시뮬레이션되었습니다.
  • 복수 사용자가 동일한 데이터/ 계정에 대해 동일한 트랜잭션을 수행합니다.
  • 과도한 트랜잭션 볼륨 또는 혼합 상태입니다(위의 성능 테스트 참조).

참고: 스트레스 테스트의 목적은 시스템 장애가 발생하여 더 이상 올바른 기능을 수행할 수 없는 조건을 식별하고 설명할 때에도 다시 언급됩니다.

기법:
  • 성능 테스트용으로 개발된 테스트를 사용합니다.
  • 제한된 자원을 테스트하려면 단일 시스템에서 테스트를 수행하여 서버의 RAM 및 DASD를 줄이거나 제한해야 합니다.
  • 나머지 스트레스 테스트의 경우에는 동일한 테스트 또는 보완 테스트를 실행하여 과도한 트랜잭션 볼륨/ 혼합을 생성하여 복수 클라이언트를 사용해야 합니다.
완료 기준: 계획한 모든 테스트가 실행되고, 소프트웨어 또는 소프트웨어 실패 없이 지정된 시스템 한계에 도달하거나 한계를 초과했습니다. 또는 시스템 장애가 발생하는 조건이 지정된 조건이 아닙니다.
특수 고려사항:
  • 네트워크에 스트레스를 주려면 메시지 또는 패킷으로 네트워크를 로드하기 위한 네트워크 도구가 필요합니다.
  • 데이터베이스가 확장될 수 있는 공간을 제한하려면 시스템에 사용되는 DASD를 일시적으로 줄여야 합니다.
  • 동일한 레코드/데이터 계정에 액세스하는 동시 클라이언트의 동기화

8. 볼륨 테스트

볼륨 테스트는 소프트웨어에 대용량 데이터를 제공하여 소프트웨어가 중단되는 한계에 도달하는지 여부를 판별합니다. 볼륨 테스트는 또한 시스템이 특정 기간 동안 처리할 수 있는 최대 연속 로드 또는 볼륨을 식별합니다. 예를 들어, 소프트웨어가 보고서를 생성하기 위해 한 세트의 데이터베이스 레코드를 처리하는 경우, 볼륨 테스트는 대규모 테스트 데이터베이스를 사용하여 소프트웨어가 정상적으로 작동되며 올바른 보고서를 생성하는지 확인합니다.

테스트 목표: 다음과 같은 대용량 볼륨 시나리오에서 응용프로그램/시스템이 올바른 기능을 수행하는지 확인합니다.
  • 장기간 동안 모두 동일한 최악의 상태의 성능 비즈니스 기능을 수행하여, 실제로 사용할 수 있는 최대 수의 클라이언트가 연결 또는 시뮬레이션되었습니다.
  • 최대 데이터베이스 크기(실제 또는 크기 조정됨)에 도달했으며 복수 조회/보고 트랜잭션이 동시에 실행되었습니다.
기법:
  • 성능 테스트용으로 개발된 테스트를 사용합니다.
  • 장기간 동안 동일한 테스트 또는 보완 테스트를 실행하여 최악의 상태의 트랜잭션 볼륨/혼합(위의 스트레스 테스트 참조)을 생성하여 복수 클라이언트를 사용해야 합니다.
  • 최대 크기의 데이터베이스를 작성하고(실제, 크기 조정됨 또는 대표 데이터로 채움) 복수 클라이언트를 사용하여 장기간 동안 조회/보고 트랜잭션을 동시에 실행합니다.
완료 기준: 계획한 모든 테스트가 실행되고, 소프트웨어 또는 소프트웨어 실패 없이 지정된 시스템 한계에 도달하거나 한계를 초과했습니다.
특수 고려사항:
  • 위에서 설명한 대용량 볼륨 조건에 허용되는 시간은 언제입니까?

9. 보안 및 액세스 제어 테스트

보안 및 액세스 제어 테스트는 다음과 같은 두 가지 핵심 보안 영역에 초점을 맞춥니다.

데이터 또는 비즈니스 기능에 대한 액세스를 포함하는 응용프로그램 보안
로그인 및 원격 시스템 액세스를 포함하는 시스템 보안

응용프로그램 보안은 해당 보안에 따라, 사용자가 특정 기능 또는 데이터만 사용할 수 있도록 합니다. 예를 들어, 데이터를 입력하거나 새 계정을 작성하는 것은 누구나 할 수 있지만 삭제는 관리자만 할 수 있습니다. 데이터 레벨의 보안이 있는 경우, 테스트를 통해 사용자 "유형" 1은 재무 데이터를 포함하여 모든 고객 정보를 볼 수 있지만 사용자 2는 동일한 클라이언트의 인적사항만 볼 수 있게 할 수 있습니다.

시스템 보안은 시스템에 대한 액세스 권한이 부여된 사용자만 해당 게이트웨이를 통해 응용프로그램에 액세스할 수 있도록 합니다.

테스트 목표: 기능/ 데이터 보안: 사용자가 해당 유형에 따라 권한이 제공된 기능/데이터에만 액세스할 수 있는지 검증합니다.

시스템 보안: 해당 액세스 권한이 있는 사용자만 시스템 및 응용프로그램에 액세스할 수 있는지 검증합니다.

기법:
  • 기능/데이터 보안: 각 사용자 유형 및 각 유형이 권한을 갖는 기능/데이터를 식별하고 나열합니다.
  • 각 사용자 유형에 대한 테스트를 작성하고, 각 사용자 유형의 특정 트랜잭션을 작성하여 권한을 검증합니다.
  • 사용자 유형을 수정하고 동일한 사용자에 대해 테스트를 재실행합니다. 각각의 경우에서 추가 기능/데이터를 올바르게 사용할 수 있는지 또는 거부되었는지 검증합니다.
  • 시스템 액세스(아래 특수 고려사항 참조)
완료 기준: 알려진 각 사용자 유형에 대해, 올바른 기능/데이터를 사용할 수 있으며 모든 트랜잭션이 예상 기능을 수행하고 응용프로그램 기능 테스트 전에 실행됩니다.
특수 고려사항:
  • 해당 네트워크 또는 시스템 관리자와 함께 시스템 액세스를 검토하거나 논의해야 합니다. 이 테스트는 네트워크 또는 시스템 관리 기능이므로 반드시 필요하지는 않습니다.

10. 장애 복구/복구 테스트

장애 복구/복구 테스트는 응용프로그램 또는 전체 시스템이 다양한 하드웨어, 소프트웨어 또는 네트워크 오작동 상황에서 과도한 데이터 손실 또는 데이터 무결성에 대한 손상 없이 이를 복구할 수 있는지 확인합니다.

장애 복구 테스트는 또한 계속 실행되어야 하는 시스템의 경우, 장애 복구 조건이 발생할 때 대체 또는 백업 시스템이 데이터 또는 트랜잭션 손실 없이 실패한 시스템을 올바르게 "대체"할 수 있는지 확인합니다.

복구 테스트는 응용프로그램 또는 시스템이 장치 I/O 실패 또는 올바르지 않은 데이터베이스 포인터/키와 같은 극단적인 조건(또는 시뮬레이션 조건)에 노출되는 대립 테스트 프로세스입니다. 이 테스트에서는 복구 프로세스가 호출되고 응용프로그램/시스템을 모니터 및/또는 검사하여 올바른 응용프로그램/시스템 및 데이터 복구가 수행되었는지 검증합니다.

테스트 목표: 복구 프로세스(수동 또는 자동)에서 데이터베이스, 응용프로그램 및 시스템이 알려진 원하는 상태로 복원되는지 확인합니다. 테스트에는 다음 유형의 조건이 포함됩니다.
  • 클라이언트의 정전
  • 서버의 정전
  • 네트워크 서버를 통한 통신 차단
  • DASD 및/또는 DASD 제어기에 대한 차단, 통신 또는 전원 손실
  • 불완전 주기(데이터 필터 프로세스 차단, 데이터 동기화 프로세스 차단)
  • 올바르지 않은 데이터베이스 포인터/키
  • 데이터베이스의 데이터 요소가 올바르지 않거나 손상됨
기법: 응용프로그램 기능 및 비즈니스 주기 테스트를 위해 작성된 테스트를 사용하여 일련의 트랜잭션을 작성해야 합니다. 원하는 테스트 시작 지점에 도달하면 다음 조치를 개별적으로 수행 또는 시뮬레이션해야 합니다.
  • 클라이언트의 정전: PC 전원 끄기
  • 서버의 정전: 서버에 대한 전원 끄기 프로시저 시뮬레이션 또는 시작
  • 네트워크 서버를 통한 차단: 네트워크 통신 중단 시뮬레이션 또는 시작(실제로 통신 배선 연결을 끊거나 네트워크 서버/라우트 전원 끄기)
  • DASD 및/또는 DASD 제어기에 대한 차단, 통신 또는 전원 손실: 하나 이상의 DASD 제어기 또는 장치와의 통신을 실제로 제거하거나 제거 시뮬레이션

위의 조건/시뮬레이션 조건이 수행되면 추가 트랜잭션이 실행되어야 하며 이 두 번째 테스트 지점 상태에 도달하면 복구 프로시저가 호출되어야 합니다.

불완전 주기에 대한 테스트에서는 데이터베이스 프로세스를 중단하거나 미리 종료해야 한다는 점을 제외하고는 위에서 설명한 기법과 동일한 기법을 사용합니다.

다음 조건에 대한 테스트를 수행하려면 알려진 데이터베이스 상태에 도달해야 합니다. 몇 가지 데이터베이스 필드, 포인터 및 키를 데이터베이스에서 데이터베이스 도구를 사용하여 수동으로 직접 손상시켜야 합니다. 응용프로그램 기능 및 비즈니스 주기 테스트의 테스트를 사용하여 추가 트랜잭션을 실행하여 전체 주기를 실행해야 합니다.

완료 기준: 위의 모든 경우에서, 복구 프로시저가 완료되면 응용프로그램, 데이터베이스 및 시스템이 알려진 바람직한 상태로 복원되어야 합니다. 이러한 상태에는 데이터 손상이 알려진 손상된 필드, 포인터/키 및 차단으로 인해 완료되지 않은 프로세스 또는 트랜잭션을 나타내는 보고서로 제한되는 상태가 포함됩니다.
특수 고려사항:
  • 복구 테스트는 매우 까다로운 작업으로서, 케이블 연결을 끊는 프로시저(전원 또는 통신 차단 시뮬레이션)가 바람직하지 않거나 불가능할 수 있습니다. 따라서 진단 소프트웨어 도구와 같은 대체 방법이 필요합니다.
  • 시스템의 자원(또는 컴퓨터 오퍼레이션), 데이터베이스 및 네트워크 그룹이 필요합니다.
  • 이 테스트는 업무 시간 후에 또는 분리된 시스템에서 실행되어야 합니다.

11. 형상 테스트

형상 테스트는 다른 소프트웨어 및 하드웨어 구성에 대한 소프트웨어 오퍼레이션을 검증합니다. 대부분의 프로덕션 환경에서는 클라이언트 워크스테이션, 네트워크 연결 및 데이터베이스 서버에 대한 특정 하드웨어 스펙이 다릅니다. 클라이언트 워크스테이션은 응용프로그램, 드라이버 등과 같은 다른 소프트웨어를 로드할 수 있습니다. 언제라도 여러 가지 다른 조합이 활성화될 수 있습니다.

 

테스트 목표: 지정된 클라이언트 워크스테이션에서 클라이언트 응용프로그램에 올바른 기능을 수행하는지 검증합니다.
기법:
  • 통합 및 시스템 테스트 스크립트 사용
  • 테스트의 일부로 또는 테스트가 시작되기 전에 다양한 PC 응용프로그램 열기/닫기
  • 선택한 트랜잭션을 실행하여 다양한 PC 응용프로그램과 관련된 사용자 활동 시뮬레이션
  • 위의 프로세스를 반복하여 클라이언트에서 사용 가능한 기본 메모리 최소화
완료 기준: 각 조합에 대해 트랜잭션이 실패 없이 완료되었습니다.
특수 고려사항:
  • 클라이언트에서 사용 및 액세스 가능한 PC 응용프로그램은 무엇입니까?
  • 일반적으로 사용되는 응용프로그램은 무엇입니까?
  • 응용프로그램에서 실행되는 데이터는 무엇입니까(예: Excel에서 열린 대용량 스프레드시트, 100페이지의 Word 문서)?
  • 전체 시스템, 네트워크 서버, 데이터베이스 등도 이 테스트의 일부로 문서화되어야 합니다.

12. 설치 테스트

설치 테스트에는 두 가지 목적이 있습니다. 첫 번째 목적은 소프트웨어를 정상 및 비정상 조건하에서, 가능한 모든 구성(예: 새 설치, 업그레이드 및 완전 설치 또는 사용자 정의 설치)에 설치할 수 있도록 하는 것입니다. 비정상 조건에는 충분하지 않은 디스크 공간, 디렉토리 작성 권한 부족 등이 포함됩니다. 두 번째 목적은 설치된 소프트웨어가 올바르게 작동하는지 검증하는 것입니다. 이를 위해 일반적으로 기능 테스트를 위해 개발된 여러 테스트가 실행됩니다.

 

테스트 목표: 클라이언트 소프트웨어가 다음 조건하에서 각 클라이언트에 올바르게 설치되는지 검증합니다.
  • 새 설치, 새 시스템, 한 번도 설치되지 않음
  • 이전에 설치된 시스템을 동일한 버전으로 갱신
  • 이전에 설치된 시스템을 더 낮은 버전으로 갱신
기법:
  • 수동으로 또는 자동화된 스크립트를 개발하여 대상 시스템 조건(새 설치, 한 번도 설치되지 않음, 동일한 버전 또는 이전 버전이 이미 설치됨)의 유효성을 검증합니다.
  • 설치를 실행/수행합니다.
  • 통합 또는 시스템 테스트 스크립트의 미리 결정된 서브세트를 사용하여 트랜잭션을 실행합니다.
완료 기준: 트랜잭션이 실패 없이 실행됩니다.
특수 고려사항:
  • 응용프로그램이 성공적으로 설치되고 중요한 소프트웨어 컴포넌트가 누락되지 않았는지 테스트하려면 어떤 트랜잭션을 선택해야 합니까?

2. 도구

시스템 테스트에 사용되는 도구는 다음과 같습니다.

 

도구

버전

테스트 관리 Rational RequisitePro

Rational Unified Process

TBD
테스트 디자인 Rational Rose TBD
결함 추적 Rational ClearQuest TBD
기능 테스트 Rational Robot TBD
성능 테스트 Rational Visual Quantify TBD
테스트 적용 범위 모니터 또는 프로파일러 Rational Visual PureCoverage TBD
기타 테스트 도구 Rational Purify

Rational TestFactory

TBD
프로젝트 관리 Microsoft Project

Microsoft Word

Microsoft Excel

TBD
DBMS 도구 TBD TBD

6. 자원

    이 섹션은 수강 신청 시스템을 테스트하기 위해 권장되는 자원, 중요한 책임 및 해당 지식 또는 스킬 세트를 제공합니다.

    1. 작업자

다음 표는 테스트 타스크에 대한 인력 가정사항을 보여줍니다.

인적 자원

작업자

최소 권장 자원

(정규 작업자 수)

특정 책임/주석

테스트 관리자 1 - Kerry Stone 관리 감독을 수행합니다.

책임:

  • 기술 지도 제공
  • 해당 자원 확보
  • 관리 보고
테스트 디자이너 Margaret Cox

Carol Smith

Sophie King

테스트 케이스를 식별하고 우선순위를 결정하며 해당 케이스를 구현합니다.

책임:

  • 테스트 계획 생성
  • 테스트 스위트 생성
  • 테스트 노력의 효과 평가
시스템 테스터 Carol Smith

Sophie King

Adrian Harmsen

테스트를 실행합니다.

책임:

  • 테스트 실행
  • 결과 로깅
  • 오류 복구
  • 결함 문서화
테스트 시스템 관리자 Simon Jones 테스트 환경 및 자산이 관리되고 유지보수될 수 있도록 합니다.

책임:

  • 테스트 관리 시스템 관리
  • 테스트 시스템에 대한 작업자 액세스 설치/관리
데이터베이스 관리/데이터베이스 관리자 Margaret Cox 테스트 데이터(데이터베이스) 환경 및 자산이 관리되고 유지보수될 수 있도록 합니다.

책임:

  • 테스트 데이터(데이터베이스) 관리
디자이너 Margaret Cox 테스트 클래스의 오퍼레이션, 속성 및 연관성을 식별하고 정의합니다.

책임:

  • 테스트 클래스 식별 및 정의
  • 테스트 패키지 식별 및 정의
구현자 Margaret Cox

Adrian Harmsen

테스트 클래스 및 테스트 패키지를 구현하고 유닛 테스트합니다.

책임:

  • 테스트 스위트에서 구현되는 테스트 클래스 및 패키지를 작성합니다.

2. 시스템

다음 표는 수강 신청 시스템을 테스트하기 위한 시스템 자원을 보여줍니다.

시스템 자원

자원

이름/유형/일련 번호

Wylie College 서버 일련 번호: X179773562b
  과정 카탈로그 데이터베이스 버전 ID: CCDB-080885
  청구 시스템 버전 ID: BSSS-88335
클라이언트 테스트 PC
 
  10개의 원격 PC(인터넷 액세스 가능) 일련 번호: A8339223

일련 번호: B9334022

일련 번호: B9332544

<7 TBD>

  여섯 대의 로컬 PC(LAN을 통해 연결) 일련 번호: R3322411(학적 담당자)

일련 번호: A8832234(IT 랩)

일련 번호: W4592233(IT 랩)

일련 번호: X3333411(교수 연구실)

일련 번호: A987344(실험실)

일련 번호: X9834000(학생회)

테스트 저장소
 
  Wylie College 서버 일련 번호: X179773562b
테스트 개발 PC - 6 일련 번호: A8888222

일련 번호: R3322435

일련 번호: I88323423

일련 번호: B0980988

일련 번호: R3333223

일련 번호: Y7289732

로드 시뮬레이터 일련 번호: ABC-123

 

 

7. 프로젝트 이정표

    테스트 활동 및 이정표는 개발 반복에 많이 의존합니다. 구현/구축(Construction) 단계는 세 개의 반복으로 구성됩니다. 각 반복에는 테스트 계획, 디자인, 개발, 실행 및 평가로 구성되는 전체 테스트 주기가 포함됩니다.

    개발 반복을 보여주는 구현/구축 단계 계획과 마스터 스케줄은 소프트웨어 개발 계획 [14] 및 반복 계획을 참조하십시오.

    다음 표는 테스트 이정표를 보여줍니다. 반복 컨텐츠가 계획되면 노력, 시작 날짜 및 종료 날짜를 완성할 수 있습니다.

    이정표 타스크 노력(pd) 시작 날짜 종료 날짜
    반복 C1: 베타 릴리스

    테스트 계획

    테스트 디자인

    테스트 개발

    테스트 실행

    테스트 평가

    TBD 3월 15일 4월 12일
    반복 C2: R1.0 릴리스

    테스트 계획

    테스트 디자인

    테스트 개발

    테스트 실행

    테스트 평가

    TBD 4월 13일 5월 14일
    반복 C3: R2.0 릴리스

    테스트 계획

    테스트 디자인

    테스트 개발

    테스트 실행

    테스트 평가

    TBD 5월 15일 6월 17일

     

8. 중간 산출물

    다음 표는 이 테스트 계획에 정의된 테스트 타스크의 중간 산출물을 보여줍니다.

    이 중간 산출물 중 일부는 각 테스트 주기 또는 반복에 대해 한 번씩 여러 번 생성됩니다. 테스트 계획과 같은 기타 중간 산출물은 개발 반복 때마다 갱신됩니다.

    중간 산출물 소유자 검토/분배 마감 날짜
    테스트 계획 K. Stone 상부 프로젝트 관리 팀 3월 28일
    테스트 환경 S. Jones - 3월 28일
    테스트 스위트 C. Smith 및 M. Cox 내부 피어 검토 3월 28일
    테스트 데이터 세트 M. Cox 내부 피어 검토 3월 31일
    테스트 스크립트 M. Cox - 4월 2일
    테스트 스텁, 드라이버 M. Cox - 4월 4일
    테스트 결함 보고서 C. Smith 상부 프로젝트 관리 팀 TBD
    테스트 결과 C. Smith 테스트 관리자 TBD
    테스트 평가 보고서 C. Smith 상부 프로젝트 관리 팀 TBD

     

1. 테스트 집합

      테스트 스위트는 모든 테스트 케이스와 각 테스트 케이스와 연관된 테스트 스크립트를 정의합니다.

2. 테스트 로그

테스트 케이스를 식별하고 각 테스트 케이스의 상태를 추적하는 데는 RequisitePro를 사용할 계획입니다. 테스트 결과는 RequisitePro에 테스트되지 않음, 패스, 조건부 패스 또는 실패로 요약됩니다. 즉, RequisitePro는 다음과 같이 요구사항 속성 가이드라인 [16]에 정의된 각 테스트 케이스의 다음 속성을 지원하도록 설정됩니다.

    • 테스트 상태
    • 빌드 번호
    • 테스터
    • 테스트 날짜
    • 테스트 참고사항

RequisitePro의 테스트 상태를 갱신하는 것은 시스템 테스터의 책임입니다.

테스트 결과는 형상 제어하에 보관됩니다.

개별 결함을 로깅하고 추적하는 데는 Rational ClearQuest가 사용됩니다.

9. 프로젝트 타스크

다음은 수강 신청 시스템을 테스트하기 위한 테스트 관련 타스크입니다.

 

테스트 계획

테스트 요구사항 식별

위험성 평가

테스트 전략 개발

테스트 자원 식별

스케줄 작성

테스트 계획 생성

테스트 디자인

워크로드 분석

테스트 스위트 개발

테스트 케이스 식별 및 설명

테스트 스크립트 식별 및 구성

테스트 적용 범위 검토 및 평가

테스트 구현

테스트 환경 설정

테스트 스크립트 기록 또는 프로그래밍

테스트 스텁 및 드라이버 개발

디자인 및 구현 모델에서 테스트 특정 기능 식별

외부 데이터 세트 설정

테스트 실행

테스트 스크립트 실행

테스트 실행 평가

정지된 테스트 복구

결과 검증

예상치 않은 결과 조사

결함 로깅

테스트 평가

테스트 케이스 적용 범위 평가

코드 적용 범위 평가

결함 분석

테스트 완료 기준 및 성공 기준을 달성했는지 판별

테스트 평가 보고서 작성

 

Copyright  (c) IBM Corp. 1987, 2005. All Rights Reserved. 

수강 신청 프로젝트 웹 예제
버전 2001.03