소프트웨어 테스트 자동화 - '테스팅 전문가들의 생생한 사례연구 스토리로 익히는'을 읽고 나서 5/6

 

소프트웨어 테스트 자동화 국내도서 저자 : 도로시 그레이엄(Dorothy Graham),마크 퓨스터(Mark Fewster) / 황영석,성찬혁,여용구역 출판 : 에이콘출판사 2013.12.23 상세보기

 

 

01. 최적화된 데이터베이스 자동화 케이스

 - 설정 항목 4가지는 다음과 같다.

 

 

 

테스트 설정: 테스트는 데이터베이스로 정의되어 있어서 그룹, 개별, 선별적으로 선택 할 수 있었다. 테스트가 수행되기 전에 초기화하고, 테스트가 수행된 후에는 정리 작업을 해서 연속 수행되는 테스트에 영향이 없게 했다. 그리고 수행된 테스트 웨어는 수집하여 저장했다.

테스트 대상 애플리케이션 설정: 디버그 버전과 개발자의 샌드박스 버전을 선택 할 수 있었다.

서버와 클라이언트 플랫폼 설정: 플랫폼과 플랫폼 그룹을 쉽게 정의 할 수 있게 했다. 하나의 플랫폼 그룹 내에서 테스트는 테스트 리그에 나누어 분배 되었다. (예를 들어 윈도우 비스타, 64비트, JDK6). 하나나 두 개의 플랫폼을 사용해서 독립된 클라이언트를 설정할 수 있었다. 그리고 클라이언트와 서버 모두 다른 운영체제를 선택할 수 있었다.

일반적으로 테스트는 4대의 장비를 필요로 한다. 테스트 장비 1대, 클라이언트 장비 1대, 테스트 대상 데이터 베이스가 있는 서버 2개가 필요하다.

 

-리소스 최적화는 다음과 같다.
테스트 리그 풀에 장비를 더 추가해서 테스트를 병렬로 수행할 수 있었다. 수행되는 테스트는 순서대로 큐에 쌓였는데, 테스트 리그 내의 한 테스트가 종료되면 큐에 있는 다음 테스트가 시작되었다.

 

- 결과물은 다음과 같다.
3년간의 개발과 사용을 거치면서 한 명의 직원이 6~10개의 플랫폼에서 수행되는 약 200개의 출시 테스트를 3~4일 만에 수행할 수 있었다. 자동화 하기 전과 비교 할 때 이것은 20명의 직원(20대1 향상)이 40개의 테스트(5대1향상)를 한 개의 플랫폼(6대1 향상)에서 16일간 수행한 분량과 같다. 결과적으로 테스트 자동화 프로세스를 통해 적어도 2400배의 능률을 향상시키는 효과를 얻을 수 있었다.
이제 모든 테스터는 테스트 개발과 도구 개발에 집중 할 수 있었고, 반복되는 업무를 수행하는 지루한 일에서 벗어날 수 있었다. 제품의 품질과 테스트의 품질은 비교 할 수 없을 정도로 향상 되었다. 개발자와 테스터는 서로 존중하고 도전하는 분위기가 조성되었고, 업무는 더욱 매력적이 되었다.
유지보수는 테스터 한 명의 10% 이하 리소스로 진행했다. 최소한의 리소스로 가능했던 이유는 제품 개발의 요구사항 중 하나로 하위 호환성을 고려했기 때문이다. 새로운 기능 때문에 테스트나 테스트 도구 자체가 변경되는 경우는 드물었다. 대부분의 경우 새로운 기능이 추가 되면 테스트를 추가하거나 테스트 순서를 변경하여 해결하였다.

다시 정리하면

 

* 사내 테스트 도구 개발의 설정 항목
- 테스트 설정: 테스트는 데이터베이스로 정의되어 있어서 그룹, 개별, 선별적으로 선택할 수 있었다. 테스트가 수행되기 전에 초기화되고, 테스트가 수행된 후에는 정리 작업을 해서 연속 수행되는 테스트에 영향이 없게 했다. 수행된 데이터웨어는 수집하여 저장했다.
- 테스트 대상 애플리케이션 설정: 디버그 버전과 개발자의 샌드박스 버전을 선택할 수 있었다.
- 서버와 클라이언트 플랫폼 설정: 플랫폼과 플랫폼 그룹을 쉽게 정의할 수 있게 했다. 하나의 플랫폼 그룹 내에서 테스트는 테스트 리그에 나누어 분배되었다. 하나의 플랫폼을 사용해서 독립된 클라이언트를 설정할 수 있었다.
- 일반적으로 테스트는 4대의 장비를 필요로 한다: 테스트 장비 1대, 클라이언트 장비 1대, 테스트 대상 데이터베이스가 있는 서버 2대가 필요하다.

