朝着 零缺陷 的方向

核心提示：软件缺陷大致有三种：做的事情不是客户想要的、做了不该做的事情、做错了事情，这里我们不认为第一种是缺陷，朝着 零缺陷 的方向，出现这种情况的原因非常多，比如需求没有挖掘到位、分析误差导致设计偏离、开发人员理解差异导致实现的与需求不一样，就基本上是有保证的，总结一句话：开发人员单步跟踪测试自己的代码，等等，那么

软件缺陷大致有三种：做的事情不是客户想要的、做了不该做的事情、做错了事情。

这里我们不认为第一种是缺陷，出现这种情况的原因非常多，比如需求没有挖掘到位、分析误差导致设计偏离、开发人员理解差异导致实现的与需求不一样，等等。

那么，对第二种和第三种，原因主要就是编码的问题了，基本上都是代码的BUG问题，杜绝代码错误，就能朝着 零缺陷 的方法迈进。

代码错误只有通过测试来找，测试有黑盒测试、白盒测试，黑盒测试是有效的，但究错误源头，大部分错误，还是只能通过白盒测试的方法来找，白盒测试一般只能由开发的自己做。而且假如是编码运行时低级错，假如不是由开发人员自己发现并修改，而是由测试人员发现出来，一个错误发现、修改、验证，需要往复；测试发现了还好，假如没有发现客户使用时才发现，那其后果影响更大；许多错误累积，项目的周期、成本就这样增大。

开发的自己测试有两种，就是由具体开发人员自己测试，还有交叉测试，例如采用XP的结对编程方法，交叉测试也是有效的，但也费时，需要一些时间才能理解到别人编码的含义，尤其编码质量不佳时。

最直接的办法的就是开发人员自己养成测试的习惯，用最笨也最有效的方法，那就是写完代码后立即实施基于单步跟踪的测试。所花时间看似多一些，但总得来说比测试、客户发现了缺陷再改时间要少得多。

在所有需要测试的方法、代码执行分支（if代码块以及所有else代码块等等）设置断点，代码被执行到了就把断点去掉，操作软件测试运行并检查中间变量值数据记录等，或通过专门的测试界面、测试代码、XUnit测试用例测试，直到所有断点（红色行）都被去掉。

修改已有代码也一样，变动的行都要单步跟踪一遍，尽管自己对写好的每一行代码都有 101% 的信心。

自己写的代码当然都知道自己期望它该做什么、不该做什么，单步跟踪，保证每行代码都被执行到，都被执行至少一遍，这样每行代码没有做不该做的事情、没有运行时错，就基本上是有保证的。

总结一句话：开发人员单步跟踪测试自己的代码，朝着 零缺陷 的方向，朝着胜利的方向