3.2 风险：很晚才发现缺陷

作者: （美）Paul M.Duvall Steve Matyas Andrew Glover著 . 出处:机械工业出版社 　2008-04-21 16:04　   砖    好    评论  条 　进入论坛

阅读提示：《持续集成》第3章为您介绍的是利用CI减少风险,本节主要为您展示的是风险：很晚才发现缺陷。

3.2   风险：很晚才发现缺陷

在某些项目中，我们手工执行测试。我们不知道是否是软件的最新变更导致其他问题，例如，对一个错误的修复导致了其他无关的错误浮现出来，这种情况让人避之不及。我们对变更没有信心，因为我们不知道变更对其他部分的影响。没有方法确保开发人员会对软件进行测试，因为这些测试是手工执行的。

场景：回归测试

让我们来看一个回归测试的场景。
Sally（技术负责人）：我发现部署到测试环境中的最新版本中有一个缺陷与两个月之前遇到的那个缺陷是一样的。怎么回事？
Kyle（开发者）：我不知道。我对所有最新的变更都进行了测试。
Sally：您执行了系统其他部分的所有其他测试吗？
Kyle：没有，我没有时间手工执行所有这些测试。这可能是我们在测试之前没有发现这个缺陷的原因。

解决方案

在新项目中，我们开始用JUnit，在业务层、数据层和共用层写单元测试。对于原来的项目，我们根据发现的缺陷，针对代码所做的变更编写单元测试。我们编写了Ant构建脚本来执行所有单元测试，对每次构建都发布一份报告。

下面的步骤展示了在项目中如何利用CI系统来进行自动化的回归测试。
1. 为所有源代码编写测试代码（从某个xUnit框架开始是很好的）。
2. 从构建脚本中执行这些测试（Ant或NAnt是最常见的）。
3. 作为CI的一部分，持续执行测试，在每次向版本控制库签入时都执行测试（利用CruiseControl或类似的CI服务器）。

就这么简单，您已经在项目中实现了自动化的回归测试！我们将在第6章更详细地讨论。

场景：测试覆盖

如果您编写并执行测试，您会看到测试的结果，但是您还想知道实际上有多少代码被测试过。因为在我们的项目中，大部分单元测试在CI系统之前都是手工执行的，所以没有独立的方法来验证这些测试是执行过的。项目经理怎样才能确定有多少代码是测试过的？请考虑下面的对话：

Evelyn（项目经理）：您在向版本控制库提交之前执行了单元测试吗？
Noah（开发者）：是的。
Evelyn：很好。您在实现的其他功能做得怎样了？
Evelyn没有什么问题？让我们再来一次。
Evelyn：针对您的新代码，有没有写新的测试或更新原来的测试？
Noah：是的。
Evelyn：这些测试都过了吗？
Noah：是的。
Evelyn：您如何确定是否有足够的代码通过了足够的测试？
这样的问题要稍好一些，但既然能够通过一些定量的方式来描述，这种定性的分析还是不够的。让我们来看解决
方案。

解决方案

如果开发者或团队相信他们已经对源代码编写了对应的测试，您就可以运行一个代码覆盖率工具，评估有多少代码实际被测试执行过。许多工具都会按包或按类显示覆盖率百分比。

利用CI可以确保这种测试覆盖率保持最新的数据。例如，您可以在CI系统的构建脚本中运行测试覆盖率工具，在向版本控制库中提交变更时就执行它。我们将在第7章中讨论代码覆盖率的问题。

回书目   上一节   下一节