7 소프트웨어 테스팅 원칙 : 사례 연구를 통해 학습

전문 소프트웨어 테스터 및 품질 보증 전문가가 알아야 할 모든 소프트웨어 테스팅의 7 가지 기본 원칙을 소개합니다.

배경

목표에서 벗어나지 않고 소프트웨어 테스팅을 수행하면서 최적의 테스트 결과를 얻는 것이 중요합니다. 그러나 테스트를위한 올바른 전략을 따르고 있다고 판단하는 방법은 무엇입니까? 이를 위해서는 몇 가지 기본 테스트 원칙을 고수해야합니다. 다음은 소프트웨어 산업에서 널리 사용되는 일곱 가지 일반적인 테스트 원칙입니다.

이것을 이해하려면 폴더 A에서 폴더 B로 파일을 이동하는 시나리오를 고려하십시오.

이것을 시험 할 수있는 가능한 모든 방법을 생각해보십시오.

일반적인 시나리오와는 별도로 다음 조건을 테스트 할 수도 있습니다.

열려있을 때 파일을 이동하려고합니다.

폴더 B에 파일을 붙여 넣을 수있는 보안 권한이 없습니다.

폴더 B가 공유 드라이브에 있고 저장 용량이 가득 찼습니다.

폴더 B는 이미 같은 이름의 파일을 가지고 있습니다. 목록은 무한합니다.

또는 테스트 할 입력 필드가 15 개이고, 각각 5 개의 가능한 값을 갖고 있다고 가정하면 테스트 할 조합 수는 5 ^ 15

가능한 모든 조합 프로젝트를 테스트한다면 EXECUTION TIME & COSTS가 기하 급수적으로 증가 할 것입니다. 우리는 테스트 노력을 최적화하기 위해 특정 원칙과 전략이 필요합니다.

여기에 7 가지 원칙이 있습니다.

1) 완전한 테스트가 불가능합니다.

예! 철저한 테스트는 불가능합니다. 대신 응용 프로그램의 위험 평가를 기반으로 최적의 테스트가 필요합니다.

그리고 백만 달러의 질문은, 어떻게 이 위험을 결정합니까?

이것에 대답하기 위해 연습을 해봅시다.

어떤 운영 체제가 운영 체제를 중단시킬 가능성이 가장 큽니까?

대부분의 사람들이 동시에 10 개의 다른 응용 프로그램을 열어 추측했을 것입니다.

따라서 이 운영 체제를 테스트하는 경우 멀티 태스킹 작업에서 결함이 발견 될 수 있고 철저하게 테스트해야한다는 사실을 깨닫게 되면 다음 원리로 넘어갑니다. 

2) 결함 클러스터링

소수의 모듈에 탐지 된 결함이 대부분 포함되어 있다는 결함 클러스터링. 이것은 소프트웨어 테스트에 파레토 원리를 적용한 것입니다. 문제의 약 80 %가 모듈의 20 %에서 발견됩니다.

경험을 통해 이러한 위험한 모듈을 식별 할 수 있습니다. 그러나이 접근법에는 자체적 인 문제가 있습니다.

동일한 테스트가 반복해서 반복되면 결국 동일한 테스트 케이스가 더 이상 새로운 버그를 찾지 않습니다.

3) 살충제 패러독스(Pesticide Paradox)

농약 중 동일한 곤충 혼합물을 반복적으로 사용하면 곤충을 근절하여 시간이 지나면 곤충이 농약에 내성을 갖게되어 벌레에 살충제가 효과적이지 않습니다. 소프트웨어 테스팅에도 동일하게 적용됩니다. 동일한 반복 테스트 세트가 수행되면이 방법은 새로운 결함을 발견하는 데 쓸모가 없습니다.

이를 극복하기 위해 테스트 사례를 정기적으로 검토 및 수정하고 새로운 & 다른 테스트 사례를 추가하여 더 많은 결함을 찾을 수 있도록해야합니다.

테스터는 단순히 기존 테스트 기술에 의존 할 수 없습니다. 그는 테스트를보다 효과적으로 만들기 위해 기존 방법을 개선하기 위해 지속적으로 주의해야합니다. 그러나 이 모든 땀과 테스트를 거친 후에도 제품에 버그가 없다고 주장 할 수는 없습니다. 

