也就是说用 flask 搭了一个 mock 服务器。
为什么不用 python 的 Mock 模块来做。

类似于 robot framework、testng、Xunit 之类的成熟框架都提供数据驱动功能，但你得自己用起来。
不会用的话请看用户手册或找教程，再搭配上一些调用接口的库就是你想找的所谓接口测试框架。

举例来说，楼主的这个就是 okhttp3（接口调用的库）+junit（成熟框架）。
你要的例子就是把他的代码重构一下，把数据和业务分离开来，
让测试人员写 case 和改 case 时需要写的代码量减少。

然后再加上各种你实际上需要的功能（比如你要分布式执行测试，比如你要 mock 一些接口，比如你要特定格式的报告或者把报告中的数据存到什么地方去做后续分析），就是比较好的框架了。

assert (delInnerString("111","11") =="1")
111 里面删掉 11 之后不再包含 11 了，中间这个 1 你能删两次？

核心能力最终还是技术能力，方法论能力太虚。就是这批人老搞虚的，所以被技术人员鄙视。近些年来从巨头们开始，拆散测试部门，减少测试人员，就是因为这批人太水。

能做工具开发，说明具备一定的开发能力。下一步当然是做开发了。凭什么有开发能力的人要被限制死在测试工具开发这么个不直接产生价值的范围内呢？继续提高技术做开发。

你们是给安排了社招任务吧。对你完成任务来说 jd 是不重要，对面试的人来说，想进的就不能多次面试失败。明显不符合的去面也是浪费时间，去年有次去了现场面试 5 分钟就知道根本不匹配他的要求，就算这么明显不符合他电话面试时也会给通过。你真要招人谈谈实际要求啊。

友情提示大家不要模仿。不吃主食损失的基础代谢，将会使你的体重反弹。即使一直不吃，也只会形成一种肌肉少脂肪也少，而食欲却很大的体质。真想减肥的，减脂增肌，科学规划，一定要吃主食，而且主食占比要高。

其实看不懂到底想要招什么样的人。

在表格中维护，给人一种画蛇添足的感觉。

直接招能写代码的人吧，哪怕少招几个。

回错人了，我并没有提问。我只是跟楼主说不理解他为什么要费九牛二虎之力解决一个不费力就能搞定的问题。

没看懂为什么需要这么庞大的架构来做一个 mock。

是不是直接写个小程序放在服务器上也能胜任？比如服务端就根据你请求的 url 不同直接返回不同的预先写好的结果。

你是想让测试人员通过你这个网站来自定义他想要的 url 的不同返回值吗……直接让他改 mock 的代码或者单独的数据文件不更方便吗。比如让测试人员在 git 上上传包含了 url 和预期返回值的数据文件，你的工具上再解析这个东西并存入数据库。这样前端就不用做了，数据库其实也不用做，直接读文件就好。反正只是个 mock。

反正我作为测试人员的话，宁可自己写小程序来实现...

不是说自动化程序出错，我是指你这个 “判断自动化检查点检查不了的东西的程序” 出错的时候，你怎么发现他出错了。

比如实际上这个点没 pass，但是你这个程序给出的输出是 pass，有没有可能出现这个情况，如果出现了，你怎样去发现？是通过对每次这个程序检查过的检查点做人工检查的方法来发现这种问题吗？

实际工作中我看到很多人实现了很神奇的自动化测试，却从来不会考虑这种测试本身有没有 bug，也不考虑如果有 bug 能不能发现。我也从别人的自动化脚本里找出过一些非常隐蔽，但会导致整个测试白测的 bug。绝没有给你挑刺的意思。

还是有个老问题，这个自动化测试程序本身出错的时候怎样发现？

先 ai 测完再人工检查一遍？或者是，直接认为这个程序不可能出错，而不需要再人工检查一遍？

这个就是靠经验推算。当然推算是不准的。

网上有淘宝的研究员对全链路压测的演讲，你可以看看。他们的第一个阶段就是推算阶段，遇到和你一样的问题，到第一个阶段最后也没解决这个问题。还设计了推算的算法，也没用，还是算不准。

这类框架的开发从来都不是问题，最终会出问题的地方就是维护。

版上问怎么写高效的测试用例的那位老兄应该看看这个贴。写详细的测试用例实在很过时了。

没错，明知没用还继续做，掩耳盗铃是测试界一大通病。

老式的测试用例设计已经过时，不过大多数人还在拒绝这一点。写出详细的测试用例本身注定了就是一个低效的活动。

bootstrap+jquery 能搞定。但是自动化测试平台并不好用，这种大 QA 时代的畸形产物只是用来刷 kpi 的。在一线的测试人员，一旦具备足够的开发能力，都会觉得这些平台非常恶心。

想说这种测试用例很难维护的。

首先第一步请把测试报告和 case 逻辑组织好一点，目标是达到：看报告时能一眼看出来是哪里 fail 和为什么 fail。

否则 case 数量一多，看报告的人要吐血。对，我就是那个看报告和不断吐槽其他人写的破 case 的人。就是上游写用例的人写得太粗糙，害我看 robot log 看得烦躁死。

一眼看不出哪里 fail，意味着要花力气分析。另外你的 robot case 就是一个线性脚本，看着晕。反映到 robot log 里，你的 log 里大部分东西都是测试人员不想看到的东西。

你完全可以使用 robot 的 template 功能来做数据驱动的 case，替代掉你的 excel。那个很丑的图形界面也可以用 pybot 命令行代替。

你发过去的异常值虽然不同，但处理逻辑相同，所以你得到了同样的返回值。实际上说明了你的那些数字都是同一个等价类的东西。

而接口的测试要对异常值测到什么程度取决于实际项目。你说的那些在有的项目里属于功能测试，在另一些项目里也可以划入安全测试。我们以前项目开发 api 给客户公司用，api 是待测产品本身，即使这样，我们仍很少测异常输入，因为默认网页开发不会去使用异常数据调用。

你引用的 library 里关键字重名了，用 库名.关键字名 这样写就好了。

没办法的，自动化测试的弊端大家都知道，就像是皇帝的新衣。不推自动化怎么来钱？

如果只为手工不遗漏，那么我又有几个问题：
第一，这个系统怎么判断需不需要加新测试用例来覆盖开发的代码改动。
第二，怎么保证这个系统的分析结果是准确的。当这个系统出现 bug，少推送了一个或几个测试用例时，该系统的用户如何发现。
第三，不管是手工还是自动化，都存在的问题，推送的测试用例版本滞后，无法执行，要先更新测试用例。
第四，用了这个系统之后，回归测试人员仍旧不敢在一个回归测试时只测系统推送的测试用例。因为 bug 可能不是来自代码，还可能来自环境。这个系统能检测这次部署和上次部署之间的环境差异，并告诉我们这个环境差异会导致哪些地方有风险，需要追加那些测试吗？

最后，这个系统打算做好后在什么场景下应用？在开发这个系统时，你们会在你这个系统上应用这个系统吗？也就是说，用你这个系统分析及这个系统的代码改动，并且所对应测试。如果你自己也不用，怎样使别人用？如果你自己也用，能分享下使用体验和效果吗？

测试用例如何维护？

如果测试用例是自动化的：开发代码改了，精准推送的测试用例一跑全 fail。测试心想可以报一大堆 bug 了，打开一看都是测试用例没更新导致的 fail。

手工测试用例？用这个辅助手工测试？
手工测试也要了解预期结果才能测。也就是手工测试人员先要拿到对应的需求吧。拿到了对应的需求直接就知道这个需求要用哪些测试用例覆盖了啊。