测试-项目流程

认知

刚到公司的时候，看着项目流程，感觉为啥要这么麻烦。项目流程中要关注的点太多了，能记下这么多环节就已经不错了，还要按照这个流程执行，着实有些困难。

但是当你工作一段时间后，你就会发现项目流程的重要性，因为项目流程就是你的套路，没有套路是工作中很可怕的一件事情；有了套路你可以避免很多共性的错误。套路即是你工作经验的总结。

在你缺少经验的时候项目流程可以使你避免犯错，在你经验丰富的时候还要通过你的经验去完善你的项目流程，更多地去避免犯错。项目流程不是一成不变的，是根据工作情况逐渐完善的。

以上说的总结两点，一是项目流程的意义，二是项目流程是需要不断完善的。

几个阶段

流程中到底要分几个阶段，这个不是我们靠脑子凭空想的，回到第一节讲的，是我们工作中根据实际情况逐渐完善的。那么我们就要想一下，我们在工作中都有哪些阶段。

首先我们要有一个需求，有了需求我们就要把它变成程序，并且验证它是我们想要的，最后给用户去使用，发布后我们还要一个反馈。这就是一个完整的需求上线流程。我们将上面的流程抽象为几个大的流程。

1. 需求阶段
2. 设计开发
3. 测试
4. 发布
5. 发布后

需求阶段

一个需求也有它自己的生命周期，从产生到决定开发，这个阶段就是我们在需求阶段所要关注的东西。除此之外我们需要围绕需求做一些辅助效率的事情，例如讲一个群沟通，确认一下上下游业务，确认一下系统结构

需求阶段主要有以下几个关注点

1. 需求评审
2. 业务确认
3. 沟通群
4. 系统结构确认
5. 权限确认

需求产生的几个途径

首先一个需求又会由哪些方式产生呢？对于我所在的机票行业来说，主要有航司的规定、运营流程的改进、运营数据的支撑和由bug带来的业务认知。对于其他行业来说，更多的是产品们的头脑风暴产生的。

1. 航司的规定：这个是行业的标准。
2. 运营流程的改进：根据现有流程分析，提高效率的需求。
3. 运营数据的支撑：根据自己的推测，上线部分功能，产品逐步迭代。
4. 由bug带来的业务认知：因为许多行业标准我们不了解，bad case就是我们最好的老师。

需求review与finally review

当一个需求由产品提出，我们就要对这个需求进行评估，评估它的价值。没有价值的需求我们没有必要去做它。由于Qunar给了每个人许多权力，需求是否通过是参与需求评审三方（PM、DEV、QA，主要是各组的负责人）共同决定的，任何一方提出异议，需求都不会通过。当我们需求评审通过后，老大们会进行一个最终评审，决定是否去做这个需求。在需求阶段就要有需求review和需求finally review。

业务确认

在做一个需求的同时我们要考虑的不仅仅要关注当前需求，在整个业务线，你的需求处于哪个环节？是否与现有业务具有冲突？你评审需求的根据也是从已有业务触发。所有你要两部分，即当前需求和上下游业务。

当前需求你要关注：业务是什么？要解决什么问题？
上下游业务你要关注：整体业务是什么？你的业务处于哪一环节？

系统结构确认

对于Qunar的QA来说，我们在测试中要关注代码，进行code diff，在确认业务之后，我们要了解相关的系统结构，与业务结合起来，了解功能与代码的对应关系，测试中可以方便查询关键日志、快速定位问题。

沟通群

当我们计划开始做这个需求了，我们要开始召集人马了，就要使用沟通工具，去帮助我们沟通，Qunar内部使用的是qtalk，也可以用QQ、微信等。这个阶段我们就要拉个群，三方及其TL，还有各位大佬们。出现问题，尽量在群里沟通，让关注此项目的人都可以第一时间了解项目的进度。

权限确认

开发的代码、测试环境、是否有发布权限（Qunar是QA发布，需要申请每个工程的权限），这些权限最好提前确认好，避免在用的时候，才发现没有权限，这样会浪费许多时间。

设计开发

为什么这个阶段叫设计开发，不是单纯的开发阶段？

因为这个阶段除了我们的DEV在疯狂的编码中，QA也在发挥自己的价值，提供一些测试点，PM也没有闲着，在Qunar case是由产品写的，这一点是互联网公司中独一无二的。

那么这个阶段，我们的流程就要分开去说明，按照每个职责划分。

QA

了解设计

QA需要提前了解开发是如何设计的，因为不同的技术方案对我们的测试影响很大，不同的技术方案可能会有不同的测试方案。

checklist

checklist作为评估需求测试点的工具，是评判一个QA水平最基本的技能，QA需要将需求的所有测试点都列出来，作为本次测试工作的指导依据。在这个阶段QA需要提供本次需求的checklist，并且尽量要早地提供出来。

进度把控

QA是对质量负责，项目是否能如期上线，也是QA的主要职责，在这里我们需要每天关注需求的进度，是否有提测delay风险。一般以早晨站会的形式，关注所有对应开发组的项目进度。

DEV

code

编码是开发的主要职责，在开始前，需要与需求review的同学或者Tl进行技术方案的确认，这个一定要做，不要到了code review阶段才发现与最初的设想不同，可能导致需求delay。

code review

为了在开发阶段就发现设计的问题，避免到了测试阶段才发现，所有code review要尽早，并且更多地指出设计模式等问题。

提交测试申请

开发在code及code review后就会移交给QA，进入到测试阶段。这个阶段我们还要做一些事情，那就是要满足我们的提测标准，这个标准对需求质量控制的重要手段。

PM

case

即测试用例，Qunar的产品要根据checklist写case，case会作为我们提测验收的标准。

项目进度邮件

项目从开始到结束，产品都应该每天发送项目进度邮件，讲进度及时周知出来。

三方共同

checklist review

checklist需要进行三方review，检验我们的checklist是否有遗漏。这里一定要三方进行，避免信息不对等。

case review

case同样需要进行三方review，并且case在review后作为我们的要收标准，在提测质量保证中起到重要作用。一旦case被开发执行且通过，在测试阶段出现过多，可以根据标准进行质量通报。

checklist&case在review中经常因为时间等原因，合并为一次进行，对于小的项目来说，这是可以的，但是对于比较的项目，还是建议分开进行。

checklist&case在review后我们还要根据review的结果修改或者补充。

需求变更

在开发中发现需求本身存在缺陷，三方均可提出，并且评估风险，是否需要进行需求变更，DEV和QA需要给出需求变更所带来的工时变化，由产品同学以邮件的形式周知出来。