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

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

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

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

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

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

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

3、测试用例编写形式

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

如何编写测试用例

大体思路分为三步：

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

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

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

总结

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

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

1.目的

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

2.范围

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

3.术语解释

集成测试：

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

系统测试：

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

4.测试用例原则

系统性

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

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

连贯性

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

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

全面性

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

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

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

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

正确性

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

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

符合正常业务惯例

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

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

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

仿真性

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

可操作性

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

鉴于篇幅所限，无法一一为大家展示这份超级实用的测试用例编写规范，有需要的小伙伴可以关注

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

 

​这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！