DevOps/CI/CD#

Q3: 工具选型与搭建：为什么决定使用 Playwright 作为自动化测试工具？相比近期流行的无代码 AI 自动化测试工具有何考量？如果让你从零搭建一套自动化测试平台，你会怎么设计？
Q4: 测试职责与场景覆盖：Playwright 在你们工作流中的职责边界是什么？主要负责哪些验收（接口逻辑、UI 渲染、元素交互）？对于带复杂业务逻辑的场景好处理吗？你是否参与编写过具体的 UI 自动化测试用例？
Q5: 流水线卡点与效率权衡：自动化测试在流水线中是如何流转的？上线前如何设置完整度卡点？CI 过程中运行测试是否会导致构建时间过长，你们是如何优化的？
Q6: 测试用例维护与误报处理：随着业务迭代，由于页面变更忘记修改用例而导致的 CI 测试误报，你们是如何解决的？这些用例日常由谁来维护？
Q7: 质量保证与 ROI 评估：你们的 E2E 测试页面/流程覆盖率大概是多少？所有的业务都要写 E2E 测试吗？没有写自动化测试的部分如何保证质量？整体来看，你认为推行自动化测试是增加了前端的负担，还是真正实现了研发提效？

Q8: 容器化落地实践：在过往经验中，前端团队是否需要自己搭建和维护基于 Docker 的 CI/CD 甚至发布环境？
Q9: K8s 基础概念：是否了解 Kubernetes (K8s) 相关的概念？例如能否讲讲 Docker / K8s 中的 ConfigMap 是什么，通常用来解决什么问题？

Q10: 代码门禁建设：请介绍一下你们团队的代码规范基建是如何落地的？代码门禁（静态检查）具体拦截了哪些内容？这些基建是你独立配置完成的吗？
Q11: 正则校验的局限性：实现拦截 i18n YAML 文件中的空字符串，或者检测代码中意外泄露的内网链接时，如果单纯使用 include 或正则表达式去做匹配，存在哪些不足之处？
Q12: AST 的实际工程应用：假设需要全局清理代码中的 console.log，在不依赖构建工具（如 Webpack 的 drop_console）的前提下，为什么推荐使用 AST（抽象语法树）处理，而不是直接用字符串匹配或正则替换？
Q13: Code Review 的边界：如果在提 PR 之前，同事已经通过工具或手动删除了所有的 console.log，我们在做 Code Review 时，针对这项变更还有什么潜在风险是需要关注的？

luke's blog