테스트를 중단 할시기를 아는 방법?

나는 이것이 매우 기본적인 질문이라는 것을 알고 있습니다. 일부 소프트웨어 응용 프로그램의 경우 응용 프로그램에 대해 거의 무한히 많은 테스트 사례가 있습니다. 모든 테스트 사례를 테스트하는 것은 실용적이지 않습니다. 테스트를 중단 할 시점을 어떻게 결정합니까? ( "돈이 다 떨어질 때"이외).

Glenford Myers의 저술 The Software of Software Testing 에는 다음과 같은 간단하지만 원칙적인 규칙이 있습니다. 버그 찾기를 중단하면 테스트가 완료됩니다. 또는보다 실질적으로 새 버그를 찾는 속도가 크게 느려질 때.

버그는 특정 모듈과 특정 기능에서 "클러스터"되는 경향이 있습니다. 하나의 버그를 발견하는 순간, 더 많은 버그를 찾기 위해 더 자세히 조사해야한다는 것을 알고 있습니다. 버그를 찾기 위해 블랙 박스 테스트, 화이트 박스 테스트 및 돌연변이 테스트 기술 을 사용할 수 있습니다 . 버그를 발견하는 한 테스트 프로세스가 작동한다는 것을 알고 있습니다!

진행 상황을 시각화하려면 팀에서 하루에 발견 한 버그 수를 도표로 표시하십시오. 차트가 아래로 기울어지면 팀에서 사용하는 기술이 해당 기술을 찾지 못할 것입니다. 물론, 당신의 기술이 동등하지 않다고 생각한다면 Myers의 책을 읽고 원리를 적용하십시오.

이제 새로운 버그 패치를 놓칠 수 없을 가능성이 있으며 조금 더 테스트를 계속하면 버그 찾기 속도가 크게 증가했을 것입니다. 그러나 기술이 적절하다고 생각되는 경우에는 그럴 가능성이 없습니다.

간단한 대답은 시스템에 따라 다릅니다. 심장 모니터 용 내장 소프트웨어 또는 원자로 용 안전 모니터링 도구를 작성하는 경우 블로그 플랫폼을 작성하는 것보다 표준이 훨씬 높습니다.

이것은 실제로 훌륭한 시스템 테스터 (그리고 나는 하나가 아닙니다)에 대한 질문이지만 샷을 줄 것입니다.

기본 측정은 테스트 범위가 될 것입니다 : 실제로 테스트 된 응용 프로그램의 양 (단위 테스트 및 기능 모두).

실제 사용 가능성 (가장 까다로운 사례가있을 수 있음), 복잡성 (버그가 포함될 가능성이 적거나 하드가 포함될 가능성이 적은 경우)에 대해 각각의 잠재적 유스 케이스 (및 해당 유스 케이스의 매개 변수)를 평가해야합니다. 버그 발견), 테스트 비용 (시간 측면에서) 및 결함이 해당 영역에서 발견되면 결함의 잠재적 영향 (원자로 대 블로그 플랫폼이 제공되는 곳).

이 평가를 기반으로 테스트 할 대상과 세부 사항을 파악해야합니다. 팀 (제품 관리자 / 프로젝트 관리자 / 사용자 담당자 포함)과 같은 목록이 있으면 해당 목록을 살펴보고 가지고있는 제약 조건에 따라 우선 순위를 지정할 수 있습니다.

고려해야 할 유용한 기술 중 하나는 각 릴리스에서 테스트되는 사용 사례를 다양하게 변경할 수 있다는 것입니다. 예를 들어 중요하지 않은 테스트 사례 목록이 있고 그중 절반을 한 릴리스로 테스트하고 다른 하나는 다음 릴리스로 테스트 할 수 있습니다 (대체). 이렇게하면 회귀 버그가 발생할 위험이 있지만 노력으로 얻을 수있는 총 테스트 범위를 늘리게됩니다.

또한 두 개의 데이터베이스 백엔드 (또는 여러 브라우저)를 지원하는 경우 하나의 앱에서 절반을 테스트하고 다른 절반은 다른 애플리케이션에서 테스트 한 다음 다음 릴리스를 교체하면 플랫폼 테스트로 확장 될 수 있습니다.

