我先测了

接口平台二次开发，首先给用例列表新增url展示列，我们知道httprunner工具的结构，接口请求地址是在testcase中，它是一个json对象或yml格式存储，原作者也没有在表结构中新增url列，故而也没有展示，所以需要咱们自己二次开发来给平台贴砖加瓦；再者，既然有url、也有用例名称，那么搜索功能既要也要。

看着如此简单的操作，是不是觉得自己也会了呢，当拿到一个开源项目之后，尽量慢慢的一点一点的蚕食，不要让它和自己一点关系也没有，只有注入了自己的血液，那么它就不是纯粹的别人的东西。日拱一卒无有尽，功不唐捐终入海!

虽然咱给HttpRunnerManger引入进来了，但作为公司提升测试效率的管理平台，也不能放任它不管，在不同人的使用下，多少还是有些区别的，譬如注册，它的错误提示竟然是绿色的，咱不能忍，还有它注册时没有过多校验，譬如长度限制、唯一键值等等，所以咱们需要给他改改颜色，优化优化！

随着平台使用时间的推移，数据量也会越来越多，用例列表前面说了，不大适合一删了之，但是测试报告呢？这个虽然也没有什么大不了，但毕竟那么多页面，也是需要腾出来点地方，毕竟它的作用不是很大，在每次使用过后就不需要了；尤其是在调试的时候，它产生的报告不需要储存，所以需要删除，而且需要支持批量删除。

参数化：在使用httprunner框架的时候，参数化说实在的不是很实用，因为更多是场景化的用例编写，不需要用过多的参数去批量执行(毕竟单接口的用例更多在测试环境执行)，无非也就是登录注册查询啥的，在生产环境就不是很建议这样玩，单接口是可以覆盖的，毕竟这是httprunner最核心的体现。

日拱一卒无有尽，功不唐捐终入海！多一点思考，会少走弯路，这个功能在很多时候都是受用的，维护用例本来就是需要花费成本的，所以不能简单的一删了之，毕竟存在即合理。那是不是又需要扩展一个功能？什么功能？那就是对用例状态的筛选，哈哈~~~这个功能就留给同学们自己去实现吧！

终归是在别人的系统上二次开发，对于原本相同的操作，总是会出现不同的位置，这样对于改造来讲，会增加一定的难度，好在前面已经有些经验，改起来也算是轻车熟路。不管怎么说：日拱一卒无有尽、功不唐捐终入海！

报告列表已经展示了很多信息，但是接口测试平台，需要统计每次执行套件的结果，以体现它的价值，比如总共执行了多少次，每次有没有发现问题，这里的问题是指：有没有发现合并代码的问题导致原来的业务出错，又或者遗漏了sql未执行而导致的错误；那么对于每次都pass的结果报告，自然不需要过多描述，但是测试不通过的报告，需要有说明找到原由，必然是会去检查对应的业务接口，然后去验证是为什么错了，如果是因为脏数据，那么就需要备注说明它不是很重要，如果是因为程序错误(sql未执行)则需要记录它的次数，表现出它的价值。

其实对于这些小功能的改造和优化，都是为了方便更好的使用这个平台，提审使用它的效率，从而对于测试的效率就会提升；有效的记录每次执行结果并进行分析，跟踪反馈。日拱一卒无有尽，功不唐捐终入海！

但是这里改了之后，有点显傻，Jinjia2库是第三方的，能改到这里会破坏原来的逻辑，要是在其他生成html报告的时候会不会报错，这就不敢保证了，需要咱们一起往下走，发现框架的report报告模板可以修改，在这个平台中，框架是内嵌在平台里的并不是直接引用第三方库，这样做的好处就是支持定制化修改。卷了，不管在哪个行业哪个岗位，都需要一技多长，可以做的慢、丑，但不能不会，所以时时刻刻要有学习的动力，需要会的能力。针对以上问题，需要在本地调试，将多份结果报告整合，统计成一份数据，以便直观浏览。

需求还是内置测试需求，就是说一个小小热修上线，仅仅只是改动到某个模块的功能，那么测试只需回归这个模块的功能，不需要全量去回归接口自动化，当然这个诉求呢，从执行效率来说，目前全部接口执行完也不过5min，真的无伤大雅；不过呢，可以花两小时实现这个搜索，让它可以正常运作还是不错的.

这样既可以丢掉每个人本地自动生成接口测试用例的环境，统一在平台实现，又可以通过平台的批量执行，岂不美哉。从手工，到人工智能，设计的用例呢始终都有些问题，好在大都是从实际出发的，只不过还需要一道人工筛选的工序，这样是不是想自己来写代码实现会不会更好呢？• 开 发 提 测 后 ， 是 否 可 以 先 自 动 化 测 试 下 ， 看 看 后 台 接 口 数 据 是 否 正 常？• 测 试 好 的 功 能 点 上 线 后 ， 突 然 坏 了 ， 关 键 是 我 们 不 知 道 它 坏 了？