单元测试标准

建立单元测试原则是时候出新版本了。那么应当把什么包括进来？显然，它应当包括每个模块的最新的最佳的版本。对吧？“最新的和最佳的”基于一种假设：最新的版本就是最佳的版本。最新的版本添加了特性，纠正了问题，简而言之，改善了之前的版本。怎么会不是最佳的呢？不过，实际上，事情并不是你想象的那么简朴。那些新的特性也许与其他既有的功能不兼容。顾客依赖的东西也许消失了。新的特性也许减弱了可用性（尤其是对新顾客来说）。尚有，那些bug总是在这些新的变化的代码中出现。因此，我们怎样才能鉴定最新的就是最佳的？我们怎样懂得代码真的准备好了被包括到下一种build中？诸多开发组通过建立升级原则来处理这个问题。升级原则是有关某个模块与否准备好包括在一种build版本中的鉴定方略。单元测试原则虽然可以把诸多别的东西包括到你的升级原则中来，不过单元测试是所有这些原则的基础。几乎每个组织都假设软件开发人员在做合适的单元测试。不过不幸的是，不一样的人对“合适”的测试倾向于采用非常不一样样的理解。好的实践规定开发人员文档化它们的测试，并且对那些测试进行同行评审以保证有合适的覆盖率。假如使用自动化测试，那么开发人员能简朴地为开发工具创立测试脚本，并且提交那些脚本用于评审。当然，对于什么应当包括在单元测试中必须建立一种小组的原则。作为一种开发组，有关应当做什么测试要到达一致的共识需要花费某些时间和做出某些权衡，不过花在这里的时间会从对的的构建过程中得到加倍的回报！让我们看看某些单元测试期望的例子。功能当然，每个模块必须被测试以保证它满足设计的规定，并且保证它做了真正应当做的对的的事情。它应当处理什么样的输入？必须完毕什么工作？会提供什么服务？它应当产生怎样的输出？它必须管理什么数据,应当怎样使用那些数据？我们必须保证这个模块真正做了它需要做的事情。负面测试然后是错误处理。当出现错误时这个模块会做“对的”的事情吗？当它处理某些特殊的输入时会出现什么状况？缺乏数据构成或数据输入的次序被打乱的时候会怎样？当需要输入数值数据时给它非数值数据会怎样？数据溢出？假如它接受到一种从数据库或网路接口返回的错误状态时会怎样？它会怎样处理？一种模块在被认为完毕之前，必须对的地处理所有错误条件。覆盖我们都懂得完全的测试不是软件测试的一种合理目的。太多的输入组合，事件的发生有太多的也许次序，太多不一样的出错方式，因此完整地测试所有东西，虽然是一种很小的程序，也是不也许的。不过代码和途径覆盖是单元测试可到达的一种目的。实际上，单元测试阶段是把完整覆盖代码和途径作为一种合理的目的的唯一时间。-代码覆盖在单元测试过程中，规定代码的每一行都被执行到，这一点都不过度（并且有诸多分析工具可以协助我们保证这点）。某些代码（尤其是错误处理）是不能被测试到的，除非采用额外的环节（例如编写一种传递坏数据的函数，或者把错误代码注入到内存中），不过这些不仅仅是适合做的，并且对于保证程序可以处理多种应当处理的状况来说非常关键的！-途径覆盖除了代码行覆盖，测试代码的每一种途径也是非常合理的。例如，我们可以保证每一种“if”的分支都通过了，并且保证每一种“case”的所有分支都得到了执行。我们还可以保证每一种循环途径的初始化和终止条件都是对的的。回归测试这些都是“新鲜出炉”的代码应当测试的内容，不过假如变化了一点点的代码模块应当做多少测试呢？在单元级别，应当做多少回归测试呢？这是很轻易误解的地方：由于只是很小的变化，因此不值得花费诸多的时间去测试它。确实，对于每次一小行的代码的变化我们不能进行完整的测试。不过，同步，这些“很小”的改动一般带来潜在的、重大的、非预期的影响。最佳的措施是恰当地评估回归测试：结合基于风险的测试和区域影响测试。基于风险的测试基于风险的测试指基于缺陷的风险来选择测试。对于风险有两个方面：也许性和影响程度。也许性是判断更改会导致某些问题的机会。我们应当测试那些也许出现问题的地方。评估代码变化的地方是其中一种判断的方式，此外一种是寻找曾经出现的类似变化。影响程度是有关程序出现错误时导致的损失程度（不管出现的也许性）。那些高影响程度的地方应当被重现测试。例如，程序常常被使用到的关键功能、影响安全的地方。区域影响测试区域影响测试是指专注于发生变化的代码区域的测试。例如：-开发人员应当完全覆盖测试增长的或变化的代码模块。-对应地，他应当测试所有受变化影响的途径。-并且，开发人员应当对那些与所修改的代码关联的地方做某些相对没有那么严格的测试。例如:假如代码变化的是参数的集合，那么应当测试那些参数被用到的地方。单元测试的客观证据计划所有这些测试都是好的，不过也需要某些客观的方式来验证测试被真正执行了。应当搜集和保留什么证据来表明开发人员已经执行了那些测试？并且测试得到期待的成果？我们怎样懂得所有我们决定要做的这些