敏捷测试度量标准打破传统测试方法

ZDNet至顶网软件频道 大多数习惯传统阶段性开发模式的测试人员也习惯了制定和使用度量数据、在正式的缺陷跟踪系统中记录缺陷、编写详细的测试计划。这些人在敏捷开发中应该何去何从？许多软件企业必须遵守审计制度或者质量过程模型。这些要求通常不会因为你开始使用敏捷开发实践而消失。事实上，一些人担心敏捷开发与这些模型和标准如CMMI、ISO 9000不协调。敏捷测试经理Lisa讨论了有关度量标准涉及的各个方面。

Lisa首先阐述了为什么我们需要度量：

我们有充分的理由收集和跟踪度量。当然，也有理由不应该这样做。任何人都可能把良好的度量标准使用得非常糟糕，例如将其作为每个团队成员业绩衡量的基础。但是，如果没有度量，如何测算进度？当度量被用作路标——提醒团队偏离了轨道或者在正确的道路上提供反馈——那么就值得收集。单元测试的数量每天都在增长吗？为何代码覆盖率从75%下降到65%？原因很可能是，我们去掉了测试覆盖的无用代码。度量可以警示我们问题，但是它们通常无法独立地提供价值。

同时，她指出，在实现团队目标的过程中，测算里程碑的度量是有用的。如果目标是把单元测试代码覆盖率提高3%，那么在每次添加代码后我们都可能运行代码覆盖测试以确保没有放松单元测试。如果没有实现预期的改善，找出原因比抱怨因此而减少的奖金更重要。不应该关注个人度量，而是着眼于目标和到达目标的趋势。

不仅如此，度量还帮助团队（包括客户）跟踪迭代期内和版本期内的进展。如果使用燃烧图，而且一直在上升而不是下降，那么这是一个警示信号，看一看当前的状况，确保我们理解和解决了问题。也许团队缺乏故事的重要信息。度量，包括燃烧图，不应该用作一种惩罚或者责备的形式。举例来说，类似“为何你的估算太低？”或者“为何你不能完成所有的故事？”的问题应该改成团队的形式：“为何我们的估算这么低？”、“为何我们没有完成所有故事？”

度量，如果使用得当，可以激励团队。Lisa的团队跟踪每一个构建运行的单元测试数量。大里程碑——100次测试、1000次测试、3000次测试——都值得庆祝。单元测试的数量每天都在增长对于开发团队和客户团队来说都是一种良好的反馈。但是，请注意数字本身毫无意义。举例来说，测试可能写得非常糟糕或者必须充分测试产品，那么我们可能需要10000次测试。数字不能孤立地看待。

Lisa还举了一个现实当中的例子：

Pierre Veragen告诉我，他曾经所在的团队对度量极度厌恶，团队成员决定停止度量测试覆盖的代码范围。六个月之后当他们决定再次度量的时候，惊讶的发现代码覆盖率已经从40%降低到了12%。如果不使用正确的度量，你会付出何种代价？

当你试图找出衡量的内容，首先需要理解你想解决的问题。当你知道问题的描述，那么你可以设定一个目标。这些目标需要是可衡量的。“在20位并发用户的压力下把XYZ应用的平均响应时间减少到1.5秒”比“提高XYZ应用的性能”要好得多。如果你的目标是可度量的，你需要收集的测量数据是显而易见的。

请记住，把度量作为一种激励的手段而不是打击士气的方式。再强调一遍：关注目标，而不是度量。可能你没有使用正确的度量来评估是否实现了团队的目标，或者没有根据情境解释它们。缺陷报告数量的增长可能意味着团队测试做得好，而不是他们代码写得糟糕。如果度量没有帮助你了解进度，你可能使用了错误的度量。

接下来，Lisa提出了一些与度量有关的问题，让读者进一步的思考度量标准的意义和制定规则。

可度量的目标是一件好事。如果无法通过某种方式衡量，就无法证明实现了目标。另一方面，使用度量判断个人或者团队的业绩是危险的。统计数据本身可以被扭曲成任何有害的解释并被利用。传统上，采用代码行数作为一种软件衡量标准。行数多是好事吗，意味着团队生产力高？还是坏事，意味着团队编写了低效的意大利面式的代码？那么发现的缺陷数量呢？通过这些数据来衡量测试人员有意义吗？会怎样帮助他们把工作完成得更出色呢？一个开发团队每行代码产生的缺陷很多，就说工作得不好吗？或者说发现了更多缺陷的团队工作得出色吗？即使存在这种思想，它又如何激励团队与这些数据斗争，会使团队成员开始编写无缺陷的代码吗？

我们都知道度量都会变化。有多少测试运行和通过？多少天才能得到一个稳定的构建版本？整个构建都通过了吗？无法看到和能够轻易解释的度量是没有意义的。如果你想要跟踪测试通过的数量，那么确保度量以正确的方式呈现给合适的人。据我说知，硕大的图表是显示度量最有效的方式。你的度量值得吗？不要为了生产数字而度量。想一想你能从这些数据中得到什么？

最后，Lisa谈到了度量的投资回报率：

当你定义所需的度量时，确保代价是合理的。如果连续构建产生了有用的数据，那么度量是有意义的。如果无论如何都要运行构建并提供我们额外的信息，那么是额外的收获。如果需要做大量额外的工作以获得信息，想想是否值得。

Lisa的团队花费了不小的精力去跟踪比较每个故事使用的实际时间和评估时间。除了发现评估也不过如此之外还学到没的东西了吗？没什么。一些经验丰富的团队不需要sprint的进度图，因为任务会议提供了度量进度的足够信息。他们能够把花在评估任务和计算剩余时间的时间用在更有生产力的活动上。这并不意味着我们建议你停止跟踪评估。新的团队需要理解速度和进度，因此才能逐步提高。

缺陷率是传统的软件度量标准，它们对于致力于零缺陷的团队来说可能没有多大价值。知道开发过程中发现和修补的缺陷率没有什么意义，因为发现和修补是开发的必要部分。如果测试人员向开发人员展示了一个由其代码引起的缺陷，并且编写了单元测试，缺陷立刻被修补，那么就没有必要记录这个缺陷。另一方面，如果在产品发布时发现了很多缺陷，那么有必要跟踪其数量以查看团队是否改进。

当Lisa的团队开始重写错误不断的遗留应用时，他们设定了一个目标：在产品发布的六个月内新代码不能出现超过六个严重缺陷。制定一个直接和容易跟踪的目标有助于帮助团队想办法在开发阶段减少缺陷并达到目标。记录每一个度量标准的投资回报并决定是否跟踪或者维护它。收集数据的精力与其产生的价值相称吗？容易交流和理解吗？总之，视情况而定。在几个sprint阶段实验一个特定度量标准，然后评估其是否成功。