登录接口前面加依赖接口(不同的验证的前置接口)就行了,不管是同一项目,还是不同项目,
不存在兼容问题,不同的接口,用不同的验证机制,如有些要 token .有些要签名,不同的接口,用不能的验证方式就行。没看懂你的问题,认证可以是全局配置,也可以是接口间依赖来解决
投入 4 个人月,致少 10 W 的成本没了,效果如何还不好说
要想降本增效,降低使用门槛,对测试小白友好,只对 jmeter 包个 WEB 没用的,不如直接原生的 jmeter , 要降低门槛 ,就得可以录制,加拖拉方式设置断言,以及参数提取,然后通过可视化拖拉方式编排接口业务场景。如下图这种
还有可能,https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议 我这里写的,对小白友好,
接口测试可以看看 https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议
非常中肯又很有建设性的建议。目前只是增加了根据 swagger url 同步,postman ,jmeter 的导入, 且也支持通过编码,写插件,以及断言等,只是是 JAVA 的;商业版我们有开放平台,实现对外 API 开放对,除此之外正在实现 web hook 机制 方便和第三方系统互动,现在和 jenkins 是联通。 后续还有很多要改进的地方,一直在不断优化。 您的建议,我们最终都会实现
手动点赞
很充实,向大佬学习
很不错,乐见百花齐放
一年搬几 W 块砖,还是要把重复的事工具化,只要提升工作效率,工具就有价值,KPI 导向的除外
是的,让大家来开发插件,不过插件要好用 如果只是插上来一堆工具集,没打通,就不得行
线上登录页下面有帐户密码,可能您上次登录时,发新版,马这注掉了 ,现在是 OK
非常不错的回复,共同点非常多,只对这一句个有点稍微不同的看法" 个人认为平台的作用更应该关注重管理轻业务 "
重管理没错,业务也要有,不过难两全,业务侧主要是方便使用的人,管理不是天天用平台的人。我个人的看法是,首先不要增加在平台上办业务的人的负担,简单好用,同时,又能从多个维护为管理提供全面的支撑数据,把流程性的东东,在平台中标准化,融入到业务中,不能太僵化,不过要做好真的很难,只服务自己公司的平台还好办,做一个能产品真的很难做好,只能说尽量用一些通用的原则。
itest work 也不错,自动推导接口依赖关系,2 个 G 内存 ,一核就 OK ,安装也简单,一键完事,升级也是一键完事,发版本很快,重点是免费的
还有接口调用链
详见 https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议
对于测试平台同样道理,测试人员的体验且工具是要提效,不是增加负担的。
研效改进的致命陷阱:忽略开发者体验 https://mp.weixin.qq.com/s/DylM-QNloraY0MQzL6oUyw 非常认同这个,总结得 很好,出自 thoughtwork 大师之手,
我是说做私单的这种心态,需求没评估好,就要赔钱 ;都报着,需求不是我的事,出错了也不是我的事,这肯定做不好! 不是卡严是挖掘出真正的需求,不是说需求不能变,变再走变更,但第一版需求,要讲清里面的业务,以及隐含量的业务逻辑是什么样的,不能等实现时,开发人员,有不同理解。定好了,开始 DIE 代,有变更走变更。
我分析需求时,我都是假设这个是私单,我来实现,要是我评估不对,工作量就偏差太多,我报价就不准,我接了就赔钱,带着这 态度去做,没有做不好的,
我觉得要提前拿到需求,然后对需求发散提问(拉个单子,找产品对需求一一确认,经过两轮,需求质量就高得多),都解决了,再来设计用例和评审,要不原始的需求就不清不楚,后面评审出发现不了太多的隐含的逻辑问题,
测试平台的架构足够好, 满足好维护,好扩展的话,可随业务再加新功能,或是更改原有功能 。可随项目开发模式,架构因变而变,这就需要测试平台有一个好的架构师来设计底坐,只是测试开的水平,来做平台这就可能难办。
用平台吧,web 脑图,以及标准用例都支持且可转换 如下图
且还可以导出来,在线下,执行, 修改,新增后,再同步回系统
增加了接口测试场景执行时的调用链
又补充了第 6 点
我们一直在改进的路上,基本上周周发版,都是按用户的的馈改的。本周增加一个小功能 swagger 导入且导入时,按参数类型自动设置值,后面我们录制功有要作,且回放时,自动在所在参数后加随机数