소프트웨어에서 파괴적 테스트란 무엇인가요?

⚡ 스마트 요약

파괴적 테스트는 소프트웨어 애플리케이션이 의도적으로 오류를 일으킬 때까지 극한의 부하를 가하여, 일반적인 기능 검사로는 결코 도달할 수 없는 부적절한 사용, 잘못된 입력 및 예측 불가능한 동작으로 인해 안정성이 무너지는 정확한 지점을 드러냅니다.

  • 💥 핵심 아이디어: 해당 애플리케이션은 의도적으로 오류가 발생하도록 설계되어 오류 발생 지점을 명확하게 파악하고 측정할 수 있도록 합니다.
  • 🔎 별도의 요구 사항이 없습니다. 사양에 대한 사전 지식은 필수 사항은 아니지만, 테스트 전략을 더욱 효과적으로 세울 수 있도록 도와줍니다.
  • ⚖️ 반대되는 쌍: 비파괴 검사는 순조로운 길을 걷지만, 파괴 검사는 온갖 잘못된 각도에서 공격합니다.
  • 🧰 구혼: 고장점 분석, 테스터 간 동료 평가, 비즈니스 검토 및 실행 시트를 활용한 탐색적 실행.
  • 🧪 재사용된 메서드: 회귀 테스트, 인터페이스 테스트, 동등 분할 테스트, 반복 테스트 및 인수 테스트는 모두 파괴적인 목표를 가지고 있습니다.
  • 📉 정직한 한계: 조사 범위를 보장하기 어렵고, 많은 노력이 필요하며, 조사 결과를 재현하기 어려울 수 있습니다.

소프트웨어 파괴 테스트란 무엇이며, 그 방법과 기법은 무엇인가?

파괴 테스트 란 무엇입니까?

파괴적인 테스트 파괴적 테스트는 소프트웨어 프로그램의 오류 발생 지점을 찾는 데 사용되는 소프트웨어 테스트 방법입니다. 이 기법에서는 애플리케이션이 의도적으로 오류를 일으키도록 만들어 안정성을 검증하고 오류 발생 지점을 식별합니다. 애플리케이션이 의도적으로 수행해야 하는 기능을 검증하는 다른 테스트 방법과 달리, 파괴적 테스트는 애플리케이션 내부에서 예측할 수 없는 사용자 동작을 검사합니다.

파괴 시험에는 원래 요구 사항에 대한 지식이 필수적이지는 않습니다. 하지만 개발 과정에서 어느 정도의 지식은 도움이 됩니다.ping 훌륭한 테스트 전략.

아래 그림은 그 개념을 잘 보여줍니다. 테스터는 제품과 함께 작업하기보다는 제품과 맞서 싸우는 역할을 합니다.

파괴적 시험 개념: 애플리케이션을 의도적으로 고장 지점까지 몰아붙이는 것

파괴 시험을 하는 이유는 무엇일까요?

  • 이는 소프트웨어가 부적절하게 사용될 때 나타날 수 있는 예측 가능한 소프트웨어 동작을 이해하는 데 도움이 됩니다.
  • 소프트웨어 제품의 견고성을 확인하는 데 도움이 됩니다.
  • 이 기능은 일반 사용자가 절대 발생시키지 않지만 생산 과정 후반에 나타나는 드문 결함을 찾아냅니다.

파괴 검사 vs 비파괴 검사

두 접근 방식은 경쟁 관계가 아니라 상호 보완적입니다. 비파괴 검사 긍정적 테스트 또는 정상 경로 테스트라고도 하는 파괴적 테스트는 소프트웨어와 올바르게 상호 작용하며 빌드를 그대로 유지합니다. 파괴적 테스트는 이와 반대로, 무언가 오류가 발생할 때까지 유효하지 않은 데이터와 잘못된 시퀀스를 입력합니다.

