소프트웨어 테스팅 노트

출처: 웹문서 The IoT Testing Atlas by Gayathri Mohan, 2017년

https://www.thoughtworks.com/insights/blog/iot-testing-atlas

디바이스와 그 내부 상태의 다양한 조합으로 인해 IoT 솔루션을 테스트하는 것은 매우 복잡하다. 저자는 다양한 상태 및 디바이스 조합을 관리하고 테스트케이스를 도출하는 데 도움을 주기 위해 IoT Testing Atlas라는 테스팅 프레임워크를 개발했다.

사물 인터넷(IoT: Internet of Things)의 출현은 품질 분석가(Quality Analysts)가 기존 프로세스를 돌아보게 만드는 몇몇 흥미로운 테스트 과제를 제시한다.

저자는 최근 모바일 앱이 연결된 머신과 통신하는 제품을 작업하였는데, 이 두 장치가 가지는 다양한 상태로 인해 테스트 시나리오를 작성하는 것이 특히 어려웠다. 따라서 내가 IoT 기반 제품을 테스트할 때 유용하다고 생각되는 프레임워크를 제시하고자 한다. IoT Testing Atlas라고 불리는 이 프레임워크는 IoT 배포에서 극도로 복잡해질 수 있는 다양한 상태 순열(permutations of states)을 관리하는 데 도움이 된다.

IoT 테스팅 패러미터

간단한 웹 애플리케이션에서 테스트되는 몇 가지 기본적인 상태(states) 또는 변형(variants)을 고려하면 다음과 같은 네 가지를 볼 수 있다. 

• 서버 다운(Server down)
• HTTP 시간 초과(HTTP timeouts)
• 느린 네트워크(Slow networks)
• 승인 및 인증 에러(Authorization and authentication errors)

어떤 인터넷 애플리케이션을 테스트하든지 우리가 이 네 가지 상태를 염두에 두어야 한다. 이제 모바일 애플리케이션을 고려해보자. 모바일 환경에서 작동하면서 발생하는 추가 상태들을 고려해야 하는 데, 여기에는 다음이 포함된다. 

• 오프라인 모드(Offline mode)
• 온라인 모드(Online mode)
• 액티비티 종료(Activity kill)
• 배경 동작(Background behavior)
• 언어(Languages)
• 위치(Location)

이제 '연결된 머신(connected machines)'이 도입하는 상태를 살펴보면 다음의 네 가지 새로운 상태를 볼 수 있다. 

• 머신 Wi-Fi 꺼짐(Machine Wi-Fi off)
• 머신 Wi-Fi 켜짐(Machine Wi-Fi on)
• 머신 사용 중(Machine is busy)
• 머신 수면 중(Machine is sleeping)

이렇게 예로 주어진 상태만 고려해도 전체 시스템이 어느 시점에나 보일 수 있는 상태가 약 96개(4 x 6 x 4)라는 것을 의미한다.

시스템 내의 상태 전환(state transition)은 추가 제약을 일으키므로 이러한 상태 각각은 독립 엔터티로 처리될 수 없다. 예를 들어 '오프라인'에서 '온라인'으로 상태가 변경되면 일련의 이벤트가 트리거될 가능성이 높다.

위의 패러미터 세트는 빙산의 일각일 뿐이다. 더 자세하게 들어갈수록 다양한 상태를 논리적 시나리오에 연결하는 것이 너무도 힘든 일이 될 수 있다. 저자가 올페어즈(all pairs), 동등 분할(equivalence partitioning), 경계 값(boundary value) 등과 같은 기존 기술을 사용해 본 결과, 정적 시스템에 대한 가변 데이터 세트(variable data set)로 시나리오를 도출하는 데 효과적이었다. 이 기법들이 테스팅을 위한 최적의 데이터 세트에 도달하기 위해 제거 로직(elimination logic)을 적용한다.

예를 들어, 올페어즈 기법은 반복적인 데이터 쌍 조합(repetitive data pair combination)을 제거하는 방식이다. 그러나 시나리오를 도출하기 위해 시스템의 가변 상태(variable states)에 동일한 기술을 적용하면, 제거된 시스템 상태로 인해 통신할 수 없는 시스템(a non-communicable system)으로 남아 신뢰가 떨어진다. 그럼에도 불구하고 이러한 기법이 IoT 시스템의 단일 장치 내에서는 여전히 잘 작동할 것이다.

이것이 저자가 IoT 테스팅 아틀라스의 필요성을 느낀 이유이다.

아틀라스 시각화(Visualising the Atlas)

