有变动， 才能体现出自动化回归的价值。
至于变更频繁，建议做好代码的结构化，接口参数尽量做到配置简单化，通过配置来维护接口的参数，就可以减少代码的维护量。

一种方式是让开发增加接口，而不是改原来的. 如果是已上线的产品的话，否则客户端老版本怎么办？ 要强制升级么
如果频繁，就别自动化，不适合

接口列表维护

1.维护一套内部已有的，和为了测试而开发供给的接口。
2.同 1 个链路的行为写在一个接口列表内。其他单个测试验证的接口做解耦。
3.根据接口数据格式用配置去填充。支持公共方法去解析全部数据结构。（这个不复杂，最难也就是 1 个 XML 了。。）

接口返回精准匹配

1.接口内部修改会影响了接口返回。判断接口成功取 msgid（msgid 可以通用所有协议），取核心的关键字，如果缺少可约定生成。
2.接口返回不用全部匹配，取正则形式和截取接口的关键字拼装。

话说，接口经常变动的话，更痛苦的应该是客户端开发吧，而且版本不保持兼容吗？新出一个版本抛弃上一个版本的用户？

目前只做 B/S 产品，不涉及客户端。接口前期没有设计好，有新特性或新需求来的时候，开发会把以前的接口作相应的修改。我们自动化测试人员就凄惨了撒。

之前的产品都是用 python 封装的关键字，较小的变更还是能适应的。 但是较大变动就吃力了。

是的，自动化适合用来做回归。我们目前处于新产品开发阶段，本来不适合自动化，但是老大说搞，让我比较彷徨。

参考格式：
url = 'http://localhost:8080/sign_in'
paras = {username:namea,password:passa}
signList = {username,password}

def sign(signList):
// 签名算法

def post(url,paras):
// 发送数据，校验

其中方法都是通用的，只是发一个请求，不会变动；
接口有变动时，对应改 url、 paras 、 signlist 这些信息就可以了，感觉工作量不会很大。

可行

公司缺失架构，没有规划整个软件的开发流程，说白了，不停的返工。这个锅是研发老大的锅。