说起回归测试，估计很多人都头大，又需要回归了，这是个无底洞吗？不知道。
如果问起，做一次回归测试需要多久？答案应该是千差万别的。我们知道，如果想要测试所有功能，几乎回归测试是不可能做不完的，尤其是日益庞大复杂的系统。那有的同学就会说，用自动化测试啊，直接跑一遍就好了。自动化固然可以节约很多时间，但是它的问题在于，我们只能自动化有标准输入和输出的测试用例，也就是说是一些固定的可以预期的，且在保障鲁棒性的前提进行的。手工测试更多的是测试那些没有且无法自动化的测试用力，因此也是无法取代的；当敏捷测试引入之后，更多的“探索性测试”也加入到了其中，这也是自动化无法覆盖的领域。当项目需要频繁的交付和上线的时候，除了自动化测试，如何有效的进行手工的回归测试呢？
好吧，本文不是灵丹妙药，只是，一种可参考的回归测试策略，我们可以把它称为：风险驱动的回归测试。
背景
先来说一个项目中实际发生的例子：
对RC版本的回归测试刚做完，正打算上线呢，但是发现了一个严重的问题，必须修复后才可以上线。那么就需要立即修复，验证后再次进行回归测试。不幸的是，距离上线我们只有一天时间，如何完成回归测试成为了一个挑战的问题。
在这里，我们遇到了三个问题：
- 重要缺陷被发现得很晚
- 没有时间做一个完整的回归测试
- 不知道如何在一天内进行一次有效的回归测试
一个想法是说，我们只测试本次改动影响的部分，以及跟该功能有集成的其他功能。经过开发和测试的讨论后，我们确定了回归测试的功能列表，成功的进行了一个为期一天的回归测试。最后，我们的产品在发布后的3个月内都没有发现重大缺陷。
这是我们第一次采用风险驱动的方法来进行回归测试。后来经过不断的改进，再也没有碰到“最后一分钟缺陷”的问题。
风险驱动的回归测试主要的挑战在于：
- 风险是很难界定和衡量
- 现有的风险驱动的方法过于复杂而很难执行。
怎么做风险驱动的回归测试
风险是你不知道它什么时候会发生，但却知道它发生的概率。软件开发的风险可定义为未检测到的软件错误可能对系统的用户产生不利的影响的可能性。
如何衡量风险发生的概率
在这里，我们将评估多种维度的风险。
- 关键业务
如果在具有高商业价值的功能中发现缺陷，这将导致严重的影响。因此，这些功能变得非常危险。
- 稳定性
由于缺陷应该被尽可能早地发现，这些不稳定的功能会获得更高的优先级。
- 自动化覆盖率
手动回归测试应涵盖未自动化的测试用例。有几种类型的自动化测试，如单元测试，集成测试，功能性自动化测试等。
- 代码变化
缺陷是由编码创建的。一个功能的更改越多，那么发现问题的概率也会越高。
也可以有其他的纬度来衡量每个功能的风险。每个团队可以决定自己的纬度，基于不同的经验和项目风险。
每个维度的风险判断由最熟悉的团队成员来进行。下表是我们自己的例子。 产品是判断业务是否有价值的专家。 测试人员可以轻易地从已经发现的缺陷的数量和严重程度来判断稳定性。显然，开发人员是单元测试和代码变化情况的专家。
对于每个纬度，我们对他进行1-5的评分，如下表：
通过评估风险设置测试优先级
来一个公式：
意思也就是说，纬度的“风险评估的分数*纬度的权重”之和，等于优先级。例如，在我们的案例中：
基于此，我们可以计算出优先级的数值，最后的表格会像这样：
如此，我们可以判断本次回归测试的优先级，比如我们只测试Priority在10以上的功能，从而可以在有限的时间和资源下，尽可能高的覆盖风险最高的那些功能模块了。
软件质量与持续交付
易用和可定量的风险驱动的回归方法正在团队中实践。它从不同的维度量化风险并且可以容易地限定回归的范围。我们的实践证明，风险驱动的回归测试是一种可行的回归策略，使敏捷团队可以不断频繁交付产品。
从另一个角度，通过实践风险驱动的回归测试，团队了解了更多关于如何控制产品的风险，即控制每个维度的风险：
- 提高自动化测试可以降低产品风险。提高自动化测试覆盖率和有效性是非常有意义的。虽然在开始的时候会花费一定的时间，但从长远的角度考虑，必定会缩短产品生命周期并降低风险。
- 从商业价值上考虑，我们始终要开发对用户最有用的部分。无商业价值的功能的开发完全是一种浪费。这将增加我们的维护和测试工作。
- 随着对回归测试和风险控制的更多了解，开发对build quality in有了更深的理解。
好吧，说了这么多，还想要说的是，尽管我们有各种测试策略，做好自动化测试，always build a working software to be able to continuous released，是我们希望推动的方向。
