위험 기반 테스트: 접근 방식, 매트릭스, 프로세스 및 예

위험 기반 테스트

위험 기반 테스트(RBT) 이는 위험 발생 확률에 기반한 소프트웨어 테스트 유형입니다. 소프트웨어의 복잡성, 비즈니스 중요도, 사용 빈도 및 위험 발생 가능성이 가장 높은 영역을 고려하여 위험을 평가하는 방식입니다. 결함위험 기반 테스트는 소프트웨어 애플리케이션의 기능 중 영향력이 크고 결함 발생 가능성이 높은 기능에 대한 테스트를 우선시합니다.

리스크란 프로젝트의 측정 가능한 성공 기준에 긍정적 또는 부정적인 영향을 미치는 불확실한 사건의 발생을 의미합니다. 이러한 사건은 과거에 발생한 사건, 현재 진행 중인 사건, 또는 미래에 발생할 가능성이 있는 사건일 수 있습니다. 이러한 불확실한 사건들은 프로젝트의 비용, 사업, 기술 및 품질 목표에 영향을 미칠 수 있습니다.

위험은 긍정적일 수도 있고 부정적일 수도 있습니다.

• 긍정적인 위험 이는 기회로 간주되며 사업 지속가능성에 도움이 됩니다. 예를 들어 신규 프로젝트 투자, 사업 프로세스 변경, 개발 등이 있습니다.ping 새로운 제품.
• 부정적 위험 이러한 요소들은 위협으로 간주되며, 프로젝트 성공을 위해서는 이러한 위협을 최소화하거나 제거하기 위한 권장 사항을 실행해야 합니다.

이 기법은 새로운 테스트 레벨을 추가하는 대신 노력을 할당하는 방식이기 때문에 기존 테스트 위에 적용됩니다. 소프트웨어 테스트 유형 그 어떤 것도 교체하는 대신에.

위험 기반 테스트를 언제 구현해야 할까요?

위험 기반 테스트는 다음과 같은 경우에 구현될 수 있습니다.

• 시간, 자원 또는 예산 제약이 있는 프로젝트.
• 위험 기반 분석을 사용하여 취약점을 탐지할 수 있는 프로젝트 SQL 주입 공격.
• 클라우드 컴퓨팅 환경에서의 보안 테스트.
• 기술 활용 경험 부족이나 사업 영역 지식 부족 등 위험 요소가 높은 신규 프로젝트.
• 점진적 및 반복적 제공 모델.

리스크 관리 프로세스

이제 위험 관리 프로세스에 포함되는 단계를 살펴보겠습니다.

위험 식별

위험 식별은 위험 워크숍, 체크리스트, 브레인스토밍, 인터뷰, 델파이 기법, 원인 및 결과 다이어그램, 이전 프로젝트에서 얻은 교훈, 근본 원인 분석, 그리고 해당 분야 전문가 및 주제 전문가와의 접촉을 통해 수행할 수 있습니다.

리스크 등록부는 식별된 리스크, 잠재적 대응 방안 및 근본 원인 목록을 담고 있는 스프레드시트입니다. 이는 리스크를 모니터링하고 관리하는 데 사용됩니다. trac프로젝트 수명 주기 전반에 걸쳐 발생하는 위험(위협과 기회 모두)을 파악해야 합니다. 위험 대응 전략은 긍정적 위험과 부정적 위험을 관리하는 데 사용할 수 있습니다.

위험 분해 구조(Risk Breakdown Structure, RBS)는 위험 계획 수립에 중요한 역할을 합니다. 위험 발생 가능성이 높은 영역을 파악하고 프로젝트 진행 과정에서 효과적인 평가 및 모니터링을 지원합니다. 또한 위험 관리 활동에 충분한 시간과 자원을 할당하고 프로젝트 위험이 발생할 수 있는 다양한 원인을 분류하는 데 도움이 됩니다.

아래 예시는 위험 분류 구조가 프로젝트의 위험을 범주별로 분류하여 어떤 위험 요소도 간과하지 않도록 하는 방법을 보여줍니다.

위험 분석(정량적, 정성적 분석 포함)

잠재적 위험 목록을 파악한 후에는 이를 분석하고 중요도에 따라 위험을 선별하는 단계를 거쳐야 합니다. 정성적 위험 분석 기법 중 하나로 위험 매트릭스(뒷부분에서 자세히 다룸)가 있습니다. 이 기법은 위험의 발생 확률과 영향력을 파악하는 데 사용됩니다.

