免费测试计划模板

免费测试计划模板

测试计划定义了测试什么、如何测试、由谁测试以及何时测试——它是 QA 团队针对某个版本的路线图。使用此模板为任何软件或硬件产品规划结构化、全面的测试。

测试计划定义了测试什么、如何测试、由谁测试以及何时测试——它是 QA 团队针对某个版本的路线图。使用此模板为任何软件或硬件产品规划结构化、全面的测试。

使用此模板

使用此模板

完善的测试计划是阻止缺陷进入生产环境的关键。使用 Trupeer,您可以从免费的测试计划模板开始,结合您的 品牌规范 进行定制,并将测试计划转换为视频演示,从而节省测试规划所需的数小时,让工程、产品与 QA 保持一致。

什么是免费的测试计划模板?

免费的测试计划模板是一种可复用的文档结构,用于说明在特定版本或项目中将测试什么、在哪些环境中测试、由谁来测试、按什么时间表测试,以及如何判断测试是否已经完成。

目录部分是标准且无争议的:范围、方法、环境、资源、进度、进入标准、退出标准、风险、交付物。每个已发布的模板都有这些内容,而且自从 ISO 与 IEEE 的传统在几十年前确立以来,它们一直保持着相对稳定。

测试计划并不会在模板阶段就失败。它们会在某个特定时刻失败——通常是在计划获批数月之后——而且失败的形态总是一样。

格式取决于用途。免费的测试计划模板 Word 文件适合用于计划本身:计划是一段需要被评审并达成一致的文字;对于小型发布而言,只有一到两页的简单测试计划模板 Word 布局就足够了。免费的测试计划模板 Excel 版本适合用于进度、覆盖矩阵与资源配置。免费的测试计划模板 PDF 则是随发布记录附上的已批准副本,而来自已发布来源的测试计划文档示例 PDF,是查看如何正确完成的最佳方式。

测试计划先被阅读,之后再被争论

测试计划通常在测试开始前数周撰写,此时没有人处于压力之下。它会被平静地评审、达成一致,然后归档。

随后只会在一个确切的时刻再次被阅读:当有人想要发版,而测试尚未完成的时候。

就在那一刻,房间里的每个人都投入其中。日期已经被告知。客户正在期待。市场已经安排了某些事情。工程团队为此努力了数周,希望尽快结束。然后有人打开测试计划,阅读退出标准,却发现它并不能解决任何问题。

所有高优先级缺陷已解决。回归测试套件已通过。已获得 UAT 签字确认。

这些听起来都很坚定,但在压力之下没有一个能站得住,原因将在下一部分说明。因此,最终的决定仍会以一贯的方式做出:由最资深、也最投入的人来拍板;而测试计划提供的是一份可供指向的文件,而不是一种约束。

提前编写测试计划的全部价值在于:冷静做出的决定,总比周四晚上九点做出的决定更好。只有当这些决定确实被做出来时,这个价值才会实现;而在大多数计划里,它们只是被描述了而已。

如何在 Trupeer 中自定义此模板

步骤 1:打开“模板”部分

从主导航进入“模板”部分。

Open the Templates section in Trupeer

步骤 2:选择并打开模板

点击任意您想要使用的模板以将其打开。

Select and open a template in Trupeer

步骤 3:展开模板视图

如有需要,请展开模板视图,以便清晰查看完整布局与细节。

Expand the template view in Trupeer

步骤 4:编辑模板

点击“编辑”开始修改所选模板。

Edit the template in Trupeer

在编辑器中,您可以:

  • 添加新章节

  • 定义或更新格式规则

  • 添加徽标并调整其位置及相关设置

步骤 5:保存您的自定义模板

完成所有必要更改后,点击“保存”,将更新后的模板存为您自己的版本。

Save your customized template in Trupeer

步骤 6:预览并微调模板

当您想查看自定义模板的效果时,请打开“预览”。

Preview and fine-tune the template in Trupeer

在预览界面中,如有需要,您还可以继续直接进行调整,确保模板呈现得正是您想要的样子。

使用测试计划模板,您可以:

  • 写作省时:跳过空白页面,使用为 QA 构建的结构。

  • 提升测试覆盖:内置章节确保不会遗漏任何关键内容。

  • 保持品牌一致:使用 Trupeer 的品牌套件应用您的徽标、字体与颜色。

  • 跨发布标准化:为每个产品与发布使用同一份测试计划模板。

  • 随时可审计:与 IEEE 829、ISO 29119 及类似标准保持一致。

  • 覆盖全球团队:一键将测试计划翻译为 65+ 种语言。