* 리소스 최적화
테스트 리그 풀에 장비를 더 추가해서 테스트를 병렬로 수행할 수 있었다. 수행되는 테스트는 순서대로 큐에 쌓였는데, 테스트 리그 내의 한 테스트가 종료되면 큐에 있는 다음 테스트가 시작되었다.

* 사내 테스트 도구 개발의 결과물
3년 간의 개발과 사용을 거치면서 한 명의 직원이 6~10개의 플랫폼에서 수행되는 약 200개의 출시 테스트를 3~4일 만에 수행할 수 있었다. 자동화하기 전과 비교할 때 이것은 20명의 직원이 40개의 테스트를 한 개의 플랫폼에서 16일간 수행한 분량과 같다. 테스트 자동화 프로세스를 통해 2400배의 능률을 향상시키는 효과를 얻을 수 있었다. 모든 테스터는 테스트 개발과 도구 개발에 집중할 수 있었고, 반복되는 업무를 수행하는 지루한 일에서 벗어날 수 있었다. 제품의 품질과 테스트의 품질은 비교할 수 없을 정도로 향상되었다.

 

 

 

 

02. 테스트 프로세스가 지속적으로 향상되어 만들어진 테스트 수명 주기 5단계

 테스트 프로세스가 지속적으로 향상되어 만들어진 테스트 수명주기 5단계는 다음과 같다.

테스트가 개발되면 검토 후 승인되고, 테스트는 후보 배치에 포함된다. (전체 자동화 테스트 스위트에 포함된다.)
후보 테스트가 4일 이상 실패하면 후보에서 제외되어 개발로 돌아간다. 한 주 동안 실패가 없으면 테스트는 활동 상태가 되어 매주 밤마다 수행되는 테스트 스위트에 포함되었다.
제품의 기능이 변경되었는데 테스트가 업데이트 되지 않았다면 테스트는 중지 상태가 됐다. 중지 원인에 따라 테스트는 다시 활동 상태가 되거나 후보 상태가 될 수 있으며, 실패 원인이 수정된 후에는 다시 상태가 변경됐다.
정기적으로 테스트 스위트의 내용을 평가했다. 수행한 테스트의 가치를 측정하기 위한 지표가 상용됐는데, 평과 결과에 따라 테스트는 다른 테스트 스위트로 이동되거나(이를 통해 더 자주 수행되거나 적게 수행될 수 있다.) 어떤 경우에도 종료 되기도 했다. 테스트가 더 이상 필요 없을 경우에는 해당 테스트를 삭제할 수 있었다.
많은 지표가 만들어 졌는데, 우선순위와 목적에 맞게 최적화되어 아주 만족스러운 결과를 얻을 수 있었다. 의심의 여지 없이 제품 승인 프로세스에 대한 신뢰가 이전보다 크게 향상 되었다.

 

다시 정리하면

 

* 테스트 수명 주기 5단계: 후보 ㅡ 활동 ㅡ 중지 ㅡ 종료 ㅡ 삭제
테스트가 개발되면 검토 후 승인되고, 테스트는 후보 배치에 포함된다. 후보 테스트가 4일 이상 실패하면 후보에서 제외되어 개발로 돌아간다.
제품의 기능이 변경되었는데 테스트가 업데이트되지 않았다면 테스트는 중지 상태가 됐다. 중지 원인에 따라 테스트는 다시 활동 상태가 되거나 후보 상태가 될 수 있으며, 실패 원인이 수정된 후에는 다시 상태가 변경됐다.
정기적으로 테스트 스위트의 내용을 평가했다. 수행한 테스트의 가치를 측정하기 위한 지표가 사용됐는데, 평가 결과에 따라 테스트는 다른 테스트 스위트로 이동되거나 어떤 경우에는 종료되기도 했다. 테스트가 더 이상 필요 없을 경우에는 해당 테스트를 삭제할 수 있었다.

 

 

 

