下面是 可测试性 领域内容的几个例子（更多内容请参阅 参考资料 部分）。
设计是否允许运行时外部工具访问“状态”变量（例如，当前状态），特别是那些测试程序需要用来验证代码是否正确工作以帮助确定问题的变量？
是否对跟踪和日志给予了足够的重视？您让其他人分析缺陷越容易，您在发现缺陷后修正它们就越容易（而且在单元测试中发现自己的问题也会更容易）。
您是否考虑了所有可能调用您的代码的上下文？如果您可以将错误消息与调用它的用户函数上下文相关联，那么用户就更有可能理解这个错误。
设计是否结合了您的测试自动化工具所需要的特定的“钩子（hook）”？
再多想一想您肯定可以在这个清单中加入更多的内容，特别是那些对您的产品或者组织特定的内容。
防御性编码技术：编译器是您的朋友
当您完成对设计的检查后，就轮到编码了。就让我们面对它，除了设计错误外，编码是惟一引入缺陷的地方。无论如何，您的测试程序和客户是不会加入缺陷的 —— 只有 您 会。我们都知道时间很紧张，但是如果您没有时间在第一次就把它编写正确，那么您怎么能找到时间去修正它呢？花上一些时间，这会使您在以后的编码工作中更轻松。
防止缺陷的最好方法之一是使用编译器。令人恐惧的是，开发人员在编译时通常选择使用最低程度的警告输出，所以请启用编译的全部警告 —— 把即使将编译器配置为检查 所有方面 编译时也不产生一个警告当成编写代码的一个挑战。此外，对代码使用多种编译器使很多程序员获益 —— 这种方法有时会捕获不同的语法错误。
编码习惯
下面我们将抛砖引玉介绍几个好的编码习惯。我们不是要为您定义“非常好的编码习惯” —— 我们只是要您形成自己遵守的代码编写习惯。下面是几个供参考的非常好的习惯的例子。
在使用前初始化所有变量
您是否有一组可接受的默认值，特别是对于可能被用户、其他组件或者其他程序有选择地修改的数据？同时，我们强烈要求您列出在最外围例程中要使用的所有本地变量，然后再专门初始化它们。这样不会对您编写代码时的想法留下任何疑问。虽然这可能要多花一些时间并且像是没有理由地增加了几行代码，但是与只是在“运行中（on the fly）”声明本地变量相比，大多数优化编译器不会对此生成任何额外的运行时代码。清单 1 显示了在一个例程中最初几行代码的一个例子：
清单 1. 初始化本地变量
public unsigned short TransMogrify( UFEventLink IncomingLink )
{
//
// local variables
//
unsigned short usRc;
String sOurEventType;
String sTheirEventType;
//
// beginning of code
//
usRc = 0;
sOurEventType = null;
sTheirEventType = null;
//
// a miracle occurs...
//
return( usRc );
} // end "TransMogrify"
使用一个“编码标准”文档
如果您有一个编码标准文档，就使用它。您可以在 Internet 上找到许多种编码标准。找到一种简单的、切中要害、并为您留下一定的活动空间的标准。Sun 的网站有一个关于 Java 编程的编码规范的文章（请参阅 参考资料），它给出了拥有标准的下列几点理由：
一个软件生存期百分之八十的成本都用在维护上。
几乎没有软件在整个使用期间都是由原作者维护的。
编码规范改进了软件的可读性，使工程师可以更快和更充分地理解新代码。
如果您将源代码作为产品交付，那么需要保证它有像您创建的所有其他产品一样的包装和整洁性。
即使不赞成“标准”的想法，至少采用这个简单的建议：对变量名使用“匈牙利命名法”，这会使您的代码更容易阅读和维护（有关匈牙利命名法的说明请参阅 参考资料）。
保证返回代码的一致性
在调试时有一种会制造麻烦的情况是：调用程序屏蔽（或者覆盖）一个表示错误的返回代码。一定要想好您要向调用您的代码的例程返回什么值，并保证从您所调用的例程返回的所有错误代码都得到恰当处理。如果返回代码 n 在一个地方意味着一件事，就不要在其他的地方用返回代码 n 表示另一件事。
对每个例程使用“单点退出”
这一点怎么强调也不过分：对每个例程使用单点退出 —— 就是说，没有多重返回！这是最容易忽视的、也是您可以采用的最好的习惯。如果例程只从一个地方返回，那么就可以用一种非常容易的方法保证在返回前完成所有必要的清理工作，这也使调试更容易。清单 2 显示了一个包含多重返回的代码示例。注意重复代码、甚至忘记“清理”项目（如红色突出显示的文本所示）是多么容易。
