테스트 분석 및 설계 방법 - HTSM 휴리스틱 테스트 전략 모델 | JD Cloud 기술팀

분석과 설계가 없는 테스트는 영혼을 잃습니다.

테스터는 사용 사례를 작성하기 전에 테스트 분석 및 설계를 어떻게 수행해야 합니까? 저번에 " The Underlying Logic of Testing "에서 [Input and Output Test Model]에 대해 이야기했고 [2W+1H Test Analysis Method]에 대해서도 이야기했지만 2W1H 분석법은 예비 분석법이고 어떻게 구현해야 테스트에서 여전히 구현해야 합니다.얇은 디자인.

오늘은 테스팅 분야의 전문가인 James Batch가 정리한 테스트 분석 및 설계 모델과 HTSM 휴리스틱 테스트 전략 모델을 소개하겠습니다.

HTSM이란 무엇입니까?

HTSM은 테스터가 테스트 전략에 대해 더 잘 생각하도록 돕고 테스트 분석 및 설계를 수행할 때 생각하는 방법과 생각해야 할 사항에 대해 테스터를 안내하도록 설계된 일련의 테스트 사고 영감 방법입니다. HTSM에는 테스트 . James Batch는 다음과 같이 제안했습니다. 자유롭게 사용할 수 있으며 모든 유형의 소프트웨어에 공통적이며 적용할 때 실제 장면에 따라 모델의 내용을 조정하여 자신의 조직 환경에 적응하는 것이 좋습니다.

James Batch  휴리스틱 테스트 전략 모델은  수행할 테스트를 설계하고 선택하기 위한 일련의 패턴입니다. 이 모델의 즉각적인 목적은 테스터에게 해당 프로세스 중에 생각해야 할 사항을 상기시키는 것입니다.

다음은 HTSM과 2W1H 분석 방법을 비교한 것으로, 이를 통해 HTSM이 2W1H에 해당함을 알 수 있다. , 우리는 테스트 범위를 결정하고 테스트하려는 것을 명확하게 한 다음 테스트 기술 및 품질 표준을 통해 테스트 방법을 안내합니다.

HTSM과 2W1H의 비교:

HTSM 모델 개요:

HTSM 모델에서 프로젝트 환경, 제품 요소, 품질 표준 및 테스트 기술의 각 항목은 많은 하위 항목을 나열하며, 그 중 [프로젝트 환경]과 [제품 요소]는 하위 항목에 따라 완전히 분석할 필요가 없습니다. 모델에서 제공하는 항목이므로 자신에게 유용한 정보를 선별하여 분석하는데 참고자료로 활용하실 수 있습니다.

또한 내 경험을 바탕으로 일부 콘텐츠를 추가할 예정입니다. [품질 표준] 및 [테스트 기술]은 참고용으로 더 유용합니다. 원본 텍스트를 자세히 번역했습니다. 단지 모델일 뿐이므로 작성자가 각각을 이해하지 못합니다 시험방법이나 시험기준에 대한 상세한 설명은 저자가 자신의 경험을 바탕으로 작성한 요약일 뿐이며 누구나 자신의 경험을 바탕으로 보다 구체적인 방법을 요약할 수 있으나 시험기술 및 품질기준의 각 하위 항목은 다음과 같이 사용할 수 있다. 테스터 테스트 설계의 참조 표준인 품질 표준은 ISO9126 소프트웨어 품질 모델을 참조할 수도 있습니다.

요컨대, 모델은 자세한 지식 설명이 아니라 테스트 분석 및 설계에서 모든 사람을 안내하는 아이디어와 방법의 모음입니다.

ISO9126 소프트웨어 품질 모델

HTSM의 네 가지 영역인 프로젝트 환경, 제품 요소, 품질 표준 및 테스트 기술이 아래에 설명되어 있습니다. 이 순서대로 HTSM을 사용하고, 2W1H 방법에 따라 분석하고, HTSM에서 제공하는 하위 항목 및 경험을 참조하여 최종적으로 완전한 테스트 계획을 세울 수 있습니다.

테스트의 첫 번째 단계: [프로젝트 환경] 테스트 전에 먼저 프로젝트 배경과 이 프로젝트를 수행하는 이유를 이해해야 합니다.

프로젝트 배경: 이 프로젝트를 수행하려는 이유는 무엇입니까? 프로젝트를 진행하게 된 배경은 무엇인가요?

문제 해결: 이 프로젝트는 어떤 문제를 해결합니까?

