问答网站上看到一个提问：

项目进入测试，但回归测试内容多，发布时间紧迫，人还少，要怎么做？

标准答案应该是自动化测试

回归测试主要关注的是历史功能，如果自动化测试覆盖率达到一定程度的话，把历史用例自动化跑一遍，就基本达到回归目的了。

但是做自动化的功夫在平时。题主这时遇到问题，自然应该是没有自动化或者自动化覆盖率很小。

这种情况下怎么办呢？

理论上的最优选择，这时需要基于二八原则，按优先级，重点保证关键部分、有风险部分的功能正常。对应的做法在测试业内也有专门的测试模式，也就是RBT(Risk Based Testing)，基于风险的测试。

抛开实践落地不谈，先聊聊RBT是怎么做的？

RBT其实是基于预先对软件的失效风险进行评估，并据此来指导整个测试流程，包括从计划到设计、执行的一种测试模式。

RBT的优点其实就是对应题主说到的这种情况，能在有限的时间内，优先完成高风险部分的验证，使产品在较短时间内就可以建立比较强的质量信心

但RBT的难点其实在于怎么比较准确地评估出这个风险。

风险的定义：

风险 = 失效的可能性 X 失效发生的严重程度

可能性跟很多因素有关，产品功能实现的复杂性；实现这个功能的开发人员技能；这个功能前期需求的清晰程度；完成这个功能投入的时间；有无单元测试....等等。

严重程度则是如果功能确实出现问题时，造成的影响后果。跟功能的使用频率；发生失效时能否被用户感知；对产品商务价值；对企业品牌的影响....等等。

基于这些尽可能丰富的维度得出一个风险评估值，在项目早期，就应该完成对各个功能测试点重要程度的打分，完成优先级的排定。

是否找到了灵丹妙药？

RBT的道理很清楚，但落地实践的时候，困难也很明确：就是这里的风险评估，不是单纯测试团队内部可以完成的，需要项目整体基于这个思路，在早期就开始基于这个模式尽可能充分地去进行风险的分析和评估，而且还需要在产品研发运作过程中，及时地动态调整风险。其中的投入，并不少。

而没有比较准确的风险评估，实际做下来，往往会因为风险未识别而导致测试遗漏。

所以RBT能保证回归测试的效率，但前提是前期的工作要做到位。

现实

回到现实，真出现题主这种情况的时候，风险其实已经很难规避。只能说尽可能按RBT的思想，根据经验，优先回归那些最关键的模块；另外根据对变更的理解，对可能关联的历史功能重点关照；

scope、time、cost三角，只能取其二；老板全都要，那就只能是尽人事，听天命！