字节测试总监，让我们用这份《测试用例规范》，再也没加班过

Posted 2023-04-02 程序员江念

经常看到无论是刚入职场的新人，还是工作了一段时间的老人，都会对编写测试用例感到困扰？例如：

固然，编写一份好的测试用例需要：充分的需求分析能力 + 理论及经验加持，作为测试职场摸爬打滚的老人，给大家分享一些用例编写的心得，接下来我会从以下几个方面展开来讲：

1、为什么要写测试用例？

• 是测试工作的指导，是软件测试质量稳定的根本保障，评估测试结果的基准。
• 有一份用例来指导测试执行，可以在测试人员疲累的时候起到一个牵引作用。
• 编写用例的过程中，通过熟悉需求，对系统架构或业务有更深入理解
• 可避免测试背锅

2、测试用例模板：每家公司模板可能会有差异性，一般大致包含以下内容

• 用例编号：唯一性，一般规则：产品名_测试阶段(it st uat)_测试项_数字
• 测试项目：对应一个功能或子功能模块
• 测试标题：一句话总结当前测试的用意和目的
• 重要级别：高/中/低
• 预置条件：需要满足一些前提条件，否则用例无法执行
• 测试输入：需要加工的输入信息，跟步骤结合起来一定要具有指导性意义
• 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
• 预期结果：根据预期输出比对实际结果，来判断被测对象是否符合需求
• 实际结果：通过测试执行后的实际结果，写用例时为空。

3、测试用例编写形式

• 通过 Excel 编写，上述给出的模板就是该种形式 ，适用于项目开发时间比较充分的情况下
• 通过 Xmind 梳理测试点，适用于项目开发时间紧急情况下
• 项目管理平台例如禅道上编写，不常用

如何编写测试用例

大体思路分为三步：

第 1 步：依据需求梳理功能及功能点

第 2 步：通过测试理论方法及经验，梳理测试点

第 3 步：挖掘隐性需求，覆盖非功能测试层面

总结

编写用例虽然不是那么简单的事，但是通过以上，是不是发现还是有方法可循的？不会写的先模仿着来写，日积月累，通过项目中测试思维的长期训练，工作中出现 bug 的经验总结，相信某一天你会发现编写测试用例也没有那么难！

公司新来的字节大佬把设计用例规范的整理成下面的PDF文档，包含了测试用例原则，测试用例主要元素，测试用例编写规范，测试用例编写细则，测试用例编写方法。看完这个PDF，你的测试用例再也不用担心出问题了。

1.目的

统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

2.范围

适用于集成测试用例和系统测试用例的编写，现在编写用例的辅助工具为TestDirector 8.0

3.术语解释

集成测试：

集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。

系统测试：

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。

4.测试用例原则

系统性

1.对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

2.对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；

连贯性

1.对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；

2.对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

全面性

1.应尽可能覆盖程序的各种路径

2.应尽可能覆盖系统的各个业务

3.应考虑存在跨年、跨月的数据

4.大量数据并发测试的准备

正确性

1.输入界面后的数据应与测试文档所记录的数据一致

2.预期结果应与测试数据发生的业务吻合

符合正常业务惯例

1.测试数据应符合用户实际工作业务流程

2.兼顾各种业务变化的可能

3.要符合当前业务行业法律，法规。

仿真性

人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。

可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

鉴于篇幅所限，无法一一为大家展示这份超级实用的测试用例编写规范

文档获取方式：

这份文档，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点击下方链接免费获取。

 

喜欢打游戏？这份优秀的游戏测试用例一定要用上

前言

如何设计一份优秀的游戏测试用例？本文章将向广大读者说明用例设计的重点和注意事项，话不多说，让我们一起看看吧~ （在后续的实战测试中会进行测试用例的展示，敬请期待！）

用例工具选择

测试用例的编写工具有很多选择：Xmind、Excel，禅道、Tapd、数据库、其他自研用例维护网站、市场主流的用例设计工具还是Xmind与Excel

