CTFL Mobile Tester Syllabus 제4장 환경과 도구

Certified Tester Foundation Level  Mobile Tester Syllabus

 

제4장 환경과 도구

 

4.1 도구
모바일 디바이스 및 어플리케이션 시장은 빠르게 확대되고 있다. 다행히도 모바일 어플리케이션 
테스트를 위한 도구의 증가도 그 속도를 따라가고 있다. 이제 테스터는 다양한 기능과 신뢰성을 
가진 도구 중 가장 적합한 도구를 선택하기 위해 노력해야 하는 상황에 직면해 있다. 이 섹션은 
테스터가 선택 가능한 도구에 대한 이해도를 높이고 특정 어플리케이션과 환경에 가장 적합한 도 
구를 선택할 수 있도록 지원한다.

4.1.1 모바일에 적용
시장에는 굉장히 많은 종류의 테스트 도구가 있다. 그 중 일반적인 테스팅 지원 도구와 모바일 
어플리케이션 테스팅에 맞추어 특별히 조정된 도구를 식별하는 것은 매우 중요하다. 일반적으로 
모바일 테스팅에 초점을 맞춘 도구는 다음 사항을 수행할 수 있어야 한다:

• 다양한 환경 및 프로토콜에 적응
• 네이티브 디바이스 시물레이션
• iOS, 안드로이드와 기타의 다른 운영체제에 걸친 테스팅 지원
• 복수의 사용자 동시 시물레이션
• 디바이스의 다양하게 조합된 위치 지원
• 다양한 속도와 품질의 네트워크 시물레이션 또는 지원
• 접속이 끊기거나 재접속되는 등의 상황을 만들 수 있는 접속 상태를 시물레이션 또는 
제공

도구를 탐색할 때, 테스터는 자신의 필요에 가장 적합한 도구를 선택하기 위해 어플리케이션의 
기능, 지원되는 환경 그리고 테스팅 요구사항을 이해하고 있어야 한다. 시장이 매우 빠르게 변화 
하기 때문에 도구 선택에 유용한 절차의 사용이 중요하며, 해당 도구의 판매사가 좋은 품질의 제 
품을 만들고 필요한 지원을 제공하는지를 확인해야 한다. 도구가 특정 환경에 적합한지를 보기 
위해 파일럿 테스트가 필요하다. 도구의 선택 및 배포에 관한 보다 자세한 설명은 [ISTQB_FL_SYL]
을 참조하면 된다. 비록 도구 자체의 구매 가격이 저렴（또는 무료）하다 해도 조직은 그 도구를 구 
현하고 사용하기 위해 상당한 리소스를 투자해야 한다. 저렴한 도구를 포함한 모든 도구의 구매 
를 위해서는 적절한 평가 절차를 따라야 할 필요가 있다.
도구의 사용 용이성도 평가되어야 한다. 모바일 테스팅 도구가 시장에 많아짐에 따라 사용성은 
더욱 개선될 것이다. 도구가 장차 크게 개선된 인터페이스를 가질 것으로 예상하는 경우, 해당 도 
구의 다음 버전을 기다리는 것도 합당하다고 볼 수 있다. 모든 도구를 선정할 때와 마찬가지로 도구를

사용할 테스터가 가지고 있는 기술을 상기해서 테스터가 접근하기 용이한 방법으로 필요한 기능을

제공하는지를 검증해야 한다.

4.1.2 일반적인 도구들
모바일 어플리케이션을 테스트할 때도 대중적으로 사용되는 일반적인 도구들은 여전히 유용하다.
예를 들어, 테스트 관리 도구, 결함 관리 도구, 요구사항 관리 도구 등은 여전히 필요하다. 빌드 
도구, 지속적인 통합/배포 및 단위 테스팅 도구 등도 개발 프로세스 지원을 위해 여전히 필요하다.
또한, 많은 모바일 어플리케이션은 백엔드 컴포넌트를 가지고 있기 때문에 어플리케이션 서버, 웹 
서버, 데이터베이스 서버에서 실행되는 SW를 테스트하는 데 사용되는 도구도 여전히 필요하다.
즉, 백그라운드 또는 지원 SW는 클라이언트 어플리케이션이나 웹 어플리케이션에서 테스트되는 
방식과 동일한 방식으로 모바일 어플리케이션에서도 테스트될 것이다.

