25 년 전에 테스트 컴퓨터 소프트웨어의 대부분을 썼습니다. 나는 그 책이 구식이거나 단순히 잘못되었다고 생각하는 여러 부분을 지적했다. http://www.kaner.com/pdfs/TheOngoingRevolution.pdf를 참조 하십시오
내 사이트에서 블랙 박스 소프트웨어 테스팅 코스 (비디오 및 슬라이드 무료 제공), www.testingeducation.org/BBST에 대한 추가 정보 (현재보기는 있지만 TCS에 대한 명시적인 포인터는 없음)를 볼 수 있습니다.
당시의 테스트 문화는 크게 확증되었습니다.
현대식 테스트에서는 단위 테스트에 대한 접근 방식이 크게 확인됩니다. 소프트웨어가 의도 한대로 계속 작동하는지 확인하는 자동화 된 테스트 모음을 작성합니다. 테스트는 코드의 다른 부분에 문제가 있거나이 부분에 문제가 있거나 실제 세계에서는 불가능했던 데이터 값이 현재 응용 프로그램에 도달하면 변경 감지기로 작동합니다. 유지 보수 문제에 프로그래머.
나는 확인 사고 방식이 단위 테스트에 적합하다고 생각하지만 모든 시스템 테스트가 확인 된 세계를 상상하십시오 (구별을하는 사람들의 경우 시스템에 대한 의견에 포함 된 "시스템 통합 테스트"및 "수락 테스트"를 해석하십시오) 테스트 시점은 프로그램이 사양을 충족하는지 확인하는 것이 었으며, 지배적 인 접근 방식은 사양의 일부를 프로그램의 동작에 매핑하는 시스템 수준의 회귀 테스트를 구축하는 것이 었습니다. (사양 별 행동 확인이 유용하다고 생각하지만 더 큰 목표의 작은 부분이라고 생각합니다.)
이런 식으로 작동하는 테스트 그룹이 여전히 있지만 더 이상 지배적 인 관점은 아닙니다. 당시는 그랬습니다. 나는이 사고 방식을 꾸준히 훈련 받고있는 사람들을 강조하기 위해 강조하면서 명쾌한 대조를 그렸다. 오늘날 일부 명암 대비 (여기 인용 된 것 포함)는 구식입니다. 그들은 잘못된 견해에 대한 공격으로 잘못 해석됩니다.
내가 알다시피, 소프트웨어 테스팅은 소프트웨어 제품이나 서비스에 대한 품질 관련 정보를 배우기위한 경험적 과정이다.
유용한 정보를 공개하도록 테스트를 설계해야합니다.
그때까지, 아무도 "정보"를 드러내는 방법으로서 테스트에 대해 이야기 한 사람은 없었습니다. 그 당시 테스트는 (일부 버전의 ...) 버그를 찾거나 (일부 버전의 ...) 사양에 대해 프로그램을 확인 (확인)하는 것이 었습니다. 나는 테스트가 유용한 정보를 드러내 기위한 주장이이 세기까지 테스트 어휘에 들어온 것으로 생각하지 않는다.
정보 가치 측면에서 등급 테스트를 상상해보십시오. 우리가 소프트웨어에 대해 알지 못하는 것을 가르쳐 줄 가능성이 높은 테스트는 정보 가치가 매우 높습니다. 우리가 이미 기대하고 이미 여러 번 입증 된 것을 확인할 가능성이 높은 테스트는 정보 값이 낮을 것입니다. 테스트 우선 순위를 정하는 한 가지 방법은 낮은 정보 값 테스트 전에 높은 정보 값 테스트를 실행하는 것입니다.
소프트웨어 우선 순위에 대해 알지 못하는 프로그래머, 프로젝트 관리자 또는 프로세스 관리자의 관심을 끌 수 있도록이 우선 순위를 지나치게 단순화하려는 경우 "버그를 해결하도록 설계된 테스트는 시간 낭비입니다" " 완벽한 번역은 아니지만 미묘함이나 자격을 이해하지 못하거나 이해하지 못하는 독자들에게는 그것이 가능한 한 가깝습니다.
당시에는 다시 한 번 보았습니다. 테스트를 이해하지 못하는 사람들 중 일부는 코너 케이스를 찾기 위해 설계된 테스트가 주요 기능의 주요 사용 테스트와 비교할 때 시간 낭비라고 응답했습니다. 그들은 두 가지를 이해하지 못합니다. 먼저, 테스터가 경계 값을 확인할 시간을 찾음에 따라 주요 기능의 주요 사용은 이미 여러 번 실행되었습니다. (예, 예외가 있으며 대부분의 테스트 그룹은 해당 예외에주의를 기울여야합니다.) 둘째, 극단적 인 값으로 테스트하는 이유는 프로그램이 극단적 인 값으로 실패 할 가능성이 높기 때문입니다. 극단적으로 실패하지 않으면 다른 것을 테스트하십시오. 이것은 효율적인 규칙입니다. 반면에 극단적 인 값으로 실패하면 테스터가 중지하여 버그를보고하거나 테스터가 추가 문제를 해결할 수 있습니다. 프로그램이 더 일반적인 값으로 같은 방식으로 실패하는지 확인하십시오. 문제 해결 담당자 (테스터 또는 프로그래머)는 기업 문화의 문제입니다. 일부 회사는이를 위해 테스터 시간을 책정하고, 일부는 프로그래머 예산을 책정하며, 일부 회사는 프로그래머가 문제를 해결할 수 있도록 일반화 여부에 관계없이 코너 버그를 수정하기를 기대합니다. 테스터가 극단적 인 값을 테스트하여 효율성을 극대화하기보다는 시간을 낭비하고 있다는 일반적인 오해는 "버그를 나타내도록 설계되지 않은 테스트가 시간 낭비"라는 또 다른 이유입니다. 일부 프로그래머가 (실제로) 프로그램에 도전 할 수있는 테스트를 실행하지 않도록 장려합니다. 메시지는 지나치게 단순화되었지만 전체 토론은 지나치게 단순화되었습니다.
그건 그렇고, "정보 가치"가 유일한 우선 순위 시스템 일 수는 없습니다. 단위 테스트 스위트를 설계 할 때는 규칙이 아닙니다. 빌드 검증 테스트 (일명 위생 검사)를 설계 할 때는 규칙이 아닙니다. 두 경우 모두 개별 테스트의 힘보다 적용 범위 유형에 더 관심이 있습니다. 개별 테스트의 힘이 내 디자인과 관련이없는 다른 경우 (예 : 설정, 실행 및 모니터링이 저렴한 대량 자동 테스트)가 있습니다. 추가 예를 생각할 수 있습니다.
그러나 일반적으로 하나의 규칙 만 명시 할 수 있다면 (예 : 한 문장 이상을 처리하려고 할 때 머리를 폭발시키는 경영진에게 말하면) 낮은 정보 가치 테스트는 일반적으로 시간 낭비입니다.