频繁变更的UI自动化测试如何界定测试边界 杂记
Author：zhoulujun Date：
自动化测试的主要优点：它能够在数小时内完成原本需要数天甚至数周的手动测试工作；它可以无限次数地重复执行，确保了回归测试的全面性；此外，它还能持续运行，实现夜间和周末的不间断测试。
但并非所有测试案例都适合自动化，例如，在处理视觉相关的UI测试、尚未稳定的应用程序界面或需要人为直觉判断的测试案例时，自动化可能不是最佳选择。在这些情况下，过度依赖自动化可能导致结果不准确或产生误导。
如何确定需要自动化测试？
确定哪些测试适合自动化，首要考量的是测试案例的稳定性和重复性。通常，那些稳定且反复执行的测试案例是自动化的理想候选。
例如，针对核心功能的回归测试、接口测试以及性能基准测试等。而一次性测试、探索性测试或需求频繁变更的功能则更适合手动执行。
需要考虑自动化的可行性
这包括考虑测试案例的复杂性、所需资源（如时间、人力和技术）以及潜在的回报。
如果一个测试案例自动化的成本高于其带来的收益，那么选择手动测试可能更为明智。
其次，自动化测试的成功实施依赖于稳定且测试工具、框架和脚本。缺乏这些技术支持，自动化测试难以发挥其应有的效能。因此，在投入自动化之前，必须确保相应的技术基础设施已经就位。
前端自动化认为应该有限量
项目一开始不引入测试，CI，CD，后面补起来的可能为零，或者代价更大。就跟盖楼一样，楼做起来后，发现地基不行，再想补救难。
但是项目前期，项目肯定是需求频繁变更，界面 UI 还不稳定，还在尝试不同的调整，而且调整都是比较大的，这事对前端做自动化收益小于成本。
但是，这不是不能完全不做前端自动化测试相关的架构工作——无论什么时候，都应该是大量的做单元测试，大量的做 API 自动化测试，根据具体项目情况，少量或中等强度的做前端自动化
只是UI层面的，可以暂缓。需要合理地限量边界！
如果项目已经比较稳定，或者本来就是一个比较稳定的界面；且软件维护周期长，有生命；被测系统UI设计较为规范，可测试性强
需求稳定不频繁变更；需要频繁的回归验证；UI 界面稳定、界面控件定义规范可测试性强；开发维护周期长的项目；项目进度压力小；大型公司大平台；测试部门中大部分测试人员具备脚本开发能力。
比如工具类的 APP，UI 一般都是小调整，变更不会频繁，这种时候可以比较大量的做前端的自动化
项目如果遇到下面3条中的一条，其实前端自动化可以放过
需求不稳定，频繁变更的项目
开发维护周期短的项目
被测系统开发不规范，可测试性需求不明确
质量度量
质量度量分为三个阶段，分别是：
需求设计质量；
研发过程质量；
用户使用质量；
通过各种测试技术手段多维度去验证软件是否符合预期，都是验证和保障交付质量的手段。而流程规范、度量标准，也是为了保障最终的交付物达标。
参考文章：
如何设计自动化测试case？ https://www.cnblogs.com/imyalost/p/16492574.html
转载本站文章《频繁变更的UI自动化测试如何界定测试边界 杂记》,
请注明出处：https://www.zhoulujun.cn/html/Operation/test/2022_0901_9183.html