배경을 이해함으로써 우리는 우리가 필요를 분석하고 가장 원래의 요구와 목적을 이해하는 데 더 도움이 될 수 있습니다. 요구 사항 문서에서 문제나 결함을 파헤칠 수 있도록 비즈니스와 요구 사항을 더 잘 이해할 수 있습니다.

프로젝트 수준: 전략적인 프로젝트인가? 아니면 기술 유지 보수 및 업그레이드 프로젝트입니까? 프로젝트의 수준을 이해하는 것은 또한 우리가 투자해야 할 자원을 결정하는 중요성의 정도이며, 품질 요구 사항은 어떤 수준이며 사용자의 품질 요구 사항은 무엇입니까?

프로젝트의 예상 완료 시간: 완료 시간을 이해하면 향후 어떤 테스트 전략을 채택할지, 어떤 테스트 방법을 채택해야 하는지, 온라인에 접속한 후 사용할 수 있는지 여부 등을 결정할 수 있습니다. 예를 들어, 시간이 매우 촉박하고 가장 중요한 것은 기능을 보장하는 것입니다.다른 성능은 온라인 계획에 따라 많은 사용자가 사용할 것인지 소수의 시드 사용자만 사용할 것인지; 온라인 후에 호환성을 구현할 수 있는지 또는 C 호환성을 보장해야 하는지 여부 자동 테스트가 불가능할 수 있거나 자동화 기술이 매우 성숙하여 녹음 관련 도구와 풍부한 경험을 갖춘 다음 자동 녹음 도구 또는 녹음 및 재생 도구 이 시간 효과에 큰 역할을 할 수 있습니다.

시스템 사용자 상황: 시스템 사용자는 누구인가? 사용자는 몇 명입니까? 사용자 수에 주의를 기울이기 위해 첫 번째는 시스템에 성능 압력 테스트 요구 사항이 있는지 여부를 아는 것이고 두 번째는 시스템 사용자가 수십, 수백 또는 수천 명인지 아는 것입니다. 사용자 수가 다르고 값도 달라야 합니다.

시스템의 고객은 누구인가: 시스템의 고객은 누구인가? 고객의 가장 독창적인 요청은 무엇입니까?

다음은 HTSM [Project Environment]의 구체적인 내용으로, 일부 내용을 보완 및 조정하였습니다.

테스트의 두 번째 단계: [제품 요소]는 우리가 테스트할 계획입니다. 테스터는 우리가 보는 부분뿐만 아니라 모든 제품 요소가 포함되어 있는지 확인해야 합니다.

궁극적으로 제품은 고객에게 제공되는 경험 또는 솔루션이며, 제품은 여러 차원을 가지고 있으며 잘 테스트하려면 우리가 다루는 차원이 포괄적이어야 합니다. 각 치수는 제품의 고유한 측면을 나타냅니다 . 테스트가 적용 범위의 일부만 다루는 경우 심각한 버그를 놓칠 위험이 있습니다. 제품의 요소를 분석하는 것은 테스트 범위와 테스트해야 할 측면 또는 콘텐츠를 분석하는 것입니다. 대부분의 사람들은 테스트 범위가 요구 사항 문서에서 나온다고 결정하지만 실제로 요구 사항 문서 외부에는 우리의 주의가 필요하고 테스트해야 하는 많은 사항이 있습니다. 다음은 HTSM의 [제품 요소]입니다.

HTSM 모델 [제품 요소]는 많은 내용을 나열하고 상대적으로 복잡하며 이러한 내용은 참조로 사용할 수 있으며 다음 내용에 따라 완전히 테스트할 필요는 없습니다.

구조 구조: 제품에 포함된 모든 것;

우리는 소프트웨어 테스트에 대부분의 시간을 보내고 하드웨어 부분은 무시하기 쉽습니다. 또한 도움말 문서, 라이센스 계약, 등 업무용으로 제공되는 경우가 많지만 회사, 제품, 사용자에 대한 책임을 지기 위해서는 여전히 실행 불가능한 이러한 문서를 확인해야 합니다. 도움말 문서가 이해하기 쉬운지, 오류가 있거나 시스템 기능과 일치하지 않는 모든 누락은 온라인에 들어가기 전에 시스템에 가장 익숙한 사람이 제품 관리자나 R&D가 아니라 테스터이기 때문입니다.