대부분의 사람이 지리 수업 시간에 지도책(atlas)을 훑어본 경험이 있을 것이다. 내가 여기서 말하는 아틀라스는 모든 잠재적인 시스템 패러미터에 대한 윤곽을 그리고 특정 기능(a feature)을 테스트하는 데 필요한 의미 있는 시나리오를 도출한다.

제품 내의 모든 시스템이 n개의 상태(states)를 갖는 원(circle)으로 묘사된다. 논리적으로 가까운 다음 상태가 서로 가까이 배치된다. 이 원은 회전 가능한 엔터티이다. 내가 크로스기능 요구사항 CFR(또는 비기능 요구사항 NFR)에 대해서도 별도의 원을 포함시켰는 데, 이렇게 복잡한 통합을 테스트할 때 CFR을 쉽게 잊어버리는 경우가 많기 때문이다.

다음 이미지는 저자가 바라보는 IoT 테스팅 아틀라스의 모습이다.

이 아틀라스를 활용한 몇 가지 시나리오를 살펴보고, 오로지 모바일과 머신 인터액션만 포함하는 일부 기능에 대한 논리적 시나리오를 도출해 보자. 이는 우리가 집중할 원이 디바이스, 머신, 네트워크임을 의미한다.

모바일 디바이스와 머신을 Wi-Fi 켜짐 상태로 고정한다. 네트워크 원을 회전하면 다음과 같은 시나리오가 나타난다.

• 승인되지 않은 사용자가 머신에 액세스하려고 시도하면 앱에 '액세스 거부(Access Denied)' 에러 메시지가 표시된다.
• 서버 다운 및 서버 에러는 '문제가 발생했습니다. 나중에 다시 시도하세요.'와 같은 적절한 비즈니스 에러 메시지를 트리거해야 한다.
• 응답 시간 초과는 다음 두 가지 중 하나를 수행할 수 있다. 연장된 로딩 아이콘을 사용하여 동일한 리퀘스트를 다시 트리거하거나 위에 제시된 것과 유사한 에러 메시지를 표시한다.
• 유효하지 않은 리퀘스트는 '앱을 업데이트해야 합니다'와 같은 메시지를 트리거 한다.

이어서 모바일 디바이스를 Wi-Fi 켜짐 상태로 유지하고 한 번에 한 단계씩 머신 원을 이동한다.

• 머신이 오프라인 모드에 있을 때 앱은 '머신의 네트워크 연결을 확인하세요'라는 메시지를 표시해야 한다.
• 머신이 Busy 상태이면 '사용중이라 요청을 완료할 수 없습니다'와 같은 경고가 필요하다.
• 머신이 수면중(sleeping)이거나 다른 네트워크에 있을 때 '머신을 찾을 수 없음' 또는 유사한 메시지가 표시되어야 한다.
• 이제 머신을 올바른 네트워크로 전환하면 모바일과 머신 간의 연결이 다시 활성화되어야 한다.

머신 원에서 Wi-Fi 켜짐으로 전환하고 모바일 디바이스 원을 회전하여 더 많은 시나리오를 찾아보자.

• 모바일이 오프라인 상태가 되면 적절한 메시지나 동작(예: 버튼 비활성화)이 팝업되어야 한다.
• 모바일이 온라인 상태가 되면 머신과 연결을 위해 앱에서 적절한 호출이 이루어져야 한다.
• 모바일이 네트워크 Wi-Fi를 3G로 전환할 때 적절한 액션은 무엇인가?
• 사용자가 전화를 받고 앱이 백그라운드 상태에 들어가면 완료된 리퀘스트가 사용자에게 계속 보여야 하는가, 아니면 다시 원점으로 돌아가야 하는가?
• Android가 한동안 백그라운드에 있는 앱을 종료(kill)할 때 사용자의 마지막 화면 상태가 저장되어야 하는가?
• 현지화(localization) 여지가 있는 앱은 모든 시나리오 수준에서 확인이 필요하다.

이런식으로 아틀라스는 여러 회전을 통해 여러 시나리오로 확장될 수 있다. 일부 시나리오는 현재 기능에 맞지 않을 수도 있고 일부는 아예 비즈니스 니즈와 관련이 없을 수도 있지만 그럼에도 불구하고 아틀라스가 포괄적인 틀을 제공한다. 이 프레임워크는 제품의 여러 시스템으로 확장될 수도 있다.

실무에서 IoT 제품을 테스트하는 팀에 둘 이상의 QA가 있는 경우 이 아틀라스가 공통의 참조 지점을 제공한다. 아틀라스가 테스트를 위한 고유한 요구사항(도구, 장치, 시나리오 및 프로토콜의 순열)을 포괄적인 방식으로 커버하기 때문에 효율적인 협업을 달성한다.