手动测试

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

©️ 图片来源：Capital Commerce

1. 需求分析 – 我评估需求是否清晰、可测试且完整，并在深入之前尽早挖掘潜在边界情况。
   示例： 在 Giti 佳通轮胎的官网改版项目中，我审阅了 Figma 设计稿和功能规格，确保诸如“查找经销商”地图、轮胎对比工具以及首页横幅等元素都有明确的展示规则。例如，我确认了精选区应展示多少个产品，并澄清当没有精选产品时页面应如何处理。
2. 测试计划 – 我规划需要测试的内容、测试方式、所需资源和时间安排，并同时决定哪些部分适合自动化。
   示例： 针对这次改版，我规划了浏览器兼容性检查（Chrome、Firefox、Safari、Edge）、移动端响应式测试，以及面向佳通轮胎各国际市场的区域化内容校验。重复性的链接检查由自动化脚本完成，而手动测试则用于验证设计还原度和整体导航流畅性。
3. 测试用例设计 – 我编写详细的手动测试用例（以及在合适场景下的自动化脚本），为一致且可重复的覆盖打好基础。
   示例： 针对产品详情页的一个测试用例，包括验证轮胎图片是否为高清加载，“规格”页签是否展示正确的技术参数，以及所有内部链接是否跳转到预期位置。我还设计了负向用例，例如当内容缺失时，是否能正确展示回退提示信息。
4. 测试环境搭建 – 我确保测试环境尽可能贴近生产环境——包括数据、配置，并通过快速的冒烟测试来确认环境就绪。
   示例： 在预发布环境中，我导入了真实的轮胎 SKU、经销商地址以及促销横幅，以模拟正式上线时的状态。在开始完整执行前，我还验证了在各目标区域内，搜索结果是否能显示正确的轮胎型号和经销商。
5. 测试执行 – 我按照手动测试用例进行执行，观察每一个细节，记录缺陷，并在修复后进行验证。
   示例： 在测试改版后首页时，我发现 Safari 移动端在放大页面时，主导航会与佳通轮胎的 Logo 发生重叠。我附上截图记录了该问题，并建议通过 CSS 调整来修复，修复上线后又进行了回归验证。
6. 测试周期收尾 – 我汇总测试结果，评估实际覆盖与目标之间的差距，并沉淀经验以改进后续测试。
   示例： 上线后，我整理了所有测试发现，记录频繁出现的 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 年及以后保持竞争力、持续交付卓越用户体验的关键。