Selenium 写的自动化脚本（UI,接口）

testjson 9
2022-10-09 11:03:51 未知地区 10F
回复

嗯，我设计的确实这块问题很大，已经在重构了，打算封装一个基类 basepage 把启动浏览器，元素定位的类型，操作等单独封装起来

testjson 9
2022-10-08 12:35:30 未知地区 8F
回复

这是在测试用例里面的加的 log 日志，断言，用例成功后的截图

testjson 9
2022-10-08 12:31:27 未知地区 6F
回复

看了，你的回复，我先修改下 ui 自动化的测试框架，UI 的问题，你说的 1,2,3, 2 和 3 有做，但是还是有问题，1 我用的隐式等待和强制等待，觉得不太好，打算改

tester 9
2022-09-30 09:12:09 未知地区 4F
回复

脚本距离框架还有很长的路要走，要想做一个团队都能用的框架，至少要解决几个问题：1
1、用例去脚本化，比如 Excel、json 维护用例
2、入参数据解决，比如数据库依赖、接口依赖
3、断言问题与问题 2 类似
4、登录、加解密、验证码等项目非通用性问题
5、报告输出，不能光有简单的执行结果，还要统计接口数、覆盖率等更丰富的数据展示维度
共勉

陈恒捷 9
2022-09-29 23:23:19 未知地区 2F
回复

资料有点少，不好评价反馈，只能留点疑问，楼主可以看下有没有做好：
1、UI 自动化里面，框架是否有提供什么机制便于提高用例稳定性？（如找元素的自动等待等）
2、UI 自动化脚本的写法里，怎么尽可能让代码容易复用？（如 PageObject，从代码看有 Page 的概念，但不确定是不是用了 PO 模式）
3、一旦有报错，框架层是否可以捕获并输出足够清晰的日志等信息，便于使用者基于日志就可以定位并解决问题？

接口自动化：
1、一般接口自动化的特点是数量多，如果每一个都得写不少代码的话，编写维护成本会相对高。针对这块是否有评估过一个接口用例按现在框架写，大概要多久？
2、从这个截图看，有不少代码是为把报告输出到 allure 服务的。不确定这部分是不是用例，如果是，可以考虑下把这部分由框架直接代劳，而不用每个用例自己写？
3、类似 UI 自动化，接口自动化也有流程型的用例的，通过调用多个接口形成一个流程进行测试。不知道是否有考虑过脚本如何分层，让流程型用例和单接口用例，都能尽量复用一些公共代码，降低编写成本？
4、接口测试很多时候会需要测试多个环境，从脚本看像是从一个全局配置文件里直接获取 url 的，建议框架可以提供多环境分开配置的能力（类似 spring 里面可以分别为 dev 和 prod 设定不同的配置项对应值）。