“没有任何办法！”
当我问及是否可以将系统测试时间缩短一周时，这是我的团队的反应。
在这个项目中，我们通常有九个月的交付周期，在代码实现里程碑之后有三个月专门用于系统测试，并且这三个月每天要充分利用起来。在最后几周的晚上和周末我们还得加班。我与团队花近一周开会探讨找出了很多原因，为什么需要更多时间，而不是更少？
所以，我们采取了与众不同的策略：花时间找出时间变量有哪些，列出在这12周内要做的所有事，最后得到了一个模拟时间的伪方程：
系统测试持续时间= RC *（TC / TV + B * BHT）/ PC
- RC =迭代测试周期，或者由于应用变更所需迭代测试的次数
- TC =每个周期中执行的测试用例数量
- TV =测试速度，或者我们在单位时间内平均执行的测试用例数量
- B =在测试阶段发现并修复的bug数量
- BHT=bug处理时间，或处理每个bug的工作量（诊断，记录，验证修复等）
- PC =人员能力或测试人数，以及他们的生产力
现在我们将这个模型作为一种以更简单的方式表达，可以提出更实际的问题：
- 我们可以做些什么来减少迭代测试的次数？
- 我们需要执行所有测试用例吗？
- 我们怎样才能提高测试速度？
- 我们如何减少测试阶段必须处理的bug数量？
- 我们可以更有效地处理bug吗？
- 我们在哪里可以找到更多人来帮助测试，如何才能提高他们的工作效率？
花时间将这个大而丑陋的问题分解成更具可操作性的问题确实帮助我们找到了可以改进的地方，我们并不是想象的那么无助。
我们重新开始开会，每次只讨论一个问题，然后探讨改进这一时间变量的方法。最后，经过一年的改进，我们将系统测试时间缩短到五周。最初开始，我们并不认为能缩短哪怕一天的时间，然而最终缩短了一半以上的时间！
减少系统测试中的bug
我们开始解决在系统测试期间发现的bug数量，因为我们确实发现并修复了许多bug，因此有很好的机会进行改进。但更重要的是，减少bug对于我们“提供高质量软件”的主要目标至关重要。
在此之前，我们没有记录系统测试中发现的bug的根本原因，因此我们不得不使用一些判断和与开发团队协作。我们阅读了上一个测试周期中发现的bug样本并查找了任何模式。我们发现了许多简单的编码错误和许多内存泄漏（它是一个C ++应用程序）。
我们花了一些时间确保从代码审查中获得最大收益，以帮助减少编码错误的数量。我们进行了代码审查培训，跟踪了代码审查，并将代码审查结果报告给了团队。我们还开始使用一些旨在检测内存泄漏的工具。这两项改进开始削弱在系统测试期间处理bug的工作量。
我们最终开始记录bug的根本原因，并定期进行分析以找到其他改进的机会。
改善bug处理时间
当我们查看bug列表时，很尴尬地发现我们报告的一半bug是在没有修复的情况下关闭的。其中两个最大的影响因素是开发人员无法重现bug，和重复bug。
这需要一个简单的改变：我们训练测试团队在新建bug之前搜索bug系统。如果他们发现了类似的bug，他们会考虑使用更新的数据修改原始bug报告，或咨询bug指派的开发人员。
对于无法重现的bug，我们尝试了一个实验。测试人员将持有一个“bug集合”来向开发团队演示bug，而不是测试员编写bug并继续。这个bug集合处理通常放在在一天结束时。然后测试人员会在该对话后再编写bug报告。这使得bug更快修复，因为开发人员经常会说，“啊，我明白发生了什么。”错误演示避免了bug重现步骤中可能存在的歧义。
经过这些改进之后，我们看到80％以上的报告bug实际上得到了修复，我们减少了“bug乒乓（太极）”游戏。
提高测试速度
提高测试自动化覆盖率似乎是提高测试速度的方向，自动化确实提供了帮助。但是我们发现其他一些东西也有助于提高速度。
我们构建工具来帮助在环境安装后自动填充测试数据，因此测试人员已安装了构建版本，并在早上到达工作时已经准备好所需的测试数据。
我们还创建了“期望修复的bug”列表，并标明这些bug的优先级。最需要修改的是阻碍性bug，因此我们将开发人员处理的优先级与测试人员的工作效率联系起来。这有助于减少测试人员等待修复的时间。
减少测试用例
考虑减少执行测试用例的想法是相当有争议的。但如果我们做基于风险的测试，将更多的工作放在风险最大的地方取得了不错的进展。
我们将每个测试用例分为两个维度：这些测试发现bug的概率，以及假如产品的某个区域存在bug，对客户造成后果和严重程度。每个维度都被标为高、中或低，并使用图表来确定该方法：
我们与开发团队一起审查了这一分析，询问他们认为风险最大的区域。他们能够立即指出一些区域，并且他们还在更改日志中对经常修复bug的代码进行了一些研究。
我们还与产品管理团队一起审核了这些数据，以评估对客户影响的严重级别。同样，他们有一些直接关注的问题，并根据使用情况分析进行了后续分析。
P1优先级的测试用例是我们测试的最高优先级。我们确保测试时尽早执行这些测试，在测试周期至少迭代测试两次。
接下来是P2测试用例，在迭代结束时对回归测试采取了更多的自由度。对于P3测试用例，我们对它们进行了详细检查，并使用采样的方式在系统测试中执行一次，将这些测试用例修剪下来。
寻求更多人
我最后保存了这个改进，因为这是团队要求的第一件事：一个更大的团队。起初要求更大的预算我感到很担心，我不想做更多同样的事情。但是，在完成上述一些改进并展示其进展后，我们的领导者会问我们还能做些什么。