---

 

 

 

 

03. 하드웨어 인터페이스를 사용한 신뢰성 테스팅의 자동화 케이스

 

 

 점증적 접근 방법에 의한 테스트 자동화와 관련된 테스트 프레임워크의 인크리먼트 1, 인크리먼트 2, 인크리먼트 3은 다음과 같다.

테스트 프레임워크의 첫 번째 인크리먼트는 시스템의 하드웨어 인터페이스로 구성되었다(예를 들어 키보드의 버튼과 핸드 스위치, 엑스레이 수집을 시작하는 풋 스위치). 이 시스템은 하드웨어 신호를 시뮬레이션 해서 랩뷰에서 접근할 수 있었다. 이러한 접근 방법을 선택했던 것은 시스템의 임베디드된 소프트웨어를 변경하는 것이 목적이 아니었기 때문이다. 소프트웨어 개발 멤버는 새로운 기능 구현으로 바빴다. 테스트 팀에서 요청한 새로운 기능은 분명히 거절할 것이었다. 랩뷰를 선택한 것은 이미 하드웨어 개발팀에서 다른 하드웨어 컴포넌트를 측정하고 테스트하는 데 사용하고 있었기 때문이다.  첫 번째 인크리먼트의 아키텍처는 아래 그림과 같다.

처음 일부 테스트 케이스는 랩뷰의 그래픽 언어를 사용해서 설계되었다. 우리는 기간 테스트에 초점을 맞췄는데, 작은 규모로 빠르게 구현 가능하지만 효과는 시스템에서 수일 동안 실행될 수 있었기 때문이다. 작은 노력이 필요하지만 그 결과로 많은 테스트 시간을 벌 수 있고 이런 테스트 케이스가 일부 치명적인 결함을 찾을 수도 있다. 개발이 진행되는 몆주 내에 첫 번째 테스트는 시스템이 사용되지 않는 밤이나 주말에 실행될 수 이었다. 테스트가 첫 주말에는 일부 시스템에서 스타트업 문제가 발생했다. 그래서 다음주에는 테스트 케이스를 조금 확장 변경했다. 시스템을 끄기 전까지 엑스레이 수집을 좀 더 했고, 시스템 사용의 증가에 따라 더 많은 결함을 발견했다. 개발자는 이 문제를 분석하고 수정하는데 바빴고, 그 결과 다음 마일스톤(내부 배포)은 지연되었다. 일부 버그 수정은 계획 내에서 스케줄 되었지만, 전체 이슈를 수정하기에는 부족했다. 고위 경영진에서는 마일스톤 일정을 맞추기 못한 것에 언짢아했지만, 품질이 향상된 것은 인지했다. 그들은 분명 품질을 첫 단계에서 요청했었다.
선택한 프레임 워크는 테스트 대상 시스템에서만 동작을 수행했지만, 시스템이 정말로 정해진 시간에 예상대로 수행되었는지는 검증하지 않았다. 시스템은 모든 정보를 담은 로그 파일을 수행했고, 서비스 엔지니어와 개발 엔지니어는 해당파일을 받아 보았다. 이 로그 파일은 테스트가 수행된 후 실패 확인을 위해 분석했다. 물론 추가로 작업 시간이 필요했지만, 개발 부서는 이를 통해 실패의 증거를 얻을 수 있었다.

