테스트 디자인 타스크에서, 두 개의 중요한 아티팩트인 테스트 스크립트 및 테스트 케이스가 식별되고 설명됩니다. 테스트 데이터가 없으면 이 두 개의 아티팩트를 구현하고 실행할 수 없습니다. 이는 단지 간결하게 식별할
구체적인 값이 없는 조건, 시나리오 및 경로 설명일 뿐입니다. 테스트 데이터는 자체가 아티팩트는 아니지만 테스트의 성공이나 실패에 많은 영향을 미칩니다. 다음에 대해 테스트 데이터가 필요하므로 테스트 데이터 없이는
테스트를 구현하고 실행할 수 없습니다.
-
조건을 작성하는 입력
-
요구사항을 평가하는 출력
-
지원(테스트에 대한 전제 조건)
그러므로 해당 값의 식별은 테스트 케이스를 식별할 때 수행되는 중요한 노력입니다( 중간 산출물:
테스트 케이스 및 가이드라인: 테스트 케이스 참조).
실제 테스트 데이터를 식별할 때 다뤄야 하는 다음과 같은 네 가지 테스트 데이터 속성이 있습니다.
-
깊이 - 테스트 데이터에서 데이터의 볼륨 또는 양
-
너비 - 테스트 데이터에서 변화의 정도
-
범위 - 테스트 목표에 대한 테스트 데이터의 관계
-
아키텍처 - 테스트 데이터의 실제 구조
각 특성이 아래 섹션에 자세하게 설명되어 있습니다.
깊이는 테스트에 사용되는 데이터의 볼륨 또는 양입니다. 깊이는 중요한 고려사항으로, 데이터가 너무 적으면 실제 조건을 반영하지 못하고 데이터가 너무 많으면 관리 및 유지보수가 힘듭니다. 이상적으로는 핵심 테스트
케이스(일반적으로 긍정적 테스트 케이스)를 지원하는 소규모 데이터로 테스트를 시작하는 것입니다. 테스트를 진행하면서 확신이 생기면 데이터 깊이가 배치된 환경(또는 적당하고 실현 가능한 환경) 수준이 되도록 테스트
데이터를 늘리십시오.
너비는 테스트 데이터 값이 변하는 정도를 참조합니다. 단지 레코드를 추가로 작성하여 테스트 데이터 깊이를 늘릴 수 있습니다. 이러한 방법은 종종 좋은 솔루션이 될 수 있지만 실제 데이터에서 볼 수 있을 것으로
기대되는 데이터의 실질적인 변동을 나타내지는 않습니다. 테스트 데이터에서 이러한 변동이 없으면 결함을 식별할 수 없습니다(예: ATM의 모든 인출금이 $50.00인 것은 아님). 그러므로 테스트 데이터의 값은
$10.00 인출 또는 $120.00 인출과 같이 배치된 환경에서 볼 수 있는 값을 반영해야 합니다. 또한 테스트 데이터는 다음과 같이 실제 정보를 반영해야 합니다.
-
직위, 숫자 값, 구두점 및 접미부를 포함하는 이름
-
Dr. James Bandlin, Ms. Susan Smith 및 Rev. Joseph P. Mayers
-
James Johnson III, Steven Wilshire 3rd 및 Charles James Ellsworth, Esq.
-
Ellen Jones-Smythe, Brian P. Tellstor
-
다음과 같은 여러 행의 주소
-
6500 Broadway Street
Suite 175
-
1550 Broadway
Floor 17
Mailstop 75A
-
실제 구/군/시 및 국가 코드와 전화 번호
-
Lexington, MA, USA + 01 781 676 2400
-
Kista, Sweden +46 8 56 62 82 00
-
Paris, France +33 1 30 12 09 50
테스트 데이터 값은 충분한 너비를 확보하기 위해 실제 데이터의 실제 표시이거나 통계적 표시일 수 있습니다. 두 방법 모두 가치가 있고 권장됩니다.
배치된 데이터의 실제 표시를 기반으로 테스트 데이터를 작성하려면, 배치된 데이터베이스에서 각 데이터 요소에 대한 허용 가능 값 또는 범위를 식별하고, 각 데이터 요소에 대하여 테스트 데이터에서 적어도 하나의
레코드가 허용 가능한 각 값을 포함하도록 하십시오.
예제:
|
계정 번호(범위)
|
PIN 번호
(정수)
|
계정 잔액
(10진수)
|
계정 유형
(문자열)
|
(S) 0812 0000 0000 -
0812 9999 9999
© 0829 0000 0000 -
0829 9999 9999
(X) 0799 0000 0000 -
0799 9999 9999
|
0000 - 9999
|
-999,999.99 - 999,999.99
|
S, C, X
|
레코드 1
|
0812 0837 0293
|
8493
|
-3,123.84
|
S
|
레코드 2
|
0812 6493 8355
|
3558
|
8,438.53
|
S
|
레코드 3
|
0829 7483 0462
|
0352
|
673.00
|
C
|
레코드 4
|
0799 4896 1893
|
4896
|
493,498.49
|
X
|
위 매트릭스는 허용 가능한 데이터 값을 실제로 나타내는 최소 레코드 수를 포함합니다. 해당 계정 번호의 경우, 세 개의 각 범위에 대해 하나의 레코드가 있고, 모든 PIN 번호가 지정된 범위에 있으며, 몇 개의
서로 다른 계정 잔액이 있고(하나의 마이너스 잔액 포함), 서로 다른 각 계정 유형에 대한 레코드가 존재합니다. 위 매트릭스는 최소 데이터이며, 우수 사례에서는 범위 내 뿐만 아니라 각 범위 한계에서 데이터 값을
갖게 됩니다(가이드라인: 테스트 케이스 참조).
실제 표시의 장점은 테스트 데이터의 크기가 제한되고 관리 가능하며 허용 가능한 값을 목표로 초점을 맞춘다는 것입니다. 그러나 단점은 실제 데이터가 완전하게 무작위는 아니라는 것입니다. 실제 데이터는 성능에 영향을
미칠 수 있는 통계적 프로파일을 가지는 경향이 있는데, 이는 실제 표시를 사용할 때는 관찰되지 않습니다.
통계 테스트 데이터 표시는 프로덕션 데이터의 통계 샘플링(동일한 백분율)을 반영하는 테스트 데이터입니다. 예를 들어, 위와 같은 데이터 요소를 사용하여 프로덕션 데이터베이스를 분석하고 다음을 발견하는 경우,
-
레코드 총계: 294,031
-
S 계정 유형 총계: 141,135(전체의 48%)
-
C 계정 유형 총계: 144,075(49%)
-
X 계정 유형 총계: 8,821(3%)
-
계정 번호 및 PIN 번호는 균등하게 분포됨
테스트 데이터는 통계적 샘플링을 기반으로 294개의 레코드를 포함합니다(위에서 본 네 개의 레코드와 비교됨).
|
테스트 데이터(프로덕션의 .1%)
|
레코드 수
|
백분율
|
레코드 총계
|
294
|
100
|
계정 번호
(S) 0812 0000 0000 -
0812 9999 9999
|
141
|
48
|
계정 번호
© 0829 0000 0000 -
0829 9999 9999
|
144
|
49
|
계정 번호
(X) 0799 0000 0000 -
0799 9999 9999
|
9
|
3
|
위 매트릭스는 계정 유형만 다룹니다. 통계적 표시를 기반으로 최상의 테스트 데이터를 개발하려면 중요한 데이터 요소를 포함시키게 됩니다. 위 예제에서는 실제 계정 잔액 반영이 여기에 해당됩니다.
통계적 표시의 단점은 허용 가능한 값의 전체 범위를 반영하지 않는다는 것입니다.
일반적으로 테스트 데이터를 식별하는 두 방법을 모두 사용하여, 테스트 데이터가 모든 값과 성능/모집단 문제를 다루도록 합니다.
테스트 데이터 너비는 테스트를 지원하기 위해 사용되는 테스트 데이터(기존에 존재하는 데이터) 뿐만 아니라 입력으로 사용되는 테스트 데이터와도 관련이 있습니다.
범위는 테스트 목표에 대한 테스트 데이터의 관계이며, 깊이 및 너비와 관련이 있습니다. 많은 양의 데이터를 가진다고 해서 올바른 데이터라는 의미는 아닙니다. 테스트 데이터 너비를 사용하여 테스트 데이터가 테스트
목표와 관계가 있음을 확인해야 합니다. 즉, 특정 테스트 목표를 지원하는 테스트 데이터가 있도록 해야 합니다.
예를 들어, 아래 매트릭스에서 처음 네 개의 테스트 데이터 레코드는 각 데이터 요소에 대해 허용 가능한 값을 다룹니다. 그러나 C 및 X 계정 유형에 대해 마이너스 잔액을 평가할 레코드가 없습니다. 따라서 이
테스트 데이터가 마이너스 잔액을 올바로 포함해도(올바른 너비), 해당 범위의 아래 데이터는 각 계정 유형에 대해 마이너스 계정 잔액을 사용한 테스트를 지원하기에 충분하지 않습니다. 이러한 실수를 해결하려면 서로
다른 각 계정 유형에 대해 마이너스 잔액을 포함시키는 등 추가 레코드를 포함시켜 이 데이터를 확장해야 합니다.
|
계정 번호(범위)
|
PIN 번호
(정수)
|
계정 잔액
(10진수)
|
계정 유형
(문자열)
|
(S) 0812 0000 0000 -
0812 9999 9999
© 0829 0000 0000 -
0829 9999 9999
(X) 0799 0000 0000 -
0799 9999 9999
|
0000 - 9999
|
-999,999.99 - 999,999.99
|
S, C, X
|
레코드 1
|
0812 0837 0293
|
8493
|
-3,123.84
|
S
|
레코드 2
|
0812 6493 8355
|
3558
|
8,438.53
|
S
|
레코드 3
|
0829 7483 0462
|
0352
|
673.00
|
C
|
레코드 4
|
0799 4896 1893
|
4896
|
493,498.49
|
X
|
새 레코드 1
|
0829 3491 4927
|
0352
|
-995,498.34
|
C
|
새 레코드 2
|
0799 6578 9436
|
4896
|
-64,913.87
|
X
|
테스트 데이터 너비는 테스트를 지원하기 위해 사용되는 테스트 데이터(기존에 존재하는 데이터) 뿐만 아니라 입력으로 사용되는 테스트 데이터와도 관련이 있습니다.
테스트 데이터의 실제 구조는 테스트를 지원하기 위해 테스트 대상이 사용하는 기존에 존재하는 데이터와만 관련됩니다(예: 응용프로그램의 데이터베이스 또는 규칙 테이블).
테스트는 한 번만 실행되고 끝나지는 않습니다. 테스트가 반복 사이에서 되풀이됩니다. 테스트를 일관되고 확실하며 효율적으로 실행하려면, 테스트 실행에 앞서 테스트 데이터를 초기 상태로 되돌려야 합니다. 테스트를
자동으로 실행할 때는 특히 그렇습니다.
그러므로 테스트의 무결성, 확신성 및 효율성을 보증하기 위해 테스트 데이터는 모든 외부적인 영향으로부터 자유로워야 하며, 테스트 실행을 시작하거나, 진행하거나, 종료할 때 상태가 알려져야 합니다. 이러한 테스트
목표를 달성하기 위해 다뤄야 할 두 가지 문제가 있습니다.
-
불안정성/격리 - 테스트 데이터 외부 영향 분리
-
초기 상태 - 데이터의 특정 초기 상태 인식 및 이 상태로 돌아가는 능력
이러한 각각의 문제는 테스트 데이터베이스 관리 방법, 테스트 모델 디자인 방법 및 다른 역할과의 상호작용 방법에 영향을 미칩니다.
다음과 같은 이유로 테스트 데이터가 안정되지 않을 수 있습니다.
-
테스트와 관련 없는 외부 영향으로 데이터가 수정됨
-
다른 사람이 어떤 데이터를 사용하는지를 다른 테스터가 모름
테스트의 신뢰성과 무결성을 유지하기 위해 테스트 데이터는 고도로 제어되어야 하고 이러한 영향과는 격리되어야 합니다. 테스트 데이터를 격리시키는 전략은 다음과 같습니다.
-
테스트 환경을 독립시키십시오. 테스터는 실제로 다른 환경으로부터 독립된 자체 테스트 환경을 가져야 합니다. 테스터는 아무 것도 공유해서는 안되며, 자체 테스트 대상 및 데이터를 가져야 합니다. 예를 들어 각
테스터가 자신의 PC를 사용함으로써 이를 달성할 수 있습니다.
-
테스트 데이터 기본 인스턴스를 독립시켜야 합니다. 테스터는 다른 모든 영향과 격리된 자체 데이터 인스턴스를 가져야 합니다. 테스트 대상이라 하더라도 실제 환경은 공유될 수 있지만 각 테스터가 자체 데이터
인스턴스를 가지면 테스트 데이터가 손상되는 위험성을 최소화할 수 있습니다.
-
테스트 데이터/데이터베이스를 파티션하십시오. 모든 테스터가 데이터베이스를 공유하고 다른 사람이 사용하고 있는 데이터에 대해 알아야 합니다(또한 다른 테스터의 데이터 사용은 금지). 예를 들어, 한 테스터가
0 - 99 사이의 레코드를 사용하면 다른 테스터는 100 - 199 사이의 레코드를 사용합니다. 또 어떤 테스터가 성이 Aa - Kz인 고객을 다루면 다른 테스터는 La - Zz라는 이름의 환자를
다룹니다.
해결해야 하는 다른 테스트 데이터 아키텍처 문제는 테스트 실행을 시작할 때의 테스트 데이터 초기 상태입니다. 이는 자동화된 테스트를 사용할 때 특히 문제가 될 수 있습니다. 테스트 대상이 알려지고 바람직한 상태에서
테스트 실행을 시작해야 하는 것처럼 테스트 데이터도 마찬가지여야 합니다. 이렇게 하면 각 테스트 실행이 이전과 동일하다는 반복성과 확신성을 가질 수 있습니다.
이러한 문제를 해결하기 위해 네 가지 전략이 공통적으로 사용됩니다.
-
데이터 새로 고치기
-
데이터 다시 초기화
-
데이터 재설정
-
데이터 롤 포워드
각각의 세부사항은 아래와 같습니다.
사용되는 방법은 몇 가지 요소에 따라 달라집니다. 여기에는 데이터베이스의 실제 특성, 테스터의 기술적인 역량, 외부(테스트 이외의) 역할의 가용성 및 테스트 대상이 포함됩니다.
테스트 데이터를 초기 상태로 되돌릴 수 있는 가장 바람직한 방법은 데이터 새로 고치기입니다. 이 방법은 초기 상태의 데이터베이스 사본을 작성하고 저장합니다. 테스트 실행 완료 시 또는 테스트 실행에 앞서 아카이브된
테스트 데이터베이스 사본이 사용하려는 테스트 환경에 복사됩니다. 이렇게 하면 테스트 데이터의 초기 상태가 각 테스트 실행 시작 때와 같아집니다.
이 방법의 장점은 데이터를 몇 가지 서로 다른 초기 상태로 아카이브할 수 있다는 것입니다. 예를 들어, 테스트 데이터는 하루, 주말, 월말 단위 상태로 아카이브될 수 있습니다. 이렇게 하면 테스터는 월말 유스
케이스 테스트와 같은 테스트를 지원하기 위해 특정한 상태로 신속하게 새로 고칠 수 있습니다.
데이터를 새로 고칠 수 없는 경우, 다음으로 좋은 방법은 특정한 프로그래밍 수단을 사용하여 데이터를 초기 상태로 복원하는 것입니다. 데이터 다시 초기화는 특수한 유스 케이스와 도구를 사용하여 테스트 데이터를
초기값으로 되돌립니다.
데이터에 오류가 도입되지 않도록 모든 데이터, 관계 및 주요 값이 올바른 초기값으로 돌아갔는지를 확인해야 합니다.
이러한 방법의 장점은 데이터베이스에서 올바르지 않은 값의 테스트를 지원한다는 것입니다. 정상적인 조건 하에서 올바르지 않은 데이터 값은 트랩되어 데이터로 입력되지 않습니다(예: 클라이언트의 유효성 검증 규칙에
의해). 그러나 다른 액터가 데이터에 영향을 미칠 수 있습니다(예: 다른 시스템의 전자적 갱신). 발생 방법과는 별도로, 올바르지 않은 데이터가 알맞게 식별되고 처리되었는지에 확인하는 테스트가 필요합니다.
데이터를 초기 상태로 되돌리는 간단한 방법은 테스트 중 데이터에 수행한 "변경을 되돌리는" 것입니다. 이 방법은 테스트 대상을 사용하여 되돌리는 항목을 입력함으로써 수행됩니다. 즉, 삭제된 레코드/값을 추가하고
수정된 레코드/값의 수정을 취소하며 추가된 데이터를 삭제합니다.
그러나 이 방법과 관련된 위험성은 다음과 같습니다.
-
일부가 아닌 모든 조치를 되돌려야 함
-
테스트 대상의 유스 케이스에 의존함(데이터 재설정에 사용하기 전에 테스트하여 올바른 기능성을 확인해야 함)
-
데이터베이스 키, 색인 및 위치는 재설정할 수 없음
이 방법이 사용자 테스트 환경에서 사용할 수 있는 유일한 방법이면, 데이터베이스 키, 색인 및 포인터를 검증하는 기본 대상으로 사용하지 마십시오. 예를 들어, 환자가 데이터베이스에 추가되었는지 여부를 판별할 때
시스템이 생성한 환자 ID 번호를 사용하는 대신 환자 이름 필드를 사용하십시오.
데이터 롤 포워드는 테스트 데이터의 초기 상태를 다루는 데 가장 권장되지 않는 방법입니다. 이 방법은 문제를 실질적으로 해결하지 못합니다. 대신 테스트 실행 완료 시점에서 데이터 상태가 테스트 데이터의 새 초기
상태가 됩니다. 일반적으로 이렇게 하려면 입력에 사용되는 테스트 데이터 및/또는 결과를 평가하는 데 사용되는 테스트 케이스 및 테스트 데이터를 수정해야 합니다.
이런 작업이 필요한 몇몇 인스턴스가 있습니다(예: 월말). 월말 이전의 데이터 아카이브가 없으면 데이터를 월말 처리 테스트에 필요한 상태로 "롤 포워드"하도록 각 일 및 주의 테스트 데이터와 테스트 스크립트를
실행해야 합니다.
이 방법과 관련된 위험성은 다음과 같습니다.
-
데이터베이스 키, 색인 및 위치는 재설정할 수 없고 검증에 사용할 수 없음
-
데이터가 계속 변경됨
-
결과를 검증하기 위해 추가 노력이 필요함
|