대학 스포츠 페이징 시스템

테스트 계획

버전 1.0

개정 히스토리

날짜

버전 설명 작성자
1999년 10월 26일 1.0 초기 버전 Context Integration
목차

소개 페이지 맨 위로

목적

대학 스포츠 페이징 시스템에 대한 이 테스트 계획 문서의 목표는 다음과 같습니다.

  1. 테스트해야 하는 소프트웨어 컴포넌트와 기존 프로젝트 정보를 식별합니다.
  2. 권장되는 테스트 요구사항(상위 레벨)을 나열합니다.
  3. 수행될 테스트 전략에 대해 설명하고 권장합니다.
  4. 필수 자원을 식별하고 예상 테스트 노력을 제공합니다.
  5. 테스트 프로젝트의 인도물 요소를 나열합니다.

배경

대학 스포츠 페이지 시스템은 등록자가 등록한 대학 스포츠 카테고리에서 이벤트가 발생할 때 등록자에게 영숫자 호출을 보냅니다. 해당 등록자는 호출된 스토리와 기타 대학 스포츠 뉴스를 볼 수 있는 개인화된 웹 사이트에 연결할 수 있습니다.

시스템은 응용프로그램 웹 서버에 포함된 세 개의 주요 서브시스템으로 구성되며 기존 WebNewsOnLine 웹 사이트 및 호출 게이트웨이와 상호작용합니다. 해당 서브시스템은 다음과 같습니다.

  • 컨텐츠 관리 - 이 서브시스템은 컨텐츠를 승인하고 카테고리를 표시하며 등록자 헤드라인을 표시합니다. 또한 해당 등록 프로파일에 따라 특정 등록자 그룹을 대상으로 하는 광고 컨텐츠를 관리합니다.
  • 페이징 - 이 서브시스템은 시스템에 새 컨텐츠가 로드될 때 활성화됩니다. 이 서브시스템은 호출 대상 등록자를 판별하고 페이징 게이트웨이로 메시지를 송신합니다.
  • 보고 - 이 서브시스템은 본 광고를 추적하고 해당 보고서를 작성합니다.

시스템 아키텍처는 다음과 같이 표시됩니다.

시스템 아키텍처 다이어그램

 

범위

대학 스포츠 페이징 시스템에는 유닛 테스트 및 시스템 테스트가 수행됩니다. 유닛 테스트는 기능 품질을 테스트하고 시스템 테스트는 확장성 및 성능 문제를 처리합니다.

서브시스템 간 상호작용은 다음과 같이 테스트합니다.

    1. 컨텐츠 관리 대 페이징
    2. 컨텐츠 관리 대 보고

테스트할 시스템 인터페이스는 다음과 같습니다.

    1. 대학 스포츠 페이징 시스템 대 기존 WebNewsOnLine 웹 서버
    2. 대학 스포츠 페이징 시스템 대 페이징 게이트웨이

가장 중요한 테스트는 로드 및 성능에 대한 테스트로서, 다음과 같이 수행됩니다.

  1. 최대 200,000개의 호출을 생성하는 테스트 시나리오를 작성합니다.
  2. 또한 20초당 한 항목의 속도로 새 컨텐츠가 도달하는 테스트 시나리오를 작성합니다.
  3. 마지막으로, 동시 등록자 로드를 최대 200,000명까지 늘리는 시뮬레이션을 수행합니다.

프로젝트 식별

다음 표는 테스트 계획을 개발하는 데 사용되는 문서화 및 가용성을 식별합니다.

문서
(버전 및 날짜 포함)
작성됨 또는 사용 가능 수신 또는 검토됨 작성자 또는 자원 참고
비전 문서 Context Integration  
보충 스펙 Context Integration  
유스 케이스 보고서 Context Integration  
프로젝트 계획 Context Integration  
디자인 스펙 아니오 아니오    
프로토타입 Context Integration  
프로젝트 / 비즈니스 위험성 평가 Context Integration  

테스트 요구사항 페이지 맨 위로

다음 내용은 테스트 대상으로 식별된 해당 항목(유스 케이스, 기능적 요구사항 및 비기능적 요구사항)을 식별합니다. 이 목록에는 테스트될 내용이 표시됩니다.

데이터베이스 테스트

    등록자 정보를 입력 및 검색할 수 있는지 확인합니다.

    컨텐츠와 카테고리를 삽입 및 표시할 수 있는지 확인합니다.

    광고주 프로파일과 계정 정보를 입력 및 표시할 수 있는지 확인합니다.

    등록자의 특정 사용법 정보를 추적할 수 있는지 확인합니다.

