这么 mean

本质是责任逃避，提测质量估计很差（研发都不懂业务）

你没有测试主管吗？？？

测试主管看好多项目，有时候反馈还处理不过来，就是纯吐槽，顺便看看大家的想法

不知道业务逻辑，就对着代码转码开发，质量不可能好的。
至于是否 show case，这是你们公司研发测试流程确定的事。按规矩办事

重构啊，不自测能接收吗？直接打回。研发不注重质量就往上反馈，不然总是被研发压着

全量回归吧，这种迁移一个方法的数据结构类型转化有点差异都是一堆问题，而且目前这种迁移大部分是用 AI 做的

必定是确保不了的

不熟悉逻辑就迁移，谁给的自信？

看楼主应该 17 年入行，现在还在干，可能他就是测试主管了

以我的经验，这种 bug 会比较多，建议慎重，全量测试

本来这种就是全量测试了，只是被这个理由搞破防了，测试太卑微了

项目组组长，因为不想管人，所以没走管理方向，主要是第一次听到这么清奇的理由，有点破防

研发那可太有自信了，说我们是 CTRL + C 跟 CTRL + V 的代码，怎么可能会有 bug 呢

说明公司内部管理混乱，测试没地位，提测质量根本没法保证

笑死，不过既然你们头头都这么说了，这个版本就先测试全程投，把 bug 和用例执行情况披露出来，然后以周报形式定期抄送给全部门尤其是你们的研发主管，到时候项目要发了 bug 没解决急得就是他了

至少应该把老系统的主流程对应新系统的部分 show case

这被你说中了，因为马上就要跑了，所以吐槽一下，公司内部管理也就对内减薪，对外要求测试帮忙隐藏测试真实情况，比如某次版本中发现 10 个 bug，只能跟客户说，我们只有 3 个甚至更少的 bug

很明显，提测后看冒烟，冒烟不过直接退回，向上提交冒烟测试不通过，打回版本提测的报告。后面出问题，让开发内部自己解决

2017 年到现在 8 年测试经验了，像这种重构类的测试任务不是应该先了解清楚他们重构的技术架构和技术方案吗？是全部新写接口还是新接口包老接口？先梳理出老系统的业务流程吗？全部新写接口如果开发不懂老业务，写的接口也不能用，测试理论上应该和开发共同梳理出老系统的前后端业务流程、交互逻辑，并维护进测试用例作为测试用例覆盖，开发提测前执行一轮你的业务流程用例。如果是新接口包老接口，BUG 不一定多，给研发一份主流程自测用例就行，测试自己全量覆盖。

研发上来就开始写代码，完全没技术评审，问就是不改动业务逻辑不用评审，然后我之前跟研发沟通的也是测试提供一份主流程测试用例给他们自测并 show case，研发就说他们不懂业务逻辑，其实争执点就是在研发认为他们只是复制粘贴代码逻辑，不需要理解业务，而测试这边都是准备好业务流程梳理图，测试用例这些，随时可以提供，但还是被拒绝了

目前这套新系统也不是新接口包老接口，而是彻底把.net 的老系统停了，转成 Spring boot 的新系统，所以我认为 showcase 还是蛮重要的

1. 既然他都说是复制粘贴性的迁移逻辑，这么简单的事情为啥还要测试来测问题，他敢不敢直接上线？
2. 【研发主管的说法是 show case 等于帮测试执行了测试用例，测试就不用工作了，因此拒绝 show case】这观点可太强了，没见过这么头铁的，给我整不会了

另外说个笑话，我刚毕业第一年那会，公司内有个工作六七年的开发，还是那种比较爱钻研技术受其他开发敬佩的类型，他当时多次表达过这么一个观点：【技术方案没必要和测试过得太细，不然测试的思维就变得和研发一样，那就测不出问题了】。现在回想，简直放屁。

你完全可以这么回复：没有技术评审、没有技术方案、只是复制粘贴逻辑、没动老代码、不需要开发进行 show case，那么测试从开发提供的方案分析，这个需求非常简单 ，开发自己就能上线。

提测质量肯定不行。一个东西，你都不知道他干啥的，照着样子做出来了，你敢直接给别人用么。。。

至少在我们公司，重构是非常严谨的。研发会详细列举各种服务所涉及到的功能并和测试一起开会讨论测试点。然后 case by case 的进行阶段性测试，保证各阶段无误后再上线，然后进行监控。目的就是一起保证重构的顺利过渡，不影响用户的体验。

