이 포스트는 “지식 제로부터 배우는 소프트웨어 테스트”를 읽고 학습한 내용입니다.
우리 팀은 테스트를 그렇게 잘하는 팀은 아니다. 테스트를 전혀 모르는 신입 한 명이 테스터의 전부다.
나도 개발자 출신이라 그동안에 테스트 활동을 옆에서만 지켜 봤지, 실제로 테스트를 수행 해 본적은 없다. 그래도 들은 풍월은 있어서 기능 요구 테스트와 비기능 요구 테스트를 각각 수행은 하고 있다.
이 책을 읽기 전에는 기능 요구 테스트는 단순히 기능별로 나눈 케이스로 테스트를 진행 했고, 비기능 요구 테스트는 최근에서야 소프트웨어의 동작 성능을 체크하는 수준이다.
이번에는 이 책에서 말하는 가장 어려운 테스트인 비기능 요구 테스트에 대해서 정리 해 보도록 하겠다.
비기능 요구 테스트란?
비기능 요구 테스트는 기능이 아닌 부분, 즉 품질 특성을 테스트하는 것을 말한다. 그렇다면 품질 특성에는 어떤 것들이 있을까? 아래 표(ISO 9126 품질 특성)와 같다.
소프트웨어 아키텍트에게 설문한 결과 이 중에서 중요한 특성은 보안성, 신뢰성, 효율성 이라고 한다.
이 특성들을 모두 만족하는 것은 무리이며, 특성 간은 각각 Trade-off 관계라고 말하고 있다.
성능 테스트(Performance Test) 란?
소프트웨어를 설계하거나 기획하는 단계에서 설정된 소프트웨어의 성능이 기대한 대로 나오는가를 확인하기 위한 테스트이다. (우리 팀에서도 성능 테스트를 종종 하는데, 주로 하는 것이 소프트웨어 로딩 시간 체크 이다.) 성능 테스트도 비기능 요구 테스트의 일부이다.
성능 테스트시 주의 사항
성능의 정의는 명확하게 해야 한다.
예를 들어
30MB 를 처리할 때 1분 이내로 되어야 한다
10MB 의 파일을 열 때 10초 이상이 걸리면 안된다
소프트웨어를 실행 시키면 로딩 시간이 1분 이내로 모든 초기 작업을 완료 해야 한다
와 같은 정의가 명확해야 한다.요구 정의대로만 테스트 케이스를 작성해서는 안된다.
테스트는 버그를 찾는 작업 이므로 요구가 정의 된 대로만 테스트가 수행이 되면 아무 의미가 없다.성능 테스트는 미루지 말아야 한다.
성능 테스트에서 발견되는 버그는 최악의 버그다. 문제가 심한 경우 소프트웨어 구조 자체를 변경해야 하는 경우까지도 있을 수 있으므로 어느 정도 소프트웨어가 동작하는 시점에서는 수행하는 것이 좋다.
성능 테스트 5 단계 ( 이 부분은 책에도 내용이 별로 없다. )
아키텍처 검증
소프트웨어의 아키텍처 측면의 스펙을 검토 한다. 예를 들어 우리 팀의 경우 electron 기반의 데스크탑 앱을 만들고 있는데, electron 자체에서 지원하는 스펙이 동작하는데 적합한지를 확인 해야 한다.성능 벤치 마크
실제 개발된 소프트웨어를 테스트 하는 것을 말한다. 소프트웨어의 로딩 시간을 측정 한다든가 하는 활동을 말한다.성능 회귀 테스트
이 테스트는 프로그램 개발 도중에 항상 변하는 상태에서 수행 하는 것을 말한다. 기능 수정이 이루어진 부분만 테스트하는 것이 아니라, 기존에 확인 했던 다른 부분도 확인을 해 줘야 한다.성능 튜닝 및 엑셉턴스 테스트
최종 제품이 요구 정의에 정해진 성능을 내는지 확인하는 것을 말한다.24x7 성능 모니터링
실제 사용 하는 데이터로 테스트가 불 가능 할 경우 더미 데이터로 검토 하라는 이야기인데.. 왜 24x7 성능 모니터링인지… 모르겠다.
나는 성능 테스트에 대해서는 크게 인사이트를 얻을 수 없었다.
신뢰성 테스트
소프트웨어의 신뢰성을 측정 하려면 신뢰도 성장 곡선을 그려야 한다. 여기서 의미 있는 개념은 평균고장간격 (Mean Time Between Failure : MTBF ) 이라는 것인데, 단위 시간당 어느 정도의 Failure (버그나 시스템 멈춤, 재부팅)을 일으키는지 측정하는 것이다. 이를 통해 신뢰성을 판단 할 수 있다고 한다.
예를 들어 어떤 소프트웨어를 테스트 해서 평균 5시간 정도 조작하면 결국 느려진다던가 멈춘다거나 한다면 MTBF 는 5시간 이다. 그렇다면 소프트웨어의 요구 정의에서 MTBF 가 24시간 이상 되어야 한다 라고 하면 신뢰성 테스트의 기준이 될 것 같다.
그리고 신뢰도 성장 곡선에 대한 내용이 나오는데, 신뢰도 성장 곡선은 아래 수식으로 그릴 수 있다.
m(t) : 시간 축에 대한 신뢰성
a : 기대 하는 장애(버그)의 총 수
b : 버그 발견율
t : 테스트 실행 시간
최종적으로는 테스트 케이스 실행에 대해 버그 곡선을 그리는 것이 거의 의미가 없다고 말하고 있다.
(왜 설명한거지..)
일단은 그냥 이런 것이 있다 정도로 넘어가야 겠다. 설명도 명확치 않을 뿐 더러 어떻게 활용 해야 할지도 사실상 의문이다. 이 부분에 대해서는 다른 책을 좀 더 읽어보고 공부 하는 것으로 하겠다.