65.000.000.000 테스트 실행

나는 65.000.000.000 테스트 스위트를 실행하는 방법에 대해 질문을 받았으며 엄청난 양의 테스트가있는 프로젝트가 정상적인 지 궁금합니다.

이 특성을 가진 프로젝트에서 일했습니까?

650 억 개의 테스트를 통해 가능한 모든 입력을 테스트하라는 요청을받는 것 같습니다. 이것은 유용하지 않습니다. 코드가 정확하지 않고 프로세서가 올바르게 작동하는지 테스트해야합니다.

대신 동등성 클래스 를 테스트해야합니다 . 이렇게하면 테스트 입력 범위가 크게 줄어 듭니다.

또한 시스템을 더 작은 조각으로 세분화 할 수 있는지 고려하십시오. 각 조각은 테스트를보다 쉽게 ​​수행 할 수 있으며 모든 조각을 하나로 통합하는 통합 테스트를 수행 할 수 있습니다.

이러한 입력 조합 중 일부가 작동한다는 확신을 여전히 원한다면 퍼지 테스트를 시도해 볼 수 있습니다. 다양한 입력을 테스트 할 때 얻을 수있는 이점 중 일부는 650 억 개를 모두 실행하지 않고도 얻을 수 있습니다.

이것이 실제 테스트 스위트 인 경우, 작업을 수행하기 위해 다른 곳으로 가고 싶지 않습니다.

테스터의 전체 업무는 "올바른"결과를 얻었음을 확신 할 수있을만큼 충분히 테스트하고 합리적인 시간에 실행할 수있는 테스트를 거의 작성하지 않는 것 사이의 균형을 유지하는 것입니다.

많은 테스트를 "동등 클래스"로 추상화 할 수 있습니다. 즉, 30 억 테스트를 실행하는 대신 1을 실행하여 해당 동등 클래스의 다른 모든 테스트가 성공적으로 실행될 것이라는 확신을 줄 수 있습니다. 그들을 실행하는 시간.

650 억 개의 테스트를 실행하려는 사람은 동등 클래스로 테스트를 더 잘 추상화해야한다고 말해야합니다.

테스트중인 시스템에 가능한 모든 입력 조합을 계산하거나 순환 복잡성을 계산하고 이러한 고유 한 실행 경로 각각에 대해 테스트를 작성해야한다고 가정하면 650 억 개의 테스트에 도달했을 가능성이 높습니다.

다른 포스터와 주석가들이 지적했듯이, 650 억 을 실행하는 데 필요한 기술적 힘이 있기 때문에 이것은 실제 테스트가 작성되는 방식이 아닙니다.테스트는 엄청납니다. 이것은 두 개의 32 비트 값의 가능한 모든 순열을 연결하고 결과를 확인하여 두 개의 정수를 추가하는 방법을 연습하는 테스트를 작성하는 것과 같습니다. 완전히 광기입니다. 선을 그리고 가능한 모든 테스트 사례의 부분 집합을 식별해야하며, 그 사이에서 시스템이 입력 범위 전체에서 예상대로 작동하게됩니다. 예를 들어. "일반적인"숫자 몇 개를 테스트하고, 음수 시나리오 몇 개를 테스트하고, 오버플로 시나리오와 같은 기술 한계를 테스트하고, 오류가 발생하는 시나리오를 테스트합니다. 언급 된 바와 같이, 이러한 다양한 유형의 시험은 "동등성 등급"을 행사합니다. 알려진 "이상 값"과 함께 가능한 입력의 대표적인 샘플을 얻을 수 있습니다.

기본 코드 카타 중 하나 인 로마 숫자 생성기를 고려하십시오. "dojo"스타일의 TDD 기술을 사용하여 수행되는 작업은 1에서 3000 사이의 숫자를 허용하고 해당 숫자 값에 대한 올바른 로마 숫자를 생성하는 함수를 작성하는 것입니다.

한 번에 3000 단위 테스트를 작성하고 차례로 통과하여이 문제를 해결하지 못합니다. 미치겠 어. 운동은 일반적으로 1-2 시간이 걸리며, 각 개인의 가치를 시험하는 날이 있습니다. 대신 똑똑해집니다. 가장 간단한 기본 사례 (1 == "I")로 시작하고 "최소 코드"전략 ( return "I";) 을 사용하여 구현 한 다음 예상되는 다른 시나리오 (2 == " II "). 헹구고 반복하십시오. 아마도 초기 구현을 "I"문자를 필요한 횟수만큼 반복하는 것으로 대체했습니다 (예 return new String('I',number);:). 그것은 분명히 III 테스트를 통과 할 것이기 때문에 귀찮게하지 마십시오. 대신 4 == "IV"에 대한 테스트를 작성하면 현재 구현이

또는보다 분석적인 방식으로 코드에서 수행 한 (또는 필요한) 각 조건부 결정을 검사하고 각 결정의 가능한 각 결과에 대해 코드를 입력하도록 설계된 테스트를 작성하십시오. 5 개의 if 문 (각각 true 및 false 분기를 가짐)이 있고 각각이 완전히 독립적 인 경우, 32 개가 아닌 10 개의 테스트를 코딩합니다. 각 테스트는 특정 가능한 결정에 대해 두 가지 사항을 주장하도록 설계됩니다. 먼저 올바른 결정을 내린 다음 해당 조건에서 입력 한 코드가 올바른지 확인하십시오. 당신은 하지 않는 독립적 인 의사 결정의 각각의 가능한 순열에 대한 테스트를 코딩. 의사 결정이 종속적 인 경우, 더 많은 결정을 조합하여 테스트해야하지만 다른 결정이 특정 결과를 가질 때만 일부 결정이 내려지기 때문에 그러한 조합은 적습니다.

