what is test data test data preparation techniques with example
테스트 데이터 란 무엇이며 테스트를 위해 테스트 데이터를 준비하는 방법을 알아보십시오.
정보 및 기술의 혁명적 인 성장의 현재 서사시에서 테스터는 일반적으로 소프트웨어 테스트 라이프 사이클에서 테스트 데이터의 광범위한 소비를 경험합니다.
테스터는 기존 소스에서 데이터를 수집 / 유지 관리 할뿐만 아니라 실제 사용을 위해 제품을 제공 할 때 품질이 급증하는 데 기여할 수 있도록 엄청난 양의 테스트 데이터를 생성합니다.
따라서 테스터로서 우리는 모든 유형의 기능 및 비 기능 테스트에 대한 데이터 수집, 생성, 유지 관리, 자동화 및 포괄적 인 데이터 관리를위한 가장 효율적인 접근 방식을 지속적으로 탐색, 학습 및 적용해야합니다.
이 튜토리얼에서는 부적절한 데이터와 불완전한 테스트 환경 설정으로 인해 중요한 테스트 케이스를 놓치지 않도록 테스트 데이터를 준비하는 방법에 대한 팁.
학습 내용 :
테스트 데이터 란 무엇이며 중요한 이유
2016 년 IBM에서 실시한 연구에 따르면 테스트 데이터 검색, 관리, 유지 관리 및 생성은 테스터 시간의 30 % -60 %를 차지합니다. 데이터 준비가 소프트웨어 테스트에서 시간이 많이 걸리는 단계라는 것은 부인할 수없는 증거입니다.
그림 1 : 테스터가 TDM에서 보낸 평균 시간
그럼에도 불구하고 대부분의 데이터 과학자가 모델 개발 시간의 50 % -80 %를 데이터 구성에 사용하는 것은 다양한 분야에서 사실입니다. 이제 법규와 개인 식별 정보 (PII)를 고려하면 테스터의 참여가 테스트 과정에서 압도적으로 괜찮은 수준으로 만들어집니다.
오늘날 테스트 데이터의 신뢰성과 신뢰성은 비즈니스 소유자에게 타협하지 않는 요소로 간주됩니다. 제품 소유자는 테스트 데이터의 고스트 사본을 가장 큰 문제로보고 있으며, 이로 인해 고객의 품질 보증에 대한 요구 / 요구 사항이 고유 한시기에 모든 애플리케이션의 신뢰성이 저하됩니다.
테스트 데이터의 중요성을 고려할 때 대부분의 소프트웨어 소유자는 보안 조치에서 가짜 데이터 이하의 테스트 된 애플리케이션을 허용하지 않습니다.
이 시점에서 우리는 왜 테스트 데이터가 무엇인지 기억하지 않습니까? 테스트 대상 애플리케이션의 주어진 기능과 개발 된 시나리오를 확인하고 검증하기 위해 테스트 케이스를 작성하기 시작할 때, 결함을 식별하고 찾기위한 테스트를 수행하기위한 입력으로 사용되는 정보가 필요합니다.
경험이 풍부한 PDF에 대한 SQL Server 2012 인터뷰 질문 및 답변
그리고 우리는이 정보가 버그를 제거하기 위해 정확하고 완전해야한다는 것을 알고 있습니다. 이것이 우리가 테스트 데이터라고 부르는 것입니다. 정확하게하기 위해 이름, 국가 등이 될 수 있습니다. 연락처 정보, SSN, 의료 기록 및 신용 카드 정보와 관련된 데이터는 본질적으로 민감하지 않습니다.
데이터는 다음과 같은 형식 일 수 있습니다.
- 시스템 테스트 데이터
- SQL 테스트 데이터
- 성능 테스트 데이터
- XML 테스트 데이터
테스트 케이스를 작성하는 경우 모든 종류의 테스트에 대한 입력 데이터가 필요합니다. 테스터는 테스트 케이스를 실행할 때이 입력 데이터를 제공하거나 애플리케이션이 사전 정의 된 데이터 위치에서 필요한 입력 데이터를 선택할 수 있습니다.
데이터는 응용 프로그램에 대한 모든 종류의 입력, 응용 프로그램에서로드하는 모든 종류의 파일 또는 데이터베이스 테이블에서 읽은 항목 일 수 있습니다.
적절한 입력 데이터를 준비하는 것은 테스트 설정의 일부입니다. 일반적으로 테스터는이를 테스트 베드 준비 . 테스트 베드에서 모든 소프트웨어 및 하드웨어 요구 사항은 사전 정의 된 데이터 값을 사용하여 설정됩니다.
데이터 구축을위한 체계적인 접근 방식이없는 경우 테스트 케이스 작성 및 실행 중요한 테스트 케이스를 놓칠 가능성이 있습니다. 테스터는 테스트 요구에 따라 자신의 데이터를 만들 수 있습니다.
다른 테스터가 만든 데이터 나 표준 프로덕션 데이터에 의존하지 마세요. 항상 요구 사항에 따라 새로운 데이터 세트를 생성하십시오.
때로는 모든 빌드에 대해 완전히 새로운 데이터 세트를 생성 할 수 없습니다. 이러한 경우 표준 프로덕션 데이터를 사용할 수 있습니다. 그러나이 기존 데이터베이스에 자신의 데이터 세트를 추가 / 삽입하는 것을 잊지 마십시오. 데이터를 생성하는 가장 좋은 방법 중 하나는 기존 샘플 데이터 또는 테스트 베드를 사용하고 테스트를 위해 동일한 모듈을 얻을 때마다 새 테스트 케이스 데이터를 추가하는 것입니다. 이렇게하면 해당 기간 동안 포괄적 인 데이터 세트를 구축 할 수 있습니다.
테스트 데이터 소싱 과제
테스터가 고려하는 테스트 데이터 생성 영역 중 하나는 하위 집합에 대한 데이터 소싱 요구 사항입니다. 예를 들어, 100 만 명 이상의 고객이 있고 테스트를 위해 1000 명이 필요합니다. 그리고이 샘플 데이터는 일관되고 통계적으로 대상 그룹의 적절한 분포를 나타내야합니다. 즉, 우리는 유스 케이스를 테스트하는 가장 유용한 방법 중 하나 인 테스트 할 적절한 사람을 찾아야합니다.
그리고이 샘플 데이터는 일관되고 통계적으로 대상 그룹의 적절한 분포를 나타내야합니다. 즉, 우리는 유스 케이스를 테스트하는 가장 유용한 방법 중 하나 인 테스트 할 적절한 사람을 찾아야합니다.
또한 프로세스에는 몇 가지 환경 적 제약이 있습니다. 그중 하나는 PII 정책을 매핑하는 것입니다. 프라이버시가 중요한 장애물이므로 테스터는 PII 데이터를 분류해야합니다.
테스트 데이터 관리 도구 언급 된 문제를 해결하도록 설계되었습니다. 이러한 도구는 보유한 표준 / 카탈로그를 기반으로 정책을 제안합니다. 그러나 그것은 그다지 안전한 운동은 아닙니다. 여전히 자신이하는 일에 대한 감사 기회를 제공합니다.
현재 및 미래의 과제를 해결하려면 항상 TDM을 언제 / 어디에서 시작해야합니까?와 같은 질문을해야합니다. 무엇을 자동화해야합니까? 회사는 인적 자원의 지속적인 기술 개발 및 최신 TDM 도구 사용 영역의 테스트에 얼마나 많은 투자를 할당해야합니까? 기능 테스트 또는 비 기능 테스트를 시작해야합니까? 그리고 훨씬 더 가능성이 높은 질문입니다.
테스트 데이터 소싱의 가장 일반적인 과제 중 일부는 다음과 같습니다.
- 팀에 적절한 테스트 데이터 생성 도구 지식과 기술이 없을 수 있습니다.
- 테스트 데이터 범위는 종종 불완전합니다.
- 수집 단계에서 볼륨 사양을 다루는 데이터 요구 사항의 명확성이 떨어짐
- 테스트 팀은 데이터 소스에 액세스 할 수 없습니다.
- 개발자가 테스터에게 프로덕션 데이터 액세스 권한을 부여하는 데 지연
- 개발 된 비즈니스 시나리오를 기반으로하는 테스트에 프로덕션 환경 데이터를 완전히 사용하지 못할 수 있습니다.
- 주어진 시간에 많은 양의 데이터가 필요할 수 있음
- 일부 비즈니스 시나리오를 테스트하기위한 데이터 종속성 / 조합
- 테스터는 데이터 수집을 위해 설계자, 데이터베이스 관리자 및 BA와 통신하는 데 필요한 시간보다 더 많은 시간을 보냅니다.
- 대부분 데이터는 테스트 실행 중에 생성되거나 준비됩니다.
- 여러 애플리케이션 및 데이터 버전
- 여러 애플리케이션에 걸친 지속적인 릴리스주기
- 개인 식별 정보 (PII)를 관리하기위한 법률
데이터 테스트의 흰색 상자 쪽에서 개발자는 프로덕션 데이터를 준비합니다. 이것이 QA가 AUT의 테스트 범위를 확대하기 위해 개발자와 접촉 기반을 작업해야하는 곳입니다. 가장 큰 과제 중 하나는 가능한 모든 시나리오 (100 % 테스트 사례)를 가능한 모든 부정적인 사례와 통합하는 것입니다.
이 섹션에서는 테스트 데이터 문제에 대해 설명했습니다. 그에 따라 해결 한 과제를 더 추가 할 수 있습니다. 그런 다음 테스트 데이터 설계 및 관리를 처리하는 다양한 접근 방식을 살펴 보겠습니다.
테스트 데이터 준비를위한 전략
우리는 테스트 업계의 플레이어가 테스트 노력과 가장 중요한 비용 효율성을 향상시키기 위해 지속적으로 다양한 방법과 수단을 경험하고 있음을 일상적으로 알고 있습니다. 정보 및 기술 진화의 짧은 과정에서 도구가 생산 / 테스트 환경에 통합 될 때 출력 수준이 크게 증가하는 것을 보았습니다.
테스트의 완전성과 전체 범위에 대해 이야기 할 때 주로 데이터의 품질에 달려 있습니다. 테스트는 소프트웨어의 품질을 얻기위한 중추이기 때문에 테스트 데이터는 테스트 프로세스의 핵심 요소입니다.
그림 2 : 테스트 데이터 관리 (TDM) 전략
매핑 규칙을 기반으로 플랫 파일 생성. 개발자가 애플리케이션을 설계하고 코딩 한 프로덕션 환경에서 필요한 데이터의 하위 집합을 만드는 것은 항상 실용적입니다. 실제로이 접근 방식은 테스터의 데이터 준비 노력을 줄이고 추가 비용을 피하기 위해 기존 리소스의 사용을 극대화합니다.
일반적으로 데이터를 생성하거나 최소한 각 프로젝트가 처음에 가지고있는 요구 사항 유형에 따라 데이터를 식별해야합니다.
TDM 프로세스를 처리하는 다음 전략을 적용 할 수 있습니다.
- 프로덕션 환경의 데이터
- 클라이언트의 기존 데이터베이스에서 데이터를 추출하는 SQL 쿼리 검색
- 자동화 된 데이터 생성 도구
테스터는 여기 그림 -3에 표시된 요소를 고려하여 완전한 데이터로 테스트를 백업해야합니다. 애자일 개발 팀의 resters는 테스트 케이스를 실행하는 데 필요한 데이터를 생성합니다. 테스트 케이스라고하면 화이트 박스, 블랙 박스, 성능, 보안 등 다양한 유형의 테스트 케이스를 의미합니다.
이 시점에서 성능 테스트를위한 데이터는 주어진 워크로드에서 시스템이 실제에 매우 가깝거나 상당한 커버리지를 가진 대량의 라이브 데이터에 얼마나 빠르게 응답하는지 결정할 수 있어야한다는 것을 알고 있습니다.
화이트 박스 테스트를 위해 개발자는 가능한 한 많은 분기, 프로그램 소스 코드의 모든 경로 및 부정적인 API (Application Program Interface)를 포함하는 데 필요한 데이터를 준비합니다.
그림 3 : 테스트 데이터 생성 활동
결국 우리는 소프트웨어 개발 라이프 사이클에서 일하는 모든 사람들이 ( SDLC ) BA와 같이 개발자 및 제품 소유자는 테스트 데이터 준비 과정에 잘 참여해야합니다. 공동의 노력이 될 수 있습니다. 이제 손상된 테스트 데이터 문제로 안내하겠습니다.
손상된 테스트 데이터
기존 데이터에 대한 테스트 케이스를 실행하기 전에 데이터가 손상 / 오래되지 않았는지, 테스트중인 애플리케이션이 데이터 소스를 읽을 수 있는지 확인해야합니다. 일반적으로 테스트 환경에서 AUT의 서로 다른 모듈에 대해 동시에 작업하는 테스터 이상의 경우 데이터가 손상 될 가능성이 매우 높습니다.
동일한 환경에서 테스터는 테스트 케이스의 필요 / 요구 사항에 따라 기존 데이터를 수정합니다. 대부분 테스터가 데이터 작업을 마치면 데이터를 그대로 둡니다. 다음 테스터가 수정 된 데이터를 선택하고 테스트를 다시 실행하자마자 코드 오류나 결함이 아닌 특정 테스트 실패의 가능성이 있습니다.
대부분의 경우 데이터가 손상되거나 오래되어 오류가 발생하는 방식입니다. 데이터 불일치를 방지하고 최소화하기 위해 아래와 같은 솔루션을 적용 할 수 있습니다. 물론이 튜토리얼의 끝 부분에 댓글 섹션에서 더 많은 솔루션을 추가 할 수 있습니다.
- 데이터 백업
- 수정 된 데이터를 원래 상태로 되돌립니다.
- 테스터 간의 데이터 분할
- 데이터 변경 / 수정에 대해 데이터웨어 하우스 관리자에게 최신 정보 제공
테스트 환경에서 데이터를 그대로 유지하는 방법은 무엇입니까?
대부분의 경우 많은 테스터가 동일한 빌드를 테스트해야합니다. 이 경우 둘 이상의 테스터가 공통 데이터에 액세스 할 수 있으며 필요에 따라 공통 데이터 세트를 조작하려고합니다.
특정 모듈에 대한 데이터를 준비한 경우 데이터 세트를 그대로 유지하는 가장 좋은 방법은 동일한 백업 사본을 유지하는 것입니다.
성능 테스트 사례에 대한 테스트 데이터
성능 테스트에는 매우 큰 데이터 세트가 필요합니다. 때때로 데이터를 수동으로 생성해도 테스트중인 응용 프로그램에서 생성 된 실제 데이터에 의해서만 잡힐 수있는 미묘한 버그가 감지되지 않습니다. 수동으로 생성 할 수없는 실시간 데이터를 원하면 리드 / 관리자에게 라이브 환경에서 사용할 수 있도록 요청하십시오.
이 데이터는 모든 유효한 입력에 대해 응용 프로그램의 원활한 기능을 보장하는 데 유용합니다.
이상적인 테스트 데이터는 무엇입니까?
데이터 세트의 최소 크기에 대해 모든 애플리케이션 오류를 식별하는 경우 데이터가 이상적이라고 할 수 있습니다. 모든 애플리케이션 기능을 통합 할 데이터를 준비하지만 데이터 준비 및 테스트 실행을위한 비용 및 시간 제약을 초과하지 않도록하십시오.
최대 테스트 범위를 보장 할 데이터를 준비하는 방법은 무엇입니까?
다음 범주를 고려하여 데이터를 설계하십시오.
1) 데이터 없음 : 공백 또는 기본 데이터에서 테스트 케이스를 실행하십시오. 적절한 오류 메시지가 생성되는지 확인하십시오.
2) 유효한 데이터 세트 : 응용 프로그램이 요구 사항에 따라 작동하고 유효한 입력 데이터가 데이터베이스 또는 파일에 제대로 저장되었는지 확인하기 위해 생성합니다.
3) 잘못된 데이터 세트 : 음수 값, 영숫자 문자열 입력에 대한 애플리케이션 동작을 확인하려면 유효하지 않은 데이터 세트를 준비하십시오.
4) 잘못된 데이터 형식 : 잘못된 데이터 형식의 데이터 세트를 만듭니다. 시스템은 유효하지 않거나 잘못된 형식의 데이터를 허용하지 않아야합니다. 또한 적절한 오류 메시지가 생성되는지 확인하십시오.
5) 경계 조건 데이터 세트 : 범위를 벗어난 데이터를 포함하는 데이터 세트입니다. 애플리케이션 경계 사례를 식별하고 하한 및 상한 경계 조건을 다룰 데이터 세트를 준비합니다.
6) 성능, 부하 및 스트레스 테스트를위한 데이터 세트 : 이 데이터 세트는 볼륨이 커야합니다.
이렇게하면 각 테스트 조건에 대해 별도의 데이터 세트를 생성하여 완전한 테스트 범위를 보장합니다.
블랙 박스 테스트 데이터
품질 보증 테스터는 통합 테스트, 시스템 테스트 및 블랙 박스 테스트로 알려진 승인 테스트를 수행합니다. 이 테스트 방법에서 테스터는 테스트중인 애플리케이션의 내부 구조, 디자인 및 코드에 대한 작업이 없습니다.
테스터의 주요 목적은 오류를 식별하고 찾는 것입니다. 그렇게함으로써 우리는 블랙 박스 테스트의 다양한 기술을 사용하여 기능적 또는 비 기능적 테스트를 적용합니다.
그림 4 : 블랙 박스 데이터 설계 방법
이 시점에서 테스터는 블랙 박스 테스트 기술을 실행하고 구현하기위한 입력으로 테스트 데이터가 필요합니다. 그리고 테스터는 주어진 비용과 시간을 초과하지 않고 모든 애플리케이션 기능을 검사 할 데이터를 준비해야합니다.
데이터 없음, 유효한 데이터, 유효하지 않은 데이터, 불법 데이터 형식, 경계 조건 데이터, 등가 파티션, 의사 결정 데이터 테이블, 상태 전이 데이터 및 사용 사례 데이터와 같은 데이터 세트 범주를 고려하여 테스트 사례에 대한 데이터를 설계 할 수 있습니다. 데이터 세트 범주로 이동하기 전에 테스터는 AUT (Application Under Tester)의 기존 리소스에 대한 데이터 수집 및 분석을 시작합니다.
데이터웨어 하우스를 항상 최신 상태로 유지하는 것에 대해 언급 한 이전 요점에 따르면 테스트 사례 수준에서 데이터 요구 사항을 문서화하고 테스트 사례를 스크립팅 할 때이를 사용 가능 또는 재사용 불가능으로 표시해야합니다. 테스트에 필요한 데이터가 처음부터 잘 정리되고 문서화되어 나중에 나중에 사용하기 위해 참조 할 수 있도록 도와줍니다.
개방형 EMR AUT의 테스트 데이터 예
현재 튜토리얼에서는 테스트 대상 애플리케이션 (AUT)으로 개방형 EMR이 있습니다.
=> 찾아주세요 여기에서 Open EMR 애플리케이션 링크 참조 / 연습을 위해.
아래 표는 테스트 케이스 문서의 일부가 될 수 있고 테스트 시나리오에 대한 테스트 케이스를 작성할 때 업데이트되는 데이터 요구 사항 수집 샘플을 보여줍니다.
( 노트 : 딸깍 하는 소리 확대보기를 위해 모든 이미지에서)
Open EMR 애플리케이션 테스트를위한 수동 데이터 생성
지정된 데이터 세트 범주에 대해 Open EMR 애플리케이션을 테스트하기위한 수동 데이터 생성으로 넘어가겠습니다.
1) 데이터 없음 : 테스터는 데이터를 제공하지 않고 Open EMR 애플리케이션 URL 및 '환자 검색 또는 추가'기능을 검증합니다.
두) 유효한 데이터 : 테스터는 유효한 데이터를 제공하여 Open EMR 애플리케이션 URL 및 '환자 검색 또는 추가'기능을 검증합니다.
3) 잘못된 데이터 : 테스터는 잘못된 데이터를 제공하여 Open EMR 애플리케이션 URL 및 '환자 검색 또는 추가'기능을 확인합니다.
4) 잘못된 데이터 형식 : 테스터는 잘못된 데이터를 제공하여 Open EMR 애플리케이션 URL 및 '환자 검색 또는 추가'기능을 확인합니다.
1-4 데이터 세트 범주에 대한 테스트 데이터 :
5) 경계 조건 데이터 세트 : 주어진 값의 내부 또는 외부에있는 경계에 대한 입력 값을 데이터로 결정합니다.
6) 등가 파티션 데이터 세트 : 입력 데이터를 유효 및 유효하지 않은 입력 값으로 나누는 테스트 기술입니다.
5에 대한 테스트 데이터일그리고 6일Open EMR 사용자 이름 및 암호에 대한 데이터 세트 범주 :
7) 의사 결정 테이블 데이터 세트 : 다양한 결과를 생성하기 위해 입력 조합으로 데이터를 한정하는 기술입니다. 이 블랙 박스 테스트 방법은 테스트 데이터의 모든 조합을 검증하는 데 드는 테스트 노력을 줄이는 데 도움이됩니다. 또한이 기술은 완전한 테스트 범위를 보장 할 수 있습니다.
html5 인터뷰 질문 및 답변 pdf
Open EMR 애플리케이션의 사용자 이름 및 비밀번호에 대한 결정 테이블 데이터 세트를 아래에서 참조하십시오.
위의 표에서 수행 된 조합의 계산은 아래의 자세한 정보에 대해 설명됩니다. 4 개 이상의 조합을 수행 할 때 필요할 수 있습니다.
- 조합 수 = 조건 수 1 값 * 조건 수 2 값
- 조합 수 = 2 ^ 참 / 거짓 조건 수
- 예 : 조합 수 – 2 ^ 2 = 4
8) 상태 전이 테스트 데이터 세트 : 시스템에 입력 조건을 제공하여 AUT (Application Under Test)의 상태 전환을 검증하는 데 도움이되는 테스트 기술입니다.
예를 들면, 첫 번째 시도에서 올바른 사용자 이름과 암호를 제공하여 Open EMR 응용 프로그램에 로그인합니다. 시스템은 우리에게 액세스 권한을 부여하지만 잘못된 로그인 데이터를 입력하면 시스템이 액세스를 거부합니다. 상태 전환 테스트는 Open EMR이 종료되기 전에 수행 할 수있는 로그인 시도 횟수를 검증합니다.
아래 표는 올바른 로그인 시도 또는 잘못된 로그인 시도가 어떻게 응답하는지 나타냅니다.
9) 사용 사례 테스트 날짜 : 특정 기능의 엔드 투 엔드 테스트를 캡처하는 테스트 케이스를 식별하는 테스트 방법입니다.
예, EMR 로그인 열기 :
또한 읽기 => 데이터 데이터 관리 기술
좋은 테스트 데이터의 속성
테스터는 대학 웹 사이트의 '시험 결과'모듈을 테스트해야합니다. 전체 애플리케이션이 통합되었고 '테스트 준비'상태에 있다고 가정합니다. ‘시험 모듈’은‘등록’,‘코스’,‘금융’모듈과 연결되어 있습니다.
애플리케이션에 대한 적절한 정보가 있고 포괄적 인 테스트 시나리오 목록을 만들었다 고 가정합니다. 이제 이러한 테스트 케이스를 설계, 문서화 및 실행해야합니다. 테스트 케이스의 '작업 / 단계'또는 '테스트 입력'섹션에서 허용 가능한 데이터를 테스트 입력으로 언급해야합니다.
테스트 케이스에 언급 된 데이터는 적절하게 선택되어야합니다. 테스트 케이스 문서의 '실제 결과'열의 정확성은 주로 테스트 데이터에 따라 다릅니다. 따라서 입력 테스트 데이터를 준비하는 단계가 매우 중요합니다. 따라서 여기에“DB 테스트 – 테스트 데이터 준비 전략”에 대한 요약이 있습니다.
테스트 데이터 속성
테스트 데이터는 정확하게 선택되어야하며 다음 네 가지 특성을 가져야합니다.
1) 현실적 :
현실적으로 이는 실제 시나리오의 맥락에서 데이터가 정확해야 함을 의미합니다. 예를 들어 '연령'필드를 테스트하려면 모든 값이 양수이고 18 이상이어야합니다. 대학 입학 지원자는 일반적으로 18 세입니다 (비즈니스 요구 사항 측면에서 다르게 정의 될 수 있음).
실제 테스트 데이터를 사용하여 테스트를 수행하면 실제 데이터를 사용하여 가능한 대부분의 버그를 캡처 할 수 있으므로 앱이 더욱 강력 해집니다. 현실적인 데이터의 또 다른 장점은 새로운 데이터를 반복해서 생성하는 데 드는 시간과 노력을 절약하는 재사용 가능성입니다.
현실적인 데이터에 대해 이야기 할 때 골든 데이터 세트의 개념을 소개하고 싶습니다. 골든 데이터 세트는 실제 프로젝트에서 발생하는 거의 모든 가능한 시나리오를 포함하는 데이터 세트입니다. GDS를 사용하여 최대 테스트 범위를 제공 할 수 있습니다. 조직에서 회귀 테스트를 수행하기 위해 GDS를 사용하고 있으며 이는 코드가 프로덕션 상자에 들어갈 경우 발생할 수있는 모든 가능한 시나리오를 테스트하는 데 도움이됩니다.
데이터베이스의 열 특성 및 사용자 정의를 분석하는 시장에서 사용할 수있는 많은 테스트 데이터 생성기 도구가 있으며이를 기반으로 실제 테스트 데이터를 생성합니다. 데이터베이스 테스트 용 데이터를 생성하는 도구의 좋은 예는 다음과 같습니다. DTM 데이터 생성기 , SQL 데이터 생성기 과 모카 루 .
2. 실질적으로 유효 :
이것은 현실과 비슷하지만 동일하지는 않습니다. 이 속성은 AUT의 비즈니스 로직과 더 관련이 있습니다. 값 60은 연령 분야에서 현실적이지만 졸업 또는 석사 프로그램 후보에게는 사실상 유효하지 않습니다. 이 경우 유효한 범위는 18-25 년입니다 (요구 사항에 정의되어있을 수 있음).
3. 시나리오를 다룰 수있는 다목적 :
인터뷰 질문과 답변을 지원합니다.
단일 시나리오에는 여러 후속 조건이있을 수 있으므로 최소 데이터 세트로 단일 시나리오의 최대 측면을 포함하도록 데이터를 현명하게 선택합니다. 결과 모듈에 대한 테스트 데이터를 만들 때 프로그램을 순조롭게 이수하는 정규 학생의 경우 만 고려하지 마십시오. 같은 과정을 반복하고 다른 학기 나 다른 프로그램에 속한 학생들에게주의를 기울이십시오. 데이터 세트는 다음과 같습니다.
씨# | 학생 아이디 | Program_ID | Course_ID | 등급 |
1 | BCS-Fall2011-Morning-01 | BCS-F11 | CS-401 | 에 |
두 | BCS-Spring2011-Evening-14 | BCS-S11 | CS-401 | B + |
삼 | MIT-Fall2010-Afternoon-09 | MIT-F10 | CS-401 | 에- |
... | ... | ... | ... | ... |
여러 가지 흥미롭고 까다로운 하위 조건이있을 수 있습니다. 예 : 학위 프로그램을 완료하는 데 필요한 기간, 과정 등록을위한 필수 과정 통과, 최대 수 학생이 한 학기에 등록 할 수있는 코스 수 등. 유한 한 데이터 세트로 이러한 모든 시나리오를 현명하게 다루도록하십시오.
4. 뛰어난 데이터 (해당하는 경우 / 필수) :
자주 발생하지 않지만 발생시 높은주의를 요하는 특정 예외 시나리오가있을 수 있습니다. 장애 학생 관련 문제.
예외적 인 데이터 세트에 대한 또 다른 좋은 설명과 예가 아래 이미지에 나와 있습니다.
요약 :
테스트 데이터가 현실적이고 유효하며 다재다능하다면 좋은 테스트 데이터로 알려져 있습니다. 데이터가 예외적 인 시나리오에 대한 커버리지를 제공하는 경우 추가 이점입니다.
테스트 데이터 준비 기술
테스트 데이터의 중요한 속성에 대해 간략히 논의했으며 데이터베이스 테스트를 수행하는 동안 테스트 데이터 선택이 얼마나 중요한지에 대해서도 설명했습니다. 이제 ' 테스트 데이터를 준비하는 기술 ' .
테스트 데이터를 준비하는 방법은 두 가지뿐입니다.
방법 # 1) 새 데이터 삽입
깨끗한 DB를 얻고 테스트 케이스에 지정된대로 모든 데이터를 삽입하십시오. 모든 필수 및 원하는 데이터를 입력 한 후 테스트 케이스 실행을 시작하고 '실제 출력'과 '예상 출력'을 비교하여 '합격 / 실패'열을 채우십시오. 간단하게 들리 죠? 하지만 잠깐, 그렇게 간단하지 않습니다.
다음과 같은 몇 가지 필수적이고 중요한 문제가 있습니다.
- 데이터베이스의 빈 인스턴스를 사용할 수 없습니다.
- 삽입 된 테스트 데이터는 성능 및 부하 테스트와 같은 일부 사례를 테스트하는 데 충분하지 않을 수 있습니다.
- 빈 DB에 필요한 테스트 데이터를 삽입하는 것은 데이터베이스 테이블 종속성으로 인해 쉬운 작업이 아닙니다. 이러한 불가피한 제한으로 인해 데이터 삽입은 테스터에게 어려운 작업이 될 수 있습니다.
- 제한된 테스트 데이터를 삽입하면 (테스트 케이스의 필요에 따라) 큰 데이터 세트에서만 발견 할 수있는 일부 문제가 숨겨 질 수 있습니다.
- 데이터 삽입의 경우 복잡한 쿼리 및 / 또는 절차가 필요할 수 있으며이를 위해서는 DB 개발자의 도움이나 충분한 도움이 필요합니다.
위에서 언급 한 다섯 가지 문제는 테스트 데이터 준비를위한이 기술의 가장 중요하고 가장 명백한 단점입니다. 그러나 다음과 같은 몇 가지 장점도 있습니다.
- DB에 필요한 데이터 만 있으므로 TC의 실행이 더욱 효율적입니다.
- 테스트 케이스에 지정된 데이터 만 DB에 존재하므로 버그 격리에는 시간이 필요하지 않습니다.
- 테스트 및 결과 비교에 필요한 시간이 줄어 듭니다.
- 깔끔한 테스트 프로세스
방법 # 2) 실제 DB 데이터에서 샘플 데이터 하위 집합 선택
이것은 테스트 데이터 준비를위한 실행 가능하고보다 실용적인 기술입니다. 그러나 건전한 기술력이 필요하고 DB Schema 및 SQL에 대한 자세한 지식이 필요합니다. 이 방법에서는 일부 필드 값을 더미 값으로 대체하여 프로덕션 데이터를 복사하고 사용해야합니다. 이는 프로덕션 데이터를 나타내므로 테스트에 가장 적합한 데이터 하위 집합입니다. 그러나 이것은 데이터 보안 및 개인 정보 문제로 인해 항상 실행 가능하지 않을 수 있습니다.
요약 :
위 섹션에서 테스트 데이터 준비 기술에 대해 논의했습니다. 간단히 말해 새로운 데이터를 생성하거나 기존 데이터에서 하위 집합을 선택하는 두 가지 기술이 있습니다. 두 가지 모두 선택한 데이터가 주로 유효 및 유효하지 않은 테스트, 성능 테스트 및 null 테스트에 대한 다양한 테스트 시나리오에 대한 커버리지를 제공하는 방식으로 수행되어야합니다.
마지막 섹션에서는 데이터 생성 접근 방식에 대해서도 간략히 살펴 보겠습니다. 이러한 접근 방식은 새 데이터를 생성해야 할 때 유용합니다.
테스트 데이터 생성 접근 방식 :
- 수동 테스트 데이터 생성 : 이 접근 방식에서는 테스트 사례 요구 사항에 따라 테스터가 테스트 데이터를 수동으로 입력합니다. 프로세스를 수행하는 데 시간이 걸리며 오류가 발생하기 쉽습니다.
- 자동화 된 테스트 데이터 생성 : 이것은 데이터 생성 도구의 도움으로 수행됩니다. 이 접근 방식의 주요 장점은 속도와 정확성입니다. 그러나 수동 테스트 데이터 생성보다 비용이 많이 듭니다.
- 백엔드 데이터 주입 : 이것은 SQL 쿼리를 통해 수행됩니다. 이 접근 방식은 데이터베이스의 기존 데이터를 업데이트 할 수도 있습니다. 빠르고 효율적이지만 기존 데이터베이스가 손상되지 않도록 매우 신중하게 구현해야합니다.
- 타사 도구 사용 : 먼저 테스트 시나리오를 이해 한 다음 그에 따라 데이터를 생성하거나 주입하여 광범위한 테스트 범위를 제공하는 도구가 시장에 나와 있습니다. 이러한 도구는 비즈니스 요구에 따라 사용자 지정되므로 정확합니다. 그러나 비용이 많이 듭니다.
요약 :
테스트 데이터 생성에는 4 가지 접근 방식이 있습니다.
- 안내서,
- 오토메이션,
- 백엔드 데이터 주입,
- 및 타사 도구.
각 접근 방식에는 고유 한 장단점이 있습니다. 비즈니스 및 테스트 요구 사항을 충족하는 접근 방식을 선택해야합니다.
결론
업계 표준, 법률 및 착수 한 프로젝트의 기본 문서를 준수하여 완전한 소프트웨어 테스트 데이터를 생성하는 것은 테스터의 핵심 책임 중 하나입니다. 테스트 데이터를 효율적으로 관리할수록 실제 사용자를 위해 버그가없는 제품을 더 많이 배포 할 수 있습니다.
테스트 데이터 관리 (TDM)는 과제 분석을 기반으로하고 최종 결과물 (제품)의 전체 범위와 신뢰성을 손상시키지 않으면 서 식별 된 문제를 잘 해결하기 위해 최상의 도구와 방법을 도입하고 적용하는 프로세스입니다.
데이터 생성을위한 도구 사용을 포함하여 테스트 방법을 분석하고 선택하기위한 혁신적이고 비용 효율적인 방법을 찾기위한 질문을 항상 제기해야합니다. 잘 설계된 데이터를 통해 다상 SDLC의 모든 단계에서 테스트중인 애플리케이션의 결함을 식별 할 수 있다는 것이 널리 입증되었습니다.
우리는 민첩한 팀 내부 및 외부의 모든 구성원과 함께 창의적이고 참여해야합니다. 데이터 관리를 통해 AUT에 대한 긍정적 인 영향을 극대화하기 위해 지속적인 기술 토론을 계속할 수 있도록 피드백, 경험, 질문 및 의견을 공유하십시오.
적절한 테스트 데이터를 준비하는 것은 '프로젝트 테스트 환경 설정'의 핵심 부분입니다. 완전한 데이터를 테스트 할 수 없다는 테스트 사례를 놓칠 수 없습니다. 테스터는 기존 표준 생산 데이터에 추가로 자신의 테스트 데이터를 만들어야합니다. 데이터 세트는 비용과 시간 측면에서 이상적이어야합니다.
창의력을 발휘하고 자신의 기술과 판단을 사용하여 표준 생산 데이터에 의존하는 대신 다른 데이터 세트를 생성하십시오.
파트 II- 이 튜토리얼의 두 번째 부분은 ' GEDIS Studio 온라인 도구로 테스트 데이터 생성 ”.
테스트를위한 불완전한 테스트 데이터 문제에 직면 했습니까? 어떻게 관리 했습니까? 이 토론 주제를 더욱 풍부하게하기 위해 팁, 경험, 의견 및 질문을 공유하십시오.