一开始看下来，也是这么认为的。

不沿用的原因是 nginx 的那个动态插件是不支持通过 http 接口动态设置请求头的，所以有临时方案在每套环境之前放 1 个 nginx 来设置对应环境的特殊请求头。

确实找过一些 “Gateway” 类的工具，但大都比较 “大而全”，放在这里有些小题大做。而且不少工具不支持通过 api 动态修改配置，需要改造，就放弃了。

这里只是一个小工具，功能精简且好移植（go 语言）

我们不做定期报告，直接将 jira 上 bug 和线上 bug 按级别、bug 产生类型及线上 bug 遗漏类型数据同步到 seatable。
seatable 上做统计图表及明细，领导想看自己去看。

去过 qcon、qecon 一类的，看到各类大厂说自己的 devops、全链路、智能自动化等等高大上的分享，一开始会很羡慕，但细细一想，这些东西都是有局限性的：业务运营的支撑、技术水平、人力物力...都限制了在其他公司的落地，盲目尝试最后落了个鸡飞蛋打的下场。

但我们能做的是从大会的分享中汲取各类创新的思维和技巧，结合自身部门的问题或瓶颈来寻找方法来解决。

从个人来讲，在我们这种不大不小的公司中，尤其是业务线的测试，对大平台的建设没有兴趣。而比较推崇楼主所言的 “小而美的工具或小平台”，准确的说是 “实用工具链”，各种工具能灵活运用各种类型的测试，这并不会比大平台效率降低。

反而把一些列工具强行整合的大平台，前期开发量大（整合时考虑的情况会很多，规则会很复杂），后续如果研发模式改变，子工具、中间件、插件的升级带来的整个平台的维护量也很大，对以发展业务为主的公司来说，这些都是极大的成本。

go 写 http/http2 相关的服务比较方便

pytest 执行依赖及 test 之间传值一种处理方式：

1. pytest 框架的 test 之间的传值：利用 fixture 即可
   conftest.py 中定义全局参数：

   @pytest.fixture(scope='session') # session是大家全局共享变量，其他仅限于各自范围内有影响
   def xGlobalArgs():
         return {}
   

2. pytest 的 test 依赖及传值，这里 testCASE2 会等待 testCASE1 测试通过再执行

   @pytest.mark.dependency(name="test1")
   def testCASE1(xGlobalArgs):
       xGlobalArgs["token"]="123123123123123"
      pass
   @pytest.mark.dependency(depends=["test1"])
   def testCASE2(xGlobalArgs):
       print(xGlobalArgs.get("token"))
       pass
   

同意@Ouroboros
用例要看覆盖的是否全面，至于深度？？？？？

当然如果能覆盖全面的基础上，让用例的可阅读理解及执行效率上做点文章，才是更优的用例。

至于为了敏捷选择脑图作为用例方式，那更考验设计者是否写的清晰了，
业务后续维护转移其他人测试时，好不好其他人理解呢？

感谢大佬的补充。

但目前的现实是：道理都懂，但实践上无所适从。
所以想先听听大家的想法和经验，先从一些好实践的地方入手来看看。

谢谢大家的分享：
我看下，代码覆盖率使用的可操作确实不是很强，但以下部分可以尝试：

1-各个版本增（变）量的的代码可以尝试代码覆盖率，测试可以进行用例的对应逻辑的查漏
2-染色代码和对应接口进行关联（需要找到可用工具或方案），可以进行后续代码变动自动关联测试接口脚本测试

“变更部分”：这个有什么工具可以自动获知吗，还是可以有配套的 diff 工具来做

对 “每个自动化所覆盖的代码片段进行了关联” 这个比较感兴趣，关联是怎样具体实现的呢？

既然要从界面上操作，那还是不要用无头模式。
至于 jenkin 去运行不能打开浏览器页面，可能的原因是 jenkin 以后台服务的方式去启动的
我都是用命令去启动 jenkins 的
但是可以试试 google 到的一个回答（我没试过）

我写本文的初衷是讨论怎样避免一些测试遗漏，比如这里：

1. 是不是用例设计的时候可以就避免了
2. 或者能不能先去了解开发写的代码设计、sql 一类 等等

歪楼了...

这个是本职工作呀

我在原文加上了补充说明，这样就能明白了。
另外，价格是从第 3 方获取的，但有二次校验（UPC、产品名...校验），校验不通过会被删除。
为啥要保留历史数据？这个是为了 BI 分析用的，看价格的历史变动用的。

至于增加一个生效标志，这个设计完全看开发的个人设计喜好了：

• 加这个标志需要在插入时多做一些步骤
• 不加的话则需要查询的时候麻烦些

对于测试来说，符合需求就 OK 了，只不过这里开发耍了一个 “技巧” 耍撇了...

至于责任，那是因为我也是测试，遗漏 bug 时首先会考虑自己的问题，而把责任推给测试那就言重了，毕竟 BUG 是开发写的。

如果是想绕过这些步骤，倒是有个建议：
1、上传：可以通过 js 操作元素/利用 requests+ 当前 driver 的 cookie 发送上传请求
2、拖拽：这个通过 js 实现元素的 dom 操作

可能我没说明白或你没细看：
那个开发给我的参考 sql 就是他开发的列表用的，那个 sql 会造成上文举例的那个 SKU 无法显示，这样不是 BUG？

同龄，同年毕业，同工。
只不过是南京 ，IT 环境及薪资可是一言难尽。

嗯，其实我建议用正则替换是有原因的，这类空格其实都满足正则里的\s:

所以用正则替换\s 为常用的空格 (chr(32)) 比较具有普遍性

其实很简单，你打印下下这两个字符串的字符 ascii 就可以看出不同了

a = "xxxx yyyyy"
for c in a:
    print(ord(c))

如果想要相同可以用正则替换掉对应字符

使用 UTC 就不用考虑这个夏令时了

OK

嗯，这个是常见思路。
其实可以用@jerrylizilong的方法，提前下好一些版本备用。因为 “墙” 的原因，chrome 更新和 driver 下载不是那么方便

一个脚本多端运行时需要考虑到部分运行端的 chrome 还是老版本的情况：
所以建议是先获取到运行端的 chrome 的版本号（大版本号，比如 103.1.201 就是 103），然后去判断是否有满足版本的 driver，没有的话再去下载。
比如 windows 端的 chrome 版本号可以从注册表中获取reg query "HKCU\Software\Google\Chrome\BLBeacon" /v Version

看完，就这个姑娘回答得很勤劳