这是一个简化的例子，但是请注意遵照这种习惯有多么容易，以及这样做的好处。
加强警戒（En garde）!
要记住，您的客户对您的产品有与您不一样的想法。他们会在一个您的小组很可能从来也没想到的 —— 或者至少是没有可能测试的 —— 环境中安装它。他们会以您从来没有想到过的方法使用它，并以您意想不到的方法配置它。下面的列表有助于帮助您保证他们不会发怒：
考虑所有可能的错误情况并增加处理每种情况的代码（您希望代码得体地处理错误条件而不是堵塞它）。
对于那些未预料到的错误条件，加入一个一般性的“捕获所有”错误处理程序。
在适当的时候和地点使用常量。
在代码各处加入跟踪和日志。
如果您的产品将翻译为另一种语言，那么保证您的代码可以“支持”它。即使出现这种情况的机会很小，但是提前计划总是好一些。修改代码以使它提供支持是最容易产生缺陷的。下面是几个您要考虑的与支持相关的问题： 您是否有任何硬编码的字符串？ 您是否正确地处理不同的日期/时间？ 不同的货币表示呢？
还有，在代码中使用大量断言。有关在 Java 代码中使用断言的细节信息请参阅参考资料。
给您的代码加上充分的注释。总之，您还记得在六个月前编写那个方法时的想法吗？一年后要修改您的代码的某个人又会怎么想呢？在我们提出的所有建议中，这一条可能是最重要的。
跟踪和日志
单元测试（防御性测试技术）
在本文中，我们所说的单元测试是开发人员在自己的代码正确编译后、在交给功能测试小组之前进行的所有测试和分析。正如我们在这只是一个测试中提到的，主动进行单元测试并在测试时像一位测试者那样思考（即，必须往坏处想、热衷于破坏并喜欢恶作剧）是很重要的。下面是在单元测试时要记住的几件事。
静态代码分析工具
第一种，也是最容易的分析代码的方法是让别人替您做 —— 或者像在这里一样，让其他工具替您做。有一些不同的静态代码分析工具可用，从综合性的工具 —— 一些开发机构实际上在他们的“编译”环境（这可是需要购买的）中加入了这样的工具 —— 到其他可以免费从 Internet 上下载的工具。有关可用的静态代码分析工具的信息请参阅参考资料。
发现缺陷
当您准备运行代码并检查缺陷时，要记住往坏处想。这些缺陷是您所创建的或者由您忽略的代码产生。下面是一些帮助您找到代码中缺陷的提示：
文章来源于领测软件测试网 https://www.ltesting.net/
