专业的测试服务体系之：测试流程和规范

前言

当下互联网产品以业务为最优先，需求快速变更、版本快速迭代的情形已经成为常态，测试作为一个技术服务部门，需要尽全力支持需求的快速上线，应该尽量灵活而不是拿沉重的流程限制产品；然而，在这种业务迅速变化的混乱情况下，恰当的流程和规范有利于产品研发各个角色的协同，从而提高（而不是阻碍）产品发布的效率。

杭研的质量保障部组建了一个名为“QA专题”的虚拟团队，定期地组织讨论并制定相关流程，目前已经制定的流程有：测试计划、冒烟测试、测试用例、质量报告。

下面就来一一详细解释各个流程的具体规定、背景、目标及意义。

一、测试计划规范

测试计划是我们第三个制定的规范（在冒烟测试、质量报告规范之后，测试用例规范之前），在测试计划制定之前，其实大多数项目测试团队都有测试计划，有些是用完整的测试计划文档体现的，有些是合并到项目计划的。不过，那些把测试计划合并到项目计划的团队，往往只规定了一个测试进度，对测试策略、测试方案等涉及得比较少。当我们深入地看这些项目的时候，发现确实是存在问题的：因为事先没有讨论测试策略和测试方案，导致整个测试团队的行动和配合存在一些随意性，也容易漏过一些Bug，另外，团队成员虽然都是在力所能及的范围内做好自己的事情，但是因为没有事先讨论，有些风险没有提早暴露出来，反而导致在测试周期快结束的时候出现一些变数。基于这些情况，我们觉得部门内统一的测试计划规范还是很重要的。本着沟通重于文档的原则，我们尽量把测试计划的格式规定得很轻型，最关键的就是能写出测试策略、回归策略等，对于其他项不作强制要求。其意义就是促使测试团队在版本的早期就开始思考回归范围，先在测试团队内达成一致，并尽早向项目组提出测试时间上、范围上可能存在的风险并解决。比如，如果范围太大，时间太短，那测试团队可以把一些简单的测试用例交给其他角色去执行、或者提早准备BugBash，号召项目所有成员都来发现Bug。

关键规定：

• 2周以上版本必须有测试计划。
• 测试计划必须经过项目组Review，可以采用线下Review或者线上Review。
• 测试计划着重写测试策略、回归策略等，并尽早提出可能存在的风险。 

模板：

为了使测试人员能快速制作测试计划，杭研QA的测试开发团队在QMS平台开发了测试计划的功能，模板如下：

测试计划.jpg

二、冒烟测试规范

背景：

在冒烟测试规定之前，很多版本提测质量差，版本到测试人员手中后发现根本无法测试，然后又打回给开发，如此反复，使测试时间节点根本无法控制，测试时间压缩；而且，在版本来回的过程中，等待和沟通占了很多时间，严重影响了版本发布的效率。引入冒烟测试最关键作用就是 把关提测质量、控制时间节点，就相当于在测试和开发之间，对提测版本的质量达成一个共识，大家都知道什么样的版本是测试可以接受的 。也有一些测试人员提出疑问，比如，很多产品为了节省时间，版本是分好几次陆续提测的，针对这种情况，我们的建议是：越是这种分次提测、版本紧张的情况，越需要执行冒烟测试来把控节奏，可以根据实际情况，只对比较大的几次提测分别规定冒烟用例，冒烟用例量也可以相对少一些。

模板：

目前，杭研的冒烟测试基本上都已经在TC平台上执行了，云阅读的冒烟测试示例如下：

冒烟测试.jpg

三、测试用例规范和TC平台

测试用例.jpg

测试执行的模版:

测试执行.jpg

写在最后

上述的这些是我们正在实施的，确认有效的一些流程，大大提升了测试工作的专业性、效率和质量。当然，在专业化测试团队的道路上，还可以有更多的轻量级的、促进工作效率和质量的流程，目前，我们正在讨论“线上Bug的收集和总结流程”，期望在几个月内能把线上Bug的流程做规范。