测试实践

　  测试是您可以在执行活动的正常过程中应用这些度量的区域。您可以容易地跟踪缺陷发现率和修复率，测试覆盖统计，等等。您应该能够开发一些度量来帮助您决定在您的整个过程中，您的实际测试过程是否是已被定义的。

　  RUP有大量的活动和工件可供团队来选择。如果您实行了迭代的增量开发，您的测试应该反应出开发的状况。这就是说，您应该希望看到第一次迭代产生的测试用例和测试工件，然后随着系统的增量而增加。

　  让我们假设您的团队的测试过程计划表明，开发人员所提供的单元测试是针对他们开发的每一个特性的；测试人员将根据需求开发一系列集成和验收测试，它将测试每次迭代中的运行软件。再一次，您需要找出这样的问题，它的回答可以帮助您确定您的团队实际上是否是根据这个过程进行测试工作的。对我们的例子来说，我们仅仅需要考虑一个问题： "开发人员会单个测试他们的编码吗？" 如果您安装了自动化测试工具，那么所有的单元测试可以从一个简单的命令开始运行，您就可以很容易地回答这个问题。更值得一提的是，您可以设置您的配置管理系统在任何检入动作发生时执行测试。

　  您怎么知道所有的功能都通过了单元测试呢？这个判定是相当困难的。您可以要求每一行编码都执行单元测试，但是在有些情况下是达不到预期的目标的——也就是说，花更多的精力来开发测试，与这个编码所带来的损失比较起来并不值得。我们知道，我们没有足够的时间来做所有的事情，因此我们必须根据这个行为的回报来进行优先级选择。无论什么原因，您确定单元测试的覆盖率达到100％是不恰当的。在这儿脑子里形成的度量是单元测试的编码覆盖率。在每次迭代或者几次迭代结束时我们可以获得数据。我们所寻找的是数据的趋势。我们想知道单元测试在整个项目中是否自始至终都在执行。

　  让我们假定我们有12个迭代数据值。图一中的曲线图表明三个项目的数据。

   
　　图1：三个项目中12次迭代的测试覆盖率

　  从这个数据中，我们可以推断项目2（图1中急剧下滑的曲线）很明显没有遵循单元测试的过程向导。项目1和项目3似乎很好地完成了这项工作。如果我们认为这很重要，而且有日常数据并有一个更好的图表，我们可以对它进行更深地研究。图2中的曲线图表明了两个项目中的每天单元测试的数据，如果根据图1中的X和Y轴看，他们看起来是十分一致的，但是根据有更多坐标点的图2来看他们却是十分不同的。我们仅仅看了四次迭代，假定我们有每周的迭代（一周按5天计算）。在这种情况下，项目2在执行编码时并没有花时间来开发测试，但是在迭代结束时花了时间来编写测试。如果这两个项目在成功之处有所不同——比如，如果项目2比项目1有更差的质量——这提供了一个这样的暗示：您在追求更高质量时要进行测试。

　  图2：在这种情况下，项目2的团队在执行编码时并没有花时间来开发测试，但是在迭代结束时花了时间来编写测试。

　  总结

　  在这篇文章中，我已经为一些基本练习提出了一些的度量方法。但是我认为这篇文章可以帮助您来确定哪些个度量方法更合适您的项目，您因此能够开发出一个更合理、更容易计算的度量方法。如果您仅仅计划为一两个项目获取度量，那就不必要用这种方法来费心。它不能为您做出有效的推论提供足够的信息。然而，如果您开始为您所有项目获取一些关键度量，您可以逐渐使之增长成为一个有价值信息的数据库，根据它您可以应用统计分析。您不需要大量的数据就可以开始分析并详细阐述关于哪些是有效的哪些不是。您可以，然而需要用一种客观一致的方法来搜集数据。

　  管理您的过程并明白它对您的组织是否有效与用科学的方法来进行实践是相似的。您的目的是能够选择并形成一套正确的能有效支持您的项目的技术。您应该为关键的实践识别出一组度量数据，收集必要的数据来确定这个项目团队是否执行了这个实践。当您获得了经验，增长了度量的数据，您就能够根据经验的观察来调整您的过程。您很快就能够信心百倍地陈述您的项目团队中哪些执行了过程，哪些没有执行过程。