수강 신청 시스템
아키텍처 프로토타입에 대한 테스트 계획
버전 1.0
개정 히스토리
날짜 | 버전 | 설명 | 작성자 |
---|---|---|---|
1999년 3월 7일 | 1.0 | 초기 릴리스 - 프로토타입 테스트 계획 | K. Stone |
|
|
|
|
|
|
|
|
|
|
|
|
목차
아키텍처 프로토타입에
대한
테스트 계획
1. 목표
1.1 목적
이 문서에서는 수강 신청 시스템의 아키텍처 프로토타입 테스트 계획에 대해 설명합니다. 이 테스트 계획 문서의 목표는 다음과 같습니다.
이 테스트 계획은 프로토타입 [16]에 대한 통합 빌드 계획에서 식별되는 서브시스템 및 컴포넌트의 반복에 따라 아키텍처 프로토타입에서 수행될 통합 및 시스템 테스트에 대해 설명합니다.
광범위한 소스 코드 적용 범위를 테스트하고 모든 모듈 인터페이스를 테스트하는 유닛 테스트가 이미 블랙 박스 테스트를 통해 제공된 것으로 가정합니다.
아키텍처 프로토타입을 어셈블링하는 목적은 선택한 아키텍처의 타당성과 성능을 테스트하기 위한 것이었습니다. 이 초기 단계에서는 시스템 성능은 물론 모든 시스템 서브시스템 인터페이스를 테스트해야 합니다. 프로토타입에 대한 시스템 기능 테스트는 수행되지 않습니다.
다음 서브시스템 간의 인터페이스는 테스트됩니다.
다음 장치에 대한 외부 인터페이스는 테스트됩니다.
테스트할 가장 중요한 성능 척도는 다음과 같습니다.
관련 참조 서적은 다음과 같습니다.
다음 내용은 테스트 대상으로 식별된 해당 항목(유스 케이스, 기능적 요구사항 및 비기능적 요구사항)을 식별합니다. 이 목록은 테스트 내용을 나타냅니다.
(참고: 이 테스트 계획의 향후 릴리스에서는 유스 케이스 문서 및 보충 스펙의 요구사항과 직접 연결되도록 Rational RequisitePro를 사용할 수 있습니다.)
2.1 데이터 및 데이터베이스 무결성 테스트
과정 카탈로그 데이터베이스 액세스에 대한 검증
동시 레코드 읽기 액세스에 대한 검증
과정 카탈로그 갱신 중 잠금 검증
데이터베이스 데이터 갱신사항에 대한 올바른 검색 검증
2.2. 기능 테스트
비전 문서, 섹션 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 메인프레임에서 작동하는 기존 과정 청구 시스템과 통합됩니다."
2.3 비즈니스 주기 테스트
없음
2.4 사용자 인터페이스 테스트
일련의 샘플 화면을 통해 탐색의 용이성 검증
샘플 화면의 GUI 표준 준수 검증
비전 문서 섹션 10: "시스템은 사용이 용이하고 학생 및 교수가 컴퓨터를 사용할 수 있는 대상 시장에 적합합니다."
비전 문서, 섹션 12.1: "데스크탑 사용자 인터페이스는 Windows 95/98을 지원합니다."
보충 스펙, 섹션 5.1: "데스크탑 사용자 인터페이스는 Windows 95/98을 지원합니다."
보충 스펙, 섹션 5.2: "수강 신청 시스템의 사용자 인터페이스는 사용하기 쉽게 디자인되어 컴퓨터 사용자라면 시스템에 대한 추가 훈련 없이 사용할 수 있습니다."
2.5 성능 테스트
외부 재무 시스템 액세스를 위한 응답 시간 검증
외부 과정 카탈로그 서브시스템 액세스를 위한 응답 시간 검증
원격 로그인을 위한 응답 시간 검증
원격 수강 신청 제출을 위한 응답 시간 검증
비전 문서, 섹션 12.3: "시스템은 10초 미만의 지연 시간으로 레거시 과정 카탈로그 데이터베이스에 대한 액세스를 제공합니다."
보충 스펙, 섹션 7.2: "시스템은 10초 미만의 지연 시간으로 레거시 과정 카탈로그 데이터베이스에 대한 액세스를 제공합니다."
2.6 로드 테스트
200명의 학생이 로그온한 상태에서 시스템 응답 검증
50명의 학생이 동시에 과정 카탈로그에 액세스하는 상태에서 시스템 응답 검증
2.7 스트레스 테스트
없음
2.8 볼륨 테스트
없음
2.9 보안 및 액세스 제어 테스트
로컬 PC에서 로그온 검증
원격 PC에서 로그온 검증
사용자 이름 및 암호 메커니즘을 통한 로그온 보안 검증
2.10 장애 복구/복구 테스트
없음
2.11 형상 테스트
비전 문서, 섹션 12.2: "시스템의 클라이언트 컴포넌트는 Windows 95, Windows 98 및 Microsoft Windows NT에서 실행됩니다."
보충 스펙, 섹션 9.4: "수강 신청 시스템의 웹 기반 인터페이스는 Netscape 4.04 및 Internet Explorer 4.0 브라우저에서 실행됩니다.
보충 스펙, 섹션 9.5: "웹 기반 인터페이스는 Java 1.1 VM 런타임 환경과 호환됩니다.
2.12 설치 테스트
없음
테스트 전략은 소프트웨어 응용프로그램 테스트를 위한 권장 접근 방식을 제공합니다. 테스트 내용에 대한 이전 섹션의 테스트 요구사항을 테스트하며 테스트 방법에 대해 설명합니다.
테스트 전략에서 가장 중요한 고려사항은 사용할 기법과 테스트 완료 시점을 파악하는 기준입니다.
각 테스트에 대해 제공되는 다음 고려사항 이외에도, 테스트는 알려지고 제어된 데이터베이스를 사용하여 보안 환경에서만 실행되어야 합니다.
다음 테스트 전략은 일반적인 전략이며 이 문서의 섹션 4에 나열된 요구사항에 적용됩니다.
3.1 테스트 유형3.1.1 데이터 및 데이터베이스 무결성 테스트
데이터베이스와 데이터베이스 프로세스는 별도 시스템으로서 테스트해야 합니다. 이러한 시스템은 데이터에 대한 인터페이스로서 응용프로그램 없이 테스트해야 합니다. 다음 테스트 방법을 지원하는 도구/기법을 식별하기 위한 DBMS에 대한 추가 연구를 수행해야 합니다.
테스트 목표: | 데이터베이스 액세스 방법 및 프로세스가 데이터 손상 없이 올바르게 작동하는지 확인합니다. |
기법: |
|
완료 기준: | 모든 데이터베이스 액세스 방법 및 프로세스가 데이터 손상 없이 원하는대로 작동합니다. |
특수 고려사항: |
|
3.1.2 기능 테스트응용프로그램 테스트는 유스 케이스(또는 비즈니스 기능) 및 비즈니스 규칙에 대해 직접 추적할 수 있는 대상 요구사항에 중점을 두어야 합니다. 이 테스트의 목적은 올바른 데이터 허용, 처리, 검색 및 비즈니스 규칙의 적절한 구현을 확인하는 데 있습니다. 이러한 유형의 테스트는 GUI를 통해 응용프로그램과 상호작용하고 결과물(결과)을 분석함으로써 응용프로그램(및 해당 내부 프로세스)을 검증하는 블랙 박스 기법을 기반으로 합니다. 다음은 각 응용프로그램에 대해 권장되는 테스트 방법에 대한 개요입니다.
테스트 목표: | 응용프로그램 탐색, 데이터 입력, 처리 및 검색이 올바른지 확인합니다. |
기법: |
|
완료 기준: |
|
특수 고려사항: |
|
3.1.3 비즈니스 주기 테스트
3.1.4 사용자 인터페이스 테스트이 섹션은 아키텍처 프로로타입 테스트에는 적용되지 않습니다.
사용자 인터페이스 테스트는 사용자와 소프트웨어의 상호작용을 검증합니다. UI 테스트의 목적은 사용자 인터페이스가 사용자에게 응용프로그램 기능을 통해 올바른 액세스 및 탐색 기능을 제공하는지 확인하는 것입니다. 또한 UI 테스트를 통해 UI의 오브젝트가 예상 기능을 수행하고 회사 또는 산업 표준을 준수하는지 확인합니다.
테스트 목표: | 다음 사항을 검증합니다.
|
기법: |
|
완료 기준: | 각 창이 벤치마크 버전 또는 허용되는 표준에서 일관성을 유지하는 것으로 검증되었습니다. |
특수 고려사항: |
|
3.1.5 성능 프로파일링
성능 테스트는 응답 시간, 트랜잭션 비율 및 기타 시간 관련 요구사항을 측정합니다. 성능 테스트의 목적은 성능 요구사항이 충족되었는지 여부를 검증하는 것입니다. 성능 테스트는 일반적으로 여러 번 실행되며 실행할 때마다 시스템에 대해 다른 "백그라운드 로드"를 사용합니다. 초기 테스트는 대상 시스템에서 발생(또는 예상)하는 정상 로드와 유사한 "명목" 로드로 수행되어야 합니다. 두 번째 성능 테스트는 최대 로드를 사용하여 실행됩니다.
또한 성능 테스트는 시스템 성능을 파악하여 워크로드 또는 하드웨어 구성과 같은 조건의 기능으로서 조정하는 데 사용할 수 있습니다.
참고: 다음 트랜잭션은 "논리 비즈니스 트랜잭션"을 의미합니다. 이 트랜잭션은 시스템 사용자가 특정 계약의 추가 또는 수정과 같이 응용프로그램을 사용하여 수행하는 특정 기능으로 정의됩니다.
테스트 목표: | 다음
두 가지 조건하에서 지정된 트랜잭션 또는 비즈니스
기능에 대한 시스템 응답 시간의 유효성을 검증합니다.
- 정상 예상 볼륨 - 과도한 예상 볼륨 |
기법: |
|
완료 기준: |
|
특수 고려사항: |
|
3.1.6 로드 테스트로드 테스트는 테스트 중인 시스템에 다양한 워크로드를 제공하여 각기 다른 워크로드에서도 시스템이 계속 올바른 기능을 수행하는지 평가합니다. 로드 테스트의 목적은 시스템이 예상되는 최대 워크로드를 초과해도 적절하게 기능하는지를 판별하고 확인하는 것입니다. 또한 로드 테스트는 응답 시간, 트랜잭션 비율 및 기타 시간 관련 문제와 같은 성능 특성을 평가합니다.
참고: 다음 트랜잭션은 "논리 비즈니스 트랜잭션"을 의미합니다. 이 트랜잭션은 시스템 사용자가 특정 계약의 추가 또는 수정과 같이 응용프로그램을 사용하여 수행하는 특정 기능으로 정의됩니다.
테스트 목표: | 다양한 워크로드 조건하에서 지정된 트랜잭션 또는 비즈니스 사례에 대한 시스템 응답 시간을 검증합니다. |
기법: |
|
완료 기준: |
|
특수 고려사항: |
|
3.1.7 스트레스 테스트
3.1.8 볼륨 테스트이 섹션은 아키텍처 프로로타입 테스트에는 적용되지 않습니다.
3.1.9 보안 및 액세스 제어 테스트이 섹션은 아키텍처 프로로타입 테스트에는 적용되지 않습니다.
보안 및 액세스 제어 테스트는 다음과 같은 두 가지 핵심 보안 영역에 초점을 맞춥니다.
데이터 또는 비즈니스 기능에 대한 액세스를 포함하는 응용프로그램 보안
원격 시스템 액세스를 포함하는 시스템 보안응용프로그램 보안은 해당 보안에 따라, 사용자가 특정 기능 또는 데이터만 사용할 수 있도록 합니다. 예를 들어, 데이터를 입력하거나 새 계정을 작성하는 것은 누구나 할 수 있지만 삭제는 관리자만 할 수 있습니다. 데이터 레벨의 보안이 있는 경우, 테스트를 통해 사용자 "유형" 1은 재무 데이터를 포함하여 모든 고객 정보를 볼 수 있지만 사용자 2는 동일한 클라이언트의 인적사항만 볼 수 있게 할 수 있습니다.
시스템 보안은 시스템에 대한 액세스 권한이 부여된 사용자만 해당 게이트웨이를 통해 응용프로그램에 액세스할 수 있도록 합니다.
테스트 목표: | 기능/
데이터 보안: 사용자가 해당 유형에 따라 권한이 제공된
기능/데이터에만 액세스할 수 있는지 검증합니다.
시스템 보안: 해당 액세스 권한이 있는 사용자만 시스템 및 응용프로그램에 액세스할 수 있는지 검증합니다. |
기법: |
|
완료 기준: | 알려진 각 사용자 유형에 대해, 올바른 기능/데이터를 사용할 수 있으며 모든 트랜잭션이 예상 기능을 수행하고 응용프로그램 기능 테스트 전에 실행됩니다. |
특수 고려사항: |
|
3.1.10 장애 복구 및 복구 테스트
3.1.11 형상 테스트이 섹션은 아키텍처 프로로타입 테스트에는 적용되지 않습니다.
형상 테스트는 다른 소프트웨어 및 하드웨어 구성에 대한 소프트웨어 오퍼레이션을 검증합니다. 대부분의 프로덕션 환경에서는 클라이언트 워크스테이션, 네트워크 연결 및 데이터베이스 서버에 대한 특정 하드웨어 스펙이 다릅니다. 클라이언트 워크스테이션은 응용프로그램, 드라이버 등과 같은 다른 소프트웨어를 로드할 수 있습니다. 언제라도 여러 가지 다른 조합이 활성화되고 다른 자원을 사용할 수 있습니다.
테스트 목표: | 지정된 클라이언트 워크스테이션에서 클라이언트 응용프로그램에 올바른 기능을 수행하는지 검증합니다. |
기법: |
|
완료 기준: | 프로토타입 및 PC 응용프로그램의 각 조합에 대해 트랜잭션이 실패 없이 완료되었습니다. |
특수 고려사항: |
|
3.1.12 설치 테스트3.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 |
4. 자원
4.1 역할다음 표는 프로토타입 테스트에 대한 인력 가정사항을 보여줍니다.
인적 자원
역할 | 최소 권장 자원
(정규 작업자 수) |
특정 책임/주석 |
---|---|---|
테스트 관리자 | 1 - Kerry Stone | 관리 감독을 수행합니다.
책임:
|
테스트 디자이너 | Margaret Cox
Carol Smith |
테스트 케이스를
식별하고 우선순위를 결정하며 해당 케이스를 구현합니다.
책임:
|
시스템 테스터 | Carol Smith | 테스트를 실행합니다.
책임:
|
테스트 시스템 관리자 | Simon Jones | 테스트
환경 및 자산이 관리되고 유지보수될 수 있도록 합니다.
책임:
|
데이터베이스 관리/데이터베이스 관리자 | Margaret Cox | 테스트 데이터(데이터베이스)
환경 및 자산이 관리되고 유지보수될 수 있도록 합니다.
책임:
|
디자이너 | Margaret Cox | 테스트 클래스의
오퍼레이션, 속성 및 연관성을 식별하고 정의합니다.
책임:
|
구현자 | Margaret Cox | 테스트
클래스 및 테스트 패키지를 구현하고 유닛 테스트합니다.
책임:
|
4.2 시스템
다음 표는 수강 신청 프로토타입을 테스트하기 위한 시스템 자원을 보여줍니다.
시스템 자원
자원 | 이름/유형/일련 번호 |
---|---|
Wylie College 서버 | 일련 번호: X179773562b |
과정 카탈로그 데이터베이스 | 버전 ID: CCDB-080885 |
청구 시스템 | 버전 ID: BSSS-88335 |
클라이언트 테스트 PC |
|
세 대의 원격 PC(인터넷 액세스 가능) | 일련 번호: A8339223
일련 번호: B9334022 일련 번호: B9332544 |
3 대의 로컬 PC(LAN을 통해 연결) | 일련 번호: R3322411(학적 담당자)
일련 번호: A8832234(IT 랩) 일련 번호: W4592233(IT 랩) |
테스트 저장소 |
|
Wylie College 서버 | 일련 번호: X179773562b |
테스트 개발 PC - 6 | 일련 번호: A8888222
일련 번호: R3322435 일련 번호: I88323423 일련 번호: B0980988 일련 번호: R3333223 일련 번호: Y7289732 |
5. 프로젝트 이정표
수강 신청 아키텍처 프로토타입의 테스트에는 이전 섹션에서 식별된 각 테스트 노력에 대한 테스트 타스크가 포함됩니다. 또한 프로젝트 상태 및 성과를 알리기 위한 별도 프로젝트 이정표가 식별됩니다.
전체 단계 또는 마스터 프로젝트 스케줄은 소프트웨어 개발 계획 [13] 및 E1 반복 계획 [14]를 참조하십시오.
이정표 타스크 | 노력(pd) | 시작 날짜 | 종료 날짜 |
---|---|---|---|
프로토타입 테스트 계획 | 2 | 3월 12일 | 3월 15일 |
프로토타입 테스트 디자인 | 3 | 3월 15일 | 3월 18일 |
프로토타입 테스트 개발 | 4 | 3월 19일 | 3월 23일 |
프로토타입 테스트 실행 | 3 | 3월 24일 | 3월 26일 |
프로토타입 테스트 평가 | 1 | 3월 29일 | 3월 29일 |
다음 표는 이 테스트 계획에 정의된 테스트 타스크의 중간 산출물을 보여줍니다.
중간 산출물 | 소유자 | 검토/분배 | 마감 날짜 |
테스트 계획 | K. Stone | 상부 프로젝트 관리 팀 | 3월 15일 |
테스트 환경 | S. Jones | - | 3월 18일 |
테스트 스위트 | C. Smith 및 M. Cox | 내부 피어 검토 | 3월 23일 |
테스트 데이터 세트 | M. Cox | 내부 피어 검토 | 3월 23일 |
테스트 스크립트 | M. Cox | - | 3월 23일 |
테스트 스텁, 드라이버 | M. Cox | - | 3월 23일 |
테스트 결함 보고서 | C. Smith | 상부 프로젝트 관리 팀 | 3월 26일 |
테스트 결과 | C. Smith | - | 3월 26일 |
테스트 평가 보고서 | C. Smith | 상부 프로젝트 관리 팀 | 3월 29일 |
6.1 테스트 스위트테스트 스위트는 모든 테스트 케이스와 각 테스트 케이스와 연관된 테스트 스크립트를 정의합니다.
6.2 테스트 로그테스트 케이스를 식별하고 각 테스트 케이스의 상태를 추적하는 데는 RequisitePro를 사용할 계획입니다. 테스트 결과는 RequisitePro에 테스트되지 않음, 패스, 조건부 패스 또는 실패로 요약됩니다. 즉, RequisitePro는 다음과 같이 요구사항 속성 가이드라인 [17]에 정의된 각 테스트 케이스의 다음 속성을 지원하도록 설정됩니다.
- 테스트 상태
- 빌드 번호
- 테스터
- 테스트 날짜
- 테스트 참고사항
7. 프로젝트 타스크RequisitePro의 테스트 상태를 갱신하는 것은 시스템 테스터의 책임입니다.
테스트 결과는 형상 제어하에 보관됩니다.
6.3 결함 보고서개별 결함을 로깅하고 추적하는 데는 Rational ClearQuest가 사용됩니다.
다음은 수강 신청 아키텍처 프로토타입을 테스트하기 위한 테스트 관련 타스크입니다.
테스트 계획 |
|
|
|
|
|
|
테스트 디자인 |
|
|
|
|
|
테스트 구현 |
|
|
|
|
|
테스트 실행 |
|
|
|
|
|
|
테스트 평가 |
|
|
|
테스트 완료 기준 및 성공 기준을 달성했는지 판별 |
테스트 평가 보고서 작성 |
Copyright (c) IBM Corp. 1987, 2005. All Rights Reserved. |
수강 신청 프로젝트 웹 예제 |