1、摘要
写这篇文章的出发点是最近确实吸收了很多营养的东西，所以很乐于总结分享，同时也是给自己这段时间的辛苦付出留下点美好的印记吧。
作为一个拥有2年开发＋6年测试经验的测试老人，多年工作确实学到了很多，但是真正沉淀下来能与人津津乐道的并不多。
工作第5年的时候，第一次组建测试团队，当时觉得非常成功，现在看来，并没有。
一杯咖啡，一台电脑，关于一个好的管理测试团队的方案，思绪开始了...
并且，感觉还不错...
第一节 测试前准备
1.需求分析：与客户沟通过需求后，测试组全组人员参与需求分析，明确项目需求。
2.设计评审：测试人员参加设计评审，提出设计文档的疑惑之处，深入了解业务，做到依据设计文档能到写出完整详密的测试用例。
3.编写用例：依据设计文档，编写测试用例。
4.测试计划：测试计划在测试任务确定后，根据测试任务，测试人员，测试时间等做好规划。
5.执行测试：测试准备工作就绪后，执行测试。
流程图如下：
第二节 测试规范流程
1开发提测
提测阶段的意义在于确保经过测试人员测试之后的系统无特别严重的缺陷，无阻塞流程的缺陷，保证系统具备流畅的测试条件。
2.第一轮
第一轮测试的依据是设计文档，产出是测试用例的第一轮结果，也是正式测试流程中最重要的一个环节，理论上应该覆盖100%的测试点，以及50%以上的发散点。在这个阶段应该发现系统中90%以上的缺陷。整个测试耗时占到所有测试工作的三分之一【假设只有2轮测试】。
3.自动化回归
一轮结束后，发现了系统中大量的缺陷，较为庞大的系统可能有几百个甚至几千个缺陷，在这些缺陷被修复后，整个系统是否引入新的缺陷，是否有新的重大问题，需要自动化脚本来检查。
这时候是回归测试的好时机。
第二轮测试
回归结束后，进行第二轮测试，第二轮测试的重点是验证第一轮的问题是否被修复，是否影响到其他功能模块，同时也要进行高密度的发散测试。
1.交替测试
交替测试是将测试任务重新分工，同一个问题在不同的测试人员二次测试后，更能保障产品质量。
2.自动化脚本维护
以上测试工作全部完成后，跟踪redmine，在所有缺陷被修复后，录制最新系统的自动化脚本。
在发包之前，进行整个系统最全面的回归测试。
第三节 缺陷单管理
缺陷单是测试过程中具有重要意义的产物，不仅体现了测试人员的专业程度，更反馈了软件开发中暴露的各种问题，认真对待缺陷单，确保所有的缺陷都能被解决是保证产品质量的最基本要求。
缺陷单一般都分为新建、开发反馈、验证、关闭等环节，以RedMine举例，如何规范缺陷单的跟踪管理。
Redmine问题新建
Redmine问题单规则：
主题：简单的一句话概括问题，通过主题可以明白该问题说的是什么
描述：还原问题出现步骤（前置条件、测试步骤、预期结果、实际结果必须有）
状态：新建
优先级：一般、严重、紧急
指派给：对应问题开发组组长
提出人：redmine提单人
处理人：对应开发组组长
责任组：该问题对应开发组
原则上所有问题必须要有问题截图
问题流转至关闭
1. 转开发后，开发回复为请验证，问题单状态为已修复
2. 问题单状态非已修复状态，测试组不予验证
3. 测试组问题验证过，问题单状态为已关闭/验证不通过/挂起
4. 已关闭：该问题测试组验证通过
5. 验证不通过：该问题验证不通过
6. 挂起：该问题开发当前版本不修改：请对应测试人员让开发在开发回复中回复不修改原因（修改中问题无法挂起，请联系开发人员修改状态）
流程图如下：
原则上最后测试组所提redmine问题单最后只能是已关闭，但由于特殊原因可以允许挂起状态。
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第五十期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