有些公司重构就是屎上雕花，开发自己知道原系统很拉胯，不如重做，但是又被下达必须重构的任务，开发就会用完成任务的方式随便搞搞，反正有测试背锅

为什么要给你 show case，按照流程规则不是应该给你出示单元测试报告吗，既然是迁移、重构，那代码覆盖率 90% 是应该保障的吧~
你想要的只是个提测质量，为啥提这么奇怪的要求？

所以这个就看你们公司内部对于质量的要求了。如果为了完成任务，那不如直接上线。这种情况在我们公司测试是可以直接打回的，就看你重不重视了

是要求提测质量，因为之前试过一次，我接受了提测，但是那次单元测试通过了，但是业务流程在我这边冒烟一个都没过，所以这次提测我才要求业务流程的 show case，这种情况下，我理解研发即使做到了单元测试的代码覆盖率到 90%，但是也要至少保证提测的业务流程是通的吧，这是我的想法；因为我之前也没遇到过这种，所以也想听听大佬的建议

说句实话，这种事情可能是很多，但是这种事情又会怎么样呢？他到底影响到了测试什么呢？如果没有影响在意这个东西干什么呢？如果没有影响，你提一下可能会觉得更好，如果不答应那就不答应了。 如果有影响，那有什么影响呢：

1. 提测质量差？提测质量差就差呗，你就说提测质量太差，比预估的时间要多很多，应为发现了这么多 SB Bug，不应该出现的，应该在提测的时候就查看的，而且因为开发根本没有验证过自己开发的东西最少符合基本功能，所以他们工作量预估都是不对的，要不然怎么会出现这么多 Bug 呢？你不要怕，你说的就是事实
2. 当然领导不答应你延期，你说加人行不？还是不行，也可以呀，那总要不事情说清楚吧，就是开发质量太差，需求都不知道也不验证一下，那你说你完成了什么？要是完成了，那为什么这么多主流程 Bug 都还有。
3. 如果领导说你可以重新估计时间，那就多估算点时间测试呗，那就也没有什么影响了，对不对

如果领导说，开发质量问题改不了，但也不能延期，那就测试快点，出点问题你提前和领导说，可能会有点问题的哦，因为开发质量比较差哦。如果领导还是说出了问题都是你的问题，那这么不看基本事实的地方，你有其他地方就去看看啦，如果没有，那没办法，你改变不了什么，那就想着怎么混过去呗。 但是话你一定要说清楚的。既然这样了，所以完全没必要纠结这些东西。

提测要跑集成吧

新特性和重构还是不一样的，看不同团队的规矩吧。
新特性肯定是单测和集成报告都要的，敏捷团队还要 show，重构应该侧重单测，集成不好说，当然有更好~

show case 啥意思

showcase 就是给大家当面演示一遍主流程，一般是用来传达核心功能已经准备好

正常来说主流程冒烟不过就直接打回，结果来一个直接不冒烟了，那不绝了么

我们这种重构都是开发改完，主流程跑完，测试测完后接口 DIFF 和流量回放通了才行的，不然鬼知道有什么坑等着你呢

"运行很久的系统"之前是楼主负责的吗，如果不是，开发不能完整演示核心功能确实他们不对。
如果之前就负责这个系统的测试，系统迁移后做测试按照之前测试用例来就可以了呀，做 show case 可能确实会拖延开发的其他工作进度。而且一个系统是多个开发负责，让谁来 “show case“也是一个问题

这个系统是从其他团队传承过来的老系统了。。。对于业务的理解研发跟测试都是从 0 开始的，所以我认为研发至少是提测前给测试做个最基本主流程的 show case 是没问题，像你说的，如果我之前就负责测试，重构之后确实可以不做 show case，但是大家都从 0 开始就很。。。

他们研发是照搬老系统的逻辑，一点业务逻辑都没改变，而且研发也不熟悉系统里面的业务逻辑，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 等工具排查内存泄漏和线程阻塞问题。
总之，需通过充分的技术调研、分模块逐步迁移、完善的测试覆盖（单元测试、集成测试、性能测试）来防范风险，确保重构后系统功能和性能稳定。

不了解业务逻辑直接重构代码简直是在耍流氓，重构时开发不懂逻辑 + 没有历史需求记录更是个天坑。测试时一脸懵逼，压根不知道之前业务需求是什么，也没人动，只能测到哪儿算哪儿···