很多人觉得“测试”是软件开发生命周期里最枯燥、最末端的一环，但放到 LLM 应用这个新领域，测试恰恰成了决定项目能不能落地、能不能上生产、能不能收得住成本的关键隘口。我在过去半年里，一边在自己团队搭 LLM 应用，一边看着身边不少朋友在从 0 到 1 做基于大模型的产品，大家不约而同卡在了同一个问题上：代码写完很容易，提示词和 RAG 链路也都能跑通 demo，可真要往生产环境推，用户问几个刁钻问题，回复质量就肉眼可见地往下掉，幻觉、答非所问、上下文漂移全来了。这时候你才发现，传统那套基于“确定性断言”的自动化测试根本用不上，而 LLM 应用的测试方法论、工具链和最佳实践都还是大片空白，这就是我说的“新战场”。
这一篇是整个系列的开篇，我不想一上来就讲怎么写 pytest 脚本、怎么搭断言器，先把“为什么”讲透。测试这活儿在 LLM 落地的过程里，不再是一个质量保障动作，它直接决定了你的应用是能用几天还是能跑几年，决定了你面对的是 Demo 级效果还是产品级交付。我会从传统测试和 LLM 测试的本质差异聊起，拆解 LLM 落地时需要被测试的各个层次，然后给出一套可落地的思路和 pytest 搭建案例，最后把我踩过的坑、犯过的错，全部摆出来。
1. 内容整体设计与思路拆解：为什么 LLM 测试必须“另起炉灶”
1.1 传统自动化测试的“确定性假设”正在失效
做传统自动化测试的同事应该深有体会，不管是做接口自动化还是 UI 自动化，我们写测试用例时心里都有一个明确的“预期结果”。调用一个接口，传入参数，返回值要么是 200，要么是 500，字段名、字段类型、错误码都是确定的；UI 上点一个按钮，元素的文本、颜色、出现位置要么符合预期，要么不符合，跑失败就是失败，不需要第二次判断。
这种测试思维建立在“系统行为可复现、输出结果可断言”的确定性基础之上。传统的 pytest、Selenium、Appium 框架，包括我们看到的各种接口自动化测试框架，本质上都是在帮你把“输入-操作-断言”这个闭环跑起来。你设计测试数据，设计预期结果，然后交给自动化框架去循环执行，一切黑白分明。
可当你把测试对象换成一个 LLM 应用，这个模型面临的却是概率性输出。你给它同一个问题，它可能用不同的表达方式回答；你给它两段相近的上下文，它可能每一次给出的答案在信息完整度上都略有差异；用户问“这个方案和那个方案到底有什么区别”，你没法在产品需求里写死“必须返回 150 字以内的对比表格”，因为模型天然会在语言这个高维空间里自由游走。
这不是“不好测”这么简单，而是传统测试框架里最核心的“断言”机制直接失效了。你不能判断一个 LLM 的回答“等于”或者“不等于”某个字符串，你需要判断它“是否语义上相关”“是否包含了必要的实体”“是否从给定的文档中引用了答案”。这种差异，是认知模型上的差异，不是换个测试工具就能解决的事。
1.2 从“断言”到“评估”：测试目标变了，方法就得跟着变
既然确定性断言失效，那 LLM 测试到底应该怎么做？我在实际项目中总结下来，核心思路是把“测试用例”从“断言器”改成“评估器”。也就是说，测试要做的不是判断“对不对”，而是判断“好不好”。这里的“好”可以从多个维度打分：准确性、相关性、忠实度、完整性、安全性、稳定性、时效性、成本，每一条都是一个可量化的评估维度。
打个比方，传统测试像质检流水线上检查螺丝的螺纹是不是标准，卡尺一量，过或不过；LLM 测试像验收一道菜品，你不能用卡尺量菜的温度，但你可以建立一套色、香、味、形、器、营养搭配的评估体系，由经验丰富的品鉴师或者一套标准化的评测流程来打分。LLM 应用的质量，不是由某一条代码逻辑决定的，而是由好几套“软性”能力共同支撑的，这就要求测试基建发生根本性变化。
这也是为什么我会把“评估器”这个角色放到测试设计的最前面。你要先确定你的 LLM 应用应该满足哪些质量维度，然后把每个维度转成可观测、可打分、可自动执行的检查项。比如“忠实度”这一个维度，就可以通过比对 LLM 生成的答案与 RAG 检索到的上下文文档之间的语义重合度来判断。你不再问“输出是否等于 A”，而是问“答案是否在事实上忠于给定的参考资料”。
1.3 测试为什么成了 LLM 落地的新战场：三个关键驱动因素
第一个驱动因素是 LLM 应用的失败模式与传统应用完全不同。传统应用挂了一般是报错、超时、崩溃，都是显性的；而 LLM 应用挂掉的时候，它通常还在正常返回内容，只是这段话里可能包含了编造的数据、过期的事实、前后不一致的建议、或者带偏见的表述，这叫“完美输出下的隐性错误”，用户不会告诉你出错了，但信任已经流失了。
第二个驱动因素是评估成本与收益失衡的现状。每跑一轮测试，要消耗 Tokens，要搭向量数据库，要设计复杂评测集，要调裁判模型的参数，成本比传统测试高一个数量级。可如果你不投入这股成本，上线后一个幻觉答案导致用户流失，或者一次敏感信息泄漏导致服务被投诉，损失远超测试成本。测试在这个场景里的“投资回报比”极高，谁先建立起测试体系，谁就先拿到生产环境的安全垫。
第三个驱动因素是工具链和数据飞轮都没有成熟。从热度趋势可以看到，大家都在关注 langchain、pytest、RAG、Agent、wiki 知识库、GraphRAG 这些关键词，但把它们拼成一个端到端的、可复现的 LLM 测试体系，现在还没有标准答案。正因为没有标准答案，先做的人才有机会沉淀出方法论，这也是我写这个系列最主要的原因。
2. 核心细节解析与实操要点：LLM 测试到底测什么
2.1 测试对象的边界：模型能力、RAG 检索、Agent 编排三层必须分开
把 LLM 应用当成一个整体去测，是我见过成本最高、效果最差的做法。你收到一个错误回答，你都不知道是模型本身能力不足，还是向量数据库里没召回该召回的内容，还是 Agent 编排时把工具调用的结果传丢了。所以我认为测试对象必须分层拆解，每一层设独立的评测集和阈值。
第一层是模型原生能力。这里要测试的是 LLM 在特定提示词下的基础能力上限，比如多轮对话保持上下文的能力、代码生成能力、结构化输出提取能力、数学推理能力。这一层不掺入外部知识库，不挂接工具，让你能够定位“裸模型”的表现基线。测试结果的作用是做版本选型和提示词调优，用同一批评测文本跑不同模型或不同提示词模板，对比分数就知道哪个更适合你的业务。
第二层是 RAG 检索链路。现在的 LLM 落地项目，几乎没有人不用知识库，无论你用的是传统的向量检索，还是带关系的 GraphRAG，或者基于 wiki 构建的知识库体系，核心都要经过“用户问题写进向量 -> 向量检索 TopK -> 文档拼进上下文”的链路。这一层测试的重点不在问答能不能答出来，而在于检索系统在给定的查询下，有没有把正确答案所在的文档给彻底漏掉。你召回的质量如果不行，后面给模型灌多少提示词都没用。
第三层是 Agent 编排与工具调用层。现在大家搭应用很少只有一个 LLM 调用，很多都是基于 langchain 或者自己写的调度逻辑，把工具调用、API 请求、外部查询编排在一起。这一层的测试既包含传统意义上的接口逻辑测试，比如 API 服务挂了能不能熔断重试、传入参数对不对，又包含新出现的逻辑语义测试，比如模型在一个步骤里提取出的参数，传到下一个工具是不是符合工具定义，工具返回的结果有没有被正确地回填到对话上下文中。说到这里，有一个特别容易忽略的点：工具调用的 Tokens 消耗往往会暴涨，但测试的时候不能直接拿线上最大并发去压，必须在评测集里单独测量平均 Tokens 和峰值 Tokens，锚定好成本基线。
2.2 测试数据的构造：评测集不是简单堆问答对
很多团队一上来就在网上找现成的 benchmark 数据集，或者把客服对话记录了事，这是大忌。LLM 应用的评测集必须具备业务边界和故障边界两层结构。业务边界好理解，就是从真实业务中提取高频问题、典型问题、边界问题，覆盖用户会问到的主要场景。但光有这个还不够，你还要准备故障边界数据，也就是那些“很容易让模型翻车”的样本，比如：
- 明知知库里没有答案，用户却追问到底，模型会不会强行编造一个答案？
- 用户提问中包含了明显的错误前提，比如把“A 模块”说成“B 模块”，模型会不会被带偏？
- 问题需要跨多个文档才能回答完整，模型有没有把所有相关内容都检索上来？
- 用户提出了敏感或者违规的问题，模型有没有按安全规范拒答？
这些故障样本才最能暴露系统的能力短板，也是最值得自动化回归的样本。构造评测集时，我会额外标注每个样本的“标准答案”或“标准态度”，比如对于“用户问了一个知识库外的问题”，标准态度就是“基于已有信息无法回答，建议补充资料”。这样在自动化运行时，就可以通过评估器判断模型输出是否接近这个标准态度，而不必像传统测试那样强行匹配一个字符串。
2.3 测试执行环境：为什么必须引入可控的“评测网关”
聊到实际操作，我还想强调一个底层设施：LLM 测试必须跑在一个可控的评测网关里。这里说的“网关”不是指部署层面的 API 网关，而是指在测试代码里统一封装模型调用、统一记录日志、统一统计 Tokens 的中间层。所有被测试的用例，不管是单测还是集成测试，都不能直接裸调模型提供商的 SDK，而应该通过评测网关来路由。
为什么一定要这么做？因为 LLM 测试的可重复性极差。你直接调一次模型生成回答，下次再跑可能就变了；你换了一个模型版本，所有历史测试结果全部作废；你想对比两个模型的输出差异，拉出来的日志格式还不一样。有了评测网关，你就可以固定模型版本、固定温度参数、固定随机种子、统一捕获返回内容和 Token 消耗。你甚至可以在这个网关里预设一个“故障注入”开关，模拟模型请求失败、工具调用超时、向量库连接中断等状况，这些在传统自动化测试里很容易模拟的场景，在 LLM 测试里如果不加网关，操作起来会非常痛苦。
3. 实操过程与核心环节实现：用 pytest 搭一个可回归的 LLM 测试基座
3.1 基础设施准备：Pytest 夹具设计
聊了这么多“为什么”，现在进入第一阶段的实操环节。这个系列第一篇我们先把最基础的测试骨架搭起来，不用部署完整的测试平台，就用 pytest 就足够打样了。为什么选 pytest？因为它生态成熟、断言方式足够灵活、fixture 机制非常适合管理外部依赖，而且现在热度趋势里反复出现“自动化测试框架 pytest”，说明这是事实上的行业标准入口。
我先建一个项目目录，结构大致如下：
llm_automation_testing/ ├── conftest.py ├── evaluation/ │ ├── evaluator_llm.py │ └── retrieval_evaluator.py ├── test_cases/ │ ├── test_model_basic.py │ ├── test_rag_retrieval.py └── playground/在conftest.py里，我定义两个核心 fixture：一个是llm_gateway，负责创建统一调用模型的环境；另一个是vectordb_session，负责拉起一个可复现的向量数据库连接。
import pytest @pytest.fixture(scope="session") def llm_gateway(): from llm_automation_testing.playground.gateway import LLMEvalGateway # 固定参数：模型版本、温度、以及评测模式 return LLMEvalGateway(config_path="config/eval_models.yaml") @pytest.fixture(scope="function") def vectordb_session(llm_gateway): # 建一个小型向量库，灌入预先构造的测试语料 from llm_automation_testing.playground.fake_vdb import FakeVectorDB vdb = FakeVectorDB.load_from_local("testdata/corpus.json") vdb.clear() vdb.batch_add(vdb_corpus()) yield vdb # 会话结束后清除数据，保证用例独立 vdb.clear()这里有一个关键设计：LLMEvalGateway里必须能设置“评测模式”。在评测模式下，模型的 temperature 统一设为 0，随机性降到最低，同时所有推理日志都会记录到本地文件。这个设计可以让你后续跑回归时，无论跑多少遍，至少基础输出是相对可控的。
3.2 核心 TM：测试的基础能力层
搭好基座后，我先测最基础的第一层——模型基础能力。我设计一组关于“信息抽取”和“结构化输出”的用例，用来验证模型在固定指令下能否稳定输出 JSON。这类用例是很多 LLM 应用的刚性依赖，因为工具调用、表单填写的几个环节都会用到。
import json def test_model_can_extract_entities_in_json(llm_gateway): input_text = "用户想申请退款，原订单号是 20240915-8899，商品是蓝牙耳机，金额 299 元。" instructions = "提取以下字段：订单号、商品、金额，并以 JSON 格式返回。" response = llm_gateway.chat(instructions + "\n\n" + input_text) try: parsed = json.loads(response) except json.JSONDecodeError as exc: pytest.fail(f"模型未返回合法 JSON：{response}，解析错误：{exc}") assert "订单号" in parsed assert parsed["商品"] == "蓝牙耳机"我跑这段用例时发现一个很容易踩的坑：模型有时候会在 JSON 外面套一层“```json”代码块标记，导致json.loads直接报错。后来我在llm_gateway.chat内部做了响应预处理，把代码块标记剥离掉，只保留 JSON 主体部分。这个小改动已经救了很多次自动化环境。
另外，这里也建议你不只是断言“存在字段”，而是针对“提取准确率”加打分逻辑。比如解析完成后，用字符串相似度函数比较目标字段，得出一个 0 到 1 的分数，低于阈值的测试判定为失败。这样你后续跑变更回归时，能看到的是更加平滑的“质量变化曲线”，而不是一把过/不过的绝对结果。
3.3 实现 RAG 检索链路测试
接下来这层值得重点说，因为我发现很多项目 Google 搜索上“RAG 推荐了什么内容”完全没概念，一直到线上出现低级错误才想到去追溯。在测试 RAG 链路时，我们不是让模型直接去回答用户，而是先把检索召回的结果拿过来做断言。
举个例子，建一个小语料库，包含《2024 年企业健康体检套餐手册》和《客户退换货政策 V5.2》两本“业务文档”，然后在这个库上构造几个查询。比如：
- 查询“员工年度体检可以选哪些镜子项目”
- 查询“已拆封的产品如何退换”
- 查询“换货的时效是多长”
这些查询都直接来自我们设定的业务场景。测试的目标是：给定查询后，检索系统返回的 TopK 文档里，必须包含目标文档。
def test_rag_retrieval_topk_hit(vectordb_session): query = "换货的时效是多长" top_k = 5 hits = vectordb_session.search(query, top_k=top_k) # 对结果做归一化后，判断目标文档是否出现在召回列表 hit_ids = {doc["doc_id"] for doc in hits} assert "return_policy_v5_2.md#section_3" in hit_ids, ( f"查询“{query}”在 TopK={top_k} 结果中没有命中目标文档，实际命中：{hit_ids}" )这里要特别提一下，RAG 测试不能只看“召回率”。你可以给各自的召回结果打一个相关性分，比如用“语义相似度”计算召回文档与查询主题之间的相关度，低于 0.75 的直接标为“疑似低相关召回”，然后在测试报告里单独列出一个可视化列表，方便你排查哪些查询的向量表示不够鲁棒。我自己的项目里，就是在跑测试时发现“退换”和“退货”两个词虽然语义很像，但向量分布差异很大，需要单独做同义词扩展。
3.4 搭建基于 LLM 的评估器：让机器评“好不好”
如果要让 pytest 用例全面替代人工测试，还必须引入“评估器”的概念。我指的不是前面那种纯规则解析，而是用一个裁判模型来给被测模型的回答打分。这个模式在业内已经很常见，但很多人把它做得过于繁琐。
我的做法是构造一个EvaluatorLLM，它接收三部分上下文：用户问题、被评估的模型回答、参考信息（比如 RAG 检索到的内容或标准答案）。然后把以下内容作为提示词：
请对以下回答做出质量评估，从“准确性”“忠实度”“相关性”三个维度，分别给出 0-10 分和一句评语。 要求： 1. 准确性衡量回答中事实性信息的正确性； 2. 忠实度衡量回答中信息是否与提供的参考资料一致，是否包含编造或猜测； 3. 相关性衡量回答是否恰当回应了用户的问题。评估器返回后，我们用正则或 JSON 解析提取三个分数，再在 pytest 用例中聚合断言。
def test_answer_faithfulness_with_evaluator(llm_gateway, vectordb_session): query = "体检套餐具体包含哪几项检查？" reference = vectordb_session.search(query, top_k=3) response = llm_gateway.answer_from_documents(query, reference_docs=reference) score = llm_gateway.evaluate_faithfulness(query, response, reference) assert score >= 7, f"忠实度得分过低：{score}，回答内容：{response}，参考资料：{reference}"跑这一类用例时，还有几个规则我得提醒你：
- 一定要把裁判模型的版本固定住。如果不固定，你拿 A 模型当裁判，跑出来的分数是 8 分；改成 B 模型当裁判，可能变成了 5 分，那测试就没法追溯了。我的做法是把裁判模型按“评测集 A/B”两套分别运行，最后汇总两个分数的差值，以此量化评测器自身的波动性。
- 注意评测时长和 Tokens 的成本。一个用例跑两条链：被测模型一条链，裁判模型一条链，普通规模的回归集可能有几千条用例，跑一轮就要几千块钱。我的建议是在日常迭代中先用 5% 的核心样本做快速回归，只有在发布前跑一轮全量回归，这样既省成本，又能早发现大部分问题。
3.5 关键参数的选择与计算逻辑
在实测中，我常被问到“召回条数 TopK 设多少”“温度参数设多少”“相似度阈值多少合适”。这些问题没有标准答案，但可以借助测试来计算。
以“召回条数”为例：我常常会在评测集上轮询一个 TopK 候选列表，比如[3, 5, 8, 10]，然后对每一组 TopK，都运行召回命中率用例。把召回命中率画成一条曲线，你会发现从 5 到 8 往往是一个收益递减的拐点。超过 8 之后，虽然命中率略有上涨，但上下文长度和 Tokens 消耗几乎是线性增长，导致回答质量和响应速度双双变差，这就得不偿失了。我业务中最后确定是 TopK=5，这就是用数据算出来的，不是拍脑袋写的。
温度参数也同理。任务类型如果偏向“标准化操作”，比如提取信息、分类、改写标题等，温度应固定在 0 到 0.2 区间；如果偏向“创意生成”，比如营销文案、角色扮演类对话，温度才能放宽到 0.7 到 1.0。但测试场景里并不需要这种多样性，所以我会在评测网关里统一覆盖温度参数，保证测试结果可复现。
4. 常见问题与排查技巧实录：LLM 测试里的典型翻车现场
4.1 翻车场景一：模型在一段答案里混入了编造的数据
最让人头疼也最普遍的问题，就是模型一本正经地编造参考资料里根本不存在的内容。比如在回答“公司今年的体检套餐有什么升级功能”时，模型可能会自行发挥“增加癌症 15 项早筛”，但实际套餐里连这个影子都没有。
我在排查这类问题时，会先做两步：第一步检查 RAG 检索的 TopK 文档里是不是真的没有相关上下文；第二步把这条用例的答案和检索上下文单独拿出来，用忠实度评估器跑分，同时做一次“事实一致性校验”。如果评估器给“忠实度”打了低于 5 分的分数，我就直接判定这条用例为测试失败，并且记录失败原因和触发的检索上下文。长期跑下来，我可以总结出哪一类问题更容易诱发幻觉，然后在业务侧增加安全兜底话术。
4.2 翻车场景二：提示词模板改了个标点，测试直接大面积失败
有一次我为了统一部门内的文案风格，把提示词模板里一个“，”改成了“，”对，只是全角半角的差异，结果回归测试大面积失败。一开始我还以为是模型版本被静默升级了，查了半天才发现，模板尾部多了一个换行符，导致模型把这个换行符误读成了指令的一部分，输出风格自然就全跑偏了。
从那以后，我养成了一个习惯：把提示词模板本身也纳入测试管理。每次改动提示词，都走“提示词变更单”，并在评测群里记录改动内容和影响面。同时，在测试环境中把提示词模板哈希化，如果模板内容有变化，自动触发一轮指定用例集的回归。听起来很夸张，但做过一次就知道，很多 LLM 应用线上“突然变差”的事故，不是因为模型变了，而是因为提示词悄悄被某个同事“顺手优化”了。
4.3 翻车场景三：外部依赖不稳定导致测试结果噪声过大
LLM 应用很少是孤立的，总有向量数据库、第三方搜索、业务 API 等各种依赖。如果这些外部依赖在测试时不稳定，LLM 用例的噪声就会非常大。你很有可能在某一天跑测试，发现用例挂了一堆，可你什么都没改，原因可能就是向量数据库连接超时或者外部 API 限流。
我的解决方案是引入两层隔离：第一层，在测试准备阶段，把所有的依赖都替换成可 mock 的本地实现，比如用一个本地 JSON 文件模拟向量库检索结果，这样单测和集成测试能稳定运行；第二层，只留少量“端到端冒烟用例”专门跑真实外部依赖，这些用例不放在高频回归里，而是放到夜间任务，并且在任务失败时自动收集外部依赖的健康状态，用来判断是“应用自身问题”还是“依赖环境问题”。
4.4 Token 消耗失控，也是一项测试
不要觉得 Token 消耗跟测试没关系，事实上它直接影响了系统的可用性。在一次 Agent 链路测试中，我设计了一个包含五个工具调用的场景，结果跑一轮下来，Tokens 消耗比原本预估的高了 10 倍。查原因发现，工具调用返回的内容很长，模型在每一轮里都把这些长内容重新拼进上下文，导致每轮都重复计费。
我把 Tokens 消耗纳入测试断言范围，对“单轮对话平均 Tokens 消耗”“工具调用链路累计 Tokens 消耗”设阈值。一旦超过了基线值，测试用例就失败，并给出哪个环节消耗最多。通过这个机制，我们优化过提示词压缩策略，也调整过工具返回数据的截断方式，最终把单轮平均成本降下来 30% 以上。
| 测试层级 | 测试重点 | 典型风险 | 推荐工具/思路 |
|---|---|---|---|
| 模型原生能力 | 指令遵循、结构化输出、上下文保持 | 输出不稳定、提示词敏感 | 固定温度参数的 pytest 用例 + 评估器 |
| RAG 检索链路 | 召回率、相关度、TopK 命中 | 向量召回偏移、同义词失效 | 本地向量库 + TopK 命中率统计 |
| Agent 工具编排 | 工具调用参数、返回值回填、重试熔断 | 参数错传、链路反复循环 | mock 服务 + 全链路日志追踪 |
| 生成质量 | 准确性、忠实度、相关性 | 幻觉、答非所问 | 裁判模型评估 + 人工抽检 |
5. 实操心得与后续扩展方向
5.1 从“一次性评测”到“持续回归”的沉淀过程
很多团队做 LLM 测试都是“上线前评一轮”，做完就扔，测试用例躺在仓库里再也不跑。这套玩法最大的问题是你永远发现不了“应用慢慢变差”的趋势。模型版本可能从 3.5 升到 4.0，你说的 OTA 提升。但同一个提示词效果可能反而回落，这你会感知不到。
我在自己的项目里建设了一套持续回归流程：每天早上 8 点，跑一个只包含 200 条核心业务的评测集，把质量分数和 Tokens 消耗按时写入一张简单的 score 表；每周五下午，做一次全量回归，覆盖千级规模评测集。长期坚持下来，我手里就多了一份“系统质量日报”，相当于一套体重秤，只要有一点变差的苗头，都能及时发现而且可以追溯到是哪个版本、哪条修改引起的。
5.2 扩大战场：向智能体链路和自动化测试平台演进
这个系列已经打下了“为什么”和“怎么做”的第一根桩基。但往前看，LLM 测试真正的深水区是 Agent 的全链路测试。举个场景，你的 Agent 需要决策“这个用户问题要不要调用外部工具”，这本身就是一个概率行为。你可以在串行链路里验证 Web 端到端行为，但当 Agent 拆分成多条分支的时候，你发现每个分支都需要单独的测试编排和独立的评测集。
后续我打算继续深入讲三个方向：一是如何把 Agent 链路的每一步都变成可观测、可断言的节点；二是如何基于 lib 设计一个真正可落地的评测平台，把模型评测、RAG 评测、成本评测统一沉淀成可复用的平台能力；三是讲清楚怎么利用 Pytest 生态里的插件和 hook 机制，把 LLM 测试嵌入到 CI/CD 里，让每一版代码提交后都能自动跑一套面向 LLM 的质量门禁。
现在边界还没有成型，但“测试驱动开发”这个词，在 LLM 应用领域正在被重新定义。我的经验是，先不要追求一次性建出完美系统，从几十条核心评测集开始，搭好一个能记录、能回放、能打分的测试基座，你就算正式走上这个新战场了。我也会继续把我在各层链路里踩到的坑和经验持续沉淀在这个系列里，希望能让更多的人少走弯路。
