destructive testing
유형 및 방법에 따른 파괴 테스트와 비파괴 테스트의 차이점 :
이 기사에서는 파괴 테스트 및 비파괴 소프트웨어 테스트에 대해 자세히 설명합니다.
우리는 그것들에 대해 하나씩 배우고 기사의 끝에서 두 가지 테스트 유형의 차이점을 볼 것입니다.
학습 내용 :
파괴 테스트 란 무엇이며 그 이점은 무엇입니까?
Destructive Software Testing (DST)은 소프트웨어 응용 프로그램의 일부가 제어되지 않은 방식으로 실패하도록하고, 견고 함을 테스트하고 실패 지점을 감지하는 일종의 소프트웨어 테스트입니다.
소프트웨어의 기능을 확인하는 다른 기존 유형의 소프트웨어 테스트 방법과 달리이 방법은 소프트웨어 내에서 예측할 수없는 사용자 행동을 검사합니다. 따라서 일반 사용자가 일반적으로 경험하지 못하는 소프트웨어 결함을 발견 할 수 있습니다.
파괴적 소프트웨어 테스트 (DST)는 기존 유형 소프트웨어 테스트 (CST)에 대한 대체 접근 방식이지만 대체가 아닙니다. CST 외에 DST를 실시하는 것이 효과적입니다.
파괴 테스트는 가장 엄격한 작동 조건에서 수행되며 애플리케이션이 중단 될 때까지 계속 진행됩니다. 이 테스트의 핵심 아이디어는 정상적인 작업 조건에서 드러나지 않을 수있는 설계 취약점을 발견 할뿐만 아니라 소프트웨어 제품의 서비스 수명을 발견하는 것입니다.
이 유형의 테스트는 Monkey Testing, Ad Hoc Testing 및 Exploratory Testing과 유사점을 공유합니다.
파괴적인 소프트웨어 테스트의 이점
Eclipse에서 프로젝트를 만드는 방법
- 애플리케이션의 견고성, 복구 가능성 및 수명을 측정하는 데 도움이됩니다.
- 소프트웨어를 부적절하거나 오용 한 경우 실패 지점을 표시합니다.
- 테스트에서 사용자 스토리의 편견을 무시하므로 테스터에게 올바른 컨텍스트를 설정합니다.
- 이를 통해 일반 사용자가 일반적으로 경험하지 못하는 소프트웨어 결함을 발견 할 수 있습니다.
- 이러한 유형의 테스트는 응용 프로그램의 결함을 발견 할 때 고유합니다. 문제가 해결되면 소프트웨어 순위가 초심자 증명 상태로 올라갑니다.
이 테스트를 수행하는 단계
- 파괴적인 소프트웨어 테스트주기가 시작될 때 클라이언트는 응용 프로그램 복사본 또는 액세스 자격 증명과 사용자 요구 사항을 보냅니다.
- 그런 다음 클라이언트는 요구 사항을 제시하고 QA 분석가에게 애플리케이션을 보여줍니다.
- 다음으로 QA 분석가는 애플리케이션 내 경계의 기능을 설정하고 경계 내에서 애플리케이션의 사용성 한계를 생성합니다.
- 이제 QA 테스터는 확률 적 기술을 사용하여 해당 경계 내에서 애플리케이션을 무작위로 테스트합니다. QA 테스트 워크 플로 및 결함이 기록됩니다.
- 마지막으로 결함 디렉토리가 클라이언트와 공유됩니다.
- 필요한 경우 고객의 요구 사항에 따라 파괴적인 테스트주기를 반복 할 수 있습니다.
이 테스트에서는 소프트웨어의 원래 요구 사항에 대해 어느 정도 알고 있으면 좋습니다. 이것은 좋은 테스트 전략을 세우는 데 도움이됩니다.
파괴 테스트에서 무엇을 확인합니까?
- 소프트웨어 응용 프로그램의 부적절하고 적절한 동작.
- 유효하고 유효하지 않은 입력 데이터.
- 소프트웨어 응용 프로그램의 부적절한 사용.
파괴적인 소프트웨어 테스트 방법 및 전략
파괴 테스트를 수행 할 수있는 방법에는 여러 가지가 있습니다.
1) 실패 점 분석 방법 :
이 방법에서는 응용 프로그램의 모든 경로와 모서리에 액세스하기 위해 응용 프로그램을 검토하고 검사합니다. 다양한 지점에서 무엇이 실패 할 수 있는지 결정됩니다. 이 방법의 경우 비즈니스 분석가의 도움을 받아 애플리케이션을 살펴볼 수 있습니다.
2) 동료 검토 :
소프트웨어에 익숙하지 않은 동료 테스터가 응용 프로그램을 검토합니다. 이것은 테스터로서 당신에게 보이지 않는 몇 가지 숨겨진 실패 지점을 찾는 데 도움이 될 것입니다.
3) 비즈니스에서 테스트 사례 검토 받기 :
최종 사용자 및 기타 이해 관계자는 때때로 테스터가 놓쳤을 수있는 유효한 테스트 시나리오를 생각할 수 있습니다. 따라서 비즈니스에서 테스트 사례를 검토하면 테스트 범위를 늘릴 수 있습니다.
4) 탐색 적 테스트 :
실행 시트를 사용하여 탐색 테스트를 수행합니다. 테스트 대상을 파악하고 테스트를 반복하며 테스트 범위를 제어하는 데 도움이됩니다.
5) 부적절한 데이터로 시스템을 공급하십시오.
응용 프로그램에 잘못된 입력을 제공 할 수 있습니다. 여기에는 손상된 데이터, 사용자 인터페이스의 잘못된 단계 순서 등이 포함될 수 있습니다.
6) 다른 소스 사용 :
다른 소스 나 방법을 사용하여 시스템을 중단하고 다른 시나리오를 분석 할 수도 있습니다. 좋은 점은 파괴적인 소프트웨어 테스트의 사용자 스토리가 반드시 '요구 사항'과 '사양'을 요구하지 않으므로이 테스트를 수행하는 데 적합한 방법을 시도해 볼 수 있다는 것입니다.
파괴적인 테스트 기법
파괴적인 소프트웨어 테스트는 다음과 같은 다양한 기술을 통해 수행 할 수 있습니다.
- 수락 테스트
- 루프 테스트
- 회귀 테스트
- 등가 분할
- 경계 값 테스트
- 인터페이스 테스트
- 알파 / 베타 테스트
- 시스템 테스트
- 하향식 테스트
- 블랙 박스 테스트
파괴적인 소프트웨어 테스트를위한 몇 가지 유용한 팁
- 가능한 한 제품에 대한 많은 지식을 얻으십시오. 고객의 입장에서 생각하고 그의 관점에서 제품에 대해 생각하십시오.
- 사용자 스토리에서 편향된 정보를 모두 지 웁니다. 사용자 스토리 설명과 허용 기준을 잊어 버리고 미친 고객처럼 애플리케이션을 중단하십시오.
- 행복한 경로가 아닌 예외 경로를 찾으십시오. 허용 기준을 무시하면 예상되거나 정상적인 워크 플로를 알 수 없습니다.
- 신청서에서 긍정적 인 반응을 기대하지 마세요. 실패하면 어떻게 되나요? 가능한 모든 것을 시뮬레이션하고 손상 시키십시오.
- 모든 실제 사용자는 최고 수준의 시스템과 네트워크 상태를 갖지 못하므로 네트워크 상태를보다 현실적인 설정으로 제한하십시오.
비파괴 검사 란 무엇이며 그 이점은 무엇입니까?
비파괴 테스트 (NDT)는 소프트웨어와 올바르게 상호 작용하는 소프트웨어 평가 기술로 설명됩니다. 예외 경로를 찾는 파괴 소프트웨어 테스트와 달리 비파괴 테스트에서는 행복한 경로 또는 황금 경로를 찾습니다. NDT는 양성 검사라고도합니다.
예를 들어 1-999 이내의 숫자를 허용하는 입력 상자가있는 경우이 범위 내의 숫자를 입력하고 입력 상자의 기능을 확인하는 것이 긍정적 인 테스트 사례입니다.
경험있는 핵심 자바 인터뷰 질문 및 답변
NDT에는 알려진 요구 사항을 사용하여 잘 정의 된 테스트 케이스가 있으며, 이는 오류나 예외없이 실행되고 원하는 출력을 생성합니다. 예상 결과를 제공하고 소프트웨어가 예상대로 작동하는지 확인합니다.
혜택 비파괴 소프트웨어 테스트
- 향상된 소프트웨어 품질과 문제는 응용 프로그램의 주요 흐름에서 수정됩니다.
- 소프트웨어 응용 프로그램이 필수 사양에 따라 작동하고 있음을 보여주는 데 유용합니다.
- 고객의 기대치를 충족하는지 확인합니다.
- 성능 요구 사항이 충족되었는지 확인합니다.
- 제품 평가 및 문제 해결에 드는 시간과 비용을 모두 절약합니다.
이 테스트를 수행하는 경우
- 이는 첫 번째 테스트 형식이어야하며 행복한 경로가 애플리케이션의 주요 흐름이기 때문에 SDLC의 초기 단계에서 수행해야하며 제대로 작동하지 않으면 나머지 테스트가 차단됩니다.
- 테스트 할 시간과 예산이 충분하지 않을 때 빠르고 쉽게 수행 할 수 있습니다. 이는 최소한 소프트웨어 요구 사항 및 승인 기준이 충족되었는지 확인합니다.
비파괴 소프트웨어 테스트를위한 전략
- 비파괴 테스트를 수행하려면 긍정적 인 테스트 방식을 채택해야합니다.
- 테스트를 수행하는 동안 테스터는 비파괴 테스트의 목적이 애플리케이션이 유효한 입력 데이터를 제공 할 때 제대로 작동하는지 확인하는 것임을 명심해야합니다. 따라서 목표는 긍정적 인 데이터 세트에 대한 애플리케이션 동작을 확인하는 것입니다.
- 가장 좋은 방법은 시스템이 의도 한 작업을 수행하고 있는지 확인하는 것입니다.
파괴 테스트와 비파괴 테스트의 차이점
파괴적인 테스트 | 비파괴 검사 |
---|---|
기능이 아닌 디자인의 약점에 중점을 둡니다. | 디자인이 아닌 기능의 약점에 중점을 둡니다. |
반드시 비즈니스 요구 사항이 필요하지는 않습니다. 사전 결정된 요구 사항에 대해 알지 못한 채 파괴 테스트를 수행합니다. | 비즈니스 요구 사항 및 허용 기준에 대한 기능을 확인하기 위해 테스트가 수행됩니다. |
의도는 오류 지점을 감지하기 위해 비정상적인 입력을 제공하여 소프트웨어를 중단하는 것입니다. | 의도는 긍정적 인 결과를 확인하기 위해 소프트웨어와 올바르게 상호 작용하는 것입니다. |
결론
파괴적인 테스트에서 애플리케이션은 애플리케이션의 견고성을 검사하기 위해 의도적으로 충돌하도록 만들어졌습니다. 고객의 부적절한 애플리케이션 처리로 인해 발생할 수있는 소프트웨어의 장애 지점을 감지합니다.
기존 소프트웨어 테스트로는 추적 할 수없는 약점을 감지합니다. 더 나은 테스트 범위를 위해 기존 소프트웨어 테스트와 함께 파괴적인 소프트웨어 테스트를 수행하는 것이 좋습니다.
소프트웨어 기능이 고객 요구 사항을 충족하는지 확인하기 위해 긍정적 인 테스트 또는 행복한 경로 테스트 방식으로 비파괴 테스트를 수행합니다. 소프트웨어와 올바르게 상호 작용하는 것이 포함됩니다.
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- 시험 입문서 eBook 다운로드
- 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
- 소프트웨어 테스팅 과정 피드백 및 리뷰