有没有办法证明改变后的实现不会引入回归?

时间:2016-01-22 12:20:29

标签: testing user-acceptance-testing

有两个极端:

  • 在更改代码后测试整个系统。
  • 根本不要测试。

在'测试'我的意思是运行所有非自动化测试。用户验收测试更精确。

我希望在不进行手动验收测试绝对安全的情况下有充分的理解。

我认为100%的代码覆盖率还不够。

1 个答案:

答案 0 :(得分:1)

好吧,似乎你混合了条款。打破系统的行为并不意味着系统没有通过验收测试,如果你有性能要求,或者有一些视觉或用户体验的东西,你也可以在不破坏系统的情况下破坏UAT。

如果你在谈论回归 - 以前通过的UAT仍然会通过,而不是应尽可能自动化。 QA总是有针对不同环境的回归测试计划,他们可以自动化甚至比较不同分辨率的屏幕截图,比如在facebook中。

如果您正在谈论新功能及其UAT,那么您可以在实施之前将其正式化并自动化,例如黄瓜方法。

另一种方法是测试用户,例如yandex或邮件。您向用户展示,或公司员工知道版本,如果您不收集错误或抱怨,您可能会很好。但是,这不是你将为每次提交做的事情,如果它是一个ap或桌面应用程序,事情会变得更加棘手