예제를 통한 소프트웨어 테스팅의 7가지 원칙
토마스 해밀턴
소프트웨어 테스팅의 7가지 원칙
1) 철저한 테스트는 불가능하다
2) 결함 ClusterING
3) 농약 역설
4) 테스트 결과 결함이 있음이 확인되었습니다.
5) 오류의 부재 – 오류
6) 초기 테스트
7) 테스트는 상황에 따라 다릅니다.
다음을 통해 테스트 원칙을 알아 보겠습니다. 비디오 예-
LINK 비디오에 접근할 수 없는 경우
배경
소프트웨어 테스트를 수행하는 동안 목표에서 벗어나지 않고 최적의 테스트 결과를 얻는 것이 중요합니다. 하지만 테스트를 위한 올바른 전략을 따르고 있는지 어떻게 판단할 수 있을까요? 그러기 위해서는 몇 가지 기본 테스트 원칙을 고수해야 합니다. 소프트웨어 산업에서 널리 실천되는 일반적인 7가지 테스트 원칙은 다음과 같습니다.
이를 이해하려면 폴더 A에서 폴더 B로 파일을 이동하는 시나리오를 생각해 보세요.
이를 테스트할 수 있는 가능한 모든 방법을 생각해 보십시오.
일반적인 시나리오 외에도 다음 조건을 테스트할 수도 있습니다.
- 파일이 열려 있는 상태에서 파일을 이동하려고 합니다.
- 폴더 B에 파일을 붙여넣을 수 있는 보안 권한이 없습니다.
- 폴더 B가 공유 드라이브에 있고 저장 용량이 가득 찼습니다.
- 폴더 B에는 이미 같은 이름의 파일이 있습니다. 실제로 목록은 끝이 없습니다.
- 또는 테스트할 입력 필드가 15개 있고 각 필드에 가능한 값이 5개 있다고 가정하면 테스트할 조합 수는 5^15입니다.
가능한 전체 조합 프로젝트를 테스트한다면 실행 시간과 비용이 기하급수적으로 늘어날 것입니다. 테스트 노력을 최적화하려면 특정 원칙과 전략이 필요합니다.
7가지 원칙은 다음과 같습니다.
1) 철저한 테스트는 불가능하다
예! 철저한 테스트는 불가능합니다. 대신, 애플리케이션의 위험 평가를 기반으로 최적의 테스트 양이 필요합니다.
그리고 백만 달러짜리 질문은 이 위험을 어떻게 결정하는가입니다.
이에 답하기 위해 연습을 해보겠습니다.
귀하의 의견으로는 어떤 작업이 귀하의 문제를 일으킬 가능성이 가장 높습니까? Opera시스템이 실패할 것 같나요?
나는 여러분 대부분이 동시에 10개의 다른 응용 프로그램을 여는 것을 짐작했을 것이라고 확신합니다.
그래서 이것을 테스트하고 있다면 Opera시스템을 사용하면 멀티 태스킹 활동에서 결함이 발견될 가능성이 높으며 철저한 테스트를 거쳐 다음 원칙을 제시해야 한다는 사실을 깨닫게 될 것입니다. 결함 ClusterING
2) 결함 ClusterING
결함 Cluster이는 소수의 모듈에 감지된 결함의 대부분이 포함되어 있음을 나타냅니다. 이는 소프트웨어 테스팅에 파레토 원리를 적용한 것입니다. 문제의 약 80%가 모듈의 20%에서 발견됩니다.
경험을 통해 이러한 위험한 모듈을 식별할 수 있습니다. 하지만 이 접근 방식에는 문제가 있습니다.
동일한 테스트가 계속해서 반복되면 결국 동일한 테스트 사례에서 더 이상 새로운 버그를 찾을 수 없게 됩니다.
3) 농약 역설
농사를 짓는 동안 곤충을 박멸하기 위해 동일한 농약 혼합물을 반복적으로 사용하면 시간이 지남에 따라 곤충이 농약에 대한 저항성을 갖게 되어 곤충에 대한 농약의 효과가 없게 됩니다. 소프트웨어 테스트에도 동일하게 적용됩니다. 동일한 세트의 반복 테스트가 수행되면 해당 방법은 새로운 결함을 발견하는 데 쓸모가 없습니다.
이를 극복하려면 테스트 사례를 정기적으로 검토하고 수정해야 하며, 더 많은 결함을 찾는 데 도움이 되는 새롭고 다양한 테스트 사례를 추가해야 합니다.
테스터는 단순히 기존 테스트 기술에 의존할 수 없습니다. 그는 테스트를 더욱 효과적으로 만들기 위해 기존 방법을 개선하기 위해 지속적으로 노력해야 합니다. 그러나 이 모든 땀과 노력을 테스트한 후에도 제품에 버그가 없다고 주장할 수는 없습니다. 이 점을 이해하기 위해 공개 출시에 대한 이 비디오를 보겠습니다. Windows 98
마이크로소프트 같은 회사가 자사 OS를 철저히 테스트하지 않아 공식 출시 중에 OS가 충돌하는 걸 보고만 명예를 걸었을 거라고 생각하세요!
4) 테스트 결과 결함이 있는 것으로 나타났습니다.
따라서 테스트 원칙은 다음과 같이 명시합니다. 테스트는 결함의 존재에 대해 이야기하고 결함의 부재에 대해 이야기하지 않습니다. 즉, 소프트웨어 테스팅 소프트웨어에 발견되지 않은 결함이 남아 있을 가능성을 줄입니다. 그러나 결함이 발견되지 않더라도 정확성의 증거는 아닙니다.
하지만 더욱 열심히 일하고 모든 예방 조치를 취하여 소프트웨어 제품을 99% 버그 없는 상태로 만든다면 어떨까요? 그리고 소프트웨어는 클라이언트의 요구 사항과 요구 사항을 충족하지 않습니다.
이는 오류의 부재라는 다음 원칙으로 이어집니다.
5) 오류의 부재 – 오류
99% 버그가 없는 소프트웨어는 여전히 사용할 수 없을 수도 있습니다. 이는 잘못된 요구 사항에 대해 시스템을 철저하게 테스트한 경우에 해당될 수 있습니다. 소프트웨어 테스팅은 단순히 결함을 찾는 것이 아니라 소프트웨어가 비즈니스 요구 사항을 충족하는지 확인하는 것이기도 합니다. 오류가 없다는 것은 오류입니다. 즉, 시스템 빌드가 사용할 수 없고 사용자의 필요와 요구 사항을 충족하지 못하는 경우 결함을 찾아서 수정하는 것은 도움이 되지 않습니다.
이 문제를 해결하기 위해 테스트의 다음 원칙은 Early Testing입니다.
6) 초기 테스트
초기 테스트 - 테스트는 소프트웨어 개발 수명 주기에서 가능한 한 일찍 시작해야 합니다. 그래야 요구 사항이나 설계 단계의 모든 결함이 초기 단계에서 포착됩니다. 테스트 초기 단계에서 결함을 수정하는 것이 훨씬 저렴합니다. 하지만 얼마나 일찍 테스트를 시작해야 할까요? 요구 사항이 정의된 순간부터 버그를 찾기 시작하는 것이 좋습니다. 이 원리에 대한 자세한 내용은 이후 교육 튜토리얼에서 설명합니다.
7) 테스트는 상황에 따라 다릅니다.
테스트는 상황에 따라 다릅니다. 즉, 기본적으로 전자 상거래 사이트를 테스트하는 방식은 상용 애플리케이션을 테스트하는 방식과 다릅니다. 개발된 모든 소프트웨어는 동일하지 않습니다. 애플리케이션 유형에 따라 다양한 접근 방식, 방법론, 기술 및 테스트 유형을 사용할 수 있습니다. 예를 들어, 소매점의 POS 시스템 테스트는 ATM 기계 테스트와 다릅니다.
통념: “원칙은 참고용일 뿐입니다. 나는 그것을 실제로 사용하지 않을 것입니다.”
이것은 매우 사실이 아닙니다. 테스트 원리는 효과적인 테스트를 만드는 데 도움이 됩니다. Test Strategy 초안 오류 잡기 테스트 케이스.
그러나 테스트 원리를 배우는 것은 처음으로 운전하는 법을 배우는 것과 같습니다.
처음에는 운전을 배우는 동안 기어 변속, 속도, 클러치 핸들링 등 모든 것에 주의를 기울입니다. 하지만 경험이 쌓이면 운전에만 집중하게 되고 나머지는 자연스럽게 따라옵니다. 차에 탄 다른 승객과 대화도 나눌 수 있을 정도입니다.
테스트 원리도 마찬가지입니다. 경험이 풍부한 테스터들은 이러한 원칙을 아무 생각 없이 적용할 정도로 내재화시켰습니다. 따라서 원칙이 실제로 사용되지 않는다는 신화는 사실이 아닙니다.
