51Testing软件测试论坛

标题: 敏捷测试过程和方法-资料收集贴 [打印本页]

作者: chenyujoe 时间: 2011-2-1 11:22
标题: 敏捷测试过程和方法-资料收集贴
研修如何在敏捷测试过程中展开测试，以及评估每个阶段的产品质量。

作者: chenyujoe 时间: 2011-2-1 11:26
原帖地址：
http://www.ibm.com/developerworks/cn/rational/r-cn-agiletesting4/#icomments

基于 Scrum 的敏捷测试应该如何考虑自动化测试

敏捷测试仍然需要自动化测试

自动化测试规划的复杂性已窥见一斑，敏捷测试、Scrum 开发模式下的敏捷测试隐约比我们分析过的情形要更加扑朔迷离。因为总所周知，Scrum 模式下的开发、测试遵循了独特的规则。

首先，迭代模式使得代码逐步累加起来，每个迭代周期又是如此短暂，似乎没有来验证最后几个质量缺陷，突然需求变化了。一半以上的测试用例和测试脚本不再有用。

每个迭代的新功能、新需求的测试和研究紧迫感并不容得我们考虑诸如测试代码复用，或者来计算多少基于上一迭代的测试用例和脚本需要再度测试。

简单的说，就是测试节奏一下子加快了，在这样的压力下，更加对迭代价值的追逐，以致使得每个开发、测试、研究的活动一定能够服务于当前迭代即将诞生的代码和产品。更多的人开始谨慎选择自动化策略，缩减自动化投入。也因而，更多的问题指向敏捷开发专家，我们是不是需要自动化测试，何时开始自动化测试，多少投入自动化测试工具和脚本的开发是值得的。

首先，关于要不要自动化测试，我们的回答是肯定的。迭代模式使得代码量逐步累加的同时，靠后的迭代我们所面临的整合测试压力、测试任务就越大。而且敏捷测试需要测试人员能够随时启动自动化的回归测试对马上发布的迭代代码进行快速验证。

接着我们借鉴传统测试的中自动化测试规划的细则，基于敏捷迭代的特点对自动化测试规划做进一步分析。

敏捷测试中的自动化测试与其在传统测试中的角度有什么不同

应该说迭代次数（n），测试覆盖次数越多，自动化测试带来的好处就应该越多，而产品开发中出错率（d%）越小，自动化测试效果越好。这是我们在之前章节分析出来的结论。

但是，自动化脚本也许因为迭代目标和对象的差异性需要大幅修改。而重新构造和改变测试脚本带来的代价和成本也非常大。

特别在敏捷测试中，产品变化之大给自动化测试带来难度也陡然增加。因此，敏捷测试中，我们要以更精细的单位来计算自动化测试的投入产出比。即，决策敏捷自动化测试的投入产出应该基于每个迭代自身的收益，而不是整个产品开发周期。

在每个迭代的 2 周到 4 周的时间内，我们将经历从测试策略的选择，测试脚本和用例的撰写到即刻的测试执行，和短暂的回归测试。我们不能保证回归测试完全可以自动化，是因为我们可能没有足够的时间投入自动化开发，而正是因为测试脚本和用例的生命短暂，我们开发的成本也如期望的一样缩减了。

因为敏捷的模式在不同项目中的实践存在较大的差异，在进一步分析敏捷测试下对自动化测试规划之前，我将描述一个笔者认为理想的敏捷测试模型。

在这个模型里，我们的迭代周期为 4 周，团队的总共有 7 名成员，其中只有 1 名是测试人员。在这四周的活动中，我们将讨论图表 3 所示的敏捷测试的自动化测试规划方案。

进入迭代的第一周的工作测试人员集中确定测试策略，制定可行的测试计划和划定充分的测试范围。

第二周的工作是准备开始测试的执行，因此要准备好测试用例和测试环境。特别的是，测试人员是根据需求和团队讨论、设计出的用例来开发测试用例的。