또한 제 경험을 공유하고 싶습니다. 우선 테스트 범위를 결정하는 것이 매우 중요하며 대부분의 사람들은 이 단계를 무시하고 테스트를 놓칠 수 있습니다. 이 단계는 우리의 테스트 기반이 PRD이므로 테스트 범위가 PRD에 있기 때문에 무시하기 쉽습니다. .

0부터 시작하는 새 프로젝트의 경우 테스트 범위를 두 가지 관점에서 고려할 수 있습니다.

1. 제품의 관점에서 PRD를 분석하는 것은 기본적으로 충분하지만, PRD의 일부 내용이 간과되거나 생략될 수 있으므로 니즈를 분석하고 존재할 수 있는 숨겨진 니즈를 파헤쳐야 합니다.

2. 기술적인 관점에서 사용자가 볼 수 있는 조작 가능한 기능 외에 외부에서 제공하는 인터페이스 서비스, 시스템의 배경, 예약된 작업, 온라인에 들어가기 전에 새로 고침되는 기본 데이터, 사전 데이터 등

유지 관리 항목을 1.X에서 1.(X+1) 또는 2.0으로 업그레이드:

일반적인 테스트 범위 평가 외에 가장 중요하고 어려운 것이 회귀 테스트 범위, 즉 원래 시스템에 미치는 영향의 범위를 평가하는 것이 가장 어렵습니다.

회귀 테스트의 범위 결정은 실제로 비용과 품질 사이의 게임입니다. 매우 높은 품질 요구 사항이 있는 소프트웨어의 경우 각 테스트에는 전체 회귀가 필요하므로 이 시나리오에서는 자동 회귀 테스트가 매우 중요합니다. 시간 요구 사항 허용 또는 제어 가능한 매우 긴급한 품질 위험의 경우 회귀 범위는 이 수정의 관련 기능으로 좁힐 수 있지만 대부분의 시나리오에서 시간 요구 사항은 상대적으로 빡빡하지만 품질은 문제가 될 수 없습니다. 이때의 범위를 어떻게 정할 것인가는 첫째, 본 수정의 관련 기능의 복귀가 필수적이며, 둘째, 시스템의 최하위선을 유지하는 것, 즉 시스템의 어떤 기능이 할 수 없는지를 결정하는 것이 필요하다. 문제를 일으키며, 매번 시스템으로 이러한 기능을 사용해야 함 회귀에 필요한 범위 . 또한 code diff 기능을 사용하여 변경 사항과 영향을 받는 기능을 분석할 수 있습니다.

기능 회귀 범위의 평가 외에도 업그레이드 프로젝트의 경우 원본 데이터의 호환성 검증에 주의를 기울여야 합니다 . 아마도 다음과 같은 상황이 있을 것입니다.

1) 기능 변경이 원래 진행 중인 데이터의 작동에 영향을 미치는지 여부

2) 공정상의 변경, 공정상의 자료 또는 거절되어 재제출된 자료가 정상적으로 수행될 수 있는지 여부

3) 데이터 전송 대상(PO, VO, DTO 등)이 변경되어 진행 중인 데이터나 재편집된 데이터가 정상적으로 동작할 수 있는지 여부는 데이터의 전송 또는 저장 여부를 확인하는 것이 가장 중요합니다.

4) 기본 데이터베이스 테이블의 변경 사항은 원래 데이터의 표시 및 작동, 새 필드를 새로 고쳐야 하는지 여부, 스와이프 후 기능이 정상인지 여부에 영향을 미칩니다.

테스트의 세 번째 단계: [품질 표준], 특정 테스트 전략을 결정하고 시스템이 수행해야 하는 테스트 유형을 명확히 합니다.

품질 표준은 제품 정의가 충족해야 하는 몇 가지 요구 사항이며 시스템이 검증을 통과했는지 테스터가 판단하는 규칙입니다. 다양한 유형의 표준을 고려하여 테스트를 보다 잘 계획하고 중요한 문제를 빠르게 찾을 수 있습니다. 다음 각 유형은 잠재적인 위험 영역으로 간주될 수 있습니다.

기능 : 시스템이 올바르게 작동하고 사용자 요구를 충족합니까?

신뢰성 : 어떤 상황에서도 작동합니까?

• Robustness (fault tolerance) : 시스템에 장애가 발생했을 때 자동으로 복구할 수 있는지 또는 장애에도 불구하고 계속 작동할 수 있는지 여부.
• 오류 처리: 제품은 잘못된 데이터가 있는 경우에도 실패하지 않으며 정상적으로 실패하고 쉽게 복구됩니다. (실패 시에도 정확한 신속한 정보 제공 및 대처 방법을 사용자에게 알려줄 수 있습니다.)
• 데이터 무결성: 시스템의 데이터가 보호되며 데이터 손실이나 데이터 손상이 발생하지 않습니다.
• 안전: 시스템이 실패한 후 큰 손실을 일으키지 않습니다.

