移动 App 应用测试方法与思路.docx
《移动 App 应用测试方法与思路.docx》由会员分享,可在线阅读,更多相关《移动 App 应用测试方法与思路.docx(9页珍藏版)》请在冰豆网上搜索。
移动App应用测试方法与思路
移动App应用测试方法与思路
分析三种主流的移动App类型,并给出和普通web测试不同的地方,给出测试的思路,并给出部分场景组合。
附:
安卓App测试常用adb命令和money命令
移动端测试还是PC端测试,业务测试其实都属于GUI测试的范畴,所以基本的测试思路,比如基于页面对象封装和基于业务流程封装的思想是相通的。
三种移动端产品类型介绍
移动端应用的测试其自身特点,和其他传统测试又有一些独特的测试方法与思路。
移动端应用又可以进一步细分为三大类:
∙
WebApp 指的是移动端的Web浏览器,其实和PC端的Web浏览器没有任何区别,只不过Web浏览器所依附的操作系统不再是Windows和Linux了,而是iOS和Android了。
WebApp采用的技术主要是,传统的HTML、JavaScript、CSS等Web技术栈,当然现在HTML5也得到了广泛的应用。
另外,WebApp所访问的页面内容都是放在服务器端的,本质上就是Web网页,所以天生就是跨平台的。
∙
∙
NativeApp 指的是移动端的原生应用,对于Android是apk,对于iOS就是ipa。
NativeApp是一种基于手机操作系统(iOS和Android),并使用原生程序编写运行的第三方应用程序。
NativeApp的开发,Android使用的语言通常是Java,iOS使用的语言是Objective-C。
通常来说,NativeApp可以提供比较好的用户体验以及性能,而且可以方便地操作手机本地资源。
∙
∙
HybridApp,是介于WebApp和NativeApp两者之间的一种App形式。
HybridApp利用了WebApp和NativeApp的优点,通过一个原生实现的NativeContainer展示HTML5的页面。
更通俗的讲法可以归结为,在原生移动应用中嵌入了Webview,然后通过该Webview来访问网页。
HybridApp具有维护更新简单,用户体验优异以及较好的跨平台特性,是目前主流的移动应用开发模式。
∙
三类不同移动应用的测试方法
根据它们的特性来总结出它们的测试方法。
∙
WebApp,显然其本质就是Web浏览器的测试,所有GUI自动化测试的方法和技术,比如数据驱动、页面对象模型、业务流程封装等,都适用于WebApp的测试。
如果Web页面是基于自适应网页设计(即符合ResponsiveWeb设计的规范),而且测试框架如果支持ResponsivePage,那么原则上之前开发的运行在PCWeb端的GUI自动化测试用例,不做任何修改就可以直接在移动端的浏览器上直接执行,当然运行的前提是你的移动端浏览器必须支持WebDriver。
其中,自适应网页设计(ResponsiveWebDesign)是指,同一个网页能够自动识别屏幕分辨率、并做出相应调整的网页设计技术。
∙
∙
NativeApp的测试,虽然不同的平台会使用不同的自动化测试方案,iOS一般采用XCUITestDriver,而Android一般采用UiAutomator2或者Espresso等,但是数据驱动、页面对象以及业务流程封装的思想依旧适用,完全可以把这些方法应用到测试用例设计中。
∙
∙
HybridApp的测试,情况会稍微复杂一点,对NativeContainer的测试,可能需要用到XCUITest或者UiAutomator2这样的原生测试框架,而对Container中HTML5的测试,基本和传统的网页测试没什么区别,所以原本基于GUI的测试思想和方法都能继续适用。
∙
唯一需要注意的是,NativeContainer和Webview分别属于两个不同的上下文(Context),NativeContainer默认的Context为“NATIVEAPP",而Webview默认的Context为“WEBVIEW_+被测进程名称”。
所以,当需要操作Webview中的网页元素时,需要先切换到Webview的Context下。
web测试和app测试的区别:
相同点:
WEB测试和App测试从流程上来说,没有区别。
都需要经历测试计划方案,用例设计,测试执行,缺陷管理,测试报告等相关活动。
从技术上来说,WEB测试和APP测试其测试类型也基本相似,都需要进行功能测试、性能测试、安全性测试、GUI测试等测试类型。
不同点他们的主要区别在于具体测试的细节和方法有区别,
性能测试,在WEB测试只需要测试响应时间这个要素,在App测试中还需要考虑流量测试和耗电量测试。
兼容性测试:
在WEB端是兼容浏览器,在App端兼容的是手机设备。
而且相对应的兼容性测试工具也不相同,WEB因为是测试兼容浏览器,所以需要使用不同的浏览器进行兼容性测试(常见的是兼容IE6,IE8,chrome,firefox)如果是手机端,那么就需要兼容不同品牌,不同分辨率,不同android版本甚至不同操作系统的兼容。
(常见的兼容方式是兼容市场占用率前N位的手机即可),有时候也可以使用到兼容性测试工具,但WEB兼容性工具多用IETester等工具,而App兼容性测试会使用Testin这样的商业工具也可以做测试。
安装测试:
WEB测试基本上没有客户端层面的安装测试,但是App测试是存在客户端层面的安装测试,那么就具备相关的测试点。
App测试基于手机设备,还有一些手机设备的专项测试。
如交叉事件测试,操作类型测试,网络测试(弱网测试,网络切换)交叉事件测试:
就是在操作某个软件的时候,来电话、来短信,电量不足提示等外部事件。
操作类型测试:
如横屏测试,手势测试网络测试:
包含弱网和网络切换测试。
需要测试弱网所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交。
弱网络的模拟,据说可以用360wifi实现设置。
升级测试:
升级测试的提醒机制,升级取消是否会影响原有功能的使用,升级后用户数据是否被清除了。
从系统架构的层面,WEB测试只要更新了服务器端,客户端就会同步会更新。
而且客户端是可以保证每一个用户的客户端完全一致的。
但是APP端是不能够保证完全一致的,除非用户更新客户端。
如果是APP下修改了服务器端,意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
如此看来,移动端的测试除了使用的测试框架不同以外,测试设计本身和GUI测试有异曲同工之妙,对于移动端还应该有其他的不同测试思路和方法。
移动应用专项测试的思路和方法
对于移动应用,顺利完成全部业务功能测试往往是不够的,当移动应用被大量用户安装和使用时,就会暴露出很多之前完全没有预料到的问题,比如:
1.流量使用过多;
2.耗电量过大;
3.在某些设备终端上出现崩溃或者闪退的现象;
4.多个移动应用相互切换后,行为异常;
5.在某些设备终端上无法顺利安装或卸载;
6.弱网络环境下,无法正常使用;
7.Android环境下,经常出现ANR(ApplicationNotResponding);
…这样的问题还有很多,为了避免或减少此类情况的发生,所以移动应用除了进行常规的功能测试外,通常还会进行很多移动应用所特有的专项测试。
1.交叉事件测试
交叉事件测试也叫中断测试,是指App执行过程中,有其他事件或者应用中断当前应用执行的测试。
比如,App在前台运行过程中,突然有电话打进来,或者收到短信,再或者是系统闹钟等等情况。
所以,在App测试时,就需要把这些常见的中断情况考虑在内,并进行相关的测试。
此类测试目前基本还都是采用手工测试的方式,并且都是在真机上进行,不会使用模拟器。
首先,采用手工测试的原因是,此类测试往往场景多,而且很多事件很难通过自动化的方式来模拟,比如呼入电话、接收短信等,这些因素都会造成自动化测试的成本过高,得不偿失,所以工程实践中,交叉事件测试往往全是基于手工的测试。
其次,之所以采用真机,是因为很多问题只会在真机上才能重现,采用模拟器测试没有意义。
交叉事件测试,需要覆盖的场景主要包括:
1.多个App同时在后台运行,并交替切换至前台是否影响正常功能;
2.要求相同系统资源的多个App前后台交替切换是否影响正常功能,比如两个App都需要播放音乐,那么两者在交替切换的过程中,播放音乐功能是否正常;
3.App运行时接听电话;
4.App运行时接收信息;
5.App运行时提示系统升级;
6.App运行时发生系统闹钟事件;
7.App运行时进入低电量模式;
8.App运行时第三方安全软件弹出告警;
9.App运行时发生网络切换,比如,由Wifi切换到移动4G网络,或者从4G网络切换到3G网络等;
…其实你可以发现,这些需要覆盖的场景,也是我们今后测试的测试用例集,每一场景都是一个测试用例的集合。
第二,兼容性测试
兼容性测试顾名思义就是,要确保App在各种终端设备、各种操作系统本、各种屏幕分辨率、各种网络环境下,功能的正确性。
常见的App兼容性测试往往需要覆盖以下的测试场景:
1.不同操作系统的兼容性,包括主流的Andoird和iOS版本;
2.主流的设备分辨率下的兼容性;
3.主流移动终端机型的兼容性;
4.同一操作系统中,不同语言设置时的兼容性;
5.不同网络连接下的兼容性,比如Wifi、GPRS、EDGE、CDMA200等;
6.在单一设备上,与主流热门App的兼容性,比如微信、抖音、淘宝等;
…
兼容性测试通常都需要在各种真机上执行相同或者类似的测试用例,所以往往采用自动化测试的手段。
同时,由于需要覆盖大量的真实设备,除了大公司会基于Appium+SeleniumGrid+OpenST去搭建自己的移动设备私有云平台外,其他公司一般都会使用第三方的移动设备云测平台完成兼容性测试。
第三方的移动设备云测平台,国外最知名的是SauceLab,国内主流的是Testin。
第三,流量测试
由于App经常需要在移动互联网环境下运行,而移动互联网通常按照实际使用流量计费,所以如果你的App耗费的流量过多,第一会导致用户流量费用增加,第二会会导致功能加载缓慢。
流量测试,通常包含以下几个方面的内容:
1.App执行业务操作引起的流量;
2.App在后台运行时的消耗流量;
3.App安装完成后首次启动耗费的流量;
4.App安装包本身的大小;
5.App内购买或者升级需要的流量;
…
流量测试,往往借助于Android和iOS自带的工具进行流量统计,也可以利用tcpdump、Wireshark和Fiddler等网络分析工具。
对于Android系统,网络流量信息通常存储在/proc/net/dev目录下,也可以直接利用ADB工具获取实时的流量信息。
Android的轻量级性能监控小工具Emmagee,类似于Windows系统性能监视器,能够实时显示App运行过程中CPU、内存和流量等信息。
对于iOS系统,可以使用Xcode自带的性能分析工具集中的NetworkActivity,分析具体的流量使用情况。
但是,流量测试的最终目的,并不是得到App的流量数据,而是要想办法减少App产生的流量。
减少App消耗的流量不是测试工程师的工作,但了解一些常用的方法,也将有助于你的测试日常工作:
1.启用数据压缩,尤其是图片;
2.使用优化的数据格式,比如同样信息量的JSON文件就要比XML文件小;
3.遇到既需要加密又需要压缩的场景,一定是先压缩再加密;