소프트웨어 테스팅의 영향 분석
찰스 무어
⚡ 스마트 요약
소프트웨어 테스트에서의 영향 분석은 제안된 변경 사항이 요구사항, 설계, 코드, 테스트 및 제공 일정에 어떤 영향을 미치는지 평가합니다.ping 팀은 작업량을 예측하고, 회귀 테스트 범위를 우선시하며, 출시 전에 의도치 않은 결함을 방지합니다.
영향 분석이란 무엇입니까?
영향 분석은 배포된 제품이나 애플리케이션에 대한 변경 사항이 미치는 영향을 분석하는 과정입니다. 특정 애플리케이션 부분 또는 기능이 변경될 때 영향을 받을 수 있는 시스템 영역을 식별합니다.
영향은 요구사항, 설계 및 전반적인 측면에서 평가됩니다. Archi구조, 테스트 및 납품 일정.
애플리케이션이나 제품에 새로운 기능이 추가될 때마다 해당 변경 사항이 시스템의 성능과 안정성에 어떤 영향을 미칠지 확인하는 것이 필수적입니다. 영향 분석은 바로 이러한 이유로 수행됩니다.
변화 영향 분석은 왜 하는가?
- 변경 사항을 구현했을 때 발생할 수 있는 결과를 이해하기 위해서입니다. 제품에 너무 많은 기능을 추가하면 전반적인 성능이 저하될 수 있습니다.
- 팀이 변경 사항을 구현하기로 결정할 경우 수정해야 할 수 있는 모든 파일, 문서 및 모델을 식별하기 위해서입니다.
- 변화를 구현하는 데 필요한 노력을 추산하기 위해.
- 변화를 구현하는 데 필요한 작업을 파악합니다.
- 변경되는 특정 요소에 대한 종속성을 나열합니다.
영향 분석 문서란 무엇인가요?
영향 분석 문서는 팀이 변경 요청에 대한 작업을 시작하기 전에 해당 변경 요청을 평가하는 체크리스트로 사용할 수 있습니다. 이 문서에는 다음과 같은 세부 정보가 포함되어야 합니다.
- 문제에 대한 간략한 설명입니다.
- 결함이 어떻게 실패 또는 비효율을 초래하는지에 대한 설명 또는 예시.
- 복잡성 추정치.
- 수리 비용 및 소요 시간 예상치입니다.
- 테스트할 기능.
- 변경 사항을 반영하여 새로운 테스트 케이스가 생성되었습니다.
- 기술 사양서 또는 관련 설계 노트와 같은 참조 문서.
예:
영향 분석 문서.
- 변경 요청 ID:
- 표제:
- 상품 설명
- 준비 날짜:
- 우선순위 추정치:
- 상대적 이익
- 상대 페널티
- 상대 비용
- 상대 위험
- 예상 총 소요 시간: ______시간
- 예상 손실 시간: ______시간
- 예상 일정 차질: ______일
- 품질에 영향을 준 요소:
- 영향을 받는 기타 요구 사항:
- 영향을 받는 다른 작업:
- 통합 문제:
영향 분석의 영향력 수준을 제시하는 방법
영향 분석은 시스템에 미치는 변화의 중요도를 나타내는 색상 코드로 표현할 수 있습니다. 일반적인 색상 코드는 아래와 같습니다.
- 빨간색 — 강한 영향
- 황색 — 중간 정도의 영향
- 녹색 — 영향이 미미함
위 표는 시행된 변경 사항의 영향을 설명합니다.
- 빨간색으로 표시된 특징은 가장 크게 변화하는 특징입니다. 노란색으로 표시된 특징은 변화의 영향을 덜 받는 특징입니다. 초록색으로 표시된 특징은 변화의 영향을 가장 적게 받는 특징입니다.
- 세로로 나열된 기능은 변경되는 기능이고, 가로로 나열된 기능은 변경 사항의 영향을 받을 수 있는 기능입니다. 위 예시에서 기능 1의 변경은 기능 3에 영향을 미칩니다.
- 기능과 특징이 많은 대규모 프로젝트에서는 위 표가 실용적이지 않을 수 있습니다. 이러한 경우, 개발자가 주요 기능 변경으로 인한 영향 수준을 아래 그림과 같이 직접 표시하는 방식을 사용합니다. 이 그림에서는 주요 기능의 영향이 각 하위 기능에 미치는 영향을 표시합니다.
영향 분석을 수행할 때 고려해야 할 질문 예시:
- 제안된 변경으로 인해 발생하는 부작용이나 위험은 무엇입니까?
- 변경 사항을 구현하고 테스트하기 위해 새로운 도구를 구입해야 합니까?
- 만약 그 변경안이 받아들여진다면, 이미 투자한 노력 중 얼마나 많은 부분이 헛수고가 될까요?
- 제안된 변경 사항이 성능 요구 사항에 부정적인 영향을 미칩니까?
- 제안된 변경 사항을 검증하기 위해 추가적인 사용자 입력이 필요합니까?
- 변경으로 인해 제품 비용이 증가합니까?
- 현 직원들은 제안된 변화를 실행할 지식과 기술을 갖추고 있습니까?
- 제안된 변경으로 인해 컴퓨터 리소스에 허용할 수 없는 요구가 발생합니까?
최고의 변경 영향 분석 사례
- 영향 분석을 시작하기 전에 테스트 요청서에 변경 사항의 영향을 받는 프로젝트의 모든 부분이 명확하게 정의되어 있는지 확인하십시오.
- 개발자와 테스터 간의 지속적인 소통은 최종 제품에 필요한 변경 사항을 놓치지 않기 위해 필수적입니다.
- 사용자 인터페이스 변경, 삭제 또는 추가가 필요한지 여부를 파악합니다.
- 필요한 인수 테스트, 시스템 테스트 및 통합 테스트 케이스의 수를 추정하십시오.
- 제안된 변경 사항이 프로젝트 계획, 구성 관리 계획 또는 품질 보증 계획에 미치는 영향을 파악하십시오.
소프트웨어 테스트에서의 영향 분석 유형
변화 영향 분석은 단일한 기법이 아닙니다. 실무자들은 일반적으로 제안된 변화에 대한 다양한 질문에 답하기 위해 상호 보완적인 세 가지 유형 중 하나를 사용합니다.
- Trac영향 분석: 사용 요구사항 Trac가능성 매트릭스와 설계 연계를 통해 모든 요구사항을 해당 요구사항을 구현하는 모듈, 테스트 및 문서에 매핑합니다. 요구사항이 변경될 경우, 매트릭스는 업데이트 또는 재테스트가 필요한 모든 하위 산출물을 보여줍니다.
- 의존성 영향 분석: 호출 그래프, 데이터 흐름 및 인터페이스 구성을 연구합니다.trac코드베이스 내부의 ts. 한 모듈의 변경 사항은 trac직접 발신자, 간접 발신자 및 공유 데이터 구조를 통해 전달되므로 숨겨진 파급 효과가 변화가 시작되기 전에 드러납니다.
- 실험적(역사적) 영향 분석: 과거 결함, 실패한 스프린트, 회귀 테스트 오류 등 과거 변경 데이터를 분석하여 현재 변경 사항이 어떻게 작동할지 예측합니다. 최신 도구는 버전 관리 기록 분석과 통계 또는 머신러닝 모델을 결합하여 각 변경 사항의 위험도를 평가합니다.
대부분의 팀은 이러한 유형 중 최소 두 가지를 결합합니다. Trac가능성 분석은 어떤 문서가 영향을 받는지 알려주고, 종속성 분석은 어떤 코드가 영향을 받는지 알려주며, 과거 분석은 변경 사항이 얼마나 위험할 가능성이 있는지 알려줍니다.
변화 영향 분석을 위한 인기 도구
현대의 변경 영향 분석은 스프레드시트로 수행되는 경우가 드뭅니다. 팀은 요구사항 관리 도구, 코드 분석 도구, 테스트 관리 도구를 함께 사용하며, 이 도구들은 공통된 기능을 공유합니다. trac척추의 안정성.
- 자마 커넥트, IBM 문, Modern Requirements및 시력 요건: 변경 사항이 제안될 때 연관된 요구 사항, 테스트 및 위험 전반에 걸쳐 요구 사항을 수집하고, 기준선을 유지하며, 영향 보고서를 생성합니다.
- Atlassian Jira와 함께 Xray 또는 제피르: Track개의 사용자 스토리, 결함 및 테스트 케이스. 영향 보고서는 제안된 변경 사항이 스프린트 또는 릴리스 트레인 내에서 영향을 미치는 모든 스토리와 테스트를 보여줍니다.
- SonarQubeSciTools의 Understand 및 Structure101을 참조하세요. 소스 코드 종속성을 분석하고 호출 그래프 및 결합도 보고서를 생성하여 엔지니어가 변경 사항으로 인해 하위 코드에 어떤 영향을 미치는지 확인할 수 있도록 합니다.
- 실행 가능, Testim 자동 치유 및 TestGrid: 머신러닝을 활용하여 변경 사항으로 인해 발생하는 결함을 잡아낼 가능성이 가장 높은 테스트를 예측함으로써, 효율적인 테스트 선택과 더 빠른 회귀 테스트 주기를 구현할 수 있습니다.
- Microsoft 엑셀 또는 Google 시트 : 소규모 프로젝트에서 초기 영향 분석 문서, 색상으로 구분된 영향표, 변경 요청 기록 등에 여전히 널리 사용되고 있습니다.
최적의 조합은 코드베이스의 규모, 규제 환경 및 배포 방식에 따라 달라집니다. 규제를 받는 산업에서는 감사 가능한 코드 관리를 위해 Jama 또는 DOORS를 주로 사용합니다. trac민첩한 제품 개발팀이 Jira에 의존하는 동안, SonarQube그리고 테스트 영향 분석 도구입니다.
