책 발췌 – 수도 계량기 모니터링 시스템 테스트 자동화 사례 by Axelrod

출처: 책 Complete Guide to Test Automation, Arnon Axelrod, 2018년
APPENDIX A Real-World Examples, 455~461페이지

 

이스라엘의 테스트 자동화 전문가인 저자가 실제 애플리케이션의 테스트 자동화 컨설팅을 수행한 경험을 기술함

 

---

 

예1 – 수도 계량기 모니터링 시스템(Water Meters Monitoring System)

이 고객은 전자 수도 계량기와 도시/지역에 배치된 계량기를 제어하고 모니터링하는 시스템을 개발한다. 계량기는 자체에 전자 장치와 임베디드 소프트웨어를 가지고 있으며 제어 및 모니터링 시스템과는 별도로 개발되고 테스트되었다. 고객은 제어 및 모니터링 시스템을 위한 테스트 자동화 인프라를 구축하는 데 도움을 원했다. 이 시스템은 Google Maps 위젯을 통해 계량기와 그 상태에 대한 정보를 디스플레이하는 웹사이트이며, 또한 표, 양식, 차트와 같은 보다 표준적인 방식으로도 정보를 디스플레이 한다. 이 시스템은 그림 A-1과 같은 아키텍처를 가진다.

그림 A-1. 수도 계량기 모니터링 시스템의 아키텍처 다이어그램

 

컴포넌트와 컴포넌트 간 인터액션에 대한 설명이 아래와 같다.

• Web Client: 브라우저가 JavaScript와 CSS를 사용해 UI를 표시하고 사용자와 인터액션하는 HTML 페이지이다. 다른 웹사이트와 마찬가지로 HTML 페이지, 관련 파일, 디스플레이 데이터는 서버 측의 Web Server로부터 가져온다. 메인 페이지는 Google Map 위젯을 표시하고 Google Maps JavaScript API를 사용하여 지도의 계량기 위치에 마커를 추가한다.
• Web Server: 웹사이트의 서버 측으로 HTML, JavaScript, CSS 파일을 클라이언트의 브라우저에 제공하고, 디스플레이할 데이터를 주는 Web API도 제공한다. Web Server는 데이터를 조회하고 중요 업데이트에 대한 이벤트를 Data Layer로부터 수신한다. 또한 Data Layer를 통해 커맨드를 계량기에 보낼 수 있다.
• Data Layer: 데이터 액세스를 관리하고 데이터 업데이트에 대한 관련 알림을 상위 계층에 보낸다. Web Server는 Data Layer를 사용하여 데이터베이스에서 데이터를 조회하고, 알림을 받고, 커맨드를 보낸다. Data Aggregator는 Data Layer를 사용하여 데이터베이스에 데이터를 저장 및 업데이트하며, 또한 계량기로 전송할 커맨드를 받는다.
• Data Aggregator: Communication Server를 통해 지역 전체의 모든 계량기로부터 거의 실시간에 가까운 데이터 스트림을 수신한다. 수신한 데이터를 집계하여 Data Layer가 요구하는 구조로 변환한다. 또한 Data Layer의 요청에 따라 계량기에 커맨드를 보낸다. 이 커맨드를 보내기 전에 Data Aggregator는 먼저 애플리케이션의 내부 데이터 구조에서 계량기가 이해할 수 있는 프로토콜로 커맨드를 변환한다.
• Communication Server: 고객이 외부업체에 발주하여 개발한 것으로 애플리케이션과 계량기 사이에서 특수 라우터처럼 작동한다. 이 서버 자체는 메시지의 내용을 읽거나 변경하지 않으며 단지 셀룰러 네트워크를 통해 메시지를 올바른 계량기로 보내고 받는다.
• 계량기: 물의 흐름을 측정하고, 문제를 경고하며, 수도꼭지 열기 또는 닫기와 같은 명령을 받아들이는 물리적 전자-기계 장치이다. Communication Server와 통신하기 위한 셀룰러 안테나가 장착되어 있고, 회사의 완전히 별개 그룹에서 따로 개발한 소프트웨어를 장치 내에 포함하고 있다. 제어 및 모니터링 시스템의 테스트가 목적이므로 이 장치 내 소프트웨어는 시스템의 필수 부분이 아닌 것으로 제외된다.

 

