使用此模板
扎实的测试文档是任何质量工程实践的基础。使用 Trupeer，您可以从免费测试文档模板开始，通过用您的 品牌规范 进行自定义，并将测试计划转换为与工程、产品和 QA 对齐的视频演练，从而节省编写测试文档的数小时。
免费测试文档模板是什么？
免费测试文档模板是测试工作会产出的文档的可复用结构：策略、计划、测试用例、数据、结果以及缺陷报告。
大多数人搜索它们，其实是在找某一份文档。测试用例是测试人员花时间编写的内容，而测试用例模板就是一张包含步骤的表格，这并不难。
模板本身不是问题。每一份已发布的测试用例模板都有相同的列：标识符、标题、前置条件、步骤、预期结果、实际结果、状态。这个结构是正确的，而且几十年来一直保持稳定。
大多数测试套件的问题在于：在这个结构内部投入的精力分配不均，最终会产出在系统已损坏的情况下仍可能通过的测试用例。
格式源于用途。测试用例模板 Excel 免费下载是最常见、可直接使用的格式，也很适合用作用例表格。测试用例模板 Word 文件适用于测试计划和策略，因为它们是偏叙述性的内容。测试文档示例 PDF 则通常会作为证据附在发布记录上。
测试集中的文档
六份文档，每一份回答一个不同的问题。在采用任何内容之前，先弄清楚您真正需要哪些，是很值得的。
测试策略。 这个组织总体上如何测试。编写一次，少量修订，适用于所有项目。
测试计划。 本次发布或项目将在哪些环境中、由谁来测试，使用什么进入与退出标准，以及具体时间安排。
测试用例。 单个检查项。步骤以及更关键的预期结果。
测试脚本。 自动化的对应物：用代码实现用例，而不是由人员手动执行。
测试数据。 用例运行所依据的数据——它本身也是一种文档，且往往是整个测试集里最缺乏控制的部分。
测试结果与缺陷报告。 发生了什么，以及提出了什么。测试用例文档示例 PDF 通常最终呈现的就是这一部分，因为组织会保留结果。
任何软件测试文档模板套件都应覆盖这六项，而大多数套件会覆盖两项。大多数组织会保留第三项和第六项，其余部分则临时补齐。这是可以“活下去”的。但不可承受的是：第三项写得很差，因为下游的一切都依赖它。
如何在 Trupeer 中自定义此模板
步骤 1：打开模板（Templates）区域
从主导航进入“Templates（模板）”区域。
步骤 2：选择并打开某个模板
点击任意您想要使用的模板以将其打开。
步骤 3：展开模板视图
如有需要，可展开模板视图以清晰查看完整布局与细节。
步骤 4：编辑模板
点击“Edit（编辑）”开始修改所选模板。
在编辑器中，您可以：
添加新的章节
定义或更新格式规则
添加徽标，并调整其位置及相关设置
步骤 5：保存您的自定义模板
完成所有必要更改后，点击“Save（保存）”，将更新后的模板存为您自己的模板。
步骤 6：预览并微调模板
当您想查看自定义模板的效果时，打开“Preview（预览）”。
在预览界面中，如有需要，您还可以继续直接进行调整，确保模板呈现得与您想要的一致。
使用测试文档模板，您可以：
节省编写时间： 跳过空白页面，直接使用经验丰富的 QA 团队常用的结构。
提升测试覆盖率： 内置章节可确保不会遗漏任何重要内容。
保持品牌一致性： 使用 Trupeer 的品牌套件应用您的徽标、字体和颜色。
跨产品实现标准化： 每次发布与每个团队都使用相同的模板。
随时准备接受审计： 与 IEEE 829、ISO 29119 及类似标准保持一致。
覆盖全球团队： 一键将测试文档翻译为 65+ 种语言。
预期结果就是测试用例
阅读任何测试套件，看看这些词出现在哪里。
步骤会写得很详细。打开应用。进入付款界面。选择一笔交易。点击“退款”。输入金额。确认。七条精确指令，每一条都毫不含糊。
接着看预期结果。它会写类似这样的话：退款已成功处理。
这一行就是整个测试。上面的一切都是准备工作。而最不需要费脑的恰恰是这行，因为编写精确步骤很容易，定义“什么才算正确”却很难。
结果就是：测试人员会按下七条准确指令操作，看到看起来像成功的内容，然后勾选通过。他们并没有做错任何事。文档问的是“退款是否成功处理”，他们看到成功提示，并且确实如此。
文档从未问过的是：是否恰好创建了一笔退款、账本是否只按正确的金额发生了变动，或者下游是否收到了重复内容。
如果预期结果可以通过对界面的乐观解读来满足，那么只要测试人员赶时间（发布前后大多数时候都会赶），测试用例就会通过。
编写可能失败的预期结果
三个特性，而且可以在现有套件中轻松核查。
它命名的是状态，而不是印象。 不是“记录保存正确”，而是“记录出现在列表中，状态为 Active，且修改时间戳在过去一分钟内”。
它可以在执行动作之外进行核查。 这是用来揪出昂贵缺陷的特性。如果动作发生在用户界面中，那么最强的预期结果应该是在别处得到验证：在数据库中、在报表中、在下游系统中、在对账单中。界面擅长报告成功，却不擅长报告真正发生了什么。
它在系统看起来没坏的情况下也可能失败。 如果测试失败的唯一方式是出现可见错误，那么测试只会发现那些会“自报其错”的错误。沉默的错误才是测试用例存在的意义，也是那些模糊的预期结果最可靠地漏掉的东西。
一次实用的审计：在一个几百条用例的套件上花一个下午即可。只读预期结果，忽略步骤。统计有多少可以仅通过观察屏幕来满足，又有多少使用诸如“正确地工作”“按预期运行”“成功完成”“无错误”等措辞——这些都根本不是结果。大多数套件里，这两个数字通常都很高。
测试用例模板必须包含什么
九个字段。模板本身不是问题，而是对其中两个字段的指导。
字段 | 它的作用 |
|---|---|
标识符 | 稳定且从不复用，因此用例可以在缺陷报告和覆盖率讨论中被引用。 |
标题 | 一句话说明正在测试什么，方便他人搜索。 |
优先级 | 因为没有人会把完整套件都跑一遍；如果不选择，压力最大的那个人就会替您选择。 |
前置条件 | 在执行第一个步骤之前需要的状态、数据与访问权限。 |
步骤 | 每次只做一个动作。最简单的部分。 |
预期结果 | 必须为真的内容、在哪里检查，以及写清楚以便它“可能失败”。整套测试的核心。 |
实际结果 | 执行过程中观察到的内容填写进去，而不是勾选。 |
状态 | 通过、失败、阻塞、未执行。阻塞与未执行是不同的；把它们合并会掩盖覆盖率的空缺。 |
证据 | 截图、查询输出、引用。任何能展示实际结果的材料，而不是用来“断言”它。 |
“阻塞”和“未执行”的区分比看起来更重要。一个报告显示 90% 通过的套件，可能只跑了 60% 的用例；如果所有未通过项都用同一种方式记录，那么差异就会完全不可见。
免费测试文档模板：可复制的结构
用真实示例填充，而不是占位符。系统是一个支付处理平台。
从这里复制。
测试计划（大纲）。 范围：4.9 版本的退款处理。范围内：全额退款、部分退款、针对已结算与未结算交易的退款。范围外：拒付（chargebacks），因为规则不变。环境：预发布环境，数据量与生产一致。进入标准：已部署构建、冒烟测试通过、测试数据已加载。退出标准：所有优先级为一的用例通过、没有未关闭的优先级一或二缺陷，并且在完整运行期间账本对账干净。
测试用例。
标识符：TC-118。标题：针对已结算交易的全额退款会准确创建一条退款记录。
优先级：一。
前置条件：商户账户 M-4471 存在，且有一笔已结算交易 T-88210，金额为 240.00。开始前已记录 M-4471 的账本余额。测试人员具备退款权限。
步骤。
打开付款界面并搜索 T-88210。
选择该交易并选择“Refund（退款）”。
输入 240.00 并确认。
预期结果。四个条件，全部都必须成立。
针对 T-88210 存在一条退款记录，且仅一条。检查位置：退款表（refunds table），而不是界面。
商户账本中 M-4471 的余额相较于开始前记录的初始值，准确减少了 240.00。检查位置：账本报表（ledger report）。
该期间的商户对账单显示一行退款记录，金额为 240.00。
交易状态在界面中显示为“Refunded（已退款）”。
注意：界面检查是四项中的最后一项，也是最弱的一项。之所以包含它，是因为用户会看到它，而不是因为它能验证任何东西。
实际结果：在执行时记录，并观察账本数据而非假设。
状态：通过、失败、阻塞或未执行。
证据：退款表的查询输出，以及账本报表对应行的副本。
缺陷报告（如失败）。 用例标识符、预期结果、观察到的结果、环境、构建版本、使用的数据、复现步骤、严重性。使用的数据字段最常被遗漏，也最常导致无法复现。
复制到这里。
测试文档示例：三百三十八条通过
Brayford Payments 为小型商户处理银行卡支付，并雇佣约两百名员工。它发布了更新后的退款流程。
付款模块中有三百四十条测试用例。用户验收测试运行了完整套件。三百三十八条通过。有两条失败，已修复，并重新测试。
在生产环境中，超过某个数值的退款在特定时序条件下会被执行两次。它运行了九天才被人发现，产生了约一千四百笔重复退款，总金额为四十一万二千英镑。追回已支付给商户的资金既慢又尴尬，最终大约 60% 被退回。
用例 TC-118 覆盖了退款。它有七个详细步骤，预期结果读取为：退款已成功处理。
测试人员完成了全部七步，看到了确认消息以及状态为“Refunded（已退款）”，并记录为通过。这就是对他们面前这份文档的正确应用。
没人去查看账本。用例里也没有要求他们查看。单笔退款和双笔退款在确认界面上看起来完全一样，这正是为什么检查必须发生在别处。
事后审计读取了全部三百四十条预期结果，忽略了步骤。
其中两百一十一条可以仅通过观察用户界面来满足。另有四十七条根本没有任何可核查的陈述，使用的都是诸如“按预期工作”“表现正确”或“无错误完成”等措辞。
补救措施是三周的重写，而不是新增测试。每一条预期结果都必须命名具体状态，说明在哪里检查，并且在没有可见错误的情况下也可能失败。当自然的检查点在界面之外时，就把检查放到那里。有些用例合并后，整个套件减少到两百九十条。
再过两次发布后，在用户验收测试中发现的缺陷数量，从每次发布的平均四条降到了十九条。
数字上升就是结果。接下来六个月里生产环境缺陷从十一条降到了两条。
这个套件并不算太小。它提出了三百四十个问题，而系统可以用一种“乐观”的方式回答它们。
用六步编写测试用例
先写预期结果，再写步骤。 这会颠倒通常的顺序，并迫使您在描述如何到达之前先决定“正确”意味着什么。后写的步骤会更短，也更贴近实际。
说明在哪里检查结果。 界面、数据库、报表、下游系统。命名检查位置，才让结果可以被其他人验证。
追问：在错误的情况下它怎么也能通过？ 如果您能回答，那么预期结果还需要另一个条件。
然后写步骤：每次只写一个动作。 这是最简单的部分，应该花费最少的时间。
记录前置条件（包括数据）。 复现缺陷失败的多数原因，来自数据不同而不是步骤不同。
诚实地设定优先级。 发布前没有人会跑完整套件。提前决定哪些用例重要，比在发布前一天晚上九点临时决定要好。
第一步就是整个方法。第二步和第三步用来捕捉那些最终进入生产环境的缺陷。
测试用例 vs 测试场景
这两者经常被互换使用，但差别在于层级。
测试场景是要测试什么的描述，站在任何人都能理解的层级。验证：已结算交易的退款能否正确工作。这是一种覆盖率声明。
测试用例是如何测试它：包含具体数据、具体步骤以及具体预期结果。一个场景通常会产生多个用例。
有用的做法是：先写场景，与理解业务的人就覆盖范围达成一致，然后再在其下方编写用例。反过来做，会得到一个套件：它覆盖的只是编写者当时想到的内容。
只产生一个用例的场景，通常说明这个场景并没有被认真思考。针对已结算交易的退款，应该产生覆盖全额、部分金额、超过原始金额的金额、对同一笔交易再次发起退款的用例，以及对已退款交易再次退款的用例。这五种情况里有四种缺陷就藏在其中。
测试策略、测试计划与 QA 计划
上面这三份文档位于测试用例之上，而它们之间的区分也具有实际分量。
测试策略是组织层面的、长期存在的内容。我们如何测试、使用哪些测试类型、我们的标准是什么。它适用于所有项目，且很少修订。
测试计划针对某个发布或项目而定。范围、环境、进入与退出标准、时间安排、资源、风险。测试计划模板 Excel 免费下载通常会给您时间表和矩阵，而那些叙述性章节属于文档本身。
QA 计划比两者都更广，因为质量保证包含了所有用于预防缺陷的工作，而不是为了发现缺陷：需求评审、完成定义（definition of done）、代码评审标准、环境一致性。QA 计划模板 覆盖了这种区分，而这在这里很重要：因为一份标题为 QA 计划、但只包含测试阶段的文档，已经在不知不觉中变成了测试计划。
真正的测试在于时序。工作完成之前发生的活动是保障（assurance）。工作完成之后发生的活动是控制（control），而测试就是控制。
免费测试文档模板无法修复什么
没有人同意的需求。 测试用例会根据某个预期来验证行为；但如果预期从未被确定，测试人员就会基于自己的假设来编写用例。
套件太大，跑不完。 每个组织都会走到这样一个阶段：完整的回归套件无法放进可用窗口。刻意地进行优先级排序，比在压力下排序更好；而任何测试用例模板 Excel 免费下载都无法替您做到这一点。
模糊的预期结果。 没有任何测试用例模板：免费下载和没有简单测试用例模板 Excel 布局会替您写出它；而且它也是唯一决定用例是否“能用”的字段。
不能代表生产环境的测试数据。 Brayford 的缺陷需要特定的时序条件和真实的数据量。但测试环境中不存在这些条件，因此任何模板都无法解决。
没有权限阻塞的测试人员。 可以被任何想要发版的人“豁免”的退出标准，并不算标准。
展示测试，而不是描述它
在这个领域里有两个问题，它们是同一个问题，且都与证据有关。
测试证据通常只是状态列里的一个勾选。有人运行了用例并说“通过”。如果之后在这个区域出现了缺陷，就无法确定当时实际观察到了什么，因此“用例是否被正确执行”的问题就无法回答，通常也会演变成争论。
第二个问题是：新加入团队的测试人员会通过观察别人来学习“如何正确检查”。如果没人有时间，他们就会从文档中学习，而这正是乐观解读的来源。
Trupeer AI 同时解决这两个问题。记录一次测试执行，会生成一份带有截图的书面演练（截图已捕获并放置好），并与视频一起放入您自己的品牌样式中。每一步实际观察到的内容会被记录下来，而不是被断言。这正是发布记录所需要的证据，也是新测试人员学习的材料。
记录它。赋予品牌。翻译它。用 Trupeer 来做。
接下来有两个要点。记录一位有经验的测试人员运行复杂用例，会展示他们在界面之外进行的检查——而书面用例往往无法传递这种习惯。并且当测试在不同站点之间进行，或由外包团队执行时，同一份记录会定义相同的检查标准，而不是把它留给解释。
这些材料放在您的 知识库 中，同时也可作为新测试人员的 培训。至于发布是否真的能发，这是另一个问题，会在 发布要求模板 中单独说明。您的文档之间保持一致性，只需要先设置一次 品牌套件；文档模板的设置方式则在 文档模板设置指南 中有讲解。
常见问题
有测试用例模板 Excel 免费下载吗？
Excel 是测试用例的标准可用格式，也很适合它们，因为一个套件就是一张表，您可以按模块、优先级和状态进行筛选。测试用例模板 Excel 免费下载会提供标准列，作为起点也确实足够。
值得添加两项内容：一列用于记录预期结果在哪里被检查，也就是界面、数据库、报表或下游。以及分别为“阻塞”和“未执行”设置状态值，因为把它们合并会掩盖实际上执行了套件的多少。
有简单的测试用例模板 Excel 版本吗？
有，而且“简单”通常就是正确的。一个简单的测试用例模板 Excel 布局，包含标识符、标题、优先级、前置条件、步骤、预期结果、实际结果和状态，几乎覆盖了所有需求。
不要急着添加更多列。测试用例模板会在设计时不断累积一些看似有用的字段，但在实际使用中往往会被留空；而一个有 8 列已填充内容的套件，比一个有 20 列但其中 12 列为空的套件更有用。
有测试用例模板 Word 版本吗？
Word 更适合放在周边文档里，而不是用在用例本身。测试用例模板 Word 文件适用于测试计划、测试策略或汇总报告——这些都是偏叙述性的内容。
但对于用例本身，Word 并不合适。您无法筛选、无法按优先级排序，而且在测试运行期间要在 Word 表格中更新两百条用例的状态会慢到让人无法准确地持续执行。
有测试用例模板：值得使用的免费下载吗？
这些列在几十年前就已经稳定了，因此测试用例模板：免费下载能为您节省的并不多，而且每个已发布版本大体上都相同。
用一个问题来判断它们：预期结果这一列是否附带了任何指导，还是只是一个空白单元格？空白单元格正是大多数测试套件出错的地方；没有模板能完全解决它，但如果模板会提示“在哪里检查结果”，那么写入该字段的内容质量就会更好。
有测试计划模板 Excel 免费下载吗？
Excel 适合测试计划中的时间安排、覆盖率矩阵以及资源计划。测试计划模板 Excel 免费下载通常会给您这些内容。
叙述性部分属于文档本身：范围、进入与退出标准、环境、假设与风险。这些需要被阅读并协商，而在电子表格单元格里协商会很糟。两者都保留，并相互引用。
我在哪里可以找到测试文档示例 PDF？
公共部门的采购记录、大学项目以及一些标准机构会发布真实的测试文档；从这些来源获得的测试文档示例 PDF 比商业模板更有启发性，因为它是在真实约束下产出的。
阅读测试用例文档示例 PDF 时，关注预期结果而不是结构。结构可以从任何地方迁移过来。真正值得学习的是：真实团队如何用文字表达“什么才算正确”，以及他们的检查是否放在界面之外。
我在哪里可以找到测试用例文档示例 PDF？
同样的来源都适用，而监管行业往往是最丰富的，因为那里的测试证据必须经得起审计，并且通常会写得更精确。
阅读测试用例文档示例 PDF 时，查看实际结果列是否包含观察记录或勾选。勾选告诉您套件已被运行。观察记录告诉您看到了什么，而只有第二种才是证据。
是否有软件测试文档模板套件？
有，套件包含六份文档：策略、计划、用例、脚本、数据以及结果（含缺陷报告）。软件测试文档模板套件通常会覆盖计划和用例，并把其余部分留给您自行补齐。
测试数据是最常缺失的那一项，也是最常导致缺陷无法被复现的那一项。记录套件运行所依据的数据是什么、以及如何刷新这些数据，其价值不亚于再补充另外五十条测试用例。