4) 결함 검사

따라서 테스트 원칙에서는 다음과 같이 명시합니다. - 테스트는 결함의 존재에 대해 이야기하고 결함이 없다는 것을 말하지 않습니다. 즉, 소프트웨어 테스팅은 소프트웨어에 남아있는 발견되지 않은 결함의 가능성을 줄이지 만 결함이 발견되지 않더라도 정확성의 증거는 아닙니다.

그러나 만약 당신이 더 열심히 일하면 모든 예방 조치를 취하고 당신의 소프트웨어 제품을 99 % 버그없는 상태로 만들 수 있습니까? 그리고 소프트웨어는 고객의 요구와 요구 사항을 충족시키지 못합니다.

이것은 우리에게 우리의 다음 원리로 인도합니다. 그것은 오류의 부재

5) 오류 없음

99 % 버그가없는 소프트웨어는 여전히 사용할 수 없습니다. 이는 시스템이 잘못된 요구 사항을 철저히 테스트하는 경우 일 수 있습니다. 소프트웨어 테스팅은 단순히 결함을 찾는 것이 아니라 소프트웨어가 비즈니스 요구 사항을 해결하는지 확인하는 것입니다. 오류의 부재는 오류입니다. 즉, 시스템 빌드를 사용할 수없고 사용자의 요구와 요구 사항을 충족시키지 못하면 결함을 찾아서 수정하는 것이 도움이되지 않습니다.

이 문제를 해결하기 위해 다음 테스트 원칙은 Early Testing

6) 조기 시험

초기 테스트 - 테스트는 소프트웨어 개발 수명주기에서 가능한 한 빨리 시작되어야합니다. 따라서 요구 사항이나 설계 단계의 결함이 초기 단계에서 파악됩니다. 테스트 초기 단계에서 결함을 수정하는 것이 훨씬 저렴합니다. 그러나 얼마나 일찍 테스트를 시작해야합니까? 요구 사항이 정의되는 순간 버그를 찾는 것이 좋습니다. 나중에이 튜토리얼에서이 원리에 대해 더 자세히 설명합니다.

7) 테스트는 문맥 의존적이다.

테스트는 컨텍스트에 따라 달라 지므로 기본적으로 전자 상거래 사이트를 테스트하는 방식이 상용 응용 프로그램을 테스트하는 방식과 다를 수 있습니다. 개발 된 모든 소프트웨어는 동일하지 않습니다. 응용 프로그램 유형에 따라 다른 접근법, 방법론, 기술 및 테스트 유형을 사용할 수 있습니다. 예를 들어, 소매점의 POS 시스템은 ATM 기계를 테스트하는 것과 다를 수 있습니다.

일곱 가지 테스트 원칙 요약

원칙 1	테스트 결과 결함이 있음을 나타냅니다.
원칙 2	철저한 테스트는 불가능합니다.
원칙 3	초기 테스트
원칙 4	결함 클러스터링
원칙 5	살충제 역설
원칙 6	테스트는 상황에 따라 다릅니다.
원칙 7	오류의 부재 - 오류

통념 : "원칙은 단지 참조 용이며 실제로 사용하지 않을 것입니다."

이것은 매우 사실이 아닙니다. 테스트 원칙은 효과적인 테스트 전략을 수립 하고 테스트 사례를 포착하는 데 드는 오류를 초안 하는 데 도움이됩니다 .

그러나 테스트 원리를 배우는 것은 처음으로 운전하는 법을 배우는 것과 같습니다.

운전을 배우는 동안 처음에는 기어 변속, 속도, 클러치 핸들링 등과 같은 모든 것에주의를 기울였습니다. 그러나 경험에 비추어 볼 때 나머지 운전은 자연스럽게 이루어집니다. 당신이 심지어 차의 다른 승객과 대화를 나눌 수 있도록.

테스트 원칙에 대해서도 마찬가지입니다. 경험이 풍부한 테스터는 이러한 원칙을 사고 없이도 적용 할 수있는 수준으로 내재화했습니다. 그러므로 원리가 실제로 사용되지 않는다는 신화는 단순히 사실이 아닙니다.