手动测试
在我 2025 年的 QA 工作流程中,依然高度依赖手动测试深度——基于人的直觉、细致入微的观察和批判性思维——去发现自动化可能遗漏的问题。手动测试让我能够站在终端用户的角度,探索真实场景,并捕捉脚本容易忽略的细微可用性问题或极端情况。在软件测试生命周期(STLC)的指导下,我遵循结构化流程,从需求分析到测试收尾的每一个阶段,确保测试的一致性、可追溯性和充分覆盖。STLC 中的每个阶段都在塑造高质量、可靠的产品方面发挥关键作用,并帮助相关方对功能发布充满信心。

©️ 图片来源:Capital Commerce
- 需求分析 – 我评估需求是否清晰、可测试且完整,并在深入之前尽早挖掘潜在边界情况。
示例: 在 Giti 佳通轮胎的官网改版项目中,我审阅了 Figma 设计稿和功能规格,确保诸如“查找经销商”地图、轮胎对比工具以及首页横幅等元素都有明确的展示规则。例如,我确认了精选区应展示多少个产品,并明确当没有精选产品时页面应如何处理。
- 测试计划 – 我规划测试内容、测试方式、所需资源和时间安排,并决定哪些测试需要自动化。
示例: 针对这次改版,我规划了浏览器兼容性检查(Chrome、Firefox、Safari、Edge)、移动端响应式测试,以及面向佳通轮胎各国际市场的区域化内容校验。由自动化脚本完成重复性的链接检查,而手动测试则用于验证设计还原度和整体导航流畅性。
- 测试用例设计 – 我编写详细的手动测试用例(以及在合适场景下的自动化脚本),为一致且可重复的测试覆盖打好基础。
示例: 针对产品详情页的一个测试用例,包括验证轮胎图片是否为高分辨率加载,“规格”页签是否显示正确的技术参数,以及所有内部链接是否跳转到预期位置。我还设计了负向用例,例如当内容缺失时,是否能正确展示回退提示信息。
- 测试环境搭建 – 我确保测试环境与生产环境高度一致,包括数据、配置,并通过快速的冒烟测试来确认环境是否就绪。
示例: 在预发布环境中,我导入了真实的轮胎 SKU、经销商地址以及促销横幅,以模拟产品正式上线时的状态。在开始完整执行前,我还验证了在各目标区域内,搜索结果是否能显示正确的轮胎型号和经销商信息。
- 测试执行 – 我手动执行测试用例,仔细观察每一个细节,记录缺陷,并验证修复方案的有效性。
示例: 在测试改版后首页时,我发现 Safari 移动端在放大页面时,主导航栏会与佳通轮胎的 Logo 发生重叠。我附上截图记录了该问题,建议通过 CSS 调整来修复,并在修复后重新进行了测试。
- 测试周期收尾 – 我汇总测试结果,评估实际覆盖率与目标之间的差距,并反思经验教训以改进后续测试工作。
示例: 上线后,我整理了所有测试发现,记录频繁出现的 UI 对齐问题,并建议在未来的改版中扩展设备/浏览器测试矩阵。上线后的数据分析显示轮胎搜索页面的跳出率有所下降,验证了用户体验的提升。
我常用的手动测试类型:
-
功能测试 – 确保每个功能都符合规格说明和业务需求。
示例: 验证佳通轮胎官网上的“查找经销商”搜索功能是否能准确返回正确的门店位置,并在地图上正确显示。
-
探索性测试 – 通过无脚本、创造性地探索应用来发现隐藏或意料之外的错误。
示例: 在改版后的网站上随机调整浏览器窗口大小,或在不同语言之间切换,以发现布局错乱或未翻译的文本。
-
验收测试 / UAT(用户验收测试) – 在发布前验证软件是否满足终端用户需求和业务目标。
示例: 与市场团队相关人员一起完整体验改版后的轮胎浏览流程,确保其与佳通轮胎的客户体验目标保持一致。
-
回归测试 – 确认新的变更或修复没有破坏现有功能。
示例: 在更新首页横幅轮播组件后,重新检查经销商搜索、产品筛选和页脚链接等功能是否仍然正常工作。
-
冒烟测试 – 在进行更深入测试之前,对关键路径进行快速、粗略的检查,确认核心功能可用。
示例: 在新的预发布版本上,确认首页加载正常、导航菜单工作正常、轮胎详情页可以无报错地打开。
-
跨浏览器测试 – 验证在不同浏览器、设备和操作系统下行为和显示是否一致。我们使用浏览器开发者工具以及 Browserstack。
示例: 在 Chrome、Safari、Firefox 和 Edge 上测试改版后的网站,并在 iOS 和 Android 的移动端浏览器上检查,确保布局和功能一致。
-
性能测试 – 在不同负载条件下评估系统的响应速度、稳定性和可扩展性。在佳通轮胎改版项目中,我还使用了 GTmetrix 测量页面加载速度、核心网页指标(Core Web Vitals)以及整体性能评分,确保网站符合现代性能标准。
示例: 对首页和轮胎搜索结果页运行 GTmetrix 测试,然后与开发人员合作,优化过大的图片和未使用的 CSS 导致的加载速度变慢问题。

