正在阅读：高效开发与彻底测试高效开发与彻底测试

　　以上流程是动态和反复的，并不是编码完成后再单元测试。开发人员写完一个类后即可提交代码由测试人员完成白盒覆盖和边界测试。另外，团队可以根据开发与测试人员的比例调整工作份额，如果团队没有测试人员，那么由开发人员完成全部单元测试也是可行的。

　　彻底的单元测试对于软件开发来说，其价值是难于估量的：除了保证局部代码的质量外，有了单元测试，任何时候修改代码后都可以通过回归测试来自动检查修改是否引入错误，这就使开发过程可以适应频繁变化的需求，系统分析、概要设计和详细设计都可以做得简单一些，也更能适应螺旋式开发过程，以后的维护升级成本也会大幅降低，同时，高质量的代码使集成测试和系统测试的工作量降低很多(实际上单元测试已包含了大部分的集成测试)，发现问题后的修改也会高效得多。总之，要提高软件开发质量、降低软件开发成本，最有效的改进就是进行彻底的单元测试，如果不进行单元测试，任何流程改进都无法保证产品质量，因为，程序始终是由代码构成的，代码的质量没有保证，软件的质量拿什么来保证？单元测试并不排斥其他过程改进，相反，单元测试对开发流程中的所有环节几乎都有促进作用。

　　下边再谈谈关于白盒覆盖的话题。使用VU实施单元测试，100%的语句、条件、分支覆盖通常都是很容易的，路径覆盖有时候会很难，例如，我们所举的例子， CExFunction::ParseOneParameter ()，有九十多条路径，要覆盖似乎不现实或没必要，这种状况通常是设计不合理造成的，例如，CExFunction:: ParseOneParameter ()函数的代码分为三块：1、解析缺省值，2、解析数组，3、解析类型和参数名，前两块解析了缺省值和数组后把相应的Token从列表中删除，这样的话，第3块与前两块是没有逻辑关系的，但是，这3块代码会组合出很多路径，没有逻辑关系的代码所组合出来的路径是没有意义的，这些代码具有"高耦合低内聚"的特征，不应该放在一个函数中。范例中另外写了一个函数：CExFunction::ParseOneParameter2()，把以上三块代码分别独立出来自成一个函数，这样每个函数都能完成100%的路径覆盖，重构后的代码既易于测试，也易于维护。范例中有大量类似的函数，甚至有超过200行的函数，这是为了检验VU的适应能力，以后的版本是会进行重构。我们建议程序员完成编码后，检查一下路径数量，如果路径很多，代码很可能需要分拆，合理的路径数量应该是等价类数量的一至两倍。另外，从逻辑结构图也可以看出来：图中有两个或两个以上串联的复杂分支结构，往往表示代码的结构有问题。

　　VU的逻辑结构图具有屏蔽对象的功能，因此，遇到上述情形时可以通过交替屏蔽部分分支结构的方式来实现路径覆盖，但这不是我们推荐的方式，因为它虽然可以保证测试的完整性，但并没有改进代码的结构。

　　关于单元测试和范例项目，还有很多值得叙述的话题，例如内存泄漏测试以及一些复杂问题的处理等等，这里暂且不谈。最后谈谈已完成编码的项目的单元测试。对于已完成编码的项目，最好先由开发人员"去耦合"，方法是将代码文件从底层向上排列，按顺序依次将文件加入到另一个工程并编译，如果产生编译错误，则想办法消除编译错误 ，VU提供了文件排序工具，具体的使用方法请查阅帮助中《测试旧工程》部分。完成“去耦合”后，由开发人员对自己编写的代码完成基本功能测试，测试人员完成白盒覆盖和边界测试。对于编码过程中使用自然驱动调试的已完成编写的代码，完全由测试部门进行单元测试通常是很难的。