사용성: 실제 사용자가 제품을 사용하기 쉬운가?

• 학습 용이성: 대상 사용자가 제품 작동을 빠르게 마스터할 수 있습니다.
• 쉬운 작동: 제품을 쉽게 작동할 수 있습니다.
• 접근성: 해당 제품은 관련 접근성 표준을 준수하며 O/S 접근성 기능과 함께 작동합니다.

보안 : 제품 이 무단 사용이나 침입으로부터 어떻게 보호됩니까?

• 인증: 로그인한 사용자가 시스템에 의해 인증되었는지 여부
• 권한 부여: 사용자의 권한이 다양한 역할 또는 수준에 따라 제어 및 권한 부여되는지 여부
• 프라이버시: 고객 또는 직원 데이터가 암호화되어 있습니까?

확장성( Scalability ): 시스템의 성장(데이터 볼륨, 트래픽, 복잡도)에 대처하기 위한 합리적인 계획이 있는지 여부

호환성( Compatibility ): 외부 구성 요소 및 구성과 호환되며 정상적으로 작동합니까? 서로 다른 하드웨어 플랫폼, 서로 다른 응용 프로그램 사이, 서로 다른 운영 체제 및 서로 다른 네트워크 환경에서 정상적으로 실행될 수 있는지 여부.

• 애플리케이션 호환성: 제품이 다른 소프트웨어 제품과 작동하는지 여부.
• 운영 체제 호환성: 제품이 다른 유형의 운영 체제에서 작동할 수 있는지 여부.
• 브라우저 호환성: 제품이 다양한 유형 및 버전의 브라우저와 호환되는지 여부.
• 하드웨어 호환성: 이 제품은 특정 하드웨어 구성 요소 및 구성과 함께 작동합니다.
• 이전 버전과의 호환성: 제품이 이전 버전과 동시에 사용할 수 있는지 여부, 데이터 및 기능이 호환되는지 여부.

성능( Performance ): 시스템이 충분히 반응하는가?

성능 테스트는 종종 전담 성능 테스터에 의해 수행되지만 기능 테스터도 주의를 기울여야 합니다. 일반적인 동시 스트레스 테스트 외에도 실제로 더 많은 시나리오가 시스템의 많은 양의 데이터로 인해 결국 쿼리로 이어집니다. , imports , export 및 기타 기능은 매우 느리게 응답합니다. 특히 동시성이 발생하거나 여러 작업이 병렬화되는 경우 내보내기 작업이 결국 며칠 후에 완료될 가능성이 큽니다.

설치성 : 해당 플랫폼에 시스템을 쉽게 설치할 수 있는지 여부 .

• 시스템 요구 사항: 일부 필수 구성 요소가 없거나 부족하다는 것을 제품이 인식합니까?
• 구성: 시스템의 어떤 부분이 설치의 영향을 받습니까? 파일과 리소스는 어디에 저장됩니까?
• 제거: 제품을 제거하면 정리할 수 있습니까?
• 업그레이드/패치: 새 모듈을 쉽게 추가하거나 새 버전을 업그레이드할 수 있습니까? 기존 구성에 영향을 줍니까?
• 관리: 전담 관리자가 설치를 처리합니까, 아니면 특별한 일정이 있습니까?

유지보수 용이성( 개발 ): 시스템 개발, 테스트 및 유지보수가 쉬운가?

• 지원 가능성: 제품 사용자에게 보다 저렴한 비용으로 지원 및 지원을 제공할 수 있는지 여부

• 테스트 용이성: 가능한 한 간단한 방법으로 빠른 테스트를 수행할 수 있습니까?

• 유지 보수성: 제품을 구축, 수정 또는 개선하는 것이 얼마나 쉽고 비용이 많이 듭니까?

• 이식성: 다른 곳에서 기술을 이식하거나 재사용하는 것이 얼마나 경제적입니까?

• 현지화 가능: 제품을 다른 곳에 적용하는 것이 얼마나 경제적입니까?

테스트의 네 번째 단계: [테스트 기술], 테스트 방법, 테스트에 사용되는 수단 및 방법을 결정하여 시스템 품질이 품질 표준 및 요구 사항을 충족하는지 확인합니다.

