移动设备App测试总结

本文是移动设备App测试的总结，好在工作中测试有个参考。

一、测试需要覆盖的方面

服务器接口测试

UI测试

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

客户端功能性测试

        功能方面目前市场上还没达到自动化的水平，主要用手工来测。出现问题最多的也就是特殊符号、边界值、按钮之类的。可以先创建一个checklist，避免漏测。

兼容性测试

        兼容性方面考虑手机的版本、型号、分辨率。不同的版本是存在差异的，一般低版本容易出现问题。

性能，适配，压测（自动化配合）

        性能方面比如如启动时间、各项操作的反应时间等，另外还有靠工具来实现的CPU占用、内存占用、电池温度等。

1)极限测试：在各种边界压力情况下（如电池、存储、网速等），验证App是否能正确响应。　　

2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求　　

3)压力测试：反复/长期操作下，系统资源是否占用异常；　　

4)性能评估：评估典型用户应用场景下，系统资源的使用情况。　　

5)Benchmark测试（基线测试）：与竞争产品的Benchmarking,产品演变对比测试等。　

6)针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法，如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。

7)app运行的内存消耗和cpu消耗，app后台长时间运行的耗流量，耗电量。

App安全性测试

1)软件权限　　

-扣费风险：包括发送短信、拨打电话、连接网络等　　

-隐私泄露风险：包括访问手机信息、访问联系人信息等　　　　

2)开发者官方权限列表信息比对分析       

3)入侵方面，下面是我的一点经验。
　　我的理解，包括以webview为主体的app，站在入侵或者攻击的角度来讲，安全隐患在于http抓包，逆向工程。谈这之前先讲讲webview相关的app，前一段时间有个曝工资的软件很火，但有查询次数的限制，抓包研究了一下，发现其主要还是webview，通过抓包详细分析，才明白他记录查询次数的手段，每一个用户都会分配一个id，以及一个代表查询次数count以cookie的形式保存到本地，通过维护cookie达到限制查询次数的目的，所以清除cookie就可以无限制的查询了，个人觉得，webview相关的app安全性测试应该还是web测试那一套，xss攻击，sql注入等（没搞过web安全测试，仅推测）。
　　大部分app还是走的http或者https，所以防http抓包泄露用户信息以及系统自身漏洞是必要的，毕竟像腾讯那种通过自身通信协议增加安全性的还是少数的（抓过微信和qq的没抓着，不知道有没有相关工具可以抓手机tcp的包）。既然有接口测试为什么还需要单独对客户端进行抓包验证安全性呢？这么说吧，接口测试其实最主要的验证接口逻辑，可用性，边界值，异常检查，但并不能预先保证客户端调用不出问题，一个针对多个app抓包都发现的问题可以说明：抓了好多社交性app，发现对于用户资料隐私泄露还是很严重的，当你查看一个陌生用户信息时，一些手机号，qq等信息页面上应该不显示的，但这些信息不显示并不代表服务器没有下发，好多都是客户端限制的，通过抓包，完全可以查看到陌生用户的app。再如好多发帖，push消息的应用，如果没有消息有效性的验证，抓到包之后篡改消息，服务器一点反应都没，这就会留有极大的隐患。
　　至于逆向工程这点，对于android就很好理解了，反编译，修改或者插入自己的代码，以达到相应目的。真见过几个没有代码混淆的app，包括我们自己的以及大名鼎鼎snapchat，记得有个游戏特搞笑，游戏主题是C#写得，结果java的代码混淆了，C#的代码没有，修改了几个参数值，插了几段自己的代码，就作弊成功了。尤其好多开放平台的游戏，通过开放平台sdk文档，再加上反编译后些许信息，即使代码混淆了，也能推测出好多东西。这些都是安全性隐患。

安装、运行、卸载测试　　

验证App是否能正确安装、运行、卸载，以及操作过程和操作前后对系统资源的使用情况，主要包括：　　

1)检测软件是否能正确安装、运行、卸载；　　

2)安装、卸载、更新错误报告；　　

3)其他辅助信息：　　

-位置和文件夹是否合理；　　

-组件是否正确注册或删除；　　

-评估操作前后，CPU、Memory（内存占用）、Storage（磁盘占用）等系统资源的使用情况。

客户反馈

