软件测试中谈一谈单元测试的肥肉与骨头
无处不在80-20规则，在软件开发中也同样存在，例如，80%的错误存在于20%的代码中，80%的项目时间消耗在20%的代码上，当然这只是粗略的估计，不同的项目，比例可能有所不同。
那么，这20%是哪些代码呢？是功能逻辑复杂的代码，也就是算法密集的代码。一个算法密集的函数，通常要对数据进行仔细的分类，一个判定就是一次分类，嵌套的判定就是分类的翻番，要做到分类正确完整且处理无误，是很困难的事。遗漏一个分类，或一个分类的处理不正确，就会造成错误，错误与行数的比值会很高，而且，只有当输入匹配时错误才能表现出来，难于在系统测试中发现。
一个功能逻辑较简单的函数，也许行数不少，也有一些判定，但这些判定通常用于拦载非法输入，以及进行调度，其功能逻辑是容易理解和明确的，错误与行数的比值较低，而且，通常一些很常规的输入，就可以覆盖全部功能逻辑，因此，错误也容易在系统测试中发现。
对于程序员来说，很多代码都是敲键盘，通过编译后，再仔细看一两遍就可以了，这些代码编写速度很快，错误很少，调试时间也少。另一些代码，即算法密集的代码，往往是解决问题的关键，需要创造性的和慎密的思维，这些代码占用了多数的编程时间和调试时间。
单元测试的成本与所需的数据规模正相关，即数据密集的函数，需要更多的测试时间来构建这些数据。算法密集的代码，一般不会同时数据密集，如果是，也应该将算法密集的部分分离出去形成独立函数，例如，一个函数，要对一个结构指针数组里的各个项做复杂处理，那么，这个复杂的处理过程应该独立出去，这是很容易做到的，也是一个基本的编码规范。
算法密集的代码包含大多数错误，且难于在系统测试中完整测试，而单元测试很容易做到这一点，且构建数据的成本低廉，是单元测试的“肥肉”。其他代码或者错误较少且容易在系统测试中发现，或者构建数据的成本较高，是单元测试的“骨头”。
单元测试应该首先将“肥肉”吃到口，至于“骨头”，则视情况选择。
文章来源于领测软件测试网 https://www.ltesting.net/