先写退出标准,并注明谁可以豁免

两个改动都很简单,而这整页的核心论点就在这里。

在计划中先写退出标准。在范围之前、在方法之前、在进度之前。它颠倒了通常的顺序,并把最难的问题提前到前面——此时它是讨论,而不是谈判。计划中的其他内容都存在于满足退出标准,因此先决定退出标准也往往会让计划更短。

为每一项注明可能的豁免人。不是团队。是某个具体的人(按角色),而且尤其不是负责发版的那个人。

豁免权限才是“做事”的那个人。退出标准几乎从不会被正式覆盖,因为没有覆盖机制,所以它们会被重新解读。缺陷会被重新分类。标准会被更宽松地阅读。有人签署了自己并未核实的内容。

重新解读是看不见的,也不会留下记录。豁免是可见的,需要指定某个人在其上署名,并会产生一份之后可以查看的结果。两者的差异会在改变其他任何事情之前就改变行为,因为在会议中重新分类缺陷很容易,而签署豁免则不容易。

再增加一个字段:当某项标准被豁免时,记录正在采取的补偿性行动。先向 10% 的客户发布,或准备好回滚方案,或已完成对支持团队的简报。没有补偿的豁免,本质上只是决定接受风险——有时这是正确的,而且至少应该明确写出来。

让退出标准可执行

三个特性,而大多数已发布的标准都没有。

一个数字。不是“回归测试套件已通过”,而是“回归测试:优先级一用例执行 100%,通过 95%,未关闭的优先级一失败为 0”。“通过”和“执行”是不同的概念;如果计划没有区分它们,就会在一个实际仅执行了 60% 的套件上报告“通过 90%”。

一个不处于压力之下的核验人。严重性分级是每个测试流程中最“软”的环节,因为给缺陷分级的人往往也是想要发版的人。明确谁来分配严重性,并让这个人不在交付链条之内,就能移除绕过退出标准的最简单路径。

一个被命名的豁免权限人。如上所述,并且应当与发布负责人是不同的人。

对现有计划的一次有用审计。阅读退出标准,并逐条追问:如果不撒谎,要绕过它需要有人做什么。如果答案在 10 秒内就能得到,那么该标准就需要数字与核验人。

测试计划模板必须包含什么

十个组成部分,并且先写退出标准。

组件

它做什么

退出标准

测试要完整完成时必须成立的条件,并包含数字、核验人以及豁免权限人。

进入标准

测试开始前必须成立的条件。防止在不稳定的构建上开始测试并占用时间窗口。

范围

将测试什么,以及明确不测试什么。下文会覆盖。

方法

测试类型(手动与自动)以及各自用途。

环境

需要什么、它与生产环境的相似程度,以及数据具体如何对比。

测试数据

数据是什么、来源在哪里、如何刷新。它们经常被省略,而这也经常是缺陷被遗漏的原因。

进度与窗口

日期,以及用于说明计划测试能适配可用时间的计算。

资源

谁在测试、他们的时间投入多少,以及如果他们被抽走会发生什么。

风险

什么可能阻止测试完成,以及对应的应对措施。

交付物

测试会产出什么:结果、缺陷报告、证据、总结。

环境与测试数据这两行值得比模板提供的更多空间。大量进入生产环境的缺陷并不是因为测试用例太弱而被遗漏。它们是“不可触达”的:因为测试环境里只有一千条记录,而生产环境有四百万条;或者触发它们的时序条件无法在单台机器上发生。

免费测试计划模板:可复制的结构

用真实示例填充,而不是占位符。该系统是便利店的销售点软件。

从这里复制。

退出标准。先写出来,并包含数字、核验人以及豁免权限人。

#

标准

阈值

核验人

可由谁豁免

1

优先级一回归用例已执行

100% 执行,100% 通过

QA 负责人

无人。此项不允许豁免。

2

优先级二回归用例

95% 执行,90% 通过

QA 负责人

工程负责人,并记录补偿性行动

3

未关闭的缺陷

优先级一为 0;优先级二不超过 3 个,且已记录并达成一致的替代方案

QA 负责人

工程负责人

4

缺陷严重性分级

由 QA 指定,而非交付团队指定;且在发布决策会议期间不进行调整

QA 负责人

无人

5

UAT 签字确认

由指定的业务负责人签署,确认其已亲自执行附录 B 中列出的十二个业务场景

