페이퍼요약 - 모바일 소프트웨어 테스팅을 위한 자동 테스트 케이스 설계 전략 by Selvam

제목: 모바일 소프트웨어 테스팅 – 자동 테스트 케이스 설계 전략(Mobile Software Testing – Automated Test Case Design Strategies)

저자: Selvam R 외 1인, 인도

문서유형: 저널 페이퍼(총 12페이지), 2011년

 

다양한 플랫폼에서 모바일 애플리케이션의 단위 테스팅을 위한 자동 테스트 케이스 작성 예를 제시한 자료(JUnit과 Silverlight 단위 테스트 프레임워크 활용)

---

모바일 애플리케이션(Mobile applications)

• PDA, 휴대폰 같은 작고 가용 전력이 제한된 휴대용 기기를 위해 개발된 애플리케이션
• 제조 시 디바이스에 사전 설치되거나 웹 모바일 App 스토어(또는 기타 모바일 소프트웨어 배포 플랫폼)를 통해 다운로드 할 수 있다.
• 디바이스의 하드웨어 용량에 완전히 의존하는 독립형 애플리케이션(예, 소프트웨어 게임, 달력, 주소록)과 디바이스는 사용자와 인터페이스 하는 플랫폼 역할만 하고 실제 동작은 원격 서버에서 이루어지는 애플리케이션(예, 모바일 TV, 이메일, 모바일 브라우저 기반 애플리케이션)이 있다.
• 전형적인 모바일 시스템은 모바일 디바이스, 유선 및 무선 연결(wired and wireless connectivity), 백엔드 서버(backend server), 기반 네트워크 인프라구조를 포함한다.

[모바일 웹 애플리케이션 아키텍쳐 예]

모바일 애플리케이션 테스팅의 어려운 점

1) 하드웨어 다양성과 복잡성(Hardware Diversity and Complexity)

• PC 환경에서는 대개 한 가지 CPU 플랫폼(x86 계열 마이크로프로세서)에서 애플리케이션을 테스트. PC 또는 Mac에 들어가는 하드웨어 장치(예, 디스크 드라이브, 그래픽 프로세서, 네트워크 어뎁터 등)도 대개 운영체제와 호환성이 충분히 테스트 되어 있어 문제가 생기는 경우가 적다. 디스플레이 형식도 선택 범위가 그다지 넓지 않으며 입력 기기(대개 키보드와 마우스)도 잘 알려져 익숙하게 사용된다.
• 반면 모바일 음성 및 데이터 서비스 업자들은 각기 고유의 형상(configurations)과 형식을 가진 광범위한 제품군의 핸드셋을 제공. 핸드셋의 프로세서, 속도와 메모리, 스크린 크기와 해상도, 방향(landscape, portrait) 등이 매우 다양한데, 이러한 차이점이 애플리케이션의 성능, 안전성, 사용성에 예상치 못한 영향을 미칠 수 있다.
• 오늘날 모바일 핸드셋은 PC보다 훨씬 많고 빠르게 변화하는 하드웨어 장치를 포함하고 있음(예, Wi-Fi와 Bluetooth 네트워크, FM 라디오, 카메라, GPS 수신기, 디스플레이를 portrait에서 landscape로 바꾸기 위해 디바이스 움직임을 감지하는 가속센서 등). 또한 많은 휴대 기기가 다수의 디지털 신호 프로세서(음성 통신 처리용, 애플리케이션 관련 오디오/비디오/이미지 처리용)와 다수의 입력 기기(예, 터치스크린, 키패드)에 의존함. 각기 다른 방식으로 상호작용하는 다양한 하드웨어 장치들의 조합, 그리고 이런 장치들과 운영체제와의 조합은 호환성(compatibility)과 성능 문제를 초래할 가능성이 높다.

2) 소프트웨어 플랫폼 다양성과 소프트웨어 복잡성(Software Platform Diversity and Software Complexity)