4.1.3 상용 도구 또는 오픈 소스 도구
상용 도구는 어떤 기업이 이익을 위해 만든 것이다. 이러한 상용 도구를 좀 더 신뢰할 수 있다고 
생각하는 사람도 있지만, 그런 상용 도구는 시장의 요구에 뒤처지는 경향이 있다. 오픈 소스 도구 
는 흥미를 가진 개인이나 커뮤니티에 의해 특정한 수요에 대응하기 위해 만들어진 것이다. 오픈 
소스 도구는 특정 문제의 해결에 집중하는 경향이 있고, 상용 도구는 다양한 기능을 다루기 위해 
디자인된다. 모바일 어플리케이션 테스팅 분야에서는 여러 영역에 초점을 맞춘 다양한 기능을 가 
진 오픈 소스 도구를 쉽게 구할 수 있다. 상용 도구 역시 이용할 수 있지만 새로운 기능과 기술 
을 추가하는 데 있어서 뒤처지는 경향을 갖는다. 어떤 유형의 도구를 선택하기 전에 업무에 가장 
적합한 도구라는 것을 확실히 하기 위해서는 상당한 주의가 필요하다. 도구 지원, 유지 보수, 산 
업과 함께 성장할 가능성과 역량, 비용과 사용성 등에 대해 고려하는 것이 중요하다.

 

4.2 환경과 프로토콜
4.2.1 환경 고려사항
모바일 어플리케이션은 다양한 환경에서 동작할 것으로 기대된다. 이러한 환경은 각각 고유한 특 
징을 가질 수 있다. 테스트 환경을 선택하고 구성할 때 최소한 다음 사항들을 고려해야 한다.
4.2.1.1 접속성
디바이스는 Wi-Fi 혹은 이동 통신 네트워크에 접속할 수 있으며, 블루투스 기술이나 다양한 다른 
수단을 통해 서로 소통할 수도 있다. 접속성을 테스트할 때는 접속 불량, 재접속 역량, 전송 중 
데이터 손실 등의 상황에서 어플리케이션이 계속 작동할 수 있는 역량과 더불어 접속 차단도 테 
스트해야 한다. 디바이스가 데이터 손실 없이, 또 사용자에게 영향을 주지 않고 접속된 네트워크 
간에 전환할 수 있는지도 검증해야 한다. 예를 들어, 디바이스는 Wi-Fi에서 이동 통신망으로 전환 
하거나 느린 3G 네트워크에서 더 빠른 네트워크로 전환할 수 있다. 디바이스는 이동하기 때문에 
이용 가능한 최고의 접속 방법을 선택해야 한다. 다양한 접속 변수를 테스트하기 위해서는 상당 
한 네트워크 자원과 구성 역량이 필요하다.
4.2.1.2 메모리
디바이스 메모리는 매우 다양하다. 태블릿, 스마트폰 및 기타 디바이스는 다양한 메모리 옵션을 
가지고 출시된다. 일반적으로 새로운 디바이스는 낮은 메모리 용량으로 시장에 진입하여 새로운 
모델이 출시 될 때 용량을 증가시킨다. 시중에 나온 디바이스 중 일부는 메모리를 추가할 수 있 
는 특징을 가지고 있다. 만약 어떤 어플리케이션이 기존 디바이스의 메모리 용량으로 구동될 경 
우, 해당 어플리케이션이 더 큰 용량을 가진 해당 디바이스의 차후 버전에도 적합할 것이라고 가 
정할 수 있다. 물론 새로운 디바이스에는 메모리를 경쟁적으로 사용하는 새로운 기능이나 주변기 
기가 있겠지만, 그런 현상은 항상 일어나고 있는 메모리 경쟁과 유사하다고 볼 수 있다.
효율적인 메모리 사용（효율성 테스팅）과 메모리 부족을 처리할 수 있는 역량에 대한 테스팅（결점 
허용성）은 다수의 프로세스가 공유된 환경을 사용하는 모바일 어플리케이션에서 매우 중요하다.
할당된 메모리가 반환되지 않아서 발생하는 메모리 누수나 메모리 손상이 발생하지 않도록 반드 
시 메모리 관리를 모니터링해야 한다.

 

