excel 在线转 xmind：因为测试都是用 excel 写的 case .
都用 excel 写了，要是我实现，我根本不转，就是存标准的用例，只是显示时加一个脑图显示模式完事 ，然后转换为 png 的图，再插入回 excel

你要是限定在河北石家庄 , 这都不算二线，为什么不看看，其他二线呢，

1：关于老是接口变更，如果接口是基于 swagger 的还好，可以有技术手段，同步到接口测试用例中
2：接口最好是基于录制来生成，省些事
3：维护接口的成本高，如果支持断言，参数提取拖拉，再加上有调用链，还是方便多了
不过不稳定期，不要忙着上接口，相对稳定了，再来做接口测试，维护量小得多
可以看看我写的这个https://testerhome.com/topics/30495 ，里面有些东东，可能有些用

用 shell 的里 sed 去 改

严重同意

成都测试圈 也还行吧，要不是有疫情，我们也搞一些沙龙，18 年搞了一次，20 年也搞了一次，看来你没找到成都的测试组织 呵呵

itest work 测试用例管理，缺陷管理，接口测试都有

非常不错

登录接口前面加依赖接口（不同的验证的前置接口）就行了，不管是同一项目，还是不同项目，

不存在兼容问题，不同的接口，用不同的验证机制，如有些要 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 代，有变更走变更。