기능 테스트

    등록자가 페이징을 요청한 정보를 볼 수 있는지 확인합니다.

    컨텐츠가 게시될 때 등록자에게 호출이 전달되는지 확인합니다.

    자동 컨텐츠 삽입 기능이 작동되는지 확인합니다.

    편집자 승인으로 비자동 컨텐츠가 삽입되는지 확인합니다.

    등록하지 않은 등록자가 호출을 받지 않는지 확인합니다.

    아카이브됨으로 표시된 컨텐츠가 등록자에게 다시 표시되지 않는지 확인합니다.

    더 이상 사용되지 않는 컨텐츠가 삭제되는지 확인합니다.

    광고주 보고서가 정확한지 확인합니다.

    광고주 보고서를 Microsoft® Word®, Microsoft® Excel ® 또는 HTML로 받을 수 있는지 확인합니다.

비즈니스 주기 테스트

    없음

사용자 인터페이스 테스트

    모든 사용자 유스 케이스를 탐색하여 각 UI 패널을 쉽게 이해할 수 있는지 확인합니다.

    모든 온라인 도움말 기능을 확인합니다.

    모든 화면이 WebNewsOnLine 표준을 준수하는지 확인합니다.

성능 프로파일링

    페이저 게이트웨이 시스템 인터페이스의 응답 시간을 확인합니다.

    기존 WebNewsOnLine 웹 서버 인터페이스의 응답 시간을 확인합니다.

    56Kbps 모뎀을 사용하여 연결될 때 응답 시간을 확인합니다.

    동일한 LAN에서 로컬로 연결될 때 응답 시간을 확인합니다.

로드 테스트

    동시 등록자가 200명일 때 시스템 응답을 확인합니다.

    동시 등록자가 500명일 때 시스템 응답을 확인합니다.

    동시 등록자가 1,000명일 때 시스템 응답을 확인합니다.

    동시 등록자가 5,000명일 때 시스템 응답을 확인합니다.

    동시 등록자가 10,000명일 때 시스템 응답을 확인합니다.

    동시 등록자가 50,000명일 때 시스템 응답을 확인합니다.

    동시 등록자가 100,000명일 때 시스템 응답을 확인합니다.

    동시 등록자가 200,000명일 때 시스템 응답을 확인합니다.

스트레스 테스트

    없음

볼륨 테스트

    단일 컨텐츠 요소가 게시될 때 5분 안에 호출이 전송되는지 확인합니다.

    20초 간격으로 컨텐츠가 게시될 때 5분 안에 호출이 전송되는지 확인합니다.

보안 및 액세스 제어 테스트

    비등록자가 등록자 전용 정보에 액세스할 수 있는지 확인합니다.

    비편집자가 컨텐츠를 승인할 수 없는지 확인합니다.

    해당 광고주가 광고 컨텐츠만 볼 수 있는지 확인합니다.

장애 복구 테스트

    없음

형상 테스트

    Netscape V4.x 브라우저를 사용하여 오퍼레이션을 확인합니다.

    Microsoft® Internet Explorer® V5.x를 사용하여 오퍼레이션을 확인합니다.

설치 테스트

    없음

테스트 전략 페이지 맨 위로

테스트 유형

데이터 및 데이터베이스 무결성 테스트
테스트 목표: 데이터베이스 액세스 방법 및 프로세스가 데이터 손상 없이 올바르게 작동하는지 확인합니다.
기법:
  • 각각 올바른 데이터 및 올바르지 않은 데이터(또는 데이터에 대한 요청)를 제공하여 각 데이터베이스 액세스 방법 및 프로세스를 호출합니다.
  • 데이터베이스를 검사하여 데이터가 원하는 대로 제공되었거나 모든 데이터베이스 이벤트가 올바르게 발생했는지 확인하거나, 리턴된 데이터를 검토하여 올바른 이유로 올바른 데이터가 검색되었는지 확인합니다.
완료 기준: 모든 데이터베이스 액세스 방법 및 프로세스가 데이터 손상 없이 원하는대로 작동합니다.
특수 고려사항:
  • 프로세스는 수동으로 호출해야 합니다.
  • 허용 불가능한 이벤트의 가시성을 향상시키려면 소규모 또는 최소 규모의 데이터베이스(레코드 수가 제한됨)를 사용해야 합니다.