4.2.1.3 성능
테스트 환경의 성능은 타당한 테스트 결과를 생성하기 위해 중요한 고려사항이다. 테스트 환경 
성능은 통신 방해, 재접속 및 네트워크 트래픽 등의 생산 환경에 대한 성능의 축소판이라 할 수 
있다. 통신은 모바일 어플리케이션의 성능에 영향을 주는 핵심적인 변수이므로, 테스트 환경은 실 
제 사용 환경에서 발생할 수 있는 약한 접속, 타임아웃 에러(Timeout error) 등과 같은 변수를 주 
입하고 제어할 수 있는 역량을 포함한 실질적인 통신 인터페이스를 제공해야 한다.
4.2.1.4 디바이스 역량 및 특성
디바이스의 역량과 특징은 매우 다양하다. 어플리케이션 테스팅에서 디바이스의 모든 역량을 다 
룰 필요는 없지만, 디바이스의 사양이 어플리케이션과 어떻게 상호작용하거나 영향을 미치는지 
이해하는 것은 중요하다. 예를 들어, 어플리케이션이 어플리케이션 인터페이스를 올바르게 표시하 
기 위한 디바이스의 방향성 판단을 위해 가속도계와 자이로스코프를 사용할 필요가 있는 경우 테 
스팅에는 해당 사양의 다양한 버전을 가진 디바이스(어떤 버전의 경우 인터페이스가 다를 수도 
있는), 해당 사양이 없거나 해당 사양이 정상 작동하지 않는 디바이스 등을 포함해야 한다. 어플 
리케이션이 사용하는 디바이스의 사양이 많을수록, 테스팅 범위에 포함해야 하는 디바이스는 더 
많아진다.
어플리케이션에 대한 적절한 테스트 환경을 결정할 때 아래와 같은 사양과 역량 요소를 고려해야 
한다:
• 디스플레이 화면 크기
• 화면 밝기
• 위치 정보
• 전화 통신
• 가속도계
• 자이로스코프
• 자력계
또한, 디바이스가 어플리케이션을 OTA(over-the-air) 방식으로 설치할 수 있는지 여부도 디바이스 
에 배포 및 업데이트를 설치하는 방법을 결정할 때 반드시 고려해야 한다. OTA 기능을 사용할 경 
우 다운로드 가능 크기가 제한될 수 있으며, 설치 과정이 중단된 경우, 다운로드 일부만 받은 경 
우 또 업데이트가 누락된 경우 등에 대한 강력한 복구 기능을 가져야 한다. 업데이트가 디바이스 
작동에 부정적인 영향을 미치거나 데이터 손실을 발생시켜서는 안 된다.
기법에 관한 부문에서 언급한 바와 같이 페어와이즈 테스팅과 같은 다중 테스팅 기법은 상호작용 
하지 않는 역량과 기능의 대표 조합들을 결정함으로써 테스트 환경의 잠재적 총 개수를 줄이는

데 도움을 줄 수 있다. 결정 테이블은 상호작용하는 역량과 기능의 조합을 결정하는 데 사용될 
수 있다.

4.2.1.5 데이터 처리
고려해야 할 또 다른 환경적 요소는 모바일 어플리케이션에 의해 사용되는 데이터이다. 일반적으 
로 모바일 어플리케이션에 사용되는 데이터는 다음 네 가지 원천 중 하나로부터 올 수 있다:
• 백엔드 시스템 （예: 데이터베이스 서버）
• 디바이스 자체 （예: GPS 위치）
• 사용자 （어떤 입력을 통해. 예: 텍스트, 선택, UI 상호작용）
• 연결된 다른 디바이스 （예: 니SB 를 통해 연결된 PC）
모바일 어플리케이션 테스팅에서는 데이터 수신, 데이터 전송, 그리고 디바이스에 데이터 저장하 
기 등을 고려해야 한다. 데이터는 반드시 적절한 수준의 보안성과 신뢰성을 갖추어 처리해야 한 
다. 데이터를 디바이스에 저장할 때는 데이터의 안전을 보장하고 무단사용으로부터 데이터를 보 
호하기 위한 주의가 필요하다.
4.2.1.6 디바이스 위치
모바일 어플리케이션 테스트에서 테스터는 실제 디바이스나 시물레이션된 디바이스가 사용 가능 
한지 고려해야 한다. 모바일 어플리케이션 테스팅은 흔히 다수의 디바이스에 걸친 테스트를 요구 
하기 때문에, 이들 디바이스가 사용 가능한지를 테스트 계획 단계에서 결정해야 한다. 다수의 디 
바이스를 이용하는 방법은 여러 가지가 있다. 경우에 따라서는 다양한 디바이스에 각 디바이스당 
여러 테스터들이 참여할 수도 있다. 다음 목록은 테스트 목적으로 다수의 디바이스를 얻기 위해 
사용하는 몇 가지 대표적인 방법이다:
• 테스터와 같은
• 오픈 디바이스
• 크라우드 소싱
• 원격 디바이스
• 가상 환경 （예: 시뮬레이터, 에뮬레이터, 클라우드 기반）
장소에 있는 실제 디바이스
랩 [Open Device Lab]
랩 （예: 공급 업체 또는 외부 조직에서）
다수의 디바이스를 마련하고, 그 세트를 새로운 모델과 버전에 맞추어 최신 상태로 유지하려면 
엄청난 비용이 들 수 있다. 그러므로 도구 판매 업체가 제공하는 원격 테스트 환경이나 가상 환 
경을 사용하는 것이 좀 더 현실적인 접근법이다.

 

4.2.2 프로토를
서로 다른 디바이스는 서로 다른 통신 프로토콜을 이용할 수 있다. 테스트 도구 특히, 로드 테스 
팅 도구는 모든 프로토콜을 지원하지 않을 수 있다. 테스터는 테스트 대상 디바이스가 사용하는 
프로토콜을 이해하고 테스트에 사용할 도구와 호환되지 않는 경우 등의 이슈를 사전에 방지해야 
한다. 시뮬레이터를 사용하는 경우, 시뮬레이터는 디바이스의 프로토콜 사용을 모의 실행할 수 있 
어야 한다.

 