(이것은 스트라이핑이라고하지만 그에 대해 인용하지는 않습니다.)

그리고 마지막으로 고려해야 할 것은 테스트 대상이 아니라 문제가 발견 될 때 실제로 수정 한 것입니다. "모든 버그 수정"이라고 말하는 것이 일반적이지만 실제로는 시간이 걸리고 모든 버그가 같은 것은 아닙니다. 다시 말하지만 모든 관련 당사자와의 정기적 인 버그 제거가 최선의 방법입니다. 이는 버그 수정이 생성하는 재 테스트 및 회귀 테스트의 추가 작업이 수정의 이점을 능가 할 수 있으므로 버그 수정이 특히 방해가되는 경우 특히 중요합니다.

소프트웨어 사용과 관련된 위험이 허용 가능한 수준으로 감소 된 경우

"프로그램 테스트는 버그의 존재를 보여주기 위해 사용될 수 있지만, 그들의 부재를 나타내지는 않습니다!" -에 제르 디크 크라

자동화 또는 기타 테스트를 수행 할 때 명심해야 할 점이 있습니다. 더 이상 버그를 발견하지 않고 더 이상 버그를 발견하지 못했음을 증명할 수 있습니다.

그러나 코드 섹션에 눈을 많이 넣을수록 올바른 작동에 대해 더 자신감을 가질 수 있습니다. 그 점에서 최적화에 대한 Knuth의 인용문과 매우 흡사합니다 : 잘못된 것을 매우 쉽게 테스트 할 수 있으며 개발시 잘못된 시간에 테스트 할 수 있습니다.

본질적으로, 당신은 두 가지 큰 장소에서 다루기를 원합니다.

1. 소프트웨어가 지정된 요구 사항을 충족하는지 입증하는 BDD 테스트를 통과합니까? 이것이 사실이 아닌 경우 소프트웨어를 완료라고 할 수도 없습니다.

2. 가장 중요하고 복잡하며 확실하지 않은 세그먼트에는 자신감을 제공하기위한 적절한 테스트가 있습니까? 그것이 핵심 루프이거나 최적화하거나 해킹해야 할 것이면 테스트를 해보십시오. 복잡하고 논리적으로 많은 분할이있는 경우 많은 테스트를 수행하십시오. 단위 테스트를 할 수 없거나 실제로 직접 테스트하기에는 너무 깊게 포함되어있는 경우 : 코드를 검토하고 코드를 직접 테스트해야합니다.

프로젝트가 끝날 때까지 기다리면 실제로 많은 테스트 사례가 생깁니다. 소규모 배송에 중점을두고 지속적으로 제공하는 경우 각 반복마다 테스트 사례가 적고 모든 것을 테스트 할 수 있습니다. 소량 배송을 할 수없는 경우 우선 순위를 정하고 가장 우선 순위가 높은 테스트를 시작한 다음 중지 할 때까지 테스트를 진행하십시오.

단위 테스트에 대해 이야기하고 TDD를 수행하는 경우 (테스트를 먼저 작성) 이것은 문제가되지 않습니다. 기능이 완료되면 테스트를 중단하면됩니다.

증분 TDD에서는 실패한 테스트를 작성한 다음 통과 할 수있는 최소량의 코드를 구현 한 다음 리팩터링합니다. 분석법이 완성 될 때까지이 방법으로 테스트를 추가하십시오.

여기 좋은 예가 있습니다.

통계 학자들은 또한 실제로 1970-80 년대 초에이 문제를 살펴 보았습니다. 버그 발견 방법에 대한 적절한 가정이 주어지면 테스트 데이터에서 버그 수를 추정하려고 시도합니다. 그런 다음 손실 기능 최적화를 기반으로 중지시기를 결정하는 데 사용됩니다. 예를 들어 https://rpubs.com/hoehle/17920 ...을 참조하십시오 . 실제로이 작업을 수행하는 방법에 대한 R 코드를 포함 하여이 문제에 대한 논문 중 하나를 간략하게 처리합니다.

