여기에서는 동등 클래스, 경계 값 테스트 및 쌍별 테스트와 같이 잘 알려져 있고 널리 사용되는 테스트 설계 기술에 대한 논의는 생략하고 덜 일반적인 다른 기술에 대해서는 논의하겠습니다. 또한 에 대한 내 기사를 읽어볼 수도 있습니다. 조합 테스트 설계 기술과 관련된 문제 의사결정 테이블 테스트 의사결정 테이블은 요구사항을 문서화하고 애플리케이션 기능을 설명하는 데 탁월한 도구입니다. 이러한 테이블은 애플리케이션의 비즈니스 로직을 설명하는 데 매우 편리하며, 그 외에도 테스트 사례를 생성하기 위한 견고한 기반 역할을 할 수 있습니다. 테스트된 애플리케이션에 적절한 문서가 부족한 경우 의사결정 테이블을 사용하는 것이 좋습니다. 요구 사항을 간결하고 간단한 형식으로 제시하면 테스트 사례를 만드는 것이 매우 쉽습니다. 접근하다: 결정 테이블은 시스템 상태의 엔터티(속성/조건)를 기반으로 애플리케이션의 논리를 설명합니다. 각 의사결정 테이블은 시스템의 한 가지 상태만 설명해야 합니다. 규칙 1 규칙 2 … 규칙 N 엔터티 속성 1 … 프로퍼티 M 행위 액션 1 … 액션 P 1부터 M까지의 엔터티(속성)는 시스템의 다양한 속성을 나타냅니다. 이는 시스템에 입력할 수 있는 입력 데이터로 표에 표시됩니다. 1부터 P까지의 동작은 지정된 엔터티 조합으로 발생할 수 있는 동작입니다. 엔터티의 모든 입력 데이터의 조합에 따라 조치는 필요한 값을 취합니다. 각 규칙은 특정 작업의 실행으로 이어지는 모든 속성에 대한 고유한 입력 데이터 집합을 정의합니다. 의사결정 테이블을 구성한 후에는 일반적으로 불가능한 시나리오 중 일부 또는 전부를 제거하여 테이블을 단순화할 수 있습니다. 그런 다음 테이블을 테스트 사례로 변환할 수 있습니다. 상태 전환 테스트 의사 결정 테이블 테스트와 같은 상태 전환 테스트는 요구 사항을 문서화하고 시스템의 구조와 디자인을 설명하는 데 유용한 도구입니다. 특정 시스템 상태를 설명하는 의사결정 테이블 테스트와 달리 상태 전환 테스트는 이러한 시스템 상태가 어떻게 변경될 수 있는지 설명합니다. 다이어그램은 애플리케이션 작동 중에 발생하는 모든 이벤트와 애플리케이션이 이러한 이벤트에 응답하는 방식을 정의합니다. 접근하다: 이 기술에는 두 가지 유형의 시각적 표현이 있습니다. 상태 전이 다이어그램 상태 전이 테이블 상태 전이 다이어그램 예를 들어 항공권 예약을 생각해 봅시다. 대략적으로 운영되는 방식은 다음과 같습니다. 처음에 고객은 출발지, 도착지, 날짜, 출발 시간 등 예약 정보를 항공사에 제공합니다. 항공사 직원은 예약을 생성하기 위해 고객이 제공한 정보를 사용하여 고객과 항공권 예약 시스템 사이의 인터페이스 역할을 합니다. 이후 고객의 예약은 "Made" 상태가 됩니다. 또한 예약을 생성한 후 시스템은 타이머를 시작합니다. 타이머가 만료되고 예약된 티켓이 결제되지 않은 경우 시스템은 해당 티켓에 대한 예약을 취소합니다. 원은 항공권 예약 시스템의 상태, 즉 "Made" 상태를 나타냅니다. 화살표는 "Made" 상태로의 전환을 나타냅니다. 화살표 아래 설명("get_info")은 시스템 외부에서 발생하는 이벤트입니다. 설명에서 화살표 아래 명령("/" 뒤)은 시스템이 이벤트에 대한 응답으로 일부 작업(이 경우 타이머 시작)을 수행했음을 나타냅니다. 검은색 원은 다이어그램의 시작/진입 지점을 나타냅니다. 타이머가 만료되지 않고 예약된 항공권에 대한 비용을 지불한 경우 시스템은 "지불됨" 상태로 전환됩니다. 이는 "payMoney"라고 표시된 화살표와 "Made" 상태에서 "Paid" 상태로의 전환으로 표시됩니다. (다이어그램에서 원으로 표시됨) 하나 이상의 이벤트를 기다리는 시스템 상태입니다. 상태는 지금까지 수신된 입력 데이터를 기억하고 시스템이 수신된 이벤트에 어떻게 반응할지를 나타냅니다. 이벤트는 작업을 트리거하거나 상태 변경으로 이어질 수 있습니다. 상태 : (다이어그램에서 화살표로 표시) 이는 이벤트로 인해 발생하는 한 상태에서 다른 상태로의 전환을 나타냅니다. 전환 : (화살표 위에 직사각형으로 표시됨) 이벤트는 애플리케이션의 상태를 변경하게 하는 것입니다. 이벤트는 애플리케이션의 사용자 인터페이스 등을 통해 애플리케이션 외부에서 발생할 수 있습니다. 동시에 애플리케이션 자체는 "타이머 만료"와 같은 이벤트를 생성할 수 있습니다. 이벤트가 발생하면 애플리케이션은 동일한 상태를 유지하거나 상태를 변경하거나 작업을 수행할 수 있습니다. 이벤트에는 매개변수가 있을 수 있습니다. 예를 들어, "pay_money" 이벤트에는 "현금", "수표", "DebitCard" 또는 "CreditCard"와 같은 매개변수가 있을 수 있습니다. 이벤트 : (전환 위 레이블에서 "/" 뒤에 표시됨) 상태 변경에 의해 시작되는 작업입니다. "티켓 인쇄", "화면에 표시" 등과 같은 작업이 될 수 있습니다. 일반적으로 작업은 시스템의 출력 데이터 역할을 하는 출력을 생성합니다. 전환 중에 작업이 발생합니다. 국가 자체는 수동적입니다. 작업 : 다이어그램에 검은색 점으로 표시됩니다. 진입점은 다이어그램에 "과녁 모양" 기호로 표시됩니다. 출구 지점은 상태 전이 테이블 상태 전이 테이블은 Current State, Event, Action, Next State의 4개 열로 구성된 테이블입니다. 상태 전환 테이블의 장점은 올바른 상태 전환 시나리오뿐만 아니라 가능한 모든 상태 전환 시나리오를 정의한다는 것입니다. 따라서 상태-전이 테이블은 정의되지 않고 문서화되지 않은 상태-전이 조합을 발견하는 경우가 많으며, 코드를 작성하기 전에 식별하는 것이 더 좋습니다. 상태-전이 다이어그램은 테스트 케이스 생성에 쉽게 사용될 수 있습니다. 모든 전환을 적어도 한 번은 다루어야 하는 테스트 케이스 세트를 생성하는 것이 필요합니다. 상태 전이 테이블에서는 테스트 사례를 생성하는 것도 비교적 간단합니다. 유효한 조합을 모두 거쳐야 합니다. (시간이 허락하거나 위험이 허락하지 않으면 유효하지 않은 조합도 모두 거쳐갈 수 있습니다.) 직교 배열 값 "1"과 "2" 쌍에 대해 몇 개의 조합이 존재합니까? {1,1}, {1,2}, {2,1} 및 {2,2}. 직교 배열은 특별한 속성을 가진 2차원 배열입니다. 배열의 두 열에는 해당 열의 모든 값 조합이 존재합니다. 즉, 값이 "1" 또는 "2"만 될 수 있는 직교 배열에서 두 개의 열을 선택하면 해당 열에 대해 다음 행을 찾을 수 있습니다 - {1,1}, {1,2}, { 2,1} 및 {2,2}. 예를 들어, 각각 이진수(즉, "1" 또는 "2" 값을 취함)인 3개의 입력 매개변수가 있는 시스템을 생각해 보세요. 행 변수 1 변수 2 변수 3 1 1 1 1 2 2 1 1 삼 1 2 1 4 1 1 2 5 2 2 1 6 1 2 2 7 2 1 2 8 2 2 2 직교 배열은 - L_4(2^3)으로 표시됩니다. 여기서 L_4는 직교 배열에 4개의 행이 있음을 나타내고, (2^3)은 배열에 3개의 열이 있음을 나타내며 값은 "1" 또는 "2일 수 있습니다. ". 행 변수 1 변수 2 변수 3 1 1 1 1 2 1 2 2 삼 2 1 2 4 2 2 1 L_4, 여기서 4는 행 수입니다. 2^3, 여기서 2는 최대값(== 2, 3, …, N)이고 3은 열 수입니다. 직교 배열 - 다음 속성을 가진 2차원 배열입니다. 배열의 두 열을 선택하면 해당 열에 있는 값의 모든 조합을 찾을 수 있습니다. 직교 배열 사용: 변수(입력 데이터 수)를 식별합니다. 입력 데이터, 즉 논리적으로 존재할 수 있는 값의 조합을 선택해야 합니다. 각 변수가 취할 수 있는 값의 개수를 결정합니다. 값의 수가 결정될 때까지 값의 수를 줄이기 위해 다른 테스트 설계 기술(예: 경계 값, 동등 클래스 등)이 이미 적용되어 있어야 합니다. 각 변수에 대한 열이 있는 직교 배열을 결정합니다(직교 배열의 열에는 변수만큼 많은 값 옵션이 있습니다). 테스트 작업을 직교 배열에 투영합니다. 테스트 케이스를 작성하세요. AllPairs 알고리즘 AllPairs 알고리즘의 핵심은 모든 변수에 대한 값의 모든 조합을 테스트할 필요가 없다는 것입니다. 대신 각 변수 쌍에 대한 모든 값 조합을 테스트하는 데 중점을 둡니다. QA 전문가로서 이러한 미묘한 차이를 이해하는 것이 중요합니다. 어떤 경우에는 이론적이지만 조합 테스트 설계 기술의 복잡성을 이해하면 QA 전문가가 앱의 복잡한 비즈니스 로직을 효과적으로 테스트하고 사용자에게 고품질 소프트웨어를 제공할 수 있습니다.

This story contains new, firsthand information uncovered by the writer.

이 오디오는 이야기의 원래 언어로 제작되었습니다!

너무 오래; 읽다

Making security fun one episode at a time

조합 테스트 설계 기법 분석

너무 오래; 읽다

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

태그 걸기

Languages

이 기사는 다음에서 발표되었습니다....

조합 테스트 설계 기법 분석

너무 오래; 읽다

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

태그 걸기

Languages

이 기사는 다음에서 발표되었습니다....

관련 기사