위험 대응 계획

분석 결과를 바탕으로 위험 요소에 대한 대응 여부를 결정할 수 있습니다. 예를 들어, 일부 위험 요소는 프로젝트 계획 단계에서 대응이 필요하고, 일부는 프로젝트 모니터링 단계에서 대응이 필요하며, 또 다른 일부는 전혀 대응이 필요하지 않을 수 있습니다.

위험 소유자는 할당된 위험의 가능성과 영향을 줄이기 위한 옵션을 식별할 책임이 있습니다.

위험 완화는 발생 가능한 위협의 부정적인 영향을 줄이기 위해 사용되는 위험 대응 방법입니다. 이는 위험을 제거하거나 허용 가능한 수준으로 줄임으로써 이루어질 수 있습니다. 아래 그림은 위험 대응 계획을 더 넓은 위험 관리 주기 내에 배치한 것입니다.

비상 위험

비상 계획이란 그 영향이 알려지지 않았거나 예측 불가능한 불확실한 사건의 가능성을 의미합니다. 비상 계획은 최악의 시나리오에 대비한 실행 계획 또는 예비 계획이라고도 합니다. 다시 말해, 예측 불가능한 사건이 발생했을 때 취할 수 있는 조치를 미리 정해두는 것입니다.

위험 모니터링 및 제어

위험 관리 및 모니터링 프로세스는 다음과 같은 용도로 사용됩니다. trac식별된 위험을 평가하고, 잔존 위험을 모니터링하고, 새로운 위험을 식별하고, 위험 등록부를 업데이트하고, 변경 사항의 원인을 분석하고, 위험 대응 계획을 실행하고, 위험 발생 요인을 모니터링합니다. 그런 다음 위험 감소에 대한 이러한 조치들의 효과를 평가합니다.

이는 위험 재평가, 위험 감사, 차이 및 추세 분석, 기술 성과 측정, 상태 업데이트 회의 및 회고 회의를 통해 달성할 수 있습니다.

아래 표는 위험 모니터링 및 통제의 투입 요소, 도구 및 산출 요소에 대한 정보를 제공합니다.

우리는 기술의 변화, 프로젝트 규모, 프로젝트 기간(프로젝트 기간이 길어질수록), 후원 기관의 수, 프로젝트 예상 비용, 투입되는 노력, 그리고 적절한 기술 인력 부족 등이 위험 증가로 이어진다는 점을 명심해야 합니다.

위험 기반 테스트 접근법

위의 관리 프로세스는 아래의 테스트 접근 방식에 입력값을 제공합니다. 각 단계는 다음 단계에서 사용할 입력값을 생성합니다.

1. 요구 사항을 분석합니다.
   • 문서(SRS, FRS, 사용 사례)를 검토합니다. 이 활동은 오류와 모호한 부분을 찾아 제거하기 위해 수행됩니다.
   • 요구사항 승인은 프로젝트 후반에 변경 사항이 발생하는 것을 방지하기 위한 위험 감소 기법 중 하나입니다. 문서가 기준선으로 확정된 후 요구사항에 변경 사항이 발생하면 변경 관리 프로세스와 그에 따른 승인이 필요합니다.
2. 위험 평가 비용, 일정, 자원, 범위, 기술적 성능, 안전, 신뢰성 및 복잡성과 같은 정의된 기준을 고려하여 각 요구사항이 프로젝트에 미칠 수 있는 가능성과 영향을 계산합니다.
   • 실패 확률과 고위험 영역을 파악하십시오. 이는 위험 평가 매트릭스를 사용하여 수행할 수 있습니다.
   • 위험 등록부를 사용하여 식별된 위험 요소들을 나열하십시오. 등록부를 업데이트하고 모니터링하십시오. track는 정기적으로 위험 요소를 평가합니다.
   • 위험 수용력과 위험 허용 수준을 이해하려면 이 단계에서 위험 프로파일링을 수행해야 합니다.
3. 등급에 따라 요구 사항의 우선 순위를 지정합니다.
   • 위험 기반 테스트 프로세스가 정의됩니다.
   • 매우 심각한 위험과 중간 수준의 위험은 완화 계획 수립, 실행 및 진행 상황 모니터링 대상으로 고려할 수 있습니다. 낮은 수준의 위험은 주시 목록에 유지할 수 있습니다.
   • 데이터의 품질을 분석하기 위해 위험 데이터 품질 평가가 수행됩니다.