4.3 특정 어플리케이션 기반 환경 고려사항
4.3.1 브라우저 기반 어플리케이션
브라우저 기반 모 바일 어플리케이션은 디바이스에서 작동되는 일련의 브라우저에서 작동하도록 
설계된다. 이 중 일부는 사용자에게 어플리케이션을 모바일 버전으로 전환하거나 표준 웹 버전에 
머무를 선택권을 제공한다. 브라우저 기반 어플리케이션의 장점 중 하나는 내장된 이식성이다. 브 
라우저를 실행할 수 있는 모든 디바이스는 이 어플리케이션을 실행할 수 있다. 그러므로 이론적 
으로는 모든 종류의 디바이스가 지원하는 브라우저 상에서의 테스팅으로 테스팅 요구사항을 제한 
한다.
그러나 브라우저 기반 어플리케이션이 동시에 모바일 어플리케이션으로 여겨질 때는 테스팅에 대 
해 따로 고려해야 하는 사항이 있다. 예를 들면, 특정 컴포넌트들, 자바 스크립트 그리고 케스케 
이딩 스타일 시트（CSS）를 다루는 방법에 있어서 서로 다른 브라우저와 버전들은 매우 큰 차이가 
있다. 일부 플러그인（예: Flash）은 모바일 디바이스에서 사용할 수 없다.
4.3.1.1 사용성과 성능에 대한 고려 사항
이런 어플리케이션은 모바일 디바이스에 최적화되어 있지 않을 수 있기 때문에 사용성과 성능에

대한 문제가 있을 수 있다. 특히, 글자 크기, 네비게이션 및 스크린 레이아웃은 스마트폰에 
서 볼 때 사용자 친화적이지 않을 수 있다. 많은 경우 이러한 어플리케이션이 "모바일" 버전으로 
전환할 수 있는 옵션을 가지고 있지만, 그 옵션은 매우 작은 글꼴로 화면의 일부만 보고있는 사 
용자에게 인식되지 않을 수 있다.
성능 역시 모바일 환경을 위해 설계되지 않은 어플리케이션에서 문제가 될 수 있다. 성능 테스팅 
섹션에서 논의한 것처럼 테스터는 여전히 성능에 대해 테스트할 필요가 있지만, 신뢰성과 성능에 
영향을 줄 수 있는 접속성 이슈도 살펴보아야 한다.

4.3.1.2 브라우저 버전 지원
모든 웹 어플리케이션의 경우와 같이 어플리케이션은 지원되는 브라우저 버전에 대해 테스트되어 
야 한다. 어플리케이션이 모바일 영역에 배포될 예정인 경우 추가 브라우저 버전이 필요할 수 있 
으며, 더 중요한 점은 특정 브라우저의 사용 빈도가 전통적 기기와는 다를 수 있다는 점이다. 예 
를 들어, PC 환경에서 어떤 한 종류의 브라우저가 지배적일 수 있다면 모바일 디바이스에서는 다 
른 브라우저가 지배적일 수 있다. 이런 경우 테스트 우선순위는 더 자주 사용되는 브라우저 쪽으 
로 이동해야 한다.

 

4.3.2 네이티브 디바이스 어플리케이션
특정 디바이스를 위해 만들어진 어플리케이션의 경우 기능을 제공하기 위해 일반적으로 그 디바 
이스의 고유 사양과 역량 및 운영체제를 사용한다. 이 경우 해당 어플리케이션은 일반적으로 다 
른 환경에 이식할 수 없다. 네이티브 디바이스 어플리케이션을 개발하는 데에는 여러 이유가 있 
다. 디바이스 역량을 최대한 활용할 수 있을 뿐 아니라 개발자는 특정 시장에 보다 적합하게 사 
용자 인터페이스를 조정할 수 있다. 이러한 접근 방식은 브라우저를 실행할 수 없는 디바이스나 
인터넷 접속 없이 작동하는 디바이스에 대하여 적용된다.

4.3.2.1 좋은 시뮬레이터 또는 실제 디바이스
네이티브 디바이스 어플리케이션의 경우 시뮬레이터는 그 디바이스를 위해 특별히 설계되어야 한 
다. 시뮬레이터가 없는 경우 테스팅은 실제 디바이스에서 진행해야 한다. 그렇게 되면 당연히 디 
바이스를 구하기 어렵거나, 많은 디바이스에 대해 성능 테스팅이 필요한 경우 많은 비용이 들 수 
있다. 테스터는 실제 디바이스가 필요한 부분과 대중적인 일반 시뮬레이터로 테스트 가능한 것이 
무엇인지 이해하기 위해 개발자와 협력해야 한다.

4.3.2.2 도구 지원
도구 지원은 시장을 따른다. 대상 디바이스의 시장 인기도에 따라 지원되는 도구가 없거나 새로 
운 어플리케이션을 테스트하기 위해 필요한 만큼 빠르게 도구를 구하지 못할 수 있다. 일반적으 
로, 도구는 iOS, 안드로이드, 윈도우 등과 같은 시장의 큰손들을 위해 처음 개발된다. 새로운 디바 
이스의 경우 시뮬레이터를 만들거나 성능 테스트를 수행하거나 테스트 자동화를 지원하기 위해 
필요한 도구 지원을 받지 못할 수 있다.

