2016년 3월 15일 화요일

프로젝트 수행 - 테스트 설계 편

완벽한 소프트웨어를 만들기 위해서는 목적에 따라 설계를 정확히 해야 하지만 한번에 완벽한 소프트웨어를 만들기는 거의 불가능하다. 요구사항을 분석하고 설계, 개발하는 일은 모두 쉽지 않지만, 그 중에서도 설계는 가장 어려운 것으로 알려져 있다. 실체가 없는 요구사항을 고객(사용자)과 개발팀이 알아볼 수 있도록 실체화 하는 작업이기 때문이다. 
개발팀은 시행착오를 겪어가며 설계를 하고 설계 경험이 쌓여가면서 일반화된 설계 기법을 만들게 된다. 이번 공학트렌드에서는 이러한 설계 기법에 대해 4회에 걸쳐 살펴보고자 하며, 첫 번째로 테스트 설계에 대해 알아본다. 
요구사항이 설계와 개발에 모두 반영되었는지 확인하고 소프트웨어가 제대로 동작하는지 확인하는 것이 테스트이다. 테스트의 역할이 확대되면서 상황과 목적에 맞는 테스트 설계가 필요하게 되었고 테스트 설계 기법도 만들어지기 시작했다. 최근에는 체계화된 테스트를 위한 자동화 도구가 개발되었고, 애자일 기반의 테스트까지 선보이고 있다. 
이번 회에서는, 전통적으로 반드시 알아두어야 하는 테스트 설계의 종류와 테스트 종류에 따른 설계 기법에 대해 살펴보도록 한다.

테스트 설계의 종류 
테스트는 일반적으로 코딩의 오류(error)를 잡는 것이라고 알려져 있지만 의도대로 올바르게 동작하지 않는 결함(defect)과 이로 인해 발생하는 장애(failure) 여부를 확인하고 개발에서 일어나는 모든 과정과 문서까지도 테스트 범위에 포함된다. 
최상의 소프트웨어 품질을 위해서는 테스트를 반드시 거쳐야 하지만 테스트 결과가 완벽하다고 해서 소프트웨어가 우수하다고 볼 수는 없다. 테스트는 요구한 소프트웨어의 기능이 정확히 갖추어졌는지 확인하는 것이기 때문이다(표 1 참조). 
<표 1> 품질 관점의 테스트 범위 

테스트의 기본적인 형태는 비실행 기반 테스팅과 실행 기반 테스팅으로 나뉘어 진다(표 2 참조). 일반적으로 우리가 알고 있는 테스트가 실행 기반 테스팅이다. 개발된 기능이 정상적으로 동작하는지 확인한다. 실행 기반 테스팅이 모두 성공했다고 해도 요구된 모든 기능이 구현되었다고 볼 수는 없다. 비실행 기반 테스팅을 통해 요구사항이 모두 반영되었는지 확인한다. 

<표 2> 테스팅의 구분 
  

실행 기반 테스팅 
실행 기반 테스팅에는 블랙박스 테스팅과 화이트박스 테스팅으로 구분된다(표 3 참조). 실행 기반 테스팅은 대부분 개발자 또는 테스터가 직접 수행할 수 밖에 없었지만 최근에는 테스트 자동화를 통해 쉽고 빠르게 적용하고 있다. 

<표 3> 블랙박스 테스팅과 화이트박스 테스팅의 정의 
  

블랙박스 테스트와 화이트박스 테스트는 소프트웨어 내부 로직의 참조 여부로 구분한다. 블랙박스 테스팅은 소프트웨어의 특징이나 요구사항을 기준으로 검토되며, 유닛, 인티그레이션, 기능, 시스템, 적합성 등의 검사가 이루어진다. 화이트박스 테스팅은 소프트웨어가 올바른 로직으로 실행되고 있는지를 검토하는 것으로 블랙박스 테스팅에 비해 번거롭고 시간이 오래 걸리지만 근본적인 테스팅이 이루어진다. 
일반적으로, 블랙박스 테스팅만으로 소프트웨어의 정상 여부를 판단하는 경우가 많은데 원하는 결과가 나와도 정확한 로직으로 구동되었는지 화이트박스 테스팅을 통해 확인하는 것이 매우 중요하다.

