测试周刊007: AI 测试工具2025上半年盘点
2025 年已经过去一半了,这半年里,ai 与测试工具的结合有了不少进展。
今天我们就一起来盘点一下。
文章 图文教程 分类 标签 视频教程 playwright
2025 年已经过去一半了,这半年里,ai 与测试工具的结合有了不少进展。
今天我们就一起来盘点一下。
在一个已有开发节奏的团队中,作为第一位测试人员去推行新流程,绝非易事。
你会被开发质疑:是不是要拖慢上线进度?是不是要卡死流程,让整个开发团队都不爽?
这些成见不是你的错,但你必须面对它们。
之前介绍过一款新的 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()
上面的代码实现了
在 Google 早期,测试并不是首要任务。公司文化高度依赖工程师的才华——聪明的人写聪明的代码。大多数情况下,这种方式都很有效。少数系统部署了集成测试,但广泛的、结构化的测试极其罕见。这就像软件开发的"狂野西部"时代。
马上就到端午假期了。
今天在电梯听到两位女士的对话,大概的意思是一位认为只有一天的假期有点不太过瘾,而另一位觉得假期归来以后上 4 休 2 已经是非常划算了。
反正我是同意后者的。
前些天 deepseek 发布了新模型,该模型在代码能力上有了较大的提升。
有人尝试之后表示模型不仅可以正确实现编码需求,还可以在生成代码的同时给出完整的单元测试用例。
今后将有越来越多的代码会由 ai 实现,而我们可以非常自信的要求 ai 在给出实现的同时,给出完成的单元测试用例和接口测试用例。
因此在不久的将来,单元测试用例和接口测试用例将会成为增量代码的标配了吧。
测试同学可能不需要人人都会写单元测试用例了,但是学会看懂测试用例,并用测试思维来对用例进行评审,反而是更实用的技能了。
传统的"质量保证"概念存在两个极端问题:
作者认为传统的"质量保证"(QA)概念存在误导性,因为质量应该是每个团队的共同责任,而不是 QA 部门的专属职责。
他提出将 QA 重新定义为"集成保证"(Integration Assurance),专注于验证现代软件系统中多个服务和组件之间的协同工作,就像苹果公司需要确保 iPhone 各个供应商的零件能完美集成一样。
这个角色类似足球比赛中的守门员——不是唯一的防线,但是防止问题到达用户的最后屏障,同时帮助发现系统级的协调问题和集成风险,而 AI 测试工具应该主要由这个集成保证团队来使用,以确保从全局视角进行有效的端到端验证。
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 渲染,通过合理使用测试替身可以让每个测试都有明确的目的和可预测的结果。
五一假期结束了。
这次五一完美的错峰出行。
核心的原因是起的早。
天刚亮就出发,第一波到达景区,人流汹涌的时候就回酒店休息。
世间的喧闹与我无关。
这大概是一种错位竞争吧。
比如,当测试都在千军万马涌入新领域的时候,业务在原有的业务上进行深耕反而会取得一些错位竞争的优势。
https://filiphric.com/testing-will-become-more-important-not-less
作者认为在 LLM 时代,测试将会变得举足轻重,并给出了几个预测。
https://qualityeng.substack.com/p/the-three-mindsets-of-a-qe
离五一只有两周了。
最近有朋友买了 cursor 的会员,我驻足观看了一番。
他先描述需求,然后让大模型生成原型,接着又让 LLM 根据原型来生成前后端项目的代码。
整体流程一气呵成,看着非常有科幻感。
不难想象,接下来根据可以工作的前后端代码就可以让大模型来生成 ui 和接口的自动化测试用例。
不久的将来,通过 AI 生成的各种测试代码可能会是开发标准输出的一部分了吧。
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 调试。