除了为数不多的几个大厂，大部分企业还是处于作坊工作模式

现在这类非常流行的真实流量复制类的测试，安全、隐私管控是个大坑。悄悄做也就罢了，公共平台宣传不怕给公司惹麻烦嘛

二者应该是相辅相成的。技术服务于业务。技术能力弱也从侧面反映业务并没有到深水区。浅水区很熟不代表能进深水区
另外所谓的框架、平台是技术部分的浅水区，实际价值也不大

好像有些货，但是要么倒不出要么是不想倒出

Jenkins 上需要配置工程路径到你自己的路径，不能使用 jenkins 的默认路径

参考
https://gitbook.cn/gitchat/activity/5c83d2aa6d5f670edc43c606

测试开发就是开发，核心竞争力是开发技能，所以想想 “如何成为一名优秀的开发”。把自己从测试圈子中摘出来，放在开发圈子里看自己，可能定位就清楚了

反对 1 楼唯 KPI 论，不是做实事的态度

首先，测试的目的最终是为了交付质量。所以对团队来说，发现 bug 不是目的，解决 bug 才是。
在这个前提下：

1. 如果测试能够识别是同样的问题，或者是同类的问题，不应该重复提交。浪费的是团队的生产力
2. 如果是黑盒的原因导致判断不出来是不是同类问题，重复提交也没什么。但是作为专业测试，还是应该尽量提升自己的判断能力
3. 这里的避免重复单，是同样原因、同样现象的问题尽可能提在一单中，但是故障单中还是应该将可能出现的位置尽可能列全（以交付为导向，其实这不应该是个问题）
4. 不同测试针对同样的问题提了不同单。这个没办法规避（但同一阶段测试力气使在一处似乎分工上有些问题），先到先得。

总而言之一句话，和开发其实是一条船。重复单本身不是好事，主观上能规避就规避，真出现的话平常对待就好。

为什么要在 teardown 之前生成？ 需求好奇葩

allure 本质上是报告转换，不是执行框架，就是在执行框架做完事才做事。你这个需求：分成两个测试写，第一个调 allure，第二个只包含 teardown，不调 allure

就是做 mock 啊。有文档，照着文档造模拟数据不就好了吗？ 不清楚为什么 POST、PUT 不能 mock

简单来说，测开要定位为服务团队，服务对象就是业务测试。实际需求是方的，你造的轮子再圆也没有用。
很多时候不是缺少工具，而是很多已有工具业务测试不了解不掌握。测开沉到业务测试中，做好工具选型并形成最佳实践，教练好团队使用，远比做一堆重复度极高的框架、工具更为重要。

服务意识往往比技术本身更重要。