자율주행 등 소프트웨어에 의존하는 시대 도래...소프트웨어 테스팅의 중요성 더욱 커져
KAIST 사이버보안연구센터-보안뉴스, ‘화이트박스 테스팅 도구 4종 기능 및 성능분석’ 결과 발표
2023년 화이트박스 테스팅 시작으로 안티바이러스, 차세대 방화벽 등 성능 테스트 계획
[보안뉴스 김영명 기자] 우리는 눈에 보이지 않는 소프트웨어의 그물망 속에 살아가고 있다고 비유할 수 있다. 빅데이터, AI, IoT, 클라우드 등 4차 산업혁명의 시대에 들어서면서 우리가 언급하는 이 모든 것들은 ‘소프트웨어(Software)’라는 큰 테두리 안에 하나의 구성요소로 자리하고 있다.
[이미지=utoimage]
최근 소프트웨어의 중요성이 더욱 빛을 발하고 있다. 소프트웨어 결함의 결과는 인간의 생명을 위협할 정도로 크다. 실제 사례로 2018년 미국의 승차 공유 서비스 우버(Uber)의 자율주행 자동차가 횡단보도를 건너던 40대 여성을 들이받아 사망사고를 냈다. 이는 자율주행차의 첫 보행자 사망사고로 이목을 끌었으며, 자율주행 소프트웨어의 안전성과 위험성이 이슈가 됐다.
이에 한국과학기술원(KAIST) 사이버보안연구센터(CSRC)와 보안뉴스는 수많은 소프트웨어의 안전성을 테스트하는 소프트웨어인 ‘소프트웨어 테스팅 도구’를 집중분석했다. KAIST 사이버보안연구센터와 보안뉴스는 지난해 오픈소스 취약점 분석 도구를 시작으로 올해 화이트박스 테스팅 도구와 안티바이러스, 개인정보 비식별화 솔루션, 차세대 방화벽 등에 대한 성능 테스트를 계획 중에 있으며, 화이트박스 테스트 도구 기능·성능 분석은 올해 첫 결과물이라고 할 수 있다.
‘소프트웨어 테스팅(Software testing)’은 크게 테스트 수행 방식에 따라 △블랙박스 테스팅(blackbox testing) △화이트박스 테스팅(whitebox testing) △그레이박스 테스팅(graybox testing) 등 세 가지로 나눌 수 있다.
먼저 ‘블랙박스 테스팅’은 Input/Output 값에 따라 원하는 결과가 일치하는지를 확인하기 위한 입출력 데이터 기반 검증 및 결함 도출 테스트 기법이다. ‘화이트박스 테스팅’은 내부 로직의 검증 기법으로 제품 컴포넌트(함수) 로직의 정상 동작 여부를 확인하기 위해 제품 내부 구조 기반 검증과 결함 도출 테스트 기법이다. 마지막으로 ‘그레이박스 테스팅’은 블랙박스 테스팅과 화이트박스 테스팅의 장점을 결합해 기존 기법으로 찾지 못한 결함을 찾을 수 있다.
전통적으로 화이트박스 테스팅은 내부(개발자 또는 소스코드) 관점에서 테스트를 수행하는 기법을 말한다. 또한, 바이너리 테스팅은 기술의 발전으로 어떠한 제약 없이 블랙박스, 화이트박스, 그레이박스 등 세 가지 테스팅 기법 모두에 적용될 수 있다. 또한, 최근 연구가 활발하게 진행되고 있는 퍼징기술은 소프트웨어 테스팅을 논할 때 빠져서는 안 될 기술이다. 퍼징은 컴퓨터 프로그램에 예상치 않은 무작위 데이터를 입력하여 프로그램 충돌 및 결함을 발견하는 기술로, 이러한 퍼징 기술 또한 블랙박스, 화이트박스, 그레이박스 테스팅 기법 모두에 사용할 수 있다.
▲블랙박스 테스트와 화이트박스 테스트 비교[자료=카이스트 CSRC]
지난 40년 내 크고 작은 국내외 소프트웨어 사고 사례
1985년 캐나다의 의료기기 회사 AECL이 개발한 테락-25(Therac-25) 방사선 치료기기의 소프트웨어 오류로 인해 환자에게 방사선이 과다하게 노출돼 5명이 사망했다. 이 사고는 과다한 방사선에 노출되는 최초의 소프트웨어 결함 사고 사례로 알려졌다. 1988년 프랑스의 초대형 여객기 에어버스(Airbus) A320 추락사고는 비행모드 전환 시 소프트웨어 결함으로 발생했다.
1996년에 발사 37초만에 폭발한 아리안 5 로켓 사고는 내부 시스템의 버퍼 오버플로로 폭발했으며, 1999년 화성 극지 착륙선은 착륙 직전 소프트웨어 결함으로 추락했다. 2009년 도요타 급발진 사망사고는 ECU 내 메모리 영역에서 소프트웨어 오류 발생으로, 같은 해 임진강 재해경보 시스템 오작동은 수위 정보를 전송하는 RTU 고장으로 발생했다.
2011년 교육행정정보서비스(NICE) 성적처리 오류는 고교생 2만9,000여명 석차 등급 변경을 불러일으켰으며, 2012년 의료서비스 윤일(Leap Day) 버그는 소프트웨어 결함으로 2012년 2월 29일 윤일을 인식하지 못해 시스템이 마비되기도 했다. 2014년에는 영국 런던공항 관제시스템에 장애가 발생해 이착륙이 지연되고 공항이 폐쇄되는 결과를 초래했다. 2015년 닛산 에어백 소프트웨어의 고장 사고는 소프트웨어 결함으로 조수석에 앉은 사람을 비식별해 에어백이 작동하지 않았으며, 2018년에는 우버 자율주행자동차의 소프트웨어 결함으로 충돌 전 긴급 제동장치가 작동하지 않아 사망사고가 일어났다. 2021년 테슬라는 소프트웨어 결함으로 인해 전방 충돌 경고 및 비정상적인 긴급 제동장치가 작동해 1만2,000대를 리콜하기에 이르렀다. 이렇듯 소프트웨어 결함으로 인한 사고는 국내외에서 다양하게 발생하고 있다.
소프트웨어 결함 사고는 언제든 일어날 수 있기 때문에 결함을 제거하는 역할이 중요해지고 있다. 하지만, 가시적이지 않은 소프트웨어의 특성상 결함을 감지하는 것은 매우 어렵고 많은 시간과 노력이 소요된다. 소프트웨어가 여러 분야에서 중요한 역할을 수행하지만, 소프트웨어의 복잡도가 증가하면서 장애 발생 사고도 늘어나고 있다. 따라서, 선행적으로 안전한 소프트웨어 개발의 필요성이 주목받고 있으며, 소프트웨어 테스팅의 필요성이 높아지고 있다. 안전한 소프트웨어 개발을 위해서는 위험 원인 분석과 함께 위험도 기준을 만드는 것이 중요하다.
위험한 원인 분석 및 평가를 위해서는 △Failure Mode and Effects Analysis(FMEA) △Fault Tree Analysis(FTA) △System Theoretic Process Analysis(STPA) 등 정형화 기법들이 존재하지만, 소프트웨어의 정확하고 체계적인 테스팅이 더 중요하다. 클라이언트의 요구사항을 확인하기 위해서는 사용자 관점의 블랙박스 테스팅 기법이 중요하지만, 소프트웨어의 안전성과 결함을 세밀하게 찾으려면 개발자 관점에서의 화이트박스 테스팅이 필요하다.
화이트박스 테스팅은 무엇을 의미하는가
화이트박스 테스팅이란 응용프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방법이다. 개발된 소스 코드를 모두 공개한 상태에서 소스 코드의 논리적인 모든 경로를 따라가면서 테스트 케이스를 작성하는 것으로, 설계된 절차에 따라 프로그램이 개발됐는지 확인하는 구조적 테스트와 테스트 과정 초기에 적용해 테스트 케이스를 생성하는 것을 의미한다.
▲소프트웨어 테스팅 개념도[자료=카이스트 CSRC]
화이트박스 테스트에는 △수행 가능한 모든 경로를 검사하는 ‘기초 경로 검사(Basic Path Testing)’ △프로그램의 조건문에 초점을 맞춰 모든 조건문을 통과하는 테스트를 진행하는 ‘조건 검사(Condition Testing)’ △프로그램의 반복 구조에 초점을 맞춰 검사하는 ‘루프 검사(Loop Testing)’ △프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 검사하는 ‘데이터 흐름 검사(Data Flow Testing)’ 등 4가지 종류가 있다.
소프트웨어 테스트, 자동화는 불가능한 영역인가
화이트박스 테스팅은 자동차, 항공, 선박에 들어가는 소프트웨어의 테스팅에 사용된다. 최근 자동차 제조 기업들은 전자장비 비중이 높아지면서 소프트웨어 품질에도 심혈을 기울이며 중요성이 더욱 커지고 있다. 국제표준화기구(ISO)는 2012년 자동차 전기·전자 장치의 테스트 기준(ISO 26262)을 국제 표준으로 제정했으며, 소프트웨어에 대한 기준도 포함됐다.
소프트웨어 테스팅이 중요해지는 시점에서 소프트웨어의 품질과 안정성, 신뢰성을 높이기 위한 효과적인 방법은 화이트박스 테스팅을 통해 소프트웨어를 검증하고 결함을 찾아 수정하는 것이다. 이를 위해서는 명확한 테스트 케이스를 만들어내는 것이 선행돼야 한다.
전통적으로 테스트 케이스는 요구 명세를 근거로 각 입력값을 사용자가 수동으로 생성했다. 하지만 최근 대형화와 복잡화된 IT 환경에서 보다 효율적인 분석·설계 작업의 필요성이 제기되면서 쉽고 편리하게 입력값을 생성하도록 화이트박스 테스트 자동화 기법에 대해 활발한 연구가 진행됐다. 이에 따라 화이트박스 테스트 시장에 다양한 자동화 도구가 등장하고 있다.
그렇다면, 과연 대형화 복잡화된 소프트웨어(시스템)라고 해서 수많은 테스트 케이스를 생성하는 자동화 도구가 과연 좋은 도구인지 아니면 가능한 적은 수의 테스트 케이스를 생성해 빠르게 테스팅하는 도구가 좋은 도구인지 생각해 볼 필요가 있다. 사실, 도구마다 테스트 케이스 생성 기준이 다르고 테스팅 방법론이 다르기 때문에 사용자(고객) 입장에서는 제품 소개서, 시장 점유율에 의존해 화이트박스 테스팅 자동화 도구를 선택해야 한다는 문제점이 있다.
다음은 오픈소스 프로젝트에 대해 실제 화이트박스 테스팅 도구를 이용해 테스트 케이스를 생성해 보며 각 도구의 기능과 성능을 분석한 결과를 살펴보고자 한다.
화이트박스 테스팅 자동화 도구 7종은 무엇?
C/C++ 언어로 구현된 프로젝트(소스 코드)를 대상으로 테스트 케이스 생성이 가능한 자동화 도구는 △Controller Tester △Coyote △Resort △Cantata++ △VectorCAST/C++ △ParaSoft C/C++ △LDRA 등 7개가 있다.
먼저, ‘Controller Tester’는 우리나라 기업인 ‘슈어소프트테크’에서 개발한 단위 및 통합 테스트를 수행하는 테스트 자동화 솔루션이다. 이 도구는 자동으로 테스트 및 테스트 데이터 생성할 수 있으며, 테스트에 필요한 시뮬레이션 및 실제 타깃 환경 테스트 지원이 가능하다.
두 번째로 ‘Coyote’는 국내 기업 코드마인드에서 개발했으며, 심볼릭 테스팅 기술과 머신러닝 기술이 융합된 완전 자동 화이트박스 테스팅 도구다. 이 제품은 심볼릭 테스팅 기술을 통해 커버된 분기나 경로를 가능한 한 다시 접근하지 않아 효율적이다.
세 번째로 ‘Resort’는 국내 기업 Soft4Soft에서 개발한 도구로, 정적 분석을 통해 코드 컴파일 과정 없는 소스코드 분석, 프로시저 간 경로 분석의 최상위 코드 검증 등이 가능하다. 동적 분석으로 코드 요구 기반 경로 테스트 자동화, 테스트 데이터 자동 생성을 할 수 있다.
네 번째로 ‘Cantata++’는 독일 기업인 QA Systems에서 개발했으며, 국내 제품 판매는 한컴엔플럭스와 유피에스테크놀로지가 담당하고 있다. 이 도구는 단위 및 확장 가능한 통합 테스트를 종합해 프레임워크를 제공하며, 기능 테스트 및 통합 코드 검사 결과 분석을 지원한다. 이밖에도 다양한 포맷으로 보고서 생성 가능, Eclipse 사용자에게 익숙한 UI 제공, 코드 커버리지 테스트 결과 시각화, 필요한 모든 코드 경로를 실행하는 단위 테스트 모음을 자동 생성 등의 특징이 있다.
다섯 번째로 ‘VectorCAST/C++’는 일본 기업인 Vector에서 개발했으며, 국내 지사가 있다. 이 제품은 소프트웨어의 안전을 우선하는 임베디드 시스템을 검증하는데 특화됐으며, 단위 및 통합 테스트 환경을 자동으로 구성해 테스트 코드 작성이 필요 없는 사용자에게 편리한 테스트 환경을 제공한다. 또한, GUI·스크립트를 통한 테스팅 지원, 코드 커버리지, 회귀 테스트, 코드 복잡도 계산 등이 가능하며, 내장 컴파일러가 존재해 컴파일 환경 구축이 필요 없다.
여섯 번째로 ‘ParaSoft C/C++’는 미국 ParaSoft에서 개발했으며, 국내에서는 VWAY 등이 담당하고 있다. 이 제품은 검증 보고서를 자동으로 생성하고, C/C++ IDE, CI/CD 파이프라인과 컨테이너화된 배포에 통합해 결함을 조기에 감지한다.
일곱 번째로 ‘LDRA’는 영국 기업 LDRA에서 개발된 도구로 국내 기업인 모아소프트가 판매하고 있다. 이 도구는 45년 이상 소프트웨어 분석과 자동화 테스팅 도구 시장을 주도하고 있다.해외에서도 항공우주 및 방위, 자동차, 산업 및 에너지 소프트웨어 테스팅에 많이 사용된다.
화이트박스 테스트 도구는 어떤 기능 및 요소가 중요할까?
화이트박스 테스트 도구의 기능과 성능 분석 연구를 위한 지표 수립을 위해 소프트웨어 진흥법(법률 제17799호) 제49조 제2항 ‘소프트웨어 기술성 평가 기준 지침’ 내 평가 기준에 따른 상용 소프트웨어 평가 항목 및 배점 한도(제3조 제2항 관련)와 국제 표준 소프트웨어 평가 기준인 ISO 25010을 참고했다. 기능 및 성능 분석 연구 지표는 △평가 부분 △평가 항목 △평가 기준 순으로 분류했으며, 34개 기준으로 세분해 화이트박스 테스팅 자동화 도구 평가 기준을 수립했다. 특히, ISO 국제 표준은 이를 △평가 기준의 광범위한 포괄성 △평가 기준의 모호함 △평가 기준의 불필요성 등을 설정했지만, 이러한 부분을 축소하고 수정했다.
▲국제 표준 ISO 25010 평가항목[자료=스플렉스]
ISO 25010 국제 표준의 평가항목에서 ‘기능적합성’은 ‘기능성’으로 수정했으며, ‘기능성숙도’, ‘기능 정확성’, ‘기능타당성’을 하나의 ‘정확성’으로 묶어 기능 측면에서 정확도를 평가할 수 있도록 했다. 기존 ‘보안성’의 ‘기밀성’, ‘부인방지’ 등은 화이트박스 테스팅 도구로 특별히 평가할 방법이 없어 별도의 평가 항목으로 구분하지 않고 기능성 항목에 추가해 최소한의 보안성이 평가되도록 했다. ISO 25010 국제 표준에서의 ‘사용성’과 ‘신뢰성’은 그대로 유지했지만, ‘신뢰성’ 항목의 ‘성숙성’, ‘결함 수용성’ 등은 의미가 미미해 평가 기준에서 제외했다. ‘사용성’은 대부분의 평가 항목을 그대로 유지했다. 또한, ‘실행효율성’, ‘이식성’, ‘호환성’은 화이트박스 테스팅 도구 평가로 수용할 수 있는 부분을 ‘사용성’과 ‘신뢰성’에 분산해 평가 기준을 수립했으며, 상위 카테고리인 ‘사용 품질’에서 ‘안정성’은 ‘운용안정성’으로 ‘신뢰성’에 포함했다. 재정립한 전체적인 평가 항목과 기준은 다음과 같다.
▲수립한 평가 항목[자료=카이스트 CSRC]
화이트박스 테스트 평가에 사용할 오픈소스 선정은?
화이트박스 테스팅 도구는 항공우주, 방위, 자동차 등 고신뢰성·안전성이 필요한 소프트웨어 또는 생명에 직접적인 산업 분야에서 사용된다. 대부분의 개발 언어가 C/C++로 이뤄졌으며, 화이트박스 자동화 테스팅 도구들이 목표로 하는 시장도 C/C++ 언어로 이뤄졌다.
연구팀에서 사용된 오픈소스도 C/C++ 위주의 UI, 암호화, 신호처리, 통신 프로토콜 등 여러 분야에서 사용되는 오픈소스를 선정했으며, ‘CITRUS : Automated Unit Testing Tool for Real-world C++ Programs’ 논문을 참고했다. 선정된 오픈소스는 화이트박스 자동화 테스팅 위해 프로젝트 자체로 빌드가 가능한 프로젝트를 대상으로 했다.
▲평가를 위한 프로젝트 항목[자료=카이스트 CSRC]
화이트박스 자동화 테스팅 도구 선정 및 오픈소스 프로젝트 테스트 결과
화이트박스 자동화 테스팅 도구 선정을 위해 7개의 도구 중 제품의 시장 점유율, 제품 소개 및 지원에 가장 적극적인 4개 도구(A, B, C, D)를 선정했으며, 이를 이용해 프로젝트를 테스트했다. 특히, A, B, D 제품은 3번 ‘mathc’ 프로젝트만은 정상으로 테스트했지만, C 제품은 ‘mathc’ 프로젝트와 연구팀 선정 10개 프로젝트 모두 불가능했다.
‘mathc’ 프로젝트 외 9개 오픈소스 프로젝트는 빌드가 정상적으로 수행되지 않아 연구팀에서는 테스트 진행이 불가능했다. 따라서 각 기업에 사용과 기술 지원을 요청했다. 그 결과 4개 도구 중 ‘B’ 테스팅 도구의 경우 프로젝트 화이트박스 테스팅을 위해 간단한 설정 파일 제공을 지원받았고, 수일 내로 쉽게 자동화 상태에서 10개 프로젝트의 테스트를 모두 완료했다.
3개(A, C, D) 테스팅 도구의 경우 사용 과정이 프로젝트마다 지원을 받아야 할 정도로 복잡했다. 다만 ‘B’ 도구가 90% 이상 ‘자동화 테스팅 도구’의 의미에 부합해 우수성이 뛰어났다. 모든 평가 항목과 기준 평가는 비교 분석 측면에서 다소 부족함이 있다. 다만, ‘C’를 제외한 나머지 3개 도구는 ‘mathc’ 프로젝트를 모두 정상적으로 빌드하고 테스트가 가능해 ‘mathc’에 한정해 4개의 화이트박스 자동화 테스팅 도구의 기능 및 성능 평가를 진행했다.
▲‘B’ 자동화 테스팅 도구의 화이트박스 테스팅 결과[자료=카이스트 CSRC]
화이트박스 자동화 테스팅 도구 평가
이번 평가는 O : 기능 지원 및 제공, △ : 미흡 및 정보 부족, X : 지원 및 제공하지 않음 등 세 가지로 평가를 측정했으며, 시간, 카운팅, ‘%’가 필요한 항목은 별도로 표시했다. 해당 평가 방법에서 지원되지 않는 경우는 ‘X’가 아닌 ‘미지원’으로 구분, 종합 평가 시 ‘X’가 카운팅돼 평가 개수가 달라지는 것을 방지해 오해가 생기지 않도록 공정한 평가를 진행했다.
평가 항목 1. 기능성
기능성은 화이트박스 자동화 테스팅 도구에 가장 중요한 기능을 평가하는 항목으로 분석(탐지)된 코드 정보들과 테스트 케이스 개수, 커버리지 정보를 평가했다. 기본은 10개의 오픈소스 프로젝트를 기준으로 평가해야 하지만, 앞서 설명한 이유로 화이트박스 자동화 테스팅 평가 항목 중 가장 중요한 항목 중 일부는 ‘mathc’ 프로젝트를 기준으로 평가 비교했다. 하지만 ‘C’ 제품은 자동화 테스트가 가능하다고 했지만 테스트할 수 없었다. ‘C’ 제품을 테스트하려면 테스트 코드를 작성해야 했으며, 작성도 오랜 시간이 소요돼 일부 테스트에서 배제했다.
①빌드시간 측정 : ‘mathc’ 소스코드 파일 사이즈는 159kb이었으며, 총 코드라인 수가 5,586개인 코드의 빌드시간을 측정한 값으로 ‘B’ 도구가 24초로 가장 빨리 빌드했다. ‘A’ 도구는 2분 27초를 기록해 6배 이상 차이가 발생했다.
②테스트 완료 시간 : 화이트박스 테스팅 도구가 완전히 테스트를 끝내고 완료된 시간으로 ‘D’ 도구는 2분 50초로 가장 빨랐으며, ‘A’ 도구의 경우 25분으로 제일 늦었다.
③사전 빌드파일 : 사전 빌드는 테스트가 정상적으로 진행되는지 여부를 확인하는 것으로, ‘B’ 도구는 실제 빌드할 소스코드를 ‘1개’라고 탐지(분석)했는데, 기본으로 헤더 파일을 제외했다. ‘D’ 도구의 경우에는 헤더파일까지 포함해 탐지(분석)해 ‘2개’가 됐다.
④탐지된 파일 개수 : 테스트 완료 후 분석(탐지)된 소스코드(파일) 개수로 ‘B’ 도구만 ‘1개’라고 탐지했다. 이는 이전 평가 기준과 마찬가지로 헤더파일을 제외하고 카운팅이 됐으며, 나머지 3개의 도구는 테스트가 불가능하거나 정보가 없어 ‘미지원’으로 평가했다.
⑤탐지된 함수 개수 : 테스트 완료 후 분석(탐지)된 함수 개수다. ‘B’와 ‘D’ 제품은 탐지한 함수가 실제 함수 개수와 일치했지만 ‘A’와 ‘C’ 도구의 경우 탐지가 불가능했다.
⑥실제 빌드파일 개수 : 실제 테스트를 위한 빌드 단계이며, 사전 빌드 파일 개수와 다를 수 있다. 실제 빌드할 소스코드(파일)에 대해 ‘B’ 도구의 경우 ‘1개’라고 탐지(분석)했는데, ‘B’ 도구의 경우 헤더파일을 제외한 개수를 결과로 나타냈으며, ‘D’ 도구의 경우 헤더파일까지 포함해 탐지(분석)해 결과가 ‘2개’였다. 나머지 두 개의 도구는 확인되지 않았다.
⑦탐지된 코드라인 개수 : 화이트박스 자동화 테스팅 도구로 실행된 코드라인 수이며, 실행 가능 유무와 특수문자 ‘{ }’만 있는 라인 등을 제거해 최적화된 테스트 가능한 라인 개수를 탐지했다. ‘A’ 도구는 2,877개 라인을 탐지했지만, ‘B’ 도구의 경우 ‘A’보다 약 1,700개가 많은 4,500개 라인을 분석했다. ‘C’와 ‘D’ 도구의 경우는 파악이 불가능했다.
▲기능성 평가항목(정확성+보안성)[자료=카이스트 CSRC]
⑧탐지된 브랜치 개수 : 화이트박스 자동화 테스팅 도구가 코드 내에 브랜치(조건문) 항목의 개수이며, 평가에서는 If(else)만 갖고 개수(138개)를 비교했다. ‘A’ 도구의 경우 1,045개를 탐지했고, ‘B’ 도구의 경우 기준과 가장 근접한 190개, ‘D’ 도구의 경우 978개가 탐지됐다. 해당 평가 항목은 도구의 특성에 따라 구하는 값이 달라져 정답이 있지는 않다.
⑨라인 커버리지 값 : ‘⑦’ 평가 기준 결과를 바탕으로 얼마나 많은 라인을 테스트했는지에 대한 ‘%’ 값이다. 예를 들어 ‘A’ 도구는 ‘⑦’에서 2,877개의 라인을 탐지했으며, 커버리지 값은 98%였다, 이 의미는 ‘A’ 도구는 2,877개의 라인으로부터 2,819개(98%) 라인을 적어도 한번은 테스트했다는 것을 보여준다. ‘A’와 ‘D’의 경우 ‘%’ 값은 같지만, ‘D’가 찾은 라인 수를 확인할 수 없었으며, ‘B’ 도구의 경우 4,192개의 라인을 100% 커버했다.
⑩브랜치 커버리지 값 : ‘⑧’ 평가 기준 결과를 바탕으로 테스트 시 얼마나 많은 브랜치(조건문)를 테스트했는지에 대한 ‘%’ 값이다. 예를 들어 ‘B’ 도구는 ‘⑧’에서 190개의 브랜치를 탐지했으며, 커버리지 값은 100%였다. ‘B’와 ‘D’는 커버리지 값이 같고, ‘A’도구의 경우 95%의 브랜치 커버리지를 보여줘 가장 낮았다. 단, 평가가 불가능한 ‘C’는 제외했다.
⑪코드별(파일) 라인 커버리지 지원 여부 : 도구의 결과(보고서)로 코드(파일)별로 라인 커버리지를 보여주는 기능이 있는지 혹은 지원되는지에 대한 평가 항목이다. ‘C’ 도구를 제외하고 3개 도구 모두 코드(파일)별 지원이 가능했다.
⑫코드별(파일) 브랜치 커버리지 지원 여부 : 도구의 결과(보고서)로 코드(파일)별로 브랜치 커버리지를 보여주거나 지원되는지에 대한 평가 항목이다. ‘⑪’ 평가항목과 동일하게 ‘C’를 제외하고 3개 도구 모두 코드(파일)별 지원이 가능했다.
⑬생성된 전체 테스트 케이스 수 : 화이트박스 자동화 테스팅 도구가 테스트 케이스를 직접 만들고 테스트한 수의 결과다. ‘A’ 도구의 경우 2,461개, ‘B’ 도구는 1,479개, ‘C’ 도구는 978개로 가장 적었다. 도구마다 알고리즘과 방법이 달라 이 개수는 무의미하다.
첫 번째 ‘기능성’ 평가에서 4개의 도구 중 유일하게 모든 프로젝트 테스트가 가능해 나온 결과 테이블인 그림 7의 커버리지를 보면 ‘mathc’ 프로젝트만 높았다. 또한, ‘mathc’만 테스트가 가능했던 ‘A’, ‘D’의 커버리지 값이 높았는데, ‘mathc’ 프로젝트는 소스코드 간 종속성이 없는 단순한 산술 연산값을 리턴하는 함수로 이뤄진 소스 코드이기 때문인 것으로 추정된다. 또한, 화이트박스 자동화 테스팅 도구에서는 적은 테스트케이스로 높은 커버리지를 달성하는 것이 중요하다. 케이스가 많으면 커버리지에 기여하지 않은 케이스가 많을 가능성이 크다.
▲사용성, 신뢰성, 유지관리성 평가항목[자료=카이스트 CSRC]
평가 항목 2. 사용성
사용성은 사용자 중심의 학습 및 사용에 대한 전반적인 평가 항목이다. ‘⑰’ 항목의 경우 ‘B’ 제품과 ‘C’ 제품은 사용 순서에 따라 매뉴얼이 잘 작성돼 흐름을 이해하기 편했지만, ‘A’와 ‘D’의 경우 매뉴얼의 내용이 부실하고 테스트 환경을 구축하는 부분에서 사용자가 이해하기 어려워 자체적으로 테스트가 불가능했다. ‘⑱’ 항목은 대부분 메인 기능에 중점적으로 작성됐다. 세부적인 기능 설명이 없어 설정이 어려웠으며, ‘B’ 제품의 경우 세부 기능을 모두 설명하고, 테스트에 필요한 요소와 변경 및 그에 따른 영향을 설명했다.
‘㉒’ 항목에서 ‘B’ 제품의 경우 별도의 컴파일러 설치 없이 테스트할 수 있어 다른 도구들에 비해 매우 편리했으며, 나머지 3개의 제품의 경우 내부 컴파일러가 있으나, 제대로 동작하지 않거나 별도의 컴파일러를 설치해야 했다. ‘㉕’ 항목은 ‘B’와 ‘D’ 모두 특정 모듈 및 필요 함수만 선택해 원하는 정보만 보고서로 만들 수 있으나, 선택 가능한 영역이 한정적이었다.
평가 항목 3. 신뢰성
신뢰성 평가 항목은 화이트박스 테스팅 도구의 자체 안정성 및 문제 발생시 회복성 평가 항목이다. ‘㉖’ 항목의 경우 ‘A’ 도구만 안정적으로 테스트가 가능했으며, 나머지 3개의 도구는 테스트가 되지 않거나 에러 메시지와 함께 비정상으로 종료됐고, 테스트 도중 프리징 현상이 발생해 도구를 강제종료해야 해 ‘X’로 평가했다. ‘㉗’ 항목의 경우 ‘A’는 안정적인 동작을 통해 장애가 발생하지 않아 ‘O’로 평가했고, ‘B’는 이미 수행된 부분은 건너뛰고 장애 시점부터 다시 테스트를 진행하기 때문에 ‘O’로 평가했다. 다른 2개의 도구의 경우 각자 테스팅 도중 멈춘 시점부터 시작하지 않고 새롭게 테스트를 시작해야 하므로 ‘X’로 평가했다.
평가 항목 4. 유지관리성
유지관리성 항목은 공급업체 또는 유지보수 업체를 통해 기술지원을 통해 문제를 파악하고 지원받을 수 있는 항목과 사용자 입장에서 테스트할 타겟(프로젝트)의 관리 측면에서 평가하는 항목이다. ‘㉘’ 항목의 경우 시스템 사용 중 오류가 발생할 경우 ‘△’ 평가를 받은 3개의 도구는 조치 방법 또는 방안에 알려주지 않거나 관련 문서가 없었다. ‘A’ 도구는 테스트 도중 Stub(프로그램 테스트를 위한 더미 코드)이 존재하지 않은 경우 해결 방안을 제시하기도 했다. 또한, ‘㉜’와 ‘㉝’ 항목의 경우 ‘B’ 도구는 별도의 계정을 발급해 조직·팀별로, ‘A’와 ‘D’ 도구는 별도의 확장프로그램 설치를 통해 조직·팀별로 작업 공간을 분리할 수 있다.
이번 연구에서는 화이트박스 자동화 테스팅 도구에 대해 알아보고, 화이트박스 자동화 테스팅 도구의 기능 및 성능을 분석할 수 있는 평가 기준을 수립했다. 또한, 4개의 화이트박스 자동화 테스팅 도구를 이용해 선정한 10개의 오픈소스 프로젝트를 테스트했으며, 34개의 세부 항목을 평가해 각 도구의 기능과 성능, 특징을 정량·정성적으로 측정했다. 도구들의 평가는 그림 12(상단)와 같으며, 평가 항목별 가장 좋은 평가를 받은 제품은 파란색으로 표시했다.
▲종합 평가표(상) 및 종합 합계 평가표(하)[자료=카이스트 CSRC]
종합 평가와 같이 기능성 경우 ‘O’의 개수가 많다고 좋은 도구라고 말할 수는 없으며, 기능성 내 정확성 평가 항목에 있는 빌드 시간, 커버리지, 테스트케이스 등 화이트박스 테스팅 도구로써의 주요 기능이 얼마나 빠르고 커버리지가 높은지가 더욱 중요하다. 또한, 다른 도구들과 달리 ‘B’ 도구는 복잡한 프로젝트(‘mathc’를 제외한 9개)도 어렵지 않게 빌드 환경을 구성해 그림 7과 같이 계획된 테스트를 정상적으로 진행했다는 점에서 긍정적이었다.
이번 연구를 진행한 KAIST 사이버보안연구센터(CSRC) 신강식 연구원과 이정호 연구원은 “화이트박스 자동화 테스팅 도구에 대한 평가 지표를 정의해 화이트박스 자동화 테스팅 도구의 중요성에 대해 더욱 깊이 인식하게 된 것이 의미 있었고, 사용자가 개입하지 않아도 자동으로 테스트 케이스를 생성하고 테스트하는 것이 흥미로웠다”며 “도구별 장단점이 있고 프로젝트의 특색과 용도에 맞게 적절히 도구를 사용한다면 소프트웨어를 안전하게 사용할 수 있고 품질 향상도 기대할 수 있을 것”이라고 말했다.
[김영명 기자(boan@boannews.com)]
KAIST 사이버보안연구센터-보안뉴스, ‘화이트박스 테스팅 도구 4종 기능 및 성능분석’ 결과 발표
2023년 화이트박스 테스팅 시작으로 안티바이러스, 차세대 방화벽 등 성능 테스트 계획
[보안뉴스 김영명 기자] 우리는 눈에 보이지 않는 소프트웨어의 그물망 속에 살아가고 있다고 비유할 수 있다. 빅데이터, AI, IoT, 클라우드 등 4차 산업혁명의 시대에 들어서면서 우리가 언급하는 이 모든 것들은 ‘소프트웨어(Software)’라는 큰 테두리 안에 하나의 구성요소로 자리하고 있다.
[이미지=utoimage]
최근 소프트웨어의 중요성이 더욱 빛을 발하고 있다. 소프트웨어 결함의 결과는 인간의 생명을 위협할 정도로 크다. 실제 사례로 2018년 미국의 승차 공유 서비스 우버(Uber)의 자율주행 자동차가 횡단보도를 건너던 40대 여성을 들이받아 사망사고를 냈다. 이는 자율주행차의 첫 보행자 사망사고로 이목을 끌었으며, 자율주행 소프트웨어의 안전성과 위험성이 이슈가 됐다.
이에 한국과학기술원(KAIST) 사이버보안연구센터(CSRC)와 보안뉴스는 수많은 소프트웨어의 안전성을 테스트하는 소프트웨어인 ‘소프트웨어 테스팅 도구’를 집중분석했다. KAIST 사이버보안연구센터와 보안뉴스는 지난해 오픈소스 취약점 분석 도구를 시작으로 올해 화이트박스 테스팅 도구와 안티바이러스, 개인정보 비식별화 솔루션, 차세대 방화벽 등에 대한 성능 테스트를 계획 중에 있으며, 화이트박스 테스트 도구 기능·성능 분석은 올해 첫 결과물이라고 할 수 있다.
‘소프트웨어 테스팅(Software testing)’은 크게 테스트 수행 방식에 따라 △블랙박스 테스팅(blackbox testing) △화이트박스 테스팅(whitebox testing) △그레이박스 테스팅(graybox testing) 등 세 가지로 나눌 수 있다.
먼저 ‘블랙박스 테스팅’은 Input/Output 값에 따라 원하는 결과가 일치하는지를 확인하기 위한 입출력 데이터 기반 검증 및 결함 도출 테스트 기법이다. ‘화이트박스 테스팅’은 내부 로직의 검증 기법으로 제품 컴포넌트(함수) 로직의 정상 동작 여부를 확인하기 위해 제품 내부 구조 기반 검증과 결함 도출 테스트 기법이다. 마지막으로 ‘그레이박스 테스팅’은 블랙박스 테스팅과 화이트박스 테스팅의 장점을 결합해 기존 기법으로 찾지 못한 결함을 찾을 수 있다.
전통적으로 화이트박스 테스팅은 내부(개발자 또는 소스코드) 관점에서 테스트를 수행하는 기법을 말한다. 또한, 바이너리 테스팅은 기술의 발전으로 어떠한 제약 없이 블랙박스, 화이트박스, 그레이박스 등 세 가지 테스팅 기법 모두에 적용될 수 있다. 또한, 최근 연구가 활발하게 진행되고 있는 퍼징기술은 소프트웨어 테스팅을 논할 때 빠져서는 안 될 기술이다. 퍼징은 컴퓨터 프로그램에 예상치 않은 무작위 데이터를 입력하여 프로그램 충돌 및 결함을 발견하는 기술로, 이러한 퍼징 기술 또한 블랙박스, 화이트박스, 그레이박스 테스팅 기법 모두에 사용할 수 있다.
▲블랙박스 테스트와 화이트박스 테스트 비교[자료=카이스트 CSRC]
지난 40년 내 크고 작은 국내외 소프트웨어 사고 사례
1985년 캐나다의 의료기기 회사 AECL이 개발한 테락-25(Therac-25) 방사선 치료기기의 소프트웨어 오류로 인해 환자에게 방사선이 과다하게 노출돼 5명이 사망했다. 이 사고는 과다한 방사선에 노출되는 최초의 소프트웨어 결함 사고 사례로 알려졌다. 1988년 프랑스의 초대형 여객기 에어버스(Airbus) A320 추락사고는 비행모드 전환 시 소프트웨어 결함으로 발생했다.
1996년에 발사 37초만에 폭발한 아리안 5 로켓 사고는 내부 시스템의 버퍼 오버플로로 폭발했으며, 1999년 화성 극지 착륙선은 착륙 직전 소프트웨어 결함으로 추락했다. 2009년 도요타 급발진 사망사고는 ECU 내 메모리 영역에서 소프트웨어 오류 발생으로, 같은 해 임진강 재해경보 시스템 오작동은 수위 정보를 전송하는 RTU 고장으로 발생했다.
2011년 교육행정정보서비스(NICE) 성적처리 오류는 고교생 2만9,000여명 석차 등급 변경을 불러일으켰으며, 2012년 의료서비스 윤일(Leap Day) 버그는 소프트웨어 결함으로 2012년 2월 29일 윤일을 인식하지 못해 시스템이 마비되기도 했다. 2014년에는 영국 런던공항 관제시스템에 장애가 발생해 이착륙이 지연되고 공항이 폐쇄되는 결과를 초래했다. 2015년 닛산 에어백 소프트웨어의 고장 사고는 소프트웨어 결함으로 조수석에 앉은 사람을 비식별해 에어백이 작동하지 않았으며, 2018년에는 우버 자율주행자동차의 소프트웨어 결함으로 충돌 전 긴급 제동장치가 작동하지 않아 사망사고가 일어났다. 2021년 테슬라는 소프트웨어 결함으로 인해 전방 충돌 경고 및 비정상적인 긴급 제동장치가 작동해 1만2,000대를 리콜하기에 이르렀다. 이렇듯 소프트웨어 결함으로 인한 사고는 국내외에서 다양하게 발생하고 있다.
소프트웨어 결함 사고는 언제든 일어날 수 있기 때문에 결함을 제거하는 역할이 중요해지고 있다. 하지만, 가시적이지 않은 소프트웨어의 특성상 결함을 감지하는 것은 매우 어렵고 많은 시간과 노력이 소요된다. 소프트웨어가 여러 분야에서 중요한 역할을 수행하지만, 소프트웨어의 복잡도가 증가하면서 장애 발생 사고도 늘어나고 있다. 따라서, 선행적으로 안전한 소프트웨어 개발의 필요성이 주목받고 있으며, 소프트웨어 테스팅의 필요성이 높아지고 있다. 안전한 소프트웨어 개발을 위해서는 위험 원인 분석과 함께 위험도 기준을 만드는 것이 중요하다.
위험한 원인 분석 및 평가를 위해서는 △Failure Mode and Effects Analysis(FMEA) △Fault Tree Analysis(FTA) △System Theoretic Process Analysis(STPA) 등 정형화 기법들이 존재하지만, 소프트웨어의 정확하고 체계적인 테스팅이 더 중요하다. 클라이언트의 요구사항을 확인하기 위해서는 사용자 관점의 블랙박스 테스팅 기법이 중요하지만, 소프트웨어의 안전성과 결함을 세밀하게 찾으려면 개발자 관점에서의 화이트박스 테스팅이 필요하다.
화이트박스 테스팅은 무엇을 의미하는가
화이트박스 테스팅이란 응용프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방법이다. 개발된 소스 코드를 모두 공개한 상태에서 소스 코드의 논리적인 모든 경로를 따라가면서 테스트 케이스를 작성하는 것으로, 설계된 절차에 따라 프로그램이 개발됐는지 확인하는 구조적 테스트와 테스트 과정 초기에 적용해 테스트 케이스를 생성하는 것을 의미한다.
▲소프트웨어 테스팅 개념도[자료=카이스트 CSRC]
화이트박스 테스트에는 △수행 가능한 모든 경로를 검사하는 ‘기초 경로 검사(Basic Path Testing)’ △프로그램의 조건문에 초점을 맞춰 모든 조건문을 통과하는 테스트를 진행하는 ‘조건 검사(Condition Testing)’ △프로그램의 반복 구조에 초점을 맞춰 검사하는 ‘루프 검사(Loop Testing)’ △프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 검사하는 ‘데이터 흐름 검사(Data Flow Testing)’ 등 4가지 종류가 있다.
소프트웨어 테스트, 자동화는 불가능한 영역인가
화이트박스 테스팅은 자동차, 항공, 선박에 들어가는 소프트웨어의 테스팅에 사용된다. 최근 자동차 제조 기업들은 전자장비 비중이 높아지면서 소프트웨어 품질에도 심혈을 기울이며 중요성이 더욱 커지고 있다. 국제표준화기구(ISO)는 2012년 자동차 전기·전자 장치의 테스트 기준(ISO 26262)을 국제 표준으로 제정했으며, 소프트웨어에 대한 기준도 포함됐다.
소프트웨어 테스팅이 중요해지는 시점에서 소프트웨어의 품질과 안정성, 신뢰성을 높이기 위한 효과적인 방법은 화이트박스 테스팅을 통해 소프트웨어를 검증하고 결함을 찾아 수정하는 것이다. 이를 위해서는 명확한 테스트 케이스를 만들어내는 것이 선행돼야 한다.
전통적으로 테스트 케이스는 요구 명세를 근거로 각 입력값을 사용자가 수동으로 생성했다. 하지만 최근 대형화와 복잡화된 IT 환경에서 보다 효율적인 분석·설계 작업의 필요성이 제기되면서 쉽고 편리하게 입력값을 생성하도록 화이트박스 테스트 자동화 기법에 대해 활발한 연구가 진행됐다. 이에 따라 화이트박스 테스트 시장에 다양한 자동화 도구가 등장하고 있다.
그렇다면, 과연 대형화 복잡화된 소프트웨어(시스템)라고 해서 수많은 테스트 케이스를 생성하는 자동화 도구가 과연 좋은 도구인지 아니면 가능한 적은 수의 테스트 케이스를 생성해 빠르게 테스팅하는 도구가 좋은 도구인지 생각해 볼 필요가 있다. 사실, 도구마다 테스트 케이스 생성 기준이 다르고 테스팅 방법론이 다르기 때문에 사용자(고객) 입장에서는 제품 소개서, 시장 점유율에 의존해 화이트박스 테스팅 자동화 도구를 선택해야 한다는 문제점이 있다.
다음은 오픈소스 프로젝트에 대해 실제 화이트박스 테스팅 도구를 이용해 테스트 케이스를 생성해 보며 각 도구의 기능과 성능을 분석한 결과를 살펴보고자 한다.
화이트박스 테스팅 자동화 도구 7종은 무엇?
C/C++ 언어로 구현된 프로젝트(소스 코드)를 대상으로 테스트 케이스 생성이 가능한 자동화 도구는 △Controller Tester △Coyote △Resort △Cantata++ △VectorCAST/C++ △ParaSoft C/C++ △LDRA 등 7개가 있다.
먼저, ‘Controller Tester’는 우리나라 기업인 ‘슈어소프트테크’에서 개발한 단위 및 통합 테스트를 수행하는 테스트 자동화 솔루션이다. 이 도구는 자동으로 테스트 및 테스트 데이터 생성할 수 있으며, 테스트에 필요한 시뮬레이션 및 실제 타깃 환경 테스트 지원이 가능하다.
두 번째로 ‘Coyote’는 국내 기업 코드마인드에서 개발했으며, 심볼릭 테스팅 기술과 머신러닝 기술이 융합된 완전 자동 화이트박스 테스팅 도구다. 이 제품은 심볼릭 테스팅 기술을 통해 커버된 분기나 경로를 가능한 한 다시 접근하지 않아 효율적이다.
세 번째로 ‘Resort’는 국내 기업 Soft4Soft에서 개발한 도구로, 정적 분석을 통해 코드 컴파일 과정 없는 소스코드 분석, 프로시저 간 경로 분석의 최상위 코드 검증 등이 가능하다. 동적 분석으로 코드 요구 기반 경로 테스트 자동화, 테스트 데이터 자동 생성을 할 수 있다.
네 번째로 ‘Cantata++’는 독일 기업인 QA Systems에서 개발했으며, 국내 제품 판매는 한컴엔플럭스와 유피에스테크놀로지가 담당하고 있다. 이 도구는 단위 및 확장 가능한 통합 테스트를 종합해 프레임워크를 제공하며, 기능 테스트 및 통합 코드 검사 결과 분석을 지원한다. 이밖에도 다양한 포맷으로 보고서 생성 가능, Eclipse 사용자에게 익숙한 UI 제공, 코드 커버리지 테스트 결과 시각화, 필요한 모든 코드 경로를 실행하는 단위 테스트 모음을 자동 생성 등의 특징이 있다.
다섯 번째로 ‘VectorCAST/C++’는 일본 기업인 Vector에서 개발했으며, 국내 지사가 있다. 이 제품은 소프트웨어의 안전을 우선하는 임베디드 시스템을 검증하는데 특화됐으며, 단위 및 통합 테스트 환경을 자동으로 구성해 테스트 코드 작성이 필요 없는 사용자에게 편리한 테스트 환경을 제공한다. 또한, GUI·스크립트를 통한 테스팅 지원, 코드 커버리지, 회귀 테스트, 코드 복잡도 계산 등이 가능하며, 내장 컴파일러가 존재해 컴파일 환경 구축이 필요 없다.
여섯 번째로 ‘ParaSoft C/C++’는 미국 ParaSoft에서 개발했으며, 국내에서는 VWAY 등이 담당하고 있다. 이 제품은 검증 보고서를 자동으로 생성하고, C/C++ IDE, CI/CD 파이프라인과 컨테이너화된 배포에 통합해 결함을 조기에 감지한다.
일곱 번째로 ‘LDRA’는 영국 기업 LDRA에서 개발된 도구로 국내 기업인 모아소프트가 판매하고 있다. 이 도구는 45년 이상 소프트웨어 분석과 자동화 테스팅 도구 시장을 주도하고 있다.해외에서도 항공우주 및 방위, 자동차, 산업 및 에너지 소프트웨어 테스팅에 많이 사용된다.
화이트박스 테스트 도구는 어떤 기능 및 요소가 중요할까?
화이트박스 테스트 도구의 기능과 성능 분석 연구를 위한 지표 수립을 위해 소프트웨어 진흥법(법률 제17799호) 제49조 제2항 ‘소프트웨어 기술성 평가 기준 지침’ 내 평가 기준에 따른 상용 소프트웨어 평가 항목 및 배점 한도(제3조 제2항 관련)와 국제 표준 소프트웨어 평가 기준인 ISO 25010을 참고했다. 기능 및 성능 분석 연구 지표는 △평가 부분 △평가 항목 △평가 기준 순으로 분류했으며, 34개 기준으로 세분해 화이트박스 테스팅 자동화 도구 평가 기준을 수립했다. 특히, ISO 국제 표준은 이를 △평가 기준의 광범위한 포괄성 △평가 기준의 모호함 △평가 기준의 불필요성 등을 설정했지만, 이러한 부분을 축소하고 수정했다.
▲국제 표준 ISO 25010 평가항목[자료=스플렉스]
ISO 25010 국제 표준의 평가항목에서 ‘기능적합성’은 ‘기능성’으로 수정했으며, ‘기능성숙도’, ‘기능 정확성’, ‘기능타당성’을 하나의 ‘정확성’으로 묶어 기능 측면에서 정확도를 평가할 수 있도록 했다. 기존 ‘보안성’의 ‘기밀성’, ‘부인방지’ 등은 화이트박스 테스팅 도구로 특별히 평가할 방법이 없어 별도의 평가 항목으로 구분하지 않고 기능성 항목에 추가해 최소한의 보안성이 평가되도록 했다. ISO 25010 국제 표준에서의 ‘사용성’과 ‘신뢰성’은 그대로 유지했지만, ‘신뢰성’ 항목의 ‘성숙성’, ‘결함 수용성’ 등은 의미가 미미해 평가 기준에서 제외했다. ‘사용성’은 대부분의 평가 항목을 그대로 유지했다. 또한, ‘실행효율성’, ‘이식성’, ‘호환성’은 화이트박스 테스팅 도구 평가로 수용할 수 있는 부분을 ‘사용성’과 ‘신뢰성’에 분산해 평가 기준을 수립했으며, 상위 카테고리인 ‘사용 품질’에서 ‘안정성’은 ‘운용안정성’으로 ‘신뢰성’에 포함했다. 재정립한 전체적인 평가 항목과 기준은 다음과 같다.
▲수립한 평가 항목[자료=카이스트 CSRC]
화이트박스 테스트 평가에 사용할 오픈소스 선정은?
화이트박스 테스팅 도구는 항공우주, 방위, 자동차 등 고신뢰성·안전성이 필요한 소프트웨어 또는 생명에 직접적인 산업 분야에서 사용된다. 대부분의 개발 언어가 C/C++로 이뤄졌으며, 화이트박스 자동화 테스팅 도구들이 목표로 하는 시장도 C/C++ 언어로 이뤄졌다.
연구팀에서 사용된 오픈소스도 C/C++ 위주의 UI, 암호화, 신호처리, 통신 프로토콜 등 여러 분야에서 사용되는 오픈소스를 선정했으며, ‘CITRUS : Automated Unit Testing Tool for Real-world C++ Programs’ 논문을 참고했다. 선정된 오픈소스는 화이트박스 자동화 테스팅 위해 프로젝트 자체로 빌드가 가능한 프로젝트를 대상으로 했다.
▲평가를 위한 프로젝트 항목[자료=카이스트 CSRC]
화이트박스 자동화 테스팅 도구 선정 및 오픈소스 프로젝트 테스트 결과
화이트박스 자동화 테스팅 도구 선정을 위해 7개의 도구 중 제품의 시장 점유율, 제품 소개 및 지원에 가장 적극적인 4개 도구(A, B, C, D)를 선정했으며, 이를 이용해 프로젝트를 테스트했다. 특히, A, B, D 제품은 3번 ‘mathc’ 프로젝트만은 정상으로 테스트했지만, C 제품은 ‘mathc’ 프로젝트와 연구팀 선정 10개 프로젝트 모두 불가능했다.
‘mathc’ 프로젝트 외 9개 오픈소스 프로젝트는 빌드가 정상적으로 수행되지 않아 연구팀에서는 테스트 진행이 불가능했다. 따라서 각 기업에 사용과 기술 지원을 요청했다. 그 결과 4개 도구 중 ‘B’ 테스팅 도구의 경우 프로젝트 화이트박스 테스팅을 위해 간단한 설정 파일 제공을 지원받았고, 수일 내로 쉽게 자동화 상태에서 10개 프로젝트의 테스트를 모두 완료했다.
3개(A, C, D) 테스팅 도구의 경우 사용 과정이 프로젝트마다 지원을 받아야 할 정도로 복잡했다. 다만 ‘B’ 도구가 90% 이상 ‘자동화 테스팅 도구’의 의미에 부합해 우수성이 뛰어났다. 모든 평가 항목과 기준 평가는 비교 분석 측면에서 다소 부족함이 있다. 다만, ‘C’를 제외한 나머지 3개 도구는 ‘mathc’ 프로젝트를 모두 정상적으로 빌드하고 테스트가 가능해 ‘mathc’에 한정해 4개의 화이트박스 자동화 테스팅 도구의 기능 및 성능 평가를 진행했다.
▲‘B’ 자동화 테스팅 도구의 화이트박스 테스팅 결과[자료=카이스트 CSRC]
화이트박스 자동화 테스팅 도구 평가
이번 평가는 O : 기능 지원 및 제공, △ : 미흡 및 정보 부족, X : 지원 및 제공하지 않음 등 세 가지로 평가를 측정했으며, 시간, 카운팅, ‘%’가 필요한 항목은 별도로 표시했다. 해당 평가 방법에서 지원되지 않는 경우는 ‘X’가 아닌 ‘미지원’으로 구분, 종합 평가 시 ‘X’가 카운팅돼 평가 개수가 달라지는 것을 방지해 오해가 생기지 않도록 공정한 평가를 진행했다.
평가 항목 1. 기능성
기능성은 화이트박스 자동화 테스팅 도구에 가장 중요한 기능을 평가하는 항목으로 분석(탐지)된 코드 정보들과 테스트 케이스 개수, 커버리지 정보를 평가했다. 기본은 10개의 오픈소스 프로젝트를 기준으로 평가해야 하지만, 앞서 설명한 이유로 화이트박스 자동화 테스팅 평가 항목 중 가장 중요한 항목 중 일부는 ‘mathc’ 프로젝트를 기준으로 평가 비교했다. 하지만 ‘C’ 제품은 자동화 테스트가 가능하다고 했지만 테스트할 수 없었다. ‘C’ 제품을 테스트하려면 테스트 코드를 작성해야 했으며, 작성도 오랜 시간이 소요돼 일부 테스트에서 배제했다.
①빌드시간 측정 : ‘mathc’ 소스코드 파일 사이즈는 159kb이었으며, 총 코드라인 수가 5,586개인 코드의 빌드시간을 측정한 값으로 ‘B’ 도구가 24초로 가장 빨리 빌드했다. ‘A’ 도구는 2분 27초를 기록해 6배 이상 차이가 발생했다.
②테스트 완료 시간 : 화이트박스 테스팅 도구가 완전히 테스트를 끝내고 완료된 시간으로 ‘D’ 도구는 2분 50초로 가장 빨랐으며, ‘A’ 도구의 경우 25분으로 제일 늦었다.
③사전 빌드파일 : 사전 빌드는 테스트가 정상적으로 진행되는지 여부를 확인하는 것으로, ‘B’ 도구는 실제 빌드할 소스코드를 ‘1개’라고 탐지(분석)했는데, 기본으로 헤더 파일을 제외했다. ‘D’ 도구의 경우에는 헤더파일까지 포함해 탐지(분석)해 ‘2개’가 됐다.
④탐지된 파일 개수 : 테스트 완료 후 분석(탐지)된 소스코드(파일) 개수로 ‘B’ 도구만 ‘1개’라고 탐지했다. 이는 이전 평가 기준과 마찬가지로 헤더파일을 제외하고 카운팅이 됐으며, 나머지 3개의 도구는 테스트가 불가능하거나 정보가 없어 ‘미지원’으로 평가했다.
⑤탐지된 함수 개수 : 테스트 완료 후 분석(탐지)된 함수 개수다. ‘B’와 ‘D’ 제품은 탐지한 함수가 실제 함수 개수와 일치했지만 ‘A’와 ‘C’ 도구의 경우 탐지가 불가능했다.
⑥실제 빌드파일 개수 : 실제 테스트를 위한 빌드 단계이며, 사전 빌드 파일 개수와 다를 수 있다. 실제 빌드할 소스코드(파일)에 대해 ‘B’ 도구의 경우 ‘1개’라고 탐지(분석)했는데, ‘B’ 도구의 경우 헤더파일을 제외한 개수를 결과로 나타냈으며, ‘D’ 도구의 경우 헤더파일까지 포함해 탐지(분석)해 결과가 ‘2개’였다. 나머지 두 개의 도구는 확인되지 않았다.
⑦탐지된 코드라인 개수 : 화이트박스 자동화 테스팅 도구로 실행된 코드라인 수이며, 실행 가능 유무와 특수문자 ‘{ }’만 있는 라인 등을 제거해 최적화된 테스트 가능한 라인 개수를 탐지했다. ‘A’ 도구는 2,877개 라인을 탐지했지만, ‘B’ 도구의 경우 ‘A’보다 약 1,700개가 많은 4,500개 라인을 분석했다. ‘C’와 ‘D’ 도구의 경우는 파악이 불가능했다.
▲기능성 평가항목(정확성+보안성)[자료=카이스트 CSRC]
⑧탐지된 브랜치 개수 : 화이트박스 자동화 테스팅 도구가 코드 내에 브랜치(조건문) 항목의 개수이며, 평가에서는 If(else)만 갖고 개수(138개)를 비교했다. ‘A’ 도구의 경우 1,045개를 탐지했고, ‘B’ 도구의 경우 기준과 가장 근접한 190개, ‘D’ 도구의 경우 978개가 탐지됐다. 해당 평가 항목은 도구의 특성에 따라 구하는 값이 달라져 정답이 있지는 않다.
⑨라인 커버리지 값 : ‘⑦’ 평가 기준 결과를 바탕으로 얼마나 많은 라인을 테스트했는지에 대한 ‘%’ 값이다. 예를 들어 ‘A’ 도구는 ‘⑦’에서 2,877개의 라인을 탐지했으며, 커버리지 값은 98%였다, 이 의미는 ‘A’ 도구는 2,877개의 라인으로부터 2,819개(98%) 라인을 적어도 한번은 테스트했다는 것을 보여준다. ‘A’와 ‘D’의 경우 ‘%’ 값은 같지만, ‘D’가 찾은 라인 수를 확인할 수 없었으며, ‘B’ 도구의 경우 4,192개의 라인을 100% 커버했다.
⑩브랜치 커버리지 값 : ‘⑧’ 평가 기준 결과를 바탕으로 테스트 시 얼마나 많은 브랜치(조건문)를 테스트했는지에 대한 ‘%’ 값이다. 예를 들어 ‘B’ 도구는 ‘⑧’에서 190개의 브랜치를 탐지했으며, 커버리지 값은 100%였다. ‘B’와 ‘D’는 커버리지 값이 같고, ‘A’도구의 경우 95%의 브랜치 커버리지를 보여줘 가장 낮았다. 단, 평가가 불가능한 ‘C’는 제외했다.
⑪코드별(파일) 라인 커버리지 지원 여부 : 도구의 결과(보고서)로 코드(파일)별로 라인 커버리지를 보여주는 기능이 있는지 혹은 지원되는지에 대한 평가 항목이다. ‘C’ 도구를 제외하고 3개 도구 모두 코드(파일)별 지원이 가능했다.
⑫코드별(파일) 브랜치 커버리지 지원 여부 : 도구의 결과(보고서)로 코드(파일)별로 브랜치 커버리지를 보여주거나 지원되는지에 대한 평가 항목이다. ‘⑪’ 평가항목과 동일하게 ‘C’를 제외하고 3개 도구 모두 코드(파일)별 지원이 가능했다.
⑬생성된 전체 테스트 케이스 수 : 화이트박스 자동화 테스팅 도구가 테스트 케이스를 직접 만들고 테스트한 수의 결과다. ‘A’ 도구의 경우 2,461개, ‘B’ 도구는 1,479개, ‘C’ 도구는 978개로 가장 적었다. 도구마다 알고리즘과 방법이 달라 이 개수는 무의미하다.
첫 번째 ‘기능성’ 평가에서 4개의 도구 중 유일하게 모든 프로젝트 테스트가 가능해 나온 결과 테이블인 그림 7의 커버리지를 보면 ‘mathc’ 프로젝트만 높았다. 또한, ‘mathc’만 테스트가 가능했던 ‘A’, ‘D’의 커버리지 값이 높았는데, ‘mathc’ 프로젝트는 소스코드 간 종속성이 없는 단순한 산술 연산값을 리턴하는 함수로 이뤄진 소스 코드이기 때문인 것으로 추정된다. 또한, 화이트박스 자동화 테스팅 도구에서는 적은 테스트케이스로 높은 커버리지를 달성하는 것이 중요하다. 케이스가 많으면 커버리지에 기여하지 않은 케이스가 많을 가능성이 크다.
▲사용성, 신뢰성, 유지관리성 평가항목[자료=카이스트 CSRC]
평가 항목 2. 사용성
사용성은 사용자 중심의 학습 및 사용에 대한 전반적인 평가 항목이다. ‘⑰’ 항목의 경우 ‘B’ 제품과 ‘C’ 제품은 사용 순서에 따라 매뉴얼이 잘 작성돼 흐름을 이해하기 편했지만, ‘A’와 ‘D’의 경우 매뉴얼의 내용이 부실하고 테스트 환경을 구축하는 부분에서 사용자가 이해하기 어려워 자체적으로 테스트가 불가능했다. ‘⑱’ 항목은 대부분 메인 기능에 중점적으로 작성됐다. 세부적인 기능 설명이 없어 설정이 어려웠으며, ‘B’ 제품의 경우 세부 기능을 모두 설명하고, 테스트에 필요한 요소와 변경 및 그에 따른 영향을 설명했다.
‘㉒’ 항목에서 ‘B’ 제품의 경우 별도의 컴파일러 설치 없이 테스트할 수 있어 다른 도구들에 비해 매우 편리했으며, 나머지 3개의 제품의 경우 내부 컴파일러가 있으나, 제대로 동작하지 않거나 별도의 컴파일러를 설치해야 했다. ‘㉕’ 항목은 ‘B’와 ‘D’ 모두 특정 모듈 및 필요 함수만 선택해 원하는 정보만 보고서로 만들 수 있으나, 선택 가능한 영역이 한정적이었다.
평가 항목 3. 신뢰성
신뢰성 평가 항목은 화이트박스 테스팅 도구의 자체 안정성 및 문제 발생시 회복성 평가 항목이다. ‘㉖’ 항목의 경우 ‘A’ 도구만 안정적으로 테스트가 가능했으며, 나머지 3개의 도구는 테스트가 되지 않거나 에러 메시지와 함께 비정상으로 종료됐고, 테스트 도중 프리징 현상이 발생해 도구를 강제종료해야 해 ‘X’로 평가했다. ‘㉗’ 항목의 경우 ‘A’는 안정적인 동작을 통해 장애가 발생하지 않아 ‘O’로 평가했고, ‘B’는 이미 수행된 부분은 건너뛰고 장애 시점부터 다시 테스트를 진행하기 때문에 ‘O’로 평가했다. 다른 2개의 도구의 경우 각자 테스팅 도중 멈춘 시점부터 시작하지 않고 새롭게 테스트를 시작해야 하므로 ‘X’로 평가했다.
평가 항목 4. 유지관리성
유지관리성 항목은 공급업체 또는 유지보수 업체를 통해 기술지원을 통해 문제를 파악하고 지원받을 수 있는 항목과 사용자 입장에서 테스트할 타겟(프로젝트)의 관리 측면에서 평가하는 항목이다. ‘㉘’ 항목의 경우 시스템 사용 중 오류가 발생할 경우 ‘△’ 평가를 받은 3개의 도구는 조치 방법 또는 방안에 알려주지 않거나 관련 문서가 없었다. ‘A’ 도구는 테스트 도중 Stub(프로그램 테스트를 위한 더미 코드)이 존재하지 않은 경우 해결 방안을 제시하기도 했다. 또한, ‘㉜’와 ‘㉝’ 항목의 경우 ‘B’ 도구는 별도의 계정을 발급해 조직·팀별로, ‘A’와 ‘D’ 도구는 별도의 확장프로그램 설치를 통해 조직·팀별로 작업 공간을 분리할 수 있다.
이번 연구에서는 화이트박스 자동화 테스팅 도구에 대해 알아보고, 화이트박스 자동화 테스팅 도구의 기능 및 성능을 분석할 수 있는 평가 기준을 수립했다. 또한, 4개의 화이트박스 자동화 테스팅 도구를 이용해 선정한 10개의 오픈소스 프로젝트를 테스트했으며, 34개의 세부 항목을 평가해 각 도구의 기능과 성능, 특징을 정량·정성적으로 측정했다. 도구들의 평가는 그림 12(상단)와 같으며, 평가 항목별 가장 좋은 평가를 받은 제품은 파란색으로 표시했다.
▲종합 평가표(상) 및 종합 합계 평가표(하)[자료=카이스트 CSRC]
종합 평가와 같이 기능성 경우 ‘O’의 개수가 많다고 좋은 도구라고 말할 수는 없으며, 기능성 내 정확성 평가 항목에 있는 빌드 시간, 커버리지, 테스트케이스 등 화이트박스 테스팅 도구로써의 주요 기능이 얼마나 빠르고 커버리지가 높은지가 더욱 중요하다. 또한, 다른 도구들과 달리 ‘B’ 도구는 복잡한 프로젝트(‘mathc’를 제외한 9개)도 어렵지 않게 빌드 환경을 구성해 그림 7과 같이 계획된 테스트를 정상적으로 진행했다는 점에서 긍정적이었다.
이번 연구를 진행한 KAIST 사이버보안연구센터(CSRC) 신강식 연구원과 이정호 연구원은 “화이트박스 자동화 테스팅 도구에 대한 평가 지표를 정의해 화이트박스 자동화 테스팅 도구의 중요성에 대해 더욱 깊이 인식하게 된 것이 의미 있었고, 사용자가 개입하지 않아도 자동으로 테스트 케이스를 생성하고 테스트하는 것이 흥미로웠다”며 “도구별 장단점이 있고 프로젝트의 특색과 용도에 맞게 적절히 도구를 사용한다면 소프트웨어를 안전하게 사용할 수 있고 품질 향상도 기대할 수 있을 것”이라고 말했다.
[김영명 기자(boan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
.jpg)
.jpg)
.jpg)
.jpg){kind=small}
.JPG){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
