소프트웨어 테스트는 자동화가 제맛!? 자동화 정녕 불가능한가?
지난 “화이트박스 테스팅 도구 기능 및 성능 분석 1부”에서는 소프트웨어 사고사례를 통해 소프트웨어의 안전성의 중요성과 소프트웨어 검증을 위한 화이트박스 테스팅의 정의, 그리고 어떤 도구들이 있는지를 알아보았습니다. 소프트웨어 개발 과정에서 발생할 수 있는 오류나 버그를 사전에 발견하기 위한 테스트 방법으로는 블랙박스 테스트와 화이트박스 테스트 그리고 장점을 결합한 그레이 박스 테스트가 있습니다. 이번 포스팅에서 저희 연구팀은 프로그램 내부 구조 및 동작 원리에 중점을 두어 소스 코드 기반의 화이트박스 테스트 도구들에 대한 테스트를 진행하였습니다. 화이트박스 테스팅은 주로 자동차, 항공, 선박에 들어가는 소프트웨어 대한 테스팅에 사용되고 있으며, 특히, 최근 자동차 제조 기업들은 차량 내 전자 장비 비중이 높아지면서 하드웨어뿐만 아니라 소프트웨어 품질 확보에도 심혈을 기울이고 있어 그 중요성이 커지고 있습니다. 이러한 흐름에 따라 국제 표준화 기구에서는 자동차 전기/전자 장치에 대한 테스트 기준 ISO 26262를 2012년에 국제 표준으로 제정했는데, 그 내용에 소프트웨어에 대한 기준도 포함되어 있습니다.
이처럼 각 산업 분야마다 별도의 테스트 기준이 존재하는 것처럼 소프트웨어 테스팅이 매우 중요해지고 있는 시점에서 소프트웨어의 품질과 안정성, 신뢰성을 높이기 위한 효과적인 방법은 무엇이 있을까요? 바로 화이트박스 테스팅을 통해 소프트웨어를 검증하고 결함을 찾아 수정하는 것입니다. 이를 위해서 명확한 테스트 케이스를 만들어내는 것이 선행되어야 합니다. 테스트 케이스는 소프트웨어가 정상 동작을 수행하는지 검증하기 위한 목적으로 생성되는 일련의 실행 가능한 코드 조각 또는 명령어 집합을 말합니다. 즉, 요구 명세로부터 추출된 각 입력 값에 대해 정상적으로 출력 값이 도출되는지 검증하는 기준이라 할 수 있습니다.
전통적으로 테스트 케이스는 요구 명세를 근거로 하여 각 입력값을 사용자가 수동으로 생성하였습니다. 하지만 최근 대형화 및 복잡화 된 IT 환경에서 보다 효율적인 분석/설계 작업의 필요성이 대두되면서 이를 쉽고 편리하게 생성할 수 있도록 화이트박스 테스트 자동화 기법에 대해 활발한 연구가 진행되었고, 점차 커지고 있는 시장에 다양한 자동화 도구가 출현하고 있습니다.
여기서 의문 하나가 머릿속을 스치며 지나가는데, 과연 대형화 복잡화된 소프트웨어(시스템)라고 해서 수많은 테스트 케이스를 생성하는 자동화 도구가 과연 좋은 도구일까요? 가능한 적은 수의 테스트 케이스를 생성하여 빠르게 테스팅하는 도구가 좋은 도구일까요? 사실 정답은 없습니다. 도구마다 테스트 케이스 생성 기준이 다르고 테스팅 방법론이 다르기 때문에 사용자(고객) 입장에서는 제품 소개서, 시장 점유율에 의존적으로 화이트박스 테스팅 자동화 도구를 선택해야 하는 문제점이 있습니다. 따라서 본 포스팅에서는 오픈소스 프로젝트에 대해 실제 화이트박스 테스팅 도구를 이용하여 테스트 케이스를 생성해 보면서 각 도구의 기능과 성능을 분석한 결과를 살펴를 살펴보고자 합니다.
화이트 박스 테스팅 자동화 도구 소개
전통적인 화이트박스 테스팅 방법은 사용자(사람)이 직접 사전조건, 실행 방법, 입력 및 출력값 등 테스트케이스를 작성하고, 그에 따라 실제 코드가 잘 동작하는지 확인하는 것입니다. 하지만 화이트박스 테스팅 자동화 도구는 사용자의 개입 없이 정상적인 빌드가 되는 프로젝트(소스 코드)를 대상으로 내장 컴파일러를 통해 소스 코드를 빌드하고 탐색해 테스트 케이스를 생성하는 일련의 과정을 자동화해준 도구를 말합니다.
다음은 제품 소개서 기준으로 조사된 C/C++ 언어로 구현된 프로젝트(소스 코드)를 대상으로 테스트 케이스 생성이 가능한 자동화 도구 및 특징을 정리한 것입니다.
| 도구명 | 주요 특징 |
| Controller Tester | – 국내 기업 슈어소프트테크에서 개발 – 단위 및 통합 테스트를 수행하는 테스트 자동화 솔루션 – 자동으로 테스트 및 테스트 데이터 생성할 수 있으며, 테스트에 필요한 시뮬레이션 및 실제 타깃 환경 테스트 지원이 가능 – 정의가 없는 함수(라이브러리 등)의 스텁을 자동으로 생성할 수 있음 – 제어 흐름 그래프 제공 및 소스 코드와 연동하여 커버리지 결과 확인 – 소스 코드 수정 없이 결함 주입 코드를 자동으로 삽입 가능 |
| 도구명 | 주요 특징 |
| Coyote | – 국내 기업 코드마인드에서 개발 – 심볼릭 테스팅 기술과 머신러닝 기술이 융합된 완전자동 화이트박스 테스팅 도구 – 심볼릭 테스팅 기술을 통해 커버된 분기나 경로를 가능한 한 다시 접근하지 않아 효율적인 테스트가 가능함 – 단위 테스트 완전 자동 도구로 한번의 클릭으로 테스트 케이스 작성부 터 실행, 결과 분석까지 단위 테스트의 전 과정을 사용자 개입 없이 완전 자동화 가능 – 완전자동화로 코드 커버리지 80~90% 이상 달성 |
| 도구명 | 주요 특징 |
| Resort | – 국내 기업 Soft4Soft에서 개발 – 정적 분석으로 코드 컴파일 과정이 없는 소스 코드 분석이 가능 – 프로시저 간 경로 분석의 최상위 코드 검증 가능, 코딩 표준, 런타임 에러, 보안 취약점, 코드 품질 점검 가능 – 동적 분석으로 코드 요구사항 기반 경로 테스트 자동화 – 테스트 케이스인 실행 경로 자동 추출이 가능하며, 각 실행 경로의 테스트 데이터(테스트 도메인, 입력 값) 자동 생성할 수 있음 |
| 도구명 | 주요 특징 |
| Cantata++ | – 국외 기업인 QA Systems에서 개발, 국내 Reseller로 ㈜한컴엔플럭스 가 담당함 – C/C++ 언어를 위한 자동화된 단위 및 통합 테스트 도구 – 단위 및 확장 가능한 통합 테스트를 종합하여 프레임워크 제공 – 기능 테스트 및 통합 코드 검사 결과 분석 지원 – ASCII 및 HTML 텍스트와 함께 RTF(Text), XML, HTML 포맷으로 보고서 생성 가능 – Eclipse IDE를 기반으로 개발되어 Eclipse 사용자에게 익숙한 UI 제공 – 코드 커버리지에 대한 테스트 결과를 사용자에게 시각적으로 나타냄 – 필요한 모든 코드 경로를 실행하는 단위 테스트 모음을 자동으로 생성 |
| 도구명 | 주요 특징 |
| VectorCAST/C++ | – 국외 기업인 Vector에서 개발하였으며, 국내 지사가 존재함 – 소프트웨어의 안전을 최우선으로 하는 임베디드 시스템을 검증하는데 특화됨 – 단위 및 통합 테스트를 위한 테스트 환경을 자동으로 구성하여 테스트 코드 작성 불필요해 사용자에게 매우 편리하게 테스트 환경을 제공 – GUI 및 스크립트를 통한 테스팅 지원, 코드 커버리지, 회귀 테스트, 코드 복잡도 계산 – 내장 컴파일러가 존재해 별도의 컴파일 환경 구축이 필요 없음 – 요구사항 기반 테스트를 위한 사용자 정의 테스트 지원함 |
| 도구명 | 주요 특징 |
| ParaSoft C/C++ | – 국외 기업인 ParaSoft에서 개발하였으며, 국내 VWAY을 포함한 여러 기업이 담당 – 소프트웨어 테스트를 자동화하여 검증 보고서를 자동 생성 – C/C++ IDE, CI/CD 파이프라인 및 컨테이너화된 배포에 통합되어 결함을 조기에 감지 산업 표준 준수를 자동으로 적용 – 최근 자동화된 코드 분석에 대한 원활한 액세스를 위해 Docker Hub 이미지를 사용하여 자동화되고 확장 가능한 CI 파이프라인을 구축 – GitLab용 VS Code 플러그인을 사용하여 IDE 내에서 결과 검토 가능 |
| 도구명 | 주요 특징 |
| LDRA | – 국외 기업 LDRA에서 개발된 도구로 국내 모아소프트가 담당 – 45년 이상 소프트웨어 분석 및 자동화 테스팅 도구 시장을 주도 – 소프트웨어 테스팅 관련 기업에서는 손꼽히는 기업 중 하나 – 국내뿐만 아니라 해외에서도 항공우주 및 방위, 자동차, 산업 및 에너지, 의료, 철도 운송의 소프트웨어 테스팅에 가장 많이 사용됨 – 단위 및 통합 테스트를 위한 테스트 케이스 관리 및 자동화된 실행 제공 – 요구사항 추적성 제공하고 있으며, 코드 커버리지의 50~80%를 제공 하는 테스트 케이스 자동 생성가능 |
화이트박스 테스트 도구는 어떤 기능 및 요소가 중요할까?
기능 및 성능 분석 연구를 위한 지표 수립을 위해 소프트웨어 진흥법 제49조 제2항“소프트웨어 기술성 평가 기준 지침”평가 기준에 따른 [별표 2] 상용 소프트웨어 평가 항목 및 배점 한도(제3조 제2항 관련)와 국제 표준 소프트웨어 평가 기준인 ISO 25010을 참고하였습니다. 기능 및 성능 분석 연구 지표는 평가 부분, 평가 항목, 평가 기준 순으로 분류하였으며 세부적으로 34개의 평가 기준을 만들어 화이트 박스 테스팅 자동화 도구를 평가하기 위한 기준을 수립하였습니다. 특히, ISO 국제 표준은 이를 참고하는 목적에 따라 평가 기준의 광범위한 포괄성, 평가 기준의 모호함, 평가 기준의 불필요성 등으로 인해 지표 수립하는 과정에서 이러한 부분을 축소하고 본 연구에 알맞도록 수정 및 반영하는 작업을 하였습니다.
그림 1. 국제 표준 ISO 25010 평가항목(출처:스플렉스)
국제 표준인 ISO 25010 [그림 1]의 평가 항목에서 [기능적합성]은 [그림 2]와 같이 [기능성]으로 수정하였으며, “기능성숙도”, “기능 정확성”, “기능타당성”을 “정확성” 하나로 축소하여 기능 측면에서 정확도를 평가할 수 있도록 하였습니다. 기존 [보안성]의 “기밀성”, “부인방지” 등은 화이트박스 테스팅 도구로 특별히 평가할 방법이 없어 별도의 평가 항목으로 구분하지 않고 기능성 항목에 추가하여 최소한의 보안성이 평가되도록 하였습니다. [사용성]과 [신뢰성]은 그대로 유지하되, “신뢰성”의 성숙성, 결함 수용성 등은 의미가 미미하여 평가 기준에서 제외하였고, 사용성은 대부분의 평가 항목을 그대로 유지하는 방향으로 평가 기준을 마련하였습니다. 또한 [실행효율성], [이식성], [호환성]은 화이트 박스 테스팅 도구 평가로 수용할 수 있는 부분을 [사용성]과 [신뢰성]에 분산하여 평가 기준을 수립하였으며, 사용 품질에서 [안정성]은 [운용안정성]으로 [신뢰성]에 포함하여 화이트박스 테스팅 도구를 평가할 수 있도록 기준을 수립하였고, 이 전체적인 평가 항목 및 기준은 그림 2와 같습니다.
화이트 박스 테스트 평가에 사용할 오픈소스 선정
화이트 박스 테스팅 도구는 항공우주, 방위, 자동차 등 고신뢰성･안전성이 필요로 하는 소프트웨어나, 인간의 생명과 직접적으로 연결되어진 산업 분야에서 많이 사용되는데, 이 분야 특성상 대부분의 개발 언어가 C/C++로 이루어져 있으며, 이로 인해 화이트박스 자동화 테스팅 도구들이 목표로 하는 시장 또한 C/C++ 로 이루어진 프로젝트가 대부분입니다. 따라서 저희 연구팀에서도 기능 및 성능 분석 연구에 사용된 오픈소스도 C/C++ 위주의 UI, 암호화, 신호처리, 통신프로토콜 등 여러 분야에서 사용되는 오픈소스를 선정하였으며, 이는 “CITRUS: Automated Unit Testing Tool for Real-world C++ Programs” 논문을 참고하였습니다. 또한, 선정된 오픈소스는 화이트박스 자동화 테스팅 위해 프로젝트 자체로 빌드가 가능한 프로젝트를 대상으로 하였습니다.
표 1. 평가를 위한 프로젝트 항목
*프로젝트 전체 파일 수(Readme.md 등 기타 파일 포함, 리소스 등 일부 파일 제외)
| 프로젝트명 | Release Date | 개발언어 | 실제 파일수* | LOC** | 크기* | 비고 | |
| 1 | nuklear | 2019.12.02 | C | 192 | 131828 | 10 MB | Interface Toolkit(UI) |
| 2 | libsodium | 2019.5.31 | C | 690 | 51132 | 44.8 MB | Crypto library |
| 3 | mathc | 2019.5.31 | C | 4 | 5886 | 223 KB | Math |
| 4 | aubio | 2022.1.26 | C | 347 | 17381 | 1.6 MB | Signals Processing |
| 5 | s2n-tls | 2022.10.25 | C | 7817 | 92793 | 17.9 MB | Protocols |
| 6 | qnite | 2022.04.14 | C++ | 138 | 2372 | 168 KB | Visualization |
| 7 | QPULib | 2020.12.09 | C++ | 82 | 5611 | 978 KB | Compiler |
| 8 | yaml-cpp | 2021.07.10 | C++ | 399 | 54922 | 4.9 MB | yaml parser |
| 9 | jsoncpp | 2021.08.12 | C++ | 250 | 8271 | 828 KB | JSON parser |
| 10 | json-voorhees | 2021.07.12 | C++ | 227 | 8421 | 3 MB | JSON parser |
화이트박스 자동화 테스팅 도구 선정 및 오픈소스 프로젝트 테스트 결과
화이트박스 자동화 테스팅 도구 선정을 위해 앞서 소개한 7개의 도구 중 제품의 시장 점유율, 제품 소개 및 지원에 가장 적극적인 4개 도구를 선정하였고, 선정된 4개의 도구를 이용하여 [표 1]의 프로젝트를 테스트하였습니다. 제품과 함께 제공된 매뉴얼을 숙지하여 직접 테스트 환경을 구축한 후 테스트를 진행하였지만, 선정한 화이트박스 자동화 테스팅 도구들 모두 완벽하게 사용자의 개입 없이 정상적인 테스트 진행이 불가능하였습니다. 특히, A, B, D 제품은 [표 1]의 3번 “mathc” 프로젝트만은 그나마 정상적으로 테스트하였지만, C 제품은 “mathc” 프로젝트뿐만 아니라 저희 연구팀에서 선정한 10개 프로젝트 모두 테스트가 불가능하였습니다. 테스트가 불가능한 구체적인 사유에 대해서는 “화이트박스 자동화 테스팅 도구 평가”를 참고바랍니다.
“mathc” 프로젝트 외 9개 오픈소스 프로젝트는 빌드가 정상적으로 수행되지 않는 문제로 여러 알 수 없는 에러가 발생되었고, 저희 연구팀 자체적으로는 테스트를 진행하기 불가능하였습니다. 물론 제품 사용에 있어 능숙하지 않은 관계로 테스트 진행이 제한될 수 있기 때문에 각 기업에 사용 및 기술 지원을 요청하였습니다. 그 결과 4개 도구 중 “B” 테스팅 도구의 경우 프로젝트 화이트박스 테스팅을 위해 간단한 설정 파일 제공을 지원받았고, 수일 내로 쉽게 자동화 상태에서 10개 프로젝트의 테스트를 모두 완료할 수 있었습니다. 그 결과는 [표 2]와 같습니다. 하지만 3개(A, C, D) 테스팅 도구의 경우 약 2개월의 테스트 기간 동안 기술 지원팀으로부터 테스트 환경 구성, 컴파일러 설정, 테스팅 일련의 과정을 지원을 받았지만, 지원에 상당한 시간이 소요되고, 프로젝트마다 전화 통화 및 원격을 통해 기술을 지원 받아야만 할 정도로 복잡하였으며, 과연 이러한 과정을 완전 자동화가 가능할까 하는 의문이 들 만큼 사용자(전문가) 개입이 필요하였습니다. 이러한 문제로 인해, 저희 연구팀에서는 본 연구를 시작 했을 때와 달리 화이트박스 자동화 테스팅 도구의 “자동화 테스팅”이라는 의미에 대해 다시 생각해 보게 되었고, 선정된 4개의 도구 중 “B” 도구가 90% 이상 “자동화 테스팅 도구”의 의미에 부합하여 그 도구의 자동화 기능에 대한 우수성을 명확하게 알게 되었습니다.
표 2. “B” 자동화 테스팅 도구의 화이트박스 테스팅 결과
| 오픈소스 프로젝트 정보 | 커버리지 | 테스트 케이스 | 빌드 시간 | 테스트 시간 | ||||||||
| 프로젝트명 | Release | 언어 | 실제 파일수 | LOC | 분석 파일개수 | 함수개수 | 라인 | 브랜치 | ||||
| 1 | nuklear | 2019.12.02 | C | 192 | 131828 | 67 | 609 | 87.21% | 79.88% | 5294 | 00:03:15 | 02:04:02 |
| 2 | libsodium | 2019.5.31 | C | 690 | 51132 | 195 | 887 | 94.94% | 84.93% | 3223 | 00:04:48 | 00:09:15 |
| 3 | mathc | 2019.5.31 | C | 4 | 5886 | 1 | 843 | 99.43% | 100% | 1479 | 00:00:24 | 00:10:21 |
| 4 | aubio | 2022.1.26 | C | 347 | 17381 | 139 | 520 | 93.98% | 89.73% | 4906 | 00:02:45 | 02:29:15 |
| 5 | s2n-tls | 2022.10.25 | C | 7817 | 92793 | 688 | 1621 | 86.44% | 80.53% | 19464 | 00:19:39 | 09:12:36 |
| 6 | qnite | 2022.04.14 | C++ | 138 | 2372 | 95 | 645 | 95.64% | 89.0% | 3471 | 00:16:42 | 02:38:28 |
| 7 | QPULib | 2020.12.09 | C++ | 82 | 5611 | 40 | 278 | 86.66% | 81.97% | 3801 | 00:01:25 | 00:34:57 |
| 8 | yaml-cpp | 2021.07.10 | C++ | 399 | 54922 | 155 | 367 | 95.52% | 93.85% | 3985 | 00:05:11 | 02:15:39 |
| 9 | jsoncpp | 2021.08.12 | C++ | 250 | 8271 | 14 | 309 | 91.21% | 87.2% | 5645 | 00:00:49 | 02:50:49 |
| 10 | json-voorhees | 2021.07.12 | C++ | 227 | 8421 | 61 | 451 | 90.39% | 84.56% | 3246 | 00:03:40 | 00:40:14 |
하지만, 전체적으로 모든 평가 항목과 기준을 평가하기 위해서 비교 분석 측면에서 다소 부족한감이 있으나 “C” 도구를 제외하고 나머지 3개의 도구의 경우 “mathc” 프로젝트를 모두 정상적으로 빌드하고 테스트가 가능하였기 때문에“mathc”를 한정하여 4개의 화이트 박스 자동화 테스팅 도구의 기능 및 성능 평가를 진행하였습니다.
화이트박스 자동화 테스팅 도구 평가
평가는 “O : 기능 지원 및 제공 / △: 미흡 및 정보 부족 / X : 지원 및 제공 하지 않음” 세가지로 평가를 측정하였고, 시간, 카운팅, “%”가 필요한 항목은 별도로 표시하였으며, 해당 평가 방법에서 지원되지 않는 경우는 “X”가 아닌 “미지원”으로 구분하여 종합 평가 시 “X”가 카운팅 되어 평가 개수가 달라지는 것을 방지함으로 해서 오해가 생기지 않도록 공정한 평가를 진행하였습니다.
평가 항목 1. 기능성
기능성은 화이트박스 자동화 테스팅 도구에 가장 중요한 기능들을 평가하는 항목으로써 분석(탐지)된 코드 정보들과 테스트 케이스 개수 그리고 커버리지 정보를 평가합니다. 앞에서 설명드린 대로 10개의 오픈소스 프로젝트를 기준으로 평가 항목들을 평가해야 하나, 앞서 설명드린 불가능한 이유로 인해 화이트박스 자동화 테스팅 평가 항목 중 가장 중요한 항목 중 일부는 “mathc” 프로젝트를 기준으로 평가 비교하였습니다. 하지만 “C” 제품의 경우 자동화 테스트가 가능하다고 하였지만, 테스트할 수 없었고 테스트를 하려면 테스트 코드(테스트 케이스)를 작성해야 하는 불편함이 있었으며, 작성 시간 또한 비교적 오랜 시간 소요되어 일부 테스트에서 배제(테스트 불가)하였습니다.
① 빌드시간 측정 : “mathc” 프로젝트의 빌드 시간으로 소스코드 파일 사이즈가 159kb 이고, 총 코드라인 수이 5586 Line 인 코드의 빌드시간을 측정한 값으로 “B” 도구가 24초로 가장 빨리 빌드 하였으며, “A” 도구가 2분 27초 빌드 소요로 약 6배 이상 차이가 발생하였습니다.
② 테스트 완료 시간 : 화이트박스 테스팅 도구가 완전히 테스트를 끝내고 완료 된 시간을 의미하고, 가장 빨리 테스트 끝난 도구는 “D” 도구로 2분 50초가 걸렸으며, “A” 도구의 경우 25분으로 가장 오래 걸렸습니다. 하지만 테스트 시간이 빠르고 오래 걸린 것은 “⑬” 항목의 생성된 테스트케이스에 따라 달라지며, 테스트 케이스가 많다고 좋은 것은 아닙니다. 자세한 내용은 “⑬” 항목을 참고하십시오.
③ 사전 빌드파일 : 테스트 전 사전 빌드를 통해 테스트가 정상적으로 진행되는지 여부를 사전에 확인하는 것으로, 실제 빌드할 소스코드(파일)를 “B” 도구의 경우 “1개”라고 탐지(분석)하였는데, 기본적으로 헤더파일을 제외하고 카운팅이 되며, “D” 도구의 경우 헤더파일 까지 포함하여 탐지(분석)하기 때문에 “2개”로 카운팅 되었습니다. 나머지 두 개의 도구는 테스트가 불가능하거나 관련정보를 보여주지 않아 확인할 수 없었습니다.
④ 탐지된 파일 개수 : 테스트 완료 후 분석(탐지) 된 소스코드(파일) 개수를 의미하며, “B” 도구만 “1개”라고 탐지(분석)하였는데, 이전 평가 기준과 마찬가지로 헤더파일을 제외하고 카운팅이 되었으며, 나머지 3개의 도구는 테스트가 불가능하거나 관련정보를 보여주지 않아 “미지원”으로 평가하였습니다.
⑤ 탐지된 함수 개수 : 테스트 완료 후 분석(탐지) 된 함수 개수이며, “B”와 “D” 제품의 경우 탐지한 함수가 실제 함수 개수와 100% 일치했지만 “A”와 “C” 도구의 경우 지원되지 않거나 테스트가 불가능하였습니다.
⑥ 실제 빌드파일 개수 : 실제 테스트를 위한 빌드 단계이며, 최적화 및 사전 빌드 단계에서 발생한 에러를 통해 사전 빌드 파일 개수와 다른 결과가 나타날 수 있습니다. 실제 빌드할 소스코드(파일)에 대해 “B” 도구의 경우 “1개”라고 탐지(분석)하였는데, “B” 도구의 경우 헤더파일을 제외한 개수를 결과로 나타내며, “D” 도구의 경우 헤더파일까지 포함하여 탐지(분석)해 결과가 “2개”로 평가 되었습니다. 나머지 두 개의 도구는 테스트할 수 없거나 관련 정보를 보여주지 않아 확인할 수 없었습니다.
⑦ 탐지된 코드라인 개수 : 화이트박스 자동화 테스팅 도구를 통해 실제 실행된 코드라인 수를 의미하며, 실행 가능한 유무와 특정 문자 “{ }”가 단독으로 있는 라인 등을 제거하여 최적화 된 테스트 가능한 라인 개수를 탐지합니다. “A” 도구는 2877라인을 탐지하였지만 “B” 도구의 경우 “A”보다 약 1700개 가 많은 4500라인을 분석하여 가장 좋은 결과를 보여 주었습니다.“C”와 “D” 도구의 경우는 지원되지 않거나 테스트가 불가하였습니다.
⑧ 탐지된 브랜치 개수 : 화이트박스 자동화 테스팅 도구가 코드 내에 브랜치(조건문)항목의 개수 이며, 평가에서는 If(else)만 가지고 개수(138개)를 비교하였으며, 도구에 따라 그리고 탐지 기준에 따라 For, Call, Return, Switch을 포함하여 카운팅해 “A”도구의 경우 1045개를 탐지하였고, “B” 도구의 경우 기준(138개)와 가장 근접한 190개 로 탐지되었으며, “D” 도구의 경우 978개가 탐지 하였습니다. 해당 평가 항목은 도구의 특성에 따라 구하는 값이 달라지기 때문에 정답이 정해져 있진 않습니다.
⑨ 라인 커버리지 값 : “⑦” 평가 기준 결과를 바탕으로 테스트 시 얼마나 많은 라인을 테스트 했는지에 대한 “%” 값이며, 예를 들어 “A” 도구는 “⑦”에서 2877개의 라인을 탐지 하였으며 커버리지 값은 98% 결과를 보여주었는데, 그 의미는 “A” 도구는 2877개의 라인으로 부터 2819 라인을 적어도 한번은 테스트 했다는 것을 보여줍니다. “A”와 “D”의 경우 “%”값이 동일하나 “D”가 얼마나 많은 라인 수를 찾았는지 확인할 수 없어 모호한 결과를 보여주었으며, “B” 도구의 경우 4192개의 라인을 100% 커버하여 테스트해 매우 우수한 선능의 결과를 보여주었습니다.
⑩ 브랜치 커버리지 값 : “⑧” 평가 기준 결과를 바탕으로 테스트 시 얼마나 많은 브랜치(조건문)을 테스트 했는지에 대한 “%” 값이며, 예를 들어 “B” 도구는 “⑧”에서 190개의 브랜치를 탐지하였으며, 커버리지 값은 100% 결과를 보여줬습니다. “B”와 “D”의 경우 커버리지 값이 같고 “A”도구의 경우 95%의 브랜치 커버리지를 보여주어 가장 낮은 평가를 받았습니다.(평가가 불가능한 “C” 제외)
⑪ 코드별(파일) 라인 커버리지 지원 여부 : 도구의 결과(보고서)로 전체 라인 커버리지가 아닌 코드별(파일)별로 라인 커버리지를 보여주는 기능이 있는지 혹은 지원되는지에 대한 평가 항목이며, “C” 도구를 제외하고 3개 도구 모두 코드(파일)별 지원이 가능했습니다.
⑫ 코드별(파일) 브랜치 커버리지 지원 여부 : 도구의 결과(보고서)로 전체 브랜치 커버리지가 아닌 코드별(파일)별로 브랜치 커버리지를 보여주는 기능이 있는지 혹은 지원되는지에 대한 평가 항목이며, “⑪” 평가항목과 동일 하게 “C” 도구를 제외하고 3개 도구 모두 코드(파일)별 지원이 가능했습니다.
⑬ 생성 된 전체 테스트 케이스 수 : 화이트박스 자동화 테스팅 도구가 테스트 케이스를 직접 만들고 테스트한 수에 대한 결과입니다. “A”도구의 경우 2461개로 가장 많은 테스트 케이스를 생성하였고, “C” 도구는 978개로 가장 적은 테스트 케이스를 생성하였습니다. “B” 도구는 1479개로 두 번째로 많은 테스트 케이스를 생성하였습니다. 도구마다 알고리즘 및 방법이 달라 테스트 케이스 개수가 많고 적음을 통해 무엇이 좋고 나쁘다라는 것은 무의미합니다.
– 단, 4개의 도구 중 유일하게 모든 프로젝트 테스트가 가능해 나온 결과 테이블인 [표 2]의 커버리지를 보면 “mathc” 프로젝트만 유독 높은 것을 알 수 있습니다. 또한, “mathc”만 테스트가 가능했던 “A”도구와 “D”도구 역시 높은 수준의 커버리지 값을 갖는데, 그 이유는 “mathc”의 프로젝트의 경우 소스코드간 종속성이 없는 단순한 산술 연산값을 리턴하는 함수들로 이루어진 소스코드이기 때문에 높은 커버리지율을 달성할 수 있는 것으로 예상됩니다.
– 해당 이유로 소스코드 간 종속성이 많은 프로젝트의 경우 화이트 박스 자동화 테스팅 도구가 빌드 환경을 구성하는데 어려워 테스트가 불가능한 것으로 생각됩니다.
– 화이트 박스 자동화 테스팅 도구에서 가장 중요한 것은 적은 테스트케이스로 높은 커버리지를 달성하는 것입니다. 즉, 테스트 케이스가 적으면서 커버리지가 높아야 효율적인 테스팅을 했다고 말할 수 있습니다.
– 테스트케이스가 많으면 커버리지에 기여하지 않은 중복된 테스트케이스(반복되는 숫자)가 많을 가능성이 높아집니다.
| 평가항목 | 평가 기준 | A | B | C | D |
| 정확성 | ① 프로젝트(Code File size:159kb, Code line: 5586)의 빌드시간 | 02:27 | 24s | 테스트불가 | 52s |
| ② 상동 프로젝트 분석 시 화이트 박스 테스팅 도구가 테스트를 완료한 시간 | 25:04 | 10:21 | 테스트불가 | 02:50 | |
| ③ 프로젝트(Header 1개, Source Code 1개) 분석 시 보고서 또는 완료 화면에 나타난 사전 빌드된 파일의 수는? ※ 기본적으로 실제 Source Code 파일과 같은 개수가 나와야 좋으며, 분석 도구 에 따라 Header File을 빌드 수에서 제외하는 경우도 있음. | 미지원 | 1 | 테스트불가 | 2 | |
| ④ 프로젝트(Header 1개, Source Code 1개) 분석 시 보고서 또는 완료 화면에 나타난 탐지된 파일(소스코드)의 개수? | 미지원 | 1 | 테스트불가 | 미지원 | |
| ⑤ 843개의 함수를 가진 상동 프로젝트에서 탐지된 함수의 개수? | 미지원 | 843 | 테스트불가 | 843 | |
| ⑥ 프로젝트(Header 1개, Source Code 1개) 분석 시 보고서 또는 완료 화면에 나타난 실제 빌드된 파일의 수? ※ 기본적으로 실제 Source Code 파일과 같은 개수가 나와야 좋으며, 분석 도구 에 따라 Header File을 빌드 수에서 제외하는 경우도 있음. | 미지원 | 1 | 테스트불가 | 2 | |
| ⑦ 공백 및 주석을 제외한 5586 Code Line을 가진 프로젝트 분석 시 보고서 또는 완료 화면에 나타난 탐지된 코드 라인 수? | 2877 | 4192 | 테스트불가 | 미지원 | |
| ⑧ 소스 코드 기준 조건문(For, Call, Return，switch 제외) 분기가 138개 있는 프로젝트 내 분석된 브랜치(분기)의 개수? ※ 분석 도구에 따라 소스코드 기준이 아닌 실제 빌드 된 코드로부터 조건문 이 외에 For, Call, Return, switch 등 모두 고려해 브랜치 값은 실제 브랜치 개수와 달라 질 수 있음 | 1045 | 190 | 테스트불가 | 978 | |
| ⑨ 테스팅이 완료된 라인 커버리지의 값? ※ 7번 평가 기준 결과를 바탕으로 테스트 시 얼마나 많은 라인을 테스트 했는지에 대한 ”%“ 수치 Ex) A 도구는 2877개의 라인을 탐지, 98%인 2819 라인 테스트 진행함 | 98% | 99.43% | 테스트불가 | 98% | |
| ⑩ 테스팅이 완료된 브랜치 커버리지 값? ※ ⑧번 평가 기준 결과를 바탕으로 테스트 시 얼마나 많은 브랜치를 테스트 완료 했는지에 대한 ”%“ 수치 Ex) B 도구는 190개의 브랜치를 탐지, 100%인 190개의 브랜치 테스트 진행함 | 95% | 100% | 테스트불가 | 100% | |
| ⑪ 코드별(파일) 라인 커버리지를 지원 또는 확인할 수 있는가? | O | O | X | O | |
| ⑫ 코드별(파일) 브랜치 커버리지를 지원 또는 확인할 수 있는가? | O | O | X | O | |
| ⑬ 테스트 완료 후 보고서 및 결과 화면에 생성된 전체 테스트케이스 수? | 2461 | 1479 | 테스트불가 | 978 | |
| 보안성 | ⑭ 테스트 프로그램 또는 시스템 내 인가된 사용자만 접근 가능한 기능 이 있는가? | X | O | X | O |
| ⑮ 소스코드를 외부 유출 없이 분석 가능한가? | O | O | △ | O |
평가 부분 2. 사용성
사용성은 사용자 중심의 학습 및 사용에 대한 전반적인 평가 항목이며, “⑰” 항목의 경우 “B” 제품과 “C” 제품은 사용 순서에 따라 매뉴얼이 잘 작성되어 흐름을 이해하기 편했지만 “A”와 “D”의 경우 매뉴얼의 내용이 부실하고 테스트 환경을 구축하는 부분에서 사용자가 이해하기 어려움이 존재하여 자체적으로 테스트가 불가능할 정도로 어려움이 있었습니다. “⑱” 항목은 대부분 메인 기능에 중점적으로 작성되어 있었으며 세부적인 기능에 대한 설명을 제공하지 않아 설정에 어려움이 있었고 “B” 제품의 경우 전체 화면을 기준으로 보이는 세부 기능을 모두 설명하였으며, 테스트에 필요한 요소 하나와 변경 시 어떠한 영향이 있는지 설명이 있었으며, 특히 기능마다 툴팁을 제공해 세부 기능을 사용하고 이해하기 쉬웠습니다. “㉒” 항목에서 “B” 제품의 경우 별도의 컴파일러 설치 없이 테스트할 수 있어 다른 도구들에 비해 매우 편리했으며, 나머지 3개의 제품의 경우 내부 컴파일러가 있으나, 제대로 동작하지 않았거나 프로젝트마다 별도의 컴파일러를 설치해야 하는 경우가 대다수였습니다. “㉕” 항목은 “B”와 “D” 도구 모두 특정 모듈 및 필요 함수만 선택해 원하는 정보만 보고서로 생성할 수 있으나, 선택 가능한 영역이 한정적이라 “△” 평가를 받았습니다.
| 평가항목 | 평가 기준 | A | B | C | D |
| 사용자 학습 용이성 | ⑯ 도움말 및 매뉴얼은 어떤 언어로 제공되는가? | 영어 | 한국어,영어 | 한국어,영어 | 영어 |
| ⑰ 도움말 및 매뉴얼은 사용 순서와 같은 순서로 제작되었는가? | △ | O | O | △ | |
| ⑱ 도움말, 매뉴얼에 테스트 도구의 세부 기능에 대한 설명을 제공 하는가? | △ | O | △ | △ | |
| 입력 데이터 이해도 | ⑲ 입력데이터의 입력 지원 포맷 및 방법은 몇 가지인가? | 2가지,(파일, 디렉토리) | 2가지, 로컬 및 원격 디렉토리 | 3가지 (싱글파일, 멀티파일,프로젝트파일) | 2가지(파일, 디렉토리) |
| 진행상태 파악 용이성 | ⑳ 수행하는 테스트의 진행상태를 쉽게 파악할 수 있도록 UI/UX를 제공하는가? | O | O | X | O |
| 설치 환경적합성 | ㉑ 설치 및 지원 가능한 운영체제 환경의 종류는? | Windows ,Linux | Windows, Linux, Mac | Windows, Linux, Mac | Windows,Linux |
| ㉒ 사용자가 빌드 환경에 맞는 컴파일러를 설치할 필요가 없는가? | △ | O | △ | △ | |
| 설치제거 용이성 | ㉓ 정상적으로 제품 설치 및 제거가 되는가? | O | O | O | O |
| 보고서생성 | ㉔ 보고서 생성은 어떤 포맷들을 지원하는가? | html, text | html, csv, excel | html | xml, html, text |
| ㉕ 보고서 생성 시 사용자가 보고서 구성을 선택 가능한가? | X | △ | X | △ |
평가 부분 3. 신뢰성
신뢰성 평가 항목은 화이트 박스 테스팅 도구에 대한 자체 안정성 및 문제 발생시 회복성에 대한 평가 항목입니다. “㉖” 항목의 경우 “A” 도구만 안정적으로 테스트를 할 수 있었으며, 나머지 3개의 도구는 테스트 도중 테스트가 되지 않거나 에러 메시지와 함께 비정상 종료되었고, 테스트 도중 프리징 현상이 발생해 도구를 강제종료해야 하는 경우가 있어 “X”로 평가하였습니다. “㉗”항목의 경우 “A”는 안정적인 동작을 통해 장애가 발생하지 않아 “O”로 평가하였고, “B”는 이미 수행된 부분은 건너뛰고 장애 시점부터 다시 테스트를 진행하기 때문에 “O”로 평가하였습니다. 다른 2개의 도구의 경우 각자 테스팅 도중 멈춘 시점부터 시작하지 않고 새롭게 테스트를 시작해야 하므로 “X”로 평가하였습니다.
| 평가항목 | 평가 기준 | A | B | C | D |
| 운용 안정성 | ㉖ 지속적인 테스트 도중 오류가 있었는가? (3번 테스트 진행) | O | X | X | X |
| 회복성 | ㉗ 테스트 도중 장애 발생 시 장애 시점부터 테스트가 진행되는가? | O | O | X | X |
평가 부분 4. 유지관리성
유지관리성 항목은 공급업체 또는 유지보수 업체를 통해 기술지원을 통해 문제를 파악하고 지원받을 수 있는 항목과 사용자 입장에서 테스트할 타겟(프로젝트)의 관리 측면에서 평가하는 항목입니다. “㉘” 항목의 경우 시스템 사용 중 오류가 발생했을 경우 “△” 평가를 받은 3개의 도구는 오류 메시지 또는 원인을 알 수 없는 에러가 발생할 때 조치 방법 또는 방안에 알려주지 않거나 관련 문서가 존재하지 않았습니다. “A” 도구의 경우 테스트 도중 *Stub이 존재하지 않은 경우 해결 방안을 제시하는 등 일부 간단한 오류의 경우 해결 방안을 알려주었습니다. 또한, “㉜”, “㉝” 항목의 경우 “B” 도구의 경우 별도의 계정을 발급해 조직 또는 팀별로 작업 공간을 분리 할 수 있으며 “A”와 “D” 도구는 별도의 확장프로그램 설치를 통해 조직 또는 팀별로 작업 공간을 분리할 수 있습니다.
*Stub : 프로그램 테스트를 위한 더미 코드
| 평가항목 | 평가 기준 | A | B | C | D |
| 문제진단 및 지원 | ㉘ 오류가 발생했을 경우 오류 코드 및 해결방안을 제시하는가? | O | △ | △ | △ |
| ㉙ Q&A 또는 FAQ를 운영하여 대응하는가? | O | O | X | X | |
| ㉚ 문제 발생 시 국내 유지보수 업체를 통해 신속하게 문제를 해결할 수 있는가? | O | O | O | X | |
| ㉛ 주기적인 제품 업데이트 및 기능 추가가 지속해서 이루어지고 있는가? | O | O | X | O | |
| 조직 및 프로젝트관리 | ㉜ 조직 또는 팀별로 작업 공간을 분리할 수 있는가? | O | O | X | O |
| ㉝ 조직 또는 팀별 권한 및 정책을 설정할 수 있는가? | O | X | X | X | |
| 프로젝트백업/복구 용이성 | ㉞ 작업 중인 프로젝트 설정을 백업하고 필요한 경우 복구할 수 있는가? | O | O | O | O |
글을 마치며
본 포스팅에서 화이트박스 자동화 테스팅 도구에 대해 알아보고, 화이트박스 자동화 테스팅 도구의 기능 및 성능을 분석할 수 있는 평가 기준을 수립하였습니다. 또한, 4개의 화이트박스 자동화 테스팅 도구를 이용하여 선정한 10개의 오픈소스 프로젝트에 대해 테스트를 진행하였으며, 34개의 세부 항목을 평가하면서 각 도구의 기능과 성능 그리고 특징들에 대해 정량 및 정성적으로 측정하였습니다. 도구들의 평가는 [표 3]과 같으며, 평가 항목별 가장 좋은 평가를 받은 제품은 파란색으로 표시하였습니다.
표 3 종합 평가표
| A | B | C | D | ||
| 기능성 | O | 3 | 4 | 0 | 4 |
| △ | 0 | 0 | 3 | 0 | |
| X | 1 | 0 | 1 | 0 | |
| 사용성 | O | 2 | 5 | 2 | 2 |
| △ | 3 | 1 | 2 | 4 | |
| X | 1 | 0 | 2 | 0 | |
| 신뢰성 | O | 2 | 1 | 0 | 0 |
| △ | 0 | 0 | 0 | 0 | |
| X | 0 | 1 | 2 | 2 | |
| 유지관리성 | O | 7 | 5 | 2 | 3 |
| △ | 0 | 1 | 1 | 1 | |
| X | 0 | 1 | 4 | 3 | |
표 ４ 종합 합계 평가표
| A | B | C | D | |
| O | 13 | 15 | 5 | 9 |
| △ | 3 | 2 | 6 | 5 |
| X | 3 | 2 | 8 | 5 |
종합 평가와 같이 기능성 경우 “O”의 개수가 많다고 좋은 도구라고 말할 수는 없으며, 기능성 내 정확성 평가 항목에 있는 빌드 시간, 커버리지, 테스트케이스 등 화이트박스 테스팅 도구로써의 주요 기능이 얼마나 빠르고 커버리지가 높은지가 더욱 중요합니다. 또한, 다른 도구들과 달리 “B” 도구는 복잡한 프로젝트(“mathc”를 제외한 9개)도 어렵지 않게 빌드 환경을 구성해 [표 2]와 같이 계획 된 테스트를 정상적으로 진행했다는 점에서 매우 긍정적인 평가를 줄 수 있습니다.해당 포스팅에서 화이트박스 자동화 테스팅 도구에 대한 평가 지표를 정의해 화이트박스 자동화 테스팅 도구에 대한 중요성과 사용자가 개입하지 않아도 자동으로 테스트케이스를 생성하고 테스트 해주는 것이 매우 흥미로웠습니다. 각각의 도구들의 장단점이 존재하고 프로젝트의 특색과 용도에 맞게 적절히 도구를 사용한다면 소프트웨어를 안전하게 사용하고 품질 향상을 기대할 수 있을 것이라고 생각합니다.
참고 문헌
[1] http://www.splex.co.kr/
[2] Herlim, Robert Sebastian, Yunho Kim, and Moonzoo Kim. “CITRUS: Automated Unit Testing Tool for Real-world C++ Programs.” 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE, 2022.
[3] https://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000195991
[4] https://www.suresofttech.com/ko/html/tool/code_controller.php
[5] https://www.codemind.co.kr/product/coyote.php
[6] http://www.soft4soft.com/main/product.php?gMenu=202
[7] https://www.qa-systems.com/tools/cantata/
[8] https://www.vector.com/kr/ko/products/products-a-z/software/vectorcast/vectorcast-c/
[9] https://www.parasoft.com/products/parasoft-c-ctest/
[10] https://ldra.com/
[11] https://www.youtube.com/watch?v=HfyA6r-6Z7U
[12] https://codemind.tistory.com/19
[13] https://github.com/vurtun/nuklear
[14] https://github.com/jedisct1/libsodium
[15] https://github.com/aws/s2n-tls
[16] https://github.com/aubio/aubio
[17] https://github.com/evonove/qnite
[18] https://github.com/jbeder/yaml-cpp
[19] https://github.com/mn416/QPULib
[20] https://github.com/felselva/mathc
[21] https://github.com/tgockel/json-voorhees
[22] https://github.com/open-source-parsers/jsoncpp
[23] https://moo-you.tistory.com/202