이것이 "정상"입니까? "정상"은 평균 또는 일반적인 경험으로 정의됩니다. 그런 프로젝트를 해본 적이 있다고 말할 수는 없지만 수백만 비트마다 하나가 뒤집히는 프로젝트를 진행하고 있습니다. 그 중 하나가 ... 도전이라는 테스트.

잠재적으로 필요한가요? 글쎄, 그것은 프로젝트의 보증과 세부 사항에 달려 있습니다. 처음에는 이해하기가 조금 믿어지지 않지만 귀하의 질문은 구체적입니다.

다른 사람들 (MichaelT)이 지적했듯이, 직렬 테스트로이 작업을 완료 할 때가 비현실적입니다. 따라서 병렬화가 첫 번째 고려 사항이됩니다. 이 문제에 대해 몇 개의 테스트 시스템을 처리 할 수 ​​있습니까? 그리고 여러 시스템의 결과를 수집하는 데 어떤 지원이 있습니까?

테스트중인 장치 또는 알고리즘이 안정적으로 복제되고 있다는 것을 어떻게 보증합니까? 소프트웨어는 복제에서 매우 안정적이지만 하드웨어 장치 (특히 1 세대)에는 제조 문제가있을 수 있습니다. 이 경우 잘못된 테스트 실패는 잘못된 알고리즘이거나 장치가 올바르게 조립되지 않았 음을 나타냅니다. 이 두 경우를 구별해야합니까?

또한 테스트 시스템 자체의 유효성을 검사하는 방법도 고려해야합니다. 많은 테스트 사례에 대한 합당한 이유를 가정하면 많은 자동화가 필요합니다. 테스트 사례 생성에 오류가 발생하지 않도록 자동화를 검사해야합니다. 오류에 대한 스팟 검사는 실제로 건초 더미에서 바늘을 찾는 것과 같습니다.

이 arstechnica 링크 는 테스트 고려 사항에 대한 통찰력을 제공하지 않을 수도 있습니다. GPU 클러스터는 일반적으로 무차별 크래킹 암호에 사용됩니다. 이 기사에서 인용 한 것은 can cycle through as many as 350 billion guesses per second65B 테스트의 관점에서 볼 수 있습니다. 다른 영역 일 수도 있지만, 다른 각도에서 작업에 접근하는 것이 어떻게 실용적인 솔루션을 얻을 수 있는지 보여줍니다.

나는 6.5e + 10 테스트를 첫 번째 로 유지 하는 것이 가능하지 않다고 생각 하므로 실행이 어려울 수 있습니다. 모든 패키지를 갖춘 데비안과 같은 가장 큰 프로젝트조차도 총 수억 개의 SLOC를 가지고 있습니다.

그러나 어쨌든 엄청난 수의 테스트를 실행해야하는 경우 몇 가지 전략이 있습니다.

• 모두 실행하지 마십시오. 모든 테스트가 모든 코드 경로에 의존하는 것은 아닙니다. 하위 시스템과 해당 테스트 및 테스트 스위트 간의 종속성을 정의하면 특정 변경과 관련된 단위 테스트 만 수행 할 수 있으며 이러한 단위 테스트에 따른 통합 테스트 만 수행 할 수 있습니다.

• 병렬로 실행하십시오. 코드 기반이 크면 대규모 빌드 팜이있을 것입니다. 비교적 작은 작업 인 JetBrains로 돌아가서 IDEA 연속 빌드 / 통합 팜에서만 40-50 개의 빌드 에이전트를 실행했습니다. 단위 테스트는 독립적이며 통합 테스트는 이미 작성된 코드를 재사용 할 수 있으므로 테스트를 비교적 쉽게 병렬화 할 수 있습니다.

• 일찍 멈춰라. 특정 테스트 스위트가 다른 테스트 스위트의 정확성에 대한 합리적인 기능에 의존한다는 것을 알고 있다면, 하나의 링크가 실패하면 전체 체인을 절단 할 수 있습니다.

면책 조항 : 저는 전문 테스트 엔지니어가 아닙니다. 소금 알갱이로 위를 가져 가라.

적은 수의 테스트로 몰래 시도하는 방법에 대한 몇 가지 좋은 제안이 있었지만 시스템에 650 억 개의 입력 조합이 있다고 의심합니다. 이는 36 비트 미만의 입력입니다. 위에서 주어진 모든 조언을 이미 받았다고 가정 해 봅시다.

각 테스트를 실행하는 데 약 밀리 초가 걸리고 테스트를 10 개의 프로세서 (일반 PC 1 대)에만 배포하는 경우 테스트는 69 일이 조금 넘게 실행됩니다. 그것은 한참이지만 완전히 불합리한 것은 아닙니다. 100 개의 프로세서 (일반 PC 12 대 또는 합리적인 서버 PC 1 대)에 배포하면 테스트는 7 일 이내에 완료됩니다. 매주 실행하여 회귀를 확인할 수 있습니다.