测试工作不仅仅要从产品的角度去保证产品质量，还要完善研发流程，就像一条流水线工作，每个环节都不能出错，才能生产出优质的产品。

　　前言：

　　本篇文章更适用于敏捷开发的团队，如有不足，欢迎探讨。

　　测试工作不仅仅要从产品的角度去保证产品质量，还要完善研发流程，就像一条流水线工作，每个环节都不能出错，才能生产出优质的产品。

　　本文所指开发周期15工作日左右，测试时间5天左右。

 

主要流程：

需求评审——>测试点编写（开发阶段）——>提测——>测试阶段——>封版、上线——>项目总结

 

　　一、需求评审

　　由产品经理发起，参会人：产品经理、项目经理、开发、测试，如有需要，提出需求方，如业务人员、运营人员也可参与。产品经理讲解产品设计，主要包含用户场景、业务流程、页面设计、交互设计等。建议遵循互联网人人都是产品经理的理念，每个人提出自己认为最好的实现方式，但最终还是由产品经理定义。

　　（1）开发同事要从技术角度、和现有框架支撑情况评估各个功能是否可以实现，如不能实现，要与产品沟通折中方案。若产品一定要实现该功能，开发要给出时间，也就是开发成本。

　　（2）测试同事相对更了解整个系统的业务逻辑，要判断每个功能的实现，是否与系统整体的使用习惯匹配，若差异较大，要提醒产品经理，否则会让用户觉得系统逻辑混乱，使用困难。同时思考每个功能点的测试方法，如需要开发协助的，也要及时提出，让开发做好后门，如果有测试点评审流程，也可以在测试点评审时提出。

　　（3）业务、运营人员要确定产品设计是否符合需求，并认真学习产品的使用。

　　评审过程中，产品经理记录要修改的地方，会后第一时间修改（建议当天完成），然后发出需求邮件，进入开发阶段。

 

　　二、测试点编写（开发阶段）

　　该阶段分为两个部分，测试点编写和测试开发。

　　测试点编写和开发并行，个人建议不需要写详细的测试用例，测试点和测试用例的取舍，可另行探讨。测试点编写同时，要及时与产品沟通，有修改的地方，第一时间同步到开发。

　　测试点应包含：

　　（1）本次新增、修改功能点。

　　（2）可能影响到的功能的回归

　　（3）系统重要功能回归

　　如果有需要的话，进行测试点评审，且要至少在提测前2天进行，由测试人员发起，给开发人员缓冲的时间，产品、项目经理、开发、测试参与，测试点评审重点要强调流程、异常处理、测试方法等，一定确保大家对产品的理解没有偏差。测试人员记录要修改的地方，会后第一时间修改（建议当天完成），然后发出测试点邮件。

　　测试开发部分，根据项目实际情况安排工作，如自动化用例的持续集成、mock系统的开发等，个人认为这些很重要，是提高测试从业者个人能力的重要环节。

 

　　三、提测

　　提测要求开发方满足一定要求，要求可酌情而定。但至少要做到本次迭代的主要功能在测试环境可跑通，如果提测不通过，开发加班修改，当天知道满足提测要求为止。避免开发挤压测试时间的情况发生。

 

　　四、测试阶段

　　通常分为三轮：

　　（1）第一轮，产品可满足用户场景，且主要流程可通。

　　（2）第二轮，进行异常操作、兼容性等测试。

　　（3）第三轮，功能回归。

　　如果测试人员在2人以上，建议进行交叉测试。

　　测试阶段可以对bug修复做一些要求，如：

　　（1）提交bug后，开发做出响应，比如在bug管理系统中，bug状态处于处理中，若10分钟内没响应，测试人员应提醒一下。

　　（2）对bug修复做出时间要求，如当天某个时间点之前提出的bug，今天必须修复完成。时间点可根据具体情况定，我们是下午4点。

　　对于封版要求，各不相同，比如bug修复率达到95%以上；代码覆盖率100%等等，本人更倾向于x小时内没有严重问题产生才可以封版。封版前的多半都是回归测试、冒烟测试阶段，若此刻还有严重问题产生，证明第一轮、第二轮测试不充分，或者开发修复bug时未考虑周全，引出其他bug。针对封板要求，希望可以和大家讨论一下，各取所长。如果未满足封板要求，但项目要求必须上线，则需要将风险体现到测试报告中。

　　封版前（可以是当天下午），建议不修复bug，产品、项目经理、测试人员一起评估，若一定要修复的，要谨慎修复并验证，不修复的遗留到下一期处理。

 

　　五、封版、上线

　　封版和上线对于测试来说没什么区别，最重要的是发布包不能变更，至于上线与否，根据公司情况而定，本人公司测试完成仅封版，上线时间由产品和开发决定，上线后通知测试，在正式环境验证功能是否正常。

　　此时需要发测试报告，应包含内容：

　　（1）结论：如测试通过、不通过（原因）

　　（2）工时：人/时

　　（3）bug统计

　　（4）存在风险

　　（5）附件：发布包

 

　　六、项目总结

　　由项目经理发起，总结本次迭代中存在的问题及改进措施。也可以收集在团队协作中，各个角色间是否对他人不满意，并进行疏导或改进。

 

　　总结：

　　还有两个本人认为很重要的流程没有加进来，开发代码review和功能验收。对于大多数敏捷团队，因为各种原因，这两个流程都会被省去。代码review应该加到提测前，益处多多，不赘述。功能验收，应该由需求提出方和产品功能验收，以确保产品满足需求，但此阶段如果出问题，对整个项目来说都是致命的，即使功能上有出入，产品被打回的几率还是很低，所以验收流程对于敏捷开发似乎存在的意义不大。

　　会议发起者或项目经理要适当控制会议节奏，避免话题无限延伸的情况，做无意义的讨论，浪费时间。

　　项目经理要将每个阶段，至少精确到天，当天差一丢丢能完成，就要加班，如果差很多，就要延期，并有明确的延期原因。

　　工欲善其事，必先利其器，本人更注重提测前的准备工作，如需求评审、测试点编写、测试点评审阶段，统一思想，明确产品方向，准备测试数据，保证测试方法可行，后期的工作会更顺利。

　　任何流程的制定，可能最终都会变成“道理我们都懂，但实践起来困难重重”，本人觉得我们至少要总结出一套高效、完善的工作流程，即使不能完整的执行，但也要朝着正确的方向不懈的努力。