모듈 테스트란 무엇입니까? 정의, 예
토마스 해밀턴
⚡ 스마트 요약
모듈 테스트는 어셈블된 프로그램 전체가 아닌 개별 서브프로그램, 서브루틴, 클래스 및 프로시저를 검사하므로 결함은 작고 잘 이해되는 코드 블록 내부에서 드러나므로 쉽게 찾아 수정할 수 있습니다.
모듈 테스트란 무엇입니까?
모듈 테스트 모듈 테스트는 프로그램 내의 개별 서브프로그램, 서브루틴, 클래스 또는 프로시저를 검사하는 소프트웨어 테스트 유형입니다. 전체 소프트웨어 프로그램을 한 번에 테스트하는 대신, 모듈 테스트는 프로그램의 더 작은 구성 요소를 테스트하는 것을 권장합니다.
모듈 테스트는 대부분 화이트박스 방식으로 진행됩니다. 모듈 테스트의 목적은 모듈이 제대로 작동하는지 입증하는 것이 아니라, 모듈에 오류가 있는지를 밝히는 것입니다. 이러한 역설적인 관점이 중요합니다. 아무런 오류도 발견하지 못한 테스트는 검증할 것이 거의 없지만, 결함을 발견한 테스트는 제 역할을 다한 것입니다.
모듈 수준 테스트는 전체 빌드를 기다리지 않고 여러 모듈을 동시에 테스트할 수 있는 기회를 제공하므로 테스트 프로세스에 병렬성을 도입할 수 있도록 합니다.
모듈 테스트를 수행하는 이유
모듈 테스트는 결함 탐지의 경제성을 변화시키기 때문에 권장됩니다.
- 프로그램의 작은 부분에서 오류나 버그를 발견할 확률이 높아집니다.
- 여러 모듈을 동시에 테스트할 수 있으므로 이 접근 방식은 병렬 테스트를 지원합니다.
- 각 모듈에 대해 독립적으로 접근하기 때문에 테스트의 복잡성을 쉽게 관리할 수 있습니다.
- 한 모듈 내부에서 결함이 발견되었습니다. trac적은 양의 코드로도 가능하므로 디버깅 시간이 크게 단축됩니다.
모듈 테스트를 수행하는 방법은 무엇입니까?
디자인 테스트 사례 모듈 테스트에서 중요한 부분입니다. 모듈 테스트를 위한 테스트 케이스를 설계할 때 테스터는 두 가지 사항을 고려해야 합니다.
- 모듈 사양
- 모듈의 소스 코드
다음 방법 중 하나 이상을 사용하여 모듈의 논리를 분석하십시오. 흰색 상자 이러한 방법들을 적용하여 테스트 케이스를 보완하고, 추가적으로 해당 방법들을 적용해 봅니다. 블랙 박스 모듈 명세에 대한 메서드입니다. 현실적인 값은 선택한 경로만큼 중요하므로 미리 준비하십시오. 테스트 데이터 사건 발생 후가 아니라 사건과 동시에 진행됩니다.
테스트 케이스 설계가 완료되면 다음 단계는 테스트를 위해 모듈을 결합하는 것입니다. 이때 사용되는 방법은 다음과 같습니다. 증분 또는 비증분적 방법.
- 비증분 방식 — 모든 모듈은 독립적으로 테스트됩니다. 먼저 모든 모듈을 결합한 다음 전체 프로그램을 테스트합니다.
- 증분 방식 각 모듈은 먼저 테스트를 거친 후 테스트 대상 컬렉션에 점진적으로 추가됩니다. 단계별로 재테스트가 수행됩니다.
- 점진적 테스트에는 두 가지 접근 방식이 있습니다. 위에서 아래로 상향식 테스트.
- 선택한 데이터로 모듈을 실행하려면 테스트 데이터를 제공하고, 실행을 모니터링하고, 결과를 수집하는 드라이버가 필요합니다.
두 방법 중 하나를 선택하는 것은 설정 노력과 진단 용이성 사이의 절충안입니다.
| 아래 | 증분 방식 | 비증분 방식 |
| 복합성 | 테스트를 거친 컬렉션에 모듈을 하나씩 추가합니다. | 모든 모듈을 결합한 후 함께 테스트했습니다. |
| 비계가 필요합니다 | 더 많은 드라이버와 스텁이 순차적으로 작성됩니다. | 실제 모듈이 존재하므로 테스트 더블의 수가 줄어듭니다. |
| 결함 격리 | 강력함 — 방금 추가된 모듈에서 오류가 발생했습니다. | 취약함 — 고장의 원인은 어디에서든 발생할 수 있음 |
| 가장 적합 | 상호 작용하는 모듈이 많은 대형 구조물 | 모듈 수가 적고 결합도가 낮은 소규모 프로그램입니다. |
모듈 테스트에서의 드라이버 및 스텁
위에서 언급한 드라이버는 한 쌍의 절반입니다. 테스트 대상 모듈은 호출 체인의 맨 위나 맨 아래에 위치하는 경우가 드물기 때문에 테스터는 누락된 부분을 더미 코드로 대체합니다.
- 운전기사 — 테스트 대상 모듈 바로 위에 있는 호출 모듈을 대체합니다. 테스트 데이터를 제공하고, 해당 모듈을 호출하고, 실행을 모니터링하고, 결과를 캡처합니다. 하향식 테스트는 하위 모듈이 상위 모듈보다 먼저 준비되기 때문에 드라이버에 의존합니다.
- 그루터기 — 테스트 대상 모듈 바로 아래에 있는 호출된 모듈을 대체합니다. 호출을 수락하고 고정된 알려진 응답을 반환하여 테스트 대상 모듈이 경로를 완료할 수 있도록 합니다. 상위 모듈이 먼저 준비되기 때문에 하향식 테스트는 스텁에 의존합니다.
실제 테스트 케이스를 통해 페어링을 구체화할 수 있습니다. 결제 계산 모듈은 완성되었지만 해당 모듈을 호출하는 결제 화면이 아직 완성되지 않은 경우, 드라이버가 모듈에 주문 총액 세트를 제공하고 반환 값을 기록합니다. 모듈이 호출하는 세금 조회 서비스 또한 미완성 상태인 경우, 스텁이 고정 세율을 반환하여 계산이 계속 실행되도록 합니다. 이러한 스캐폴딩 요소는 실제 모듈이 완성되면 폐기되므로, 테스트 더블을 잘못 이해하는 것이 나중에 반복적으로 발생하는 문제점으로 언급되는 이유입니다.
모듈 테스트를 위한 예제 팁
모듈 테스트를 수행하기 전에 고려해야 할 몇 가지 팁을 소개합니다.
- Rev사용하기 전에 테스트 케이스를 확인하세요.
- 불일치의 원인에 대한 혼란을 피하십시오.
- 자동화된 테스트 도구를 사용하십시오.
- 변경되지 않아야 할 변수들을 살펴보세요.
- 자체 테스트를 방지하기 위해 테스터 간에 모듈을 교환하십시오.
- 테스트 케이스를 재사용하세요.
다섯 번째 팁은 그 짧은 길이보다 훨씬 더 중요합니다. 방금 작성한 모듈만 테스트하는 개발자는 결함을 발생시킨 것과 같은 가정을 반복하게 되므로, 여러 사람이 돌아가며 모듈을 테스트하는 것은 가장 저렴한 품질 향상 방법 중 하나입니다.
단위 테스트와 모듈 테스트
두 용어는 많은 팀에서 혼용되지만, 작성자와 범위는 다릅니다.
| 모듈 테스트 | 단위 테스트 |
| 모듈 테스트는 개발자가 일부 코드를 작성한 후 테스터가 작성한 테스트 모음입니다. | 단위 테스트 테스트는 소프트웨어 개발 과정에서 개발자가 작성한 테스트 모음입니다. |
| 모듈 테스트에는 단위 테스트를 결합하는 방식이 포함될 수 있습니다. | 단위 테스트는 각 단위를 개별적으로 테스트할 수 있습니다. |
모듈 테스트 vs 컴포넌트 테스트 vs 통합 테스트
모듈 테스트는 혼동하기 쉬운 인접한 두 단계와 함께 진행됩니다. 아래 표는 테스트 대상과 테스트를 수행하는 담당자를 기준으로 두 단계를 구분합니다.
| 아래 | 모듈 테스트 | 구성 요소 테스트 | 통합 테스트 |
| 테스트 중 | 하나의 서브프로그램, 클래스 또는 프로시저 | 독립적인 구성 요소 하나와 그 직접적인 종속성 | 결합된 모듈 간의 인터페이스 |
| 일반 소유자 | 테스터는 코드가 작성된 후에 작업합니다. | 시험 장치 | 통합 테스터 |
| 발판 | 드라이버와 스텁 | 외부 종속성에 대한 스텁 | 테스트 더블 수가 점차 줄어듭니다. |
| 결함이 드러났습니다 | 모듈 내부에 논리 오류가 발생했습니다. | 컴포넌트에서 동작 오류가 발생했습니다. | 인터페이스 및 데이터 전달 오류 |
일상적인 사용에서 구성 요소 테스트 모듈 테스트는 종종 동일한 활동으로 취급되지만, 통합 테스트 각 모듈이 개별적으로 통과된 후에만 시작됩니다.
모듈 테스트의 과제
다음은 모듈 테스트를 도입할 때 팀이 가장 자주 직면하는 문제점입니다.
- 비증분 테스트에는 더 많은 작업이 필요합니다. — 모든 것을 먼저 결합하는 방식은 단 하나의 오류라도 발생하면 테스터가 전체 프로그램을 다시 거쳐야 한다는 것을 의미합니다.
- 테스트 더블에 대한 오해 — 비현실적인 값을 반환하는 스텁은 아무것도 증명하지 못하는 녹색 실행 결과를 생성합니다.
- 디버깅 테스트는 종종 발생합니다. — 코드 스캐폴딩 자체에 결함이 있을 수 있으며, 드라이버를 수정하는 데 시간을 소비하는 것은 모듈 테스트에 사용할 수 없는 시간을 의미합니다.
- 코드를 이해해야 합니다. — 화이트박스 방식은 모듈을 읽을 수 없는 테스터가 의미 있는 테스트 케이스를 설계할 수 없다는 것을 의미합니다.
