不是哦，端口和地址都换过了，还是一样报错。
不过看报错提示是地址占用，如果是端口占用应该会提示占用的进程啥的这些信息。

博主加油，期待尽快开源啊

是的，这种问题的难点，可能就在生产条件的模拟。 不下雨的时候检查，可能没那么有用。 雨天检查，是不是还得考虑雨下多大，积水有多少，踩上去的是个胖子还是瘦子？
如果按照不下雨天的检查结果来保障，那么标准就相当于向上拔高，质量保障没有达到 “刚刚好” 的这个限度，成本会有损失。

同意一楼的回复，
我们这边把回归范围包含两部分，本身修改部分 + 受影响部分。

黑盒测试，确实只能通过需求文档和设计文档评估范围，但这个不太准确，时不时会有遗漏。

目前精准测试还在构建中，调用链路分析没搞定之前，貌似也起不了啥作用。

如果人为去 code diff 代码行，除了对测试人员代码能力要求较高以外，花费的时间估计也不少。
可能折中一下会好一些，还是以黑盒评估为主。在代码提交以后，git diff 获取修改代码的文件，根据文件判断大致涉及功能，然后反馈黑盒，确认是否有测试范围遗漏。 不过这个方法还没实践过，楼主可以参考下

不管啥时候，选择权掌握在自己手上总是没错的，多看看机会，跳出舒适区。说个血的教训， 我去年拿了涨幅接近 70% 的 offer，结果公司说能特批调整下，然后就没走，现在肠子都悔青了。

allure 本身就支持生成报告，最后的结果是 html 格式的。 一般生成报告都是集中存放，然后启动一个 httpserver，然后其他人只要拿到测试报告的地址，可以通过浏览器直接访问测试报告。

报告的地址可以在消息通知的时候推送出去，比如钉钉，企业微信，邮件等。 我们目前就是这么干的，很方便。

sql1 对应 index1， sql2 对应 index2，本来是没有问题的。
不过可能会出现一种情况就是 index1 修改以后，sql1 查询变快了，不过 sql2 查询 不走原来的 index2 索引，会走 index1 索引，导致 sql2 变慢。

是的，这就是当前的典型场景之一

服务层的性能测试我们已经在做了，而且这块如果有风险，线上就可以进行扩容等操作进行处理。
mysql 这块，就没法线上扩容，所以导致出现问题比较棘手

说下我的理解哈
从职业发展来讲，测试开发可以干自动化测试，效能工具或平台开发，或者是专项测试及相关工具。
其实对你来说，这个可能是一次比较好的机会。尤其是你的 leader 没有什么明确思路的时候，你发光的机会就来了。

先跟你 leader 对齐下目标，然后梳理思路，确定实现过程，最后就周期性跟他对齐结果就行了。
对齐目标类似就跟做规划一样，可以从 3 个角度去处理。1.你们所在部门的岗位职责。 2.你们部分承接的上级部门的 OKR 是啥？3.结合历史分析，比如去年你们哪里做的不够好，外部评价不够？ 就从这些角度跟你老大讨论下，看看你们要大概做成什么样子，对你的期望是啥？
梳理思路就是讨论下实现过程怎么搞，开源工具集成还是自研工具?分几个阶段做，里程碑怎么设置？到时候做完大概怎么推动落地等等，然后就是搞一搞跟 leader 同步下进度。如果搞得不错，指不定还能拉更多资源，你就升级当 leader 了。