4. 평가 기준에 따라 테스트를 계획하고 정의하십시오.
   • 적절한 테스트 접근 방식과 테스트 설계 기법을 적용하여 위험도가 가장 높은 항목부터 먼저 테스트하십시오. 위험도가 높은 항목은 해당 분야에 대한 풍부한 지식과 경험을 갖춘 담당자가 테스트할 수 있습니다.
   • 다양한 테스트 설계 기법을 사용할 수 있습니다. 예를 들어, 결정 테이블 위험도가 높은 시험 항목에 대한 기법, 그리고 오직 등가 분할 위험도가 낮은 검사 항목의 경우.
   • 테스트 케이스 또한 다양한 기능과 엔드 투 엔드 비즈니스 시나리오를 포괄하도록 설계되었습니다.
   • 테스트 데이터, 테스트 조건 및 테스트 환경을 준비합니다.
5. Rev테스트 문서를 참조하십시오. — 테스트 계획, 테스트 전략, 테스트 케이스, 테스트 보고서 및 테스트 팀이 작성한 기타 모든 문서.
   • 동료 검토는 결함 식별 및 위험 감소에 있어 중요한 단계입니다.
6. 예행연습을 실시하고 결과에 대한 품질 검사를 수행하십시오.
   • 위험 항목의 우선순위에 따라 테스트 케이스가 실행됩니다.
   • 유지하다 trac위험 요소 간의 호환성, 해당 요소를 다루는 테스트, 테스트 결과, 그리고 테스트 중에 발견된 결함. 모든 테스트 전략은 제대로 실행될 경우 품질 위험을 줄일 수 있습니다.
   • 위험 기반 테스트는 모든 테스트 단계에서 사용할 수 있습니다. 구성 요소, 완성, 체계 그리고 인수 테스트.
   • 시스템 수준에서는 애플리케이션에서 가장 중요한 요소에 집중해야 합니다. 이는 기능의 가시성, 사용 빈도, 그리고 오류 발생 시 예상되는 비용을 고려하여 판단할 수 있습니다.
   • 출구 기준 평가: 모든 고위험 영역에 대한 철저한 검사가 완료되었으며, 경미한 잔여 위험만 남아 있습니다.
7. 위험도 기반 검사 결과를 보고하십시오. 그리고 지표를 분석합니다.
   • 핵심 위험 지표를 기반으로 기존 위험 이벤트와 새로운 위험 이벤트를 재평가합니다.
   • 위험 등록부를 업데이트하세요.
   • 비상 계획은 위험 노출이 높은 상황에 대비한 예비 계획 또는 비상 계획 역할을 합니다.
   • 결함 분석 및 결함 예방은 결함을 제거하기 위해 사용됩니다.
   • 재검사 및 Regression Testing 사전에 계산된 위험 분석을 기반으로 결함 수정 사항을 검증하고, 위험도가 높은 영역에 대해 가장 집중적으로 검증해야 합니다.
   • 가능하다면 위험 기반 자동화 테스트를 실시합니다.
   • 잔여 위험 계산.
8. 위험을 감시하고 관리하십시오.
   • 종료 기준 또는 완료 기준은 위험 수준별로 별도로 정의할 수 있습니다. 모든 주요 위험은 적절한 조치 또는 비상 계획을 통해 해결되었으며, 위험 노출 수준은 프로젝트에 허용 가능한 수준으로 합의된 기준 이하입니다.
   • 위험 프로파일링 재평가 및 고객 피드백.

시스템 테스트에 대한 위험 기반 테스트 접근 방식

1. 기술 시스템 테스트 — 이는 환경 테스트 및 통합 테스트라고 합니다. 환경 테스트에는 개발 환경, 테스트 환경 및 운영 환경에서의 테스트가 포함됩니다.
2. 기능 시스템 테스트 — 모든 기능, 특징, 프로그램 및 모듈에 대한 테스트. 이 테스트의 목적은 시스템이 명시된 요구 사항을 충족하는지 평가하는 것입니다.
3. 비기능적 시스템 테스트 — 비기능 요구사항 테스트: 성능, 부하 테스트, 스트레스 테스트구성 테스트, 보안 테스트, 백업 및 회복 절차 및 문서(시스템, 운영 및 설치 문서).

아래 그림은 위에서 언급한 과정을 명확하게 보여줍니다.

