최소 개념 원리

계획

수요 분석

설계

코딩

시험

운영 및 유지보수

전통적인 폭포 모델

V 모델

W 모델

민첩한 개발 모델

정의

콘텐츠

이식성과 호환성의 차이점:

블랙박스 테스트

화이트 박스 테스트

회색 상자 테스트

통합 테스트

확인 테스트

시스템 테스트

회귀 테스트

승인 테스트: 공급 및 수요 당사자와 제3자가 테스트하며, 다양한 실행 주제에 따라 ɑ 테스트(내부), 베타 테스트(공개 베타), γ 테스트로 나눌 수 있습니다.

개발단계 주요문서

테스트 단계의 주요 문서

분석하다

기획 : 테스트 계획 및 솔루션 문서 작성

디자인: 테스트 케이스 디자인

구현: 테스트 케이스, 테스트 스크립트 등 작성

실행: 테스트 환경 설정, 테스트 스크립트 실행, 결함 보고

정의

목적

프로세스

전략

정의

테스트 대상

테스트 기능

테스트 결론

테스트 네트워크 다이어그램

하드웨어 환경

소프트웨어 환경

관련 통계

최소 개념 원리

계획

수요 분석

설계

코딩

시험

운영 및 유지보수

전통적인 폭포 모델

V 모델

W 모델

민첩한 개발 모델

블랙박스 테스트

화이트 박스 테스트

회색 상자 테스트

통합 테스트

확인 테스트

시스템 테스트

회귀 테스트

승인 테스트

개발단계 주요문서

테스트 단계의 주요 문서

분석하다

기획 : 테스트 계획 및 솔루션 문서 작성

디자인: 테스트 케이스 디자인

구현: 테스트 케이스, 테스트 스크립트 등 작성

실행: 테스트 환경 설정, 테스트 스크립트 실행, 결함 보고

①테스트 활동과 개발이 동시에 진행됩니다.

②테스트 대상은 프로그램뿐만 아니라 요구사항 및 설계도 포함됩니다.

③소프트웨어 결함을 조기에 발견하면 개발 비용을 절감할 수 있다

유연한 버전 반복을 지원할 수 없습니다.

민첩한 개발 및 테스트 모델은 주로 현대 인터넷 회사의 "짧고, 평평하고, 빠른" 개발 리듬에 적응하도록 설계된 개발 및 테스트 모델입니다.

①반복: 각 반복을 스프린트라고 합니다. 각 스프린트에서 구현하기 위해 선택한 요구 사항은 스프린트 백로그에 정리됩니다. 각 스프린트는 일반적으로 한 주기로 진행됩니다.

② 제품 소유자 : 제품 관리자와 동일합니다. 전체 프로젝트의 모든 요구사항을 정리하고 우선순위에 따라 요구사항을 Produce Backlog에 정리합니다.

③ 일일회의 : 일일회의로, 주로 스탠드업 미팅 형태로 진행됩니다. 각 사람의 연설은 일반적으로 1분을 초과하지 않으며 주요 내용에는 어제 완료된 작업, 오늘 수행할 작업, 직면한 위험과 문제의 세 가지 사항이 포함됩니다.

④ 스프린트 번다운: 남은 작업량을 기록하는 반복적 번다운 차트

⑤ 스프린트 검토 회의: 반복 검토 회의로 주로 이번 반복에 어떤 문제가 있었고 개선 방법 등을 검토합니다.

⑥ 스크럼 마스터 : 팀장에 해당하며, 팀원을 일원적으로 관리하는 역할

①기존 결함이 수정되었는지 확인

② 하자보수로 인해 새로운 하자가 발생하지 않는지 확인

수요는 어디서 오며, 수요가 없다면 어떻게 될까요?

요구사항 평가를 어떻게 평가하나요?

테스트 요구사항 분석을 수행해야 하는 이유는 무엇입니까?

테스트 요구사항 분석 프로세스

테스트 번호: TC TestCase

테스트 제목: 이 사용 사례가 테스트하는 테스트 포인트를 설명하려면 한 문장을 사용하세요.

