卷麻了，00后测试用例写的比我还好，简直无地自容...........

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

 如何编写测试用例？

作为一个测试新人，刚开始接触测试，对于怎么写测试用例很是头疼，无法接触需求，只能站在用户角度去做测试，但是这样情况会导致不能全方位测试APP......

如何写出高效的软件测试用例？

从事软件测试大半年，基本上都是靠着对软件产品的大致了解来进行测试工作，很难对产品 进行一个全面细致的测试。现在想学习一下怎么写测试方案和测试用例，有哪些相关书籍可以参考？

固然，编写一份好的测试用例需要：充分的需求分析能力 + 理论及经验加持。 但这并不意味着，没测试经验、分析能力弱就不能写好用例，还是有方法可循的。作为混迹测试职场 9 年的老人，给大家分享一些用例编写的心得，接下来我会从以下几个方面展开来讲：

1. 测试用例概念、作用、内容等介绍
2. 如何编写测试用例？
3. 微信发送朋友圈案例分享

​​ 一、测试用例介绍

测试用例是为项目需求而编制的一组包含测试输入、执行条件以及预期结果的文档，以便测试某个程序是否满足客户需求。

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

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

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

​

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

3、测试用例编写形式

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

二、如何编写测试用例

大体思路分为三步：

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

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

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

举例： 微信朋友圈动态发送

​

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

简而言之，就是把你能看得到的功能及功能点梳理出来。公司一般都有产品需求资料，例如需求规格说明书文档、原型图、UI 设计图；当没有任何需求资料情况下，可以通过操作软件来熟悉业务。像发送朋友圈，我们可以先功能模块—> 再子功能—> 再到功能需求细节来梳理，注意一些不明确的需求细节需要及时跟产品确认。大致梳理如下：

​

​

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

这一步非常重要，依据需求梳理完功能点后，接下来我们需要针对每个功能点拆分整理具体的测试点，这时候我们需要设想用户操作的所有情况，包含到正常及异常场景。

我们需要同时具备测试理论方法和测试经验，才能较好地设计出一份全面可靠的测试用例。常见的测试用例设计方法包括：等价类划分、边界值分析、判定表、因果图、错误推测法、场景法、正交试验法、状态迁移法等。测试经验需要多个项目测试的积累及沉淀。对于测试新人来说，测试经验可能趋于 0，这个时候可以先借鉴一些前人的经验。对于此，我曾经整理过一份资料，很多测试新人用过资料后都觉得对测试用例有了豁然开朗的感觉，知道怎么去写用例了。

这份资料分享如下：

​

​

注：这份资料我们可以用在任何的软件产品的分析上面，从本质上来说，任何一款基于用户角度操作的软件产品，操作功能无外乎都是对数据做增删改查，所以当需要对软件产品进行分析编写测试用例时，我们可以依据当前功能是增删改查的哪一个操作，用上面梳理的测试点来套用编写用例。按增删改查操作来梳理，分为：

1. 表单测试：涉及到数据提交的页面，包含新增或删改数据页面
2. 搜索测试：为数据查询的页面
3. 删除测试：为数据删除的页面
4. cookies、session 等测试：用户操作角度，补充测试
5. 数据库测试：页面添加、修改、删除、查询业务相关操作，就是对数据库数据的增改删查

通过测试理论方法和测试经验，我们可以得出微信朋友圈的测试点：

​

编写为 Excel 文档用例，可为：

​

728 x 291 1254 x 502

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

除了以上这些功能层面的，对于微信移动端产品，还需要考虑到一些特性方面的测试，包括非功能测试层面，如：

​

三、总结

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

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

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群：1150305204，里面有各种测试开发资料和技术可以一起交流哦。

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