소프트웨어 테스트에서의 테스트 커버리지: 측정 방법

테스트 커버리지란 무엇입니까?

테스트 범위는 일련의 테스트에서 수행되는 테스트 양을 측정하는 소프트웨어 테스팅의 측정 기준으로 정의됩니다. 여기에는 조건문의 어떤 분기가 수행되었는지 확인하기 위해 테스트 스위트를 실행할 때 프로그램의 어느 부분이 실행되는지에 대한 정보 수집이 포함됩니다.

간단히 말해서 테스트가 코드를 테스트하고 있는지 또는 테스트를 실행하여 코드를 얼마나 연습했는지 확인하는 기술입니다.

테스트 커버리지란 무엇인가요?

실제 프로젝트에서 테스트 커버리지는 다음과 같은 네 가지 실질적인 활동을 지원합니다.

• 일련의 테스트 케이스에 의해 구현되지 않은 요구사항 영역 찾기
• 적용 범위를 늘리기 위해 추가 테스트 사례를 만드는 데 도움이 됩니다.
• 품질 확인을 위한 간접적인 방법인 테스트 범위의 정량적 측정 식별
• 적용 범위를 늘리지 않는 의미 없는 테스트 사례 식별

소프트웨어 엔지니어링 테스트 범위의 이점

그러한 활동들은 구체적인 공학적 이점으로 이어집니다.

• 테스트의 품질을 보장할 수 있습니다.
• 릴리스 또는 수정을 위해 실제로 코드의 어떤 부분이 터치되었는지 식별하는 데 도움이 될 수 있습니다.
• 이 기능을 사용하면 테스트되지 않은 애플리케이션의 모든 결정 지점과 경로를 파악할 수 있으므로 테스트 범위를 넓힐 수 있습니다.
• 방지 결함 누출
• 시간, 범위 및 비용을 통제할 수 있습니다.
• 프로젝트 수명주기 초기 단계의 결함 예방
• 요구사항, 테스트 사례, 단위 수준 및 코드 수준의 결함의 차이를 쉽게 찾을 수 있습니다.

테스트 커버리지 유형

커버리지는 절대 단일 숫자로 표현되지 않습니다. 팀 track는 여러 유형을 동시에 처리할 수 있는데, 각 유형이 동일한 제품군에 대한 서로 다른 질문에 답하기 때문입니다. 아래 표는 가장 자주 접하게 되는 유형들을 그룹으로 분류한 것입니다.

처음 다섯 가지 유형은 코드 수준 측정 항목이며 다음과 같습니다. 화이트 박스 테스트반면 요구사항 및 위험 범위는 테스트 계획 수준에서 다뤄집니다.

주요 차이점은 무엇입니까 Code 커버리지와 테스트 커버리지?

Code 적용 범위 테스트 범위는 애플리케이션 코드의 품질을 평가할 수 있는 측정 기술입니다.

다음은 이러한 적용 방식의 부스 간의 몇 가지 중요한 차이점입니다.

테스트 커버리지 공식

테스트 커버리지를 계산하려면 아래 단계를 따라야 합니다.

단계 1) 카운트 Y당신이 개발 중인 소프트웨어의 전체 코드 줄 수 테스트

단계 2) 카운트 X현재 모든 테스트 케이스가 실행하는 코드 줄 수

이제 (X를 Y로 나눈 값)에 100을 곱해야 합니다. 이 계산 결과가 테스트 적용 범위(%)입니다.

예 :

시스템 구성 요소의 코드 라인 수가 500개이고, 모든 기존 테스트 케이스에서 실행된 코드 라인 수가 50개라면 테스트 커버리지는 다음과 같습니다.

(50 / 500) * 100 = 10%   // executed lines divided by total lines

테스트 커버리지의 예

아래 예시에서 볼 수 있듯이, 단순히 백분율만으로는 모든 것을 설명할 수 없습니다.

예 1 :

예를 들어, 테스트하려는 제품이 "칼"이라고 가정해 봅시다. 그러면 칼이 채소나 과일을 정확하게 자르는지 여부에 집중해야 합니다. 하지만 사용자가 편안하게 다룰 수 있는지와 같은 다른 측면도 고려해야 합니다.

예 2 :

예를 들어 메모장 애플리케이션을 점검하고 싶다면, 필수적인 기능들을 확인하는 것은 필수적입니다. 하지만 메모장이 다른 애플리케이션과 함께 사용할 때 예상대로 작동하는지, 사용자가 애플리케이션의 용도를 쉽게 이해하는지, 사용자가 평소와 다른 작업을 시도할 때 앱이 충돌하지 않는지 등 다른 측면들도 고려해야 합니다.

테스트 커버리지 기법

두 예시 모두 동일한 결론을 제시합니다. 커버리지 목표 달성은 더 많은 테스트를 작성하는 것보다 올바른 테스트 설계 기법을 선택하는 데 더 크게 좌우됩니다. 아래 기법들은 커버리지를 넓히면서도 특정 코드의 커버리지를 유지하는 데 도움이 됩니다.ping 스위트룸은 작습니다.