우선순위: 높음, 높음, 낮음. 프로젝트 시간이 부족하거나 인력이 부족한 경우 주요 테스트 사례를 우선적으로 테스트할 수 있는 기능입니다.

사전 설정된 조건: 이 사용 사례를 실행할 때 시스템이 미리 도달해야 하는 상태 또는 조건입니다. 선택사항, 있으면 쓰고, 없으면 쓰지 마세요.

테스트 단계: 이 사용 사례를 테스트할 때 어떤 작업을 수행해야 하는지 자세히 설명합니다.

기대 결과: 필요에 따라 발생하고 우리가 달성해야 하는 결과입니다.

실제 결과: 실제 운영 체제 이후에 얻은 결과입니다.

테스트 결과: 통과/실패/NA 통과 예상 결과는 실제 결과와 동일합니다. 실패 예상 결과와 실제 결과가 다릅니다. N/A는 현재 사용 사례가 적용 가능하지 않거나 작동 불가능함을 의미합니다.

동등 클래스 테이블을 작성하고, 각 입력에 대해 동등 클래스를 나누고, 동등 클래스 테이블을 얻고, 각 동등 클래스에 대한 고유 번호를 지정합니다.

아직 다루지 않은 유효한 동등 클래스를 가능한 한 많이 포함하는 테스트 케이스를 설계하십시오. 모든 유효한 동등 클래스가 테스트 사례에 포함될 때까지 이 단계를 반복합니다.

하나의 유효하지 않은 동등 클래스만 다루도록 테스트 케이스를 설계하십시오. 잘못된 동등 클래스가 모두 포함될 때까지 이 단계를 반복합니다.

입력 조건이 값 범위 또는 값 개수를 지정하는 경우 유효한 동등 클래스 1개와 유효하지 않은 동등 클래스 2개를 결정할 수 있습니다.

입력 조건은 입력 값 세트를 지정하거나 충족해야 하는 조건을 지정합니다. 그런 다음 유효한 동등 클래스와 유효하지 않은 동등 클래스를 결정할 수 있습니다.

입력조건이 Boolean 값인 경우 유효한 동등클래스와 무효한 동등클래스를 판단할 수 있다.

이미 분할된 동등 클래스의 각 요소가 프로그램에서 다르게 처리된다는 것을 확실히 안다면, 동등 클래스를 더 분할해야 합니다.

입력 데이터가 준수해야 하는 규칙이 지정되면 유효한 동등 클래스(규칙 준수)와 여러 개의 잘못된 동등 클래스(다른 관점에서 규칙 위반)가 설정될 수 있습니다.

1. 프로그램의 입력 및 출력 경계를 테스트하는 블랙박스 유스 케이스 설계 방법입니다. 이때 유스 케이스는 동등 클래스의 경계에서 나옵니다.

2. 경계값 분석 방법의 이론적 근거는 다양한 입력 조건의 경계에서 대부분의 오류가 발생한다고 가정하는 것입니다. 경계 근처의 값은 프로그램 오류를 일으키지 않습니다. 그러면 다른 값이 프로그램 오류로 이어질 가능성도 매우 적습니다.

3. 경계값 사용 조건(강조: 측정 가능)

위쪽 점: 경계 위의 점

오프 포인트(Off point): 경계에 가장 가까운 포인트

내부 점: 값 범위 내의 모든 점

각 지점은 서로 다른 숫자여야 합니다. 한 지점이 위쪽 지점이자 멀리 있는 지점일 수는 없습니다.

상단 포인트: 범위에 보이는 두 포인트는 상단 포인트여야 합니다.

입력 매개변수 유형 분석: 테스트 사양에서 입력 매개변수 유형을 분석합니다.

등가클래스 분할(선택) : 입력 등가클래스 분할 방법은 등가클래스를 분할하여 경계를 결정함 : 도메인 테스트 분석 방법을 사용하여 도메인 범위의 경계(상위점, 원점, 내부점)를 결정

테스트 항목 형성: 이러한 상위 포인트, 오프 포인트 및 내부 포인트를 선택하거나 이러한 포인트의 조합을 선택하여 테스트 항목을 구성합니다.

