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

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

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

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

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

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

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

主要看维护工作量。
有的测开工具，把大量业务层的东西抽象出来，做到配置、数据文件里。框架是灵活了，但是对业务测试来说，似乎工作量并少不了多少。有的业务测试怼回来：需求变化用你这个框架配置一遍，比自己写一遍代码还累
这样的框架稳定有啥用？

尝试下这些操作看看

1. Jenkins 设置的工程是否是脚本运行的工程路径
2. allure 每次生成报告覆盖原报告试下
3. 检查确认下 Jenkins 中的报告路径设置指向

是因为没有多次 Run 的记录吧

乐刻庙小了点

跟着产品团队走，面向交付，不要面向技术解耦。测试关心的应该是一个完整的特性，包括前后端。
当然如果你的测试标的就是前端或者后端的交付是另一说

不错，赞一个～

@ 恒温 恒大，问题还在，是 bug？

多谢，已经看到。不过创建不了...

访问被拒绝，你可能没有权限或未登录。

再次申请开通～～

//hand 人到中年，各种不易，祝尽快出坑

其实主要还是看团队气质... 有的团队 CI 都搞不起来，随时发版就是个笑话。团队磨合好，形成适合的节奏，不会今天这样明天那样一锅粥就好

补充一点：大公司经历，意味着至少对方几轮面试已经帮你把过一次关。越是知名公司门槛一般也越高，相当于是背书了。类似校招先看学校

TestNG 本身不就是支持多线程吗？或者换 Junit5，根据 cpu core 自动分解用例，一行配置而已

Allure 本质上是个 report 转换工具，你的问题都是没有把转换后的报告生成到指定目录