移动测试避坑指南（第一篇）：从流程到技术的知识概要

随着敏捷开发模式的日益流行，单纯的手工测试已经不能保证快速迭代的版本质量。虽然团队掌握了一些常用的自动化测试技术，但是

1、如何系统的开展自动化测试呢？

2、如何丈量自动化的收益呢？

3、如何让团队的每个测试工程师共同进步呢？

我们将移动测试过程中遇到的问题和使用的方法记录整理下来分享给大家，解答以上问题的同时，为大家抛砖引玉，希望共同提升公司产品的质量和众多测试工程师的技术水平。

项目的质量保证

一个项目的发布离不开以下四个环节：

1、产品团队采集需求与设计功能

2、软件工程师的编码研发

3、测试工程师对功能进行测试

4、发布上线与日常更新维护

可以看出来，项目的成功离不开三个团队的通力合作。而在整个项目的研发过程中，测试团队扮演了质量推动者的角色，同时其他两个团队也对质量负责。

项目的质量保证测试前移：

测试团队的早期介入

这是一张在不同阶段修复Bug所需要的成本演示图，随着时间推移修复Bug的成本将越来越高。所以作为测试团队，如果能将软件Bug在前期就发现并推进修复，将大大降低之后的软件开发成本，也会降低因为后期修复过程中导致二次Bug的概率。

想要进行测试前移，就要理解开发的流程以及在各个重要环节进行接入：

我们的移动测试方案

一. 需求分析阶段

顾名思义，需求评审是由产品团队，开发和测试团队一起对需求进行介绍和评审的会议。我们在这个会议中扩大了测试人员的责任，主要体现在以下几个方面：

• 测试团队需要在需求评审过程中提出异常的Case, 这些Case主要有三个作用：

1、能够帮助产品团队补充异常场景，完善产品的设计。

2、能够帮助开发团队在编码期间，针对异常的场景进行处理，避免后期的Bug出现。

3、产出的Case可以作为后续的测试用例一部分。

• 测试团队需要在需求评审中不断地统一需求：

1、协助确认产品的需求被正确的理解，规避因为理解偏差导致的Bug以及返工。

2、协助完善产品需求文档，帮助提升文档的可维护性。

二. 用例评审阶段

传统的用例评审是由编写测试用例的人员将自己的用例讲解给其他有相关业务或者丰富测试经验的测试工程师，由他们进行差缺补漏。我们这这个阶段进行了一定的优化：

1. 用例采用思维导图的方式进行编写，降低了用例的维护成本，提升了编写的效率。
2. 流程上优化，邀请产品经理和对应的开发工程师参加用例评审，并在这个过程中再次确认需求被三方正确的理解。
3. 引入探索式测试的方法论，大幅提升测试用例的异常场景覆盖

三. 编码阶段

编码阶段我们引入了"简化版"的单元测试，来将测试前置。那么什么是“简化版”的单元测试呢？

1、阅读开发的代码，进行基本的逻辑走查。

2、对代码逻辑中未被覆盖的场景，未处理的异常积极的和开发进行沟通。

3、对代码进行静态检查，保证每次提交的代码没有潜在Issue

4、提交代码后进行持续构建，执行自动化测试用例，保证对存在的功能没有影响

四. 测试阶段

测试阶段是每个测试工程师都熟悉的环节，往往是在上线前使用手工测试或者自动化测试方法对版本进行测试。但是，我们为了对质量进一步的提升，做了如下的改进：

1. 编写和维护自动化测试脚本，提升测试效率
2. 测试人员定期交叉业务测试， 保证了解项目中的测试内容和方法
3. 针对移动App的特点，对App进行专项测试：电量测试，流量测试，内存泄露测试， Crash测试和安全测试等
4. 版本上线前集中体验测试，弥补测试人员的思维盲区
5. 提升每个组员的测试能力，积极进行业务分享和技术分享，保证每周1-2次的频率

五. 上线/日常维护

上线后并不意味着测试团队的工作告一段落，我们编写了监控脚本和监控平台，时刻监控线上的接口，主流程等。这里，我们以7Fresh为例：

