防御性编码与单元测试“交通规则”.docVIP

防御性编码和单元测试“交通规则”软件工程 软件测试 软件开发 级别：入门Scott A. Will (sawill@), 经理，质量保证和系统测试，IBM Corporation/Tivoli Systems SoftwareTheodore F. Rivera (trivera@), 产品开发经理，质量保证，IBM Corporation/Tivoli Systems SoftwareAdam Tate (atate@), 经理，质量保证和总体解决方案测试，IBM Corporation/Tivoli Systems Software1 月 开发人员编写代码。不幸的是，开发人员也编写缺陷，其中大多数缺陷是在最初的编码阶段加入的。修复这些缺陷成本最低的地方同样也是在开发的初始阶段。如果等到功能测试或者系统测试来捕获并修复缺陷，那么您的软件开发成本就会高得多。在本文中，作者 Scott Will、Ted Rivera 和 Adam Tate 讨论了一些基本的“防御性”编码和单元测试实践，让开发人员更容易找到缺陷 —— 更重要的是，从一开始预防缺陷产生。 　　我们三个人的家中有四个青少年驾驶员，很快还会增加一个。不用说，我们非常熟悉在驾驶员培训班中灌输给我们这些新驾驶员的防御性驾驶技术。因为在我们的青少年驾驶员短短的开车期间，他们看到了打手机的男人闯红灯、女人在拐弯的时候化妆，以及业务主管在早晨上班的路上读报。所以孩子们很快学会如何注意可能会发生事故的区域以及如何避免这些事故。 防御性驾驶和防御性开发　　大多数司机接受过防御性驾驶技术的教育 —— 这有很好的理由 —— 但是并不是所有开发人员都接受过防御性开发的教育，特别是那些没有用汇编语言进行过多少开发（如果不是完全没用过的话）、也没有因内存约束和处理器限制而关心过编写极其紧凑的代码的年轻开发人员。本文讨论防御性编码和单元测试概念，它们可以帮助开发人员更快生成更好的代码并且缺陷更少。 为什么防御性开发是重要的？　　捕捉错误、问题和缺陷的最佳位置是在开发周期的早期。图 1 展示了最容易出现缺陷的地方，以及最容易发现它们的地方，并包括了修复这些缺陷的成本（这些成本是针对 1996 年的 —— 今天的成本显然更高）。 图 1. 缺陷：引入阶段及发现阶段（包括成本） 　　当然，比在编码阶段找到缺陷更好的是在一开始就防止它们。防止缺陷应该是开发人员最优先考虑的。我们将分析几个让开发人员可以在编码和单元测试时防止并检测缺陷的简单的、经过证明的方法。 在编译前（防御性设计考虑）　　防止缺陷（特别是系统性缺陷）的最有效方式是仔细检查编码所依据的设计。由设计缺陷导致的缺陷 —— 虽然一般不是很多 —— 通常修补成本是最高的。事前花很少的时间针对以下几点对设计进行检查可以得到显著的长期回报。 设计考虑　　设计是否有任何不清楚或者混乱的部分？如果是的话，在编写任何代码 之前 澄清这些问题。否则，您可能以一种方式解释一个设计需求，而同事则以另一种方式解释它，从而得到不兼容的实现。 　　如果您的代码要访问同时被其他组件访问的数据，那么保证您的设计可以处理这种情况。同时，检查设计的安全问题（请参阅 参考资料）。 　　如果您的代码严重依赖于其他应用程序的代码，那么您对那个应用程序是否熟悉到可以对设计进行检查？考虑在您的设计检查小组中加入熟悉该产品的一个开发人员。在 设计阶段 发现的集成问题可以得到最有效的处理。 安装和使用考虑　　如果您的代码是以前版本的一个升级，那么是否有会使升级失败的参数或者其他选项改变？有哪些其他产品与新代码交互或者集成 —— 如果这些产品本身也改变了呢？还有，您的代码是否容易安装？ 操作系统和数据库考虑　　您的代码是否会在新版本的操作系统或者数据库上运行？您是否知道这些新版本中加入了哪些改变以及它们是否（及如何）影响您的代码？ 这只是测试　　设计是否结合了可测试性？虽然您可能认为可测试性问题不是您需要关心的，但是事实上单元测试 是 开发人员的责任之一 —— 几乎所有使执行功能测试和/或系统测试更容易的任何事情也会使单元测试更容易执行。 下面是 可测试性 领域内容的几个例子（更多内容请参阅 参考资料 部分）。 设计是否允许运行时外部工具访问“状态”变量（例如，当前状态），特别是那些测试程序需要用来验证代码是否正确工作以帮助确定问题的变量？ 是否对跟踪和日志给予了足够的重视？您让其他人分析缺陷越容易，您在发现缺陷后修正它们就越容易（而且在单元测试中发现自己的问题也会更容易）。 您是否考虑了所有可能调用您的代码的上下文？如果您可以将错误消息与调用它的用户函数上下文相关联，那么用户就更有可能理解这个错误。 设计是否结合了您的测试自动化工具所需要的特定的“钩子（