테스트 계획의 목적은 테스트 타스크의 의도를 커뮤니케이션하는 것입니다. 이 문서를 가능한 초기에 작성해야 합니다. 정제(Elaboration) 단계의 첫 번째 반복 중 하나에서 초기에 이 아티팩트를 생성하는 것도
너무 빠른 것은 아닙니다. 테스트 계획을 반복적으로 개발하고 사용 가능한 정보를 섹션을 추가하는 것이 바람직합니다.
테스트의 범위, 테스트에 대한 요구사항 및 필요한 자원에 대해 분명하게 커뮤니케이션해야 합니다. 이 정보는 테스트 노력의 목적과 경계, 테스트 내용, 테스트 방법, 테스트에 필요한 자원을 식별합니다. 이 정보를
분명하게 설명하면 테스트 노력의 검토, 피드백 및 승인이 빨라집니다.
프로젝트를 시작할 때 프로젝트에 대해 전체적으로 의도된 테스트를 식별하는 "마스터 테스트 계획"이라고 하는 테스트 계획을 작성해야 합니다. 각 반복을 계획함에 따라 더욱 정확한 "반복 테스트 계획"(또는 테스트
유형별로 구성되는 몇 가지 테스트 계획)이 작성됩니다. 여기에는 반복에 관련된 데이터(테스트에 대한 요구사항, 테스트 전략, 자원 등)만 포함됩니다. 또는 이 정보를 반복 계획에 포함할 수 있습니다(반복 계획의 관리 또는 사용을 어렵게 하지 않는 경우).
아래는 테스트, 테스트 위험성, 우선순위 및 테스트 정책에 대한 요구사항을 더욱 잘 식별하고 커뮤니케이션하기 위한 가이드라인입니다.
테스트 요구사항은 테스트할 내용을 식별합니다. 이는 특정한 테스트 대상입니다. 테스트 요구사항을 도출할 때 적용해야 하는 몇 가지 일반 규칙이 있습니다.
-
테스트 요구사항은 관찰이 가능하고 측정할 수 있는 동작이어야 합니다. 테스트 요구사항을 관찰할 수 없거나 측정할 수 없으면 요구사항이 만족되었는지 판단할 수 없습니다.
-
시스템의 각 유스 케이스 또는 보충 요구사항과 테스트 요구사항 사이에는 일 대 일 관계가 있는 것은 아닙니다. 일부 보충 요구사항에서 하나 이상의 테스트 요구사항이 파생되는 반면 유스 케이스는 종종 하나
이상의 테스트 요구사항을 가지고 마케팅 또는 패키징 요구사항과 같은 다른 요구사항에서 아무 것도 파생되지 않습니다.
테스트 요구사항은 유스 케이스, 유스 케이스 모델, 보충 스펙, 디자인 요구사항, 비즈니스 사례, 사용자와의 인터뷰 및 소프트웨어 아키텍처 문서를 포함하여 많은 소스에서 파생될 수 있습니다. 테스트 요구사항을
식별하는 데 사용되는 정보를 수집할 때 이런 모든 내용을 검토해야 합니다.
이름에서 볼 수 있듯이 기능 테스트 요구사항은 테스트 대상의 기능 동작의 설명에서 파생됩니다. 각 유스 케이스는 적어도 하나의 테스트 요구사항을 도출해야 합니다. 보다 세부적인 테스트 요구사항 목록은 각 이벤트
유스 케이스 플로우에 대해 적어도 하나의 테스트 요구사항을 포함해야 합니다.
성능 테스트 요구사항은 테스트 대상의 특정 성능 동작에서 파생됩니다. 일반적으로 성능은 응답 시간 및/또는 자원 사용의 측정으로 설명되며, 이는 다음과 같은 다양한 조건 하에서 측정됩니다.
-
서로 다른 워크로드 및/또는 시스템 조건
-
서로 다른 유스 케이스
-
서로 다른 구성
성능 요구사항은 보충 스펙에 설명되어 있습니다. 이러한 자료를 검토하되, 다음을 포함하는 구문에 특별히 주의하십시오.
-
응답 시간 또는 타이밍 프로파일과 같은 시간 구문
-
여러 이벤트 또는 유스 케이스가 지정된 기간 내에 발생해야 함을 표시하는 구문
-
한 항목의 동작을 다른 항목과 비교하는 구문
-
하나의 구성에서의 응용프로그램 동작을 다른 구성에서의 동작과 비교하는 구문
-
일정 기간 동안의 오퍼레이션 신뢰성(평균 실패 시간 간격(MTBF))
-
구성 또는 제한조건
위에 나열된 내용과 같은 정보를 반영하는 스펙의 각 구문에 대해 적어도 하나의 테스트 요구사항을 도출해야 합니다.
신뢰성 테스트 요구사항은 일반적으로 보충 스펙, 사용자 인터페이스 가이드라인, 디자인 가이드라인 및 프로그래밍 가이드라인에 설명되어 있는 몇 가지 소스에서 파생됩니다.
이러한 중간 산출물을 검토하되, 다음을 포함하는 구문에 특별히 주의하십시오.
-
신뢰성 또는 실패, 런타임 오류(예: 메모리 누수)에 대한 저항 관련 구문
-
코드 무결성 및 구조(언어 및 구문 준수)를 표시하는 구문
-
자원 사용과 관련된 구문
위에 나열된 정보를 반영하는 중간 산출물에서 적어도 하나의 테스트 요구사항을 도출해야 합니다.
성공적인 테스트를 위해서는 자원 제한조건 및 위험성과 같은 요소의 밸런스를 적절히 조절하는 테스트 노력이 필요합니다. 이를 위해서는 테스트 노력의 우선순위를 결정하여 가장 중요하거나, 의미 있거나, 위험성이 높은
유스 케이스나 컴포넌트를 먼저 테스트해야 합니다. 테스트 노력의 우선순위를 결정하려면 위험성 평가와 운영 프로파일을 수행하여 테스트 우선순위를 설정하는 기초로 사용해야 합니다.
다음 섹션은 테스트 우선순위를 결정하는 방법을 설명합니다.
테스트 요구사항을 식별하는 것은 테스트 대상을 식별하는 작업의 일부분입니다. 테스트 대상 우선순위를 설정하고 수행할 순서도 지정합니다. 이 단계는 다음을 포함하는 몇 가지 이유로 실행됩니다.
-
테스트 노력을 가장 적당한 테스트 요구사항에 집중하도록 함
-
가장 중요하거나, 의미 있거나, 위험성이 높은 테스트 요구사항을 가능한 빨리 처리되도록 함
-
시퀀스 또는 데이터와 같은 종속성을 테스트하도록 함
위험성을 평가하고 테스트 우선순위를 설정하는 세 가지 단계가 있습니다.
각 단계의 가이드라인이 아래에 제공됩니다.
테스트 우선순위를 평가하는 작업은 위험성 평가부터 시작됩니다. 실패 시 위험성이 가장 크거나 실패할 가능성이 높은 유스 케이스 또는 컴포넌트가 테스트되는 첫 번째 유스 케이스 중에 포함되어야 합니다.
다음과 같이 사용할 위험성 크기 지표를 식별 및 설명하여 시작하십시오.
-
H - 높은 위험성, 허용 안됨. 심각하게 외부 노출됩니다. 회사는 커다란 금융상의 손실, 신뢰도 추락 또는 회복할 수 없는 평판 손실로 고통을 겪게 됩니다.
-
M - 중간 위험성, 허용 가능하지만 바람직하지 않음. 외부 노출은 최소화되며, 회사는 금융상의 손실은 있지만 신뢰성이나 평판의 손실은 심각한 수준이 아닙니다.
-
L - 낮은 위험성, 허용 가능. 외부적인 노출은 거의 없으며 회사는 금융상이나 신뢰도에 거의 손상을 입지 않습니다. 회사의 평판은 그대로 유지됩니다.
위험성 크기 지표를 식별한 다음 테스트 대상에 각 유스 케이스 또는 컴포넌트를 나열하십시오. 목록의 각 유스 케이스 또는 컴포넌트에 대해 위험성 크기 지표를 식별하고 간단한 구문으로 값의 이유를 설명하십시오.
위험성 평가에 사용되는 세 가지 관점이 있습니다.
-
영향 - 지정한 유스 케이스, 요구사항 등의 영향 또는 시퀀스
-
원인 - 유스 케이스의 실패로 인한 바람직하지 않은 결과에서 시작하여 가능한 원인을 점검
-
가능성 - 유스 케이스가 실패할 가능성
하나의 관점을 선택하고 위험성 크기 지표를 식별한 다음 이유를 설명하십시오. 각 위험성 관점에 대해 지표를 식별할 필요는 없습니다. 그러나 낮은 지표가 식별된 경우 항목의 위험성이 정말 낮은지를 확인하기 위해 서로
다른 위험성 관점에서 항목 평가를 시도해 보는 것이 좋습니다.
아래는 이러한 세 가지 관점으로 위험성을 평가하는 방법에 대한 세부적인 설명입니다.
영향으로 위험성을 평가하려면 조건, 이벤트 또는 조치를 식별한 다음 그 영향을 결정하십시오. 다음과 같이 질문하십시오.
"___________면 어떻게 됩니까?"
예제:
-
"새 프로그램을 설치하는 중에 디스크 공간이 부족하면 어떻게 됩니까?"
-
"트랜잭션 조회 중에 인터넷 연결이 끊어지면 어떻게 됩니까?"
-
"물건을 구매하는 중에 인터넷 연결이 끊어지면 어떻게 됩니까?"
-
"사용자가 예상치 못한 값을 입력하면 어떻게 됩니까?"
아래는 이러한 항목에 대한 샘플 이유 표입니다.
설명
|
위험성 크기
|
이유
|
설치 중에 디스크 공간 부족
|
H
|
프로그램 설치 과정은 제품이 사용자에게 주는 첫인상입니다. 아래 나열된 내용과 같이 바람직하지 않은 결과는 사용자의 시스템과 설치된 소프트웨어에 문제를 발생시킬 수 있으며 사용자에게
좋지 않은 인상을 줄 수 있습니다.
-
일부 파일이나 일부 레지스트리 항목과 같이 부분적으로 설치되어 설치된 소프트웨어가 불완전한 상태가 됨
-
설치 과정 때문에 시스템이 불완전한 상태가 됨
|
조회 중에 인터넷 연결이 끊어짐
|
L
|
연결이 끊어져도 데이터나 데이터베이스는 손상되지 않습니다. 인터넷 연결이 끊어지면 사용자에게 좋지 않은 인상을 줄 수 있습니다.
|
구매 중에 인터넷 연결이 끊어짐
|
H
|
아래에 나열된 결과를 가져오는 모든 트랜잭션 또는 연결 끊김은 비용을 증가시키고 수익을 감소시키므로 허용되지 않습니다.
-
데이터베이스 손상
-
부분 주문
-
데이터 또는 주문 유실
-
다중 주문(복제됨)
|
예기치 않은 값이 입력됨
|
H
|
아래 나열되는 결과를 유발하는 트랜잭션은 허용되지 않습니다.
|
원인으로 위험성을 평가하는 방법은 영향으로 평가하는 방법과 반대입니다. 바람직하지 않은 이벤트나 조건 설명으로 시작하여 해당 조건을 가지도록 허용할 수 있는 이벤트 세트를 식별하십시오. 다음과 같이 질문하십시오.
"어떻게 하면 ___________할 수 있습니까?
예제:
-
"어떻게 하면 시스템에서 모든 레지스트리 항목이 아닌 파일 중 일부만 작성할 수 있습니까?"
-
"어떻게 하면 트랜잭션이 중앙 데이터베이스에 올바르게 반영되지 않습니까?"
-
"어떻게 하면 청구 주기 구문이 원하는 기준을 충족시키는 데이터베이스에서 레코드 중 일부를 반영할 수 있습니까?"
아래는 이러한 항목에 대한 샘플 이유 표입니다.
설명
|
위험성 크기
|
이유
|
누락/응용프로그램 파일 및 레지스트리 항목
|
H
|
응용프로그램(잠재적으로는 시스템)을 사용할 수 없게 됩니다. 설치 과정은 사용자가 보는 응용프로그램의 첫인상입니다. 어떤 이유에서든지 설치에 실패하면 사용자는 소프트웨어에 대해 좋지
않은 인상을 가지게 됩니다.
이러한 조건의 가능한 원인에는 다음이 포함됩니다.
-
설치 프로세스가 모든 파일을 올바르게 설치하지 않았거나 레지스트리가 제대로 갱신되지 않음
-
사용자 개입(취소 또는 종료)으로 설치 프로세스가 중단됨
-
소프트웨어/하드웨어 개입(디스크 공간 부족, 지원되지 않는 구성 등)으로 설치 프로세스가 중단됨
-
알 수 없는 조건으로 설치 프로세스가 중단됨
-
사용자가 파일/레지스트리 항목을 삭제
이러한 원인 중 마지막 내용만 설치 프로세스에서 발견하고 처리할 수 없습니다.
|
부분 주문
|
H
|
부분 주문은 이행되지 못하므로 고객도 줄고 수익도 감소합니다.
가능한 원인에는 다음이 포함됩니다.
-
사용자 조치(모뎀 연결 끊기, PC 끄기 등) 때문에 인터넷 연결이 끊어짐
-
IP 때문에 인터넷 연결이 끊어짐
-
직원 조치(모뎀 연결 끊기, 서버 전원 끄기 등) 때문에 인터넷 연결이 끊어짐
|
데이터베이스의 데이터 손상
|
H
|
데이터 손상은 어떤 이유로든 허용할 수 없습니다.
가능한 원인에는 다음이 포함됩니다.
-
사용자 개입으로 데이터베이스에 쓰는 트랜잭션이 완료되지 않았거나 확약되지 않음
-
인터넷 연결이 끊어져 데이터베이스에 쓰는 트랜잭션이 완료되지 않았거나 확약되지 않음
-
트랜잭션 시 사용자가 올바르지 않은 데이터를 입력
-
데이터베이스 액세스 방법/유틸리티
-
초기에 인스턴스화될 때 데이터베이스가 올바르게 채워지지 않음
|
복제된 주문
|
H
|
복제된 주문은 회사의 부담을 증가시키고 운송, 처리 및 재고와 관련된 비용으로 인해 수익이 줄어듭니다.
가능한 원인에는 다음이 포함됩니다.
-
데이터베이스에 주문을 쓰는 트랜잭션이 사용자의 개입으로 복제되었습니다. 사용자가 확인 과정 없이 주문을 두 번 입력했습니다.
-
데이터베이스에 주문을 쓰는 트랜잭션이 사용자 이외의 개입으로 복제되었습니다. 끊어진 인터넷 연결의 복구 과정이나 데이터베이스 복원 때문일 수 있습니다.
|
주문의 정확하지 않은 데이터
|
H
|
완료되지 않았거나 추가 비용 부담을 가져오는 주문은 허용되지 않습니다.
가능한 원인에는 다음이 포함됩니다.
-
사용자 개입으로 주문 트랜잭션이 완료되지 않았거나 확약되지 않음
-
인터넷 연결이 끊어져 주문 트랜잭션이 완료되지 않았거나 확약되지 않음
-
사용자가 올바르지 않은 데이터를 입력
|
구문에 잘못된 레코드 수가 반영됨
|
H
|
비즈니스 결정 및 외상 매출금은 이러한 보고서의 정확성에 의존합니다.
가능한 원인에는 다음이 포함됩니다.
-
정확하지 않은 검색/선택 기준
-
잘못된 SQL 문
-
데이터베이스의 데이터 손상
-
데이터베이스의 잘못된 데이터
|
가능성으로 위험성을 평가하는 방법은 유스 케이스 또는 유스 케이스를 구현하는 컴포넌트가 실패할 가능성을 결정하는 것입니다. 일반적으로 가능성은 다음과 같은 외부 요소를 기반으로 합니다.
이 위험성 관점을 사용하면 위험성 크기 지표는 실패 가능성과 관련이 있으며, 영향 및 원인으로 위험성을 평가할 때처럼 실패가 조직에 미치는 영향과는 관련이 없음에 유의하십시오.
이러한 요소와 존재하는 실패 가능성 사이의 상관이 아래 식별되어 있습니다.
외부 요소
|
가능성
|
실패 발견 비율
|
실패 가능성은 실패 발견 비율이나 밀도가 늘어감에 따라 증가합니다. 결함은 모이는 경향이 있으므로 유스 케이스나 컴포넌트에서 발견 비율 또는 결함 수(밀도)가 증가하면 다른 결함을
발견할 가능성도 증가합니다. 이전의 높은 발견 비율이나 밀도는 추가 실패를 발견할 가능성이 높음을 의미하므로, 이러한 요소를 사용하여 위험성을 평가할 경우 이전 릴리스의 발견 비율과
밀도도 고려해야 합니다.
|
변경률
|
유스 케이스나 컴포넌트에 대한 변경률이 증가하면 실패 가능성이 증가합니다. 그러므로 변경 수가 증가하면 결함을 발견할 가능성도 많아집니다. 코드를 변경할 때마다 다른 결함을 "발생시킬"
위험성이 있습니다.
|
복잡도
|
유스 케이스나 컴포넌트의 복잡도가 증가함에 따라 실패 가능성이 증가합니다.
|
생성지/제안자
|
코드 생성지에 대한 지식 및 경험과 실패 가능성을 늘리거나 줄일 수 있는 사람을 말합니다.
일반적으로 써드파티 컴포넌트를 사용하면 실패 가능성이 줄어듭니다. 그러나 이런 경우는 써드파티 컴포넌트가 요구사항을 충족하고 이전 테스트 또는 경험으로 인증을 받은 경우에만
적용됩니다.
일반적으로 구현자의 지식과 스킬이 늘어나면 실패 가능성은 줄어듭니다. 그러나 여러 역할 수행 또는 새로운 도구, 기술 또는 조치를 사용하는 경우 최고의 팀 구성원이 있다 하더라도 실패
가능성은 증가합니다.
|
예제:
-
새 소프트웨어 설치
-
"경험상 1, 10 및 12 유스 케이스를 구현하기 위해 사용되는 컴포넌트에서 많은 결함을 발견했고 고객은 14 및 19 유스 케이스에서 많은 변경을 요청했습니다."
아래는 이러한 항목에 대한 샘플 이유 표입니다.
설명
|
위험성 크기
|
이유
|
새 소프트웨어 설치
|
H
|
자체 설치 유틸리티를 작성하고 있습니다.
응용프로그램을 사용하지 못하게 됩니다. 설치 과정은 사용자가 보는 응용프로그램의 첫인상입니다. 어떤 이유에서든지 설치에 실패하면 사용자는 소프트웨어에 대해 좋지 않은 인상을
가지게 됩니다.
|
새 소프트웨어 설치
|
L
|
상업적으로 성공한 설치 유틸리티를 사용하고 있습니다.
설치에 실패하면 응용프로그램을 사용하지 못할 수 있으므로, 시장 점유율 1위이며 4년 이상 사업을 계속해온 벤더의 제품을 선택하여 설치 유틸리티로 사용합니다. 이에 대한 평가를
통해 제품이 요구사항을 충족시키고, 제품과 벤더, 서비스 및 지원 레벨에 고객이 만족하고 있음을 알 수 있습니다.
|
유스 케이스 1, 10, 12에서 실패 발견 비율 / 결함 밀도가 높음
|
H
|
1, 10 및 12 유스 케이스의 경우 이전의 실패 발견 비율과 결함 밀도가 높았기 때문에 위험성이 높은 것으로 간주됩니다.
|
14 및 19 유스 케이스에서 변경 요청
|
H
|
이러한 유스 케이스에 대한 변경이 많으면 코드에 결함을 발생시킬 가능성이 높아집니다.
|
위험성을 평가하고 테스트 우선순위를 설정하는 다음 단계는 테스트 대상의 운영 프로파일을 결정하는 것입니다.
다음과 같이 사용할 운영 프로파일 크기 지표를 식별 및 설명하여 시작하십시오.
-
H - 기간당 아주 자주, 많이 사용하거나 많은 액터 또는 유스 케이스가 사용합니다.
-
M - 기간당 자주, 몇 번 사용하거나 몇 개의 액터 또는 유스 케이스가 사용합니다.
-
L - 기간당 자주 사용하지 않거나 아주 적은 수의 액터나 유스 케이스가 사용합니다.
선택한 운영 프로파일 편집기는 다음을 포함하여 유스 케이스나 컴포넌트가 실행되는 빈도를 기반으로 해야 합니다.
-
주어진 기간에 한 액터나 유스 케이스가 유스 케이스나 컴포넌트를 실행하는 횟수
-
유스 케이스나 컴포넌트를 실행하는 액터 또는 유스 케이스 수
일반적으로 유스 케이스나 컴포넌트를 사용하는 횟수가 많을수록 운영 프로파일 지표가 높습니다.
운영 프로파일 크기 지표를 식별한 다음 테스트 대상에 각 유스 케이스 또는 컴포넌트를 나열하십시오. 목록에서 각 항목에 대한 운영 프로파일 지표를 결정하고 지표 값에 대한 이유를 설명하십시오. 워크로드 분석 문서의
정보(중간 산출물: 워크로드 분석 문서)가 이 평가에 사용될 수 있습니다.
예제:
-
새 소프트웨어 설치
-
온라인 카탈로그에서 항목 주문
-
주문 후 온라인으로 주문 내역을 조회하는 고객
-
항목 선택 대화 상자
설명
|
운영 프로파일 요소
|
이유
|
새 소프트웨어 설치
|
H
|
일반적으로 한 번 수행되지만 많은 사용자가 수행합니다. 그러나 설치하지 않으면 응용프로그램을 사용할 수 없습니다.
|
카탈로그에서 항목 주문
|
H
|
사용자가 실행하는 가장 일반적인 유스 케이스입니다.
|
고객이 주문을 조회
|
L
|
주문한 다음 내역을 조회하는 고객은 거의 없습니다.
|
항목 선택 대화 상자
|
H
|
이 대화 상자는 고객이 주문을 하고 재고 관리자가 재고를 채워넣는 데 사용됩니다.
|
위험성을 평가하고 테스트 우선순위를 설정하는 마지막 단계는 테스트 우선순위를 설정하는 것입니다.
다음과 같이 사용할 테스트 우선순위 크기 지표를 식별 및 설명하여 시작하십시오.
-
H - 테스트해야 함
-
M - 테스트해야 함, 모든 H 항목을 테스트한 후에 테스트함
-
L - 테스트할 수 있음, 모든 H 및 M 항목을 테스트한 후에 테스트함
테스트 우선순위 크기 지표를 식별한 다음 테스트 대상에 각 유스 케이스 또는 컴포넌트를 나열하십시오. 목록에서 각 항목에 대한 테스트 우선순위 지표를 결정하고 이유를 설명하십시오. 아래는 테스트 우선순위 지표
결정에 대한 가이드라인입니다.
각 항목에 대한 테스트 우선순위 지표를 결정할 때 다음을 고려하십시오.
-
이전에 식별한 위험성 크기 지표
-
이전에 식별한 운영 프로파일 크기 값
-
액터 설명(숙련된 액터입니까?, 임시 해결책을 허용합니까? 등)
-
계약상의 책임(유스 케이스나 컴포넌트가 전달되지 않는 경우 테스트 대상이 허용됩니까?)
테스트 우선순위를 설정하는 전략에는 다음이 포함됩니다.
-
전체적인 우선순위로 각 항목에 대해 가장 높게 평가된 요소(위험성, 운영 프로파일 등) 값을 사용합니다.
-
하나의 평가된 요소(위험성, 운영 프로파일, 기타)를 가장 중요한 사항으로 식별하고 해당 요소의 값을 우선순위로 사용합니다.
-
우선순위를 식별하기 위해 평가된 요소의 조합을 사용합니다.
-
개별 요소를 가중시키는 가중치 스키마를 사용하여, 해당 값과 계산된 우선순위는 가중치를 기반으로 합니다.
예제:
-
새 소프트웨어 설치
-
온라인 카탈로그에서 항목 주문
-
주문 후 온라인으로 주문 내역을 조회하는 고객
-
항목 선택 대화 상자
가장 높이 평가된 값을 사용하여 우선순위를 결정한 경우 우선순위는 다음과 같습니다.
항목
|
위험성
|
운영 프로파일
|
액터
|
계약
|
우선순위
|
새 소프트웨어 설치
|
H
|
H
|
L
|
H
|
H
|
카탈로그에서 항목 주문
|
H
|
H
|
H
|
H
|
H
|
고객 조회
|
L
|
L
|
L
|
L
|
L
|
항목 선택 대화 상자
|
L
|
H
|
L
|
L
|
H
|
한 요소(위험성)에서 가장 높이 평가된 값을 사용하여 우선순위를 결정하는 경우 우선순위는 다음과 같습니다.
항목
|
위험성
|
운영 프로파일
|
액터
|
계약
|
우선순위
|
새 소프트웨어 설치
|
H
|
H
|
L
|
H
|
H
|
카탈로그에서 항목 주문
|
H
|
H
|
H
|
H
|
H
|
고객 조회
|
L
|
L
|
L
|
L
|
L
|
항목 선택 대화 상자
|
L
|
H
|
L
|
L
|
L
|
가중치를 사용하여 우선순위를 결정한 경우 우선순위는 다음과 같습니다.
(참고: 아래 표에서 H = 5, M = 3 및 L = 1입니다. 총 가중치가 30보다 크면 높은 우선순위 테스트 항목, 20에서 30 사이의 값이면 중간 우선순위, 20 미만의 값이면 낮은 우선순위입니다.)
항목
|
위험성(x 3)
|
운영 프로파일(x 2)
|
액터(x 1)
|
계약(x 3)
|
가중치
|
우선순위
|
새 소프트웨어 설치
|
5(15)
|
5(10)
|
1(1)
|
5(15)
|
41
|
H(2)
|
카탈로그에서 항목 주문
|
5(15)
|
5(10)
|
5(5)
|
5(15)
|
45
|
H(1)
|
고객 조회
|
1(3)
|
1(2)
|
1(1)
|
1(3)
|
9
|
L(4)
|
항목 선택 대화 상자
|
1(3)
|
5(10)
|
1(1)
|
1(3)
|
17
|
L(3)
|
테스트 전략은 특정 테스트 노력의 일반적인 접근 방식 및 목표를 설명합니다.
좋은 테스트 전략은 다음을 포함해야 합니다.
구현할 테스트 유형과 테스트 목표를 분명하게 설명하십시오. 이러한 정보를 정확하게 지정하면 혼란을 줄이고 오해를 최소화할 수 있습니다(특히 일부 테스트는 매우 비슷하기 때문에 필요함). 목표는 이 테스트를 실행하는
이유를 분명하게 설명해야 합니다.
예제:
"기능 테스트. 기능 테스트는 사용자 인터페이스의 테스트 대상에서 구현되는 다음 유스 케이스를 실행하는 데 초점을 맞춥니다."
"성능 테스트. 시스템의 성능 테스트는 유스 케이스 2, 4 및 8 - 10의 응답 시간을 측정하는 데 초점을 맞춥니다. 이러한 테스트의 경우 단일 액터의 워크로드(테스트 시스템에서 다른 워크로드 없이 유스
케이스 실행)가 사용됩니다."
"구성 테스트. 구성 테스트는 세 가지 서로 다른 구성에서 테스트 대상의 동작을 식별하고 평가하기 위해 구현되고 성능 특성을 벤치마크 구성과 비교합니다."
테스트가 실행되는 단계를 분명하게 설명하십시오. 아래 식별된 내용은 공통 테스트가 실행되는 단계입니다.
|
테스트 단계
|
테스트 유형
|
유닛
|
통합
|
시스템
|
적합성
|
기능 테스트
(구성, 기능, 설치, 보안, 볼륨)
|
X
|
X
|
X
|
X
|
성능 테스트
(개별 컴포넌트의 성능 프로파일)
|
X
|
X
|
(X)
선택적 또는 시스템 성능 테스트가 결함을 발견할 때
|
|
성능 테스트
(로드, 스트레스, 경합)
|
|
|
X
|
X
|
신뢰성
(무결성, 구조)
|
X
|
X
|
(X)
선택적 또는 다른 테스트가 결함을 발견할 때
|
|
기법은 테스트를 어떻게 구현하고 실행할 것인지를 설명해야 합니다. 테스트 내용, 테스트 실행 중 취할 주요 조치 및 결과를 평가하는 데 사용되는 메소드를 포함합니다.
예제:
기능 테스트:
-
각 유스 케이스 이벤트 플로우에 대해 트랜잭션의 대표 세트가 식별되고, 유스 케이스를 실행할 때 각각은 액터가 수행하는 조치를 나타냅니다.
-
각 트랜잭션에 대해 최소 두 개의 테스트 케이스가 개발됩니다. 하나는 긍정적 조건을 반영하는 테스트 케이스이고 다른 하나는 부정적(허용 불가능) 조건을 반영하는 테스트 케이스입니다.
-
첫 번째 반복에서는 다음과 같은 방법으로 1 - 4 및 12 유스 케이스가 테스트됩니다.
-
유스 케이스 1:
-
유스 케이스 1은 액터가 기본 창에서 응용프로그램에 로그인하면 시작되며 사용자가 SAVE를 지정하면 종료됩니다.
-
각 테스트 케이스는 Rational Robot를 사용하여 구현되고 실행됩니다.
-
각 테스트 케이스의 실행 확인 및 평가는 다음 메소드를 사용하여 수행할 수 있습니다.
-
테스트 스크립트 실행(각 테스트 스크립트가 원하는 대로 성공적으로 실행되었습니까?)
-
테스트 스크립트에서 구현되는 창 존재(Window Existence) 또는 오브젝트 데이터(Object Data) 확인 메소드로 기본 창이 표시되어 있고,
테스트 실행 중 테스트 대상으로 지정한 데이터가 캡처되고 표시되는지 확인합니다.
-
테스트 중 실행된 변경이 정확하게 데이터에 반영되었는지 확인하기 위해 테스트 전과 테스트 후에 다시 테스트 대상 데이터베이스 (Microsoft Access
사용)를 점검합니다.
성능 테스트:
-
워크로드 분석 문서에서 식별된 내용과 같이 각 유스 케이스에 대해 트랜잭션 대표 세트가 Rational Suite PerformanceStudio(vu 스크립트) 및 Rational Robot(GUI
스크립트)를 사용하여 구현되고 실행됩니다.
-
다음을 포함하여 적어도 세 개의 워크로드가 테스트 스크립트 및 테스트 실행 스케줄에 반영됩니다.
-
극심한 워크로드: 750명의 사용자(관리자 15%, 판매 담당자 50%, 마케팅 담당자 35%)
-
최대 워크로드: 350명의 사용자(관리자 10%, 판매 담당자 60%, 마케팅 담당자 30%)
-
적은 워크로드: 150명의 사용자(관리자 2%, 판매 담당자 75%, 마케팅 담당자 23%)
-
각 트랜잭션을 실행하는 데 사용되는 테스트 스크립트는 워크로드 분석 문서에 정의된 내용과 같이 전체 트랜잭션 시간 및 주요 트랜잭션 타스크 또는 프로세스 시간과 같은 응답 시간을 캡처하기 위해 알맞은
타이머를 포함하고 있습니다.
-
테스트 스크립트는 1시간의 워크로드를 실행합니다(그렇지 않은 경우 워크 로드 분석 문서에 설명됨).
-
워크로드의 각 테스트 실행에 대한 확인 및 평가는 다음을 포함합니다.
-
테스트 및 워크로드가 예상했던 대로 실행되는지를 확인하기 위해 상태 히스토그램을 사용하여 테스트 실행을 모니터링합니다.
-
테스트 스크립트 실행(각 테스트 스크립트가 원하는 대로 성공적으로 실행되었습니까?)
-
다음 보고서를 사용하여 식별된 응답 시간을 캡처하고 평가합니다.
완료 기준은 다음의 두 가지 목적에 대해 설명됩니다.
-
허용 가능한 제품 품질 식별
-
테스트 노력이 성공적으로 구현되는 시기 식별
완료 기준의 분명한 설명에는 다음 항목을 포함해야 합니다.
-
측정된 기능, 동작 또는 조건
-
측정 방법
-
측정에 대한 준수 기준 또는 정도
예제 1
-
계획된 테스트 케이스가 모두 실행되었습니다.
-
식별된 결함이 합의된 해결 방법에 따라 모두 처리되었습니다.
-
계획된 테스트 케이스가 모두 실행되고 알려진 결함이 합의된 해결 방법에 따라 모두 처리되며 새로운 결함이 더 이상 발견되지 않았습니다.
예제 2
-
높은 우선순위의 테스트 케이스가 모두 실행되었습니다.
-
식별된 결함이 합의된 해결 방법에 따라 모두 처리되었습니다.
-
심각도 1 또는 2 결함이 모두 해결되었습니다(상태 = 수정됨 또는 연기됨).
-
높은 우선순위의 테스트 케이스가 모두 재실행되고 알려진 결함이 합의된 해결 방법에 따라 모두 처리되었으며 새로운 결함이 더 이상 발견되지 않았습니다.
예제 3
-
계획된 테스트 케이스가 모두 실행되었습니다.
-
식별된 결함이 합의된 해결 방법에 따라 모두 처리되었습니다.
-
심각도 1 또는 2 결함이 모두 해결되었습니다(상태 = 확인됨 또는 연기됨).
-
높은 우선순위의 테스트 케이스가 모두 재실행되고 알려진 결함이 합의된 해결 방법에 따라 모두 처리되었으며 새로운 결함이 더 이상 발견되지 않았습니다.
이 섹션은 테스트 정책에서 설명한 테스트 노력에 영향을 미칠 수 있는 영향력이나 종속성을 식별해야 합니다. 영향력에는 다음이 포함됩니다.
-
인적 자원(예: 테스트에 참여/지원하기 위한 테스트 이외 자원의 필요 또는 가용성)
-
제한조건(예: 장비 제한사항 또는 가용성, 특수 장비의 필요/부족)
-
테스트 스케줄 또는 시스템 액세스와 같은 특별 요구사항
예제:
-
테스트 데이터베이스에는 테스트 데이터를 작성하고, 갱신하며, 새로 고치는 데 데이터베이스 디자이너/ 관리자의 지원이 필요합니다.
-
시스템 성능 테스트는 기존 네트워크의 서버를 사용합니다(테스트 이외의 트래픽 지원). 업무 시간 후에 테스트하도록 스케줄하여 네트워크에 비테스트 트래픽이 없도록 해야 합니다.
-
전체 기능 테스트가 구현 또는 실행되려면 테스트 대상이 레거시 시스템을 동기화(또는 시뮬레이트 동기화)해야 합니다.
|