아래 파괴적인 테스트 비파괴 검사
의지 애플리케이션이 실패하도록 강제합니다 애플리케이션이 명시된 대로 작동하는지 확인하십시오.
입력 사용됨 유효하지 않음, 형식이 잘못됨, 범위를 벗어남, 순서가 잘못됨 예상 범위 내의 유효한 데이터
질문에 대한 답변 어디서, 어떻게 고장나는 건가요? 제대로 작동하나요?
요구사항 지식 Optional 본질적인
일반적인 비용 더 높은 수준 — 탐구적이고 개방적인 하위 — 스크립트화되고 반복 가능
결과 실패 지점, 범위 제한, 복구 동작 규격에 부합하는지 여부에 따라 합격 또는 불합격 여부가 결정됩니다.

파괴 검사에서 무엇을 확인하나요?

파괴 시험은 동작 경계의 양쪽 측면을 모두 살펴봅니다.

  • 소프트웨어의 올바른 동작
  • 부적절한 소프트웨어 동작
  • 부적절한 사용
  • 부적절한 입력 데이터
  • 올바른 출력 데이터

이 연습 과정 전반에 걸쳐 다음 두 가지 조건이 충족되어야 합니다.

  • 이 소프트웨어는 유효하지 않은 입력 데이터를 절대 처리하거나 허용해서는 안 됩니다.
  • 입력 데이터의 유효성이나 정확성과 관계없이 소프트웨어는 항상 올바른 출력 데이터를 생성해야 합니다.

파괴적인 테스트를 수행하는 방법은 무엇입니까?

파괴적 테스트에는 테스트 스크립트 세트 설계, 스크립트 실행, 버그 보고, 버그 해결, 그리고 반복 작업 종료 시 이해관계자에게 합격 또는 불합격 여부 지표 제공과 같은 여러 활동이 포함됩니다.

실행하는 방법은 여러 가지가 있습니다. 몇 가지 예는 다음과 같습니다.

  • 고장점 분석 방법: 시스템 작동 과정을 단계별로 살펴보고, 발생할 수 있는 다양한 문제점을 평가합니다. 도움을 줄 수 있는 전문가의 도움을 받으세요. 비즈니스 분석가 이 전략에 사용될 수 있습니다.
  • 테스터 동료 평가: 너를 잡아라. 테스트 케이스 시스템이나 기능에 대해 덜 익숙한 동료 테스터가 분석 또는 검토했습니다.
  • 테스트 케이스에 대한 비즈니스 검토: 최종 사용자나 전문가들은 테스터들이 놓치는 타당한 시나리오를 종종 떠올리는데, 이는 테스터들이 명시된 요구 사항에만 집중하기 때문입니다.
  • 실행표를 사용하여 탐색적 테스트를 수행하십시오. 탐색적 테스트 테스트 실행 기록지는 테스트 내용을 기록하고, 테스트를 반복할 수 있게 하며, 테스트 범위를 관리하는 데 도움이 됩니다.
  • 다른 자료를 활용하세요: 다른 사람에게 소프트웨어 제품을 분석해 달라고 요청하고, 그들이 발견한 시나리오를 분석해 보세요.

파괴 시험 예시

은행 애플리케이션의 로그인 및 프로필 화면을 생각해 보세요. 파괴적 접근 방식은 이러한 경우들을 통해 작동할 수 있습니다.

  • 50자 제한 필드에 5,000자 길이의 문자열을 붙여넣고, 필드가 문자열을 잘라내지 않고 거부하는지 확인하십시오.
  • 숫자 금액 입력란에 문자, 기호 및 음수 값을 입력하십시오.
  • 예상되는 순서를 깨고 이전 단계를 완료하지 않고 바로 결제 확인 페이지를 엽니다.
  • 중복된 기록이 생성되는지 확인하려면 제출 버튼을 반복해서 빠르게 눌러보세요.
  • 거래 도중에 네트워크 연결을 끊고 애플리케이션이 정상적으로 복구되는지 또는 부분적인 기록이 남는지 확인하십시오.

각 테스트 케이스에는 명확한 유효성 검사 메시지, 데이터 손상 없음, 처리되지 않은 예외 없음과 같은 기대치가 있습니다. 이 외의 모든 사항은 결함으로 보고해야 할 실패 지점입니다.

파괴적인 테스트 방법

소프트웨어 엔지니어링에서 파괴적 테스트 목표를 달성하기 위해 다음과 같은 방법들이 사용됩니다.