시스템 테스트에는 기능 테스트와 비기능 테스트가 모두 포함됩니다.

기능 테스트 제품이나 애플리케이션이 고객 및 비즈니스 요구 사항을 충족하는지 확인합니다. 반면에, 비기능 테스트 이는 제품이 품질, 신뢰성, 사용성, 성능 및 호환성 측면에서 고객의 기대에 부응하는지 확인하기 위해 수행됩니다.

위험 기반 테스트 수행 방법: 전체 프로세스

이 섹션에서는 5단계로 진행되는 위험 기반 테스트 프로세스를 다룹니다.

1. 위험 식별
2. 위험 분석
3. 리스크 대응
4. 테스트 점수ping
5. 테스트 프로세스 정의

아래 그림과 같이 다섯 단계는 서로 연계됩니다.

1. 이 과정에서 위험을 식별하고 분류하며, 위험 등록부 초안을 작성하고, 중요 위험을 식별하기 위해 위험 분류 작업을 수행합니다.
2. 위험 대응은 위험으로부터 시험 목표를 수립하고, 시험 활동 또는 시험 기법이 해당 시험 목표를 충족하도록 적절한 기법을 선택하는 것을 포함합니다.
3. 소프트웨어 테스트의 효율성 점수를 계산할 때는 문서화된 의존성, 요구 사항, 비용 및 소요 시간을 고려합니다.
4. 테스트 점수ping 이 검토 활동은 모든 이해관계자와 기술 담당자의 참여를 필요로 합니다. 합의된 위험 범위를 준수하는 것이 중요합니다. 이러한 위험은 테스트를 통해 해결해야 하며, 모든 구성원은 자신에게 할당된 책임과 이러한 활동에 배정된 예산에 동의해야 합니다.
5. 테스트 범위가 확정되면 각 테스트 단계에 대한 테스트 목표, 가정 및 종속성을 표준 형식으로 정리해야 합니다.

아래 예시에서는 각 요구사항을 관련 위험 및 해당 위험을 해결하는 테스트 목표와 연결합니다.

기능적 요구사항 F1, F2, F3과 비기능적 요구사항 N1, N2를 고려해 보겠습니다.

F1 — 기능 요구사항, R1 — F1과 관련된 위험

• 테스트 목표 1 — 테스트를 통해 시스템의 예상되는 기능과 작동 방식이 올바르게 작동함을 입증하고, 기능 테스트를 통해 위험 요소 R1을 해결할 수 있음을 보여줍니다.
• 테스트 — 브라우저 페이지 테스트는 중요한 사용자 작업을 실행하고 다양한 시나리오에서 R1(F1과 관련된 위험)을 해결할 수 있는지 확인하기 위해 수행됩니다.

F2 — 기능 요구사항, R2 — F2과 관련된 위험

• 테스트 목표 2 — 테스트를 통해 시스템의 예상되는 기능과 작동 방식이 올바르게 작동함을 입증하고, 기능 테스트를 통해 위험 요소 R2을 해결할 수 있음을 보여줍니다.
• 테스트 — 브라우저 페이지 테스트는 중요한 사용자 작업을 실행하고 다양한 시나리오에서 R2 문제가 해결될 수 있는지 확인하기 위해 수행됩니다.

F3 — 기능 요구사항, R3 — F3과 관련된 위험

• 테스트 목표 3 — 테스트를 통해 시스템의 예상되는 기능과 작동 방식이 올바르게 작동함을 입증하고, 기능 테스트를 통해 위험 요소 R3을 해결할 수 있음을 보여줍니다.
• 테스트 — 브라우저 페이지 테스트는 중요한 사용자 작업을 실행하고 다양한 시나리오에서 R3 문제가 해결될 수 있는지 확인하기 위해 수행됩니다.

N1 — 비기능적 요구사항, NR1 — N1과 관련된 위험

• 테스트 목표 N1 — 테스트를 통해 시스템의 작동 특성이 올바르게 작동하고, 비기능 테스트를 통해 위험 NR1를 해결할 수 있음을 입증합니다.
• 테스트 — 사용성 테스트는 사용자 인터페이스가 얼마나 사용하기 쉬운지 평가하고, 사용성 테스트를 통해 NR1 문제를 해결할 수 있는지 확인하는 데 사용되는 기법입니다.

N2 — 비기능적 요구사항, NR2 — N2과 관련된 위험