기능 테스트
테스트 목표: 탐색, 데이터 입력, 처리 및 검색을 포함한 테스트 대상 기능이 올바른지 확인합니다.
기법: 올바른 데이터 및 올바르지 않은 데이터를 사용하여 각 유스 케이스, 유스 케이스 플로우 또는 기능을 실행하여 다음 내용을 검증합니다.
  • 올바른 데이터를 사용하면 예상 결과가 발생합니다.
  • 올바르지 않은 데이터를 사용하면 해당 오류 및 경고 메시지가 표시됩니다.
  • 각 비즈니스 규칙이 올바르게 적용됩니다.
완료 기준:
  • 계획한 모든 테스트가 실행되었습니다.
  • 식별된 결함이 모두 해결되었습니다.
특수 고려사항: 없음
사용자 인터페이스 테스트
테스트 목표: 다음 사항을 검증합니다.
  • 테스트 대상을 통한 탐색이 창 대 창, 필드 대 필드 및 액세스 방법 사용(탭 키, 마우스 이동, 단축키)과 같은 비즈니스 기능 및 요구사항을 올바르게 반영합니다.
  • 메뉴, 크기, 위치, 상태 및 초점과 같은 웹 오브젝트 및 특성이 표준을 준수합니다.
기법: 각 창의 테스트 사항을 작성 또는 수정하여 각 응용프로그램 창 및 오브젝트에 대한 올바른 탐색 및 오브젝트 상태를 확인합니다.
완료 기준: 각 창이 벤치마크 버전 또는 허용되는 표준에서 일관성을 유지하는 것으로 검증되었습니다.
특수 고려사항: 사용자 정의 및 써드파티 오브젝트에 대한 일부 특성에만 액세스할 수 있습니다.
성능 프로파일링
테스트 목표: 다음 조건에서 지정된 트랜잭션 또는 비즈니스 기능에 대한 성능 동작을 확인하십시오.
  • 예상되는 정상 워크로드
  • 잘못된 케이스에 대한 예상 워크로드
기법: 기능 또는 비즈니스 주기 테스트용으로 개발된 테스트 프로시저를 사용합니다.

데이터 파일을 수정하여 트랜잭션 수를 늘리거나 스크립트를 수정하여 각 트랜잭션이 발생하는 반복 횟수를 늘립니다.

스크립트는 하나의 시스템에서 실행해야 하며(가장 올바른 벤치마크 예는 단일 사용자, 단일 트랜잭션) 여러 클라이언트(가상 또는 실제)에서 반복해야 합니다. 다음 특수 고려사항을 참조하십시오.

완료 기준: 단일 트랜잭션 또는 단일 사용자: 트랜잭션당 할당된 예상 또는 필수 시간 이내에 실패 없이 테스트 스크립트가 완료됩니다.

복수 트랜잭션 또는 복수 사용자: 할당된 시간 안에 실패 없이 테스트 스크립트가 완료됩니다.

특수 고려사항: 전체 성능 테스트에는 서버에 대한 "배경" 워크로드가 포함됩니다.

이를 수행하기 위해서는 다음과 같은 몇 가지 방법을 사용할 수 있습니다.

  • 일반적으로 SQL 호출 형식으로 서버에 직접 "트랜잭션을 구동"시킵니다.
  • "가상" 사용자 로드를 작성하여 많은(일반적으로 수백 개) 클라이언트를 시뮬레이션합니다. 원격 터미널 에뮬레이션 도구를 사용하여 이 로드를 수행합니다. 이 기법은 또한 "트래픽"이 발생한 네트워크를 로드하는 데도 사용될 수 있습니다.
  • 각각 테스트 스크립트를 실행하여 시스템에 로드를 할당하는 여러 실제 클라이언트를 사용합니다.

성능 테스트는 전용 시스템 또는 지정된 시간에 수행해야 완벽한 제어 및 정확한 측정 효과를 얻을 수 있습니다.

성능 테스트에 사용되는 데이터베이스는 실제 크기이거나 규모가 동일해야 합니다.

로드 테스트
테스트 목표: 다양한 워크로드 조건에서 지정된 트랜잭션 또는 비즈니스 사례에 대한 성능 동작 시간을 확인합니다.
기법: 기능 또는 비즈니스 주기 테스트를 위해 개발된 테스트를 사용합니다.

