비파괴 소프트웨어 테스트(NDT): 테스트 전략이란 무엇인가?
⚡ 스마트 요약
비파괴 테스트는 애플리케이션이 유효한 입력을 받았을 때 올바르게 동작하는지 확인하는 테스트입니다. 이러한 이유로 테스터들은 이를 긍정적 경로 테스트 또는 정상 경로 테스트라고도 부릅니다. 비파괴 테스트는 문서화된 요구사항과 예상되는 결과가 일치하는지 확인합니다.

비파괴적인 소프트웨어 테스팅이란 무엇입니까?
비파괴 검사 소프트웨어 응용 프로그램을 올바르게 테스트하고 상호 작용하는 소프트웨어 테스트 유형입니다. 즉 NDT(Non Destructive Software Testing)는 Positive Testing 또는 Happy Path Testing이라고도 합니다. 이는 예상한 결과를 제공하고 소프트웨어 애플리케이션이 예상대로 작동하고 있음을 증명합니다.
이 용어는 공학에서 차용한 것으로, 비파괴 검사는 물리적 구성 요소를 손상시키지 않고 검사하는 기술입니다. 소프트웨어에서도 개념은 동일합니다. 애플리케이션은 설계된 방식대로 실행되며, 테스트를 거쳐도 손상되지 않고 그대로 유지됩니다.
예: 로그인 모듈에 올바른 데이터를 입력하고 자격 증명이 승인되어 다음 페이지로 이동하는지 확인합니다.
아래 스크린샷은 테스트 실행 전에 사용자 이름 필드에 유효한 값이 입력된 로그인 양식을 보여줍니다.
위 예시에 대한 비파괴 검사를 수행하려면 로그인 양식에 유효한 사용자 이름과 비밀번호를 입력하십시오. 입력값이 요구 사항과 일치하므로 원하는 결과는 긍정적이며, 검사자는 애플리케이션이 다음 페이지로 이동하는지 확인하기만 하면 됩니다.
비파괴 소프트웨어 테스트(NDT)를 수행하는 이유는 무엇입니까?
비파괴 테스트는 모든 이해관계자가 빌드에 대해 묻는 첫 번째 질문, 즉 "기능이 실제로 요청된 대로 작동하는가?"에 대한 답을 제공합니다. 이것이 바로 팀이 비파괴 테스트를 실행하는 이유입니다.
- 비파괴검사(NDT) 방법의 가장 큰 장점은 주요 코드 흐름에서 발견된 결함을 조기에 수정함으로써 소프트웨어 품질을 향상시킬 수 있다는 점입니다.
- 소프트웨어 기능이 사양에 따라 작동하고 있음을 보여줍니다.
- 성능 요구사항이 충족되었는지 확인하기 위해서입니다.
- 최종 사용자의 요구사항이 충족되었는지 확인하기 위해서입니다.
- 코드의 일부 또는 기능이 예상대로 작동하는지, 관련 기능을 손상시키지 않는지 확인하기 위해서입니다.
- 증거를 제시하여 특정 상황에서 보여줄 수 있도록 하기 위해 사용자 수용 테스트 최종 승인 단계에서는 고객이 실패 모드보다는 의도된 동작을 확인하고 싶어합니다.
비파괴검사(NDT)는 언제 수행되나요?
여기서는 타이밍이 다른 대부분의 기술보다 훨씬 중요합니다. 왜냐하면 성공적인 경로가 이후의 모든 것을 좌우하기 때문입니다.
- 이는 테스터가 애플리케이션에 대해 수행하는 첫 번째 형태의 테스트, 즉 초기 단계에서 수행하는 테스트입니다. SDLC.
- 비파괴 검사는 일반적으로 전체 검사 주기를 수행할 시간이 부족할 때 실시되며, 이를 통해 합격 기준이 충족되었음을 입증할 수 있습니다.
- 이는 부정적이고 파괴적인 시나리오가 발생하기 전에 실행됩니다. 주요 흐름이 중단되면 오류 처리 테스트는 실제 결함이 아닌 노이즈를 보고합니다.
- 이는 모든 결함 수정 후에 반복되며, 그 부분에서 기존 내용과 중복됩니다. 회귀 테스트.
비파괴 테스트를 위한 테스트 전략
비파괴 검사 전략은 의도적으로 단순하며, 핵심은 도구보다는 긍정적인 자세를 유지하는 데 있습니다.
- 비파괴 검사에 대한 접근 방식은 긍정적이어야 합니다.
- 비파괴 검사(NDT) 기법의 목적은 유효한 입력 데이터가 주어졌을 때 애플리케이션이 제대로 작동하는지 증명하는 것입니다.
- 비파괴 검사를 수행하는 데 특별한 요구 사항이나 환경이 필요하지 않습니다.
- 비파괴 검사의 가장 좋은 방법은 시스템이 제대로 작동하는지 확인하는 것입니다.
아래 다이어그램은 해당 전략이 테스트 주기 동안 일반적으로 어떻게 구성되는지 요약한 것입니다.
비파괴(긍정적) 테스트 케이스 작성 방법
비파괴 테스트 케이스는 입력값이 검증 가능한 유효성을 가지고 있고, 예상 결과가 테스터의 추측이 아닌 요구사항에서 도출된 경우에만 유용합니다. 다음 단계들을 통해 이러한 조건을 충족하는 테스트 케이스를 만들 수 있습니다. 테스트 사례.
1단계) 합격 기준을 하나 선택하세요. 요구 사항을 읽고 "사용자 이름 필드에는 6자에서 20자 사이의 영숫자를 사용할 수 있습니다."와 같이 검증 가능한 단일 문장으로 다시 작성하십시오.
2단계) 유효한 입력 데이터를 선택하세요. 허용된 범위 내에 속하는 값을 선택하십시오. 등가 분할 여기서 도움이 되는 것은 유효한 파티션당 하나의 대표값이면 일반적으로 충분하다는 점입니다.
3단계) 실행하기 전에 예상 결과를 적어 두세요. 예상 결과는 명세에 명시되어야 합니다. 실행 후에 예상 결과를 작성하면 테스트는 빌드 과정에서 발생한 결과에 대한 설명으로 전락하게 됩니다.
4단계) 사용자가 원하는 순서대로 단계를 진행하세요. 해당 순서는 실제 사용자가 작업을 완료하는 방식과 일치해야 합니다. 왜냐하면 이 기법의 목적은 의도된 사용자 여정을 확인하는 것이기 때문입니다.
5단계) 요구사항 식별자를 기록합니다. Trac해당 사례를 원래 기준으로 되돌리는 것이 팀이 검토 과정에서 보장 범위를 입증할 수 있게 해주는 핵심입니다.
로그인 모듈의 예시는 다음과 같습니다.
| 분야 | 비파괴 검사 사례 |
|---|---|
| 요구 사항 | 사용자 이름은 6~20자의 영숫자로 구성될 수 있습니다. |
| 테스트 데이터 | ID / Username guru99tester유효한 일치하는 비밀번호 |
| 단계 | 로그인 페이지를 열고 자격 증명을 입력한 후 로그인을 선택하세요. |
| 예상 결과 | 자격 증명이 승인되면 홈페이지가 표시됩니다. |
| 타입 | 긍정적/행복한 길 |
이 경우 어떤 것도 입력 필드를 깨뜨리려고 시도하지 않는다는 점에 유의하십시오. 오류 메시지를 보려면 다섯 글자를 입력해야 하는 경우입니다. 음성 검사비파괴적인 방식이 아닙니다.
비파괴 검사의 예
아래 예시는 결함이 수정된 후 다중 모듈 애플리케이션에서 비파괴 검사가 어떻게 작동하는지 보여줍니다.
- 이 애플리케이션은 로그인 페이지, 홈 페이지, 사용자 상세 페이지, 신규 사용자 생성 및 작업 생성의 다섯 가지 모듈로 구성됩니다.
- 로그인 페이지에 버그가 있다고 가정해 보겠습니다. 사용자 이름 입력란에 6자 미만의 영숫자 문자가 허용되는 것입니다. 이는 사용자 이름에 6자 미만의 문자를 입력할 수 없다는 요구 사항을 위반하는 것이므로 결함입니다.
- 해당 버그는 일반적인 절차를 통해 개발팀에 보고됩니다. 결함 관리 프로세스문제가 해결되면 빌드를 테스트 팀으로 다시 보냅니다.
- 테스트 팀은 결함이 수정된 로그인 페이지뿐만 아니라 다른 모듈도 테스트합니다. 모든 모듈을 유효한 데이터로 테스트하는 동안, 전체 애플리케이션이 여전히 정상적으로 작동하는지 확인하기 위해 비파괴 테스트를 수행합니다.
비파괴 검사 vs 파괴 검사
이 두 가지 기술은 동일한 제작 과정에 대한 정반대의 질문에 답을 제시하기 때문에 함께 가르치는 경우가 많습니다. 파괴적인 테스트 소프트웨어가 제대로 작동하지 않는 지점을 찾는 반면, 비파괴 검사는 의도한 동작이 유지되는지 확인합니다.
| 아래 | 비파괴 검사 | 파괴적인 테스트 |
|---|---|---|
| 의지 | 애플리케이션을 올바르게 사용하고 긍정적인 결과를 확인하십시오. | 오류 지점을 찾기 위해 비정상적이거나 유효하지 않은 입력을 제공하십시오. |
| 입력 데이터 | 요구사항에서 추출한 유효한 데이터 | 유효하지 않거나, 손상되었거나, 순서가 잘못된 데이터 |
| 필요한 요구 사항 | 예, 사례는 승인 기준에 따라 작성됩니다. | 꼭 그렇지는 않습니다. 테스터는 사용자 스토리에 대한 편견 없이 작업합니다. |
| 그것이 드러내는 것 | 사양 대비 기능상의 약점 | 설계, 견고성 및 복구 가능성의 약점 |
| Related techniques | 연기 테스트, 기능 테스트 | 원숭이 테스트, 탐색적 테스트 |
이 두 가지는 대안이 아니라 상호 보완적인 관계입니다. 비파괴 검사만으로는 오류 처리 능력을 검증할 수 없고, 파괴 검사만으로는 제품이 제 기능을 제대로 수행한다는 것을 결코 입증할 수 없습니다.
비파괴 소프트웨어 테스트의 장점과 한계
해당 기법이 더 이상 유용하지 않은 지점을 아는 것은 그 기법이 어떤 범위를 다루는지 아는 것만큼 중요합니다.
장점
- 설계 및 실행 속도가 빠릅니다. 테스트 데이터가 사양서에서 바로 제공되기 때문입니다.
- 특별한 환경, 오류 주입 또는 손상된 데이터 세트가 필요하지 않습니다.
- 요구사항과 일대일로 대응하는 증거를 제시하여 감사 및 승인에 적합합니다.
- 똑같이 잘 작동합니다 수동 테스트 그리고 대본대로 자동화 테스트따라서 동일한 사례를 회귀 테스트 스위트에서 재사용할 수 있습니다.
- 유닛부터 시작하여 모든 단계에서 빌드 상태에 대한 조기에 솔직한 신호를 제공합니다. 통합 테스트 에 시스템 테스트.
제한 사항
- 완벽한 테스트 통과는 애플리케이션이 유효하지 않은 입력에 대해 어떻게 동작하는지에 대한 정보를 제공하지 않으므로, 심각한 오류 처리 결함이 테스트를 통과할 수 있습니다.
- 테스트 범위는 요구사항의 품질에 따라 제한됩니다. 명시되지 않은 사항은 절대 테스트하지 않습니다.
- 출시 전에 성공적인 경로만 시도하는 것은 잘못된 자신감을 심어줄 수 있습니다.
- 이는 스트레스 상황에서의 견고성, 회복력 또는 성능을 측정하지 않으며, 이러한 부분에는 더 광범위한 측정 기법이 필요합니다. 소프트웨어 테스트 유형.
비파괴 검사를 모든 다른 기술의 기반이 되는 기본 단계로 간주하고, 더 넓은 범위의 검사 계획에 포함시켜야 합니다. 소프트웨어 테스팅 수명주기 일회성 활동이 아니라, 지속적인 노력의 결과이다.


