소프트웨어를 검사하는 소프트웨어?!?
소프트웨어 테스팅이란?
현대 사회에서는 소프트웨어가 세상을 움직인다고 하여도 전혀 이상하지 않을 만큼 우리 삶에 있어 소프트웨어가 가지는 의미는 실로 막강합니다. 이렇게 중요해진 소프트웨어에 결함이 존재한다면 어떤 일이 발생 될까요? 2018년 세계 최대 차량공유업체(Uber)의 자율주행차가 횡단보도로 걸어가던 40대 여성을 쳐 사망하는 사고가 발생했습니다. 이는 자율주행차의 첫 보행자 사망사고라는 점에서 많은 관심을 갖게 되었고, 동시에 자율주행 소프트웨어에 대한 안전성과 위험성이 뜨거운 이슈로 떠올랐습니다.
소프트웨어 테스팅은 블랙박스 테스트와 화이트박스 테스트 그리고 그레이박스 테스트 세 가지로 나눌 수 있습니다. 세 가지 모두 소프트웨어의 정상 동작을 검증하고 결함을 도출하는 기법이지만. 이는 내부 또는 외부, 혼합(내부+외부)하여 테스트를 수행 하느냐에 따라 나뉘게 됩니다. 먼저 블랙박스 테스팅은 Input/Output 값에 따라 원하는 결과가 일치하는지를 확인하기 위한 입출력 데이터 기반 검증 및 결함 도출 테스트 기법이라고 말할 수 있고, 화이트박스 테스트는 내부 로직을 검증하는 기법으로 제품에 대한 컴포넌트(함수) 로직의 정상 동작 여부를 확인하기 위해 제품 내부 구조 기반 검증 및 결함 도출 테스트 기법을 말합니다. 그레이박스 테스팅을 설명하기에 앞서 테스팅 명칭으로 인해 많은 이들이 오해하는 것이 화이트박스 테스팅인데, 전통적으로 화이트박스 테스팅은 내부(개발자 또는 소스코드) 관점에서 테스트를 수행 기법입니다. 그렇다면 바이너리 테스트는 어느 기법에 속할까요? 대부분의 사람들은 바이너리 테스팅은 블랙박스 기반이라고 생각할 것입니다. 하지만 바이너리 테스팅은 기술의 발전으로 어떠한 제약 없이 블랙박스, 화이트박스, 그레이박스 세가지 테스팅 기법 모두에 적용될 수 있습니다. 마지막으로 그레이박스 테스팅은 블랙박스의 장점과 화이트박스의 장점을 결합한 테스트 방법으로 기존 테스트 기법으로 찾지 못한 결함을 찾을 수 있는 장점이 있습니다.
또한 최근 연구가 활발하게 진행되고 있는 퍼징기술은 소프트웨어 테스팅을 논할 때 빠져서는 안 될 기술입니다. 퍼징은 컴퓨터 프로그램에 예상치 않은 무작위 데이터를 입력하여 프로그램 충돌 및 결함을 발견하는 기술로, 좀 더 알아보고자 한다면 지난 저희 블로그 “스마트 컨트랙트 퍼저”, “윈도우 커널 퍼저”, “퍼징 연구“ 내용을 참고하면 되겠습니다. 이러한 퍼징 기술 또한 블랙박스, 화이트박스, 그레이박스 테스팅 기법 모두에 사용할 수 있는 기술이며, 이번 포스팅에서는 소스코드 기반의 화이트박스 테스팅에 대해 살펴보고자 합니다.
| 비교항목 | 블랙박스 | 그레이박스 | 화이트박스 |
| 테스트 수행 관점 | 사용자 관점 | 사용자+개발자 관점 | 개발자 관점 |
| 테스트 기준 문서 | 요구사항 명세서 | 요구사항 + 단위 설계 | 단위 설계 명세서 |
| V 모델 위치 | 상위 레벨(사용 환경) | 하이브리드 | 하위 레벨(개발 환경) |
| TestCase 설계 유형 | 동등분할, 경계값 분석 등 | 통합테스트 | 루프, 제어구조 테스트 등 |
| 결함 여부 기준 | 예상된 출력값과 일치 여부 | 기존 테스팅에서 발견되지 않은 결함 | 설계문서와 논리구조 일치 여부 |
표 1. 블랙박스 테스트와 화이트박스 테스트 비교
크고 작은 국내･외 소프트웨어 사고 사례
1985년 테락-25 방사선 치료기기 사건으로 소프트웨어의 오류로 인해 환자에게 과다한 방사선에 노출되는 최초의 소프트웨어 결함 사고 사례로 알려져있습니다. 또한 1988년 에어버스 A320 추락사고는 비행모드 전환 시 소프트웨어 결함으로 인해 추락하였고, 내부 시스템의 버퍼 오버플로우 발생으로 발사 37초만에 폭발한 아리안 5 로켓 사고, 그 밖에도 1999년 화성 착륙선 실종, 2009년 도요타 급발진 사망사고 등 크고 작은 소프트웨어 결함 사고는 국내외적으로 다양하게 발생하고 있습니다.
| 소프트웨어 장애 | 장애 원인 및 영향 | 연도 |
| 방사선 치료기기 사고 | SW 장애로 인한 방사선 출력 오류 | 1985 |
| 에어버스 A320 추락 | 비행 모드 전환시 SW 결함으로인해 추락 | 1988 |
| 아리안 5 로켓 폭발 | 오버플로우 발생으로 폭발 | 1996 |
| 화성 극지 착륙선 실종 | 착륙직전, 소프트웨어 결함으로 인해 추락 | 1999 |
| 도요타 급발진 사망사고 | ECU내 메모리 영역에서 SW 오류 발생 | 2009 |
| 임진강 재해경보 시스템 오작동 | 수위 정보를 전송하는 RTU 고장 | 2009 |
| 교육행정정보서비스(나이스)성적처리오류 | 고교생 2만 9천여명 석차 등급 변경 | 2011 |
| 의료서비스 윤일 버그 | SW 결함으로 2012년 2월 29일 윤일을 인식하지 못해 시스템 마비 | 2012 |
| 런던공항 관제시스템 장애 | SW 장애로 이착륙 지연 및 공항 폐쇄 | 2014 |
| 닛산 AIRBAG 소프트웨어 고장 | SW 결함으로 조수석에 앉은 사람을 비식별하여 에어백이 작동하지 않음 | 2015 |
| 우버 자율주행자동차 사망사고 | SW 결함으로 충돌 전 긴급 제동장치가 작동하지 않음 | 2018 |
| 테슬라 1만 2천대 리콜 | SW 결함으로 인해 전방 충돌 경고 및 비 정상적인 긴급 제동장치 작동 | 2021 |
표 2. 소프트웨어 결함 사고사례
이처럼 크고 작은 소프트웨어 결함 사고는 현재 사회에서 다양하게 사용되는 소프트웨어에서 언제든 일어날 수 있기 때문에 이러한 결함을 제거하는 역할이 갈수록 중요해지고 있습니다. 하지만, 가시적으로 보이지 않는 소프트웨어의 특성상 결함을 감지하는 것은 매우 어렵고 많은 시간과 노력이 필요합니다. 소프트웨어가 여러 분야에서 중요한 역할을 수행함에도 불구하고 소프트웨어 결함을 보정하는 일은 매우 어려운 일이기 때문에 소프트웨어의 복잡도가 증가함에 따라 장애 발생 사고도 지속적으로 증가하고 있습니다. 따라서, 선행적으로 안전한 소프트웨어 개발의 필요성이 부각되고 있으며, 우리 삶의 안위와 직결되는 전자기기의 소프트웨어의 신뢰성을 평가하고 보정할 수 있도록 소프트웨어 테스팅의 필요성이 그 어느 때보다 높아지고 있습니다.
소프트웨어의 안전성은 국방, 항공, 철도 등 주요 분야별 국제 표준 및 소프트웨어 안전 관련 표준이 존재하여 표준에 따라 개발되고 있지만, 안전한 소프트웨어 개발을 위해서는 무엇보다 위험한 원인을 분석하고 위험도에 대한 기준을 만들어 평가하는 것이 중요합니다.
이러한 위험한 원인 분석 및 평가를 위해 “Failure Mode and Effects Analysis(FMEA)”, “Fault Tree Analysis(FTA)”, “System Theoretic Process Analysis(STPA)” 등 정형화 기법들이 존재하지만 가장 중요한 것은 소프트웨어에 대한 정확하고 체계적인 테스팅입니다. 클라이언트의 요구사항을 충족했는지 확인하기 위해서는 앞서 설명드렸던 사용자 관점에서의 블랙박스 테스팅 기법을 통해 충분히 검증할 수 있지만, 소프트웨어의 안전성과 결함을 세밀하게 찾기 위해서는 개발자 관점에서의 화이트 박스 테스팅이 반드시 필요합니다.
화이트박스 테스팅이 뭐야?
그림 1. 소프트웨어 테스팅 개념도
화이트박스 테스팅이란 응용프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방법입니다. 개발된 소스 코드를 모두 공개한 상태에서 소스 코드의 논리적인 모든 경로를 따라가면서 테스트 케이스를 작성하는 것으로, 설계된 절차에 따라 프로그램이 개발되었는지 확인하는 구조적 테스트와 테스트 과정 초기에 적용하여 테스트 케이스를 생성을 의미합니다.
화이트박스 테스트에는 수행 가능한 모든 경로를 검사하는 기초 경로 검사(Basic Path Testing)가 있으며, 프로그램의 조건문에 초점을 맞춰 모든 조건문을 통과하는 테스트를 진행하는 조건 검사(Condition Testing), 프로그램의 반복 구조에 초점을 맞추어 검사하는 루프 검사(Loop Testing) 그리고 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 검사하는 데이터 흐름 검사(Data Flow Testing)가 있습니다.
화이트박스 테스팅 도구는 어떤 것들이 있을까?
OTestManager
국내 기술로 개발한 공개 소프트웨어로써 자동화 도구는 아니지만 테스트 케이스 관리 협업을 통한 공용 테스트 케이스 관리 및 테스트 케이스 설계/할당/실행을 수행할 수 있으며, 결함 관리기능을 통해 결함과 테스트 케이스 간의 추적관리가 가능합니다. 또한, 무료임에도 불구하고 리포트 정보를 제공합니다. 사용 기업에 최적화된 시스템으로 커스터마이징 용이하며 국내 기술로 개발하였기 때문에 완벽한 한글 지원이 가능하다는 특징이 있습니다.
Controller Tester
국내 슈어소프트테크에서 개발한 도구로 단위 및 통합 테스트를 수행하는 테스트 자동화 솔루션입니다. 자동으로 테스트 및 테스트 데이터 생성할 수 있으며, 테스트에 필요한 시뮬레이션 및 실제 타깃 환경 테스트 지원이 가능한 특징이 있고 정의가 없는 함수(라이브러리 등)의 스텁을 자동으로 생성할 수 있습니다. 또한, 제어 흐름 그래프 제공 및 소스 코드와 연동하여 커버리지 결과 확인 할 수 있으며, 소스 코드 수정없이 결함 주입 코드를 자동으로 삽입할 수 있는 것이 특징입니다.
Coyote
국내 코드마인드에서 개발한 도구로써 심볼릭 테스팅 기술과 머신러닝 기술이 융합된 완전자동 화이트박스 테스팅 도구입니다. 단위 테스트 완전 자동 도구로서 한번의 클릭으로 테스트 케이스 작성부터 실행, 결과 분석까지 단위 테스트의 전 과정을 완벽히 수행할 수 있는 가장 큰 특징을 가지고 있으며, 현재 자동차 전장, 자동차 파워트레인 제어, 통신장비, 금융, 로봇, 항공 등 여러 분야의 소프트웨어 테스팅 도구로써 사용되고 있습니다. Coyote는 코드 커버리지 90% 이상 달성할 수 있으며, 테스트 케이스를 사람 개입 없이 완전 자동화 할 수 있습니다.
Resort
국내 Soft4Soft에서 개발한 도구로써 정적 분석으로써는 코드 컴파일 과정이 없는 소스 코드 분석이 가능하며, 프로시저 간 경로 분석의 최상위 코드 검증할 수 있으며, 코딩 표준, 런타임 에러, 보안 취약점, 코드 품질 모두 점검할 수 있는 특징을 가지고 있습니다. 동적 분석으로는 코드 요구사항 기반 경로 테스트 자동화할 수 있으며, 테스트 케이스인 실행 경로 자동 추출할 수 있습니다. 또한, 각 실행 경로의 테스트 데이터(테스트 도메인, 입력 값) 자동 생성할 수 있는 특징이 있습니다.
cppunit
무료로 사용할 수 있는 오픈소스로써 기존의 java의 junit을 c++로 구현한 테스팅 도구입니다. 무료이지만 다양한 Platform 및 IDE 지원이 가능하며, 소스코드 수정 없이 소스코드가 의도한 대로 제대로 실행되는지 간단한 테스트를 통해 확인할 수 있습니다. 알고있는 화이트 박스 테스트와 사용자 고유의 회귀 테스트 작성이 가능하며 테스트 결과로 XML과 TEXT 포맷형태로 출력이 가능합니다.
Cantata++
국외 제품으로 QA Systems에서 개발한 도구입니다. C 및 C++ 언어를 위한 자동화된 단위 및 통합 테스트 도구로 단위 및 확장 가능한 통합 테스트 모두에 대한 테스트 스타일의 조합을 가능하게 하는 통합테스트 프레임워크를 제공하여, 기능 테스트 및 통합 코드 검사 결과를 분석 할 수 있습니다. 보고서 포맷으로는 ASCII 및 HTML 텍스트와 함께 RTF, XML, HTML로 생성할 수 있으며, 코드 커버리지 결과 제공해 사용자에게 테스트 결과를 시각적으로 잘 보여줄 수 있습니다. 또한, 필요한 모든 코드 경로를 실행하는 단위 테스트 모음을 자동으로 생성할 수 있는 특징을 가지고 있습니다.
VectorCAST/c++
국외 기업인 vector에서 개발한 도구로 임베디드 테스팅에 특화된 도구입니다. 기능과 소프트웨어의 안전을 최우선으로 하는 임베디드 시스템을 검증하는데 필요한 자동화된 단위 및 통합 테스트 솔루션을 제공하며, 단위 및 통합 테스트를 위한 테스트 환경을 자동으로 구성하여 테스트 코드 작성 불필요해 사용자에게 매우 편리하게 테스트 환경을 제공합니다. GUI 및 스크립트를 통한 테스트를 실행할 수 있도록 지원하며, 코드 커버리지, 회귀 테스트, 코드 복잡도 계산해 줍니다. 또한 요구사항 기반 테스트를 위한 사용자 정의 테스트 지원하는 특징이 있습니다.
parasoft c/c++
국외 기업인 parasoft에서 개발한 도구로 테스팅 도구를 통해 소프트웨어의 조기 결함 감지할 수 있습니다. 산업 표준 준수하였으며 테스트를 자동화하여 검증 보고서를 자동으로 생성합니다. 특히, C/C++ 테스트는 임베디드 안전이 중요한 산업을 위한 완전히 통합된 소프트웨어 테스트 솔루션으로써 C 및 C++ IDE, CI/CD 파이프라인 및 컨테이너화된 배포에 긴밀하게 통합되어 결함을 조기에 감지하고 산업 표준 준수를 자동으로 적용할 수 있습니다. 최근 자동화된 코드 분석에 대한 원활한 액세스를 위해 Docker Hub 이미지를 사용하여 고도로 자동화되고 확장 가능한 CI 파이프라인을 구축할 수 있고, GitLab용 VS Code 플러그인을 사용하여 IDE 내에서 결과를 검토할 수 있습니다.
LDRA
국외 기업으로써 45년 이상 소프트웨어 분석 및 테스팅 관련 도구 제공업체이며, 테스팅 관련 기업에서는 손꼽히는 기업 중 하나입니다. 국내뿐만 아니라 해외에서도 항공우주 및 방위, 자동차, 산업 및 에너지, 의료, 철도 운송의 소프트웨어 테스팅에 가장 많이 쓰이고 있으며, 단위 및 통합 테스트를 위한 테스트 케이스 관리 및 자동화된 실행을 제공합니다. 또한, 요구사항 추적성 제공하고 있으며, 코드 커버리지의 50~80%를 제공하는 테스트 케이스를 자동으로 생성할 수 있는 특징을 가지고 있습니다.
cppcheck
무료 정적 분석 도구로써 크로스 플랫폼(윈도우, 데비안, 페도라, 맥 등)을 지원하며 개발 IDE 플러그인으로 연동 가능합니다. 메모리 누수, 오버플로우, 사용하지 않는 함수 등 여러 가지 휴먼 에러가 날 수 있는 코드들을 검사해주는 도구입니다.
CodeSonar
CodeSonar는 함수별, 파일별, 모듈별로 결함이 분포된 정도를 색의 농도 차이로 표시해 줍니다. 결함이 많이 검출된 함수는 그렇지 않은 함수에 비해 추후 기능 오류로 이어질 가능성이 높기 때문에 해당 함수에 대한 테스트를 더욱 정확하게 할 수 있도록 도와주는 역할을 합니다. CodeSonar의 Visualization은 결함 분포율에 대한 그래픽 이외에도 결함별 함수 호출 경로를 그래프 형태로 제공합니다. 이 그래프는 결함이 검출된 함수가 실행될 수 있는 모든 함수 호출 경로를 시각화하고, 그 중 결함 발생이 가능한 호출 경로를 별도로 표시해주어 기능 시험을 위한 테스트케이스 생성 시 참고될 수 있으며, 시험 결과서 제출 시 실제 설계한 대로 테스트케이스를 생성하고 시험을 했는지에 대한 근거자료로도 사용할 수 있습니다. 불필요한 소스코드(Dead code)를 결함으로 검출 하여 동적 시험 시 코드 커버리지를 높이는데 용이하게 사용할 수 있습니다.
글을 마치며
이번 포스팅에서는 소프트웨어 사고사례를 통해 소프트웨어 안전성의 중요성을 확인하였으며, 소프트웨어의 신뢰성 및 안전성을 검증하기 위한 기법으로써 화이트박스 테스팅이 무엇인지에 대한 것과 다양한 화이트박스 테스팅 도구에 대해 알아보았습니다. 다음 포스팅에서는 앞서 소개된 화이트박스 테스팅 도구들을 이용하여 소프트웨어의 결함을 찾아보고, 체계적으로 시나리오를 개발하여 도구의 기능과 성능을 분석한 후 그 결과를 공유하겠습니다.
참고문헌
[1] https://spri.kr/posts/view/22434?code=data_all&study_type=industry_trend
[2] https://www.edunet.net/nedu/contsvc/viewWkstCont.do?contents_id=fs_a0000-2019-0123-0000-000000000014&svc_clss_id=CLSS0000075595&clss_id=CLSS0000000361&menu_id=87
[3] https://devinus.tistory.com/6
[4] https://catsbi.oopy.io/7c084479-c9d0-44a1-acb9-f6b43a19e332
[5] http://www.acornpub.co.kr/book/historic-software-errors
[6] https://junhyunny.github.io/information/white-black-box-test/
[7] http://blog.skby.net/%EB%B8%94%EB%9E%99%EB%B0%95%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%99%80-%ED%99%94%EC%9D%B4%ED%8A%B8%EB%B0%95%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EB%B9%84%EA%B5%90/
[8]https://itwiki.kr/w/%ED%99%94%EC%9D%B4%ED%8A%B8%EB%B0%95%EC%8A%A4_%ED%85%8C%EC%8A%A4%ED%8A%B8