QA 팀의 자동 테스트 프레임워크 구축을 도와달라는 요청을 받았을 때 그들에게 테스트를 해야 하는 중요한 것이 무엇인지 물었고, 그들의 첫 반응은 "끝에서 끝까지 전부 다(end to end)"였다. 그러나 더 깊은 대화가 진행되면서 그들이 정말로 신경쓰는 것은 UI와 서버 부분이며(이게 고객 그룹이 직접 구축한 소프트웨어), 반면 Communication Server와 계량기 자체는 안정적이고 신뢰할만 한 것으로 여겨 그들의 관심이 적었다.

 

Communication Server 시뮬레이션

다음은 고객에게 오늘 수동 테스트는 어떻게 수행했는지를 물었다. 그들이 한 클라이언트의 데이터베이스 복사본을 사용하고 있고 모든 테스트를 Web Client UI를 통해 수행하는 것으로 나타났다. 고객은 이 회의를 통해서야 많은 로직을 가진 Data Aggregator 컴포넌트를 자신들이 전혀 테스트하지 않고 있음을 깨달았다. 테스트 자동화 관점에서 어떻게 접근할지에 대해 논의했을 때 계량기와 Communication Server를 위한 시뮬레이터를 만들어야 한다는 결론에 도달했다. 이것은 Data Aggregator 컴포넌트도 테스트할 수 있는 유일한 방법이며, 서로 영향을 끼치지 않는 신뢰할 수 있는 테스트를 생성하는 데에도 필요하였다. 

문제는 프로토콜에 대한 지식을 개발자만 가지고 있어서 개발자가 시뮬레이터 개발을 해 주어야 하는데, 이들이 너무 바빠서 가까운 장래에 그럴 시간이 없을 것이라는 점이였다. 따라서 나는 개발자는 프로토콜에 대한 문서와 약간의 지식 전달만 제공하고 실제 시뮬레이터 개발은 자동화 개발자가 할 것을 제안했다. QA 매니저가 관련 개발자에게 전화를 걸어 이를 도와줄 수 있는지 물었고, 그는 즉시 동의했다! 개발자가 프로토콜에 대한 매우 상세한 문서를 가지고 있었으며, 불분명하거나 오래된 세부 사항에 대해서는 기꺼이 도움을 주었다. 그림 A-2는 테스트 자동화의 최종 아키텍처를 나타낸다.

 

그림 A-2. 수도 계량기 모니터링 시스템의 최종 테스트 아키텍처

 

Google Maps 처리

또 다른 아키텍처적인 어려움은 Google Maps 컴포넌트에 있었다. Google Maps 컴포넌트를 포함하는 모든 웹 페이지가 그림 A-3과 같은 아키텍처를 가진다.

그림 A-3. Google Maps를 포함하는 Web Client 아키텍처

 

Selenium이 우리의 UI 자동화 기술이었기 때문에 Google Maps 같은 그래픽 컴포넌트와 관련하여 작업하기가 쉽지 않았다. Google Maps는 지도를 표시하는 데 필요한 선과 모양을 나타내는 모든 원시 데이터를 포함하는 HTML 5 SVG((Structured Vector Graphics) 엘리먼트를 기반으로 한다. Selenium이 이 데이터에 액세스할 수 있는 반면 이에 대해 추론하고 사용자 눈에 보이는 것의 의미를 알아내는 것은 불가능하다. 하지만 Google Maps는 더 의미 있는 정보와 오퍼레이션을 제공하는 JavaScript API도 막후에서 사용한다. Selenium이 브라우저에서 직접 실행되도록 JavaScript 코드를 보낼 수 있고 그 결과를 받을 수도 있다. 따라서 Selenium을 사용하여 Google Maps의 JavaScript API를 쿼리하고 조작할 수 있으며, 이를 통해 사용자가 보는 것이 무엇인지 의미(개념)을 얻어낼 수 있다. 그림 A-4는 Google Maps 컴포넌트와 관련한 솔루션의 아키텍처를 보여준다.

그림 A-4. Google Maps 컴포넌트를 포함한 Web Client의 테스트 아키텍처