다음 단계에서 테스트 자동화 접근 방법 적용을 진행하게 경영진으로부터 확인을 받은 후, 테스트 프레임워크를 좀더 개발할 수 있는 리소스와 투자를 받았다. (하드웨어와 LabVIEW로 구성된 테스트 프레임워크는 비용이 만만치 않았다). 다음 단계(인크리먼트2)에서는 랩뷰로부터 추상화 작업을 했다. 랩뷰의 프로그래밍 언어는 테스트 케이스를 정의하기에 적합하지 않았기 때문이었다. 랩뷰를 테스트 엔지니어가 학습하기에는 어려웠기 때문에 랩뷰에서 테스트 케이스의 유지보수성은 이슈가 될 것으로 예상했다. 테스트 엔지니어는 기본 프로그래밍 언어를 사용하는 것은 불가능했다. 그래서 유연성 있고 사용하기 쉬운 스크립트 언어를 사용하기로 결정했고, 루비를 선택했다.
루비는 간단함과 생산성에 초점을 맞춘 동적 오픈 소스 스크립트 언어이기 때문이다. 명쾌한 문법을 가져서 자연스럽고 쉽게 작성 가능하고, 수많은 정보 지원을 얻을 수 있으며 랩뷰와도 인터페이스가 잘 된다. 하드웨어 추상화 레이어는 여전이 랩뷰에서 프로그래밍했지만, 테스트 케이스는 이제 루비로 프로그래밍 할 수 있고, 랩뷰의 복잡함을 감출 수 있다. 테스트 케이스의 표준 기능은 라이브러리로 구현했다. 그래서 테스트 케이스는 복잡하지 않았고 테스트 케이스의 유지보수성은 증가했다. 향후에는 프레임워크를 신뢰성 테스트뿐 아니라 기능 테스트에도 사용하려고 했기 때문에 유지보수성을 미리 고려했다.

 

세 번째 인크리먼트에서는 로그 파일 해석을 추가했다. 로그 파일은 수 많은 정보를 담아 테스트 대상 시스템에서 제공했다. 여기에는 사용자가 수행한 모든 동작과 중요한 내부 시스템 이벤트를 기록했다. 이 로그 파일은 이제 하드웨어 추상화 레이어를 통해 테스트 프레임워크가 제공했다 그리고 테스트 케이스가 실행되는 동안 테스트 케이스는 로그 파일을 해석할 수 있게 되었다. 테스트 케이스는 로그 파일을 스캔 해서 특정 정규 표현 식을 찾았고, 이를 통해 성공이나 실패기준을 구현할 수 있었다.
처음 두 인크리먼트에서 테스트 케이스는 수행 동작들로만 구성되었지 동작들로만 만, 이제는 체크하는 부분도 테스트 케이스에 추가되었다. 또한 로그 파일 분석을 통해 로그 파일에 기록된 정보에 따라 테스트 케이스를 다른 경로로 실행할 수 있었다(물론 테스트 케이스는 좀 더 복잡해진다). 이를 통해 테스트를 매우 효율적으로 수행할 수 있었다. 광범위하게 시스템을 테스트할 때 이 테스트는 신뢰성 테스트가 진행될 동안에도 진행될 수도 있는데, 일부 시스템은 매우 뜨거워 져서 쿨링 다운 상태로 들어가게 된다. 이 상태에서는 엑스레이 노출이 수행될 수 없다. 그리고 대부분의 테스트 케이스는 실패가 된다. 이제는 이런 상태를 해결할 수 있었다. 쿨링 다운 상태에서는 전원 사이클power-cycle 테스트를 수행했다. 이 테스트는 시스템을 끄고 다시 킨 후 로그 파일을 통해서 시스템 스타트업이 성공했는지 체크했다. 프레임워크는 시스템 온도를 모니터링하고, 시스템이 충분히 식으면 다른 기간 테스트를 실행한다. 쿨링 다운 시간에 다른 가치 있는 테스트 케이스를 수행할 수 있었기 때문에 효율성이 향상되었다. 테스트 결과를 평가하는 부분도 테스트 실행 시간에 성공과 실패 기준을 체크해서 수행되었다. 하지만 발견되지 않은 에러 상태와 예상치 못한 수행을 분석하려면 로그 파일을 여전히 수동으로 분석했다(예를 들어 하드웨어 실패는 테스트 케이스로 발견되지 않지만 이후의 수동 분석에서는 발견되어야 했다.) 몇 가지 작은 규모의 직접 만든 로그파일 분석 툴도 개발되어 테스트 대상 시스템으로부터 로그 파일을 스캔하고 파싱해서 다음과 같은 기능을 수행했다.
-로그 파일에서 에러를 찾는다
-다른 에러 발생 수를 카운트한다
-로그 파일로부터 성능을 유추한다(예를 들어 초당 처리 이미지 수)

