【原创】6年测试经验，总结一下我心中的开发流程

前言：

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

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

本文所指开发周期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应该加到提测前，益处多多，不赘述。功能验收，应该由需求提出方和产品功能验收，以确保产品满足需求，但此阶段如果出问题，对整个项目来说都是致命的，即使功能上有出入，产品被打回的几率还是很低，所以验收流程对于敏捷开发似乎存在的意义不大。

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

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

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

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

欢迎大家加入社群，交流经验。

VIPTEST社群（简称V社）是由一群热心的测试行业志愿者自发组织形成的开放性测试同业联盟。

扫上方二维码，或加微信wangxin20317（本人）

 

种下一棵树最好的时间是十年前，如果错过就是现在。

转载于:https://www.cnblogs.com/goldsking/p/9341719.html