• 打回第二回后,把用例也给研发,让研发自己自测好没问题再给你验证吧。

  • 他们研发是照搬老系统的逻辑,一点业务逻辑都没改变,而且研发也不熟悉系统里面的业务逻辑,show case 是不可能的

    这个听着风险就很高了。重构但又不了解业务逻辑,这是怎么敢去做重构的?不同语言之间语法有差异,且有些语言特性可能另一个语言没有,得 workaround 处理,这种谁敢保证 “一点业务逻辑都没改变”?

    PS:试着问了下豆包 把一个程序从使用.net重构成使用 java spring boot ,会有什么坑,需要怎么防范?,看着可能存在的坑还不少:

    分析:将程序从.NET 重构成 Java Spring Boot 时,会面临技术栈差异、架构适配、数据处理等多方面的 “坑”,需针对性防范。主要包括语言特性差异导致的逻辑实现问题、框架生态不同引发的集成适配难题、数据访问层转换中的兼容性问题、部署与运维环境的迁移挑战等。
    答案:
    
    语言特性差异坑
    坑点:C# 的委托、事件、LINQ 等特性在 Java 中无直接对应,如 LINQ 的链式查询需用 Stream API 替代,且语法和功能有差异。
    防范:前期梳理.NET 特有语法和类库的使用场景,用 Java 等效方案替换,如用 Google Guava 库补充集合操作能力,通过单元测试验证逻辑一致性。
    
    框架生态适配坑
    坑点:.NET 的ASP.NET MVC 与 Spring Boot 的 MVC 架构虽相似,但依赖注入、拦截器、过滤器等实现方式不同;第三方组件(如 ORM 框架)需替换,如 Entity Framework 换成 MyBatis 或 JPA。
    防范:深入对比两者框架组件的生命周期和配置方式,逐步替换组件,例如用 Spring 的@Autowired替代.NET 的依赖注入,确保权限控制、事务管理等核心功能逻辑一致。
    
    数据访问层转换坑
    坑点:SQL Server 特有的 T-SQL 语法(如TOP、OUTPUT)在 MySQL 等 Java 常用数据库中不兼容;存储过程迁移复杂。
    防范:梳理数据库脚本,替换数据库特有语法为标准 SQL,用 MyBatis 的动态 SQL 替代复杂存储过程,通过数据库迁移工具(如 Flyway)管理版本,确保数据迁移后完整性。
    
    部署与运维坑
    坑点:.NET 依赖 IIS 部署,Spring Boot 常用 Docker 或 Jar 包部署,环境变量、配置文件(如 appsettings.json vs application.yml)处理方式不同。
    防范:重构配置中心,统一用 Spring Cloud Config 或 Nacos 管理配置,通过 Docker 容器化保证部署环境一致性,编写部署脚本自动化迁移流程。
    
    性能与并发坑
    坑点:两者线程模型、内存管理机制不同,如.NET 的异步async/await与 Java 的 CompletableFuture 实现逻辑有差异,可能导致性能问题。
    防范:对高并发模块进行压力测试,用 Java 并发工具(如线程池、CountDownLatch)优化异步逻辑,借助 JProfiler 等工具排查内存泄漏和线程阻塞问题。
    总之,需通过充分的技术调研、分模块逐步迁移、完善的测试覆盖(单元测试、集成测试、性能测试)来防范风险,确保重构后系统功能和性能稳定。
    
  • 1、你如果要离职了,你会主动进行挖掘性的输出,进行交接吗?

    挖掘性说不上,但总结文档或者一些代码交接(说明下各个模块作用啥的,对方有个印象)还是会做的。如稀饭所说,还是要保持好自己的口碑,这样以后前同事有好机会还会想起你。维护好人脉还是挺重要的。

    2、你会主动对接替者进行交接吗?还是被动等着他来问

    我会主动找,反正也比较闲,交接好可以减少交接后找我的次数。被交接的人一般都比较忙,而且不熟悉,完全被动的话,交接效果会不大好,最后就变成离职后还得来经常问,背后可能还会在公司里吐槽我没做好交接,给别人留下差印象,没必要。

    3、你不会担心由于交接有问题,导致后续给你打电话吗?

    这个没啥好担心的,有就解答就好了,一般也不会很久。

  • Author only
  • 恭喜恭喜!

    建议先准备一些简单的小的点的思路(如楼上说的优化流程、增加基建等,最好是你自己测试时就觉得是个需要优化的痛点的,这样优化后效果有保障;举个例子,某个流程的测试,每次造数据都要 10 分钟以上走各种流程,这时候如果有个脚本可以一键造数据,提升就会很直接明显),然后找你的上级沟通下,了解他的想法吧。

    上级提升你上来,一般内心都会有一些希望你去做的想法的。要获得上级认可,首先要了解上级的想法,确保方向不要走歪。

  • 不好意思,我这边已经 5 年多没有碰过这个了,估计没法回答你这个问题。

    建议你到官方的沟通群里反馈下?

    PS:建议把相关报错截图信息也附上,光一个 “回放失败”,信息有点少。

  • 工作内容除了日常的测试,还需要兼顾一定的测试管理,项目经理传达的意思是,之前的管理主要都是做一些资源的分配,想让通过推动例会复盘的形式,实现测试工作的提质和提效

    这个目的,感觉怪怪的。一般复盘会应该是有明确的问题,要复盘根因,确认改进项,避免问题再次发生才开的,第一次听复盘会目的是 “实现测试工作的提质和提效”

    我理解这个是不是应该是一个内部的定期例会,用于一起去 review 看整个 QA 的目标(OKR 或 KPI)的进度和困难,以及不同的组之间做一些信息同步和交流分享?

  • 额,你这个不算单元测试吧。如果里面有一些上下游函数需要 mock 返回,你都不在同一个进程里,做不了,那你异常处理的代码会很难覆盖,行覆盖率会上不去。

    建议花点时间去学下 java 和 javascript 的单元测试框架,比你这么折腾简单,而且现在有挺多能生成单元测试的 AI 工具,上手不难。

  • | 是否需要将 yaml 格式的用例,转换成页面组件的形式进行编写呢?

    建议自己权衡吧。做成页面组件,好处是可以折叠省一些空间,以及对于小白友好,缺点是可能编写和查看效率降低(比如要知道某一步的参数,还得多展开一下)。

    | 当前 yaml 内容步骤过多的时候,自己看的都有些费劲。不知道有什么好方法去改进这块。

    做封装呀。参照 Page Object 把页面和页面上的常用操作封装一下,这样应该你的步骤应该就少很多了。

  • 个人能想到的,仅供参考

    1、换幻觉少一些的模型,比如最新出的 GPT5
    2、调用多个模型,只取多个模型都一致的结果(基本不大会多个模型在同一个位置有一样的幻觉)
    3、调整 prompt 及模型参数,减少模型自行发挥空间

  • 如果是我,我会先问项目落地情况、实际收益、遇到的困难和解决方法,后面再进一步去深挖实现原理等细节。测开不像开发,落地会有产品 + 运营等负责,测开基本要自己负责落地,完成整体闭环的。

    另外,这里的量化指标,说实话,太工整了,很明显不是统计出来,而是自己拍脑袋估算出来的。

  • 34+

  • 97 年,如果还想拼,能拼,建议选能走得更远的 B。
    AI 目前在改变整个行业,甚至产品、业务本身都在适配改造,并且在一些业务上已经证明了其价值。虽然有一些吹的成分,但很多领域已经实打实地产生收益,甚至离不开了。

    想延长职业生涯,走得更远,还是往这个方向靠吧。

  • 打羽毛球,自驾游,打打游戏,补下觉

  • 想问下,所以崩溃率大概是多高?百分之多少?

    老功能不常用,所以没回归,但灰度或全量时用户会遇到,而且遇到得还不少导致你们崩溃率高。“不常用” 和 “崩溃率高” 两个有点矛盾。

  • 没有移动办公的需求,就 mini 吧。同样价格 Mini 配置更高。

    我很久以前第一个 mac 买的官翻版 air,主要是当年还有些热情带着 air 去图书馆啥的折腾技术,顺便骑自行车到处走走,在家里干扰会比较多。如果你没有类似情况,可以直接 mini。

  • mini 你还得算上显示器、键盘鼠标等配件的费用,air 就简单很多,还能带出去随时用。财力 ok 的话,建议 air。

  • 我是

    倒没有特别去挑选对比,只是这个最简单方便,题目也多。

  • 个人经验,一般会逐级分类:

    先按责任方分,主责事故(自己系统导致的问题)、非主责事故(其他系统出问题,连带影响到。比如机房网络挂了)
    然后主责里面再分,具体的类型,比如代码问题、配置问题、数据问题、人为操作问题
    根据具体类型,可以再进一步细分,比如代码问题,再细分为实现遗漏、实现不正确、健壮性不足等

    一般统计分析,分到第二层就差不多了,到达这一层就足够去定一些比较通用的改进项,预防高频发生的事故。

  • 自动化测试工具求推荐 at March 07, 2025

    我想到的也是截图对比。这块比较容易做自动化

    如果不熟悉写对应的代码,可以用 cursor 辅助下

  • 职业发展的困惑 at March 07, 2025

    是的。现在外包很多简历,以前都是做正职的,能力都不差(基本都是业务测试 + 自动化测试 + 少量专项)。没有 gap 的非常多,相比之下有 gap 的竞争力会低不少

  • 职业发展的困惑 at March 06, 2025

    现在岗位太少,gap 2 年基本 hr 这一关就过不了了

  • 我用的是这个,在 cursor 里项目的根目录下执行,仅供参考:

    请使用python pytest、request框架,生成根目录下django后端项目对应的接口自动化用例到 api-test 文件夹中。要求:
    
    1、覆盖所有接口
    
    2、断言覆盖接口返回码、关键返回字段值
    
    3、使用 allure-report 生成测试报告
    
    4、一个接口一个py文件,py文件中1个用例一个函数
    
    5、合理使用setup和teardown减少代码重复
    

    生成出来的内容大概如下:

    当然缺点还是有,比如跑起来有些用例会报错,需要人肉看和修正,有些断言写得还是过于简单,需要人肉加。但从提效角度,省了很多手工活。

  • 确实还是会有一些 bug,需要足够熟悉,给到真正有效的指引,才可以快速和有效解决。但相比自己从零撸代码,省了很多力了。

  • 最近试了下 cursor,可以直接给 django 后台项目,生成完整的 python+pytest+request 的接口自动化用例(根据项目代码自动理解有哪些接口 + 生成对应的自动化用例 + 错误码及关键字段的断言)。这堆代码人肉写,至少 1 人天,用 AI 几分钟左右就可以生成出来,提效挺明显的。

    现在 cursor、trae 等深度结合 AI 的 IDE,已经可以做到用自然语言从零生成完整项目,且可以正常跑起来,还可以通过自然语言提需求,AI 直接根据需求改代码,给我震撼还挺大的。