저자: JD Logistics Wang Yukun
소프트웨어 테스트 설계는 테스트 프로세스에서 중요한 테스트 활동입니다.테스트 케이스를 설계하는 방법은 테스트의 효율성과 품질을 향상시킬 수 있습니다.다음 측면에서 간략한 설명이 제공됩니다.
1 테스트 케이스 설계 원칙
테스트 케이스 설계의 기본 원칙에는 효율성, 명확성, 재사용 가능성, 유지 관리 가능성, 무결성, 호환성, 운영 용이성, 관리 용이성 및 평가 용이성이 포함됩니다.
- 유효성: 테스트 케이스 단계를 명확하게 설명해야 하며 모호하고 반복되는 단어가 나타날 수 없으며 테스트 케이스는 특정 순서로 작성되어야 실행 효율성이 상대적으로 높아집니다.
- 명확성: 사용 사례의 작업 단계는 명확한 입력 데이터 및 예상 출력을 포함하여 명확하게 설명되어야 합니다. 검증 포인트는 명확하고 명확해야 하며 핵심 사항을 강조할 수 있습니다. 절차적 사용 사례의 경우 사용을 정렬하는 것이 좋습니다. 첫 번째 검증 포인트부터 마지막 검증 포인트까지, 구성 프로세스의 처음부터 끝까지 프로세스 순서대로 경우에 따라 테스트 실행에 편리합니다. 테스트 케이스에 전제 조건이 포함되어 있는 경우 진입점 등을 포함하여 전제 조건을 명확하게 설명해야 합니다.
- 재사용성: 재사용이 가능하며 유사한 기능으로 테스트 사례를 추상화하고 분류합니다.
- 유지 보수성: 비즈니스 요구 사항으로 인해 테스트 케이스가 변경되면 테스트 케이스의 실시간 성능과 유효성을 보장하기 위해 테스트 케이스를 적시에 업데이트하고 유지 관리해야 합니다.테스트 케이스를 개선하고 지속적으로 개선해야 합니다. 점진적인 과정이다.
- 완전성: 요구 사항을 완전히 이해할 수 있도록 사용 사례가 완전하고 모든 요구 사항을 포함하는지 여부.
- 호환성: 테스트 케이스에는 이전 버전과 새 버전 간의 호환성, 이전 데이터와 새 데이터 간의 호환성, 브라우저 호환성과 같은 테스트 포인트가 포함되어야 합니다.
- 관리 용이성: 테스터의 테스트 진행 상황, 워크로드 등을 감지하는 기능
- 평가 가능성: 테스트 케이스의 합격률과 결함의 수는 소프트웨어의 품질을 평가하는 기준입니다.
2 테스트 케이스의 수명 주기
소프트웨어 테스트 케이스의 설계 단계에는 요구 사항 분석, 테스트 케이스 설계, 테스트 케이스 구현, 테스트 케이스 실행, 테스트 케이스 관리가 포함됩니다.
2.1 수요 분석
테스트 사례 프로세스의 첫 번째 단계는 테스트 대상을 결정하고 테스트 포인트를 식별하고 우선 순위를 지정하는 것입니다.
2.2 테스트 케이스 설계
테스트 케이스 설계는 분석된 테스트 포인트를 테스트하는 방법을 결정합니다.
테스트 설계의 주요 포인트는 테스트의 예상 결과를 결정하는 것입니다. 예상되는 테스트 결과를 결정하기 위해 테스터는 테스트 출력에 주의를 기울여야 할 뿐만 아니라 테스트 데이터 및 테스트 환경의 사전 및 사후 조건에도 주의를 기울여야 합니다. 테스트 케이스가 예상한 테스트 결과를 가지고 있지 않다면 테스트 케이스가 테스트 결과가 옳고 그름을 판단하는 것은 의미가 없다.
테스트의 예상 결과는 생성 또는 출력해야 하는 결과, 업데이트 또는 변경해야 하는 결과, 삭제해야 하는 결과 등 다양할 수 있습니다. 각 테스트 사례는 테스트의 예상 결과를 명확하게 설명해야 합니다. 이와 같이 테스터는 소프트웨어 시스템의 테스트 출력을 올바르게 평가하기 위해 테스트 중인 시스템과 관련된 풍부한 지식과 경험이 필요합니다. 테스트 출력 평가가 올바른 것으로 간주되면 테스트 케이스의 예상 출력으로 사용할 수 있습니다.
2.3 테스트 케이스 실현
테스트 케이스 실현 프로세스에는 테스트 스크립트 준비, 테스트 입력, 테스트 데이터 및 예상 결과가 포함됩니다. 테스트 스크립트는 표준 구문에 따라 데이터 또는 지침을 구성하는 것을 말합니다. 테스트를 실행하기 전에 먼저 테스트 전제 조건이 충족되어야 하는데, 예를 들어 테스트 케이스가 일부 구성된 데이터를 사용해야 하는 경우 이 데이터를 미리 생성해야 합니다.
2.4 테스트 케이스 실행
테스트 사례를 실행하여 테스트 중인 시스템을 테스트합니다. 수동 테스트의 경우 테스트 실행은 주로 테스트 케이스의 단계를 참조하고 예상 결과와 실제 결과를 비교하며 테스트 중에 발견된 문제를 기록합니다.
자동화된 테스트 프로세스를 위해서는 실행 중에 테스트 도구를 사용하고 테스트 케이스 스크립트 등을 실행하고 테스트 결과를 기록해야 합니다.
실제 결과가 테스트 실행 시 기대한 결과와 같으면 통과한 것으로 간주하고, 그렇지 않으면 유스케이스 실행에 실패했거나 문제가 있는 것으로 유스케이스 실행에 실패했다면, 소프트웨어 문제인지 사용 사례의 예상 여부를 결정하기 위해 추가 검사가 필요합니다. 결과에 문제가 있거나 데이터 문제 또는 환경 문제로 인한 경우 다른 측면에서 분석해야 합니다.
2.5 테스트 케이스 관리
1) 테스트 케이스 구성
각 프로젝트에는 매우 많은 수의 테스트 사례가 있습니다. 테스트 사례를 구성, 추적 및 유지 관리하는 방법은 매우 중요합니다. 테스트 케이스를 구성하는 방법은 테스트의 성공에 중요한 요소이며 테스트 효율성을 향상시키는 중요한 단계입니다.
테스트 케이스 구성은 다양한 방식으로 구성하거나 분류할 수 있습니다.
- 소프트웨어 기능 모듈에 따라 구성: 소프트웨어 시스템은 일반적으로 소프트웨어 기능 모듈에 따라 작업을 할당합니다. 따라서 소프트웨어 기능 모듈을 기반으로 테스트 케이스를 설계하고 실행하는 것은 매우 일반적인 방법입니다. 모듈에 따라 테스트 케이스를 구성하면 테스트 케이스가 각 시스템 모듈을 커버하고 더 나은 모듈 테스트 범위를 달성할 수 있습니다.
- 테스트 케이스 우선 순위별로 구성: 테스트 케이스의 우선 순위가 지정됩니다. 모든 소프트웨어에 대해 철저한 테스트를 구현하는 것은 현실적이지 않습니다. 제한된 리소스와 시간으로 우선 순위가 높은 테스트 사례를 먼저 실행해야 합니다.
기능 모듈에 따라 나누는 것이 가장 일반적으로 사용되며 예를 들어 기능 모듈에 따라 나눈 다음 다른 우선 순위로 나누는 것과 같이 조합하여 사용할 수도 있습니다.
2) 테스트 케이스 추적
테스트 케이스의 추적은 주로 테스트 실행 과정에서 테스트 케이스의 상태에 대해 수행되며 테스트 상태의 추적 및 관리를 통해 테스트 프로세스 및 테스트 유효성의 관리 및 평가를 실현할 수 있습니다.
- 테스트 케이스 실행 추적: 테스트 실행 과정에서 테스트 케이스의 상태를 추적하면 테스트 프로세스를 효과적으로 정량화할 수 있습니다. 예를 들어, 테스트 라운드를 실행하는 과정에서 테스트된 테스트 사례의 수는 얼마이며, 통과, 실패 및 테스트되지 않은 테스트 사례의 비율은 얼마입니까? 이러한 데이터는 소프트웨어 프로젝트의 품질 및 실행 진행 상황을 판단할 수 있는 정보를 제공할 수 있으며 테스트 진행 및 테스트 초점을 제어하는 데 도움이 되는 테스트 진행 및 상태에 대한 명확한 데이터를 제공할 수 있습니다.
3) 테스트 케이스 유지
테스트 케이스는 정적이지 않습니다.단계의 테스트 프로세스가 끝나면 일부 테스트 케이스가 부당하게 작성되었거나 요구 사항이 변경되었음을 알 수 있습니다.이를 위해 현재 일부 테스트 케이스를 수정하고 업데이트해야 합니다. 테스트 케이스에는 재사용성이 있습니다.
테스트 케이스 작성의 3가지 요소
- 유스 케이스 번호: 유스 케이스의 고유 식별
- 테스트 모듈: 테스트 케이스가 속한 모듈
- 테스트 케이스 제목: 테스트 케이스에 대한 간략한 설명
- 전제조건: 유스케이스 실행을 위한 전제조건
- 테스트 단계: 사용 사례 단계 실행
- 예상 결과: 얻어야 할 결과
- 우선순위: 사용 사례 중요도
4 기능 테스트 케이스 설계 방법
4.1 등가분할 방식
등가분류법의 정의
- 데이터의 대표적인 하위 집합을 입력하세요.
등가 등급 분류
- 유효한 등가 클래스: 요구 사항을 충족하는 클래스
- 유효하지 않은 등가 등급: 요구 사항을 충족하지 않습니다.
적용 범위
- 단일 입력 함수
단계
- 명확한 필요
- 유효 및 유효하지 않은 등가 클래스 결정
- 테스트 케이스 작성
예
요구 사항: 주문이 신속하게 배송되는 경우 택배사가 수정할 수 있어야 하며 제한된 수의 패키지는 1개, 무게는 <0.5kg이어야 합니다.
4.2 경계값 분석
경계값의 정의
- 입력 등가 클래스 및 출력 등가 클래스의 일부 특정 경우에 대해 경계 약간 위 또는 약간 아래
경계 값 범위
- 정확히 같다
- 보다 더 크다
- 보다 작다
경계값 분석의 3가지 포인트
- 위쪽 점: 경계의 점
- 시작점: 경계에 가장 가까운 점
- 인라이어: 범위 내의 포인트
예: 1-100, 상위 포인트: 1 100 포인트: 0 99 2 101 내부 포인트: 50
적용 범위
- 입력 매개변수가 있고, 입력 유형 또는 범위 길이에 경계가 있는 경우(제목 요건에 길이 또는 범위가 있는 경우에 해당)
- 단일 함수에 대한 입력의 경우 등가 클래스와 함께 사용
단계
- 명확한 필요
- 유효 및 유효하지 않은 등가 클래스 결정
- 주제 조건에서 경계값을 명확히 함
- 테스트 케이스 작성
예
4.3 의사결정 테이블 방식
적용 가능한 조건
- 의사결정 테이블은 다중 입력과 다중 출력, 입력과 입력 사이의 조합 관계, 입력과 출력 사이의 상호 제약과 종속성이 있음을 보여줍니다.
요소
- 조건 파일: 질문 조건의 모든 테스트 입력
- 작업 파일: 주제 조건의 모든 출력
- 조건 항목: 테스트 입력 값
- 작업 항목: 테스트 출력 값
단계
- 조건 파일을 명확히 함
- 클리어 액션 파일
- 조건부 파일의 전체 조합
- 각 조합에 해당하는 액션 파일을 명확히 함
- 테스트 케이스 설계
예
4.4 인과관계도 방법
원인 및 결과 다이어그램 정의
- 이론적으로는 Decision Table로 이어지는 중간 과정이다.
적용 범위
- 인과도는 프로그램 입력 조건의 다양한 조합을 확인하는데 적합한 그래픽 방식을 사용하여 다양한 입력 조합을 분석하여 테스트 케이스를 설계하는 방법입니다.
인과관계도의 핵심
- 소위 원인은 입력이고 소위 결과는 출력입니다.
- 인과관계도의 원인-입력 조건
- 원인-결과 다이어그램의 결과-입력 결과
원인과 결과 다이어그램 기본 표기법
관계
- 항등식: Ci가 1이면 ei도 1이고 그렇지 않으면 ei는 0입니다.
- 아님: ci가 1이면 ei는 0이고 그렇지 않으면 ei는 1입니다.
- 또는: c1 또는 c2 또는 c3이 1이면 ei는 1이고 그렇지 않으면 ei는 0입니다.
- 그리고: c1과 c2가 모두 1이면 ei는 1이고 그렇지 않으면 ei는 0입니다.
단계
- 입력 및 출력 식별
- 인과관계도를 그리다
- 원인-결과 다이어그램을 의사 결정 테이블로 변환
- 테스트 케이스 생성
예
요구 사항: 특정 소프트웨어 사양에는 다음과 같은 요구 사항이 포함되어 있습니다: 첫 번째 열의 문자는 A 또는 B이고 두 번째 열의 문자는 숫자여야 합니다. 이 경우 파일을 수정하되 첫 번째 열의 문자가 열이 올바르지 않으면 출력 정보 L을 제공하고 두 번째 열의 문자가 숫자가 아닌 경우 출력 정보 M을 제공합니다.
의사결정 테이블로 변환
드디어 테스트 케이스로 바뀌었습니다.
4.5 직교 분석 방법
정의
- Orthogonal 방식은 Orthogonal Test 방식이라고도 하며 Orthogonal Arrangement 방식이라고도 하며 가장 작은 테스트 프로세스 세트를 사용하여 가장 큰 테스트 커버리지 비율을 얻습니다. 직교 실험 설계법은 수많은 실험 포인트 중에서 적절하고 대표적인 포인트를 선택하고 갈루아 이론에서 파생된 "직교 테이블"을 사용하여 실험을 합리적으로 배열하는 과학적 실험 설계 방법입니다.
직교 테이블의 개념: 특수 테이블, 일반적인 직교 테이블은 Ln(mk)로 표시
- n은 행 수, 즉 테스트해야 하는 조합 수를 나타냅니다.
- k로 표시되는 열의 수는 컨트롤의 수(요인의 수 또는 요인의 수)를 나타냅니다.
- m은 각 컨트롤에 포함된 값의 개수(각 요인의 수준 수, 즉 각 요인의 상태 수)
예: L9(34)
에는 4개의 컨트롤이 있고
각 컨트롤에는 3개의 값이 있으며
9는 테스트할 조합의 수이며
4개의 요인과 3개의 수준이라고 하는 9개의 테스트 케이스가 있습니다.
단계
- 요구 사항에 따라 요인 상태 테이블 구성 - 요인: 컨트롤 이름 상태: 각 컨트롤에 해당하는 값
- 사용된 직교 테이블 결정
- 직교 테이블의 숫자를 단어로 바꿉니다.
- 라인은 테스트 케이스
예
알아채다
각 요인의 상태 수가 균일하지 않고 균일한 상황을 갖는 것이 거의 불가능할 경우 요인 수, 상태 수 및 시행 횟수와 같거나 약간 큰 직교 테이블을 선택합니다. 가장 적다
직교 테스트 테이블 생성 방법
온라인 생성: https://jaccz.github.io/pairwise/tools.html
각 컨트롤의 값을 입력하고 컨트롤
생성된 테이블
직교 테스트의 예제 테이블은 유스 케이스에 적용할 수 있습니다. http://www.york.ac.uk/depts/maths/tables/orthogonal.htm
직교 테스트의 예제 테이블은 유스 케이스에 적용할 수 있습니다 . ://support.sas.com/techsup/technote/ts723_Designs.txt
4.6 시나리오 방법-흐름도 방법
정의
- 주로 여러 기능의 조합 사용을 테스트하는 데 사용되는 사용자 조작 장면을 시뮬레이션합니다.
왜 사용자 시나리오인가
- 사용자 관점: 사용자는 일반적으로 단일 기능이 아닌 여러 기능의 조합을 사용합니다.
- 테스터의 관점에서: 일반적으로 단일 기능 포인트를 테스트합니다. 테스트의 포괄성을 보장하기 위해 여러 기능 간의 결합 테스트 시나리오를 고려합니다.
장면 방법의 적용 범위
- 여러 기능 간의 결합 테스트
- 연기 테스트에 자주 사용됨
장면 방법의 두 가지 중요한 개념
- 기본 흐름: 올바른 비즈니스 프로세스를 따르는 경로
- 대체 흐름: 오류가 발생하는 작업 흐름
단계
- 프로젝트 역할 식별
- 역할의 공통 기능을 명확히 합니다.
- 요구 사항에 따라 테스트 시나리오 구축
- 장면은 사건이다
5 보안 테스트 설계
보안 테스트는 소프트웨어 제품 개발이 기본적으로 완료되었을 때 해당 제품이 보안 요구사항 정의 및 제품 품질 기준을 충족하는지 검증하는 과정입니다. 보안 테스트는 시스템이 불법 침입 및 침입을 방지하는 기능을 확인하는 것입니다.
포함된 테스트 포인트는 다음과 같습니다.
- SQL 인젝션
- 일반 텍스트 전송
- 승인되지 않은 접근
- SMS 이메일 확인
- 인증 부족
- 암호 보안
- 데이터 견고성 등