4.3.3 하이브리드 어플리케이션
하이브리드 어플리케이션은 플러그인을 통해 디바이스의 특정 사양（기능） 및 역량을 사용할 수 있 
다. 디바이스 호환성은 어플리케이션을 개발하는 데 사용된 프레임워크에 의존하고 그 프레임워 
크에 결함이 존재할 수 있기 때문에 여러 디바이스에 걸쳐 테스팅을 수행해야 한다. 일반적으로 
네이티브 어플리케이션과 브라우저 기반 어플리케이션에 대해 필요한 모든 테스트가 하이브리드 
어플리케이션에 대해서도 필요하다.

 

4.4 실제 디바이스, 시물레이터, 에물레이터 및 클라우드
테스터는 개발자와 협력하여 가장 적합한 테스트 플랫폼을 결정해야 한다. 실제 디바이스일 수도 
있고, 디바이스 시뮬레이터이거나 에뮬레이터일 수도 있으며 또는 이 세 가지의 조합이 될 수도 
있다.

4.4.1 실제 디바이스
정의 그대로, 실제 디바이스가 가장 현실적이며 가장 정확한 테스트 환경을 제공한다. 실제 디바 
이스는 실제 사용 환경을 제공하며 테스터로 하여금 시뮬레이터에서는 놓칠 수 있는 모든 디바이 
스 고유 문제를 발견할 수 있게 해준다. 디바이스 간에는 수백 가지의 차이점이 있다. 디바이스 
는 또한 사용자 입력에 대한 일관성 없는 민감도（예: 화면의 가장자리에서 압력을 인식하지 못함） 
나 물리적 문제들（예: 신뢰할 수 없거나 일관적이지 않은 버튼）과 같은 자체적 결함을 가지고 있 
다. 시뮬레이터는 항상 실제 디바이스보다 시기적으로 뒤처지게 된다. 품질좋은 시물레 
이터를 개발하고 테스트하는 데는 시간이 걸리기 때문이다.
실제 디바이스는 가장 좋은 테스트 플랫폼이지만 확보하기 어려울 수 있다. 또한, 실제 디바이스 
에서 작동하는 테스트 자동화나 성능 테스팅은 만들기 어려울 수 있다. 일반적으로 사용성, 성능 
샘플링, 일반적인 기능 테스트 등을 실제 디바이스에서 수행하면서 복수의 플랫폼을 적절하게 조 
합하는 것이 가장 좋다. 실제 디바이스는 시뮬레이터가 "진짜" 응답을 제공하는지 확인하기 위해 
시물레이터와의 비교를 위해 자주 사용된다.
사용성 테스팅은 사용자 경험에 대한 적절하고 완전한 평가를 제공하기 위해 항상 실제 디바이스 
에서 수행해야만 한다. 디바이스 간의 차이는 사용성에 영향을 미칠 수 있으며, 같은 어플리케이 
션이라 하더라도 서로 다른 디바이스에서 상이한 수준의 사용성을 보여줄 수 있다.
어플리케이션과 대상 플랫폼에 따라 대상과 유사한 역량을 가진 디바이스를 가지고 테스트를 수 
행하는 것이 가능한 경우도 있다. 새로운 운영체제 버전이 이용 가능하거나 새로운 디바이스에서 
새로운 기능이 이용 가능하지만 어플리케이션에 의해 영향을 받지 않을 경우에 종종 이루어진다.

4.4.2 시뮬레이터
시뮬레이터는 디바이스의 일부 측면을 모의 실행하는 프로그램이다. 하드웨어 자체를 모방하지는 
않으며 디바이스의 모든 응답 및 활동을 모의 실행하지는 않을 수 있다. 디바이스와 동일한 운영 
체제상에서 작동하지 않는다.

 

개발자의 어플리케이션 테스트를 돕기 위해 디바이스 제조 업체가 시물레이터를 제공하는 경우도 
있다. 다수의 어플리케이션을 가진 디바이스가 더 인기 있을 가능성이 높기 때문에 제조사는 좋 
은 시뮬레이터를 제공하는 것에 많은 관심을 기울이게 된다. 하지만 시뮬레이터가 반드시 좋거나 
신뢰할 수 있는 것은 아니며 실제 디바이스를 제대로 반영하지 못할 수도 있다.

4.4.2.1 구매 또는 구축
신뢰할 수 있는 시뮬레이터가 없는 경우 개발 조직은 직접 시뮬레이터를 개발할 수 있다. 이 경 
우 개발 조직은 어플리케이션 개발 및 테스트에 정확히 필요한 것을 제작할 수 있다. 시뮬레이터 
는 반드시 테스트되어야 한다. 시뮬레이터 구축（개발）은 그 자체로 하나의 개발 프로젝트로서 분 
석, 설계, 아키텍처, 개발, 테스팅 그리고 당연히 문서화 작업도 필요하다. 시뮬레이터는 또한 실제 
디바이스에 일어난 변화에 맞추어 항상 최신의 상태에 있어야 하며 그렇지 않으면 그 시뮬레이터 
를 활용한 테스팅은 무용지물이 될 것이다.