客户反馈对测试人员来说，也是很重要的参考。

 二、一个重要原则是：测试你最终要发布给用户的App版本。

    可能每日构建、每日测试的理念已经深入人心，我们很多时候测试的只是App的开发和Debug版本，而不是最终的Release版本。在打包最终的Release版本时，我们一般还要加上数字签名，或者再加上代码混淆。那么最终的发布版本和Debug版本肯定有不一致的地方。我们iPhone的App曾经使用过一个第三方开源库，在Debug版本时完全工作正常，但是正式上线后才发现必定会导致崩溃。这个代价和经验非常宝贵（其实这个开源库的论坛上已经讨论并警告过这个问题）。我们后来花了许多力气来修正和弥补这个问题。如果在一开始就针对Release版本进行了测试，这样的问题是不会出现的。

三、测试网络相关的App，有三个非常重要的最佳实践。

    1、2G、3G、wifi都要覆盖

    这三者之间不仅仅只是网络速度的差别，它们代表了三种不同的网络环境。另外你可能没有想到一种特殊的情况可以用它们来测出问题：开发环境和生产环境。

    一个有经验的开发团队会在内网搭建测试环境来进行开发时的测试，在上线时将配置切换到线上的生产环境。这个切换应该是在发布流程中需要Check的一个环节。但是，我们有可能遗漏。

    所以这个测试用例可以用来防止这种情况的出现，在wifi下内网环境可以work fine，但是2G和3G就不行，只有真实的环境下2G和3G才能正常工作（想想2G和3G是否可以正常访问http://192.168.1.xxx这样的地址就可以了）。

    2、HTTP、HTTPS都要覆盖

    许多App和后台服务都是通过HTTP来交互的，正常情况下都一切正常。为什么需要测试HTTPS环境？在一些免费上网的环境中，例如在麦当劳、星巴克里，它们的网络环境都要输入用户名和密码，通过SSL认证来访问网络。如果你使用HTTP Client的library对这种异常没有做捕获处理，那么你的App必定会崩溃掉。

    3、进行网络异常、服务器宕机或出现404、502等情况下的测试

    后台服务的稳定性是你有时很难去控制的，尤其是牵涉到DNS、空间服务商的情况下。国内某著名DNS服务商经常出现大规模域名解析故障，碰到这种情况，你对后台API的请求很可能就会出现404错误。而你和API交互的数据应该是某种固定格式例如JSON和XML，这样你的数据解析必然会出现错误，抛出异常。如果你对异常没有进行正确的处理可能会导致程序不能正常工作。以下用伪代码解释一下逻辑：

[html] view plaincopyprint?

1. try {  
2. if(request() == success) {  
3.     callSuccess();  
4. } else {  
5.     callFail();  
6. }  
7. hidePopup();  
8. } catch(e) {  
9.     // do nothing, just wait….now popup window will show forever on the screen!!!  
10.     // if it is a iOS app, the popup window will lock the screen  
11. }  

try {if(request() == success) {callSuccess();} else {callFail();}hidePopup();} catch(e) {// do nothing, just wait….now popup window will show forever on the screen!!!// if it is a iOS app, the popup window will lock the screen}

    而针对不同的手机系统也有需要注意的地方。Android系统固件1.5、1.6和2.0以上版本都是要分别详细测试的。因为Android 1.5、1.6及以上的SDK有很多实现不一致的地方，兼容性有很大问题。在没有做特殊处理时，可以在Android 1.6上正常运行的程序基本在1.5上打开就会崩溃（资源文件和API的问题，这个可以单独写一篇文章来解释这个问题）。

Andorid 1.5目前仍有1.0%的保有量

我测试Android1.5的机型：摩托罗拉Backflip

    针对iOS系统，除了iOS3、iOS4和iOS5的测试外。我只想说尽可能多，尽可能谨慎，尽可能苛刻的进行测试。受限于App Store冗长的审核周期，一旦你的应用出现严重系统错误，你的修复版本基本不可能在很短时间内在App Store上架。那么用户将需要容忍一周左右的时间你的App所带来的煎熬或者永远离去。App Store的审核以严厉和时间长著称

以上这些只是最近一段时间对于手机app系统测试的一点总接，很肤浅，只有通过不断增加经验，才能更好的做好测试。

个人用过的软件/模拟器：

• Android Studio

• http://www.dimensionstoolkit.com/

• http://www.testize.com/

• ResponsiveTest- Allows you to type in a URL and change resolutions, devices and monitors with ease.

• DesignModo- A site very similar to the one above, just a matter of preference.

• Responsive Web Design Tester - A Google Chrome extension that allows you to test Responsive Design within your browser. 

•  http://ruit.mytechlabs.com/

参考：

http://blog.csdn.net/hfahe/article/details/6886127