• PC의 경우 애플리케이션이 대부분의 사용자 PC에서 제대로 작동하는지 확인하기 위해 현재 가장 널리 사용되는 윈도우/매킨토시/리녹스 OS 버전을 테스트하면 되지만, 모바일 기기의 경우 그 범위가 훨씬 넓음(예, iPhone, Windows Mobile 7, Symbian, Android, RIM Blackberry OS, 노키아의 MeeGo 플랫폼 등). 즉, PC에 비하여 핸드셋 OS 시장은 훨씬 분할되어 있고 빠르게 변하고 있다. 이렇게 지속적으로 변화하는 OS에 적용 가능한 테스트 도구에 대한 테스터의 지식이 요구됨
• 모바일 OS 뿐만 아니라 네트워크, 프로토콜, 네트워크 공급업자가 사용하는 인프라구조의 주요 요소들이 계속 변화하고 있음. 또한 통신사업자들은 2-G에서 3-G나 LTE(Long Term Evolution)를 수반한 4-G로 네트워크를 지속적으로 업데이트
• 여러 계층의 모바일 소프트웨어도 복잡성을 가중시킴. 테스터는 핸드셋에 올라가는 다양한 애플리케이션들간의 상호작용 뿐만 아니라 애플리케이션과 컴포넌트(예, 카메라, 마이크로폰, 충전기, 블루투스, Wi-Fi, 라디오 등)간의 상호작용도 체크해야 함
• 모바일 기기 작동에 사용되는 여러 네트워크와 애플리케이션 간의 호환성도 확인 필요. 운영하는 통신 사업자에 따라 네트워크의 대역폭, 트래픽 터널링 방법, 데이터 송수신 방법, 웹 프록시 등이 제각각 다르며, 이러한 차이점이 모바일 애플리케이션의 안정성, 성능, 보안 등에 영향을 줄 수 있으므로 테스트가 요구됨
• 통신사업자 또는 핸드셋 제조업자의 인증을 받으려면 애플리케이션이 산업 표준(또는 특정 사업자 고유의 표준)을 준수하는지 테스트 해야 함
• 위와 같은 여러 테스트 요구사항들이 모바일 애플리케이션의 품질 보장에 소요되는 시간과 비용을 증가시킴

3) 에뮬레이터상의 모바일 애플리케이션 테스팅(Testing Mobile Application on Emulators)

• 모바일 애플리케이션을 실제 타겟 기기에서 테스팅하면 하드웨어, 소프트웨어, 네트워크의 여러 요인들간의 상호작용이 정확하고 신뢰성 있게 테스트 가능하지만, 테스팅 단계 중 실제 타겟 기기(물리적 시료)에서 테스트를 수행할 수 있는 경우는 많지 않다. 대신 디바이스 에뮬레이터(물리적 기기의 성능과 동작을 흉내 내는 소프트웨어)가 주로 사용됨
• 에뮬레이터 상에서의 테스트는 비용 효과적이고 광범위한 모바일 기기 제품군(예, 스크린 해상도가 각기 다른 기기들)을 취급하는데 유용하지만, 실제 기기의 모든 동작을 동일하게 흉내 낼 수는 없으며(예, 사진 및 비디오 촬영) 현실적인 시나리오의 성능 평가도 어렵다. 따라서 애플리케이션이 에뮬레이터상에서 완벽하게 동작한다고 해서 실제 기기에서도 마찬가지일거라는 보장을 할 수 없다.

자동화된 테스트 케이스 개발(Automated test case development)

단위 테스트 수행을 위해 개발된 자동 테스트 케이스의 플랫폼 별 예가 아래와 같다(플랫폼은 다르지만 대부분이 동일한 테스트 템플릿을 사용)

안드로이드 플랫폼의 자동화된 단위 테스트 케이스 개발

안드로이드에서는 아래 같은 Junit 테스트 프레임워크 기반의 테스트 케이스가 개발되었고 Eclipse IDE에서 테스트 되었다. 