비실행 기반 테스팅 비실행 기반 테스팅은 요구사항이 분석, 설계에 명확히 반영되었는지 확인한다. 일반적으로 문서 중심으로 테스트가 진행되며, 워크스루(Workthrough)와 인스펙션(Inspection)을 통해 검토한다(표 4 참조). 

<표 4> 워크스루와 인스펙션의 정의 

  

인스펙션은 프로세스 단계가 끝날 때마다 품질관리를 담당하는 전문가와 함께 수행하는 공식적인 활동이다. 인스펙션을 통해 만들어진 산출물의 완성도를 높이게 된다. 워크스루는 인스펙션을 준비하는 비공식적 활동으로 이해하면 된다. 워크스루는 횟수에 제한이 없고 개발팀 내부에서 자체적으로 실시하는 경우가 많다. 워크스루를 통해 예기치 않았던 작은 오류들을 수정하게 된다. 
일반적으로, 개발팀에서는 비실행 기반 테스팅을 하지 않거나 작성자가 직접 검토하는 경우가 많다. 소프트웨어는 고객의 요구사항을 기초로 만들어지는데 이를 정리한 산출물들을 검토하지 않으면 프로젝트 후반에 대대적인 수정이 필요할 수도 있다. 표준화된 프로세스가 아니더라도 요구사항이 분석서나 설계서에 반영되었는지 반드시 확인해야 한다.

원전 계측제어 소프트웨어 V&V 적용기술

그 어떤 산업보다도 ‘안전 운영’을 최우선으로 하는 원전계통의 운영 환경을 들여다 보면, 최근 들어 디지털 장치의 도입 및 적용이 점차 증가하고 있는 추세이다. 디지털 장치의 사용은 간편한 장치로써 다양한 제어 기능이 가능하기 때문에 편리하다는 장점이 있고, 여러 가지 운영 측면에서 효율성이 높기 때문이다. 이에 따라, 소프트웨어의 ‘안전성 보증을 위한 소프트웨어의 검증 기술’이 중요한 이슈로 대두되고 있다. 
최근 소프트웨어의 안전성 검증 관련 국제표준의 대응체계는 과거 소프트웨어 중심의 프로세스 안전성 검증개념에서 시스템과 소프트웨어를 ‘동시에’ 분석하는 개념으로 변화하고 있다. 이 같은 변화는 소프트웨어를 전체 시스템의 일부로 인식하여, 시스템 레벨에서 위험성 분석을 선행하고, 시스템 위험분석 결과로 도출된 시스템 안전요구사항을 바탕으로 소프트웨어 안전요구사항을 도출하는 것을 의미한다. 
 하지만 지금까지의 국내 SW V&V(Verification&Validation/ SW 안전검증) 적용 기술 수준 및 현황은 SW safety life cycle 개발 프로세스 이해 부족 및 SW safety life cycle 일부 단계 시범적용 수준이라 설명될 시점이므로 걸음마 단계라고 볼 수 있다. 
 이와 관련해, 국내 안전 소프트웨어 개발 공급자가 필수적으로 이해하여야 하는 safety life cycle의 선택방안과 안전 소프트웨어 개발을 위한 단계별 산출물에 관한 기본적인 가이드에 대해 한국SGS의 장우현 전문위원으로부터 조언을 구했다.

<한국 SGS 장우현 전문위원>



