为什么不直接像 jmeter 那样,直接在断言中写 SQL 呢,写是把 SQL 变为一个服务 (接口),主要是为了重用
itest 如果你需要到数据中验证,你可以通过 itest 的 api 生成功能。建好数据源后,写 SQL 就行,sql 变为服务 (接口)。然后在你需要在接口测试中, 写一个接口用例,然后不管是执行完要验证数据,还是执行前,从 DB 中提取数据 都 OK ,引用这个 接口用例的数据就行了
我们都实现了,自己实现的 。之前也是找开源的,没找到,所以自己写,搞了一年,现在基本上完事了。在最后的测试阶段
先写用例,在写用例的时候,你只要存在参数引用,就是存在依赖关系,如 A 接口,引用了 B 接口提取的参数,或是 A 接口引用了 C 接口取到的 token 也算是存在 依赖 。然后我反推出来,和调用链不太一样的
不管如何同步,还是没解决,怎么接口又变了,这里的同步,只是同步了接口的变更,前端要是按之前的返回数据做的响应,如果数据结构变了,前端能不改?
fixed
谢谢指正,确实是,马上改
你好! 你这问题和本贴要表达的没一分钱关系。 如果你硬要曲解 一站式为一统江湖,只能表示无话可说!汽车的 4S 都有丰田家的,本田家的且还有众多的专修店的存在,就算有 6S ,10S 专修店也一样会存在。一统江湖我认为是狂妄的想法,且很不现实。
"目前 itest 上面集成接口测试之后,就把自己限制在很小的一个 web 接口测试范围了 " 人是活的,工具是死的,从来没有人被工具限定
实际不乱,建项目时,选择的是一站式模板,可以改的,接口测试,就看不到手工测试的东东了,后续我们可以让用户制制显示的页面 ,他关注什么,显示什么,不关注的功能,他看不到。
关于接口测试,免费版就只做 HTTP 的,后续可能有 RPC 的,GUI 现在及将来也不会碰,性价比低。后续 CD CI 集成以及代码扫描都要实现
什么都想干反而可能搞不好,就算想都做,最好把自己的平台做成一个工具集,可选的插入式集成。这个建议非常好,免费版这个不改的,正在实现的商版是这样做的
我就欢迎这种平台,乐见百花齐放
调用接口时,制造混乱,也是混沌的概念呀,叫接口混沌测试有何不妥
造据数据是强业务,没法做成通用的
之前也可以用,只是后置插件你要自己实现,这前手册没写这 如何用,后续手册中我们写详细 点,下周的版本,你就不用写只要写 SQL 就行,我们自动把他当成一个插件(但是你一行 JAVA 代码不用写),然后调完接口 A,再调这个服务就行,后续通过这个服务来检查,如果你想在 A 接中后就检查,还是要写插件,在插件中,调用这个服务
DevTestOps
打错了是说 我们实现方式和 其他不同,上面不是能
这个刚开发完,下周就 OK 了,我们实现方式和 其他不能,数据库校验做成一个服务,SQL 你自己写,以插件形式,插进来,我们后置来调用
非常中肯的评论,共识多多
您提的调试提醒了我,后面我在上传插件后,加一个测试 ,输入相关数据,可以测试插件本身, 在测试时,单独把这个测试线程的日志写为一个独立文件,可下下来看。
插件化后,调试确实是一个问题。后续,这块我们文档补充全,只要按文档来,我们来回调,对使用者来说就是个回调函数,目前这块文档还没写得很细。
这个回复打 100 分 哈哈
维护慢就是平台维护的问题了,而不是平台没有用 。本质上还是投入产出,看哪个合算
我就是感于之前的讨论,觉得我要说些什么
没太明白你的意思,itest work 中,A 接口提取了响应数据中的 某个值取名为 A ,这个 A 是不能重或的,,别的接口只是引用,和 key 没关系呀, 不同的接口,KEY 可能是 name ,等,我们不关记他的 Key ,只关心,他引用的变量。如下图,第一个图和第二个图都引用了 packageId 这个变量,和 key 无关呀。不知你说的 key 是参数名不,且我们支持 XXX.XX.XX 这种对向属性的 key
接口间只要存在参数引用 事实上就存在依赖关系,然后就可以推导出来了