如何测试一个你不理解的系统？从“不懂”开始的测试方法
很多测试任务从你还不了解系统开始。
一个紧急工单突然被分给你。需求写得很短，熟悉这块业务的人暂时没有时间，代码、接口和历史缺陷也都还没来得及看。然后有人问：
这个今天能帮忙测一下吗？
这正是 Kim Muncey 在 Ministry of Testing 分享中讨论的问题：如果测试人员还不理解一个系统，应该怎样开始测试？
Kim 从客户服务岗位走进 Northcoders 编程训练营，后来进入质量保证领域。她面对陌生系统时，会把“不懂”拆成一组需要逐步缩小的问题。
测试人员要处理的是信息缺口、风险判断和反馈循环。
测试人员不需要一开始就理解整个系统
测试人员很容易给自己设置一个过高的起点：先把系统架构、业务流程、数据模型和全部历史背景弄明白，然后再开始测试。
现实项目很少给我们这样的条件。系统一直在变化，文档总有缺口，需求也不一定完整。即使长期负责某个产品的人，也不可能在每一次变更前都拥有全部上下文。
测试的起点可以小很多。当前任务通常只需要先回答四个问题：
- 用户这次想完成什么事情？
- 这次具体改了什么？
- 哪些行为可能受到影响？
- 什么结果可以证明功能正常或异常？
剩下的未知信息，可以在测试过程中继续补齐。测试也会推动你建立这些知识。
Kim 提到，她观察资深测试人员时发现，他们面对陌生系统并不一定比新人知道更多。区别在于，他们更习惯从问题开始：
- 这个功能解决什么问题？
- 输入和输出分别是什么？
- 为什么要做这次改动？
- 哪些状态会发生变化？
- 失败时应该发生什么？
- 依赖哪些系统或数据？
- 这次改变还可能影响哪里？
他们开始测试时未必已经知道答案，但知道应该先问什么、去哪里找答案。知道从哪些问题开始，本身就是测试能力。
把“我不懂”换成“我还没懂”
“我不懂”听起来像一个结论，容易让人停在原地。“我还没懂”则更像一个工作状态，它会自然地引出下一步：
- 我还缺哪一块信息？
- 谁最可能知道这件事？
- 我能通过什么观察或实验验证它？
这句话的作用，是把模糊的不安转换成可以处理的问题。它不要求测试人员假装自信，只要求把缺口说清楚。
测试陌生系统可以按几个连续动作推进：先提出问题，再收集信息；根据现有证据建立暂时模型；找出模型里的缺口；验证重要假设；根据结果继续修正模型。
目标也很明确：在开始测试前获得足够的信息，能够识别风险并做出下一步测试决策。没有必要把整个系统学完再开始。
不要只读工单写了什么，还要看它没写什么
Kim 还提醒，读工单时要同时关注它没有写什么：
阅读一张工单时，不只是看里面有什么，还要看里面缺了什么。
很多用户故事（User Story）看起来写得很好，验收标准（Acceptance Criteria）也很完整，但它们经常只描述一条顺利完成的路径：
用户做出正确操作，系统收到正确输入，依赖服务正常，状态有效，最后返回预期结果。
这就是 happy path。测试人员需要继续问的是：
如果 happy path 没发生呢？
可以从这些问题开始：
- 输入为空或格式非法时怎么办？
- 用户重复提交时怎么办？
- 用户权限不足时怎么办？
- 依赖服务超时或返回错误时怎么办？
- 网络在操作中途断开时怎么办？
- 数据状态不一致时怎么办？
- 操作执行到一半失败时，已经发生的变化怎么办？
- 重试是否安全，会不会产生重复订单、重复扣款或其他副作用？
比如，一张工单只写着“支持用户修改收货地址”。这句话还没有告诉我们：已发货订单能不能改，订单、发票和物流信息分别显示什么，两个页面同时修改时谁的结果应该保留，保存后刷新页面是否仍然一致，地址服务不可用时能否重试。
这些问题用来找出需求里尚未明确的风险。工单没有写出来的内容，往往正是测试输入。
缺失的信息本身也是线索
看到信息缺失，先不要急着下结论。信息缺口还会告诉你下一步应该找谁。
| 缺少的信息 | 通常可以找谁确认 |
|---|---|
| 业务规则和用户目标 | 产品经理、业务分析师（BA）或领域专家 |
| 技术实现和历史原因 | 开发人员 |
| 接口行为和错误契约 | API 或后端负责人 |
| 旧版本行为和回归影响 | 熟悉系统的 QA 或开发人员 |
| 生产环境表现和真实案例 | 客户支持、运维（Ops）、日志或监控 |
测试陌生系统不需要一个人坐在那里猜。先发现未知，再分类未知，找到掌握信息的人，验证自己的理解，最后更新测试模型——这是一条更可靠的路径。
当然，别人给出的解释也不自动等于事实。不同角色可能给出不同答案，旧文档也可能和当前实现不一致。测试人员仍然要把口头说明转成可观察、可复现的证据。
知道该问谁、怎样把问题问具体，本身就是测试能力。
测试陌生系统，本质上是在建立一个最小测试模型
这个过程可以先落到一个最小测试模型上。
它只回答当前测试所需的问题，不要求你在第一天就理解所有模块：
| 需要回答的问题 | 对测试的帮助 |
|---|---|
| 它解决什么问题？ | 确定功能目的 |
| 谁在什么场景下使用？ | 确定用户和入口 |
| 主要输入和输出是什么？ | 确定数据和可观察结果 |
| 核心业务规则是什么？ | 确定哪些结果算对或算错 |
| 哪些状态会发生变化？ | 确定前后状态都要检查 |
| 依赖哪些系统、接口或数据？ | 确定外部失败路径 |
| 失败以后会怎样？ | 确定错误处理和恢复方式 |
| 哪里可能造成最大的损失？ | 确定风险优先级 |
有了这份最小模型，就可以先设计一轮有针对性的测试，再随着新信息不断修正它。
第一轮不必追求覆盖所有分支。可以先验证一条正常路径，再主动改变一个关键条件：换一个角色、换一组边界数据、重复提交一次、打断网络，或者让依赖服务返回异常。
每一次实验都应该回答一个问题。测试结果会改变你对系统的理解，也会暴露新的未知。理解和测试会一起向前推进，你不需要先完成其中一项再开始另一项。
AI 可以帮助你，但不能替你理解系统
对 AI 的使用有一个前提：测试人员至少要具备判断输出是否合理的基础能力。
Kim 提到，她参加 Northcoders 训练时，训练营不鼓励初学阶段直接依赖 AI。原因很直接。如果一个人还不知道：
- 代码为什么这样写；
- 语法表达了什么；
- 背后的核心概念是什么；
- 什么结果才算正确；
那么 AI 给出一段看起来完整的答案时，就很难判断它是正确，还是只是看起来正确。
这对测试人员同样适用。AI 可以解释代码、整理材料、生成例子，但它不知道团队没有写进文档的约定，也不知道某个字段在生产环境里到底有多重要。你需要先拥有足够的基础，才能检查它的假设和结论。
AI 最大的风险之一：你不知道自己不知道什么
假设你完全不了解一个系统，然后直接问：
帮我生成完整的测试用例。
AI 很可能真的给你三十条、五十条，甚至一百条用例。结构完整，分类清晰，读起来也很像一份正式测试计划。
问题是：
你怎么知道它漏掉的不是最重要的那一条？
如果测试人员没有领域知识，也没有足够的业务上下文，就很难识别：
- 错误假设；
- 遗漏风险；
- 虚构规则；
- 错误优先级；
- 看起来合理、实际没有价值的边界场景。
这就是“你不知道自己不知道什么”的风险。输出越完整，越容易让人忘记检查它的前提。
在陌生系统中，我更倾向于让 AI 辅助理解、提问、挑战和检查，由测试人员决定应该怎么测试。
一个很好的 AI 用法：压力测试你的测试计划
Kim 分享了一个很实际的做法。
当她面对一个不太熟悉的功能时，可能会先问自己：
我对这个领域的风险不够熟悉，现在的测试计划真的覆盖够了吗？
她先完成自己的分析，再把功能概述和已有测试计划交给 ChatGPT，让 AI 去挑战这份计划。
可以让 AI 具体检查：
- 遗漏了哪些核心业务风险？
- 哪些失败路径没有覆盖？
- 哪些测试可能已经超出当前范围？
- 哪些测试依赖未经验证的假设？
- 哪些明显场景被习惯性忽略了？
这里 AI 扮演的是复核者和挑战者。它提供第二视角，提醒风险，提出反例和边界条件；测试人员仍然需要判断每条建议是否适用于当前系统。
这样既能让 AI 参与测试思考，也能让测试人员继续控制范围、证据和质量结论。
从“让 AI 帮我写”变成“让 AI 挑战我”
把需求交给 AI 和让 AI 挑战自己的分析，是两种不同的工作方式。
第一种是把需求直接交给 AI，让它输出测试计划。第二种是测试人员先读需求、梳理风险、写出第一版计划，再让 AI 检查遗漏，最后由测试人员判断是否修改。
第二种方式更适合陌生系统，因为最终决策仍然掌握在测试人员手里。AI 可以贡献第二视角、风险提醒、反例、边界条件和遗漏检查，但不能把未经验证的业务规则直接写进测试计划。
一个实际可用的工作习惯是：先独立写出“我为什么要测这些”，再问 AI“我可能漏掉什么”。这样更容易分辨 AI 是在补充证据，还是在补造上下文。
另一个有意思的用法：让 AI 帮助检查“我到底学会没有”
Kim 还分享了一个学习实验。它与测试本身没有直接关系，却能帮助检查自己是否真的学会了一个主题。
她选择两个自己完全不了解的主题，分别通过播客和文章学习相同的时间，并做笔记。之后，她把材料和具体评价标准交给 Claude，让 Claude 根据这些内容出题，检查她究竟理解了多少。
她发现，自己阅读文章时并没有一直主动处理信息，而是在期待知识可以“自然渗透”进来。这个发现后来影响了她阅读和审查代码的方式。
这里 AI 用来验证她到底有没有学会主题。
对 QA 来说，学习之后还要验证。读过需求、看过代码、听过解释，都不能自动证明你已经能据此识别风险。
读完一个陌生模块后，可以让 AI 根据你的说明提出问题，同时覆盖正常流程、失败处理、数据状态和权限边界。只让它总结内容，无法检查你是否真的理解；如果你答不出来，说明自己可能只是看过材料，还没有形成可用于测试的理解。
使用 AI 的关键不是 Prompt 技巧，而是上下文是否具体
问答环节里，Kim 给了一个很简单的原则：尽可能具体。
不一定需要研究复杂的提示词工程（Prompt Engineering）。很多时候，先把问题、范围和约束说清楚，结果就会明显改善。
不要只说：
帮我检查这个测试计划。
可以把请求写成：
这是功能背景、变更范围、已知依赖和当前测试计划。请从核心业务风险、失败路径、范围边界和未经验证的假设几个角度进行检查。不要补充材料中没有出现的业务规则。对于缺少证据的部分，请标记为 Unknown，并说明下一步需要向谁确认或通过什么实验验证。
具体上下文还有一个好处：人工复核更容易。你可以逐条追问，这条建议对应了哪条已知信息，依赖了哪个假设，应该用什么证据确认。
输入越模糊，结果越不可控。测试也遵循同一条规律。
AI 仍然无法替代人的反馈循环
钩针编织的例子说明，反馈需要发生在动作现场。
Kim 从身边真正会钩针的人那里学习。对方可以直接看到她的手怎么放、线怎么走、哪一步做错、为什么错，以及下一步应该怎样纠正。
这种“观察、反馈、修正、再观察”的实时循环，目前仍然很难被 AI 完整替代。
这对 QA 新人也一样。AI 可以解释边界值分析、探索式测试、基于风险的测试和 API 测试，但真实项目里的很多判断来自反复实践：
- 先做一次；
- 接受评审；
- 发现自己哪里判断错了；
- 理解为什么错；
- 下一次做得更好。
产品人员可以解释用户真正关心的结果，开发人员可以解释技术约束和历史原因，领域专家可以指出文档里没有写出来的规则。真实用户则可能告诉你，团队认为合理的流程在实际使用中根本行不通。
向人提问不代表测试能力不足。带着具体问题找到合适的人，正是高质量测试的一部分。
AI 可以加速学习，但不能消灭产生判断力的反馈循环。
如果明天让我测试一个完全不懂的系统
结合这次分享，如果明天突然收到一个完全陌生的测试任务，我会按下面的顺序开始：
- 明确这次到底改了什么。
- 把需求里已经确认的事实和自己的假设分开记录。
- 标记所有仍然未知的内容。
- 找出一条最基本的 happy path。
- 反过来寻找输入、权限、依赖、网络和状态方面的 failure path。
- 梳理输入、输出、状态变化和外部依赖。
- 判断哪些风险可能造成最大的业务影响。
- 为每个信息缺口找到合适的信息负责人。
- 建立当前任务的第一版最小测试模型。
- 设计并执行一轮有明确问题的测试。
- 让 AI 挑战测试计划，检查遗漏和未经验证的假设。
- 人工判断 AI 的每条建议，不把生成结果直接当成结论。
- 根据测试结果更新自己的理解，再决定下一步测试。
Unknown 不是失败。它只是一个还没有关闭的信息缺口。把它写下来，比用一个未经验证的答案填上去更安全。
对 QA 新人的另一个提醒
今天进入软件行业的人，面对的工具比以前多很多：ChatGPT、Claude、Copilot、各种 Agent、Skill、MCP，以及不断出现的新工具。
AI 可以很快生成测试用例、自动化代码、SQL、API 脚本和测试报告。但“能够生成”和“真正理解”之间仍然有很大距离。
如果长期跳过这些问题：
- 为什么要测这个？
- 为什么这是风险？
- 为什么这个结果是错的？
- 为什么这个测试有价值？
最终可能会得到大量输出，却没有形成真正的测试判断能力。
我更愿意把 AI 看成能力放大器。它不能代替基本功；已有的判断能力越强，AI 越容易放大它。如果连结果都无法判断，AI 也可能只是更快地产生一些看起来很专业的错误。
刚接触陌生系统时，不知道答案很正常。真正危险的是因为害怕暴露不懂，开始默默补全假设。
把“我认为应该如此”和“系统已经证明如此”分开记录。把问题问得具体一些，把测试结果写得可复现一些。随着每一次观察、提问和实验，陌生系统都会从一团模糊的东西变成一组可以讨论的行为。
最后
这次分享回答的是：
如何测试一个你不理解的系统？
我的答案是一种工作方式：保持好奇，承认未知，提出问题，找到掌握信息的人，建立最小测试模型，识别风险，设计测试，再用工具和反馈挑战自己的判断。
测试人员不需要一开始就知道所有答案。更重要的是，知道自己还不知道什么，并知道下一步如何把“不知道”变成可以验证的问题。
AI 可以整理信息、发现遗漏、提出反例、挑战测试计划和检查理解。但最终仍然需要测试人员判断：
- 这个建议合理吗？
- 这个风险真实吗？
- 这个场景值得测吗？
- 现有证据足够支持这个结论吗？
所以下一次又收到一个自己完全不了解的测试任务时，可以先把“这个我不懂”换成：
这个我还没懂。那我先看看自己缺什么信息。
很多测试工作，就是从这里开始的。
来源：Ministry of Testing 分享原文:https://www.ministryoftesting.com/media-sessions/how-can-you-test-a-system-that-you-don-t-understand