파괴적인 테스트 기술

아래 기술들은 약간의 수정을 거쳐 사용할 수 있습니다.

견고성을 목표로 할 때 추가할 만한 관련 기술은 다음과 같습니다. 부정적인 테스트, 스트레스 테스트, 회복 테스트 퍼지 테스트.

파괴 검사의 장점과 단점

해당 기술을 출시하기 전에 그 장단점을 명확히 밝히는 것이 중요합니다.

장점

  • Rev사양 기반 테스트로는 결코 도달할 수 없는 실패 지점을 찾아냅니다.
  • 실제 작동 범위 한계를 설정하여 제품을 해당 범위 내에서 안심하고 사용할 수 있도록 합니다.
  • 출시 후 오랜 시간이 지나 생산 과정에서 드러나는 드문 결함을 밝혀냅니다.
  • 오용 상황에서의 내구성, 복구 가능성 및 오류 처리 능력을 점검합니다.

단점

  • 본질적으로 범위가 정해져 있지 않으므로 보장 범위를 쉽게 보장하거나 측정할 수 없습니다.
  • 시간이 많이 소요되며 테스터의 경험과 창의성에 따라 결과가 달라집니다.
  • 실험 과정을 꼼꼼하게 기록하지 않으면 결과를 재현하기 어려울 수 있습니다.
  • 제대로 제어되지 않은 실행은 공유 테스트 데이터를 손상시킬 수 있으므로 격리된 환경이 필요합니다.

자주 묻는 질문

두 개념은 겹치는 부분이 있지만 범위는 다릅니다. 음성 테스트 정의된 유효하지 않은 입력에 대해 예상되는 오류 처리를 검증하는 검사입니다. 파괴적 테스트는 더 광범위하고 개방적이며, 애플리케이션 오류를 유발하는 모든 조건을 찾아냅니다.

일반적으로 경험이 풍부한 QA 엔지니어들이 해당 모듈에 익숙하지 않은 동료 및 비즈니스 사용자의 지원을 받아 검토합니다. 외부인의 시각이 중요한 이유는 기능을 개발한 사람들이 설계된 방식대로 테스트하는 경향이 있기 때문입니다.

기능 통합이 안정화된 후에는 오류가 발생하더라도 미완성 기능보다는 안정성 문제임을 알 수 있습니다. 많은 팀에서 시스템 테스트 중에 이 작업을 수행하고 주요 릴리스 전에 반복합니다. 테스트 수명 주기.

모델은 테스터가 따라잡을 수 없는 엄청난 양으로 잘못된 페이로드, 경계값 및 비정상적인 동작 시퀀스를 생성한 다음, 어떤 모델이 이상 현상을 발생시켰는지 순위를 매깁니다. 과거 결함 데이터에 대한 머신 러닝은 어떤 모듈이 가장 강력한 처리를 받아야 하는지도 예측합니다.

GitHub 부조종사 입력 생성기, 경계 조건 및 테스트 종료 루틴을 신속하게 작성할 수 있습니다. 하지만 테스터는 어떤 오류 모드가 중요한지, 그리고 관찰된 동작이 허용 가능한 결과인지 여부를 여전히 결정해야 합니다.

정확한 입력값 또는 순서, 관찰된 오류, 로그 및 스크린샷, 환경, 그리고 영향의 심각도 등이 포함됩니다. 반복 작업의 성공 또는 실패 여부는 이해관계자에게 전달됩니다. 결함 기록.

이 코드는 절대로 프로덕션 환경에 배포해서는 안 됩니다. 의도적으로 잘못된 데이터를 입력하거나 강제로 프로그램을 종료시키면 불완전한 기록이 남을 수 있으며, 이를 복구하는 데 상당한 비용이 발생할 수 있으므로, 복구 가능한 데이터를 사용하여 격리된 환경에서 실행하십시오.

세션 동안 모든 동작과 입력을 순서대로 기록하는 실행표를 작성하십시오. 기록표를 깨끗한 상태에서 재생한 다음, 오류가 발생하는 가장 짧은 시퀀스로 줄이십시오.

이 게시물을 요약하면 다음과 같습니다.