移动APP的测试与传统的软件测试稍微有些区别。 

阅读目录

1. 移动App比PC上的程序测试要复杂

2. 移动App测试中如何设计Test Case

3. 让自己成为真实的用户

4. 关注用户体验测试

5. 少做UI自动化，多做后台接口的自动化

6. 测试你最终要发布给用户的APP版本

7. HTTP，HTTPS都要覆盖

8. 进行网络异常，服务器宕机或出现404，502情况下的测试

9. AppStore 冗长的审核机制

移动App比PC 上的程序测试要复杂

各种兼容性，多种分辨率， 多种异常情况。 会让移动APP上的测试更复杂。

移动APP测试中如何设计Test Case

移动互联网开发节奏很快，而且版本快速迭代，  建议完全放弃传统的Tese Case, 不需要写详细的测试用例。  而采用feature list.

比如使用思维导图工具+功能点 的方法。  这样能节省大量的时间。  而且思维导图比较直观，不容易漏掉功能。 

让自己成为真实的用户

大部分移动APP都是面向普通用户的，而不是企业用户。 要让自己成为APP的真实用户， 这样彻底了解业务逻辑， 

关注用户体验测试

用户体验式APP成功的关键， 在这么小的屏幕上，用户体验关系着用户对APP的满意度 

少做UI自动化，多做后台接口的自动化

UI自动化大部分的时候，都没什么意义，投入大，收入少。 应该多关注后台借口的自动化测试

重要的原则：  测试你最终要发布给用户的APP版本

每日构建，每日测试的理念已经深入人心， 很多时候我们测试的是App的开发和Debug版本。 而不是最终的Release版本， 在打包最终的Release版本时。 我们一般还要加上数字签名，或者再加上代码混淆。那么最终的发布版本和Debug的版本肯定有不一致的地方。  很可能最终的版本会有问题。 比如Debug版本是完全工作正常，但是上线后才发现会导致奔溃

HTTP，HTTPS都要覆盖

许多App和后台服务都是通过HTTP来交互的，正常情况下都一切正常，为什么需要测试HTTPS环境？  一些免费上网的环境中，比如，麦当劳，万达商城，他们的网络环境都需要输入用户名和密码，通过SSL认证来访问网络。 如果你使用HTTP Client 的Library对这种异常没有做捕获处理，那么你的APP，肯定要奔溃。 

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

后台服务的稳定性是你有时候很难去控制的，尤其是牵扯到DNS，空间服务商的情况下。 如果出现DNS解析故障，碰到这种情况，你对后台API的请求很可能就会出现404错误， 而你和API交互的数据应该是某种固定格式例如JSON和XML，这样你的数据解析比如会出现错误，抛出异常。如果你对异常没有进行正确的处理可能会导致程序不能正常工作。

2G,3G,4G wifi 都要覆盖

这四者之间不仅仅是网络速度的差别， 它们代表了不同的网络环境。 经常会有些APP能在3G网络下运行，但是不能在wifi下运行。所以在需要check在不同的网络环境。 

AppStore 冗长的审核机制

一旦你的应用出现严重系统错误， 你修复版本基本不可能在很短时间内在App Store上架。   那么你的用户就会离去。