Q: SW V&V(Verification&Validation)는 왜 필요한가요?
 국내의 여러 가지 산업 분야에서 공통적으로 겪고 있는 애로사항이 바로 ‘소프트웨어 안전성을 어떻게 보증하는가’에 대한 고민이라고 할 수 있습니다. 소프트웨어 안전성을 보증한다는 의미는 소프트웨어가 가지고 있는 여러 가지 속성 중에서 특히 안전기능(Safety Function)이 올바르게 선정되었는지를 확인할 수 있어야 하고, 최종 개발 결과물이 수행하는 안전기능이 정상적으로 작동하는가를 확인하는 것입니다. 
 예를 들어, “원자로를 안전하게 보호할 수 있고, 위험성을 알릴 수 있는 SW를 개발하자” 라고 사람들이 먼저 생각을 합니다. 그러면 중간에 사업계획서를 만들고, 요구사항 명세서를 정리하고, 상세기술 명세서를 만들고, 소스코드를 만드는 등... 여러 직원들의 손과 머리를 거치고 나면 처음에 의도했던 바와 전혀 다른 결과물이 나올 수 있게 됩니다. 그렇기 때문에 SW V&V의 목적은 처음의 요구사항과 최종 결과물의 일치성을 확보하기 위해서고, 그중에서도 Safety Function이 원래 의도한대로 개발되었는가를 검사하는 것이 SW V&V입니다. [그림1 참조]
<그림 1> 실제 요구사항과 결과물인 소스코드의 차이발생
 사실 이러한 SW 품질검증의 개념은 시대에 따라 많은 변화를 거쳐왔습니다. 1990년대에 ‘Life cycle’이라는 말이 처음 등장하면서 프로세스를 검증하자는 움직임이 시작되었죠. 그리고 2000년대에 들어오면서 ‘Safety’가 추가되었습니다. 여기에다  2012년부터는 국제표준에 ‘System’이라는 개념이 추가되면서, ‘System&SW’로 변화되었죠.  [그림 2 참조] 
이것은 결국, 시스템을 고려하지 않고는 SW 안전 문제를 보증할 수 없다는 것입니다. SW가  HW에 내장되어 상호 인터랙션을 하기 때문에 시스템 전체의 시각으로 바라보지 않으면 SW안전은 확보될 수 없다는 뜻이죠. 원자력 관련 국제표준의 변화 상황도 동일합니다.[그림 3 참조]
<그림 2> SW 품질 검증 개념의 변화과정
<그림 3> 국제 표준 IEEE의 최근 동향

SOA와 클라우드 컴퓨팅의 발전 동향

SOA(Service Oriented Architecture, 서비스 지향 아키텍처)와 Cloud Computing은 조직의 IT 인프라 운영효율과 비용절감을 달성하는데 있어서 더욱 중요한 역할을 하고 있다.

SOA의 관점에서 보면, 서비스는 컴포넌트이고 인터페이스를 통해 비즈니스 프로세스 처리가 가능하다. SOA와 관련한 서비스는 3가지 특징을 갖는다.
- 서비스의 인터페이스는 플랫폼에 독립적이다.
- 서비스는 동적으로 검색될 수 있으며, 호출될 수 있다.
- 서비스는 자족적(self-contained)이며, 자신의 상태를 스스로 유지(self-healing)한다.

    SOA와 Cloud Computing은 독립적으로 존재할 수 있다. 즉, 상호 의존적이지 않고 서로 보완적으로 도움을 주고 받을 수 있다. Cloud Computing은 매우 유연하게 규모 있는 플랫폼을 제공할 수 있는데, 이것은 단순히 저비용의 혜택만을 주는 게 아니라  이전과 달리 고객, 파트너, 공급자와 연결되는 외부 서비스 처리를 가능하게 한다.

    하지만, SOA없이 Cloud Computing을 사용한다면 많은 어려움에 직면할 것이다. 왜냐하면, 단단한 아키텍처 기반 없이 어플리케이션들을 운영해야 하기 때문이다. 클라우드 환경으로 이전할 때 개념적으로나 물리적으로 복잡성이 또한 커질 것이다. 즉, 높은 확장성을 위해서는 어플리케이션 아키텍처와 이에 적합한 인프라가 필요하다.

    “클라우드 기반의 시스템은 SOA와 최신 Enterprise Architecture 원칙을 적용할 때 비로소 효과를 발휘한다.” - Paul Fremantle (WSO2 공동창업자이자 부사장)

    Cloud Computing을 구현할 때는 보안, 품질, 성능, 유용성 등의 핵심 이슈를 고려해야 하고 운영 단계로 들어가면 통합, 조정, 빠른 속도 등이 중요한 관건이 된다.  더 보기 >>>