• 테스트 목표 N2 — 테스트를 통해 시스템의 작동 특성이 올바르게 작동하고, 비기능 테스트를 통해 위험 NR2를 해결할 수 있음을 입증합니다.
• 시험 - 보안 테스트 이는 애플리케이션이 안전한지 또는 공격에 취약한지, 정보 유출이 있는지 여부를 확인하고 NR2 문제가 보안 ​​테스트를 통해 해결될 수 있는지 검증하는 데 사용되는 기술입니다.

구체적인 시험 목표: 아래 요약된 바와 같이, 나열된 위험 요소 및 테스트 목표는 테스트 유형별로 다릅니다.

위험 기반 테스트 프로세스 설계 절차

• 위험 등록부를 작성하십시오. 이 등록부에는 일반적인 위험 목록, 기존 체크리스트 및 브레인스토밍을 통해 도출된 위험 요소가 기록됩니다.
• 시스템의 기능적 요구사항과 비기능적 요구사항(사용성, 보안, 성능)과 관련된 위험을 포함하십시오.
• 각 위험에는 고유 식별자가 할당됩니다.

해당 등록부의 1열과 2열에는 식별자와 위험 설명이 기록되어 있습니다. 나머지 열에 대한 설명은 아래와 같습니다.

두 등록 변수가 각 위험의 발생 확률(1 낮음, 5 높음)과 결과(1 낮음, 5 높음)를 평가합니다.trac아래를 참조하세요.