데이터 파일을 수정하여 트랜잭션 수를 늘리거나 테스트를 수정하여 각 트랜잭션이 발생하는 횟수를 늘립니다.

완료 기준: 복수 트랜잭션 또는 복수 사용자: 할당된 시간 안에 실패 없이 테스트가 완료됩니다.
특수 고려사항: 로드 테스트는 전용 시스템 또는 지정된 시간에 수행해야 따라서 완전한 제어와 정확한 측정이 가능합니다.

로드 테스트에 사용되는 데이터베이스는 실제 크기이거나 규모가 동일해야 합니다.

볼륨 테스트
테스트 목표: 다음과 같은 대용량 볼륨 시나리오에서 테스트 대상이 올바른 기능을 수행하는지 확인합니다.
  • 확장 기간 동안 모두 동일한 최악의 상태의 성능 비즈니스 기능을 수행하여, 실제로 사용할 수 있는 최대 수의 클라이언트가 연결 또는 시뮬레이션되었습니다.
  • 실제 또는 크기 조정된 최대 데이터베이스 크기에 도달하며 복수의 조회 및 보고서 트랜잭션이 동시에 실행됩니다.
기법: 성능 프로파일링 또는 로드 테스트용으로 개발된 테스트를 사용합니다.

동일한 테스트 또는 보충 테스트 실행하는 복수 클라이언트를 사용하여, 장기간 최악의 경우 트랜잭션 볼륨 또는 믹스(위의 스트레스 테스트 참조)를 생성해야 합니다.

최대 크기의 데이터베이스를 작성하고(실제, 조정됨 또는 대표 데이터로 채움) 복수 클라이언트를 사용하여 장기간 조회 및 보고 트랜잭션을 동시에 실행합니다.

완료 기준: 계획한 모든 테스트가 실행되고, 소프트웨어 또는 소프트웨어 실패 없이 지정된 시스템 한계에 도달하거나 한계를 초과했습니다.
특수 고려사항: 위에서 설명한 대용량 볼륨 조건에 허용되는 시간은 언제입니까?
보안 및 액세스 제어 테스트
테스트 목표: 응용프로그램 레벨 보안: 액터는 해당 사용자 유형에 해당 권한이 제공된 기능 및 데이터에만 액세스할 수 있습니다.

시스템 레벨 보안: 해당 액세스 권한이 있는 액터만 시스템 및 응용프로그램에 액세스할 수 있는지 확인합니다.

기법: 응용프로그램 레벨: 각 액터 유형과 각 유형별로 권한이 있는 기능 또는 데이터를 식별하고 나열합니다.

각 액터 유형별로 테스트를 작성하고, 각 사용자 액터별 특정 트랜잭션을 작성하여 각 권한을 확인합니다.

사용자 유형을 수정하고 동일한 사용자에 대해 테스트를 재실행합니다. 각각의 경우, 추가 기능 및 데이터를 올바르게 사용할 수 있는지 또는 거부되었는지 검증합니다.

시스템 레벨 액세스(아래 특수 고려사항 참조)

완료 기준: 알려진 각 액터 유형에 대해, 올바른 기능 및 데이터를 사용할 수 있으며 모든 트랜잭션이 예상 기능을 수행하고 기능 테스트 전에 실행됩니다.
특수 고려사항: 시스템에 대한 액세스는 해당 네트워크 또는 시스템 관리자와 검토하거나 논의해야 합니다. 이 테스트는 네트워크 또는 시스템 관리 기능이므로 반드시 필요하지는 않습니다.
형상 테스트
테스트 목표:

필수 하드웨어 및 소프트웨어 구성에 대해 테스트 대상이 올바른 기능을 수행하는지 확인합니다.

기법:

기능 테스트 스크립트 사용

테스의 일부로 또는 테스트를 시작하기 전에 Microsoft 응용프로그램(예: Excel® 및 Word®)과 같은 다양한 비테스트 대상 관련 소프트웨어를 열거나 닫습니다.

선택한 트랜잭션을 실행하여 테스트 대상 및 비테스트 대상 소프트웨어와 상호작용하는 액터를 시뮬레이션합니다.

위의 프로세스를 반복하여 클라이언트에서 사용 가능한 기본 메모리 최소화

완료 기준:

테스트 대상 및 비테스트 대상 소프트웨어의 각 조합에 대해 모든 트랜잭션이 실패 없이 완료됩니다.

특수 고려사항:

데스크탑에서 필요하고 사용 가능하며 액세스할 수 있는 비테스트 대상 소프트웨어는 무엇입니까?