입력(출력) 조건에서 값 범위를 지정하는 경우 범위 경계 내 및 근처의 값을 테스트 케이스로 사용해야 합니다.

입력(출력) 조건에서 값의 개수를 지정하는 경우 최대 개수, 최소 개수, 최소 개수보다 1개 작은 개수, 최대 개수보다 1개 큰 개수를 테스트 케이스로 사용한다.

프로그램 사양에 언급된 입력 또는 출력이 순서 집합인 경우 순서 집합의 첫 번째 요소와 마지막 요소를 테스트 케이스로 선택하는 데 주의를 기울여야 합니다.

프로그램에서 내부 데이터 구조를 사용하는 경우 내부 데이터 구조 경계의 값을 테스트 케이스로 선택해야 합니다.

의사결정 테이블은 여러 입력 조건 하에서 시스템이 수행하는 다양한 동작을 분석하고 표현하기 위한 도구입니다. 복잡한 논리적 관계와 여러 조건의 조합을 구체적이고 명확하게 표현할 수 있습니다.

규칙 수를 결정합니다. 예를 들어 여기에는 3개의 조건이 있고 각 조건에는 2개의 값이 있으므로 2*2*2=8 규칙이 있어야 합니다.

모든 조건 파일 및 작업 파일 나열

조건부 항목을 입력하세요.

액션 더미와 액션 아이템 채우기

유사한 규칙을 단순화하고 병합합니다.

각 규칙을 사용 사례로 변환

프로세스 분석 방법(시나리오 설계 방법이라고도 함)은 소프트웨어 시스템의 특정 프로세스를 경로로 간주하고 경로 분석 방법을 사용하여 테스트 케이스를 설계합니다. 프로세스의 모든 분기에 도달할 수 있도록 프로세스 순서에 따라 순서대로 결합합니다. 이는 화이트박스 테스트의 경로 커버리지 분석 방법에서 블랙박스 테스트로 확장된 테스트 분석 방법이다.

개념

비즈니스 프로세스 다이어그램 그리기

함수 경로 우선순위 설정

테스트 경로 결정

테스트 데이터 선택

테스트 케이스 구성

1. 송신 서브루틴을 입력합니다

2. 시스템은 사용 가능한 전송 버퍼가 있는지 확인하고 그렇지 않은 경우 전송 실패 메시지를 표시합니다.

3. 여유 버퍼가 있으면 데이터 패킷을 여유 전송 버퍼에 씁니다.

4. 시스템은 쓰기 성공 여부를 확인하고 실패하면 전송 실패 메시지를 표시합니다.

5. 쓰기가 성공하면 전송 명령을 시작하십시오

6. 성공 메시지 반환

오류 추측 방법은 경험을 바탕으로 문제가 무엇인지 추측하고 이에 따라 테스트 케이스를 설계하는 것입니다.

오류 테스트 방법은 테스트 설계의 보완 수단으로만 사용할 수 있으며 테스트 사례를 설계하는 데 단독으로 사용할 수 없습니다.

잘못된 추측은 맹목적인 추측이 아니며 근거와 목적이 없는 추측도 아닙니다. 시스템의 약점에 대한 이해와 개발자의 사각지대에 대한 이해가 바탕이 되어야 합니다.

a = [3,5,8,9,2,4]

반복하다

숫자가 아님

목록이 비어 있습니다.

순서 문제

비즈니스에 대한 친숙함과 풍부한 프로그래밍 경험

1. 먼저 인터페이스 요소가 올바르게 표시되는지 확인하십시오.

2. 페이지의 기본 기능을 테스트합니다. 페이지에 양식과 목록이 모두 있는 경우 양식 기능이 정상인지 테스트하는 것이 우선입니다.

3. 양식을 테스트할 때 양식의 각 필드를 순서대로 테스트해야 합니다. 사용자가 입력할 수 있는 모든 입력 필드는 동등 클래스 및 경계 값을 사용하는 필드의 제약 조건에 따라 고려되어야 합니다.