4.4.2.2 시뮬레이터 신뢰성 검증
시뮬레이터에 의존하기 전에 시뮬레이터가 입력에 대해 정확한 응답을 제공하는지 확인하는 것이 
중요하다. 이러한 작업은 실제 디바이스와 시뮬레이터에 동일한 입력을 제공하고 산출되는 결과 
가 동일한지 검증함으로써 이루어진다. 만약 다르다면 그 시뮬레이터는 신뢰할 수 없다. 이는 성 
능뿐만 아니라 기능에 대해서도 마찬가지다. 기능적으로 정확하지만 느린 시뮬레이터（또는 빠른 
시뮬레이터）는 기능 테스팅에 여전히 사용 가능하지만 응답 시간의 차이가 어플리케이션에 영향 
을 주지 않음을 보장하기 위해 실제 디바이스에서의 더 많은 추가적 테스팅이 필요할 것이다.

4.4.2.3 성능 및 부하 테스팅을 위한 시뮬레이터 사용
시뮬레이터는 통상적으로 부하 생성과 성능 평가에 사용된다. 시뮬레이터는 하드웨어이기보 
다는 SW이기 때문에 추가적인 비용 없이 많은 수의 시뮬레이터가 만들어지고 실행될 수 있다.
다른 성능 테스트와 마찬가지로 테스터는 정확한 부하와 성능 보고서를 만들기 위해 각각의 시물 
레이터 활동이 각각의 실제 디바이스 예상 활동과 동일함을 확신할 수 있어야 한다.

4.4.3 에뮬레이터
에뮬레이터는 SW, 하드웨어 및 운영체제를 포함하는 디바이스 자체의 기능성을 제공하기 위해 
사용된다. 이는 카메라나 특수 화면 제어와 같은 다양한 디바이스 구성요소를 사용하는 특정 어 
플리케이션을 위해 필요하다 . 에뮬레이터는 일반적으로 디바이스 제조업체에 의해 만들어지지만 

일부는 다른 출처를 가지기도 한다. 실제 디바이스의 내부를 모른 채 에뮬레이터가 올바르게 작 
동하는지 테스트하기는 어렵다. 에뮬레이터를 사용하려면 테스터는 그것이 믿을 수 있는 출처를 
가진 것인지, 철저히 테스트된 것인지를 확인해야 한다. 실제 디바이스 응답에 대비하여 시험적 
응답을 확인하는 것도 좋은 생각이며 사용 중인 에뮬레이터의 버전이 대상 디바이스에 상응하는 
지 확인하는 데 도움을 줄 것이다.

4.4.4 클라우드
모바일 어플리케이션 테스팅을 위한 많은 클라우드 대안들이 존재하며, 이들은 다음과 같다:

 

• 클라우드 호스티드 어플라이언스 - 어플라이언스나 디바이스는 클라우드 상에 존재하며 
수동 또는 자동화된 테스트를 통해 접근 가능하다. 따라서 다양한 유형의 디바이스에 
대한 접근이 가능하다. 이 디바이스들은 기능 테스트뿐만 아니라 성능 및 사용성 
테스트에 사용될 수 있다
• 클라우드 호스티드 에이전트 - 전세계 각지의 사용자를 모의 실행하는 SW 가 
클라우드에서 실행될 수 있다. 이로 인해 조직은 여러 유형의 네트워크에서 수많은
모바일 디바이스 사용자가 어플리케이션을 사용할 때 백-엔드에서 무슨 일이 일어나는지 
확인할 수 있게 된다. 경우에 따라 클라우드 상에서 디바이스 시뮬레이터로 처리하기도 
하고, 클라우드 상에서 실제 디바이스로 처리하기도 한다
• 클라우드 네트워크 시뮬레이터 - 클라우드에서 테스트를 수행할 때, 네트워크 
시뮬레이터는 다양한 네트워크 구성, 속도 및 에러 조건을 모의 실행하는데 사용할 수 
있다. 그렇기 때문에 다양한 네트워크 유형들로 실제와 흡사한 테스트 환경을 구축할 수 
있게 된다
• 클라우드 프로토콜 시뮬레이터 - 디바이스는 서로 다른 프로토콜을 통해 통신할 수 있기 
때문에 프로토콜 시뮬레이터는 이러한 프로토콜을 모의 실행하기 위해 사용한다. 조직은 
다양한 프로토콜에서 그들의 어플리케이션을 테스트하거나 여러 프로토콜에 걸쳐 성능 
테스트를 수행할 수 있게 된다
테스팅을 위한 모든 클라우드 솔루션은 클라우드 환경의 신뢰성, 환경의 현실성（이는 종종 설정 
가능한 범위에 의해 결정된다）과 접근성을 고려해야 한다. 또한, 클라우드 환경에서 테스트하는 
경우 보안에 대해 신경써야하며 특히, 새롭고 혁신적인 어플리케이션 및 디바이스에 대하여서는 
더욱 그렇다.

 