Xmind-思维导图，通常用于逻辑性较强的事件梳理，或者带有明确时间线的事件整合，随着测试行业的变化，使用者逐渐增多，其修改便捷、备注灵活、可视化信息明确的特点，使其备受青睐

Excel-微软电子表格，曾经测试用例设计工具的鼻祖，N年前的曾经与N年后的今天，绝大多数的测试行业从业者仍然在使用Excel进行用例设计，Excel对于数据分析更加灵活，维护更加便捷，用例设计更加清晰明确、严谨。

选择的工具有很多，笔者这里不逐一进行介绍，建议大家使用Xmind或Excel进行用例设计，没有所谓的最好，只有适合自己的工具~，笔者个人是使用Xmind进行用例设计的，但如果要设计一份真正优秀的测试用例，必定是选择Excel…毫无疑问…

用例设计评判规范

在日常的功能测试工作中会经常接触到测试用例设计，那么你是如何进行用例设计的呢？又是如何进行测试用例评审的呢？以下是笔者个人的评判标准，仅供参考哦（仅代表黑盒测试）：

1、用例设计的系统性：业务需求梳理清晰，系统与系统、玩法之间的关系明确，列举出系统集成与数据牵连

2、用例设计的全面性：设计内容覆盖全面、考虑周全，能够深入分析需求并解析为独立的测试用例

3、用例设计的结构性：用例设计从上至下，从简单到复杂，设计结构清晰明确

4、用例设计的可执行性：用例从上至下，用例具有顺序性，部分用例进行整合，便捷统一执行

5、用例设计的可阅读性：用例语句通顺，无错别字、错误语句，阅读性高，易理解，清晰明了

6、用例设计的可维护性：用例设计有维护信息，编写作者，最新修改时间等，用例维护更加便捷高效

7、符合项目规范的数据：使用的测试数据由用例设计者提供且符合项目规范中所使用的标准测试数据构造

8、用例设计的游戏观念：用例设计的检查提及到了关于游戏观、价值观，相关可能影响的法律法规、社会人文等

用例设计格式组成

用例设计的格式是在用例设计中非常重要的一个环节，通常而言，一份优秀的测试用例至少包括的标签头为：

1、用例序号：序号通常为特定格式，即 项目名称+模块名称+用例序号，例如WZRY_ZC_001 ，则代表王者荣耀项目，注册模块，编号为001的测试用例

2、所属模块：直接填写对应模块即可，代表该编号的用例是所属于某个模块的测试用例

3、用例标题：说明该用例的执行目的，检查内容

4、前置条件：执行用例所需的前置条件，即执行前的准备工作

5、用例步骤：用例的可执行操作步骤

6、预期结果：预期执行用例步骤后所产生的结果

7、实际结果：执行用例后的最终结果

8、备注信息：通常会写明一些测试方法、注意事项、测试数据等

用例设计的注意事项

一份用例中有很多值得注意的事项，往往很多测试人员在用例设计时会出现的常见问题：

1、问题一：用例设计标题不清晰，执行者不能通过标题判断编写者的目的，不清楚该用例的设计目的，没有头绪，例如描述有误，过长的标题反而增加阅读难度等

2、问题二：用例的操作步骤不可执行，按照测试用例的执行步骤执行，发现该用例是无法执行的，只列举了测试点，他人无法通过测试点进行执行

3、问题三：用例没有备注信息，部分需要测试数据、特定方法执行的测试用例无备注信息，执行者在执行该用例时不清楚执行方式与方法陷入困境

4、问题四：用例子模块划分不明确，用例的标题和子模块划分不明确，格式不清晰，执行者很难执行

5、问题五：用例不具有顺序性，用例的顺序性差，能够一起执行的用例分开进行了编写，导致执行一次后反反复复进入同一个模块和界面再次执行另外一个测试用例，耗费时间

最后:【可能给予你助力的视频教程】

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….