4. 여러 필드 사이에 상관 관계와 제약 조건이 있는 경우 단일 필드의 동등 클래스 및 경계 값을 테스트한 후 계속해서 결합 테스트를 위한 의사 결정 테이블과 같은 테스트 방법을 사용해야 합니다.

5. 양식 테스트 후 목록의 기능을 테스트하십시오.

6. 단일 페이지의 내용을 테스트한 후, 프로세스 분석 방법(시나리오 방법)을 이용하여 프로세스 관련 내용을 테스트한다.

7. 프로세스 분석 및 테스트가 완료된 후 마지막으로 오류 추측 방법을 사용하여 누락된 테스트 포인트가 없는지 확인합니다.

8.예시

요구 사항 추적 매트릭스는 제품 요구 사항, 테스트 포인트 및 테스트 사례를 기반으로 세 가지 매핑 목록을 설정하는 것을 의미합니다. 이 테이블을 요구 사항 추적 매트릭스라고 합니다.

요구사항 추적 매트릭스의 역할

JDK 설치는 주로 JAVA 실행 환경을 제공하기 위한 것입니다. (TOMCAT 서버는 Java로 작성되어 있으므로 Tomcat을 실행하기 위해서는 먼저 JAVA 운영환경을 설정해야 합니다.)

JAVA_HOME: JDK를 설치한 경로

CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar

Path 환경 변수에 %JAVA_HOME%\jre\bin 및 %JAVA_HOME%\bin 두 경로를 추가합니다.

Tomcat은 기본 웹 서버 역할을 하며 클라이언트가 보낸 모든 요청을 처리합니다.

중국어나 특수 문자가 포함되지 않은 경로에 tomcat 압축 패키지의 압축을 풉니다.

CATALINA_HOME: Tomcat 패키지의 압축을 푼 경로

Path 환경 변수에 %CATALINA_HOME%\bin 경로를 추가합니다.

bin 디렉토리에 있는 start.bat 파일을 두 번 클릭하여 Tomcat을 시작합니다.

MySQL 데이터베이스는 주로 시스템 데이터를 관리하는 데 사용됩니다.

wampserver 툴킷을 통해 mysql 애플리케이션을 설치하고 wampserver를 통해 mysql 및 apache 서버를 시작합니다.

완전한 테스트 보고서

결함 심각도

결함 상태 분류

코드 수정 후 다시 테스트

실제로 결함이 수정되었는지 확인

프로그래머가 결함을 수정할 때 새로운 결함을 도입하는지 여부

1. 테스트 전략 수립 단계에서는 회귀 테스트 전략을 수립합니다.

2. 회귀 테스트가 필요한 버전을 결정하면 버그가 수정된 버전이 반환됩니다.

3. 회귀 테스트 버전을 출시하고 회귀 테스트 전략에 따라 회귀 테스트를 수행합니다.

4. 회귀 테스트를 통과하고 결함 보고서가 닫힙니다.

5. 회귀 테스트가 실패하면 결함 보고서가 개발자에게 반환되고, 개발자는 문제를 다시 수정한 후 회귀 테스트를 위해 테스터에게 다시 제출합니다.

전액 반환

선택적 회귀

내부 시스템 테스트를 통과한 후 승인 테스트를 시작할 수 있습니다.

Acceptance Testing은 사용자 중심의 테스트이며, Acceptance 팀은 프로젝트 팀원, 사용자 대표 등으로 구성되어야 합니다.

승인 테스트는 사용자가 있는 곳에서 진행하는 것을 원칙으로 하나, 사용자의 동의가 있는 경우 회사 내에서 사용자 환경을 시뮬레이션하여 진행할 수도 있습니다.

인수 테스트: 계약서, "요구 사항 사양" 또는 "인수 테스트 계획"에 따라 완제품의 인수 테스트

제품형 프로젝트의 경우 승인 테스트는 일반적으로 알파 테스트(내부 테스트: 개발 환경에서 수행)와 베타 테스트(공개 테스트: 실제 사용 환경에서 테스트)로 구분됩니다.