最近在技术社区看到一个很扎心的问题标题翻译过来就是手动 QA 在你们的研发流程里还有位置吗提问者不像是在挑事更像是被逼到了墙角——自动化覆盖率已经不低CI 跑得越来越快可是每次版本上线前还是心慌总觉得差了一道保险。这种感觉做过后端、搞过企业级应用、维护过复杂业务系统的团队应该都不陌生。我的判断很明确手动 QA 不会消失但它的定位必须变。如果手动 QA 还停留在“人工照着需求文档点一遍功能”的阶段那它在任何一个追求快速迭代的团队里都会越来越尴尬如果把它重新定义为“业务风险的守门人 自动化体系的设计者”它反而是质量保障里最不能被砍掉的那一环。围绕这个判断这篇文章会把下面几件事讲清楚手动 QA 和自动化测试的分工边界到底划在哪里手动 QA 应该在研发流程的哪个节点介入以什么形式介入手动 QA 的产出如何结构化如何避免沦为“无记录的点点点”手动 QA 和自动化测试如何协作才能既保住质量又不太拖迭代速度手动 QA 的效果怎么衡量如何在团队里自证价值。如果你正在纠结“我们团队要不要养测试”或者刚接手质量体系想动手改造这篇文章值得读完再收藏。1. 手动 QA 为什么变成今天的争议话题先把这个问题的时代背景说清楚。十年前很多团队的节奏是开发写完代码交给测试测试在测试环境里把功能从头到尾过一遍提缺陷单开发修测试再回归。这个模式下测试人员几乎是唯一的“质量闸门”手动执行占据绝对主流。这几年 CI/CD 和敏捷开发把节奏彻底改变了。功能分支可以随时合并流水线每天跑几十次版本按周甚至按天发。在这种节奏里如果每一轮都靠人工把全量功能点一遍手动 QA 很快就会成为发布链路的最大瓶颈。于是很多团队的选择是让自动化测试覆盖回归把测试人员转去做自动化脚本或者干脆不设专职 QA让开发自己负责质量。但问题随之而来。自动化测试能守住“这个功能不再坏”却很难回答“这个功能在真实业务中是不是真的能用”。尤其当需求描述模糊、交互逻辑复杂、历史数据五花八门的时候自动化用例反而会把错误固化下来——测试全绿上线还是出事故。所以在 HN 上那个讨论里真正让大家争论不休的不是“要不要手动测试”而是“手动测试到底应该承担什么职责”。我的观点是手动 QA 不应该作为自动化的对立面存在而应该作为自动化的上游存在。自动化负责“已知问题的回归”手动 QA 负责“未知问题的发现”和“业务风险的判断”。没有前者团队走不快没有后者团队走不稳。2. 手动 QA 与自动化测试的分工逻辑很多团队在规划质量体系时喜欢把手动测试和自动化测试当成两条路非此即彼。这个框架本身就错了。正确的分法不是按“谁来执行”分而是按“被测对象的状态”分对已知的、稳定的、可重复校验的功能用自动化。对新增的、模糊的、依赖业务判断的功能用手动测试。对需要随机探索、边界验证、异常数据冲击的场景用手动测试。对核心链路、高频回归、需要长期守护的老功能逐步迁移到自动化。用一张表对比更直观维度自动化测试手动 QA执行成本前期开发高后期执行几乎为零每次都要投入人力时间反馈速度秒级到分钟级通常小时级到天级覆盖能力适合确定性的输入输出校验适合不确定性、探索性场景发现缺陷类型以逻辑错误、接口错误、崩溃为主以业务设计缺陷、体验问题、数据问题为主维护成本需求变化时需要同步修改用例需求变化时更新手动用例成本较低对测试人员要求需要具备编程和框架能力需要具备业务理解和场景设计能力这条分工逻辑的落点是一个健康的测试体系不应该追求“把所有用例自动化”而应该追求“自动化覆盖那些值得重复执行的用例手动 QA 聚焦那些无法被前置判定的场景”。如果一个团队把 100% 的用例都做成自动化最直接的结果是——维护成本爆炸而且用例的可信度持续下降。反过来如果 100% 都靠手动那团队就没法持续交付。在实际项目里我更推荐三七开起步成熟业务的主链路自动化回归占七成新功能和探索性场景的手动 QA 占三成。这个比例不是一个绝对标准而是一个思考起点帮助团队把精力从“谁来做测试”转到“什么场景用什么手段”。3. 手动 QA 的介入时机从需求阶段就要进场手动 QA 最容易踩的坑是等到开发提测才进场。这时候需求已经实现了所有设计层面的问题都已经固化进代码手动 QA 能做的只剩“挑毛病”而很多毛病改起来成本极高。正确做法是把手动 QA 的介入点提前到需求评审阶段。这一步做的事不是检查代码而是检查需求的“可测性”需求中的业务规则有没有歧义主流程之外有没有隐含的边界条件异常分支、幂等性、并发、权限边界是否被定义验收标准是否明确到可以写出用例我建议每个项目都使用一个提测入口标准达不到标准的一律退回。下面是一份适合中小团队的入口检查清单检查项说明是否满足需求文档已评审产品、开发、测试三方对规则理解一致是 / 否接口文档已更新新增和变更接口有明确出入参定义是 / 否自测通过开发在本地完成主链路自测是 / 否测试环境可用环境、测试数据、账号权限就绪是 / 否已知缺陷已登记未修复问题有单可追溯是 / 否这份清单的价值不在于“卡开发”而在于把手动 QA 从“事后检查”变成“事中协作”。当测试人员在提测之前就看到需求、评审过规则、定义了场景那么真正开始手动执行的时候他关心的就不是“按钮能不能点”而是“这个需求到底有没有被正确实现”。另外手动 QA 还应该在发布评审阶段参与。上线前最重要的问题不是“测试用例跑没跑过”而是“这次改动的影响面是什么”。手动 QA 可以基于对业务的整体理解判断哪些“看似无关”的模块可能被影响然后安排相应的回归范围。这种风险判断能力是自动化测试无法替代的。4. 手动 QA 的核心工作流设计手动 QA 最怕的不是没有时间执行而是执行完没有留下任何可供追溯的信息。很多团队的手动测试本质上是“测试人员在测试环境点了一遍”既没有用例记录也没有执行结果记录更谈不上风险量化。这会让测试变成一种“人肉黑箱”出了问题也无法复盘。要解决这个问题必须把手动 QA 也当成一个“工程化过程”来设计而不是简单的人工操作。核心工作流建议拆成四步测试计划定义本次测试的目标、范围、风险点、执行顺序。测试用例以结构化的方式记录场景描述、前置条件、操作步骤、预期结果。执行与记录按用例执行记录实际结果对失败项登记缺陷。回归与结论修复后回归验证输出测试报告和上线建议。下面给出一份可以直接使用的测试计划模板Markdown 格式建议直接放进项目的docs/test-plan目录# 测试计划订单模块 V2.0 ## 1. 本次测试范围 - 新增优惠券叠加规则 - 变更订单取消后的库存回滚逻辑 - 回归支付主链路、退款主链路 ## 2. 重点风险 - 优惠券叠加导致优惠金额为负值 - 库存回滚在高并发下的幂等性 - 旧订单数据兼容 ## 3. 测试环境 - 环境地址test-env-01 - 数据库order_db_v2 - 测试账号qa_user_01 / qa_user_02 ## 4. 执行安排 - 新增功能测试2 人天 - 主链路回归1 人天 - 探索性测试0.5 人天 ## 5. 通过标准 - 无 P0/P1 缺陷 - P2 缺陷全部关闭或有明确规避方案 - 主链路用例通过率 100%测试用例建议用 JSON 或表格维护方便后续导入测试管理平台。下面是一份轻量的 JSON 结构适合小团队在 Git 仓库里管理用例{ test_suite: 订单模块-支付流程, test_cases: [ { id: TC-ORDER-01, title: 用户使用优惠券后支付成功, precondition: 用户已登录账户有可用优惠券, steps: [ 在商品页选择商品并加入购物车, 进入结算页选择优惠券, 点击支付使用模拟支付渠道完成支付, 跳转到订单详情页 ], expected: 支付成功后订单状态显示已支付优惠券标记为已使用, priority: P0 }, { id: TC-ORDER-02, title: 优惠金额大于订单金额时不允许提交, precondition: 用户已登录存在面额大于商品金额的优惠券, steps: [ 在结算页选择该优惠券, 观察页面提示, 尝试提交订单 ], expected: 页面提示优惠券不可用提交被拦截, priority: P1 } ] }这份模板的核心点是每条用例都有明确的步骤和预期结果。如果没有预期结果执行者就只能“凭感觉判断”最后给出的测试结论会非常主观。手动 QA 的工程化首先要从“用例可执行、结果可断言”开始。执行环节要注意手动 QA 一定不能只执行自己设计的用例还要留出独立的探索性测试时间。探索性测试的特点是“没有脚本但有目标”比如“围绕库存回滚这件事用各种异常顺序去点”。探索性测试发现的问题往往是自动化用例和常规手动用例都覆盖不到的深层缺陷。5. 手动 QA 与自动化测试的协作机制在很多团队里手动 QA 和自动化测试是两拨人在做甚至可以互不理会。这是一个典型的组织协作问题自动化测试人员在写脚本手动测试人员在点按钮两个动作之间没有任何信息流动。结果就是自动化用例越来越厚但手动测试人员完全不知道哪些场景已经被自动守护了每次回归依然从零开始。协作机制的第一步是让自动化测试的结果反哺手动测试的范围选择。具体做法在自动化测试框架里把用例按层级标记区分哪些用例自动化覆盖哪些用例必须手动执行。以 Python 的 pytest 为例可以通过自定义标记来区分用例类型。首先在项目根目录的pytest.ini中注册标记[pytest] markers auto: 自动化回归用例 manual: 需要手动执行的用例 smoke: 冒烟用例发布前必须通过然后在测试文件中标记用例# 文件路径tests/test_order.py import pytest pytest.mark.smoke def test_payment_success(): 主流程支付成功 assert True pytest.mark.manual def test_coupon_overlay_rule(): 手动用例优惠券叠加规则。 原因涉及金额计算与业务规则判断无法用单测可靠覆盖 需要在测试环境验证真实展示和交互。 assert True有了标记之后可以很方便地在 CI 中把两类用例分开执行。比如 CI 只跑auto和smoke而把manual标记的用例生成一份待执行清单同步给测试人员作为手动回归的输入。在 GitHub Actions 或 GitLab CI 中还可以用“手动触发”来承接测试审批的环节。以 GitLab CI 为例可以把发布前的冒烟测试和手动验收定义为独立的 job# 文件路径.gitlab-ci.yml stages: - test - verify - deploy auto-test: stage: test script: - pytest -m auto or smoke --junitxmlreport.xml artifacts: when: always reports: junit: report.xml manual-qa: stage: verify script: - echo 请测试人员在测试环境完成手动验收 - echo 访问测试地址https://test.example.com - echo 验收通过后点击本 Job 的 Play 按钮继续发布 when: manual allow_failure: false deploy: stage: deploy script: - echo 进入发布流程 needs: - manual-qa这段配置的逻辑是自动化测试跑完后进入一个等待手动确认的阶段。测试人员在实际环境中完成手动验收后手动点击执行manual-qa这个 Job发布流程才会继续。这套机制把“手动 QA”从“线下口头确认”变成了“流程里不可跳过的一环”既保证了质量闸门也留下了审计记录。从实践来看真正高效的协作状态是手动 QA 把探索过程中发现的高价值场景“反哺”成新的自动化用例自动化用例释放手动 QA 的时间让测试人员有精力去做更深度的探索。两者不是并行关系而是迭代关系。6. 如何验证手动 QA 的产出与效果手动 QA 在团队里地位低的另一个原因是它的产出很难量化。自动化测试可以说“我们有多少用例、覆盖率多少、跑了多少次”手动 QA 如果只有一句“测过了”那确实很难让人信服。要改变这种局面建议至少追踪下面几个指标指标计算方式说明需求覆盖数实际执行用例覆盖的需求数 / 本期需求总数防止“测了但没覆盖全部需求”缺陷发现数手动测试期间提交的有效缺陷数衡量执行密度和业务理解深度测试用例通过率通过用例数 / 执行用例总数衡量本轮代码质量缺陷逃逸率发布后发现的高级别缺陷数 / 总缺陷数衡量 QA 闸门的有效性自动转化率本轮手动用例转化自动化的数量衡量手动 QA 的长期贡献其中最值得关注的是“缺陷逃逸率”。它的含义是一个缺陷在测试阶段没有被发现而是上线后才被用户或者监控发现。这个指标越低说明手动 QA 的“守门”效果越好。如果逃逸率一直很高可能不是测试人员不努力而是介入时机太晚、测试范围太窄或者用例设计深度不够。除了指标手动 QA 还需要输出结构化的测试报告。一份好的测试报告不需要花哨但必须包含测试结论是否建议上线 测试范围覆盖了哪些模块未覆盖哪些模块 缺陷统计P0/P1/P2 缺陷数量及当前状态 风险清单已知问题、遗留缺陷、规避方案 回归建议上线后需要重点观察哪些业务指标写出这份报告的过程本质上就是在倒逼手动 QA 把注意力从“点按钮”转移到“做判断”。测试报告是手动 QA 和开发、产品对话的载体也是它自证价值的核心证据。在验证手动 QA 效果时还有一个容易被忽视的点测试数据。很多手动 QA 的缺陷都出在测试环境和生产环境的数据不一致上。所以建议团队在测试计划阶段就明确数据的准备方式优先使用脱敏后的生产数据或通过脚本构造的仿真数据再补充典型的边界数据。没有贴近真实的数据环境手动 QA 的结论天然不可信。7. 常见问题与排查思路手动 QA 在落地过程中最常见的问题基本都集中在流程和执行层面。下面把高频问题整理成一张排查表。问题现象可能原因排查方式解决方案手动 QA 用例没人维护需求变了用例还停留在旧逻辑用例缺少责任人变更时没有同步更新检查用例最后修改时间和需求关联在需求评审中明确用例更新责任人测试环境不稳定手动执行频繁被环境问题打断环境缺少配置管理数据污染严重查看环境初始化和数据准备流程环境扫码自动化恢复测试数据脚本化手动 QA 变成了自动化的“附属品”团队只考核自动化覆盖率忽略业务探索分析缺陷来源和测试报告内容重新定义考核指标加入探索性测试时间手动 QA 执行时间长版本发布总是等测试用例粒度太粗或执行内容重复审查用例是否有冗余步骤划分冒烟、主链路、深度回归三级用例缺陷被开发直接拒绝测试结论没有影响力缺陷单缺少必要信息和复现步骤抽查缺陷单的质量要求缺陷单包含环境、数据、步骤、期望和实际结果自动化覆盖率和手动 QA 脱节两边各测各的缺少用例标记和任务流转机制观察 CI 配置和测试任务分配流程用 pytest 标记或测试管理平台实现任务同步这里特别想展开说明一个容易被忽视但杀伤力很大的场景手动 QA 发现了一个缺陷缺陷单也提了但开发在下一轮迭代里“顺手修了”既没有关联测试用例也没有触发回归验证。等到正式发布的时候这个缺陷的验证状态是模糊的一旦修复方式引入新问题测试团队完全不知道。针对这个问题建议缺陷单必须关联到具体的测试用例 ID并设定“修复后必须回归通过才能关闭”的状态流转规则不给糊涂账留空间。另一个常见争议是“手动 QA 要不要写自动化脚本”。我的建议是不要强求。让手动 QA 人员投入大量时间学自动化框架短期会削弱最核心的业务探索能力长期也未必能培养出优秀的自动化工程师。更合理的做法是手动 QA 负责把业务场景提炼成“哪些值得做自动化”的清单自动化工程师负责实现。专业分工比全员全栈更适合质量领域。8. 最佳实践与工程建议手动 QA 要在一个团队里长期立足不能只靠个别人认真负责必须有制度和规范支撑。下面是我认为落地价值最高的几条建议。第一命名和编号规范要前置。测试计划、测试用例、缺陷单都建议使用统一的前缀和编号规则。比如用TC-模块名-序号来给用例编号用BUG-模块名-序号来给缺陷编号。这套编号体系不只是为了方便搜索更重要的是让“需求——用例——缺陷——修复——回归”之间形成可追踪的链路。第二手动 QA 的记录要尽量结构化。执行过程中发现的问题、环境信息、测试数据、例外风险都应该按固定格式记录而不是散落在聊天记录里。哪怕团队没有测试管理平台也可以用 Git 仓库维护测试记录每次执行提交一次变更这样至少能保证所有信息可回溯。第三明确不同级别用例的执行策略。可以把手动用例分为三档冒烟用例每次提测和发布前必跑控制在 10-15 条以内主链路用例覆盖核心业务闭环每次版本迭代必须执行深度回归用例按风险影响面选择执行不要求每次都完整跑。分级的好处是版本发布不那么频繁的时候可以深度回归版本迭代很快的时候可以只握守核心链路让手动 QA 的投入和风险匹配起来。第四手动 QA 和开发要保持固定的同步节奏。推荐用“测试前置沟通 提测后集中验证 发布前风险复核”三段式节奏。测试人员在开发完成前先介入提测后按用例执行发布前和开发确认遗留缺陷的规避方案避免上线前的突然拉扯。第五要建立“手工测试也能推动自动化”的正反馈机制。每轮手测结束后手动 QA 可以提交一批“建议自动化”的用例清单自动化团队评估后纳入计划。如果这个机制运转良好团队的手动测试负担会逐步下降而自动化测试的质量会因为用例来源更贴近真实业务而明显上升。第六也是我认为最重要的一条手动 QA 必须拥有“说上线有风险”的独立发言权。如果测试结论是“不建议发布”不应该因为业务压力或开发进度而被强行推翻。质量闸门的权威建立在流程刚性上一旦“测试说不行也能发”成为常态手动 QA 就会迅速退化成走流程的摆设后续再想重建信任会非常困难。9. 总结与后续学习方向手动 QA 的真正价值不在于“手工”这两个字而在于它提供了自动化测试难以替代的两种能力对模糊业务问题的判断能力和对未知风险的探索能力。自动化在体系里承担的是“守住底线”手动 QA 承担的是“发现上限之外的问题”。一个好的质量体系必须让这两种能力形成循环手动发现新问题自动化守住旧问题如此往复质量才会螺旋上升。如果你现在的团队还在为“要不要保留手动 QA”争论我的建议是不要直接回答“要”或“不要”而是先回答另外两个问题哪些场景自动化一定守不住测试人员在手动执行之外有没有持续积累业务判断力把这两个问题想清楚手动 QA 的定位自然就浮出水面了。后续值得继续深入的方向有三个。一是探索性测试的方法论可以学习基于风险的测试设计和 session-based test management二是自动化测试与手动测试的用例管理系统落地研究 Jira、TestRail、PingCode 这类工具如何把流程串起来三是质量度量的进阶用法比如缺陷逃逸率的趋势分析如何反向驱动研发流程改进。这三块学完你对手动 QA 的理解就不会停留在“要不要”的层面而是能真正搭建出一套质量体系。 
长河君 · 2026/10/9 2:18:15 · 阅读 1.2k 手动QA在研发流程中的价值重定位：与自动化测试协作的工程实践指南
最近在技术社区看到一个很扎心的问题标题翻译过来就是手动 QA 在你们的研发流程里还有位置吗提问者不像是在挑事更像是被逼到了墙角——自动化覆盖率已经不低CI 跑得越来越快可是每次版本上线前还是心慌总觉得差了一道保险。这种感觉做过后端、搞过企业级应用、维护过复杂业务系统的团队应该都不陌生。我的判断很明确手动 QA 不会消失但它的定位必须变。如果手动 QA 还停留在“人工照着需求文档点一遍功能”的阶段那它在任何一个追求快速迭代的团队里都会越来越尴尬如果把它重新定义为“业务风险的守门人 自动化体系的设计者”它反而是质量保障里最不能被砍掉的那一环。围绕这个判断这篇文章会把下面几件事讲清楚手动 QA 和自动化测试的分工边界到底划在哪里手动 QA 应该在研发流程的哪个节点介入以什么形式介入手动 QA 的产出如何结构化如何避免沦为“无记录的点点点”手动 QA 和自动化测试如何协作才能既保住质量又不太拖迭代速度手动 QA 的效果怎么衡量如何在团队里自证价值。如果你正在纠结“我们团队要不要养测试”或者刚接手质量体系想动手改造这篇文章值得读完再收藏。1. 手动 QA 为什么变成今天的争议话题先把这个问题的时代背景说清楚。十年前很多团队的节奏是开发写完代码交给测试测试在测试环境里把功能从头到尾过一遍提缺陷单开发修测试再回归。这个模式下测试人员几乎是唯一的“质量闸门”手动执行占据绝对主流。这几年 CI/CD 和敏捷开发把节奏彻底改变了。功能分支可以随时合并流水线每天跑几十次版本按周甚至按天发。在这种节奏里如果每一轮都靠人工把全量功能点一遍手动 QA 很快就会成为发布链路的最大瓶颈。于是很多团队的选择是让自动化测试覆盖回归把测试人员转去做自动化脚本或者干脆不设专职 QA让开发自己负责质量。但问题随之而来。自动化测试能守住“这个功能不再坏”却很难回答“这个功能在真实业务中是不是真的能用”。尤其当需求描述模糊、交互逻辑复杂、历史数据五花八门的时候自动化用例反而会把错误固化下来——测试全绿上线还是出事故。所以在 HN 上那个讨论里真正让大家争论不休的不是“要不要手动测试”而是“手动测试到底应该承担什么职责”。我的观点是手动 QA 不应该作为自动化的对立面存在而应该作为自动化的上游存在。自动化负责“已知问题的回归”手动 QA 负责“未知问题的发现”和“业务风险的判断”。没有前者团队走不快没有后者团队走不稳。2. 手动 QA 与自动化测试的分工逻辑很多团队在规划质量体系时喜欢把手动测试和自动化测试当成两条路非此即彼。这个框架本身就错了。正确的分法不是按“谁来执行”分而是按“被测对象的状态”分对已知的、稳定的、可重复校验的功能用自动化。对新增的、模糊的、依赖业务判断的功能用手动测试。对需要随机探索、边界验证、异常数据冲击的场景用手动测试。对核心链路、高频回归、需要长期守护的老功能逐步迁移到自动化。用一张表对比更直观维度自动化测试手动 QA执行成本前期开发高后期执行几乎为零每次都要投入人力时间反馈速度秒级到分钟级通常小时级到天级覆盖能力适合确定性的输入输出校验适合不确定性、探索性场景发现缺陷类型以逻辑错误、接口错误、崩溃为主以业务设计缺陷、体验问题、数据问题为主维护成本需求变化时需要同步修改用例需求变化时更新手动用例成本较低对测试人员要求需要具备编程和框架能力需要具备业务理解和场景设计能力这条分工逻辑的落点是一个健康的测试体系不应该追求“把所有用例自动化”而应该追求“自动化覆盖那些值得重复执行的用例手动 QA 聚焦那些无法被前置判定的场景”。如果一个团队把 100% 的用例都做成自动化最直接的结果是——维护成本爆炸而且用例的可信度持续下降。反过来如果 100% 都靠手动那团队就没法持续交付。在实际项目里我更推荐三七开起步成熟业务的主链路自动化回归占七成新功能和探索性场景的手动 QA 占三成。这个比例不是一个绝对标准而是一个思考起点帮助团队把精力从“谁来做测试”转到“什么场景用什么手段”。3. 手动 QA 的介入时机从需求阶段就要进场手动 QA 最容易踩的坑是等到开发提测才进场。这时候需求已经实现了所有设计层面的问题都已经固化进代码手动 QA 能做的只剩“挑毛病”而很多毛病改起来成本极高。正确做法是把手动 QA 的介入点提前到需求评审阶段。这一步做的事不是检查代码而是检查需求的“可测性”需求中的业务规则有没有歧义主流程之外有没有隐含的边界条件异常分支、幂等性、并发、权限边界是否被定义验收标准是否明确到可以写出用例我建议每个项目都使用一个提测入口标准达不到标准的一律退回。下面是一份适合中小团队的入口检查清单检查项说明是否满足需求文档已评审产品、开发、测试三方对规则理解一致是 / 否接口文档已更新新增和变更接口有明确出入参定义是 / 否自测通过开发在本地完成主链路自测是 / 否测试环境可用环境、测试数据、账号权限就绪是 / 否已知缺陷已登记未修复问题有单可追溯是 / 否这份清单的价值不在于“卡开发”而在于把手动 QA 从“事后检查”变成“事中协作”。当测试人员在提测之前就看到需求、评审过规则、定义了场景那么真正开始手动执行的时候他关心的就不是“按钮能不能点”而是“这个需求到底有没有被正确实现”。另外手动 QA 还应该在发布评审阶段参与。上线前最重要的问题不是“测试用例跑没跑过”而是“这次改动的影响面是什么”。手动 QA 可以基于对业务的整体理解判断哪些“看似无关”的模块可能被影响然后安排相应的回归范围。这种风险判断能力是自动化测试无法替代的。4. 手动 QA 的核心工作流设计手动 QA 最怕的不是没有时间执行而是执行完没有留下任何可供追溯的信息。很多团队的手动测试本质上是“测试人员在测试环境点了一遍”既没有用例记录也没有执行结果记录更谈不上风险量化。这会让测试变成一种“人肉黑箱”出了问题也无法复盘。要解决这个问题必须把手动 QA 也当成一个“工程化过程”来设计而不是简单的人工操作。核心工作流建议拆成四步测试计划定义本次测试的目标、范围、风险点、执行顺序。测试用例以结构化的方式记录场景描述、前置条件、操作步骤、预期结果。执行与记录按用例执行记录实际结果对失败项登记缺陷。回归与结论修复后回归验证输出测试报告和上线建议。下面给出一份可以直接使用的测试计划模板Markdown 格式建议直接放进项目的docs/test-plan目录# 测试计划订单模块 V2.0 ## 1. 本次测试范围 - 新增优惠券叠加规则 - 变更订单取消后的库存回滚逻辑 - 回归支付主链路、退款主链路 ## 2. 重点风险 - 优惠券叠加导致优惠金额为负值 - 库存回滚在高并发下的幂等性 - 旧订单数据兼容 ## 3. 测试环境 - 环境地址test-env-01 - 数据库order_db_v2 - 测试账号qa_user_01 / qa_user_02 ## 4. 执行安排 - 新增功能测试2 人天 - 主链路回归1 人天 - 探索性测试0.5 人天 ## 5. 通过标准 - 无 P0/P1 缺陷 - P2 缺陷全部关闭或有明确规避方案 - 主链路用例通过率 100%测试用例建议用 JSON 或表格维护方便后续导入测试管理平台。下面是一份轻量的 JSON 结构适合小团队在 Git 仓库里管理用例{ test_suite: 订单模块-支付流程, test_cases: [ { id: TC-ORDER-01, title: 用户使用优惠券后支付成功, precondition: 用户已登录账户有可用优惠券, steps: [ 在商品页选择商品并加入购物车, 进入结算页选择优惠券, 点击支付使用模拟支付渠道完成支付, 跳转到订单详情页 ], expected: 支付成功后订单状态显示已支付优惠券标记为已使用, priority: P0 }, { id: TC-ORDER-02, title: 优惠金额大于订单金额时不允许提交, precondition: 用户已登录存在面额大于商品金额的优惠券, steps: [ 在结算页选择该优惠券, 观察页面提示, 尝试提交订单 ], expected: 页面提示优惠券不可用提交被拦截, priority: P1 } ] }这份模板的核心点是每条用例都有明确的步骤和预期结果。如果没有预期结果执行者就只能“凭感觉判断”最后给出的测试结论会非常主观。手动 QA 的工程化首先要从“用例可执行、结果可断言”开始。执行环节要注意手动 QA 一定不能只执行自己设计的用例还要留出独立的探索性测试时间。探索性测试的特点是“没有脚本但有目标”比如“围绕库存回滚这件事用各种异常顺序去点”。探索性测试发现的问题往往是自动化用例和常规手动用例都覆盖不到的深层缺陷。5. 手动 QA 与自动化测试的协作机制在很多团队里手动 QA 和自动化测试是两拨人在做甚至可以互不理会。这是一个典型的组织协作问题自动化测试人员在写脚本手动测试人员在点按钮两个动作之间没有任何信息流动。结果就是自动化用例越来越厚但手动测试人员完全不知道哪些场景已经被自动守护了每次回归依然从零开始。协作机制的第一步是让自动化测试的结果反哺手动测试的范围选择。具体做法在自动化测试框架里把用例按层级标记区分哪些用例自动化覆盖哪些用例必须手动执行。以 Python 的 pytest 为例可以通过自定义标记来区分用例类型。首先在项目根目录的pytest.ini中注册标记[pytest] markers auto: 自动化回归用例 manual: 需要手动执行的用例 smoke: 冒烟用例发布前必须通过然后在测试文件中标记用例# 文件路径tests/test_order.py import pytest pytest.mark.smoke def test_payment_success(): 主流程支付成功 assert True pytest.mark.manual def test_coupon_overlay_rule(): 手动用例优惠券叠加规则。 原因涉及金额计算与业务规则判断无法用单测可靠覆盖 需要在测试环境验证真实展示和交互。 assert True有了标记之后可以很方便地在 CI 中把两类用例分开执行。比如 CI 只跑auto和smoke而把manual标记的用例生成一份待执行清单同步给测试人员作为手动回归的输入。在 GitHub Actions 或 GitLab CI 中还可以用“手动触发”来承接测试审批的环节。以 GitLab CI 为例可以把发布前的冒烟测试和手动验收定义为独立的 job# 文件路径.gitlab-ci.yml stages: - test - verify - deploy auto-test: stage: test script: - pytest -m auto or smoke --junitxmlreport.xml artifacts: when: always reports: junit: report.xml manual-qa: stage: verify script: - echo 请测试人员在测试环境完成手动验收 - echo 访问测试地址https://test.example.com - echo 验收通过后点击本 Job 的 Play 按钮继续发布 when: manual allow_failure: false deploy: stage: deploy script: - echo 进入发布流程 needs: - manual-qa这段配置的逻辑是自动化测试跑完后进入一个等待手动确认的阶段。测试人员在实际环境中完成手动验收后手动点击执行manual-qa这个 Job发布流程才会继续。这套机制把“手动 QA”从“线下口头确认”变成了“流程里不可跳过的一环”既保证了质量闸门也留下了审计记录。从实践来看真正高效的协作状态是手动 QA 把探索过程中发现的高价值场景“反哺”成新的自动化用例自动化用例释放手动 QA 的时间让测试人员有精力去做更深度的探索。两者不是并行关系而是迭代关系。6. 如何验证手动 QA 的产出与效果手动 QA 在团队里地位低的另一个原因是它的产出很难量化。自动化测试可以说“我们有多少用例、覆盖率多少、跑了多少次”手动 QA 如果只有一句“测过了”那确实很难让人信服。要改变这种局面建议至少追踪下面几个指标指标计算方式说明需求覆盖数实际执行用例覆盖的需求数 / 本期需求总数防止“测了但没覆盖全部需求”缺陷发现数手动测试期间提交的有效缺陷数衡量执行密度和业务理解深度测试用例通过率通过用例数 / 执行用例总数衡量本轮代码质量缺陷逃逸率发布后发现的高级别缺陷数 / 总缺陷数衡量 QA 闸门的有效性自动转化率本轮手动用例转化自动化的数量衡量手动 QA 的长期贡献其中最值得关注的是“缺陷逃逸率”。它的含义是一个缺陷在测试阶段没有被发现而是上线后才被用户或者监控发现。这个指标越低说明手动 QA 的“守门”效果越好。如果逃逸率一直很高可能不是测试人员不努力而是介入时机太晚、测试范围太窄或者用例设计深度不够。除了指标手动 QA 还需要输出结构化的测试报告。一份好的测试报告不需要花哨但必须包含测试结论是否建议上线 测试范围覆盖了哪些模块未覆盖哪些模块 缺陷统计P0/P1/P2 缺陷数量及当前状态 风险清单已知问题、遗留缺陷、规避方案 回归建议上线后需要重点观察哪些业务指标写出这份报告的过程本质上就是在倒逼手动 QA 把注意力从“点按钮”转移到“做判断”。测试报告是手动 QA 和开发、产品对话的载体也是它自证价值的核心证据。在验证手动 QA 效果时还有一个容易被忽视的点测试数据。很多手动 QA 的缺陷都出在测试环境和生产环境的数据不一致上。所以建议团队在测试计划阶段就明确数据的准备方式优先使用脱敏后的生产数据或通过脚本构造的仿真数据再补充典型的边界数据。没有贴近真实的数据环境手动 QA 的结论天然不可信。7. 常见问题与排查思路手动 QA 在落地过程中最常见的问题基本都集中在流程和执行层面。下面把高频问题整理成一张排查表。问题现象可能原因排查方式解决方案手动 QA 用例没人维护需求变了用例还停留在旧逻辑用例缺少责任人变更时没有同步更新检查用例最后修改时间和需求关联在需求评审中明确用例更新责任人测试环境不稳定手动执行频繁被环境问题打断环境缺少配置管理数据污染严重查看环境初始化和数据准备流程环境扫码自动化恢复测试数据脚本化手动 QA 变成了自动化的“附属品”团队只考核自动化覆盖率忽略业务探索分析缺陷来源和测试报告内容重新定义考核指标加入探索性测试时间手动 QA 执行时间长版本发布总是等测试用例粒度太粗或执行内容重复审查用例是否有冗余步骤划分冒烟、主链路、深度回归三级用例缺陷被开发直接拒绝测试结论没有影响力缺陷单缺少必要信息和复现步骤抽查缺陷单的质量要求缺陷单包含环境、数据、步骤、期望和实际结果自动化覆盖率和手动 QA 脱节两边各测各的缺少用例标记和任务流转机制观察 CI 配置和测试任务分配流程用 pytest 标记或测试管理平台实现任务同步这里特别想展开说明一个容易被忽视但杀伤力很大的场景手动 QA 发现了一个缺陷缺陷单也提了但开发在下一轮迭代里“顺手修了”既没有关联测试用例也没有触发回归验证。等到正式发布的时候这个缺陷的验证状态是模糊的一旦修复方式引入新问题测试团队完全不知道。针对这个问题建议缺陷单必须关联到具体的测试用例 ID并设定“修复后必须回归通过才能关闭”的状态流转规则不给糊涂账留空间。另一个常见争议是“手动 QA 要不要写自动化脚本”。我的建议是不要强求。让手动 QA 人员投入大量时间学自动化框架短期会削弱最核心的业务探索能力长期也未必能培养出优秀的自动化工程师。更合理的做法是手动 QA 负责把业务场景提炼成“哪些值得做自动化”的清单自动化工程师负责实现。专业分工比全员全栈更适合质量领域。8. 最佳实践与工程建议手动 QA 要在一个团队里长期立足不能只靠个别人认真负责必须有制度和规范支撑。下面是我认为落地价值最高的几条建议。第一命名和编号规范要前置。测试计划、测试用例、缺陷单都建议使用统一的前缀和编号规则。比如用TC-模块名-序号来给用例编号用BUG-模块名-序号来给缺陷编号。这套编号体系不只是为了方便搜索更重要的是让“需求——用例——缺陷——修复——回归”之间形成可追踪的链路。第二手动 QA 的记录要尽量结构化。执行过程中发现的问题、环境信息、测试数据、例外风险都应该按固定格式记录而不是散落在聊天记录里。哪怕团队没有测试管理平台也可以用 Git 仓库维护测试记录每次执行提交一次变更这样至少能保证所有信息可回溯。第三明确不同级别用例的执行策略。可以把手动用例分为三档冒烟用例每次提测和发布前必跑控制在 10-15 条以内主链路用例覆盖核心业务闭环每次版本迭代必须执行深度回归用例按风险影响面选择执行不要求每次都完整跑。分级的好处是版本发布不那么频繁的时候可以深度回归版本迭代很快的时候可以只握守核心链路让手动 QA 的投入和风险匹配起来。第四手动 QA 和开发要保持固定的同步节奏。推荐用“测试前置沟通 提测后集中验证 发布前风险复核”三段式节奏。测试人员在开发完成前先介入提测后按用例执行发布前和开发确认遗留缺陷的规避方案避免上线前的突然拉扯。第五要建立“手工测试也能推动自动化”的正反馈机制。每轮手测结束后手动 QA 可以提交一批“建议自动化”的用例清单自动化团队评估后纳入计划。如果这个机制运转良好团队的手动测试负担会逐步下降而自动化测试的质量会因为用例来源更贴近真实业务而明显上升。第六也是我认为最重要的一条手动 QA 必须拥有“说上线有风险”的独立发言权。如果测试结论是“不建议发布”不应该因为业务压力或开发进度而被强行推翻。质量闸门的权威建立在流程刚性上一旦“测试说不行也能发”成为常态手动 QA 就会迅速退化成走流程的摆设后续再想重建信任会非常困难。9. 总结与后续学习方向手动 QA 的真正价值不在于“手工”这两个字而在于它提供了自动化测试难以替代的两种能力对模糊业务问题的判断能力和对未知风险的探索能力。自动化在体系里承担的是“守住底线”手动 QA 承担的是“发现上限之外的问题”。一个好的质量体系必须让这两种能力形成循环手动发现新问题自动化守住旧问题如此往复质量才会螺旋上升。如果你现在的团队还在为“要不要保留手动 QA”争论我的建议是不要直接回答“要”或“不要”而是先回答另外两个问题哪些场景自动化一定守不住测试人员在手动执行之外有没有持续积累业务判断力把这两个问题想清楚手动 QA 的定位自然就浮出水面了。后续值得继续深入的方向有三个。一是探索性测试的方法论可以学习基于风险的测试设计和 session-based test management二是自动化测试与手动测试的用例管理系统落地研究 Jira、TestRail、PingCode 这类工具如何把流程串起来三是质量度量的进阶用法比如缺陷逃逸率的趋势分析如何反向驱动研发流程改进。这三块学完你对手动 QA 的理解就不会停留在“要不要”的层面而是能真正搭建出一套质量体系。