一年搬几 W 块砖，还是要把重复的事工具化，只要提升工作效率，工具就有价值，KPI 导向的除外

是的，让大家来开发插件，不过插件要好用 如果只是插上来一堆工具集，没打通，就不得行

线上登录页下面有帐户密码，可能您上次登录时，发新版，马这注掉了 ，现在是 OK

非常不错的回复，共同点非常多，只对这一句个有点稍微不同的看法" 个人认为平台的作用更应该关注重管理轻业务 "

重管理没错，业务也要有，不过难两全，业务侧主要是方便使用的人，管理不是天天用平台的人。我个人的看法是，首先不要增加在平台上办业务的人的负担，简单好用，同时，又能从多个维护为管理提供全面的支撑数据，把流程性的东东，在平台中标准化，融入到业务中，不能太僵化，不过要做好真的很难，只服务自己公司的平台还好办，做一个能产品真的很难做好，只能说尽量用一些通用的原则。

itest work 也不错，自动推导接口依赖关系，2 个 G 内存 ,一核就 OK ,安装也简单，一键完事，升级也是一键完事，发版本很快，重点是免费的

还有接口调用链






详见 https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议

对于测试平台同样道理，测试人员的体验且工具是要提效，不是增加负担的。

研效改进的致命陷阱:忽略开发者体验 https://mp.weixin.qq.com/s/DylM-QNloraY0MQzL6oUyw 非常认同这个，总结得 很好，出自 thoughtwork 大师之手,

我是说做私单的这种心态，需求没评估好，就要赔钱 ；都报着，需求不是我的事，出错了也不是我的事，这肯定做不好！ 不是卡严是挖掘出真正的需求，不是说需求不能变，变再走变更，但第一版需求，要讲清里面的业务，以及隐含量的业务逻辑是什么样的，不能等实现时，开发人员，有不同理解。定好了，开始 DIE 代，有变更走变更。

我分析需求时，我都是假设这个是私单，我来实现，要是我评估不对，工作量就偏差太多，我报价就不准，我接了就赔钱，带着这 态度去做，没有做不好的，

我觉得要提前拿到需求，然后对需求发散提问（拉个单子，找产品对需求一一确认，经过两轮，需求质量就高得多），都解决了，再来设计用例和评审，要不原始的需求就不清不楚，后面评审出发现不了太多的隐含的逻辑问题，

测试平台的架构足够好， 满足好维护，好扩展的话，可随业务再加新功能，或是更改原有功能 。可随项目开发模式，架构因变而变，这就需要测试平台有一个好的架构师来设计底坐，只是测试开的水平，来做平台这就可能难办。

https://www.oschina.net/news/156397/itest-10-1-4-released 35 楼说的对，
官网 http://www.itest.work/itest/ 可下载

用平台吧，web 脑图，以及标准用例都支持且可转换 如下图


且还可以导出来，在线下，执行， 修改，新增后，再同步回系统

增加了接口测试场景执行时的调用链

又补充了第 6 点

我们一直在改进的路上，基本上周周发版，都是按用户的的馈改的。本周增加一个小功能 swagger 导入且导入时，按参数类型自动设置值，后面我们录制功有要作，且回放时，自动在所在参数后加随机数

为什么不直接像 jmeter 那样，直接在断言中写 SQL 呢，写是把 SQL 变为一个服务 (接口),主要是为了重用

itest 如果你需要到数据中验证，你可以通过 itest 的 api 生成功能。建好数据源后，写 SQL 就行，sql 变为服务 (接口)。然后在你需要在接口测试中， 写一个接口用例，然后不管是执行完要验证数据，还是执行前，从 DB 中提取数据 都 OK ，引用这个 接口用例的数据就行了

我们都实现了，自己实现的 。之前也是找开源的，没找到，所以自己写，搞了一年，现在基本上完事了。在最后的测试阶段

先写用例，在写用例的时候，你只要存在参数引用，就是存在依赖关系，如 A 接口，引用了 B 接口提取的参数，或是 A 接口引用了 C 接口取到的 token 也算是存在 依赖 。然后我反推出来，和调用链不太一样的

不管如何同步，还是没解决，怎么接口又变了，这里的同步，只是同步了接口的变更，前端要是按之前的返回数据做的响应，如果数据结构变了，前端能不改?

fixed

谢谢指正，确实是，马上改

你好！ 你这问题和本贴要表达的没一分钱关系。 如果你硬要曲解 一站式为一统江湖，只能表示无话可说！汽车的 4S 都有丰田家的，本田家的且还有众多的专修店的存在，就算有 6S ,10S 专修店也一样会存在。一统江湖我认为是狂妄的想法，且很不现实。

"目前 itest 上面集成接口测试之后，就把自己限制在很小的一个 web 接口测试范围了 " 人是活的，工具是死的，从来没有人被工具限定