好的

@Lihuazhang 目前我这个格式可以吗，用 markdown 语法不是怎么熟练。

markdown 的语法，真心玩不转

上午没有修改好格式就发了出来， 下午喝完药抓紧修改一波

坑

这么奇怪，

有报错吗？贴代码或者报错看看，是不是你用错了。这个说看不出来。

研发多测试人少，往往需求会叠加，产品新手，沟通不畅，导致到测试手里往往是多个叠加，老大有时候强压上线。我预估时间就会多加几天。传统的互联网公司就这样，哎。

我一般评估度，会确定本次修改内容，牵涉平台，对现有系统的影响进行评估，对 checklist 进行估算，一般每个测试环境 给 2-3 天的测试期，1-2 天的改 bug 期，依据开发预估的提测日期，给 2-3 的天开发缓冲期，测试后期留 1-2 天的延后期。不过在实践中，我发现，这个计算的周期会因为项目进度受影响，目前会上线出现加班通宵上线情况，主要在我们流程上面不完善，沟通不顺畅。临时会接很多别的临时的需求，加上产品新手情况，最近预估的十次有八次需要加班，沟通不畅。

谢谢建议，数据库我才用的是最简单方便的，表单处理上面会如果产生数据的交互才会触发，这个数据库迁移还是很快的，我在迁移到公司来说，这个 sqlite 满足业务需求，增加运维平台这里我感觉应该运维是一个单独的平台更好，UI 自动化的测试平台其实好做了很多，接口能做出来，做 UI 就不难，关键是需求，还有三个人并行开发的配合能力、。

我感觉两个场景都是可以实现的，目前没有加入进去这个，第一个场景 技术处理还简单，第二个 能实现，但是做出来也内部用行， 一般我做的 基于的都是通用的，类似你说的这种可以实现，但是不通用的，不能做到所有的接口都支持，只能是尽可能的去满足大部分的接口测试，迁移到公司用的开放平台都会二次开发，因为这些做的都是针对通用的技术比较多。

接口管理和接口用例这两个功能都不一样，依据接口管理的接口来写接口测试用例。一个管理接口，一个管理用例

注意，我这里说到的是接口，接口变动的相对于 ui 低，我也在力推接口。

可以的，完全可以实现。

业务流那是另外一种，我这种服务的是单独的接口测试，想改业务流的那种也可以。目前没有做到那一步。工具选择根据自己的业务和自己公司的情况来定，工具不是万能的，只能是大家一起努力让工具更加万能

我这里的接口都是保证接口测试的独立性。

没救了，网速

用例就是存数据库。json 支持的，你说的多接口传参什么意思。

后续可以研究研究优化进去。

Hdc 插件是什么，没了解呢，请指点

有些地方看是重复，但是有的地方的检验是必须的，优化后续再进行。

目前没有这个打算，后期可以优化

Bootstrap

继续努力。

不难吧