有两个极端:
- 对代码进行任何更改后测试整个系统。
- 根本不要测试。
在“测试”下,我的意思是运行所有非自动化测试。更精确的用户验收测试。
当不执行手动验收测试绝对安全时,我想有一个扎实的理解。
我相信 100% 的代码覆盖率在这里是不够的。
有两个极端:
在“测试”下,我的意思是运行所有非自动化测试。更精确的用户验收测试。
当不执行手动验收测试绝对安全时,我想有一个扎实的理解。
我相信 100% 的代码覆盖率在这里是不够的。
好吧,看来您混合了术语。破坏系统的行为并不意味着系统没有通过验收测试,如果您对性能、视觉或用户体验有要求,您也可以在不破坏系统的情况下破坏 UAT。
如果你在谈论回归——之前通过的 UAT 仍然会通过,那么它们应该尽可能地自动化。QA 总是有针对不同环境的回归测试计划,它们甚至可以自动比较不同分辨率的屏幕截图,例如在 facebook 中。
如果您正在谈论新功能并且它是 UAT,那么您可以在实施之前对其进行形式化和自动化,例如黄瓜方法。
另一种方法是对用户进行测试,例如 yandex 或邮件。你向用户展示,或者公司员工知道版本,如果你不收集错误,或者抱怨,你可能没问题。但这不是你每次提交都会做的事情,如果它是一个 ap 或桌面应用程序,事情会变得更加棘手