1. 覆盖95%以上的网络接口，在接口出现问题的时候，可以迅速的通知部门相关负责人。
2. 覆盖首页所有测试点，包括但不限于：轮播图的展示和内容链接，活动的链接和对应的商品价格，名称和图片等。
3. 覆盖基础主流程，如个人中心，列表分类页等。
4. 维护自动化接口统计文档，每次添加/更新接口的信息都及时录入。

总结

现在我们结合团队的移动测试方案及各个环节的产出，一一回答开篇的问题：

一、如何系统的开展自动化测试呢？

自动化测试其实是辅助手工测试的一种手段，其核心目的是更加有效率地发现/保证软件的质量，所以系统的开展自动化分成四个步骤，这里我们以7Fresh的App为例：

1、明确测试的内容：自身的业务功能，用户使用体验以及异常场景的覆盖。

·7Fresh的基本业务流程，如登录，下单，搜索，查看商品等。

·异常场景：低电量，弱网络，安全相关等。

2、调研自动化测试方法以及推进学习和使用

·基础业务流程包括 UI和与服务器交互(接口)等，所以我们选择了Robotium(iOS暂未做UI自动化)和JMeter为主要的测试工具。H5的测试选择Python+Selenium/Beautiful Soup +unittest 作为基础框架编写用例。

·电量测试: 使用了开源工具GT进行测试。

·内存泄露: 使用了LeakCanary，并进行定制化修改。

·性能相关: 使用Trace工具进行监控

·崩溃测试: 使用Monkey进行测试，并上传Crash信息到搭建的平台

·安全测试: 自己编写基础安全测试工具以及使用公司的安全测试平台

我们定期进行工具的调研分享，来帮助大家学习和使用这些测试工具。

3、将自动化测试纳入测试流程，规范化测试产出

·进行自动化脚本的统计，明确项目和人员的自动化产出。

·进行自动化脚本的评审，提升脚本质量以及与绩效进行挂钩。

·优化测试报告，包含UI/专项测试结果。

4、引入持续集成和监控

·持续集成：每天固定时间/代码提交之后 进行自动化用例的执行，并邮件进行通知。

·监控：构建监控平台，并对线上环境/预发测试环境进行监控，邮件通知。

二、如何丈量自动化的收益呢？

以7Fresh为例，我们从几个维度进行自动化收益的衡量

1、覆盖率：我们的自动化涵盖了App的UI主流程，90%以上的接口，H5首页(运营动态配置)的所有监控点：轮播图，活动，商品。 7Fresh所有SKU商品的校验：名称、价格、图片、详情等

2、人效提升: 引入自动化测试的"ROI"公式进行计算

人效提升 = (脚本编写/维护时间 + 脚本执行时间)*迭代次数 - 手工执行时间*迭代次数

所以当测试迭代的次数越多的时候，我们节约的时间越多。根据实行自动化的历史数据，我们得到以下的结果：

3、特殊工具的提升：

·对接口的监控达到秒级，通过分布式执行和核心用例选取，我们可以在30秒内发现7Fresh的接口运行问题。

·7Fresh活动校验，解决了运营团队配置活动后测试团队无法进行校验的痛点。

·7Fresh所有SKU的校验，90分钟可以完成7Fresh所有SKU的核心数据校验。手工测试断然无法进行覆盖测试。

综上，时间的节省，测试效率的提升以及出现线上问题时候测试团队的响应速度，是衡量自动化收益的核心标准

三、如何让团队的每个测试工程师共同进步呢？

1、和每个组员制定可以量化的提升目标，并定期进行审核评估。

2、每周保证1-2次的技术/业务分享，来提升组员的技术栈和对业务的理解。

3、统计项目和测试人员的自动化脚本/工具的开发进度，量化数据。

4、帮助树立职业规划和目标，指明前进的方向。

以上，就是我们的移动测试解决方案，从流程到技术做了一个概要的介绍。

之后的篇章将会详细的介绍各个环节的测试方法，敬请期待。