不想当将军的兵不是好兵，作为一名软件测试工程师，有一天你也有可能接手你们公司的测试团队，带领他们走向人生巅峰，但是作为软件测试管理者，我们怎样才能不让人失望呢?
写这篇文章的出发点是最近确实吸收了很多营养的东西，所以很乐于总结分享，同时也是给自己这段时间的辛苦付出留下点美好的印记吧。
作为一个拥有2年开发+6年测试经验的测试老人，多年工作确实学到了很多，但是真正沉淀下来能与人津津乐道的并不多。
工作第5年的时候，第一次组建测试团队，当时觉得非常成功，现在看来，并没有。
一杯咖啡，一台电脑，关于一个好的管理测试团队的方案，思绪开始了...
并且，感觉还不错...
测试前准备
1.需求分析：与客户沟通过需求后，测试组全组人员参与需求分析，明确项目需求。
2.设计评审：测试人员参加设计评审，提出设计文档的疑惑之处，深入了解业务，做到依据设计文档能到写出完整详密的测试用例。
3.编写用例：依据设计文档，编写测试用例。
4.测试计划：测试计划在测试任务确定后，根据测试任务，测试人员，测试时间等做好规划。
5.执行测试：测试准备工作就绪后，执行测试。
流程图如下：
测试规范流程
开发提测
提测阶段的意义在于确保经过测试人员测试之后的系统无特别严重的缺陷，无阻塞流程的缺陷，保证系统具备流畅的测试条件。
第一轮
第一轮测试的依据是设计文档，产出是测试用例的第一轮结果，也是正式测试流程中最重要的一个环节，理论上应该覆盖100%的测试点，以及50%以上的发散点。在这个阶段应该发现系统中90%以上的缺陷。整个测试耗时占到所有测试工作的三分之一【假设只有2轮测试】。
自动化回归
一轮结束后，发现了系统中大量的缺陷，较为庞大的系统可能有几百个甚至几千个缺陷，在这些缺陷被修复后，整个系统是否引入新的缺陷，是否有新的重大问题，需要自动化脚本来检查。
这时候是回归测试的好时机。
第二轮测试
回归结束后，进行第二轮测试，第二轮测试的重点是验证第一轮的问题是否被修复，是否影响到其他功能模块，同时也要进行高密度的发散测试。
交替测试
交替测试是将测试任务重新分工，同一个问题在不同的测试人员二次测试后，更能保障产品质量。
自动化脚本维护
以上测试工作全部完成后，跟踪redmine，在所有缺陷被修复后，录制最新系统的自动化脚本。
在发包之前，进行整个系统最全面的回归测试。
缺陷单管理
缺陷单是测试过程中具有重要意义的产物，不仅体现了测试人员的专业程度，更反馈了软件开发中暴露的各种问题，认真对待缺陷单，确保所有的缺陷都能被解决是保证产品质量的最基本要求。
缺陷单一般都分为新建、开发反馈、验证、关闭等环节，以RedMine举例，如何规范缺陷单的跟踪管理。
1.Redmine问题新建
Redmine问题单规则：
主题：简单的一句话概括问题，通过主题可以明白该问题说的是什么
描述：还原问题出现步骤(前置条件、测试步骤、预期结果、实际结果必须有)
状态：新建
优先级：一般、严重、紧急
指派给：对应问题开发组组长
提出人：redmine提单人
处理人：对应开发组组长
责任组：该问题对应开发组
原则上所有问题必须要有问题截图
2.问题流转至关闭
1. 转开发后，开发回复为请验证，问题单状态为已修复
2. 问题单状态非已修复状态，测试组不予验证
3. 测试组问题验证过，问题单状态为已关闭/验证不通过/挂起
4. 已关闭：该问题测试组验证通过
5. 验证不通过：该问题验证不通过
6. 挂起：该问题开发当前版本不修改：请对应测试人员让开发在开发回复中回复不修改原因(修改中问题无法挂起，请联系开发人员修改状态)
流程图如下：
原则上最后测试组所提redmine问题单最后只能是已关闭，但由于特殊原因可以允许挂起状态。
特殊原因：该问题不影响用户使用，对用户基本无影响;该问题当前版本修改风险具大，这两种情况可挂起，开发回复中写清楚下个版本修改原因
Redmine历史遗留问题
每月版本正式测试前，测试组确认上月版本遗留问题本月是否修改，上月redmine遗留问题，确认本月版本修改的，测试组修改redmine问题单系统版本号为本月版本，问题单状态改为新建。
3.同问题单流转至关闭流程
流程图如下：
案例剖析
测试人员Co在系统功能测试时发现某个新建数据的操作：新建数据有个生成数量的输入框，生成数量没有做限制，于是Co一次生成了1000万条数据，生成之后，对应页面由于大量的数据导致页面打开极其缓慢，影响到工作效率。那么问题来了?如果是你，会如何解决这个问题呢?
为了解决这个问题，Co提出，删掉生成的这1000万条用不到的数据，将生成数量字段做了条件限制，于是开发人员给生成数量字段加了每次最多生成100条数据。
问题看似解决了......
几天后，领导找到Co，因为当时庞大的数据，正好发现了一个数据同步的问题，因为数据量巨大，导致同步数据的过程中，丢失了部分数据，于是，领导要求恢复千万条数据场景再次同步数据分析下问题原因，但是数据已经被删掉了，且因为数据关联性复杂后台也无法重现。
测试Co是万不会想到这批数据会影响到数据同步，但是引发的数据同步问题同时也引出一个新的问题，就是Co在处理这批大数据时的做法究竟合理吗?
我们知道，系统的问题除了功能问题，还有性能问题，虽然这千万条数据不会影响到功能，但是访问页面变得缓慢了问题本质则变成了性能问题了，而Co则完全没有想到这批数据是不可以删除的，而是应该经过性能分析从而判定这批数据是否有存在的必要性或者如何提高系统的性能以达到大量数据存在时，页面访问流畅无阻。
希望这个案例能带给测试人员一个小小的思考：发现问题的解决方法有很多，但是往往由于考虑不周而选择了最捷径的方法。用简单的方式解决了一个小问题，同时也掩盖了一个大问题。
发现问题，分析问题，不放过任何一个细节，才能保证产品的质量。