“最新的和最好的”基于一个假设：最新的版本就是最好的版本。最新的版本添加了特性，纠正了问题，简而言之，改进了之前的版本。怎么会不是最好的呢？
但是，实际上，事情并不是你想象的那么简单。那些新的特性可能与其它现有的功能不兼容。用户依赖的东西可能消失了。新的特性可能削弱了可用性（尤其是对新用户来说）。还有，那些bug总是在这些新的改变的代码中出现。
因此，我们如何才能判定最新的就是最好的？我们如何知道代码真的准备好了被包括到下一个build中？很多开发组通过建立升级标准来解决这个问题。升级标准是关于某个模块是否准备好包括在一个build版本中的判定策略。
单元测试标准
虽然可以把很多别的东西包括到你的升级标准中来，但是单元测试是所有这些标准的基础。几乎每个组织都假设软件开发人员在做适当的单元测试。但是不幸的是，不同的人对“适当”的测试倾向于采用非常不一样的理解。
好的实践要求开发人员文档化它们的测试，并且对那些测试进行同行评审以确保有适当的覆盖率。如果使用自动化测试，那么开发人员能简单地为开发工具创建测试脚本，并且提交那些脚本用于评审。
当然，对于什么应该包括在单元测试中必须建立一个小组的标准。作为一个开发组，关于应该做什么测试要达成一致的共识需要花费一些时间和做出一些权衡，但是花在这里的时间会从正确的构建过程中得到加倍的回报！让我们看看一些单元测试期望的例子。
功能
当然，每个模块必须被测试以确保它满足设计的要求，并且确保它做了真正应该做的正确的事情。它应该处理什么样的输入？必须完成什么工作？会提供什么服务？它应该产生怎样的输出？它必须管理什么数据,应该怎样使用那些数据？我们必须确保这个模块真正做了它需要做的事情。
负面测试
然后是错误处理。当出现错误时这个模块会做“正确”的事情吗？当它处理某些特殊的输入时会出现什么情况？缺乏数据组成或数据输入的顺序被打乱的时候会怎样？当需要输入数值数据时给它非数值数据会怎样？数据溢出？如果它接收到一个从数据库或网路接口返回的错误状态时会怎样？它会如何处理？一个模块在被认为完成之前，必须正确地处理所有错误条件。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/