大家好，又见面了，我是你们的朋友全栈君。
前言：整理了一下软件测试流程规范简介，仅供参考!
一、流程图概述
二、测试启动阶段（需求分析）
参与软件需求评审、技术评审，以测试的角度分析需求的可测性，可构思将来对测试进行的方法、原则等。更重要的是对不可测或难以测试性问题要及时与产品经理、项目经理、研发人员协调解决。
全面了解需求，从用户角度考虑软件测试需要达到的验证的状态，即哪些功能需要重点测试，哪些则无需，以便将来制定测试计划。
测试人员参与项目晨会，明确需求及任务完成进度及时间节点，研发人员需向测试人员提供外部应用及使用说明（如Redis、RMQ、xxlJob等）、数据库设计说明等!! ，明确测试任务，确定测试周期。
三、制定测试计划_
根据产品需求分析，制定测试计划、测试风险分析，规划测试资源，对测试人员进行分工。测试人员根据项目大小及项目紧急度商讨测试交付件颗粒度。
四、设计测试用例
根据产品需求文档以及历史业务需要提炼出测试要点，形成测试checklist（提取测试需求），根据测试功能点设计测试用例。测试人员根据产品需求尽可能多的设计测试用例，尽可能多的覆盖所有的测试需求。由小组或产品对测试用例进行评审–修改–再次评审–初步定稿–三方评审–定稿。测试用例需要录入到TAPD系统，以便跟踪归档。
五、搭建测试环境（测试准备）
研发人员需告知所需代码仓、新增的数据库字段及表、Job、Redis key、是否需要同步旧数据等。准备测试数据，尽量按照真实有效的数据来测试系统，这样更加的符合业务场景。
六、执行冒烟测试
开发提测后测试人员进行冒烟验收测试，根据冒烟测试的主要功能、测试点进行测试。 冒烟主要流程测试用例与测试数据，检查主要功能是否已经基本正确实现，初步运行主要功能的性能测试，是否存在明显的性能缺陷。对测试发现的问题定时进行归纳与总结，预测以后测试可能会存在的风险。需要对是次的测试情况进行总结，发现冒烟不通过发邮件并口头告知项目经理及研发负责人冒烟不通过，驳回开发重新冒烟。
七、执行测试用例
当测试用例设计完后，测试人员就开始全力 !!实施每一条测试用例!! ，当预期结果和实际结果不符时，这时就产生了bug，测试人员要争取每个bug都能够重现，便于开发修改；测试人员将bug记录到Tapd反馈给相关开发人员，开发人员进行修复，测试人员对已修复的bug进行再次验证，直到bug解决为止，把状态置为关闭，并将测试结果记录下来。在测试的过程中，如果出现了bug但研发人员不认为这是bug，这时应该与产品经理一起讨论判定是否属于bug。对于测试过程中发现的不在测试用例范围的问题应补充到测试用例中，不断地完善测试用例，提高测试覆盖率。
八、Bug跟踪处理
1、测试人员提交bug => 开发人员解决bug => 测试人员验证关闭；
2、测试人员提交bug => 开发人员解决bug => 测试人员验证未通过 => 激活bug => 重新解决 =>验证关闭。
九、UAT测试
测试环境测试及回归测试完毕后提前一天邮件告知运维同步线上数据，准备UAT环境，由测试部署至UAT环境进行验证测试。在UAT需回归所有新增功能及历史场景，特别是对旧数据的处理等。
十、预发布验收（如有）
测试执行完毕，且具备发布标准后与项目经理协商发布至预发布环境，进行冒烟测试。测试通过后通知产品经理进行验收，验收通过监督产品输出验收报告。对验收时与产品要求不符的功能及时跟进根据严重级别优先解决，直至验收通过，达到产品需求标准为止。
十一、测试报告输出
在约定的测试周期内，在所有的用例都执行完，所有的bug都修复完且产品验收通过后测试人员需要针对本次测试项目编写测试报告!! ，将测试结果反馈，反馈是否具备上线标准，可以上线，以及存在的潜在风险和容易出现bug的模块给予建议，相关负责人在下次开发中予以借鉴，避免类似错误的出现，测试报告输出后，可通过邮件形式，让相关研发人员知晓。
测试结束条件：
-
当所有的用例都被执行完，所有的bug都被修复，编写完测试总结报告；
-
基本功能都已实现，一些建议性的bug可以再下一版本中修复； 测试周期结束；
-
如遇项目紧张，急于上线，测试部测试基本功能没问题，对于用户后续发现的bug可以进行跟踪，可与产品经理沟通处理办法。
备注：测试流程将在以后的测试项目中慢慢的修正和完善，一旦进入测试过程中，不接受任何大模块更改，如需更改需求请走需求变更流程。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/135269.html原文链接：https://javaforall.net