业务负责人

运营总监

6

性能

在峰值模拟负载(400 台并发收银机)下,交易完成时间不超过两秒

性能负责人

工程负责人,并记录补偿性行动

豁免需在发布前以书面形式记录补偿性行动,而不是发布之后。

进入标准。已将构建部署到预发布环境。冒烟测试通过。已加载并刷新测试数据。上一轮周期中没有未关闭的优先级一缺陷。

范围。在范围内:收银机交易、退款、日终对账、离线模式,以及新的促销引擎。不在范围内:后台报表套件(本次发布保持不变);新外设的硬件认证(另行进行);以及与第三方积分提供商的集成(由其供应商测试覆盖,并基于该测试结果接受;该风险已在下文记录)。

方法。对现有收银机与退款路径进行自动回归测试。对新的促销引擎进行手动探索性测试。对峰值模拟负载进行性能测试。离线模式通过物理断开连接进行测试,而非通过模拟。

环境。预发布环境:从大型门店环境的生产快照中恢复数据库。两代硬件共四台实体收银机。注意:预发布环境只有一台应用服务器,而生产环境有六台,因此负载均衡行为无法被真实呈现;这是一项已声明的风险。

测试数据。生产快照(已匿名化),每周刷新。至少包含一家门店,其历史交易量超过五万笔,因为与容量相关的缺陷此前已出现。

进度与窗口。三周。预计执行工作量为两名测试人员共 11 天;对应 15 天窗口中的 14 个工作日。另有 1 天的应急缓冲,但较为紧张,并作为风险记录。

资源。两名测试人员,全职。三天内安排一名性能工程师。两天内安排业务负责人进行 UAT。若任一测试人员被抽调到支持工作中,窗口将无法满足,且第二条标准将首先面临风险。

风险。预发布环境中只有单一应用服务器。进度存在一天的应急缓冲。第三方积分集成由我们尚未测试。该业务负责人为新任。

交付物。已执行的测试结果及证据、缺陷报告、测试总结报告;如有豁免则附上已签署的豁免记录。

从这里复制。

测试计划示例:三个高优先级缺陷最终变成两个

Danecroft Retail Systems 为便利店提供销售点软件,并拥有约一百八十名员工。它向一家拥有三百四十家门店的客户群发布了一个重大版本。

测试计划本身是一个常规版本。其退出标准写道:所有高优先级缺陷已解决,回归测试套件已通过,已获得 UAT 签字确认。

在发布决策当天,仍有三个高优先级缺陷未关闭。回归测试套件执行了 91%,但计划没有区分“执行”和“通过”。UAT 已由一位在岗五周的产品负责人签署。

发布经理将此事向 CTO 提出。CTO 问:那三个缺陷真的算高优先级吗?

会议期间,其中两个被重新分类为中优先级。第三个则基于“存在可用的替代方案”被接受。

没有人撒谎,也没有人覆盖任何内容。计划中没有对“高优先级”的定义,没有说明严重性由谁分配,也没有对回归执行设置阈值,更没有指定豁免权限人。既然没有可覆盖的内容,就也没有可记录的内容。

这两个被重新分类的缺陷之一在特定促销条件下会导致收银机冻结。它在周六全店高峰交易时出现。零售商估算损失销售额约为 89 万英镑,适用合同罚金,并由 Danecroft 退还了数月的费用。

评审发现了三个具体的薄弱点,全部都在退出标准里,而不在测试本身。

严重性由处于压力之下、想要发版的人来分配。“通过”和“执行”被当作同义词使用,因此 91% 听起来像是通过率。而签字确认没有点名具体个人,也没有说明他们确认了自己做过什么。

重写之后,每一项标准都被赋予了数字,指定了交付链条之外的核验人,指定了不是发布经理的豁免权限人,并要求豁免必须以书面形式记录补偿性行动。

在接下来的六次发布中,共发出了两次豁免。两次都被记录,两次都附带补偿性行动,并且在发布决策会议期间没有对任何缺陷进行重新分类。

测试本身是足够的。问题在于计划没有提供机制让测试真正发挥作用。

如何用六个步骤编写测试计划

  1. 先写退出标准,在文档的任何其他内容之前,用数字表达。

  2. 为每一项指定核验人,并确保核验人的目标不包含发版日期。

  3. 为每一项指定豁免权限人,包括那些完全不能被豁免的标准。至少有一项不可豁免,才能让其他豁免变得有意义。

  4. 写清范围(包括不在范围内的内容),并说明每一项排除为何是可接受的。

  5. 诚实描述环境,尤其是与生产环境存在差异、可能掩盖缺陷的地方。

  6. 做进度计算并记录应急缓冲,这样当窗口被压缩时,讨论的重点应是哪些标准面临风险,而不是测试是否“差不多完成了”。

