思考一个问题：
做产品功能开发使用设计模式，本质上应该说是解决：解藕和复用的问题。
但是如果自动化脚本也存在大量需要解藕和复用的关系，是否是自动化测试方案设计有问题？
如果在公司是不主导测试方案设计，而是只负责方案实现，感觉可以理解模式的使用。因为脚本编写的人员不知道自己需要
实现什么样的脚本，也无法预知后续方案迭代的变化。就像做功能开发的人员，不知道后续产品的变化一样
但如果是做整体的解决方案，个人比较倾向于，方案设计和脚本实现都是整体的
在做测试方案设计的时候，应该要尽量避免掉用例间存在交叉和关联，也就减少耦合部分。这样在脚本实现上也会更加简单，成本更低
UI 测试主流程足以，设计模式不是必需品。不如多想想怎么提高稳定性。写一段逻辑复杂的 UI 测试，重复跑 1000 遍并录视频，分析其中的所有错误，你就会知道该以何种方式提升 UI 测试。
Karaser
回复
“UI 测试本身最根源的不稳定性”——哈哈，这让我想到了那个经典的测试金字塔了，我更多时候会去想一下，为什么要堆这么多脚本，有那么多重复的功能在不同的场合去测这个测试方案为啥要这样设计用例？
曾经用过 BDD+PO，其中的用例函数其实是通过动态加载得到的，所以你在编写用例的时候无法得到 BasePage 对象，里面的方法也需要你去手动打出来。
更烦的是，随着编码量增加，复杂度的增加，大家都会在 BasePage 对象里面加很多自己的实现，反过来就是说，这个模式的扩展其实都是在 BasePage 里面的，所以这个类只会越来越大，优化上其实应该增加一个层级，但是也是治标不治本。
还有里面提到的维护性，这个的可维护性仅仅解决的是分层的维护性，UI 测试本身最根源的不稳定性带来的维护成本是没有降低的，不要偷换概念。
感兴趣可以玩一玩，个人观点。
这篇文章写得挺好的，不知道有没有同样从测试方案角度探讨这个问题的？
用例间闭环式的解耦或者其他解耦方式是基础，只有先解耦才能分层。
自动化如果用单元测试框架后，能用设计模式组合基本也是比较固定的几种。
纯小白那会，自己搭建简单自动化架子，代码分层少，到处是硬编码，函数复用性低，使用的设计模式也少，更像是在堆叠。。。
现在再搭建自动化脚本框架，有时就会纠结封装颗粒度，复用性和通用性，调用方式是否优雅。
每次明明知道这些优化没有增加自动化脚步测试的价值，但是还是会去做一些优化😂
可以不用，但是如果你的项目频繁变动，你需要经常维护的时候，我建议还是对整个测试框架的设计重构一下。比如 Web UI 里面的 POM 模式，比如 httprunner 在 2.x 重构后的分层机制，这些都是为了方便后期的维护迭代，以及对复用部分的高度封装。
青谷
回复
其实并不会，很多年前我也有你这类的想法，认识系统的本质，追求卓越的技术最终落地是以品质为中心的，只是它代替了人为而以更高效更稳定的方式执行。产生这样的想法也许是你认为当前某些黑盒因素是技术无法取代的，就像当年手工工艺者一样 认为机器的出现不会做的比手工工艺更精细，而事实证明目前机器所带来的精细化远超手工劳作预期
脚本没必要，基础框架得要。自动化用例一般也就业务耦合，框架把常见业务提取出来就行。设计模式主要是让自动化测试易于维护，比如改个东西啥的，好改你的脚本。要是做了永远都不变，引不引入设计模式，说实话好像也没有那么必要。
被测系统对业务建模，测试被测系统不仅需要对业务建模，还需要对业务的系统进行建模，所以真实的自动化不比业务简单，对于传统的用例脚本方案设计，多数是对业务被测要素，行为操作进行抽离，需要依赖人为去构造测试案例。以此进行上升应该是对领域模型进行抽离，元素依据被测模板生成，测试用例按照被测元素节点以及领域行为生成，能够做到后者的 应该少之又少吧。
但是如果自动化脚本也存在大量需要解藕和复用的关系，是否是自动化测试方案设计有问题？
这句话我一直想说的，我现在入职一家公司，接手之前外包出去做的整个测试框架，关键是 920 条 case(rpc\ws) 代码量 3.5W 行