一、需求阶段测试职责：测试组长指定模块负责人熟悉需求，并参与需求评审。测试产出：1、需求问题跟踪列表并已找产品/开发沟通解决，需在语雀对应项目上汇总记录或者项目钉钉群中跟踪，参考如下图：
2、整体测试计划：测试组长给出，人力需求/总测试周期/测试环境/测试工具/测试策略/线上验证策略(线上验收后持续一段时间的功能验证，如定时跑批后功能是否正常，消息推送等)。参考整体测试计划文档：
二、测试设计阶段 (按需)测试职责：模块测试负责人给出模块业务流程图和业务理解（或者测试架构做测试设计），并在概设会议上讲解。测试产出：1、测试设计，需要在概设或详设会议上讲解，目的是开发和测试对模块的理解一致。参考测试设计：
三、编码阶段测试职责：详细测试用例，提供冒烟测试用例，专门的接口用例和性能用例。测试产出：1、用例编写计划：测试组长给出，在编码阶段开始前就需要给出。参考用例编写计划：
2、冒烟测试所需的详细测试用例：负责模块的主流程并录入禅道。3、负责模块详细测试用例：用例需要写在MeterSphere(测试平台)上，或者按照可导入的格式写在excel/xmind上。用例编写参考：
4、测试每日情况同步(日报)：这阶段开始就需要汇总测试情况，主要是：风险同步/编写用例计划进展风险同步参考：
四、冒烟测试测试职责：提供冒烟用例给开发自测，测试验证测试结果，冒烟需100%通过才让提测（开发必须在dev环境测试，测试在test环境100%验证通过）。测试产出：1、提测报告并钉钉群通知(提测报告模板测试出)，提测报告参考下表：注意：开发提测时间推迟的，测试时间也要有相应的推迟，具体测试时间推迟多久，开发负责人和测试负责人一起沟通，不合理的测试时间，测试有权力拒绝。
五、集成测试测试职责：执行用例/提交Bug/跟踪回归Bug/测试总结/测试报告/Bug分析等。测试要求：1、原则上要求每日每人执行用例30个以上，提交有效Bug 3个以上，这个可以根据项目难易程度增减，只要整个集成测试平均达标即可，或者bug率达标：有效Bug数/用例数大于1/4。2、Bug提交需遵守规范，紧急及以上Bug需要当天修复，没有修复说明情况，普通问题三天需给出解决方案。Bug提交要求参考：
3、Bug要正确填写优先级和严重程度。Bug定级标准和打标签：
4、一个项目用例执行最少需要两轮，第二轮根据第一轮的测试情况选择一轮未通过/阻塞/Bug较多模块，第二轮进行交叉测试。5、转UAT标准：整体用例执行率100%，整体用例通过率98%，Bug关闭率95%，不能存在紧急严重以上Bug，安全性测试报告(按需)，不能存在高风险漏洞，性能测试报告（按需），性能符合预期，功能测试报告等齐全，可以先搭建UAT环境，或根据项目计划做调整。测试产出：1、 集成测试计划：测试组长给出，集成测试开始前就需给出。参考集成测试计划：
2、建议复杂难度大的模块需给出测试方法并上传到语雀相应的项目上，方便其他人学习了解。3、测试总结_每人：测试结束，每人都需要写一遍测试总结，主要是测试过程好的方面/不足的地方及改进建议。参考测试总结_每人：
4、功能测试报告：第二轮测试结束，由测试组长编写。参考功能测试报告：
5、安全测试报告(按需)：代码需要用常用安全工具扫描过，且不能有高风险的漏洞。6、性能测试报告（按需）：包括稳定性、性能指标和性能调优，转验收前要求一周稳定性无问题(可选)。报告参考性能测试报告：
稳定性关注内容和指标：
7、用例维护记录清单：测试过程中遇到的用例问题都需要记录下，并反馈给模块负责人优化，测试负责人review。参考用例维护流程：
六、验收测试(UAT)测试职责：测试checklist功能，协助产品完成验收，并复现/验证/关闭Bug。测试产出：1、新增需求添加到功能checklist并测试通过，checklist是为了快速确定主功能无问题；参考内部验收功能checklist：
2、验收Bug分析：产品验收发现的Bug已经算测试漏测，需要分析是否什么原因引起的？参考Bug归因维度的标签：
3、UAT稳定性连续跑7天无问题（按需）；4、性能指标和压测(按需)：UAT要求跑应用和接口的性能指标，并至少做一轮压测。七、线上阶段测试职责：指定一位测试人员线上问题跟踪/复现/验证/关闭。测试产出：1、线上bug分析：线上Bug算测试漏测，需要分析是否什么原因引起的？参考线上问题跟踪规范：
2、自动化线上稳定监控，主要是接口自动化和UI自动化；参考UI自动化关注内容和指标：
3、上线后要持续验证一段时间功能（一二周），如：定时跑批后基本功能是否正常？邮件/钉钉/平台能否正常推送？基本功能是否正常等。八、追责机制(试运行)追责目的：让大家重视自己的模块质量，对自己的测试/开发结果负责，追责或者处罚不是最终目的，提高整体模块质量才是最终目的.测试人员追责方式：分两种，追责A是UAT阶段产品提交的Bug中打标测试漏测的，追责B是线上阶段发现Bug中打标测试漏测的(线上问题在禅道上有专门的项目集，每个项目当成一个模块).追责A：统计周期（同绩效周期）内允许漏测Bug数a=本人有效Bug3%(不影响主流程Bug)，a个＜漏测≤3+a个或2个影响主流程Bug，当次绩效不能A；3+a个＜漏测≤8+a个或3个影响主流程Bug，当次绩效不能B+；漏测＞8+a个或5个影响主流程Bug，当次绩效直接B-；追责B：统计周期内允许漏测Bug数b=本人有效Bug2%(不影响主流程Bug)，b个＜漏测≤2+b个或1个影响主流程Bug，当次绩效不能A；2+b个＜漏测≤5+b个或2个影响主流程Bug，当次绩效不能B+；漏测＞5+b个或3个影响主流程Bug，当次绩效直接B-； 开发人员追责方式：冒烟测试被打回次数：统计周期提测被打回1次，当次绩效不能为A；2次不能为B+；3次直接B-;Bug被reopen次数：统计周期每个开发人员允许被reopen=3次，3次＜reopen≤6次，当次绩效不能为A；6次＜reopen≤10次，当次绩效不能为B+；reopen＞10次，直接B-;Bug的修复时间：严重紧急以上Bug修复不能超过24小时，普通Bug修改不能超过三天，一个Bug超过时间算一次，统计周期每个开发人员允许超时10次，10次＜超时≤15次，当次绩效不能为A，15次＜超时≤25次，当次绩效不能为B+，超时＞25次，当次绩效直接B-。千行代码Bug率：这个作为参考
说明：1、UI优化/建议性问题可以不算漏测；2、项目/产品上线一个月后开始统计，统计周期落在哪个绩效周期，那个绩效周期就执行追责机制；3、统计周期都按绩效考核周期来。九、软件生命周期一览表
本文仅代表个人观点，欢迎指正，
欢迎点赞、评论和转发，谢谢！
