what is impact analysis software testing
이 자습서에서는 영향 분석의 정의, 장점, 수행 방법 및 영향 분석 문서 준비 방법을 설명합니다.
아시다시피 기술은 사회에 긍정적 인 영향과 부정적인 영향을 모두 미칩니다. 모든 간단한 변경은 해당 시스템에 영향을 줄 수 있습니다. 아주 작은 변화라도 시스템에 큰 영향을 미칠 수 있습니다.
이 자습서에서는 영향 분석을 자세히 이해하고 영향 분석 문서를 준비하는 몇 가지 단계도 살펴 봅니다.
ER (엔티티 관계) 다이어그램의 도움으로이 분석의 중요성을 이해하겠습니다.
학습 내용 :
고급 프로그래밍 언어 목록
영향 분석의 중요성
Department Shop Management System의 ER 다이어그램을 고려하십시오. 'Item'모듈의 이름을 'Product'모듈로 변경하여이 데이터 모델 다이어그램을 편집하려고합니다. 그림 : No. 01에서 'Item'모듈이 다른 많은 모듈과 관련되어 있음을 알 수 있습니다. 따라서 'Item'모듈의 이름을 변경하면 불가피하게 다른 모듈에 영향을 미칩니다.
그림 : No. 01 : 백화점 관리 시스템
따라서 이러한 변경을 수행하기 전에 데이터 모델과 변경의 영향에 대해 잘 분석해야합니다. 관심있는 사람들이 모듈에서 커밋 할 변경의 결과에 대해 신중하게 생각하지 않는 경우 애플리케이션 자체의 올바른 작동에 영향을 미칠 수 있습니다. 이것이 영향 분석이 매우 중요한 이유입니다.
참고 :이 분석은 예상치 못한 동작과 애플리케이션의 모든 부작용을 보여줍니다.
영향 분석이란?
여기에는 애플리케이션의 기능 / 모듈에서 변경된 영향을 분석하는 것이 포함됩니다. 프로젝트 요구 사항, 시스템 디자인, 코딩, 테스트 등과 같은 소프트웨어 개발 라이프 사이클의 거의 모든 단계에서 수행 할 수 있습니다.
- 영향 분석 문서의 도움으로 모듈을 분석합니다. 모듈 / 제품의 모든 종류의 변경과 관련된 위험을 찾습니다.
- 시스템을 변경하는 데 필요한 팀 노력을 추정하는 데 도움이됩니다.
- 또한 개발자와 테스터가 시스템에서 효과를 경험할 수 있도록 프로토 타입을 구현하는 데 도움이됩니다.
효과적인 영향 분석을 수행하는 방법?
다음은 프로젝트 분석을 수행하는 단계입니다.
- 팀을 준비하십시오.
- 고급 모듈을 검사합니다.
- 하위 수준 모듈을 검사합니다.
- 영향을 평가합니다.
- 부정적인 결과를 관리합니다.
1 단계팀 준비
애플리케이션의 모듈을 변경하기 전에 팀이 있어야합니다. 팀 구성원은 응용 프로그램의 모든 모듈에 액세스 할 수 있어야하며 제안 된 변경 사항에 대한 철저한 지식이 있어야합니다.
일부 팀원은 모든 모듈을 인식하지 못합니다. 하지만 임팩트 분석을 실시한 후 모든 구성원은 시스템에 대한 철저한 지식을 갖게됩니다.
2 단계고급 모듈 검사
팀 구성원은 먼저 제안 된 변경 사항의 영향을받을 수있는 응용 프로그램의 상위 수준 모듈을 분석합니다. 이 시점에서 그들은 모듈의 전략 및 워크 플로 규칙에 대해 더 잘 알고 있어야합니다.
3 단계하위 수준 모듈 검사
상위 수준 모듈을 검사 한 후 팀 구성원은 하위 수준 모듈을 검사하고 변경 사항의 영향을 식별합니다. 팀 구성원은 각 모듈의 변경 영향을 나열하는 문서를 준비 할 수 있습니다. 엑셀 시트 나 워드 문서를 사용할 수 있습니다.
4 단계영향 평가
팀원이 작성한 문서에는 변경 사항의 긍정적 인 영향과 부정적인 영향의 목록이 모두 표시됩니다. 문서의 도움으로 팀 구성원은 변경으로 인해 발생할 수있는 이점과 변경으로 인해 직면하게 될 문제에 대한 명확한 아이디어를 갖게됩니다.
5 단계부정적인 결과 관리
지금은 팀원들이 변경 사항의 장단점에 대한 정확한 아이디어를 갖게 될 것입니다. 결과적으로 팀 구성원 및 이해 관계자와 논의한 후 변경 사항을 수락하거나 거부 할 수 있습니다.
테스터는 회귀 테스트를 수행 할 수 있습니다. 회귀 테스트는 모듈 변경의 영향으로 인해 발생한 모듈 간의 문제를 인식하는 데 도움이됩니다.
영향 분석 방법은 개발자에게 어떻게 유용합니까?
프로젝트에서 때로는 개발 프로세스를 시작한 후에도 클라이언트가 제시 한 요구 사항이 변경 될 수 있습니다. 개발자는 일부 코딩을 수행했을 수 있습니다. 나중에 요구 사항의 변경으로 인해 코드를 변경해야합니다. 따라서 개발자는 요구 사항에 따라 코드를 편집하고 변경 사항을 커밋합니다.
개발 프로세스에는 둘 이상의 개발자가 참여할 수 있습니다. 어떤 상황에서는 둘 이상의 개발자가 코드를 커밋하기 때문에 다른 모듈에서 변경 사항의 영향을 추적하기가 매우 어렵습니다.
개발자‘A’는 개발자‘B’가 처리하는 다른 모듈의 워크 플로를 인식하지 못할 수 있습니다. 따라서 개발자가 테스트를 수행하더라도 일부 모듈과 기능은 '테스트되지 않음'으로 유지됩니다. 개발자는 또한 공유 리소스를 잘 추적해야했습니다.
이러한 상황에서 우리는 모듈을 변경하기 전에 소프트웨어 영향 분석 회의를 수행 할 수 있습니다. 회의 후 팀 구성원은 영향 분석 문서를 준비합니다. 최신 변경 사항과 모든 위험 기반 정보를 반영해야합니다.
회의 후 개발자는 응용 프로그램의 모든 모듈을 알게됩니다. 이러한 회의에서는 각 팀원의 의견을 고려합니다.
개발자는 변경하기 전에 전체 애플리케이션 / 최종 제품을 고려합니다. 개발자가 수행 한 테스트가 더 좋습니다. 따라서 최종 개발 단계에서 오류가 발생할 위험이 줄어 듭니다.
참고 : 영향 분석 문서는 최신 상태로 유지해야합니다.
영향 분석 방법은 테스터에게 어떻게 유용합니까?
개발자와 테스터 간의 커뮤니케이션은 매우 중요합니다. 때때로 테스터는 요구 사항의 변경에 대한 알림을받지 못하고 변경에 대한 정보없이 테스트 프로세스를 계속합니다. 이것은 시간과 자원의 낭비입니다.
영향 분석 방법이 없으면 애플리케이션의 새로운 기능은 '테스트되지 않음'으로 유지됩니다. 테스터가 애플리케이션에 추가 된 새 기능에 대해 알고 있으면 회귀 테스트를 시작할 수 있습니다.
분석 후 테스터는 요구 사항의 변경 또는 시스템에 추가 된 새로운 기능에 따라 테스트 케이스를 생성하거나 수정하기 시작합니다.
노트 : 이 분석은 테스터가 테스트에 집중할 영역을 결정하는 데 도움이되고 테스트 케이스의 우선 순위를 지정할 수 있습니다. 따라서 테스트의 효율성이 향상 될 수 있습니다. .
영향 분석 문서를 준비하는 방법은 무엇입니까?
영향 회의의 모든 참가자는 영향 분석 문서 작성에 기여합니다. 일반적으로 엑셀 파일입니다. 워드 문서 일 수도 있습니다.
이 문서의 템플릿은 매트릭스와 같습니다. 이해하기 매우 쉽습니다. 가독성이 높습니다. 자세한 내용은 표 02를 참조하십시오.
영향 분석 문서를 준비하는 방법을 알아 보겠습니다. 프로젝트에는 많은 모듈, 기능 및 기능이 포함될 수 있습니다.
5 가지 기능이있는 작은 프로젝트를 고려하십시오.
mp3 플레이어 용 무료 mp3 음악 다운로드
- 로그인
- 프로필
- 사서함
- 즐겨 찾기에 추가
- 로그 아웃
아래 (표 02)는이 특정 프로젝트의 해당 영향 분석 표입니다.
여기서 열은 변경된 모듈 / 기능을 나타내고 매트릭스의 행은 변경의 영향을받은 모듈 / 기능을 나타냅니다. 개발자는 기능 'A'의 변경이 기능 'B'에 영향을 미칠 때 표에 표시 ()를 표시합니다. 이 문서가 테스터에게 제공되기 전에.
| 풍모 | 로그인 | 프로필 | 사서함 | 즐겨 찾기에 추가 | 로그 아웃 | ||||
|---|---|---|---|---|---|---|---|---|---|
| ............. | |||||||||
| 로그인 | | ||||||||
| 프로필 | | ||||||||
| 사서함 | | ||||||||
| 즐겨 찾기에 추가 | | ||||||||
| 로그 아웃 | |
표 02
강한 영향력을 보여주기 위해 RED 색상을 사용했습니다. 노란색은 적당한 영향을 나타 내기 위해 사용되며 녹색은 약한 영향을 나타냅니다. 자세한 내용은 표 03을 참조하십시오.
이를 통해 테스터는 문서의 다른 색상 코드를보고 모듈의 변경 사항을 쉽게 이해할 수 있습니다. 이 문서는 개발자를위한 체크리스트 역할을하며 모듈과 종속성이 누락되었는지 여부를 확인할 수 있습니다.
| 그림 물감 | 기술 |
|---|---|
| 그물 | 높은 영향력 |
| 노랑 | 중간 영향력 |
| 초록 | 주 영향 |
표 03
로그인 기능이 변경되면 대부분 '로그인'기능 자체에 영향을 미칩니다. 로그인 기능의 변경 사항은 '프로필'기능과 '로그 아웃'기능에 약간 영향을 미칠 수 있습니다. 이는 색상 코드를 사용하여 영향 분석 문서에 표시됩니다. 따라서 문서는 Table No.04와 같습니다.
| 풍모 | 로그인 | 프로필 | 사서함 | 즐겨 찾기에 추가 | 로그 아웃 |
|---|---|---|---|---|---|
| 로그인 | |||||
| 프로필 | |||||
| 사서함 | |||||
| 즐겨 찾기에 추가 | |||||
| 로그 아웃 |
테이블 No.04
숫자를 사용하여 표 05에 표시된 영향력 수준을 나타낼 수 있습니다. 따라서 Table No.04는 Table No.06과 같이 다시 그릴 수 있습니다.
표 06에서는 로그인 기능 (영향 수준 : 03)이 가장 높은 우선 순위를가집니다. 프로필 기능 (영향 수준 : 02)은 중간 우선 순위가 부여됩니다. 로그 아웃 기능 (영향 수준 : 01)에 가장 낮은 우선 순위가 부여됩니다.
| 영향력 수준 | 기술 |
|---|---|
| 3. 네트워크 | 강한 영향력 |
| 2. 노란색 | 매질 |
| 1. 그린 | 낮은 |
테이블 No.05
| 풍모 | 로그인 | 프로필 | 사서함 | 즐겨 찾기에 추가 | 로그 아웃 |
|---|---|---|---|---|---|
| 로그인 | 3. 네트워크 | 1. 그린 | 2. 노란색 | ||
| 프로필 | |||||
| 사서함 | |||||
| 즐겨 찾기에 추가 | |||||
| 로그 아웃 |
표 06
노트 :
- 표에 표시된 숫자는 QA 팀에 매우 유용합니다. 그들은 쉽게 숫자를 기반으로 테스트 케이스의 우선 순위를 지정할 수 있습니다.
- 일부 큰 프로젝트는 더 많은 수준의 영향력을 갖습니다. 아래 표에 명시되어 있습니다. (참고로 Table No.07을 확인하시기 바랍니다.)
| 영향 수준 | 기술 |
|---|---|
| 5 | 매우 강한 |
| 4 | 강한 |
| 삼 | 매질 |
| 두 | 약한 |
| 1 | 매우 약한 |
표 No.07
많은 기능과 하위 기능이있는 프로젝트에 대한 영향 분석 문서를 준비하는 방법은 무엇입니까?
20 개의 기능이있는 프로젝트를 고려하고 해당 프로젝트의 모든 주요 기능에는 각각 5 개의 하위 기능이 있습니다. 영향 분석 문서를 나타내는 매트릭스는 매우 커서 유지 관리하기 어려울 것입니다. 해당 테이블은 테이블 번호와 같습니다.08.
| 기준 치수 | 모듈 1 | 하위 모듈 1 | 하위 모듈 2 | 하위 모듈 3 | ........ | 모듈 2 | 하위 모듈 1 | 하위 모듈 2 | .............. |
| 모듈 1 | |||||||||
| 하위 모듈 1 | |||||||||
| 하위 모듈 2 | |||||||||
| ............. | |||||||||
| 모듈 2 | |||||||||
| 하위 모듈 1 |
표 No.08
따라서이 문제를 극복하기 위해 영향 분석 문서에서 모듈 및 하위 모듈을 나타내는 특수 테이블을 사용할 수 있습니다. Table No.09를 참조하여 행은 주요 기능, 열은 하위 기능을 나타냅니다.
| 하위 모듈 1 | 하위 모듈 2 | 하위 모듈 3 | 하위 모듈 4 | 하위 모듈 5 | |
|---|---|---|---|---|---|
| 모듈 7 | |||||
| 모듈 1 | |||||
| 모듈 2 | |||||
| 모듈 3 | |||||
| 모듈 4 | |||||
| 모듈 5 |
표 09
이 문서를 대규모 프로젝트에 사용함으로써 개발자는 주요 기능의 변경으로 인해 영향을 미치는 하위 기능을 쉽게 표시 할 수 있습니다. 이 문서의 가독성은 다음과 비교할 때 더 좋습니다.표 09.
참고 : 모든 하위 기능은 주요 기능의 변경으로 인해 영향을받지 않습니다.
이제 50 개의 주요 모듈이있는 다른 프로젝트를 고려하십시오. 이 프로젝트에는 개발자 그룹이 있습니다. 다른 개발자는 프로젝트에서 다른 작업 (새 기능 추가, 버그 수정, 리팩토링 등)을 수행하고 있습니다.
영향 분석 문서를 사용하여 프로젝트의 변경 사항을 표시 할 수 있습니다. 개발자는 해당 변경 사항에 대한 정보를 테이블에 기록합니다. 표 10, 표 11을 참조하십시오.
| 구성 변경 | 개발자 의견 | 우선 순위 | 향후 계획 | |
|---|---|---|---|---|
| 모듈 1 | Chrome 브라우저 | Chrome 브라우저를 사용하여 테스트합니다. | 버그 보고서 # 001 | |
| 모듈 2 | ||||
| 모듈 3 | ||||
| 모듈 4 | ||||
| 모듈 5 | ||||
| 모듈 6 |
표 10
| 아이템 | 기술 |
|---|---|
| 구성 변경 | 프로젝트에서 일부 모듈 / 기능의 변경은 사용 된 장치 / 환경에 따라 다릅니다. 개발자는 테스터가 변경 사항을 더 잘 이해할 수 있도록 문서에서 구성 변경 사항을 지정해야합니다. |
| 개발자의 의견 | 테스트를 수행하는 동안 테스터에게 필요한 가장 중요한 정보 중 하나입니다. |
| 우선 순위 | 테스터는 문서의 색상 코드 또는 숫자를 사용하여 테스트 작업의 우선 순위를 쉽게 지정할 수 있습니다. |
| 향후 계획 | 테스터는 개발자의 향후 계획을 알고 있어야합니다. 개발자가 몇 주 후에 코드를 변경할 계획이라면 테스터는 기능을 테스트하고 시간을 낭비 할 필요가 없습니다. 테스터는 개발자가 코딩 프로세스를 완료 할 때까지 기다릴 수 있습니다. |
표 11
테스트에서 영향 분석의 장점
- 정확한: 이 문서는 항상 애플리케이션의 모듈 / 기능 변경에 관한 정확한 데이터를 제공합니다.
- 테스트 효율성 향상 : 이 문서의 도움으로 테스터는 모듈의 변경 사항에 대한 명확한 정보를 제공하므로 테스트 사례를보다 효율적으로 계획 할 수 있습니다.
- 동기화 된 작업 : 모든 팀 구성원은 영향 분석 문서를 업데이트 할 책임이 있습니다. 이 문서는 최신 상태 여야합니다.
- 정확한: 문서를 쉽게 읽을 수 있기 때문에 테스터는 문서를보고 애플리케이션의 변경 사항에 대한 명확한 아이디어를 갖게됩니다.
- 테스트 시간 감소 : 전체 시스템을 테스트하는 것 외에도 테스터는 변경된 모듈 및 하위 모듈에서 테스트를 수행 할 수 있습니다. 테스터는 테스트 케이스의 우선 순위를 지정하고 계획 할 수 있습니다. 따라서 테스트 시간을 줄일 수 있습니다.
- 범위 증가 : 이 문서를 사용하여 테스터는 모듈 변경 사항의 영향을받는 하위 모듈을 확인했는지 확인합니다. 이렇게하면 프로젝트의 테스트 범위가 증가합니다.
- 테스트 결과의 표준화 : 개발자와 테스터는 모듈의 모든 변경 사항을 나타내는 공통 영향 분석 문서를 사용합니다.
- 팀의 책임 증가 : 팀 구성원은이 문서를 최신 상태로 유지해야합니다. 모든 팀원은 자신이 시스템에 적용한 변경 사항에 대한 정보를 업데이트 할 책임이 있습니다.
- 작업의 우선 순위를 빠르고 쉽게 지정하십시오. 문서는 변경 사항에 대한 명확한 그림을 제공하므로 테스터는 이에 따라 테스트의 우선 순위를 지정할 수 있습니다.
- 제품에 대한 명확한 지식 : 이 문서의 도움으로 개발자와 테스터 모두 시스템에있는 모든 모듈에 대한 아이디어를 갖게됩니다.
- 쉬운 버그 감지 : 버그 감지가 훨씬 향상되었습니다. 영향 분석 문서는 통합 테스트에 유용합니다.
결론
프로젝트는 영향 분석을 사용하거나 사용하지 않고 수행 할 수 있습니다. 그러나 위 기사에서 영향 분석 문서의 이점을 확인했습니다. 이 문서의 도입으로 테스트 시간이 크게 단축되었습니다. 테스터는 변경되지 않은 기능을 테스트하여 시간을 낭비 할 필요가 없습니다.
이 문서의 도입으로 개발자와 테스터 간의 의사 소통이 훨씬 향상되어 테스트 효율성이 향상됩니다. 테스터는 전체 시스템에 대해 더 잘 이해할 수 있습니다.
자바에서 이진 트리 삽입 및 삭제
테스트의 영향 분석에 대해 명확하게 이해 하셨기를 바랍니다. 의견을 자유롭게 공유하십시오.
추천 도서
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- 경력으로 소프트웨어 테스트 선택
- 분석 능력 및 사고력 테스트-소프트웨어 테스트 연습 (2 부)
- 소프트웨어 테스팅 과정 피드백 및 리뷰
- 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
- 소프트웨어 테스트는 감정적 인 작업입니까?