嗯……，很多是靠维护用例之间的执行顺序来测试业务逻辑的，这样在用例较多或业务逻辑逻辑复杂时候，维护起来很麻烦；第二个问题没看明白，没有一个接口写两次呀

1.yml 文件维护的接口定义信息（不是为做数据驱动），也就是接口请求参数的格式，一般是 json，当然表单、get 传参、文件上传最终的二进制文件都没问题；目的一方面是方便接口定义维护，再者避免掉接口请求时设置地址、登录 cookie、参数组织（业务中往往参数结果很复杂）这些重复冗余代码的，后面用例代码只需根据测试意图设置相应的参数值，未设置的参数值按照定义中的值作为默认，写用例时更多关注业务逻辑，也就是接口间的关系就好了
2.场景用例很多时候不只是会话保持 - 把前面请求的 cookie 带进去，如 demo 中 testerhome 帖子点赞的例子，整个流程是登录（前置操作中完成）- 浏览帖子 - 点赞，最后的点赞除正常参数外，还需要 cookie 中带一个 x_csrf_token，这个 csrf_token 是在浏览帖子的 html 中动态传递的，另外点赞接口还需要一个 cookie 也是从浏览帖子的返回中获取的，如 1 中表达，这种接口间的关系是测试用例中的重点，而其它接口调用需要的信息由框架来解决；这个例子断言只校验了状态码，只是示例，当然也可以校验点赞前后点赞数的变化，其落库情况等，不是这里表达的重点，没有对此展开
3.编程语言的选择，是因为组内多数人更熟悉 java，pytest 和 testng 同样优秀，就像 python 之余 java,java 中的 http 请求框架很多也支持会话的，编程效率上有差异，但不是很大，不用过分纠结；allure 也用过一段时间，当时它有些 bug 不知后面版本 fix 没有
4.总之，这个框架解决的是接口调用的简洁性问题

独角兽……

来杭州吧，杭州现在明显互联网人才多，像样的公司很少