제품 및 일부 사용자가 사용한 후 해당 수정 의견을 제공하고 괜찮다고 생각한 후 온라인에 접속하여 인터넷 또는 일부 앱 다운로드 플랫폼에서 직접 사용할 수 있으며 표준화된 소프트웨어 테스트가 수행되지 않았습니다 ! 이러한 소프트웨어에는 다소 버그가 있으며 이러한 버그는 기능, 호환성, 성능 등의 문제일 수 있습니다!
낮은 소프트웨어 품질 문제를 개선하기 위해 소프트웨어 테스트 산업이 주목을 받기 시작했습니다! 소프트웨어 테스트의 목적은 소프트웨어 품질을 개선하고 사용자에게 더 나은 경험을 제공하는 것입니다!
소프트웨어 테스팅 프로세스
개발이든 테스팅이든 수요측이 있고, 수요측과의 소통을 통해 정보가 통합되고 수요 사양이 만들어진다! 요구 사항 사양: 소프트웨어 기능, 성능, 호환성, UI 등에 대한 사용자 요구 사항의 텍스트를 말합니다! 개발 요구 사항 사양에 따라 프로그램을 개발하고 설계하십시오! 그러나 일부 회사는 요구 사항 사양을 제공하지 않으며 대부분의 회사는이 부분에서 요구 사항으로 회의 및 설계 모델을 불규칙적으로 사용합니다.이 목적은 요구 사항이 명확하지 않고 통신 비용이 너무 많이 든다는 것입니다!
다음은 더 엄격하거나 표준화된 테스트 흐름도입니다.
테스트 포인트 추출
요구사항 명세서가 검토를 통과한 후 개발, 제품, 테스트에 대한 통합된 요구사항 문서가 있으며, 요구사항 명세서를 기반으로 테스트는 요구사항 명세서의 내용을 기반으로 테스트 포인트를 추출합니다. 테스트 포인트는 일반적으로 다음과 같습니다. 하나의 테스트 포인트 테스트 사례에 해당합니다! 요구 사항의 범위를 보장하기 위해! 일반적으로 테스터는 요구 사항 사양에 따라 테스트를 직접 작성하므로 요구 사항의 불완전한 커버리지로 쉽게 이어질 수 있습니다! 테스트 포인트에는 요구 사항 사양에 표시된 수요 포인트뿐만 아니라 일부 암시적 요구 사항도 포함되어 있어 추출된 테스트 포인트가 가능한 한 많은 요구 사항을 충족할 수 있습니다!
테스트 케이스 설계 및 사용 케이스 검토
테스트 케이스는 소프트웨어 테스트의 가장 작은 세분화된 단위이며 테스트의 핵심 포인트 중 하나입니다. 당신이 테스트의 신참이든 수년 동안 테스트의 베테랑이든 테스트 케이스 테스트는 없어서는 안될 부분입니다! 회사의 업무에 따라 각 회사의 테스트 사례가 다릅니다.템플릿의 공통 핵심 매개변수는 주로 다음 사항을 포함합니다: 유스 케이스 ID, 유스 케이스 이름, 유스 케이스 설명, 실행 단계, 예상 결과, 실제 결과, 소속 기능 모듈, 사용 사례 상태, 소속 버전 번호, 작성자, 생성 날짜. 일부 회사에는 우선 순위, 전제 조건 등이 있습니다. 이러한 속성은 자체 비즈니스에 따라 개선에 사용됩니다. 테스트 케이스 디자인의 주요 포인트는 간단하고 명확하며 체계적입니다!
다음 그림은 간단한 테스트 사례 템플릿을 보여줍니다. 템플릿의 속성은 자신의 필요 또는 비즈니스에 따라 확장 및 삭제할 수 있습니다. 일반적으로 사용 사례 속성은 열에 표시됩니다. 다음은 제가 제공한 양식 템플릿입니다.
1. 테스트의 요점을 명확하게 하고, 요구 사항에 대한 이해를 통일하고, 테스트의 완전성을 보장합니다.유스 케이스 설계가 완료된 후 테스트의 다음 단계는 시작하는 것이 아니라 사용하는 것입니다. 사례 검토. 요구사항 명세가 주어졌음에도 불구하고 제품, 개발, 테스트에서 통일된 요구사항에 대한 이해의 차이가 있을 수 있으므로 구현 및 테스트에서 다른 결과가 나타납니다. 이 파트의 주요 목적은 다음과 같습니다.
2. 테스트 케이스 설계가 기능 요구 사항을 완전히 포함하는지 검토합니다.
3. 테스트 시간 노드를 결정합니다.
이 단계의 참가자는 주로 제품, 개발 및 테스트이며 대기업에서는 프로젝트 리더도 사용 사례 검토에 참여합니다.
테스트 유형 선택
사용 사례가 설계되고 검토된 후 테스트 구현을 위한 다양한 테스트 방법을 선택해야 합니다. 일반적으로 프로젝트에 포함되는 테스트 유형은 수동 테스트, 블랙 박스 테스트/기능 테스트, 화이트 박스 테스트, 자동 테스트, 호환성 테스트, 인터페이스 테스트, 성능 테스트, 침투 테스트 등입니다.
리터 수동 테스트
주로 더 복잡한 논리와 덜 자주 사용하는 일부 기능을 수행하십시오! 그러나 현재 대부분의 회사에서 수동 테스트를 사용하여 앱 테스트의 약 70%를 차지합니다.
l 자동화된 테스트
주로 반복적이고 자주 사용되는 경우에 사용합니다. 자신의 기술에 따라 적절한 언어와 도구를 선택하여 자동화를 실현할 수 있습니다! 현재 RF, UFT(QTP), winrunner, selenium, appium, uiautomator, XCUITEST 등 시장에서 많이 사용되고 있습니다. 관심있는 분들은 직접 알아보세요! 자동화 스크립트를 설계하기 전에 해당 업무를 분류하고, 테스트 실행 프로세스를 설계하고, 테스트 데이터를 준비해야 합니다.
엘 인터페이스 테스트
인터페이스 테스트는 반환 매개변수와 인터페이스의 상태가 올바른지 확인하는 것으로 인터페이스 테스트 초기 단계에서 다음과 같은 준비가 필요합니다.
개발자가 서비스 인터페이스(인터페이스 경로, 헤더 파일, 요청 데이터 형식 등)를 제공합니다.
b. 테스트 데이터를 제공합니다. 로그인을 예로 들어 보겠습니다. 사용자 이름과 암호의 다양한 조합이 필요합니다.
c.처음 두 부분에 따라 Postman, RESTClient, Fiddler 및 Charles 중 하나를 선택하여 요청을 시뮬레이트할 수 있습니다. 요청이 성공적으로 전송되고 !
d. 모의 설계 요청 형식에 따라 해당 테스트 도구를 선택합니다. 현재 주류 인터페이스 테스트에는 주로 Jmeter, Locust 및 직접 작성한 일부 스크립트가 포함됩니다. Jmeter는 인터페이스 테스팅 뿐만 아니라 동시성 테스팅, 프레셔 테스팅, 인터페이스 기반의 부하 테스팅도 할 수 있지만 성능과 안정성이 로드러너만큼 좋지는 않습니다. .
스크립트 작성을 위한 프로젝트 디렉토리에는 일반적으로 라이브러리 파일 라이브러리, 테스트 데이터 파일 데이터, 테스트 케이스 파일, 테스트 보고서, 로그 파일 및 기본 프로그램이 포함됩니다.
엘 호환성 테스트
기기, 브라우저, 운영 체제의 다양성으로 인해 제품이 온라인되기 전에 일반적으로 다른 기기(다른 해상도), 브라우저 및 운영 체제에서 작동하여 애플리케이션이 정상적으로 표시되는지, 애플리케이션 기능이 응답할 수 있는지 확인합니다. 보통! 호환성 테스트는 현재 주로 모바일 장치 호환성, 운영 체제 호환성 및 브라우저 호환성을 나타냅니다.
호환성 테스트 방법은 테스트 벤치마크를 결정하고 테스트 벤치마크를 예상 결과로 가져와 다른 장치, 브라우저 및 운영 체제에서 동일한 작업을 수행하는 것입니다.테스트 벤치마크와 일치하여 응용 프로그램이 요구 사항을 충족함을 나타냅니다. 호환성 측면에서 사용자 또는 제품의.
엘 성능 테스트
성능 테스트는 완전한 기능과 인터페이스를 기반으로 하며 서버에서 스트레스 테스트, 로드 테스트, 피로 테스트 및 동시성 테스트를 수행하여 성능 병목 현상을 발견합니다.
성능 테스트에는 주로 다음이 포함됩니다.
1. 수요 추출, 이 부분에는 응답 시간, 동시 사용자 수, TPS, 처리량, CPU 사용률, 메모리 사용량, 온라인 동시 사용자 수 등이 포함됩니다.
2. 요구사항 전략 수립: 성능 테스트 시나리오 설계! 다음은 로그인의 예입니다.
동시 사용자 수: 150, 200, 250 및 300;
사용자 간격: 1, 2, 2 및 2;
연속 실행 시간: 20, 30, 30 및 30.
3. 테스트 데이터 준비
여기서의 테스트 데이터는 자동 테스트에서 사용하는 테스트 데이터와 다르며, 여기의 테스트 데이터는 요구 사항을 효과적으로 구성하는 데이터이며 이 데이터를 사용하라는 요청은 성공적인 데이터에 응답할 수 있습니다.
4. 테스트 도구 선택
테스트 도구는 개인적으로 크랙 버전의 loadrunner를 권장하는데 주된 이유는 다음과 같습니다. loadrunner는 또한 더 표준화되고 더 선별적입니다. 요구 사항이 그다지 표준화되지 않은 경우 jmeter를 선택할 수 있습니다.jmeter의 동시 사용자 수는 압력 테스트의 클라이언트 구성과 관련이 있지만 초보자에게 적합합니다.당신을 위해 회사는 나를 요구하지 않습니다. 기본 성능 테스트 및 인터페이스 테스트를 충족할 수 있는 이것을 사용하도록 권장합니다. loadrunner의 내부 프로그래밍 스크립트는 C 언어를 사용하며 엔트리 레벨이 비교적 높습니다.
5. 적절한 성능 카운터 및 관련 성능 분석 지표를 선택합니다.
여기서 성능 카운터는 클라이언트가 아닌 서버에서 설정한다는 점에 유의하십시오.서버에 대한 권한이 없으면 스트레스 측정 시간 노드를 기록하고 서버와 통신하여 서버의 성능 지표를 얻어야 합니다. 이 기간 동안.
성능 분석 지표: 응답 시간, 동시 접속자 수, TPS, 처리량, 온라인 동시 접속자 수
6. 스트레스 테스트를 수행하고 테스트 테스트 데이터 또는 보고서를 얻습니다.
7. 성능 테스트 보고서 작성
l 침투 테스트
기술의 발전과 모바일 결제의 발달로 보안 테스트가 점차 주목받고 있다. 보안 테스트는 광범위한 지식이 필요하고 개인 수준이 제한되어 있으므로 여기서는 아무것도 잘못하지 않겠습니다! 그러나 현재 주류 침투 테스트 플랫폼은 주로 BT5와 Kali입니다.이 두 플랫폼은 보안 테스트에 가장 많이 사용되는 도구와 명령을 수집합니다.관심있는 경우 온라인에서 확인하거나 개인 메시지를 보내 주시면 알려 드리겠습니다. 학습 문서!
테스트 실행 및 결함 관리
테스트 실행에는 테스트 케이스 수동 실행, 자동 테스트 스크립트 실행, 인터페이스 테스트 스크립트, 성능 테스트 스크립트, 호환성 테스트 등이 포함됩니다. 이 과정에서 버그가 발견되면 회사의 버그 관리 시스템을 선택하여 버그를 기록할 수 있습니다. 버그 관리 시스템에는 현재 bugzilla, mantis, bugtags 등이 포함됩니다. 이러한 도구를 사용하지 않은 경우 doc 또는 excel을 사용하여 직접 버그 모듈을 만들 수 있습니다. 버그의 핵심 속성에는 bugId, 버그 이름, 버그 설명, 심각도 수준, 우선 순위, 기능 모듈, 버전 번호, 개발자, 재현 단계, 예상 결과 및 실제 결과가 포함됩니다.
결함 라이프 사이클 순서도:
버그 보고서 템플릿은 다음과 같습니다.
회귀 테스트 및 인수 테스트
회귀 테스트는 시간표에 따라 적절한 회귀 전략을 선택하고 시간이 충분하면 모든 테스트 케이스를 실행하고 시간이 충분하지 않으면 핵심 테스트 케이스 및 버그 수정 테스트 케이스를 실행하도록 선택합니다.
합격시험은 제품 또는 사용자가 제품의 기능구현, 페이지 표시, 성능 등이 요구사항 명세에 따라 요구사항 명세의 요구사항과 일치하는지 여부를 확인하는 것을 요구하며, 일치한다면 제품이 요구사항을 만족하고 합격한 것을 의미합니다. 수락.
시험성적서
시험종료 후 각 단계의 시험품을 제출하여야 한다. 테스트 요구 사항 문서, 테스트 사례, 자동화 스크립트, 성능 테스트 스크립트, 성능 테스트 보고서, 자동화 실행 보고서, 인터페이스 스크립트 및 보고서 등
요약
위에 제시된 소프트웨어 테스트 프로세스와 각 프로세스에서 수행해야 하는 작업은 무엇입니까? 이 기사를 통해 테스트 프로세스, 테스트 케이스 작성, 버그 작성 및 관리의 세 가지 핵심에 집중해야 합니다. 관련된 테스트 유형에 대해서는 여기에서 간략하게 언급합니다.기사에 언급 된 도구 및 기술은 개인 메시지로 수신하고 테스트에 대해 함께 논의하고 함께 배우고 함께 발전하며 서로 도움이 될 수 있습니다. 함께하는 시험의 길
