《移动App测试实战》——1.3 测试进度管理

本节书摘来自华章出版社《移动App测试实战》一 书中的第1章，第1.3节，作者：邱鹏　陈吉　潘晓明，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.3　测试进度管理

在一个较大型的项目中，通常运作的方式是按照子项目或者功能模块来进行分工，每个功能模块有具体对应的设计、产品、运营、开发和测试人员。结合实际的项目情况，如果功能较大可能上面一个角色有多个人一起参与，反之也可能一个人同时负责多个功能模块。不管是哪种情况，实际项目在测试进行中，以上不同的角色，以及对应的各个团队leader，甚至公司或部门管理层，都希望及时看到工作的进展，以及遇到的问题和风险。
而另一个方面，互联网产品的测试周期都比较短，一个模块的整个测试周期只有几天是非常常见的，使得我们不可能有大量的时间用在整理测试进度的报告本身。结合这两种情况，我们需要考虑一个比较清晰简洁的方式来反映出测试工作的进度，暴露出其中的问题让大家尽快关注到，同时让编写这样的进度报告的代价变得比较小，因为太多的文字工作是无法承受的。下面我们来看一下在实际的项目中我们用到的一些方式。
从大的方面，我们将测试报告分为两类：
1）测试进度报告：在测试阶段中间发出，告知测试工作的进度，发现的问题、风险，以及接下来的计划。
这个报告发送的频次依据具体的项目情况而定，对于比较重要的且时间比较短的项目，建议每天发出，让相关人员可以非常及时地了解进展和风险。对于一些周期比较长的或者重要性的不高的项目，可以考虑隔天或者每周发送，基于大家的讨论来约定。
2）测试完成报告：标志测试工作的结束，会给出对应的测试结果和结论，包含是否达到可发布的标准以及还有哪些遗留问题。这个报告一般在整个测试工作完成之后发出，针对某一个具体的模块或者整个的测试项目。
下面我们来看看这两种测试报告的具体内容。
1.3.1　测试进度报告
首先来看下测试进度报告，我们拿一个具体的邮件报告的例子来看，如图1-5所示。
从以上报告我们可以看出，主要的内容非常简洁，符合我们前面说的目标。主要侧重以下几个方面：

风险和问题：基于要事先说的原则，在邮件的一开始就把当前遇到的可能影响项目质量或者进度的问题列出来。如果是比较紧急的，可以标红或者加粗来引起收件人的注意。
测试工作进度：这个可以给出一个大概的百分比，可以用测试用例的执行情况，也可以基于测试人员自己的工作估计。
当前bug统计：一个简单的bug统计，让大家可以看到bug的总数和待处理的bug数量。
未关闭bug列表：让大家可以比较直观地看到待解决bug的情况，从标题上就有个基本的了解，以及对应的状态、严重程度和相关的处理人。
以上测试进度报告的内容在项目实际运作过程中并不是严格限定的，相当于一个指导，大家可以基于项目的情况，补充项目的内容信息。
比如我们常遇到以下几种情况：
1）该项目包括多个子项目，每个子项目有独立的进展情况，但是整体在一个进度报告里面比较高效。
针对这种情况，可以在上面的“测试进度报告”里面写上各个子项目的进展情况，如表1-1所示。

2）专项测试进展。针对某个模块的测试，除了基本的黑盒功能测试之前，可能还需要进行其他针对性的测试，我们称之为专项测试，具体的专项测试内容和做法将在本书的后续章节展开讨论，这里为了便于说明，只简单列举部分测试类型，比如：兼容性测试、流量测试、电量测试、弱网络测试、代码覆盖率测试。
针对不同类型的模块，专项测试的开展情况可能不同，如果有相关的开展，建议也在测试进度报告中显示出来。可以在上述简单模板的基础上，补充类似下面的信息：
【专项测试进展】
兼容性测试：已完成Android 2.3，4.0，以及3种不同分辨率的测试，整体进度40%
流量测试：已完成，无异常
电量测试：已完成，无异常
弱网络测试：已完成，一个问题已提交bug，bug单号××××
代码覆盖率测试：未完成
以上是单个项目的测试进展报告，为了便于全局了解整体的测试进度情况，可以将各个项目的进展汇总到一张表格中，如图1-6所示。
在这个聚合的整体测试进度报告中，信息已经被抽象，所以不像单个模块的测试进度报告一样可以看到比较细节的信息。如果需要了解对应模块的细节，需要查看该模块的测试人员发出的针对该模块的测试进度报告。

