手机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 后台长时间运行的耗流量，耗电量。

        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 来设计测试点，测试点可以是思维导图或者别的。但是并不需要去编写很
详细的测试用例。