测试周刊005: Google是怎么做测试的
在 Google 早期，测试并不是首要任务。公司文化高度依赖工程师的才华——聪明的人写聪明的代码。大多数情况下，这种方式都很有效。少数系统部署了集成测试，但广泛的、结构化的测试极其罕见。这就像软件开发的"狂野西部"时代。
专注测试技术的课程订阅站点
测试周刊004: 单元测试和接口测试用例将成为标配
马上就到端午假期了。
今天在电梯听到两位女士的对话，大概的意思是一位认为只有一天的假期有点不太过瘾，而另一位觉得假期归来以后上 4 休 2 已经是非常划算了。
反正我是同意后者的。
观点
AI 将使得单元测试和接口测试成为标配
前些天 deepseek 发布了新模型，该模型在代码能力上有了较大的提升。
有人尝试之后表示模型不仅可以正确实现编码需求，还可以在生成代码的同时给出完整的单元测试用例。
今后将有越来越多的代码会由 ai 实现，而我们可以非常自信的要求 ai 在给出实现的同时，给出完成的单元测试用例和接口测试用例。
因此在不久的将来，单元测试用例和接口测试用例将会成为增量代码的标配了吧。
测试同学可能不需要人人都会写单元测试用例了，但是学会看懂测试用例，并用测试思维来对用例进行评审，反而是更实用的技能了。
从质量保证到集成保证
传统的"质量保证"概念存在两个极端问题：
- 过度依赖 QA：认为 QA 团队独自负责产品质量，其他团队可以推卸责任
- 完全取消 QA：认为每个工程师都应该"拥有质量"，但缺乏系统级验证
作者认为传统的"质量保证"（QA）概念存在误导性，因为质量应该是每个团队的共同责任，而不是 QA 部门的专属职责。
他提出将 QA 重新定义为"集成保证"（Integration Assurance），专注于验证现代软件系统中多个服务和组件之间的协同工作，就像苹果公司需要确保 iPhone 各个供应商的零件能完美集成一样。
这个角色类似足球比赛中的守门员——不是唯一的防线，但是防止问题到达用户的最后屏障，同时帮助发现系统级的协调问题和集成风险，而 AI 测试工具应该主要由这个集成保证团队来使用，以确保从全局视角进行有效的端到端验证。
自动化测试
有效的软件测试需要通过测试替身（Test Doubles）来隔离被测系统，从而编写可控、可靠的单元测试
https://medium.com/@raissa.puti/behind-the-green-check-a-guide-to-test-doubles-7199be3b08c2
作者认为，真正的测试不仅仅是检查功能是否正常运行，而是要通过 Dummy、Stub、Spy、Mock、Fake 等不同类型的测试替身来替代真实的外部依赖（如 API、数据库、时间服务等），这样可以：
- 控制测试环境和输入数据，
- 验证特定的交互行为，
- 避免依赖不稳定的外部服务
- 提高测试速度和可靠性。
作者以自己的 React 项目 SiNgawas 为例，展示了如何在前端测试中应用这些概念，同时分享了借助 AI 工具来改进测试设计的经验。文章强调，好的测试应该专注于验证有意义的行为，而不是简单地检查 UI 渲染，通过合理使用测试替身可以让每个测试都有明确的目的和可预测的结果。
测试周刊003: 大模型时代测试将会变得更加重要
五一假期结束了。
这次五一完美的错峰出行。
核心的原因是起的早。
天刚亮就出发，第一波到达景区，人流汹涌的时候就回酒店休息。
世间的喧闹与我无关。
这大概是一种错位竞争吧。
比如，当测试都在千军万马涌入新领域的时候，业务在原有的业务上进行深耕反而会取得一些错位竞争的优势。
观点
测试将会变得越来越重要
https://filiphric.com/testing-will-become-more-important-not-less
作者认为在 LLM 时代，测试将会变得举足轻重，并给出了几个预测。
- 测试将更紧密嵌入软件创建过程
- AI 不仅生成应用代码，还将同时生成测试代码
- code review 时也将包括 review 通过的测试
- 运行先前迭代生成的测试可避免回归问题
- 更多 AI 解决方案将整合自动化测试
- 将出现更多能同时生成代码和测试的 AI 工具
- 已有工具（如 Replay.io 的 Nut.new）能在后台运行测试并将结果反馈给 LLM
- 人工测试将演变而非消失
- 人工测试将更加精细，专注于新功能测试和 code review
- 回归测试将主要由自动化测试承担
- 测试人员将专注于变更测试，而不是专门写自动化测试用例
- 良好的测试设计将继续受到高度重视
- 优秀测试工程师的价值不仅在于编写测试代码
- 良好的测试实践、测试数据架构和风险区域识别能力更为关键
- 技术精湛的测试人员将引导和 review AI 生成的测试代码
- 应用和测试运行时将成为巨大挑战
- 虽然 Playwright 等工具中的追踪查看功能成为标准，但应用运行时信息仍然缺乏
- AI 模型在调试软件方面仍有困难，因为它们缺乏代码实际运行方式的信息
- 可观察性工具可能是让 AI 生成可靠代码的关键
优秀的测试工程师应该具备哪些思维方式
https://qualityeng.substack.com/p/the-three-mindsets-of-a-qe
测试周刊-AI不应该用来解决本来就不存在的问题
离五一只有两周了。
最近有朋友买了 cursor 的会员，我驻足观看了一番。
他先描述需求，然后让大模型生成原型，接着又让 LLM 根据原型来生成前后端项目的代码。
整体流程一气呵成，看着非常有科幻感。
不难想象，接下来根据可以工作的前后端代码就可以让大模型来生成 ui 和接口的自动化测试用例。
不久的将来，通过 AI 生成的各种测试代码可能会是开发标准输出的一部分了吧。
AI 与测试的思考
停止过度设计：为什么测试 ID 比人工智能驱动的定位器智能更适合 UI 自动化(英文)
https://testersdigest.blogspot.com/2025/04/stop-overengineering-why-test-ids-beat.html
并不是所有的测试人员都关注 AI。
并不是所有关注 AI 的测试工程师都盲目的拥抱 AI。
这篇文章就反对使用人工智能来解决 UI 自动化测试中的定位问题，而是提倡使用测试 ID（Test IDs）这一更简单有效的方法。
测试 ID 稳定可靠：测试 ID（如
data-testid="submit-button"）是可预测的，不会因为开发人员更改 CSS 类、更新布局或重命名元素而失效。避免不必要的 AI 复杂性：为什么要让 AI 去"猜测"正确的元素，当我们可以从一开始就通过测试 ID 明确告诉 DOM 要查找什么。AI 应该增强测试策略，而不是清理本可避免的混乱。
效率优于优雅：在测试中，我们的目标是验证功能而非创造艺术。Test ID 是低耦合、高效率的工具，能直接指向我们关心的元素，且运行更快。
过度工程化难以扩展：使用 AI 来修复不稳定的测试和适应 UI 变化增加了另一层复杂性，意味着更多不可控的点。如果 AI 模型抽风了，不仅测试会失败，还需要进行 AI 调试。
测试周刊-憧憬五一的第一周
清明过后似乎会更加期待劳动节一些。
今年五一放五天假，时间是充裕的，但想到各大景点的人山人海，可能最终还是会选择躲在家里吧。
看看书，在附近活动活动，陪陪家人，安静的时光就足够了吧。
AI 工具
最近在读一本关于二战时期太平洋战争的书，里面一些细节很有意思。
比如美军在珍珠港被空袭之后大概一年的时间里，一直在边打仗边学习。
因为美军中大部分将军和士兵都没有经历过真正的战争。
因此战争初期配合失误和自身混乱的情况时有发生。
感觉跟最近的 AI 热潮很像，大部分人都没有既往的经验，只能边用边学。
在实战中创新。
这两周跟 AI 相关的测试动态里，最让人眼前一亮的就是 playwright 发布了官方的 MCP 支持。
github 地址在这里:https://github.com/microsoft/playwright-mcp。
目前 7k+的 star，热度还是很高的。
看一下官方介绍。
基于 Playwright 实现浏览器自动化的 MCP。该服务器使大语言模型(LLM)能够通过结构化的可访问性快照与网页交互，无需依赖截图或视觉模型。
核心优势
- 快速轻量 ：采用 Playwright 的无障碍访问树技术，非像素级输入 - 适配 LLM：无需视觉模型，完全基于结构化数据操作
- 确定性操作 ：避免基于截图方法常见的歧义问题
应用场景
- 网页导航与表单填写(自动化操作)
- 结构化内容数据提取(爬虫)
- LLM 驱动的自动化测试(自动化测试)
- 智能体的通用浏览器交互接口(通用操作)
既然做 UI 自动化又难又花时间，那么不如让大语言模型帮助我们去实现吧。
目前已经看到有人使用 Playwright + Cursor + MCP Server 跑通了自动化测试的流程。
具体效果在这里：https://www.youtube.com/watch?v=cNh3_r6UjKk
AI 测试策略
https://testingtitbits.com/ai-usage-for-testers-quadrants-model/ 这篇文章里作者讨论了 AI 的测试策略。
作者把测试工作分成了 4 个象限。
3个最没用的质量指标(以及可以用哪些指标去替代)
看到一篇讨论质量指标的文章。
文中描述了 3 个过时的不推荐继续使用的指标。