테스트 기술은 테스트의 전략 분석이며 일반적으로 사용되는 테스트 기술은 다음과 같습니다.

기능 테스트 기능 테스트: 제품의 각 기능을 검증하고 _기능 테스트_유스 케이스에 따라 항목별로 테스트하여 제품이 사용자가 요구하는 기능을 충족하는지 확인합니다.

클레임 테스트 제약 조건 테스트:  모든 클레임에 도전하세요! 사용자가 보는 모든 자료에 언급된 기능의 정확성과 일관성을 보장합니다.

1) SLA, 광고, 매뉴얼, 도움말, 운영매뉴얼 등 관련 참고자료를 명확히 함 (_SLA_는 일반적으로 서비스 수준 계약을 의미함. 서비스 수준 계약은 서비스를 제공하는 기업과 고객 간의 서비스 계약을 의미함) 양 당사자가 품질, 수준, 성능 등의 측면에서 상호 인정하는 합의 또는 계약)

2) 위의 정보를 참조하여 제품의 각 진술을 테스트하십시오.

Flow Testing 흐름 테스트: 특정 순서로 수행되는 테스트

1. 여러 처리 단계로 연결된 테스트 프로세스

2. 관련 작업 또는 프로세스 간에 시스템을 재설정하지 마십시오.

3. 시간 및 순서 변경 및 동시 작업 수행

도메인 테스트 필드 테스트:

1) 제품의 가능한 입력 및 출력을 분석합니다.

2) 테스트를 위해 테스트에 사용된 데이터를 결정합니다. 예로는 경계값, 대표값, 일반적으로 사용되는 값, 유효하지 않은 값, 가장 대표적인 값 등이 있습니다.

3) 테스트된 데이터의 조합을 고려하십시오.

시나리오 테스트

1) 가능한 모든 실제 시나리오를 먼저 고려하십시오.

2) 제품에 대한 의미 있는 기능과 복잡한 상호작용 시나리오를 포함한 테스트 케이스 설계

3) 좋은 시나리오 테스트는 중요한 사람이 자신에게 중요한 일을 어떻게 하는지에 대한 설득력 있는 이야기입니다.

스트레스 테스트 스트레스 테스트

1) 스트레스 테스트 범위 결정 이 하위 시스템 또는 기능은 매우 많은 양의 데이터 압력을 받거나 리소스 제약으로 인해 많은 동시성이 시스템 과부하 또는 "손상"을 유발할 수 있습니다.

2) 이러한 하위 시스템 및 기능과 관련된 데이터 및 리소스를 식별합니다.

3) 제한된 조건(예: 크거나 복잡한 데이터 구조, 높은 부하, 긴 테스트 실행, 많은 수의 테스트 사례 실행, 낮은 메모리 조건)에서 어려운 데이터 또는 리소스를 선택하거나 생성합니다.

자동 확인자동 테스트

위험 테스트 위험 테스트

1) 제품에 어떤 문제와 위험이 발생할 수 있는지 생각해보십시오.

2) 어떤 문제가 발생할 가능성이 가장 높습니까? 발생할 가능성이 높은 문제에 집중

3) 존재한다면 어떻게 탐지하고 발견할 것인가?

4) 이러한 문제를 나열하고 이를 마이닝하는 데 특별히 사용되는 해당 테스트 케이스를 설계합니다.

5) 관련 전문가와 상담하거나 설계 문서, 과거 결함 보고서를 검토하거나 위험 휴리스틱을 적용하는 것도 도움이 될 수 있습니다.

사용자 테스트사용자 테스트

1) 사용자 범주 및 역할 식별

2) 각 범주의 사용자가 매일 수행할 작업, 일반적으로 어떻게 작동하며 어떤 기능에 중점을 둘지 결정합니까?

3) 실제 사용자 데이터를 얻거나 실제 사용자를 소개하고 미리 테스트를 위해 시스템을 사용하십시오.

4) 실제 사용자의 사용 시나리오를 체계적으로 시뮬레이션(실제 사용자는 아니지만 사용자로 자신을 상상하기 쉽습니다)

5) 최상의 사용자 테스트에는 단일 사용자 또는 사용자 작업뿐만 아니라 다양한 사용자 역할, 다중 사용자 병렬 및 교차 작업이 포함됩니다.

저자: JD Retail Zhang Qiang

콘텐츠 출처: JD Cloud 개발자 커뮤니티

{{o.이름}}

{{이름}}