例如是后端接口返回的数据错误，那就是后端的问题；
如果是接口返回正确，前端展示错误，那就是前端的问题。

可以从流程上去推动一些规范，例如接口的规范、接口文档的参数列表和说明，接口设计等等，减少接口频繁变动带来的风险和自动化维护成本

这个我就不清楚了， 可以去搜一下看有没方案

你是在命令行里执行吧？ 这时应该是会用默认的环境

赞，这一套搭起来工作量不小

截一下完整的日志和提示？
有一种可能是你本地安装了多个 python 版本，然后刚好执行的这个版本上还没装 allure

2019-02-02 update:

• 抽取公共的接口和签名测试方法
• 补充 pytest 的 mark 功能跳过某些用例

是消息系统又出问题了吧？ 之前好像也遇到过

1. OPTION 请求只有在第一次访问的时候会请求一次，后面就不会请求了。
   
   从测试结果看，是每次都会请求 options 的，可能是我的方式不对？

2. 如果请求跨域了，必须要有 OPTION
   测试结果如下：
   修改前：
   https://testerhome.com/uploads/photo/2019/1bf20558-9ef5-4a34-a887-a1dcb7ea87a8.png! large

修改后：

测试的结果说明，改成 text/plain 之后是不会触发 options 接口的。

正常毕业加上待业一年，为啥会被嫌弃年龄小啊？

https://testerhome.com/topics/10422

可以参考下这篇文章的介绍

建议检查一下这两个地方：

1. workspace 里是否能正确展示对应的目录和文件？
   

2. 看下日志里打印的目录是否正确？ 你之前的截图里，命令中的目录是错的（因为没有加 ${}， 所以没有生成正确的 build id）
   

你确定加不加 ${} 是没没关系吗？ 先去百度一下 Jenkins 环境变量的使用说明吧

没有代码，没有截图，只看这些描述是没人能明白你的问题的

你两个地方配的 build id 格式都不一样

不是好欺负，跟踪、确认、记录 bug，这是测试的责任所在啊

你的测试方法 f 是空的？

认真观察一下，好像是圆角

了解了，如果要上容器编排会注意这个配置。

如果是业务相关的，依赖基本上是跑不掉吧？
我这边的接口三四层依赖的都有呢，但是能稳定地跑就行了啊，你做自动化的目的不就是为了稳定回归么

参数不稳定 -- 是输入参数不稳定，还是输出参数不稳定？

分批测试有什么问题呢？ 如果所有模块一起提测，你就不用分先后顺序了吗？
项目时间紧的情况下，相对于全部一起提，分批提测下测试执行的时间更为充足。相对于提前介入了

看你的 192.168.1.102：8000 是不是有中文字符（：）， 正常的英文字符应该是 192.168.1.102:8000

只要是在线上发现的 bug ，不管有没造成损失，都是自己的工作失误（给线上带来了风险），这块我觉得计算到绩效是没什么好说的；
不过我们一般会按严重级别来计算。

要保证 0 事故？ 感觉除了杀个 XX 祭天或者勤快点拜拜之外没绝对保证的办法