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

  • 博主加油,期待尽快开源啊😀 😀

  • 从测试角度看现实问题 at 2022年08月17日

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

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

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

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

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

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

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

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

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

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

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

  • 测试开发到底应该干点啥 at 2022年03月22日

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

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