©️ 图片来源:qawerk
自动化测试
虽然手动测试能够提供精确性和洞察力,但自动化测试才是我的制胜法宝——它可以加速重复性检查、提升测试覆盖率,并在问题进入生产环境前捕获回归缺陷。我最初使用 Selenium 开始自动化之旅,但在 2025 年我已经完全转向使用 Playwright,因为它速度更快、更稳定,并具备针对现代 Web 应用程序量身定制的特性。

©️ 图片来源:TestTribe
为什么 Playwright 是我自动化测试的强大工具:
-
原生跨浏览器 & 跨平台支持 – Playwright 允许我在 Chromium、Firefox 和 WebKit(Safari 引擎)上无缝运行同一套测试,无需额外配置或维护多套代码库,从而确保在所有主流浏览器上都具备一致的用户体验。
-
执行速度极快 – 得益于其优化的架构,测试运行快速且稳定,大幅减少了其他框架常见的“测试结果不稳定”问题,让我可以减少在调试上的时间,把更多精力投入到交付高质量的产品。
-
内置 API 测试 – 我可以在同一测试套件中同时验证后端服务和前端 UI 流程,无需在多个工具之间切换,就可以简化测试并提升端到端覆盖率。
-
自动等待 & 智能断言 – Playwright 会自动等待元素就绪,并提供丰富的断言库,大幅减少因时序问题或 UI 延迟导致的测试不稳定和维护成本。
-
对现代 Web 应用的原生支持 – 无论是单页应用(SPA)、动态内容更新,还是拖拽、无限滚动等复杂交互,Playwright 的现代架构都能原生处理,无需复杂的变通方案。
如何高效构建并维护自动化:
-
借助 Cursor – 这款强大的 AI 辅助工具帮助我快速搭建 Playwright 测试、重构现有脚本以提升可读性和性能,并在不同项目间保持统一的编码风格,从而加速开发并降低新成员入门门槛。
-
紧密集成 CI/CD – 自动化测试会在每次代码提交或构建时,通过 GitHub Actions、Jenkins 或 Azure DevOps 等流水线运行自动化测试。持续测试能够及早发现回归问题,避免发布带缺陷的版本,并为开发人员提供快速反馈。
-
平衡的测试策略 – 我会有策略地使用自动化来覆盖快速、重复性强以及高风险的场景,以最大化覆盖率和执行速度,同时将手动测试保留给探索性测试、可用性测试以及需要人类直觉和创造力的复杂边界情况测试。这种“人工 + 自动化”的混合方法,既保证效率,又兼顾深度。
借助 AI 测试
我目前使用 Cursor AI(基于 Claude Sonnet 模型)来加速测试脚本的编写并提升整体测试效率。这款先进的 AI 能够快速生成准确的测试场景,使冒烟测试和回归测试周期更短。除了脚本生成之外,Cursor AI 还会协助重构已有测试用例,以提升可读性和可维护性,减少人工工作量和人为错误。它还能提出人工设计测试时可能忽略的边界情况和变体,从而提高测试覆盖率和健壮性。通过与我的 Playwright 流程无缝集成,Cursor AI 让我能够更快速地迭代,把更多精力投入到探索性测试和复杂验证上,同时将日常的测试生成工作交给智能 AI 完成。

©️ 图片来源:Cursor
将 AI 集成到测试流程中的关键收益包括:
-
以最少人工投入加速脚本生成 — 像 Cursor 这样的 AI 工具可以基于需求或现有代码快速生成高质量测试脚本,大幅减少测试人员在日常脚本编写上的时间投入。
-
优先聚焦高风险用例,及早发现缺陷 — 通过分析代码变更、历史缺陷数据和使用模式,AI 能帮助识别风险最高的测试用例,使测试更聚焦,从而更早发现关键缺陷。
-
通过 AI 建议的边界场景提升覆盖率 — AI 算法可以提出不太明显的场景和边界条件,而这些场景和条件往往会在人工设计测试时被遗漏,从而增强测试过程的全面性。
-
利用机器学习进行异常检测,捕捉意外问题 — 机器学习模型会监控测试结果和应用行为,标记偏离正常模式的异常,为隐藏或间歇性缺陷提供预警。
-
聚焦高价值测试,优化测试流程 — AI 能根据近期代码变更和测试历史,推荐哪些测试应该执行、哪些可以跳过,在保证质量的前提下节省时间和资源。
-
规划引入 AI Agent,实现自动执行与自愈脚本 — 展望未来,我计划利用 AI 驱动的智能代理,实现测试的自主执行;当 UI 发生变化时,脚本可以自动修复(自愈),以最少的人为干预持续完成验证。
结语
将手动测试、自动化测试和 AI 相结合,构建出一个平衡而强大的 QA 体系,充分发挥各自优势。这种协同能够实现更快、更智能的测试,并在当今复杂的开发环境中保障更高质量的软件。拥抱这三者,是在 2025 年及以后保持竞争力、持续交付卓越用户体验的关键。