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

前言
作为一个测试新人，刚开始接触测试，对于怎么写测试用例很头疼，无法接触需求，只能根据站在用户的角度去做测试，但是这样情况会导致不能全方位的测试APP，这种情况就需要一份测试用例了，但是不会写，求指教！还有就是测试出来的bug该如何追踪？与开发的接触基本上面对面的交流，没有很好的一个规范

带着问题学习是最高效的学习方法。

目录

一.什么是测试用例

二.为什么要写测试用例

三.如何编写测试用例

带着问题学习是最高效的学习方法。

因此，在介绍如何编写测试用例之前，先看一个软件系统登录功能的测试（如下截图所示）：

要做这个登录页面的测试用例，你会从哪些方面思考进行测试呢？

看似简单的页面功能能够设计多少条测试用例完成较全面的测试呢？10条以内？20条？.......

 那么在给出上述答案之前，先带大家熟悉一下 什么是测试用例？测试用例有什么作用？ 然后在结合上述抛出的案例抛砖引玉一起讨论 如何编写测试用例？

 下面就是此文目录截图：

 一、什么是测试用例

测试用例：为了特定的目的（证明软件存在某问题）而设计的一组由测试输入、执行条件、预期结果构成的文档

1、测试用例简单来说就是指导如何做测试的文档，该文档主要记录需要验证被测软件的是否满足需求

2、测试用例表现形式常见的有两种，可以以模板形式展示

1）一种是通过Excel直接编写

——大多数项目中都需要按照这种方式设计编写

2）一种是通过xmind直接整理测试点

——时间紧迫，项目没有强制要求时，可以设计测试点的形式编写
——对于业务流程类的测试，也可以整理为测试点进行测试

3、设计及执行人员：测试工程师

4、用例的模板：描述编写用例核心内容，一般项目都有自己的设计用例的模板，常见测试用例模板可参照如下：

 二.为什么要写测试用例

为什么要写测试用例，实际中产品出现问题，第一责任人首先想到的是测试为啥没有测到？

 产品出现问题了，你为啥没有测出来呢？

 

当然，除了避免“甩锅和背锅”，其实写测试用例更重要的作用如下：

• 技术上将需求转化为具体可验证的指标
• 以文档的形式记录软件可能存在的问题
• 防止测试过程的活动出现遗漏，提高工作效率
• 测试工作量的展示

三.如何编写测试用例

既然写测试用例如此重要，那么如何更好的编写测试用例呢？个人认为需要满足如下几点：
- 常规思考，设身处地的从用户角度出发（比如：实际用户是这么使用的么，会不会遇到异常情况呢？）
- 测试理论方法的支撑（比如：根据需求设计测试用例时，能用到哪些常见的测试用例设计方法？）
- 产品的熟悉和经验的积累（比如：已经有过类型项目经验，曾经在某个方面有过问题，当时是如何处理的呢？）
 
上述的设计用例过程，有个前提，就是对于测试有耐心和毅力，加上日常有意识的思维训练，才会写出全面的用例。

1、常规思考

回归到开篇的问题，对于一个基本的登录页面，按照常规思路能否会想到如下截图的测试点呢？实际，这些测试点都是源于从用户角度出发，结合需求进行细化设计的过程。实际测试中是不是只有这些测试点呢？

 

2、学习积累

相信大多数测试工程师都能够想到上述基本的测试点，然在实际工作中面对的项目不同，设计测试用例的颗粒度也有不同的要求，如果针对上述登录的模块，更深入一层考虑呢？此时需要对产品的熟悉程度及测试经验的加持，而且这些点的设计是不断学习、熟悉项目、测试积累中得到的。

 

3、理论支撑

有了常规的思考，有了经验的积累，还需要理论的支撑。测试用例毕竟是通过人去思考设计，这个过程不可避免有疏漏。如何规避？实际就需要测试理论的支撑，个人认为深入思考设计用例不外乎以下两方面：

1）测试用例的设计方法

测试理论中很关键一块就是将需求拆分为具体的测试点，然后根据用例设计方法进行具体的设计，其中拆分需求的关键是熟悉需求，将文档中已有的描述内容，按照用户使用场景、个人测试经验的积累（如果有的话）、把大段的内容拆分成能够直接用用例设计方法的测试点，这样就直接可以通过简明扼要的文字描述转化为Excel的测试用例，在这个过程通俗理解就是拆分细化的过程，直到可以直接写用例验证一个具体的功能点即可。
 

其中熟知的设计用例方法有：

- 观察法

- 等价类、边界值

- 判定表、因果图

- 流程图、场景法

- 错误推测法

---

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！【保证100%免费】