测试周刊 on 重定向学院

测试周刊008: AI 在测试中有深度的应用了?

Fri, 25 Jul 2025 10:26:47 +0800

本期内容再次印证了软件测试行业正在经历的深刻变革。从传统的手工测试向智能化测试转变，从技术层面的优化到文化层面的重塑，我们看到测试工程师们不仅要掌握新兴的 AI 工具，更需要具备战略思维和质量意识的深度转变。

测试周刊007: AI 测试工具2025上半年盘点

Thu, 03 Jul 2025 16:26:47 +0800

2025 年已经过去一半了，这半年里，ai 与测试工具的结合有了不少进展。

今天我们就一起来盘点一下。

测试周刊006: playwrightv1.53的新功能

Thu, 26 Jun 2025 16:26:47 +0800

在一个已有开发节奏的团队中，作为第一位测试人员去推行新流程，绝非易事。

你会被开发质疑：是不是要拖慢上线进度？是不是要卡死流程，让整个开发团队都不爽？

这些成见不是你的错，但你必须面对它们。

pydoll 初体验

之前介绍过一款新的 ui 自动化测试工具—-pydoll。

今天抽空在 github 的 copilot 的帮助下试用了一下。

我用 pydoll 实现了一个测试任务列表的测试套件，包含 5 个测试用例。

具体用例如下

import asyncio
import os
import unittest
from pydoll.browser.chromium import Chrome
from pydoll.browser.options import ChromiumOptions
from pydoll.constants import Key

class TestTodoMVC(unittest.IsolatedAsyncioTestCase):
 async def asyncSetUp(self):
 options = ChromiumOptions()
 options.add_argument('--start-maximized')
 options.add_argument('--disable-notifications')
 self.browser = Chrome(options=options)
 self.tab = await self.browser.start()
 await self.tab.go_to('https://todomvc.com/examples/react/dist/')

 async def asyncTearDown(self):
 await self.browser.__aexit__(None, None, None)

 async def test_add_todo(self):
 new_todo = await self.tab.find(class_name='new-todo', timeout=5, raise_exc=True)
 await new_todo.type_text("Install pydoll")
 await asyncio.sleep(1)
 await new_todo.press_keyboard_key(Key.ENTER)
 todo_items = await self.tab.find(class_name = 'view', timeout=5, find_all=True, raise_exc=True)
 found = False
 texts = []
 for item in todo_items:
 text = await item.text
 texts.append(text)
 if "Install pydoll" in text:
 found = True
 break
 self.assertTrue(found)

 async def test_complete_todo(self):
 await self.test_add_todo()
 toggle = await self.tab.find(class_name="toggle", timeout=5, raise_exc=True)
 await toggle.click()
 completed = await self.tab.find(class_name='completed', timeout=5, raise_exc=True)
 self.assertIsNotNone(completed)

 async def test_delete_todo(self):
 await self.test_add_todo()
 todo_item = await self.tab.find(class_name='view', timeout=5, raise_exc=True)
 await todo_item.click()
 destroy_btn = await todo_item.find(class_name='destroy', timeout=5, raise_exc=True)
 await destroy_btn.click()
 todo_items = await self.tab.find(class_name='view', find_all=True)
 found = False
 for item in todo_items:
 if "Install pydoll" in item.text:
 found = True
 break
 self.assertFalse(found)

 async def test_filter_todo(self):
 await self.test_add_todo()
 toggle = await self.tab.find(class_name="toggle", timeout=5, raise_exc=True)
 await toggle.click()
 active_filter = await self.tab.find(text="Active", timeout=5, raise_exc=True)
 await active_filter.click()
 await asyncio.sleep(1)
 active_items = [item for item in await self.tab.find(class_name = 'view', find_all=True)]
 self.assertEqual(len(active_items), 0)
 completed_filter = await self.tab.find(text="Completed", timeout=5, raise_exc=True)
 await completed_filter.click()
 await asyncio.sleep(1)
 completed_items = await self.tab.find(class_name = 'view', find_all=True)
 found = False
 for item in completed_items:
 title = await item.text
 if "Install pydoll" in title:
 found = True
 break
 self.assertTrue(found)

 async def test_screenshot(self):
 await self.test_add_todo()
 screenshot_path = os.path.join(os.getcwd(), 'pydoll_repo.png')
 await self.tab.take_screenshot(path=screenshot_path)
 self.assertTrue(os.path.exists(screenshot_path))

if __name__ == "__main__":
 unittest.main()

上面的代码实现了

测试周刊005: Google是怎么做测试的

Thu, 19 Jun 2025 10:12:22 +0800

在 Google 早期，测试并不是首要任务。公司文化高度依赖工程师的才华——聪明的人写聪明的代码。大多数情况下，这种方式都很有效。少数系统部署了集成测试，但广泛的、结构化的测试极其罕见。这就像软件开发的"狂野西部"时代。

测试周刊004: 单元测试和接口测试用例将成为标配

Fri, 30 May 2025 09:26:37 +0800

马上就到端午假期了。

今天在电梯听到两位女士的对话，大概的意思是一位认为只有一天的假期有点不太过瘾，而另一位觉得假期归来以后上 4 休 2 已经是非常划算了。

反正我是同意后者的。

观点

AI 将使得单元测试和接口测试成为标配

前些天 deepseek 发布了新模型，该模型在代码能力上有了较大的提升。

有人尝试之后表示模型不仅可以正确实现编码需求，还可以在生成代码的同时给出完整的单元测试用例。

今后将有越来越多的代码会由 ai 实现，而我们可以非常自信的要求 ai 在给出实现的同时，给出完成的单元测试用例和接口测试用例。

因此在不久的将来，单元测试用例和接口测试用例将会成为增量代码的标配了吧。

测试同学可能不需要人人都会写单元测试用例了，但是学会看懂测试用例，并用测试思维来对用例进行评审，反而是更实用的技能了。

从质量保证到集成保证

https://medium.com/@sean.zhang/lets-rethink-the-role-of-qa-it-s-not-about-owning-quality-ed159d0a424b

传统的"质量保证"概念存在两个极端问题：

过度依赖 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: 大模型时代测试将会变得更加重要

Fri, 09 May 2025 09:36:02 +0800

五一假期结束了。

这次五一完美的错峰出行。

核心的原因是起的早。

天刚亮就出发，第一波到达景区，人流汹涌的时候就回酒店休息。

世间的喧闹与我无关。

这大概是一种错位竞争吧。

比如，当测试都在千军万马涌入新领域的时候，业务在原有的业务上进行深耕反而会取得一些错位竞争的优势。

观点

测试将会变得越来越重要

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不应该用来解决本来就不存在的问题

Thu, 17 Apr 2025 16:05:24 +0800

离五一只有两周了。

最近有朋友买了 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 调试。

测试周刊-憧憬五一的第一周

Fri, 11 Apr 2025 09:16:18 +0800

清明过后似乎会更加期待劳动节一些。

今年五一放五天假，时间是充裕的，但想到各大景点的人山人海，可能最终还是会选择躲在家里吧。

看看书，在附近活动活动，陪陪家人，安静的时光就足够了吧。

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 个象限。