ARTICLE · 1145287
一次完整测试会留下哪些文档和产出物?
一次完整测试会留下哪些文档和产出物?很多刚学测试的人会觉得，测试工作就是打开页面、点按钮、发现问题、提 Bug。 这样理解只看到了中间的一小段。 
一个功能真正测完后，团队还需要知道：你测了什么？哪些没测？发现了什么问题？问题修好了吗？现在到底能不能发布？ 这些答案不能只靠测试人员说一句“我测过了”。要靠留下来的记录和结论。 这篇仍然只用一个场景：小林要测试“好物商城”的商品下单功能。这个版本新加了一条规则：订单满 99 元时，用户可以使用“满 99 减 10”优惠券。 我们就跟着小林走一遍，看看一次完整测试通常会留下哪些东西。 
测试产出物，指测试过程中留下、能被别人查看和使用的记录、数据或结论。 有的团队把它们写在 Excel 表格里，有的放在项目管理工具里，有的记录在在线文档中。工具和格式可以不同，内容不能凭空消失。 比如，小林在工具里写的一条 Bug，不是“随手记个问题”。开发人员要靠它复现问题，产品人员要靠它判断规则，项目负责人也会从中了解当前风险。 所以，测试产出物的作用很朴素：让别人不用站在你身边，也能明白你做过什么、看到什么、下一步该做什么。 严格说，需求文档通常不是测试人员从零写出来的，它往往由产品人员提供。 但测试人员必须留下自己确认过的测试范围和待确认问题。否则，测到一半很容易出现“我以为不需要测”“我以为这个规则是那样”的情况。 小林看到的需求是：“下单时支持使用优惠券。” 这句话明显不够细。她把需要确认的内容记下来： 本次只测试网页下单，还是 App 下单也要一起测？ 满 99 元的金额，是商品原价、优惠前金额，还是运费也算进去？ 一笔订单能选一张优惠券，还是能选多张？ 使用优惠券后取消订单，优惠券是否退回？ 这些内容还不能叫 Bug。 因为 Bug 的前提是“要求已经明确，实际结果却不符合”。规则没定下来时，正确做法是标成“待确认”。 这份记录可以很简单。重点不是格式漂亮，而是让小林后面写用例、执行测试时有依据。 测试计划是“这次测试准备怎么做”的安排。 规模比较大的项目里，测试组长或测试经理会编写测试计划；小项目里，也可能只是一段写在任务卡里的安排。新人不一定负责制定它，但要会读。 小林拿到的安排里，至少要看懂下面几项： 测试什么：本次重点是商品下单和优惠券抵扣。 在哪里测：测试环境的地址、版本和账号。 什么时候测完：开始时间、提测时间、需要给结论的时间。 谁负责什么：小林负责下单主流程和优惠券规则，另一位同事负责退款流程。 先测什么：能否下单、优惠金额是否正确，优先级高于页面文字是否好看。 这里的测试环境，是专门给测试人员验证功能的运行位置，不是正式用户正在使用的线上系统。 计划的意义不是把每一分钟排满，而是提前把范围、资源和顺序说清。测试时间只有一天时，小林就不能把精力平均撒在每个按钮上。 测试用例是为了验证一条功能或规则，提前写好的操作说明。 它通常会写明：要验证什么、准备什么数据、怎样操作、预期应该看到什么结果。 小林要验证“满 99 减 10”这条规则，可以先写一条很小的用例： 用例名称：订单金额满 99 元时使用优惠券。 前提条件：买家账号里有一张满 99 减 10 优惠券；购物车里有一件价格为 99 元的商品。 操作步骤：进入下单页，选择这件商品，选择优惠券，提交订单。 预期结果：优惠券可以被选择；订单金额从 99 元变为 89 元；订单能提交成功。 “预期结果”就是这一步本来应该发生什么。 没有预期结果，测试就容易变成“我点了一下，感觉没问题”。有了预期结果，实际显示 88 元、90 元，或者优惠券根本无法选择，才有明确的判断依据。 用例不等于把每个按钮都机械点一遍。它是把要验证的规则、场景和结果提前写清，防止漏测。 
测试数据，是为了验证规则而准备的商品、金额、账号、优惠券、收货地址等信息。 小林不能只用一件 100 元商品试一次，就说优惠券没问题。 她至少要准备：98 元商品、99 元商品、100 元商品；一张可用优惠券；一张已过期的优惠券。 为什么要有 98、99、100 这三种金额？ 因为 99 元是规则发生变化的位置：低于 99 元不能用，达到 99 元可以用。这样的临界位置叫边界值，很容易藏着计算错误或判断错误。 测试结束后，这些数据也要能被追溯。至少记录用的是哪个账号、哪个商品、哪张优惠券、在哪个测试环境测试。 否则开发人员问“小林当时到底下了哪个订单”，小林只能重新猜一遍，既慢又容易对不上。 有些团队会把环境地址、账号和数据单独维护；有些直接写在用例的前提条件里。放在哪里不是重点，关键是别人能按记录复现同一个场景。 测试用例写好了，不代表已经测试过。 执行记录用来说明：这条用例到底有没有跑、结果通过还是失败、失败时留下了什么证据。 小林执行“满 99 减 10”用例后，看到金额从 99 元变成 89 元，订单也成功生成。她可以把结果记为“通过”。 如果优惠券能选，但金额只减了 8 元，她就把这条用例记为“失败”，并进入下一份产出物：缺陷报告。 执行记录还有一个很实际的作用。 到了测试结束那天，别人问“下单相关的用例都测完了吗”，小林不需要翻聊天记录。看执行记录，就能知道总共多少条、通过多少条、失败多少条、还有多少条没执行。 未执行不等于失败。 它可能是测试数据还没准备好，也可能是功能还没部署。把状态分开记录，团队才能看见真正的阻塞点。 缺陷报告，就是把确认发现的软件问题记录下来，交给开发人员处理，并持续跟踪结果。 它是测试和开发之间很重要的沟通记录。 小林发现订单满 99 元却只减了 8 元。她写缺陷报告时，不能只留一句“优惠券金额不对”。 一条别人能用的缺陷报告，至少要有： 标题：满 99 元订单使用满 99 减 10 优惠券后只减 8 元。 环境和版本：在哪个测试环境、哪个版本发现。 测试数据：买家账号、商品价格、优惠券名称。 操作步骤：怎样进入下单页，怎样选择优惠券。 实际结果：订单金额显示为 91 元。 预期结果：订单金额应显示为 89 元。 证据：截图、录屏、订单号或报错信息。 复现的意思是，另一个人按照你的步骤操作，也能再次看到同一个问题。 缺陷不是提交后就结束了。开发人员修复后，小林还要做一次返测，也就是重新按原步骤验证这个问题是否真的修好了。 返测通过，缺陷可以关闭；返测仍然失败，缺陷就要重新打开，继续处理。 同时，小林还要看看这次修改有没有影响别的地方。比如优惠金额的计算逻辑改过后，满减活动、订单详情页、取消订单后的退款金额是否还正常。这类“修改后再检查相关功能”的工作，叫回归测试。 测试报告不是把测试过程从头到尾抄一遍。 它要回答一个更直接的问题：这个版本现在是什么状态，能不能发布，还有哪些风险？ 版本测试结束后，小林会把信息汇总成结论。例如： 本次测试范围是网页端商品下单和优惠券抵扣。 共执行 25 条用例，23 条通过，2 条失败。 其中，“订单金额抵扣少 2 元”的问题仍未修复，会直接影响用户支付金额，属于发布风险。 另外，“优惠券列表的提示文案不够清楚”已经修复，不影响本次发布。 测试报告里最有价值的不是“测试很辛苦”，而是把事实和风险说清楚。 产品和项目负责人据此决定：继续修、带着已知风险发布，还是暂缓发布。 有的团队叫它测试报告，有的叫测试总结、测试结论、发布评估。名字不一样，核心内容差不多：测试了什么、结果怎样、遗留什么问题、建议怎么做。 把小林的商品下单测试收起来，通常会看到这样一组东西： 已确认的需求范围和待确认问题。 测试计划或测试安排。 测试用例。 测试数据和环境、账号信息。 用例执行记录。 缺陷报告、截图或录屏，以及返测结果。 测试报告或最终测试结论。 不需要每个项目都产生七份单独的文件。 小团队可能把计划、范围和执行结果放在同一张表里；项目管理工具也能同时管理需求、用例和缺陷。但这些信息本身不能少。 第一个错，只写“通过”或“有问题”，没有留下依据。 这样过两天再回头看，连自己都记不清当时用了什么账号、测了哪个版本，更别说请别人复现。 第二个错，把测试报告写成“全部通过，可以上线”。 如果还有未修复的金额问题，就应该把风险写出来。测试人员的职责不是替团队拍板，而是把事实、证据和风险交代清楚。 你可以记住这句话：测试结束，不是关掉浏览器；是把本次测试能说明白、能复查、能交接的东西留下来。 下次你测试一个功能时，不妨对照一下：需求范围、用例、数据、执行记录、缺陷和结论，自己手里分别有没有。少的那一项，往往就是后面最容易说不清的地方。
先纠正一个误会：产出物不一定是一份 Word 文档
第一份：需求理解和测试范围记录
第二份：测试计划或测试安排
第三份：测试用例