第三步才是改变结果的关键。一个所有内容都能由发版负责人豁免的计划,本质上只是意图的描述。

范围与您不测试的内容

“不在范围内”部分是测试计划中第二重要的内容,而且大多数计划里只占一行。

其中应包含三类内容,而且它们是不同的。

明确排除,因为它没有变化。这是合理的,并且值得写出原因,因为“未变化”有时会被证明是错误的假设。

排除,因为由其他人来测试。第三方组件、供应商集成、硬件认证。说明是谁在测试,以及您接受的是哪些证据。风险会在这里被悄悄转移。

排除,因为在这里无法测试。负载均衡行为、真实支付网络、生产数据量、真实并发。这些才是最诚实的情况,它们也应该同时出现在风险部分与范围部分,因为它们点名了流程无法捕捉的缺陷。

第三类内容是用来预测生产事故的。一个能列出“测试无法触达什么”的团队,才知道当出问题时该去哪里找。

测试计划、测试策略还是测试用例?

三个层级,它们之间的混淆非常常见,因此值得直接说清楚。

测试策略是组织层面的:这家公司如何测试、使用哪些测试类型、适用哪些标准。一次编写,适用于所有项目。

测试计划则针对某个具体发布或项目。就是本页所讲的内容。

测试用例是一次检查:包含步骤与预期结果。测试文档模板 页面涵盖了这些内容,并解释了为什么“预期结果”是大多数测试套件出错的地方。

在这三者之上还有 QA 计划,它涵盖的是为防止缺陷而进行的所有工作,而不是为了发现缺陷:需求评审、完成定义、代码评审标准。QA 计划模板 页面会说明这种区别。如果您的 QA 计划只包含测试,那么您写的其实是一个标题更宽泛的测试计划。

发布是否能够发出的问题,比“测试是否完成”更广泛,因为文档、支持就绪与计费配置也会作为门槛。发布需求模板 页面会覆盖这些内容。

测试计划的变体

结构保持不变,重点会有所移动。

敏捷或按迭代(sprint)的测试计划。通常更短,往往只有一页,并且经常被并入“完成定义”。退出标准的论点同样适用且不变,而且更重要,因为每个迭代都会重复做出同样的决定。

用户验收测试计划。退出标准是由某个人签署某些内容,因此需要明确他们确认的是自己亲自完成了什么。对一份无人阅读的文档进行签字,是常见用法中最薄弱的控制手段。

性能与负载测试计划。阈值天然是数字,因此这些计划最容易编写出可执行的标准。难点转移到:环境能否生成具有代表性的负载。

受监管与已验证的环境。在制药、医疗器械及类似场景中,对测试文档、可追溯性与审批有明确要求;计划也是证据包的一部分,可能会在数年后被检查。应基于合格输入并按适用标准构建,因为本页内容无法替代这些要求。

硬件与集成系统。测试计划必须覆盖物理配置与环境条件,因此环境部分通常会成为文档中最长的部分。

免费测试计划模板无法解决什么

一个无法移动的日期。如果无论如何都要发布,那么计划只会记录“跳过了什么”,而不是阻止它。某些情况下这确实是合理的业务决策,应该直接说明,而不是伪装成“通过”的标准。

一个无法暴露缺陷的环境。任何免费的测试计划模板下载都无法为您提供生产环境的数据量或真实并发。

由利益相关方分配严重性。退出标准被绕过的最常见方式之一就是这样;这属于治理选择,而不是文档问题。

从未现实过的时间窗口。至少在计划中做进度计算,会让短缺在仍有时间调整时变得可见。

展示测试确实发生过

退出标准依赖证据,而在大多数组织中,证据通常是一列状态字段。

回归测试套件已运行。有人勾选了用例。每个用例是否按写法执行、实际观察到了什么——这些信息在任何地方都没有被记录。这意味着“100% 已执行”的标准依赖的是断言,而不是记录。事故发生后,审查的就是这条断言,而且通常无论如何都无法被证实。