4.5 성능 테스트 도구와 지원
마치 모바일 디바이스가 순식간에 시장에 폭발적으로 퍼지게 된 것처럼, 그들에 대한 테스팅 특 
히, 성능 테스팅을 지원하는 도구 역시 폭발적으로 증가하였다. 클라우드 솔루션은 수많은 디바이 
스, 네트워크 및 프로토콜에 대한 접근을 허용하는데, 그 결과 다양한 클라우드 기반 디바이스나 
디바이스 시뮬레이터를 사용해서 시스템 로드를 발생시킬 수 있게 되었다. 그러나 좋은 도구가 
반드시 효과적인 성능 테스팅을 가져오지는 않는다. 3.3.1 절에서 설명한 바와 같이, 성능 테스팅 
은 반드시 관련된 중요한 운영 프로파일과 시스템이 겪게 될 예상 로드를 고려해서 실행해야 한 
다.
성능 테스트 도구를 선택할 때, 테스터는 다음 사항을 만들고 추적할 수 있는 도구의 역량을 고 
려해야 한다:

• 서버와 디바이스 사이에 오가는 다음과 같은 정보
• 트랜잭션 데이터
• GPS 정보
• 이미지
• 양과 빈도
• 접속/끊김 패턴
• 활동량 폭발
• 사용 패턴
• 일/주 동안의 시간에 따른 변동
• 개인용 대 업무용 기기 사용
• 피크 사용 시간 （예: 일별, 분기별）

성능 테스팅 활동의 성공을 위해 이러한 정보를 제어하고 모니터링하는 도구의 역량은 매우 중요 
하다. 잘못된 도구를 활용한 테스팅은 시간 낭비이거나 더 심각하게는 잘못된 결과를 일으킬 수 
있다.
성능 테스트에 사용할 수 있는 좋은 상업적인 도구는 많다. 전통적인 도구 중 일부는 모바일 
디바이스에 대한 지원을 추가하고 있다. 모바일을 대상으로 하는 새로운 성능 테스트 도구도 
계속해서 시장에 진입하고 있다. 도구를 선택할 때는 현재뿐만 아니라 미래에 필요한 기능을 
평가해야 한다. 성공을 예상하고 계획을 잡는 것이 좋으며, 어플리케이션의 사용자 기반이 기존 
전통 SW 의 경우보다 훨씬 더 빠르고 극적으로 성장할 것이라고 가정하는 것이 좋다.

 

4.6 테스트 자동화
모바일 어플리케이션 테스팅에서 테스트 자동화는 선택이 아닌 필수 조건이다. 더 많은 도구가 
시장에 합류하면서 테스트 자동화는 잘 설계되고 계획되었을 경우에만 실현 및 유지보수가 가능 
해진다. 모바일 어플리케이션 테스트 자동화 프로젝트는 다음 사항을 고려해야 한다:
• 실제 사용 패턴에 기반을 두고 테스트
• 사용자와 디바이스 간의 상호작용을 이해하고 그것을 테스트
• 디바이스와 서버 사이의 상호작용을 이해하고 그것을 테스트
• 데이터 주도 또는 키워드 주도 접근법을 적용하여 테스트 자동화 스크립트에서 데이터를 
분리
• 실제 기기 제어 기능
• 유지보수를 위한 개발
• 테스트 케이스의 버전을 관리하고 이전 버전의 테스트 자동화를 활용해 유지보수 및 
릴리스 프로세스를 검증

테스트 자동화는 모바일 어플리케이션 테스팅에 매우 중요하며 좋은 계획, 견고한 설계 그리고 
조심스런 구현이 필요하다. 테스트 자동화 코드를 설계할 때부터 유지보수를 고려해야 하며 데이 
터 분리와 같은 좋은 습관은 유지보수성을 보장하는 데 도움을 준다. 모바일 어플리케이션은 매 
우 빠르게 변화하기 때문에 유지보수성은 전통적 어플리케이션에 대해서보다 모바일 어플리케이 
션 테스트 자동화에 있어서 더 높은 우선순위를 가진다. 테스트 자동화는 테스팅하는 SW 만큼이 
나 가치 있는 것이다. 버전 제어, 좋은 코딩 습관, 그리고 품질 요구사항은 테스트 자동화 코드에 
적용된다. 이상적인 케이스는 테스트 자동화를 어플리케이션과 동시에 개발하여 지속적으로 통합 
되고 배포될 수 있는 어플리케이션에 대한 자동화 테스팅을 가능하게 하는 것이다.
실제 디바이스에서의 테스트 자동화는 어렵다. 시뮬레이터（또는 에뮬레이터）에서의 테스트 자동화 
가 보다 일반적인 접근 방식이며, 따라서 시뮬레이터는 자동화된 테스트와 정보 전달을 가능하게 
해주는 적절한 인터페이스를 제공하도록 제작해야 한다. 시뮬레이터는 누를 수 있는 버튼이나 터 
치할 수 있는 화면이 없으므로 자동화된 테스트가 실제 기기를 다루는 사용자와 같은 결과를 얻 
을 수 있는 명령을 전달할 수 있도록 해주어야 한다. 실제 디바이스에 자동화된 테스트를 실행해 
주는 도구가 시장에 나와 있지만, 작은 개발 조직을 위해서는 비용이 문제가 될 수 있어 시물레 
이터 사용이 보다 실용적인 솔루션이 될 수 있다.

 