물론 하나의 문제는 항상 버그 발견 프로세스에 대한 가정입니다. 예를 들어, 위의 처리에서 버그는 서로 독립적으로 발견된다고 가정합니다. 실제로, 하나의 큰 버그를 수정하면 새로운 버그 등이 발생할 수 있습니다. 그러나 그것은 시작을 제공하고 내장 감을 보완합니다.

배송일이 도착했을 때. 소프트웨어 테스트는 끝이 없습니다. 그러나 다시 일정이라는 것이 있습니다. 예정된 시간에 대부분의 기능을 테스트하고 발생하는 버그를 수정해야합니다. 소프트웨어가 완벽하다는 것을 보장 할 수있는 방법은 없습니다.

가장 먼저 테스트해야 할 것은 "행복한 길", 중요한 경우 및 잘못된 입력입니다. 동시 사용자가 둘 이상인 경우 잠금 및 경쟁 조건과 같은 동시성 문제를 테스트해야합니다. 앱이 외부 리소스를 사용하는 경우 해당 리소스를 사용할 수 없을 때 앱의 작동 방식을 테스트해야합니다. 그런 다음 코드를 사용하여 코드가 깨져 테스트 할 수있는 것을 찾을 수 있습니다. 모든 테스트가 통과되면 추가 테스트의 비용 / 혜택 비율이 증가하기 시작하여 그 시점에서 중단하는 것이 합리적입니다.

그것은 모두 자신감의 문제로 귀결됩니다. 시스템이 충분히 테스트되었다고 확신하십니까?

분명히, "신뢰 수준"은 완전히 확신 할 수는 없지만 충분히 확신 할 수 있기 때문에 매우 주관적입니다. 이것이 바로 우리가 찾고있는 것입니다. 이를 위해서는 일반적으로 완료의 정의로 알려진 지표 목록을 작성 해야하며 팀 전체가 동의 한 것이어야합니다.

다음은 몇 가지 테스트 관련 "완료 표시기"입니다.

• 빌드 및 설치가 완전히 자동화되고 모든 테스트 (단위, GUI, 통합)가 자동으로 실행됩니까?
• 코드를 작성하는 동안이나 나중에 작성하지 않고 테스트를 작성합니까?
• 버그를 도입하지 않고 큰 코드 리팩토링을 수행 할 수있을 정도로 안전하다고 생각하십니까?
• 코드 적용 수준이 충분히 높습니까?
• 팀에 전담 테스터가 있습니까? 끝이 아니라 전체 개발 과정에서 매일 관여합니까?
• 테스터가 수동으로 (탐사) 성공하지 못한 상태로 테스트를 시도 했습니까?

이 점을 확인할 수 있다면 충분히 테스트했다고 말할 수 있습니다.

절대로 시스템에서 테스트를 끝내지 않을 것이라고 생각합니다. 관리 할 수없는 변수가 너무 많습니다.

그러나 우리가 알고 있듯이 "영원히"테스트 할 수 없으므로 한계는 기본적으로 다음에 달려 있다고 생각합니다.

• 소프트웨어 사용과 관련된 위험이 허용 가능한 수준으로 감소 된 경우 (@Graham Lee가 말한 것처럼)
• 시스템 사용자는 누구입니까? 그것은 당신이나 미국 대통령 일 수 있습니다. 첫 번째 경우 버그를 해결하고 버그를 해결하여 버그가 나타나면 크게 신경 쓰지 않습니다. 두 번째 경우에는 어떤 버그도 표시하고 싶지 않습니다.
• 고객과의 관계는 무엇입니까? 아마도 고객이 당신의 아빠 일 것이므로 그렇게 끔찍하지는 않을 것입니다.
• 시스템 사용자에게는 버그가 얼마나 심각합니까? 3 차 세계 대전이나 추악한 메시지를 유발할까요?

배포시 사인 오프해야하는 사람들이 만족할 때

또는 일부 경우 책임 당사자의 대다수가 만족합니다.