예제를 통한 소프트웨어 테스팅의 7가지 원칙


이 튜토리얼에서는 모든 소프트웨어 테스터와 QA 전문가가 알아야 할 XNUMX가지 기본 소프트웨어 테스트 원칙을 소개합니다.

소프트웨어 테스팅의 7가지 원칙

  1. 테스트 결과 결함이 있음이 확인되었습니다.
  2. 철저한 테스트는 불가능
  3. 초기 테스트
  4. 결함 클러스터링
  5. 농약 역설
  6. 테스트는 상황에 따라 다릅니다.
  7. 오류의 부재 오류

다음과 같이 테스트 원리를 배워봅시다.wing 비디오 예-

여기를 눌러 더 많은 정보를 찾으세요. 비디오에 접근할 수 없는 경우

배경

목표에서 벗어나지 않고 소프트웨어 테스트를 수행하면서 최적의 테스트 결과를 얻는 것이 중요합니다. 하지만 당신이 추종자인지 어떻게 판단하는가?wing 테스트를 위한 올바른 전략은 무엇입니까? 이를 위해서는 몇 가지 기본 테스트 원칙을 고수해야 합니다. 다음은 소프트웨어 업계에서 널리 사용되는 일반적인 XNUMX가지 테스트 원칙입니다.

이를 이해하려면 폴더 A에서 폴더 B로 파일을 이동하는 시나리오를 생각해 보세요.

이를 테스트할 수 있는 가능한 모든 방법을 생각해 보십시오.

일반적인 시나리오 외에도 다음을 테스트할 수도 있습니다.wing 조건

  • 파일이 열려 있는 상태에서 파일을 이동하려고 합니다.
  • 폴더 B에 파일을 붙여넣을 수 있는 보안 권한이 없습니다.
  • 폴더 B가 공유 드라이브에 있고 저장 용량이 가득 찼습니다.
  • 폴더 B에는 이미 같은 이름의 파일이 있습니다. 실제로 목록은 끝이 없습니다.
  • 또는 테스트할 입력 필드가 15개 있고 각 필드에 가능한 값이 5개 있다고 가정하면 테스트할 조합 수는 5^15입니다.

가능한 전체 조합 프로젝트를 테스트한다면 실행 시간과 비용이 기하급수적으로 늘어날 것입니다. 테스트 노력을 최적화하려면 특정 원칙과 전략이 필요합니다.

7가지 원칙은 다음과 같습니다.

1) 철저한 테스트는 불가능하다

예! 철저한 테스트는 불가능합니다. 대신, 애플리케이션의 위험 평가를 기반으로 최적의 테스트 양이 필요합니다.

그리고 백만 달러짜리 질문은 이 위험을 어떻게 결정하는가입니다.

이에 답하기 위해 연습을 해보겠습니다.

귀하의 운영 체제에 오류가 발생할 가능성이 가장 높은 작업은 무엇이라고 생각하십니까?

나는 여러분 대부분이 동시에 10개의 다른 응용 프로그램을 여는 것을 짐작했을 것이라고 확신합니다.

따라서 이 운영 체제를 테스트하는 경우 멀티 태스킹 활동에서 결함이 발견될 가능성이 높으며 철저한 테스트를 거쳐 다음 원칙을 제시해야 한다는 점을 깨닫게 될 것입니다. 결함 클러스터링

2) 결함 클러스터링

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

경험을 통해 이러한 위험한 모듈을 식별할 수 있습니다. 하지만 이 접근 방식에는 문제가 있습니다.

동일한 테스트가 계속해서 반복되면 결국 동일한 테스트 사례에서 더 이상 새로운 버그를 찾을 수 없게 됩니다.

3) 농약 역설

농사를 짓는 동안 곤충을 박멸하기 위해 동일한 농약 혼합물을 반복적으로 사용하면 시간이 지남에 따라 곤충이 농약에 대한 저항성을 갖게 되어 곤충에 대한 농약의 효과가 없게 됩니다. 소프트웨어 테스트에도 동일하게 적용됩니다. 동일한 세트의 반복 테스트가 수행되면 해당 방법은 새로운 결함을 발견하는 데 쓸모가 없습니다.

이를 극복하려면 테스트 사례를 정기적으로 검토하고 수정해야 하며, 더 많은 결함을 찾는 데 도움이 되는 새롭고 다양한 테스트 사례를 추가해야 합니다.

테스터는 단순히 기존 테스트 기술에 의존할 수 없습니다. 그는 테스트를 더욱 효과적으로 만들기 위해 기존 방법을 개선하기 위해 지속적으로 노력해야 합니다. 그러나 이 모든 땀과 노력을 테스트한 후에도 제품에 버그가 없다고 주장할 수는 없습니다. 이 점을 이해하기 위해 공개 출시에 대한 이 비디오를 보겠습니다. Windows 98

당신은 회사가 다음과 같다고 생각합니다 MICROSOFT OS를 철저하게 테스트하지 않았을 것이며 공개 출시 중에 OS가 충돌하는 것을 보는 것만으로도 평판이 위험해질 것입니다!

4) 테스트 결과 결함이 있는 것으로 나타났습니다.

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

하지만 더욱 열심히 일하고 모든 예방 조치를 취하여 소프트웨어 제품을 99% 버그 없는 상태로 만든다면 어떨까요? 그리고 소프트웨어는 클라이언트의 요구 사항과 요구 사항을 충족하지 않습니다.

이는 오류의 부재라는 다음 원칙으로 이어집니다.

5) 오류의 부재 – 오류

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

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

6) 초기 테스트

조기 테스트 – 테스트는 소프트웨어 개발 수명 주기에서 가능한 한 일찍 시작되어야 합니다. 요구 사항이나 설계 단계의 모든 결함을 초기 단계에서 포착합니다. 테스트 초기 단계에서 결함을 수정하는 것이 훨씬 저렴합니다. 하지만 얼마나 일찍 테스트를 시작해야 할까요? 요구사항이 정의되는 순간부터 버그 찾기를 시작하는 것이 좋습니다. 이 원칙에 대한 자세한 내용은 later 훈련 튜토리얼.

7) 테스트는 상황에 따라 다릅니다.

테스트는 상황에 따라 다릅니다. 즉, 기본적으로 전자 상거래 사이트를 테스트하는 방식은 상용 애플리케이션을 테스트하는 방식과 다릅니다. 개발된 모든 소프트웨어는 동일하지 않습니다. 애플리케이션 유형에 따라 다양한 접근 방식, 방법론, 기술 및 테스트 유형을 사용할 수 있습니다. 예를 들어, 소매점의 POS 시스템 테스트는 ATM 기계 테스트와 다릅니다.

통념: “원칙은 참고용일 뿐입니다. 나는 그것을 실제로 사용하지 않을 것입니다.”

이것은 매우 사실이 아닙니다. 테스트 원리는 효과적인 테스트를 만드는 데 도움이 됩니다. Test Strategy 초안 오류 잡기 테스트 케이스.

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

처음에 운전을 배우면서 기어 변속, 속도, 클러치 핸들링 등 모든 것에 주의를 기울이게 됩니다. 그러나 경험이 쌓이면 나머지는 자연스럽게 운전에만 집중하게 됩니다. 심지어 차에 탄 다른 승객들과도 대화를 나눌 수 있습니다.

테스트 원리도 마찬가지입니다. 경험이 풍부한 테스터들은 이러한 원칙을 아무 생각 없이 적용할 정도로 내재화시켰습니다. 따라서 원칙이 실제로 사용되지 않는다는 신화는 사실이 아닙니다.