4.6.1 도구 지원
성능 테스트 도구와 마찬가지로 모바일 어플리케이션 테스트 자동화 도구 역시 시장에 빠르게 진 
입하고 있다. 주의 깊은 도구 평가가 필요하지만, 새로운 시장에 느리게 적응해가는 기존 테스트 
자동화 도구보다는 모바일 어플리케이션을 위해 더 정교하게 조정된 역량을 가진 새로운 도구를 
찾는 것이 타당하다. 모바일 디바이스와 그들의 어플리케이션은 계속 빠르게 진화할 것이기 때문 
에, 모든 테스트 자동화 도구들도 이에 맞출 수 있어야 한다. 테스트 자동화는 중요한 투자이며 
잘못된 도구의 구입은 적지않은 비용 손실이 될 수 있다.

4.6.1.1 환경 선택
적절한 도구 선택과 적절한 환경의 선택은 서로 밀접한 관련이 있다. 테스트 자동화는 반드시 특 
정 환경을 대상으로 해야 하며, 그러한 환경에는 아래와 같은 것들이 포함될 수 있다:

• 실제 디바이스
• 시물레이션된 디바이스
• 클라우드 호스티드 디바이스나 사용자 에이전트
• 상기 기술된 것들의 임의 조합

대상 환경에 집중한 테스트 자동화는 도구 선택 프로세스에 도움이 되며, 테스팅 환경이 확장되 
어도 도구가 테스팅을 지속적으로 지원하는 데 도움이 될 것이다. 클라우드 솔루션이 현재 조직 
에 적합하지 않을지라도 차후에는 필요해질 수 있다. 테스트 자동화는 수년간 지속될 수 있도록 
설계해야 하므로, 이러한 유형의 환경 변화는 초기부터 세심히 고려해야 한다.

4.6.1.2 조정을 위한 지원
도구가 다양한 디바이스 및 시물레이터로부터의 트랜잭션 송•수신을 지원해야 하는 경우가 있다.
특히 서버 테스트의 경우, 도구는 테스트 자동화 실행 중 시스템에서 어떤 일이 벌어지고 있는지 
이해할 수 있도록 이러한 정보를 상호 관련시킬 수 있어야 한다. 이러한 조정은 아래와 같은 것 
을 포함할 수 있다:

• 트랜잭션 수
• 트랜잭션 타이밍
• 트랜잭션 유형
• 요약된 보고

이러한 조정을 관리할 수 없는 도구는 테스트팀이 테스트 준비 및 결과 분석에 필요한 수작업에 
상당한 시간을 허비하게 할 수 있다.

 

4.6.2 필요 기술
여느 테스트 자동화 프로젝트에서와 마찬가지로, 높은 품질의 유지 가능한 테스트 스크립트를 개 
발하기 위해서는 프로그래밍과 스크립트 작성 기술이 요구된다. 모바일 어플리케이션은 업그레이 
드되기 전에 제품으로써 단명할 것이고 그렇기 때문에 테스트 자동화 코드도 단명할 것이라고 오 
해하기 쉽다. 좋은 테스트 자동화는 제품과 함께 성장할 수 있고 새로운 기능이 도입되었을 때 
기존 기능에 대한 좋은 리그레션 테스팅을 제공할 수 있다. 이를 위해서 테스트 자동화 아키텍처 
는 지속되고 성장할 수 있도록 견고하게 만들어져야 한다.
모바일 어플리케이션 분야에서 역량 세트는 계속 증가할 것이다. 자동화는 안정적이지 않을 것이 
다. 즉 디바이스와 어플리케이션의 새로운 기능을 수용하기 위해 지속적으로 확장될 것이다. 도 
구는 디바이스 개발보다 뒤처질 수 있다.
도구 역량과 디바이스 역량 간의 격차를 메우기 위해 프로그래밍이나 스크립트 작성이 필요할 것 
이라고 예상하는 것이 합리적이다. 이러한 격차를 코딩으로 해결하기 전에 테스터는 신뢰할 수 
있는 도구가 있는지를 확인해야 한다. 도구는 매우 빠르게 개발되고 배포되기 때문에 지속적인 
조사는 불필요한 노력 방지를 위해 꼭 필요하다.