APP测试总结

手机上的app分为基于HTML5的app（类似于pc上的b/S应用）和本地app（类似于C/S结构）。

所以测试上我们也可以充分吸收web的b/s和c/s测试经验。但是不同于pc上的应用测试，手机上的测试有其独特性

 

测试前的思考：我们这个产品主要是做什么的？为什么我要做这个产品?市场上有那些同类型的产品？

测试前的准备：1.使用同类型的产品，不仅仅是使用，应该是测试同类型的产品。2.熟悉我们产品的spec文档，积极和pm交流。3，写测试用例，没有时间至少要有一个checklist。

1.功能

a.基本功能，主要指app是否完成了设计的所有功能。分清模块，写一份checklist，避免漏测。考虑横竖屏切换，不过很多app现在只支持竖屏。

b.系统交互:电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等，

2.性能:稳定性，兼用型（android碎片化是个难题，bug也多，ios相对bug少），app运行的内存消耗和cpu消耗，app后台长时间运行的耗流量，耗电量。

推荐testin这个第三方平台，对android兼用性测试比较有帮助。

 

3.易用性：面是否吸引人、容易理解。界面整洁、简单。无错别字。点击范围确定等。这部分测试中，如果测试认为有不合理的地方通常会提交需求bug。

4.外场：网络切换，网络信号强，弱下的app运行情况。

 

对自动化的一些看法：

目前我们可以接触到手机方面的自动化工具：robotium，monkey，monkeyrunner，androidjunit。但是由于ui变化快，自动化测试往往不方便维护。前三个不需要源码支持，但是功能有限，androidjunit很强大，对代码能力要求高，同时需要源码支持。app的开发周期一般都很短，ui变化大，用自动化要考虑投入成本，大多数的公司估计都不适用。不过测接口之类的通过自动化是个不错的选择。

 

转，说得多有道理的。

1.移动互联网开发节奏很快，版本快速迭代，如何让测试敏捷起来？
Monkey：我建议放弃完全得Test Case。全部用feature list或者测试思维导图或者功能点划分表来进行引导得测试。主要目的不会漏掉功能点以及防止regression得bug。其次要敏捷必须要有自动化得支持。关于这点就是根据不同得app进行定义了。首先UT无论如何就要做起来。其次是api和regression test得自动化要做起来。当然CI也一定要搭建的。


2.移动应用测试，如何更全面的保证产品质量？如何让用户参与到测试中来？
Monkey：更全面得保证产品质量。如果要说到全面，那么必须就是功能，压力，性能，安全，用户体验面面具到了。其实还是和我第一个问题说得一样。将app结合os得特性分层进行逐个得测试或者自动化测试。关于让用户参与到测试中来的话。我建议可以将不同的用户集合起来，qq或者weixin保持联系。然后android可以定期发布内测版本，ios可以发布testflight版本。


3.用户反馈问题建议非常多，如何做好有效管理、分析和反馈？
Monkey：这个我相信无论哪家公司都会碰见。用户的反馈不一定都是有效的。管理的话，我建议还是需要安排一个专门的人进行记录。将反馈全部作为bug的一种，随后填入bug系统方便跟踪。其次关于crash或者无法重现的问题。就需要自己在软件中增加自动反馈crash log的机制。包括用第三方的友盟等也可以。随后再定期的进行log的分析。这些其实都不难，主要就是需要坚持，一直去做。


4.竞争产品很多，测试如何做竞品分析？
Monkey：这个其实我并不是很在行。不过我觉得分析的话。主要有几点。其一，核心功能的体验。也就是说核心功能路径长短。比如A用了3步完成B用了4步完成的功能，那么A明显有优势。其二，核心功能的交互，包括用户的学习成本。其三，场景分析，比如我们可以设计N个场景，在这N个场景中我们自己的产品和竞争对手的产品，用户会做什么选择。其实往往我们一设计之后就发现，有些功能用户根本无法理解，或者根本不用去做。自然也就没有意义。当然分析还有很多，包括下载量，点击数，评论等等。都可以观察。

 

app的测试方式我在我自己的书中会有写。这里我简单介绍以下。不过首先需要肯定是不是拿到手就可以测的。更多的是需要了解
a。产品功能feature list需要熟悉
b。需要产品所在的系统的架构
c。需要熟悉产品本身的结构，本身的逻辑，包括cs结构，生命周期，api等
d。根据abc来设计测试点，测试点可以是思维导图或者别的。但是并不需要去编写很详细的测试用例。