단위 및 통합 테스트를위한 별도의 코드 범위 보고서 또는 둘 다에 대한 하나의 보고서?


10

단위 및 통합 테스트에 대해 별도의 코드 적용 범위 보고서가 있어야합니까, 아니면 둘 다에 대해 하나의 코드 적용 범위 보고서가 있어야합니까?

코드 적용 범위를 통해 코드가 가능한 한 테스트를 통해 적용되도록 할 수 있다는 생각이 있습니다.

단위 테스트에서 다루지 않은 것과 통합 테스트에서 다루지 않은 것을 알기 위해 별도의 보고서를 작성하는 것이 더 편리합니다. 그러나이 방법으로 총 커버리지 비율을 볼 수 없습니다.


1
나는 따로 통통 할 것이다. 테스트 방법을 모른 채 "코드가 테스트되었다"고 말하는 것만으로는 충분하지 않다고 생각합니다. 단위 테스트 및 통합 테스트는 동일한 코드를 사용하지만 다른 방식으로 예를 들어 단위 테스트는 엣지 케이스 값을 사용하고 통합은 중간 ( "현실적인") 값을 사용합니다. 동일한 코드, 매우 다른 테스트.
Mawg에 따르면 Monica Monica는

우리는 정확히 이런 이유로 단위 테스트와 통합 테스트를 별도의 라이브러리에 보관합니다.
Robbie Dee

고객의 요구 사항에 따라 다릅니다.
mouviciel

답변:


12

무엇보다도, 당신은 결합 된 (총) 커버리지를 가지고 분석해야합니다. 당신이 그것을 생각한다면, 이것은 당신의 위험을 적절하게 우선시하고 테스트 개발 노력에 집중하는 가장 자연스러운 방법입니다.

결합 된 범위는 어떤 코드가 테스트 포함되지 않는지 보여줍니다 . 즉 가장 위험하며 먼저 조사해야합니다. 별도의 적용 범위 보고서는 여기에서 도움이되지 않습니다.이 코드를 사용하면 코드가 다른 방식으로 테스트되었는지 전혀 테스트되지 않았는지 확인할 수 없습니다.


개별 적용 범위 분석도 유용 할 수 있지만 결합 분석을 수행 한 후에 수행하는 것이 좋으며 결합 된 범위 분석 결과도 포함하는 것이 좋습니다.

개별 범위 분석의 목적은 결합 된 범위와 다릅니다. 별도의 커버리지 분석은 테스트 스위트의 디자인을 개선하는 데 도움이되며, 테스트 대상을 결정하기위한 결합 된 커버리지의 분석과는 달리, 테스트 범위를 분석합니다.

"오히려이 간극은 간단한 단위 (통합) 테스트를 단위 (통합) 제품군에 추가하는 것을 잊어 버렸기 때문에 다루지 않습니다."-분리 된 범위와 분석은 여기에서 가장 유용합니다. 특정 제품군에서 다루고 싶을 것입니다.

상기 관점에서, 까다로운 경우를 분석하기 위해 결합 된 커버리지 분석의 결과를 갖는 것이 여전히 바람직하다. 이러한 결과를 통해 "파트너"테스트 스위트에 대한 정보가 있으므로 테스트 개발 결정이 더 효율적일 수 있습니다.

"여기에 차이가 있지만,이를 다루기 위해 단위 (통합) 테스트를 개발하는 것은 정말 번거로울 것입니다. 옵션은 무엇입니까? 결합 된 범위를 확인합시다 ... 이미 다른 곳에서 다룹니다. "중요하게 중요합니다."



5

테스트 도구는 언급하지 않았습니다. 다수의 런 또는 스위트 결과를 집계 할 수있는 "결합"기능이 있습니다. 집계 적용 범위 메트릭을 원하면 적용 범위 도구의 결합 기능을 탐색하십시오.


이제 방에있는 코끼리에 대해 이야기 할 수 있습니까?

숟가락이 없다. 그리고 "총 적용률"은 없습니다. 최소한 간단한 것은 없습니다.

적용 범위 백분율은 테스트 스위트의 범위, 깊이 및 범위를 이해하는 데 도움이되도록 쉽게 이해할 수있는 지표입니다. 그러나 단순한 벤치 마크와 마찬가지로, "완전한 테스트"라는 일종의 마법 부적처럼이 값을 목표로 고정 하는 것은 매우 쉽습니다 .

"100 % 테스트 범위"의 영광을 달성했다고 가정 해 봅시다. 예이! 그러나 그것은 무엇을 의미합니까? 코드 라인의 100 %가 테스트 되었습니까? 그렇다면이 라인은 어떻습니까?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

있는 다양한 조건이 있기 때문에,하지만 훨씬 - 그 라인 수단 뭔가 "를 다루는" True또는 False약간의 확률로, 그러나 당신이 이러한 조건의 모든 조합을 테스트 한 가능성이다. 해당 라인이 수십 번 적용 되더라도 조건 중 하나가 상대적으로 드문 경우 실제로 발생할 수있는 실제 결과를 모두 테스트하는 것은 아닙니다. 더 명확하고 합성적인 예를 들면 다음과 같습니다.

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

실제로 철저하게 테스트하려면 해당 라인을 몇 번 덮어야합니까? 프로그램의 다른 모든 변수 (자체적으로 비슷하거나 드물게) 확률과 함께 테스트하기 위해 몇 번을 다루어야합니까?

커버리지 메트릭이 쓸모 없다고 말하지 않습니다. 그들은 실제로 훌륭 합니다. 주요 문제 중 하나에 중점을 둡니다. 소프트웨어 시스템은 얼마나 광범위하게 테스트됩니까? 그들은 "우리는 몇 가지 테스트가 있습니다"에서 "우리는 철저히 테스트했습니다"로 이동하는 데 도움이됩니다.

그러나 "결합 된 점수"로 작업하는 동안 실제로는 점수가 일반적으로 "조건", "조건 자"또는 "경로"범위가 아닌 "표기 범위"에 대한 점수입니다 . 따라서 총점에서 얻은 숫자에 관계없이 테스트 가능한 상태 및 상태 조합의 양을 실제로 파악할 수는 없습니다. 커버리지 비율을 높이는 동안 술어 커버리지도 측정하십시오. 테스트의 광범위성에 대해보다 현실적이고 거의 변치 않는 견해를 제공합니다.


사용되는 적용 범위 메트릭의 유형은 해당 질문과 완전히 직교하는 것으로 보이며 모든 메트릭은 단위 테스트 또는 통합 테스트 또는 둘 다
jk에

확실한. 같은 방법으로 사용중인 차량의 종류와 관계없이 직각으로 "연료 당 마일 (연료)"을 계산할 수 있습니다. 나는 무거운 리프트 부스터 로켓, 장거리 트럭 및 이코노미 카의 결과를 병합하면 잘못된 콤보 메트릭스를 제공한다고 주장합니다. 어떤 목적으로도 "함대에 걸쳐"그림을 계속 사용할 수 있다고 생각합니다.
Jonathan Eunice

흥미롭지 만 주제를 약간 벗어난 답변 .... 어쨌든 찬성했습니다!
HDave
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.