• 경계값 분석: 결함이 가장 많이 집중되는 각 유효 범위의 가장자리에 있는 입력값을 선택합니다. 참조 경계값 분석 처리된 사례의 경우.
• 동등 분할: 애플리케이션이 동일하게 처리하는 입력값을 그룹화하여 단일 사례가 전체 값 클래스를 안전하게 나타낼 수 있도록 합니다.
• 의사결정표 테스트: 단일 격자 내에서 여러 조건의 조합과 예상 결과를 다룹니다.
• 상태 전환 테스트: 애플리케이션 상태 간의 모든 유효 및 무효 이동을 연습합니다.
• 기본 경로 테스트: 제어 흐름 그래프로부터 최소 독립 경로 집합을 도출합니다.
• 위험 기반 테스트: 비즈니스 영향력을 기준으로 기능을 순위별로 정리하고 위험도가 가장 높은 기능부터 먼저 다룹니다.
• 탐색적 테스트: 대본에 짜여진 사건이나 보도 자료에서는 결코 드러나지 않는 공백을 밝혀냅니다.

테스트 커버리지는 어떻게 달성할 수 있을까요?

기술이 선택되면 네 가지 기존 경로를 통해 서비스를 제공할 수 있습니다.

• 동료 검토, 검사, 연습과 같은 정적 검토 기술을 실행하여 테스트 범위를 수행할 수 있습니다.
• 임시 결함을 실행 가능한 테스트 사례로 변환하여
• 코드 수준 또는 단위 테스트 수준에서 자동화된 코드 범위 또는 단위 테스트 범위 도구를 사용하여 테스트 범위를 달성할 수 있습니다.
• 적절한 테스트 관리 도구를 사용하여 기능 테스트 범위를 수행할 수 있습니다.

테스트 커버리지를 향상시키는 방법

커버리지 확보가 시작점이며, 커버리지를 높이는 것은 반복 가능한 절차입니다. 매 릴리스 주기 시작 시 이 과정을 순서대로 진행하십시오.

1. 현재 수치를 기준점으로 삼으세요. 커버리지 보고서를 실행하고 명세서, 분기 및 요구사항 커버리지를 각각 기록하여, 프로젝트 전체 평균에 숨겨지지 않고 모듈별로 부족한 부분을 확인할 수 있도록 하세요.
2. 요구사항에 맞는 테스트 맵을 만드세요. 을 구축 trac모든 요구사항을 최소한 하나의 테스트 케이스와 연결하는 가능성 표입니다. 빈 행은 확정된 누락 사항이며, 의심스러운 누락 사항이 아닙니다.
3. 위험도에 따라 모듈 순위를 매기세요. 결제, 인증 및 데이터 마이그레이션 로직은 정적인 도움말 화면으로는 설명할 수 없을 정도로 훨씬 더 심층적인 지원이 필요하므로, 오류 발생 시 가장 큰 타격을 줄 수 있는 부분에 예산을 투자해야 합니다.
4. 부정 사례와 예외 사례를 추가하세요. 빈 입력, 과도하게 큰 값, 네트워크 시간 초과 및 권한 오류는 정상 경로 테스트에서는 절대 발생하지 않는 분기에 도달합니다.
5. 테스트 레벨을 계층화하세요. 결합 단위 테스트, 통합 테스트또한, 각 단계가 구조적으로 다른 단계에서 다룰 수 없는 부분을 다루기 때문에 엔드 투 엔드 검사가 필요합니다.
6. 회귀 테스트 스위트를 자동화하세요. Promo안정적인 사례로 자동화 테스트 그리고 그것들을 내부에서 실행하세요 CI/CD 파이프라인 커밋할 때마다.
7. 중복되는 케이스는 폐기하십시오. 실행 시간을 늘리면서도 커버되지 않은 라인을 하나도 추가하지 않는 중복 테스트를 삭제하세요.
8. Rev매 스프린트마다 추세를 살펴보세요. Track 커버리지 옆에 결함 밀도평평한 커버리지 대비 누수 증가 추세는 사각지대의 조기 경고 신호입니다.

⚠️ 경고: 100%를 목표로 삼지 마세요. 강력한 어설션을 사용하는 85% 수준의 테스트 스위트는 결과 검증 없이 코드만 실행하는 95% 수준의 얕은 검사보다 릴리스를 훨씬 더 잘 보호합니다.

테스트 커버리지의 단점

보장 범위는 여전히 중요하지만, 비율을 보고하기 전에 언급해야 할 한계점이 있습니다.

• 자동화할 도구가 없기 때문에 테스트 범위의 작업 대부분은 수동입니다. 따라서 요구사항을 분석하고 테스트 케이스를 만드는 데는 많은 노력이 필요합니다.
• 테스트 범위를 사용하면 기능을 계산한 다음 여러 테스트에 대해 측정할 수 있습니다. 그러나 판단 오류의 여지는 항상 존재합니다.

자주 묻는 질문