项目小结：向答案靠近的答案

[如需转载，请在转载时注明出处，并保证本文的完整性]

之前写了篇小结《项目小结：只有问题，没有答案》，转眼几个月过去了，总觉着得交份答案才能对过去忙忙碌碌的2012有点交代。也许这个答案离正确答案的距离尚远，但至少希望能一点一点去靠近。

上回书说到，作为测试人员，我们的目标是在项目计划的时间内交付达到质量要求的产品。这里的目标可以细分为两点，一是质量，一是进度，那在我们项目组目前的现有流程中，如何去实现这两个目标？

——先交代背景

目前项目组的研发流程应该属于传统的瀑布模型，依次分为需求阶段——设计阶段——编码阶段——测试阶段，测试阶段包括ST测试和UAT测试，其中UAT测试是安排在ST测试之后，但没有明确的标准规定什么时候UAT开始介入，一般是ST测试到一定程度，各个功能点的流程能跑通了，没有太多L1/L2的缺陷了，就通知业务开始进行UAT测试，但是项目时间紧的时候，UAT一般是在冒烟测试结束后就开始介入，所以很多时候ST测试和UAT测试时并行的。这里不去讨论这种流程的优劣，我们现在也只能在现有的流程下，规范我们各个环节的工作，去实现我们的质量和进度目标。

——关于质量

相对于进度，质量似乎不容易看见，不容易度量。在产品上线之前，我们怎么判断产品的质量是否可靠，交付到生产环境之后不会出现太多的问题？当然我们会有测试报告，报告中会有诸如测试用例执行率、缺陷收敛趋势、遗留情况分析等指标，但是，用例执行100%是否就能代表测试已经足够充分？缺陷收敛趋势、遗留情况的度量都是针对已发现缺陷的，能就此断定程序中不会隐藏着缺陷吗？

或许测试覆盖率能解答这个问题（这里讨论的是基于测试需求的覆盖，而基于代码的测试覆盖在工作中没有应用过，无法讨论）。测试覆盖率是指测试用例对测试需求的覆盖程度，这是度量测试完整性的一个手段，大部分出现的生产缺陷都是因为漏测，当我们的测试能确保对测试需求有完整的覆盖（这里所说的是测试需求而非业务需求），我们就能判断我们的测试是充分的，能在很大程度上避免漏测，避免严重级别的缺陷遗留到生产上。

那么，在我们现有的流程中，我们可以在哪些环节去做到这些呢？

* 需求阶段：在需求阶段我们有一个很重要的工作就是需求分析，通过需求分析提取出测试需求，从而明确我们要测什么。在这个过程中我们可以梳理出测试需求列表，或者整理成《需求跟踪矩阵》，后续则可以基于测试需求进行测试用例设计。
* 设计阶段：测试需求的来源不仅仅只是需求文档，我们还需要在设计阶段的接口文档、详细设计文档、数据库设计文档、界面原型中提取测试点，补充容易遗漏的异常场景和校验点。
* 测试阶段：一般来说在测试阶段之前测试用例编写就已经完成且通过评审，在这个时候我们的测试需求和测试用例都应该是比较完整的了，这样对于质量才会有比较大的保障。但是，基于各种风险的考虑，对于测试设计而言，应该是持续的，随着对被测系统的熟悉和测试的深入及思路的调整，在测试阶段，还应该及时查漏补缺，确保测试的完整。

——关于进度

回顾了一下经常加班的2012，想到的以下几点：

1、UAT测试介入得太早，导致IT测试人员的主要精力都在支持业务人员的UAT测试，不能充分进行系统测试。常规来说UAT测试应该是在系统测试完成之后才进行，但是项目组这边的UAT测试一般都和系统测试并行，极端的情况是在冒烟测试结束之后，业务人员就开始进行验收测试了，这种情况导致大量缺陷直接暴露在业务人员面前，而IT测试人员的主要精力就从执行测试变成疲于应付业务人员。

IT测试人员和业务人员在测试方面各有优势，作为测试人员，我们有专业的测试手段去指导和规范我们的测试执行，可以更高效地去发现缺陷、定位问题，协调开发人员或者关联系统解决，减少很多沟通解释的成本；而作为业务人员，他们的测试会相对随意，不能避免低效测试和漏测的风险，另外他们对程序不了解，对于发现的问题是否是缺陷，是哪个子系统的缺陷，这些都需要测试人员协助定位、解释，这中间会耗费大量沟通成本，这些是业务测试的劣势，但是，业务人员对生产上的实际使用场景最为熟悉，他们可以发现容易被测试人员和开发人员忽略的业务上的缺陷。

所以更优的方式是确保IT测试人员先充分进行系统测试，先发现和解决程序上的大部分缺陷之后，再通知业务人员进行UAT测试。这里暂时也不能提供一个指标，测试到什么程度可以开始UAT测试了，此前的经验是根据测试计划估算大致工作量，先测试通过一部分功能点，估算这些功能点业务测试大致需要多少人天，相应的这些时间内IT测试这边能否完成剩下的大部分的功能点的测试，取到一个可以平衡的时间点就可以通知业务去验证我们已经验证通过的功能点了，而IT测试这边花少量精力支持业务测试即可，大部分i的精力可以继续进行系统测试。

2、注重协调项目进展速度，却忽略了测试前期所做工作的质量。测试执行效率受限于测试前期所做工作的质量，一方面如果测试前期需求人员、开发人员相应工作质量低下，导致引入大量需求缺陷、设计缺陷或者程序缺陷，这无疑会加大测试执行阶段的工作压力，大量的时间在发现缺陷、修复缺陷、验证缺陷中，导致用例执行率、通过率偏低，进度紧张；另一方面，测试人员在前期的需求分析、测试用例设计如果不到位，不能很好地规范和指导测试执行，也很容易导致测试效率低下。所以测试进度管理重在前期，作为测试人员我们有必要去要求需求人员、开发人员按时保质地完成他们的工作，同时我们也应该尽早介入测试，从项目启动开始，我们就可以开始各项相应的测试工作了，包括和SA、开发人员沟通需求，审核各种文档，参与各种评审，设计用例，准备数据等等。

3、没有提前做好相关测试准备。之前的项目中遇到过部署环境和验收环境的时候没有挑选到有针对性的测试用例来检查环境，导致开始测试时才发现环境问题，阻塞测试，另外测试数据没有提前准备或者准备不充分，也会耽误测试时间，其它的还有熟悉业务和被测系统、新手的培训等等，也是需要提前做好的。在项目进度紧张的时候，往往被压缩的都是测试时间，所以相关的测试准备尽量要提前做好，以免延误测试进度。