나의 마지막 블로그 항목 범주 플랫폼에 대한 기본 설정을 테스트하기 위해 커버링 배열을 사용하여 설명했습니다. 모든 테스트가 통과된다는 희망이 있지만,이 블로그에서는 이러한 테스트 중 하나가 실패 할 때 우리가 할 수있는 일을 고려합니다. Covering Array 플랫폼에서 디자인을 만든 후 "Make Table"을 사용하면 "Response"레이블이 붙은 첫 번째 열과 "Analysis"테이블 스크립트가주의를 기울여야합니다. 응답 열은 1과 0의 값을 사용하여 측정중인 내용에 따라 특정 실행이 성공했는지 여부를 나타냅니다. 범주 형 플랫폼의 경우 플랫폼이 예상대로 작동하면 값 1이 기록되고 오류가 있으면 0이 기록됩니다. 응답 열이 채워지면 "분석"스크립트가 사용됩니다.
테스트를 수행 할 때 이상적으로 응답 열에있는 모든 1을 관찰합니다. 제공된 데이터 표에서 파일 교환 , 나는 약간의 가설적인 데이터를 조사했고 수집했다 : 마지막 하나를 제외하고 실행의 각각은 건네 줬다. 이 실패로 우리는 무엇을합니까? 잠재적 인 원인을 좁히는 것이 좋을 것입니다.
분석
원인을 찾는 첫 번째 장소는 단일 요인으로 인해 실패가 발생할 수있는 경우입니다. 각 환경 설정 옵션은 둘 이상의 행에서 발생하고 다른 모든 옵션은 전달되므로이 문제를 일으키는 유일한 요소는 아닙니다. 다음 가능성있는 후보는 2 가지 옵션이 될 수 있습니다. 우리는이 행에 2 = 990 개의 다른 2 옵션 조합을 선택했습니다. 그건별로 유익하지 않은 것 같습니다. 그러나 이러한 조합 중 많은 부분이 설계의 다른 부분에 나타나며 플랫폼이 이러한 테스트를 통과하므로 잠재적 인 원인으로이를 제거 할 수 있습니다. 잠재적 인 원인 목록을 검토하고 다른 곳에 나타난 문제를 제거하면 지루한 작업이됩니다. 이는 Analysis 스크립트가 우리를 위해 처리하는 것입니다. 해당 스크립트 실행 :
분석 보고서는 실패의 잠재적 인 원인을 보여줍니다. 실패한 행이 포함 된 행 990 쌍에서 크게 줄어 듭니다. 또한 검사가 쌍으로 이루어 지도록 단순화되었습니다.
어떤 종류의 정보라도이 프로세스를 훨씬 쉽게 만들 수 있습니다. 이 예에서 테스터는 "ChiSquare 테스트 선택 사항"이 최근에 업데이트되었고이 두 가지 사례를 먼저 볼 수 있다는 사실을 알고 있습니다. 잠재적 인 원인 중 하나를 클릭하면 실패 행과 해당 열이 강조 표시됩니다. 많은 행 및 / 또는 열을 다루고 있고 테이블을 서브 세트 할 수있는 빠른 방법을 원할 때 유용합니다.
마지막 생각들
우리는 불가능한 것처럼 보인 테스트 환경의 테스트에서 불과 16 회의 런닝으로 합당한 커버리지를 얻은 테스트를 진행했습니다. 강도 3 커버링 어레이를 작성하여 더욱 발전 할 수있었습니다. 최적화를 통해 65 회 실행 (4 커버리지 96 % 이상)이 가능한 디자인을 발견했습니다. 일부 조합을 함께 실행할 수없는 제약 조건은 허용되지 않는 조합으로도 수용 될 수 있습니다. 자신의 작업에서 커버링 어레이를 사용하는 행운? 내게 의견을 남겨주세요. 읽어 주셔서 감사합니다!