Trupeer AI 会作为副产品生成这份记录。记录一次测试运行,会得到一份书面演示流程,并附带已捕获并放置好的截图;同时,这些内容会与视频一起放入您自己的品牌体系中。每一步实际观察到的内容是真实存在的,而不是被断言出来——这正是核验人需要的,以便能够诚实地签署某项标准。

记录它。打造它。翻译它。用 Trupeer 来完成它。

接下来有两点。第一,当测试由外包或离岸团队执行时,实际做了什么的证据比状态报告更有价值,而录制是最便宜的方式。第二,由经验丰富的测试人员在复杂场景中逐步操作的录制,能让新测试人员学习“正确检查”应当是什么样子——而这种习惯,是任何书面用例都无法传递的。

这些材料放在您的 知识库 中,同时也可作为 培训 使用。让文档之间保持一致,只需要先设置一次 品牌套件;而模板的设置流程则在 文档模板设置指南 中有说明。

常见问题

有免费的测试计划模板 Word 版本吗?

Word 适合用于计划本身,因为其中大部分是需要被评审并达成一致的文字,而且通常还需要审批。测试计划模板的 Word 文件是正确的工作格式。

把退出标准表放在第一页。每个模板都会把它们放在靠近末尾的位置:在起草过程中它们最后才会被阅读、也最不受关注;而它们又是文档中唯一会在压力之下被使用的部分。

有简单的测试计划模板 Word 版本吗?

有。对于小型发布或单个迭代,只有一到两页的简单测试计划模板 Word 文件完全适用。

在删掉退出标准之前,先删掉“方法”和“资源”部分。一个包含数字标准、指定核验人和豁免权限人的一页计划,比一个没有这些内容的十五页计划更有价值。

有免费的测试计划模板 Excel 版本吗?

Excel 适合用于测试计划中表格化的部分:进度、覆盖矩阵、资源分配以及退出标准表本身。测试计划模板的 Excel 文件能很好地处理这些内容。

范围、方法与风险部分是文字内容,应该放在同一份文档中。把计划拆到两个文件里也可以,只要其中一个引用另一个,并且只有一个是已批准版本。

有免费的测试计划模板 PDF 吗?

PDF 是随发布记录附上的已批准副本。将已达成一致的版本与日期导出一次免费的测试计划模板 PDF,并将其与结果及任何豁免记录一起保存。

如果之后出现问题,这个打包文件就是会被审查的内容;而豁免记录是人们最希望自己拥有的那部分。没有豁免记录的计划,会让所有人试图从记忆中重建当时的会议。

我在哪里可以找到测试计划文档示例 PDF?

大学、公共部门采购以及受监管行业都会发布真实案例;来自这些来源的测试计划文档示例 PDF 比商业模板更有用,因为它是在真实约束下编写的,而且往往会由具备权限的人进行评审。

阅读退出标准与“不在范围内”部分。这两部分能说明该计划是控制手段还是形式主义;而它们也是不同组织之间差异最大的部分:那些能可靠发版的组织与那些不能的组织,差异往往就体现在这里。

免费的测试计划模板免费下载值得用吗?

目录部分几十年来一直保持稳定,因此免费的测试计划模板免费下载对您节省的并不多,而且每个版本提供的结构大体相同。

用一个问题来判断它们。退出标准是否为阈值、核验人和豁免权限预留了空间?没有。添加这三列只需要两分钟;它们也是区分“做出决定的计划”和“描述意图的计划”的关键。

退出标准到底应该写什么?

数字、核验人以及豁免权限人。不是“回归测试套件已通过”,而是“优先级一用例执行并通过 100%(通过率经 QA 负责人核验,且不可豁免)”。

测试的关键在于:是否有人在不做实际工作的情况下、也不撒谎就能满足该标准。如果缺陷可以被重新分类,那么一个百分比就可能被解读为通过率;如果签字可以由未核验任何内容的人完成,那么该标准就存在绕过路径,需要增加另一条约束。

谁应该编写测试计划?

由负责测试的人来编写,并由不拥有发版日期所有权的人来确认退出标准。这样的分离才是重点;因此,完全由交付团队内部编写的计划往往会有“软”的标准。

让业务负责人专门阅读退出标准,因为其中通常有一项依赖他们的签字;他们也应该提前知道自己将确认的是“亲自完成了什么”。

需要视频剪辑师、翻译和编剧吗?

免费试用 Trupeer

预约演示

需要视频剪辑师、翻译和编剧吗?

免费试用 Trupeer

预约演示

需要视频剪辑师、翻译和编剧吗?

免费试用 Trupeer

预约演示