要记住，您的客户对您的产品有与您不一样的想法。他们会在一个您的小组很可能从来也没想到的 —— 或者至少是没有可能测试的 —— 环境中安装它。他们会以您从来没有想到过的方法使用它，并以您意想不到的方法配置它。下面的列表有助于帮助您保证他们不会发怒：

　　验证所有收到的参数的完整性（考虑如果您期待一个数组而传递来的是一个 null，但是您在索引数组之前没有检查这种可能性时会发生什么情况）。

　　考虑所有可能的错误情况并增加处理每种情况的代码（您希望代码得体地处理错误条件而不是堵塞它）。

　　对于那些未预料到的错误条件，加入一个一般性的“捕获所有”错误处理程序。

　　在适当的时候和地点使用常量。

　　在代码各处加入跟踪和日志。

　　如果您的产品将翻译为另一种语言，那么保证您的代码可以“支持”它。即使出现这种情况的机会很小，但是提前计划总是好一些。修改代码以使它提供支持是容易产生缺陷的。下面是几个您要考虑的与支持相关的问题：

　　您是否有任何硬编码的字符串？

　　您是否正确地处理不同的日期/时间？

　　不同的货币表示呢？

　　还有，在代码中使用大量断言。

　　给您的代码加上充分的 注释。总之，您还记得在六个月前编写那个方法时的想法吗？一年后要修改您的代码的某个人又会怎么想呢？在我们提出的所有建议中，这一条可能是重要的。

　　单元测试（防御性测试技术）

　　在本文中，我们所说的 单元测试 是开发人员在自己的代码正确编译后、在交给功能测试小组之前进行的所有测试和分析。正如我们在 这只是一个测试 中提到的，主动进行单元测试并 在测试时像一位测试者那样思考（即，必须往坏处想、热衷于破坏并喜欢恶作剧）是很重要的。下面是在单元测试时要记住的几件事。

　　静态代码分析工具

　　第一种，也是容易的分析代码的方法是让别人替您做 —— 或者像在这里一样，让其他 工具 替您做。有一些不同的静态代码分析工具可用，从综合性的工具 —— 一些开发机构实际上在他们的“编译”环境（这可是需要购买的）中加入了这样的工具 —— 到其他可以免费从 Internet 上下载的工具。

　　发现缺陷

　　当您准备运行代码并检查缺陷时，要记住往坏处想。这些缺陷是您所创建的或者由您忽略的代码产生。下面是一些帮助您找到代码中缺陷的提示：

　　试着强行制造您所想到的所有错误条件并检查可以出现的所有错误消息。

　　试着使用与其他组件或者程序交互的代码路径。如果其他程序或者组件还不存在，那么自己编写一些脚手架代码以使您可以试用 API 或者填充共享内存、共享队列，等等。并让您的功能测试小组可以使用这个脚手架代码，这样他们可以把它加入到他们的武器库中。

　　对于 GUI 中的每一个输入字段，试验下面多种不同的组合（考虑 自动化）：

　　不可接受的字符（控制字符、非打印字符等）。

　　过多的字符。

　　过少的字符。

　　负数（特别是当您只期待正数时）。

　　过大和/或者过小的数。

　　剪切和粘贴数据和文本到输入字段，特别是当您编写的代码限制用户可以键入该字段的内容时。

　　文本和数字的组合。

　　全大写字母和全小写字母。

　　为代码创建“压力条件”，如大量活动、慢连接的网络和所有您想到的可以将代码推到极限条件的东西。

　　反复进行同样的步骤，然后：

　　检查未预计到的内存损失条件。

　　检查当内存用光时发生什么。

　　试图创建缓存溢出、满队列、不可用的缓存以及其他“不能正确工作”的情况。

　　对于数组和缓存，试着向数组（或者缓存）增加 n 个数据项，然后试图删除 n+1个项。

　　关于时间的考虑？

　　如果操作“b”在操作“a”之前发生会怎么样？算您 认为 它不会发生 —— 您能 使 它发生吗？如果是的话，可以打赌您的客户会使它发生的。好现在找出来，而不是在修复成本更高、并听到客户报怨您的软件质量糟糕之后再去做。