소프트웨어 인터페이스는 시스템 내 소프트웨어의 변경 없이 그대로 프레임워크 에 통합되었다. 그래서 테스트 케이스에서 내부 소프트웨어의 기능을 사용할 수 있었고, 기대 결과의 상태와 실제 결과의 상태가 동일한지 확인하고자 특정 상태를 정의 할 수 있었다. 테스트 케이스를 설계하면서 다음과 같은 규칙을 지켰다.
- 테스트 케이스 수행 동작에서는 가능하면 최대한 실제 사용자와 비슷하게 외부 인터페이스를 사용한다. 동작을 수행하기 위해 내부 인터페이스를 사용하는 것 은 피해야 한다.
-내부 인터페이스는 로그 파일로부터 특정 상태나 변수 값을 체크할 수 없을 때 만 사용해야 한다.
프레임워크의 이런 접근 방법을 사용해서 스모크 테스트와 리그레션 테스트, 기능 테스트, 비기능 테스트와 같은 다른 종류의 테스트 케이스도 만들 수 있다. 리소스 제 한이 있었기 때문에 이런 테스트는 아직 만들지 못했다. 우리는 남아 있는 신뢰성 테스트에 모든 리소스를 집중했기 때문인데, 어쨌든 프레임워크는 이런 종류의 테스트를 지원했다.
테스트 실행의 정의와 실행을 할 수 있도록 테스트 스케줄러를 개발했다. 또한 실행된 테스트 케이스의 개요와 실행 결과를 요약해서 보여주는 리포트를 생성하는 기 능을 개발했다. 테스트 케이스(스크립트)와 테스트 프레임워크, 테스트 결과는 중앙 리파지토리에 저장했다. 그리고 프로젝트 내 소프트웨어와 문서에서 동일 버전을 사용 해서 소프트웨어와 시스템을 테스트할 때 사용하는 테스트 케이스 버전이 다르지 않게 예방했다. 이것은 전문화를 향해 한 걸음 전진하는 것이었다.
테스트 프레임워크에서 하드웨어 신호로부터 읽기와 이미지 파이프라인으로부터 이미지 검색과 같은 다른 개선이 필요한 부분도 이미 정의되었다. 이러한 개선점은 다음 인크리먼트에서 구현될 예정이었다.
신뢰성 이분법적인 특성이 아니다. 그래서 이 시스템은 신뢰할 만하다'라고 말할 수 없다 이것은 양적인 특성 표현으로, 예를 들어 평균 고장 시간 간격과 같다. 우리는 새로운 시스템이 이전 시스템보다 더 신뢰할 수 있다는 것을 보여주고 싶었다 그래서 같은 테스트 케이스를 사용해서 이전 시스템의 신뢰성 측정이 필요했다. 이 테스트 케이스는 하드웨어 인터페이스를 사용해서 시스템의 동작을 실행했는데, 하드웨어 인터페이스는 전혀 변하지 않았기 때문 이전 버전 시스템에서도 테스트 케이스를 그대로 실행할 수 있었다. 프레임워크나 테스트 케이스는 중단 없이 실행되었다. 이제 기존(리거시)시스템과 새롭게 개발한 시스템 의 신뢰성을 명확하게 비교할 수 있었다.
아래 그림은 테스트 프레임워크의 세 번째 인크리먼트의 아키텍처를 보여준다.

 

 

04. 테스트 자동화 접근 방법이 성공하기 위한 포인트 4가지와 우리 회사는 시스템의 신뢰성을 확보하기 위한 노력

 테스트 자동화 접근 방법이 성공하기 위한 포인트 4가지는 다음과 같다.
- 정확한 시기에 적합한 프로젝트를 선택하자.
- 테스트 프레임워크를 점진적으로 개발해서 추가되는 가치를 가능하면 빨리 보여주자
- 프레젠테이션을 자주해서 접근 방법과 결과를 공유하자.
- 명확하고 간단하여 이해하기 쉬운 신뢰성 성장 리포트를 사용하자

 

우리회사는 시스템의 신뢰성을 확보하기 위해 어떤 노력을 해야 하는지 실천방안은 다음과 같다.

현재 이미지 매칭을 통한 자동화 테스트를 진행하고 있는데 실제 적용 불가능한 부분도 있고 서체, 애니메이션 적용에 따라 이미지 결과 비교 값이 달라져서 신뢰성이 낮아지게 된다. 그래서 OS의 애니메이션 효과 미적용, 서체 통일을 통한 예상결과와 실제 결과 이미지를 최대한 같게 만들어서 자동화 테스트의 신뢰성을 확보하는 실천방안이 되겠다.