我们都知道完全的测试不是软件测试的一个合理目标。太多的输入组合，事件的发生有太多的可能顺序，太多不同的出错方式，因此完整地测试所有东西，即使是一个很小的程序，也是不可能的。
但是代码和路径覆盖是单元测试可达到的一个目标。事实上，单元测试阶段是把完整覆盖代码和路径作为一个合理的目标的唯一时间。
- 代码覆盖
在单元测试过程中，要求代码的每一行都被执行到，这一点都不过分（并且有很多分析工具可以帮助我们确保这点）。一些代码（尤其是错误处理）是不能被测试到的，除非采用额外的步骤（例如编写一个传递坏数据的函数，或者把错误代码注入到内存中），但是这些不仅仅是适合做的，而且对于确保程序可以处理各种应该处理的情况来说非常关键的！
- 路径覆盖
除了代码行覆盖，测试代码的每一个路径也是非常合理的。例如，我们可以确保每一个“if”的分支都经过了，并且确保每一个“case”的所有分支都得到了执行。我们还可以确保每一个循环路径的初始化和终止条件都是正确的。
回归测试
这些都是“新鲜出炉”的代码应该测试的内容，但是如果改变了一点点的代码模块应该做多少测试呢？在单元级别，应该做多少回归测试呢？这是很容易误解的地方：因为只是很小的改变，所以不值得花费很多的时间去测试它。
确实，对于每次一小行的代码的改变我们不能进行完整的测试。但是，同时，这些“很小”的改动通常带来潜在的、重大的、非预期的影响。最好的方法是恰当地评估回归测试：结合基于风险的测试和区域影响测试。
基于风险的测试
基于风险的测试指基于缺陷的风险来选择测试。对于风险有两个方面：可能性和影响程度。
可能性是判断更改会造成某些问题的机会。我们应该测试那些可能出现问题的地方。评估代码改变的地方是其中一个判断的方式，另外一个是寻找曾经出现的类似改变。
影响程度是关于程序出现错误时造成的损失程度（不管出现的可能性）。那些高影响程度的地方应该被重现测试。例如，程序经常被使用到的核心功能、影响安全的地方。
区域影响测试
区域影响测试是指专注于发生改变的代码区域的测试。例如：
- 一个开发人员应该完全覆盖测试增加的或改变的代码模块。
- 相应地，他应该测试所有受改变影响的路径。
- 并且，开发人员应该对那些与所修改的代码关联的地方做一些相对没有那么严格的测试。例如，如果代码改变的是参数的集合，那么应该测试那些参数被用到的地方。
单元测试的客观证据
计划所有这些测试都是好的，但是也需要一些客观的方式来验证测试被真正执行了。应该收集和保存什么证据来表明开发人员已经执行了那些测试？并且测试得到期待的结果？我们如何知道所有我们决定要做的这些测试已经做了并且做对了呢?
很明显，我们加给开发人员的验证检查的负担应该合理，并且要考虑测试被无意忽略的风险。我们不想强加不必要的作业；我们只是想确保当开发人员说一个模块已经准备好提交了，我们都知道这意味着什么。
文章来源于领测软件测试网 https://www.ltesting.net/
