标签: 回归测试

哪一种测试方法能更好地检测软件修改中的bug ？ 来看看 回归测试与背靠背测试的比较 吧 定义 ISTQB将回归测试定义为对已经测试过的程序或修改后的部分功能的重新测试。其目的是证明没有由于所做的更改而引入错误状态或以前掩盖的错误状态暴露。 ISTQB将背靠背测试定义为通过对所有变量执行相同的测试用例并比较结果来比较被测系统的两个或多个变量，或者相同被测系统的仿真模型。 这两种动态测试方法之间的主要区别是测试资料库的类型。测试资料库是测试用例成功的评估基础。 在回归测试中，评估基于从需求中得到的预期结果。在背靠背测试中，预期结果是与另一个软件版本相同的行为。 在我们看来，如果想要做出或确定关于函数行为的声明，那么回归测试是合适的。如果测试与需求联系在一起，那么功能和需求中的bug就可以被清晰明确地分配和评估。 持续集成和持续测试(CI/CT)环境代表了回归测试的自动化。在大多数配置中，基于更改执行每天的测试。通过CI/CT构建计划，只执行对产品有影响的测试。 当参考内容，例如软件的原始版本高度可信时，背靠背测试是非常适合的。当从模型生成代码时，就会出现这种情况。如果模型已经经通过了广泛的测试，则给出了较高的置信度。 在实践中，特别是对于浮点运算中的转换，背靠背的测试设置可能是具有挑战性的，例如，当将模型转换为C代码时 。 乍一看，设置公差似乎很简单。 当信号级联时，错误会传播，必须重新考虑将最小有效位(LSB)设置为容差值。如果选择的公差太小，测试将出现错误并失败。如果选择的公差太大，测试总是通过，背靠背测试就失去了意义。因此，正确的设置在技术上成为一项艰巨的工程任务。 总结 在TPT中，可以同时执行回归测试和背靠背测试，并且可以在一次执行中结合这两种测试方法。 我们建议测试经理在选择测试方法并做出一个有意识的决定之前，通过进行他们自己的调查，从努力和利益的角度检查操作的适宜性。