1.3.2　测试完成报告

当某个具体的功能模块测试完成后，对应模块的测试负责人会发出对应模块的测试报告，发给相关的项目经理/设计/产品/开发/运维同事，以及对应的团队leader，标志着该功能通过了测试，可以进入发布（或者灰度）阶段。
图1-7所示是一个测试完成报告的样例。

实际中报告的具体信息可以根据团队项目管理的要求来做调整。在有专职项目经理来跟进功能和版本进度的情况下，通常项目经理会基于这样的测试完成报告来认定该模块的测试完成，常常也意味着该模块研发工作的完成，所以在发出该报告前也需要将遗留问题都评审过，大家认定当前模块质量达到了发布标准。
以上是单个模块的测试完成报告，对于整个App，通常Android和iOS等平台分开来看，因为对外发布的单位是一个完整的App，所以也需要一个完整的测试完成报告来给出测试的结论。格式和上面类似，只是测试范围和遗留问题的罗列可能会多一些。

1.3.3　系统化的方法

以上介绍的测试进度和测试完成报告，基本能满足测试项目管理的需求，在日常的测试工作中保持信息的及时同步。但是在信息的完整性和效率上也有进一步提升的空间，主要体现在下面几个方面：
1）以上报告里面的信息都是手工填写的。上述报告的里面的测试用例信息，bug统计信息和列表，以及对应的需求点等信息，都是测试人员手工填写到报告中的，这个会需要耗费一些时间，同时信息的准确性有时也得不到保障。
2）一些时间维度的信息丢失。按前面讨论的，测试进度报告是定期发出的，每次看到都是一封独立的邮件，阅读报告的人无法快速地了解到时间维度的信息，比如：
该功能是什么时候提测的，有没有提测延期？
测试和预期有没有延期，偏差的原因。
测试的耗时情况。
这些信息也可以手工填写，但是非常容易因为理解不一致而出错。
3）沟通的成本。如果需要报告格式的变更，需要很多的沟通成本。
针对这样的一些问题，在一些比较成熟的测试团队，特别是一些有较强开发能力的测试团队，通常会借助自动化的系统来标准化测试进度的填写，以及相关信息的自动抽取，测试人员只需要触发相关的报告，并填写少量的主观信息，就可以发出标准化的报告。
图1-8、图 1-9、图1-10是单个模块的测试报告样例。

以上报告的大部分信息都来自于功能测试平台，测试人员只需填写测试报告总结和发布延期原因等主观信息，以及针对一些选项做选择。整个模板是标准化且可定制的。
如果要做到上面的系统化方法，除了测试团队有一定的成熟度和开发能力之外，其实对整个研发组织的项目管理也提出了一定的要求。上面功能测试平台的信息粗略地说需要来自三个方面的系统：
版本需求管理平台。将产品经理或者研发自身提出的各个功能迭代，录入到对应的系统管理起来，需求评审/开发/走查/转测试/测试完成等各个状态都可以在系统中扭转，各个对应的研发角色可以参与进来操作，并完善相关的信息。这个比Excel和邮件的方式来管理需求要方便和高效很多。
测试用例管理平台。可以方便地进行用例的录入和管理，以及支持评审等功能。
缺陷管理平台。缺陷的创建、状态的扭转、已经数据的统计等功能。
以上三个平台都需要提供相关的数据接口，允许测试平台等外部程序拉取对应的信息来汇总。
而更近一步，如果平台上有了每个模块的上述基本信息，自然就会想到可以借助平台来自动化地聚合整个项目组，或者整个大的App版本所有模块的测试进展和完成情况。这样就可以非常具体地看到各种不同维度的测试项目的信息，对于测试团队的负责人来说，对整个测试情况也会有比较好的把握，也能及时发现项目的风险和问题，同时也提到了非常多的度量角度，对项目和团队管理上也是很好的参考。