第三周的第三天，基于约定，第一个可以执行的产品代码已经能够发布了（这个约定的履行需要整个团队的配合）我们便可开始功能测试了。直到第三周周末，一部分功能测试已经完成，大部分关键的新功能得到验证。

第四周我们将要结束迭代的测试，在这一周中，不但要完成新功能和新非功能需求的测试，也要顾及持续性开发带来的老代码的质量风险。也就是说产品的回归测试将在这个周内开始并结束。同样，基于约定，我们将迭代最后的两天或者更少时间作为回归测试阶段。正如基于 Scrum 的拥有严格的周期制度一样，一旦进入了回归测试阶段，所有人都要配合、遵守例如 Code Freeze 的时间等约定。

图 3. 敏捷测试 Work Flow 最佳实践

Scrum 的自动化测试的 ROI 指标

我们对自动化的规划也将融入这个 4 周的计划。同样，为了更好分析，我们需要几个假设和声明：

声明 1：n，进入回归测试的后我们仍然需要对测试用例反复测试的次数。

声明 2：d%，这段时间内测试的平均出错率仍然是 d%。

声明 3：TotalEf, 即执行一次回归测试所花费的执行成本。

假设：

假设 1：产品迭代周期为 4 周。

假设 2：在此次迭代中，第一个可测的产品发布于第三周的第三天。

假设 3：回归测试于第四周的倒数第 1 或者第 2 天进入，在此之前测试人员将要完成新功能测试。

假设 4：一个迭代达到退出的标准是 (d%)n<5%，也就是说 95% 的测试都通过了，这样的迭代才能是的客户满意。

因此，迭代次数 n 就必须满足

公式 10：

而从图表 3 所示的的最佳实践中，我们假设测试人员将用迭代的最后 1 到 2 个工作日来完成回归测试测试。

因此，如果TotalEf 是执行一次回归测试用例所花费的代价的话，那么

公式 11：
（单位人天）

根据公式 10 和公式 11，我们可以确定的得出：

公式 12：

将公式 12 代入公式 9 得到公式 13（不是十分严谨，不过不影响分析）

公式 13：
（单位人天）

绘制其曲线是，n 作为横坐标取值为 1:1:10，x 为自动化工具、脚本开发维护的最大投入。

图 4. 迭代中自动化测试脚本开发与维护成本规划

基于图示，我们可以得到以下基于敏捷测试的自动化测试规划的规律：

结论：
一般产品的测试错误率高于 20%，也就说为了达到质量好到足够能够退出，回归测试至少需要 3 次，在这种情况下我们其允许投入到自动化开发的成本为不多于 3 人天。

而当产品质量非常好，错误率低于 20%，因为不需要经过多次测试以达到退出标准，我们也就可以省去自动化测试的步骤了。

最后关于本文的经验之谈，当我们从事着敏捷测试活动时，在四周为周期的迭代测试中，测试人员在第二周的开始进入自动化脚本开发。开发活动不易超过 3 天。

--------------------------------------------------------------------------------
回页首
总结

不要指望自动化投入越多对产品和质量越好，也不要指望自动化测试可以取代手动测试。但是，自动化测试是需要测试人员合理、科学的使用来提高测试成效的途径之一。ROI 的自动化规划将是非常适合敏捷测试、传统测试的最佳原则。

而成功的自动化测试除了拥有良好的规划外，自动化成本越低，开发工具越简易，自动化维护和管理复杂度越小，自动化测试也越容易驾驭。因此，在同等自动化规划下，测试人员应当采用更成熟的自动化测试工具，积极参与自动化测试经验交流以不断提高测试自动化开发的生产率，以有限的投入获得更大测试收益。

作者: chenyujoe 时间: 2011-2-22 11:40
先规划出有哪些测试类型。

作者: trz95 时间: 2011-4-1 17:26
好贴。我们公司也在采用这种开发模式，但是还在摸索阶段

作者: shimltester 时间: 2011-6-25 14:46

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)