일반적으로 사용되는 응용프로그램은 무엇입니까?

응용프로그램에서 실행되는 데이터는 무엇입니까(예: Excel에서 열린 대용량 스프레드시트, 100페이지의 Word 문서)?

전체 시스템, Netware, 네트워크 서버, 데이터베이스 등 또한 이 테스트의 일부로 문서화해야 합니다.

도구

이 프로젝트에 사용되는 도구는 다음과 같습니다.

 

도구

버전

결함 추적

Project HomePage

 
프로젝트 관리

Microsoft® Project®

 


자원 페이지 맨 위로

이 섹션은 대학 스포츠 페이징 시스템 테스트 노력에 대해 권장되는 자원, 핵심 책임 및 해당 지식 또는 스킬 세트를 제공합니다.

작업자

다음 표에는 프로젝트에 대한 인력 구성 가정이 표시됩니다.

인적 자원
작업자 최소 권장 자원 특정 책임 및 주석
테스트 관리자,
테스트 프로젝트 관리자
1(대학 스포츠 페이징 시스템 프로젝트 관리자) 관리 감독을 수행합니다.

책임:

  • 기술 지도 제공
  • 해당 자원 확보
  • 관리 보고
테스트 디자이너 1 테스트 케이스를 식별하고 우선순위를 결정하며 해당 케이스를 구현합니다.

책임:

  • 테스트 계획 생성
  • 테스트 모델 생성
  • 테스트 노력의 효과 평가
테스터 4(WebNewsOnLine에서 제공) 테스트를 실행합니다.

책임:

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

책임:

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

책임:

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

책임:

  • 테스트 클래스 식별 및 정의
  • 테스트 패키지 식별 및 정의
구현자 4 테스트 클래스 및 테스트 패키지를 구현하고 유닛 테스트합니다.

책임:

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

시스템

다음 표에는 테스트 프로젝트에 대한 시스템 자원이 표시됩니다.

이 시점에서는 테스트 시스템의 특정 요소가 완전히 알려져 있지 않습니다. 필요한 경우 액세스 및 데이터베이스 크기를 줄여 프로뎍션 환경을 시뮬레이션해야 합니다.

시스템 자원
자원 이름 및 유형
데이터베이스 서버  
네트워크/서브넷 TBD
서버 이름 TBD
데이터베이스 이름 TBD
클라이언트 테스트 PC  
특수 구성 포함
- 요구사항
TBD
테스트 저장소  
네트워크/서브넷 TBD
서버 이름 TBD
테스트 개발 PC TBD

프로젝트 이정표 페이지 맨 위로

  이정표 타스크   노력 시작 날짜 종료 날짜
  테스트 계획        
  테스트 디자인        
  테스트 구현        
  테스트 실행        
  테스트 평가        

인도물 페이지 맨 위로

테스트 모델

실행된 각 테스트에 대해 테스트 결과 양식이 작성됩니다. 이 양식에는 테스트 이름 또는 ID, 테스트와 관련이 있는 유스 케이스 또는 보충 스펙, 테스트 날짜, 테스터 ID, 테스트 전 필수 조건 및 테스트 결과가 포함됩니다.

테스트 로그

Microsoft Word를 사용하여 테스트 결과를 기록하고 보고합니다.

결함 보고서

결함은 웹에서 Project HomePage를 사용하여 기록됩니다.

부록 A: 프로젝트 타스크 페이지 맨 위로

다음 표에는 테스트 관련 타스크가 나열됩니다.

테스트 계획
테스트 요구사항 식별
위험성 평가
테스트 전략 개발
테스트 자원 식별
스케줄 작성
테스트 계획 생성
테스트 디자인
워크로드 분석
테스트 케이스 식별 및 설명
테스트 프로시저 식별 및 구성
테스트 적용 범위 검토 및 평가
테스트 구현
테스트 스크립트 기록 또는 프로그래밍
디자인 및 구현 모델에서 테스트 특정 기능 식별
외부 데이터 세트 설정
테스트 실행
테스트 프로시저 실행
테스트 실행 평가
정지된 테스트 복구
결과 확인
예상치 않은 결과 조사
결함 로깅
테스트 평가
테스트 케이스 적용 범위 평가
코드 적용 범위 평가
결함 분석
테스트 완료 기준 및 성공 기준 달성 여부 판별

 

 

Copyright 1987 - 2003 Rational Software Corporation