• 테스트 노출량이 계산됩니다.
• 테스터는 각 위험 요소를 분석하고 해당 위험 요소가 테스트 가능한지 여부를 평가합니다.
• 테스트 목표는 테스트 가능한 위험에 대해 정의됩니다.
• 테스터는 테스트 목표를 달성하기 위해 계획된 방식으로 수행해야 하는 테스트 활동(정적 검토, 검사, 시스템 테스트, 통합 테스트, 인수 테스트, HTML 유효성 검사, 현지화 테스트 등)을 명시합니다.
• 이러한 테스트 활동은 단계별로 분류할 수 있습니다(구성 요소 테스트 또는 단위 테스트(통합 테스트, 시스템 테스트, 인수 테스트).
• 경우에 따라 하나의 위험에 대해 하나 이상의 테스트 단계를 거쳐야 할 수도 있습니다.
• 의존성 및 가정 사항(기술, 도구, 테스트 환경 및 리소스의 가용성)을 파악합니다.
• 테스트 효과성이 계산됩니다. 테스트 효과성은 테스트를 통해 위험이 확실히 해결될 것이라는 테스트 담당자의 확신 수준과 관련이 있습니다. 테스트 효과성 점수는 1에서 5 사이의 숫자입니다(5 = 높은 확신, 1 = 낮은 확신).
• 이러한 테스트를 준비하고 실행하는 데 필요한 노력, 시간 및 비용을 추산하십시오.

다음 두 전tracts는 나머지 등록 열과 테스트 효과 점수를 표시합니다.

• 시험 우선순위 번호는 확률, 결과 및 시험 효과성 점수의 곱으로 계산됩니다.
• 125(최대) - 검사를 통해 감지할 수 있는 매우 심각한 위험입니다.
• 1(최소) — 검사로 감지되지 않을 정도로 매우 낮은 위험.
• 테스트 우선순위 번호를 기준으로 테스트 중요도는 높음(빨간색), 중간(노란색), 낮음(녹색)으로 분류할 수 있습니다. 위험도가 가장 높은 항목부터 먼저 테스트합니다.
• 테스트 활동을 테스트 단계에 할당합니다. 각 테스트 단계(단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트)에서 각 목표에 대한 테스트를 수행할 그룹을 지정합니다.

테스트 단계별 할당 내역은 아래와 같습니다.

테스트 범위에 포함되는 항목과 포함되지 않는 항목은 테스트 계획서에서 결정됩니다.ping 단계.

• 각 단계별로 테스트 목표, 테스트 대상 구성 요소, 책임자, 환경, 진입 기준, 종료 기준, 도구, 기술 및 결과물이 정의됩니다.

일반적인 시험 목표 — 이러한 일반적인 목표는 여러 프로젝트 및 애플리케이션에 적용될 수 있습니다.

• 해당 구성 요소는 요구 사항을 충족하며 더 큰 하위 시스템에서 사용할 준비가 되었습니다.
• 특정 테스트 유형과 관련된 위험이 해결되고 테스트 목표가 달성됩니다.
• 통합 구성 요소는 정확하게 조립되었으며 구성 요소 간의 인터페이스 호환성이 보장됩니다.
• 이 시스템은 명시된 기능적 및 비기능적 요구사항을 충족합니다.
• 제품 구성 요소는 의도된 작동 환경에서 최종 사용자의 요구 사항을 충족합니다.
• 위험 관리 전략은 위험을 식별, 분석 및 완화하는 데 사용됩니다.
• 이 시스템은 업계 규제 요건을 충족합니다.
• 이 시스템은 조건을 충족합니다.trac법적 의무.
• 제도화 및 비용, 일정, 품질 목표와 같은 기타 구체적인 목표 달성.
• 시스템, 프로세스 및 인력이 비즈니스 요구 사항을 충족합니다.

다양한 테스트 단계에 대한 일반적인 테스트 목표를 정의할 수 있습니다.

• 구성 요소 테스트
• 통합 테스팅
• 시스템 테스트
• 수락 테스트

시스템 테스트 단계를 살펴보겠습니다.

1. G4와 G5는 시스템이 기능적 요구사항(F1, F2, F3)과 비기능적 요구사항(N1, N2)을 충족함을 보여줍니다.
2. 테스트를 통해 시스템의 예상되는 기능과 작동 방식이 올바르게 작동하는지, 그리고 F1, F2, F3과 관련된 위험 요소들을 기능 테스트를 통해 해결할 수 있음을 입증하십시오.
3. 시스템의 작동 특성이 올바르게 작동함을 테스트를 통해 입증하고, N1 및 N2와 관련된 위험을 비기능 테스트를 통해 해결할 수 있음을 보여주십시오.
4. 테스트 우선순위 번호를 기준으로 테스트 중요도는 높음(빨간색), 중간(노란색), 낮음(녹색)으로 분류할 수 있습니다.

우선순위 지정 및 위험 평가 매트릭스

위험 평가 매트릭스는 발생 확률-영향 매트릭스입니다. 이 매트릭스는 프로젝트 팀에게 위험 요소를 빠르게 파악하고 각 위험 요소에 대해 어떤 우선순위로 대응해야 하는지 알려줍니다.

Risk rating = Probability x Severity

확률은 시간, 근접성 및 반복성 측면에서의 노출을 기반으로 불확실한 사건이 발생할 가능성을 측정하는 척도입니다. 확률은 백분율로 표시됩니다.

이는 빈번함(A), 가능성 높음(B), 가끔 발생함(C), 드물게 발생함(D), 가능성이 낮음(E), 완전히 배제됨(F)으로 분류할 수 있습니다.

• 빈번한 — 대부분의 상황에서 여러 번 발생할 것으로 예상됩니다(91~100%).
• 유망한 후보자 — 대부분의 상황에서 여러 번 발생할 가능성이 높습니다(61~90%).
• 수시 — 언젠가 발생할 수 있습니다 (41~60%).
• 원격수행 — 발생 가능성은 낮지만, 언젠가는 발생할 수도 있습니다(11~40%).
• 희한 — 드물고 예외적인 상황에서 발생할 수 있습니다(0~10%).
• 탈락 — 발생 불가능(0%).

심각도는 불확실한 사건으로 인해 발생하는 피해 또는 손실의 정도를 나타냅니다. 1에서 4까지 점수로 평가되며, 재앙적(1), 심각(2), 경미(3), 무시할 만함(4)으로 분류됩니다.

• 치명적인 — 심각한 결과를 초래하여 프로젝트가 완전히 비효율적이 되거나 심지어 중단될 수도 있습니다. 이는 위험 관리 시 최우선 순위로 고려해야 합니다.
• 결정적인 — 막대한 손실로 이어질 수 있는 심각한 결과를 초래할 수 있습니다. 프로젝트가 심각한 위협에 처해 있습니다.
• 가장자리 가의 — 복구 활동을 통해 되돌릴 수 있는 단기적인 손상.
• 무시할 만하다. — 피해나 손실이 경미하거나 최소한입니다. 이는 일상적인 절차를 통해 모니터링 및 관리할 수 있습니다.

우선순위는 네 가지 범주로 분류되며, 아래 이미지에서 보는 바와 같이 위험의 심각도 및 발생 가능성에 따라 등급이 나뉩니다.

• 진지한
• 높음
• 중급
• 높음

심각한: 이 범주에 속하는 위험은 황색으로 표시됩니다. 해당 활동은 즉시 중단하고 위험을 격리하기 위한 조치를 즉시 취해야 합니다. 효과적인 통제 방안을 파악하고 실행해야 합니다. 또한, 위험이 낮음 또는 중간 수준으로 감소될 때까지 해당 활동을 진행해서는 안 됩니다.

높음 : 이 범주에 속하는 위험은 빨간색으로 표시되며 즉각적인 조치 또는 위험 관리 전략이 필요합니다. 위험을 격리, 제거 또는 대체하고 효과적인 위험 통제를 시행하기 위해 즉각적인 조치가 취해져야 합니다. 이러한 문제를 즉시 해결할 수 없는 경우, 해결을 위한 엄격한 기한을 설정해야 합니다.

매체 : 이 범주에 속하는 위험은 노란색으로 표시되어 있습니다. 위험을 최소화하기 위해 합리적이고 실질적인 조치를 취해야 합니다.

낮은: 이 범주에 속하는 위험은 녹색으로 표시되며, 심각한 문제를 야기하지 않으므로 일반적으로 허용 가능한 수준입니다. 하지만 통제 조치가 효과적인지 확인하기 위해 정기적인 검토는 필수적입니다.

위험 기반 테스트를 위한 일반 체크리스트

매트릭스는 위험도를 평가하는 방법을 결정합니다. 아래 체크리스트는 어떤 후보들이 매트릭스에 포함될지 결정하는 기준이 됩니다.

• 프로젝트의 중요한 기능.
• 프로젝트에서 사용자가 볼 수 있는 기능입니다.
• 안전에 가장 큰 영향을 미치는 기능.
• 사용자에게 가장 큰 재정적 영향을 미치는 기능.
• 매우 복잡한 소스 코드 영역과 오류 발생 가능성이 높은 코드.
• 개발 주기 초기에 테스트할 수 있는 기능입니다.
• 제품 설계에 마지막 순간에 추가된 기능 또는 특징들.
• 유사하거나 관련된 이전 프로젝트에서 문제를 야기했던 주요 요인.
• 운영 및 유지 관리 비용에 큰 영향을 미친 유사하거나 관련된 프로젝트의 주요 요인 또는 문제점.
• 부실한 요구사항은 부실한 설계와 테스트로 이어져 프로젝트 목표와 결과물에 악영향을 미칠 수 있습니다.
• 최악의 경우, 제품의 결함이 너무 심각하여 재작업이 불가능하고 완전히 폐기해야 할 수도 있는데, 이는 회사의 명성에 심각한 손상을 초래할 수 있습니다. 제품 목표 달성에 중요한 문제가 무엇인지 파악하십시오.
• 지속적인 고객 서비스 불만을 야기할 수 있는 상황이나 문제.
• 시스템의 여러 기능을 쉽게 집중적으로 테스트할 수 있는 엔드 투 엔드 테스트.
• 위험 범위를 극대화할 수 있는 최적의 검사 세트.
• 어떤 검사가 시간 대비 고위험군 진단율이 가장 좋을까요?

위험 기반 테스트 결과 보고 및 지표

1. 시험 보고서 작성. 테스트 상태 보고는 프로젝트 이해관계자에게 테스트 결과를 효과적으로 전달하고, 명확한 이해를 제공하며, 테스트 결과와 테스트 목표의 비교를 보여주는 것입니다.
   • 계획된 테스트 케이스 수와 실제로 실행된 테스트 케이스 수의 차이.
   • 테스트 케이스 통과 또는 실패 횟수.
   • 발견된 결함의 수, 그리고 결함의 상태와 심각도.
   • 아직 해결되지 않은 심각한 결함의 수.
   • 환경 다운타임(있을 경우).
   • 혹시라도 흠잡을 만한 부분이 있다면 알려주세요.
   • 시험 요약 보고서 및 테스트 범위 보고합니다.
2. 지표 준비. 메트릭은 소프트웨어 프로세스, 프로젝트 및 제품을 비교하는 데 사용되는 두 개 이상의 측정값의 조합입니다.
   • 노력 및 일정 변동.
   • 테스트 케이스 준비 생산성.
   • 테스트 설계 범위.
   • 테스트 케이스 실행 생산성.
   • 위험 식별 효율성(%).
   • 위험 완화 효율(%).
   • 테스트 효과율(%).
   • 테스트 실행 범위.
   • 테스트 실행 생산성.
   • 결함 누출률(%).
   • 결함 탐지 효율 및 결함 밀도.
   • 요구사항 안정성 지수.
   • 품질 비용.

그런 다음 이러한 조치들을 위험도와 비교하여 다시 검토합니다.

• 결함 상태 및 테스트 통과 또는 실패 결과 수를 기준으로 비기능적 범주(성능, 신뢰성 및 사용성)의 위험을 분석하고, 이러한 위험과의 관계를 파악합니다.
• 기능 범주별 위험을 분석할 때, 테스트 지표, 결함 상태, 테스트 통과 또는 실패 여부 등을 위험 요소와 연관시켜 고려합니다.
• 주요 선행 및 후행 지표를 파악하고 조기 경보 지표를 구축하십시오.
• 데이터 패턴, 추세 및 상호 의존성을 분석하여 선행 및 후행 위험 지표(핵심 위험 지표)를 모니터링하고 보고합니다.

고유 위험과 잔여 위험 평가

위험 식별 및 분석에는 내재적 위험, 잔여 위험, 이차적 위험 및 재발성 위험도 포함되어야 합니다.

• 내재된 위험: 통제 및 대응 조치가 시행되기 전에 시스템에 이미 존재했거나 파악된 위험 요소입니다. 내재적 위험은 중대한 위험이라고도 합니다.
• 잔류 위험: 통제 및 대응 조치가 시행된 후에도 남아 있는 위험을 잔여 위험이라고 합니다. 잔여 위험은 순 위험이라고도 합니다.
• XNUMX차 위험: 위험 대응 계획 시행으로 인해 발생한 새로운 위험.
• 재발 위험: 초기 위험 요인이 다시 발생할 가능성.

위험도에 기반한 테스트 결과 측정은 조직이 테스트 실행 중 남아 있는 품질 위험 수준을 파악하고 정보에 입각한 출시 결정을 내리는 데 도움이 됩니다.

위험 프로파일링 및 고객 피드백

리스크 프로파일링은 고객이 필요로 하는 위험 수준, 위험 감수 능력 및 위험 허용도를 고려하여 고객에게 가장 적합한 투자 위험 수준을 찾는 과정입니다.

1. 위험 부담 필요 이는 고객이 만족스러운 수익을 얻기 위해 감수해야 하는 위험 수준입니다.
2. 위험 수용 능력 이는 고객이 감당할 수 있는 재정적 위험 수준입니다.
3. 위험 감수 이는 고객이 감수하고자 하는 위험 수준입니다.

고객 피드백 : 고객 피드백과 리뷰를 수집하여 비즈니스, 제품, 서비스 및 경험을 개선합니다.

위험 기반 테스트의 이점

위험 기반 테스트의 이점은 다음과 같습니다.

• 생산성 향상 및 비용 절감.
• 시장 기회 확대(제품 출시 기간 단축) 및 정시 납품.
• 서비스 성능이 향상되었습니다.
• 애플리케이션의 모든 핵심 기능이 테스트되므로 품질이 향상되었습니다.
• 테스트 범위에 대한 명확한 정보. 이 접근 방식을 통해 팀은 무엇이 테스트되었고 무엇이 테스트되지 않았는지 알 수 있습니다.
• 위험 평가를 기반으로 한 테스트 노력 할당은 릴리스 시 잔여 위험을 최소화하는 가장 효율적이고 효과적인 방법입니다.
• 위험 분석에 기반한 테스트 결과 측정은 조직이 테스트 실행 중 남아 있는 품질 위험 수준을 파악하고 정보에 입각한 출시 결정을 내릴 수 있도록 해줍니다.
• 위험 평가 방법을 명확하게 정의하여 최적화된 테스트를 수행합니다.
• 고객 참여와 효과적인 보고 및 진행 상황 점검을 통해 고객 만족도가 향상되었습니다. trac왕.
• 잠재적인 문제 영역을 조기에 발견하여 효과적인 예방 조치를 취할 수 있습니다.
• 프로젝트 전체 수명 주기 동안 지속적인 위험 모니터링 및 평가는 위험을 식별하고 해결하며, 프로젝트의 전반적인 목표 달성을 위협할 수 있는 문제를 해결하는 데 도움이 됩니다.

자주 묻는 질문