但是如果自动化脚本也存在大量需要解藕和复用的关系，是否是自动化测试方案设计有问题？

这句话我一直想说的，我现在入职一家公司，接手之前外包出去做的整个测试框架，关键是 920 条 case(rpc\ws) 代码量 3.5W 行

通常发生这种情况，就是在做的是 “测试自动化”，920 条 case，有多少是存在重复的呢？这种重复，从测试目的来说是真的必要的么？

被测系统对业务建模，测试被测系统不仅需要对业务建模，还需要对业务的系统进行建模，所以真实的自动化不比业务简单，对于传统的用例脚本方案设计，多数是对业务被测要素，行为操作进行抽离，需要依赖人为去构造测试案例。以此进行上升应该是对领域模型进行抽离，元素依据被测模板生成，测试用例按照被测元素节点以及领域行为生成，能够做到后者的 应该少之又少吧。

脚本没必要，基础框架得要。自动化用例一般也就业务耦合，框架把常见业务提取出来就行。设计模式主要是让自动化测试易于维护，比如改个东西啥的，好改你的脚本。要是做了永远都不变，引不引入设计模式，说实话好像也没有那么必要。

常常会忘记了测试的原本目的

所以感觉是否引入设计模式，本质还是看自动化测试方案是怎么设计的。

其实并不会，很多年前我也有你这类的想法，认识系统的本质，追求卓越的技术最终落地是以品质为中心的，只是它代替了人为而以更高效更稳定的方式执行。产生这样的想法也许是你认为当前某些黑盒因素是技术无法取代的，就像当年手工工艺者一样 认为机器的出现不会做的比手工工艺更精细，而事实证明目前机器所带来的精细化远超手工劳作预期

可以不用，但是如果你的项目频繁变动，你需要经常维护的时候，我建议还是对整个测试框架的设计重构一下。比如 Web UI 里面的 POM 模式，比如 httprunner 在 2.x 重构后的分层机制，这些都是为了方便后期的维护迭代，以及对复用部分的高度封装。

用感觉还是要用，但感觉有一个平衡点的问题。个人更倾向于优先从测试方案上进行调整，感觉这样子人力成本也降到最低

纯小白那会，自己搭建简单自动化架子，代码分层少，到处是硬编码，函数复用性低，使用的设计模式也少，更像是在堆叠。。。
现在再搭建自动化脚本框架，有时就会纠结封装颗粒度，复用性和通用性，调用方式是否优雅。
每次明明知道这些优化没有增加自动化脚步测试的价值，但是还是会去做一些优化😂

用例间闭环式的解耦或者其他解耦方式是基础，只有先解耦才能分层。
自动化如果用单元测试框架后，能用设计模式组合基本也是比较固定的几种。

先解藕才能分层，这个说得好。比较固定的几种设计模式是什么呢？

这种优化可以体现技术价值吧，我们原来 3 个人完成 50 个应用的脚本编写，就只能是从方案上去耦合，使得脚本独立彼此之间功能无交集

这篇文章写得挺好的，不知道有没有同样从测试方案角度探讨这个问题的？

曾经用过 BDD+PO，其中的用例函数其实是通过动态加载得到的，所以你在编写用例的时候无法得到 BasePage 对象，里面的方法也需要你去手动打出来。
更烦的是，随着编码量增加，复杂度的增加，大家都会在 BasePage 对象里面加很多自己的实现，反过来就是说，这个模式的扩展其实都是在 BasePage 里面的，所以这个类只会越来越大，优化上其实应该增加一个层级，但是也是治标不治本。
还有里面提到的维护性，这个的可维护性仅仅解决的是分层的维护性，UI 测试本身最根源的不稳定性带来的维护成本是没有降低的，不要偷换概念。
感兴趣可以玩一玩，个人观点。

“UI 测试本身最根源的不稳定性”——哈哈，这让我想到了那个经典的测试金字塔了，我更多时候会去想一下，为什么要堆这么多脚本，有那么多重复的功能在不同的场合去测这个测试方案为啥要这样设计用例？

UI 测试主流程足以，设计模式不是必需品。不如多想想怎么提高稳定性。写一段逻辑复杂的 UI 测试，重复跑 1000 遍并录视频，分析其中的所有错误，你就会知道该以何种方式提升 UI 测试。