package com.utest.helloandroid.test;   import com.utest.helloandroid.HelloAndroid; import android.test.ActivityInstrumentationTestCase2; import android.widget.TextView;   public class HelloAndroidTest extends ActivityInstrumentationTestCase2<HelloAndroid> { private HelloAndroid mActivity; // the activity under test private TextView mView; // the activity's TextView (the only view) private String resourceString;   public HelloAndroidTest() { super("com.utest.helloandroid", HelloAndroid.class); } @Override protected void setUp() throws Exception { super.setUp(); mActivity = this.getActivity(); mView = (TextView) mActivity.findViewById(com.example.helloandroid.R.id.textview); resourceString = mActivity.getString(com.example.helloandroid.R.string.hello); } public void testPreconditions() { assertNotNull(mView); } public void testText() { assertEquals(resourceString,(String)mView.getText()); } }

J2ME 플랫폼의 자동화된 단위 테스트 케이스 개발

J2ME 단위 테스팅의 자동 테스트 케이스 예가 아래와 같다(자바 개발자들이 주로 사용하는 테스트 프레임워크인 JUnit과 유사한 프레임워크인 J2MEUnit을 활용).

import j2meunit.framework.*; public class TestLoginWindow extends TestCase { public TestLoginWindow() { super("null"); } public TestLoginWindow(String s) { super(s); } protected void runTest() throws java.lang.Throwable { if(getTestMethodName().equals("testLoginWindow")) { testLogindWindow(); } public Test suite() { return new TestSuite(new TestLoginWindow().getClass(), new String[] {"testLoginWindow"}); } public void testLoginWindow(){ // test it // use assert(String, boolean) } } }

iPhone의 자동화된 단위 테스트 케이스 개발

*Test.h import <Foundation/Foundation.h> #import <SenTestingKit/SenTestingKit.h> @interface SUnitTest : SenTestCase { NSMutableArray* _array; } @end   *Test.m #import "SUnitTest.h" @implementation MyUnitTest - (void) setUp { _array = [[NSMutableArray arrayWithObjects:@"1", @"2", @"3", nil] retain]; } - (void) testSize { STAssertEquals(3, (int)[_array count], @"Size must be three."); } - (void) testIndex { STAssertEqualObjects(@"2", [_array objectAtIndex:1], @"Must retrieve object at index of 1."); } - (void) tearDown { [_array release]; } @end

Windows Phone 7 플랫폼의 자동화된 단위 테스트 케이스 개발

Windows phone 7의 테스트 케이스를 개발하기 위해 Silverlight Unit Test Framework를 Windows Phone 7에 맞게 약간 변경하여 사용(아래 두 개의 Silverlight 단위 테스트 프레임워크 DLL에 대한 참조를 추가함)

Microsoft.Silverlight.Testing.dll

Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight.dll

 

아래 코드는 폰의 스크린 상단에 있는 바인 SystemTray를 감추고(테스트 결과 스크린의 상단을 가리지 않게 하기 위해) 백버튼을 잡아채어 테스트 결과로부터 빠져 나오게 한다.

using Microsoft.Phone.Shell; using Microsoft.Silverlight.Testing; void MainPage_Loaded(object sender, RoutedEventArgs e) { SystemTray.IsVisible = false; var testPage = UnitTestSystem.CreateTestPage() as IMobileTestPage; BackKeyPress += (x, xe) => xe.Cancel = testPage.NavigateBack(); (Application.Current.RootVisual as PhoneApplicationFrame).Content = testPage; }   [TestClass] public class BasicTests : SilverlightTest { [TestMethod] public void AlwaysPass() { Assert.IsTrue(true, "method intended to always pass"); }   [TestMethod] [Description("This test always fails intentionally")] public void AlwaysFail() { Assert.IsFalse(true, "method intended to always fail"); } }