一、背景

有些测试同学，写测试用例的时候，直接就是将需求文档上的内容抄一遍，转换成测试用例的格式。没有加入任何自己的思考和理解，没有融入任何测试方法论。测试完全依赖于需求文档的质量，依赖于产品经理保姆级的服务。需求写得细，测试用例覆盖就全面，需求写得粗，就有很多地方都没有测试用例覆盖。

让他针对一个功能设计测试用例，总是习惯性的回答：根据PRD来写呗，PRD怎么说我就怎么写，慢慢地将自己变成只会复制、粘贴的工具人。在他们眼里，做测试和进厂打螺丝没有任何区别。最后上线出bug了，就转过头来攻击PRD写的怎么那么粗糙，完全不会思考自己的用例是否有问题。

二、测试用例的作用

1、理清测试细节，提高测试覆盖率，避免漏测；
2、通过详细的用例设计反推是否有需求漏洞，提前发现需求细节问题；
3、提前准备测试数据，便于测试过程高效执行；
4、测试过程中用于判断测试进度，预知测试风险；
5、测试用例是测试的重要资产，便于测试内容回溯、测试工作交接；

看懂了以上测试用例的作用，请不要再将测试用例像垃圾一样用完随手丢弃，而是要好好写，好好存。

三、你真的会写测试用例吗？

传统的测试用例编写，会采用Excel的方式编写，用例中包含的内容大致如下：
测试模块、用例编号、用例标题、用例类型、用例等级、是否可自动化、预置条件、步骤描述、预期结果、备注。
Excel的方式适用于系统逻辑简单、清晰的需求。

如果系统需求较为复杂，需要测试人员做复杂的测试数据设计、做较多的联动场景测试时，推荐用Xmind的方式编写测试用例，通过脑图的方式，相比纯文字更有利于测试人员梳理测试逻辑。此外Xmind梳理测试点的方式也更适应如今互联网高效的模式，Excel编写维护起来会比较臃肿耗时，可读性方面也比xmind差。

测试类型：从从功能测试、UI测试、异常测试、场景化测试、功能性并发测试、兼容性测试、易用性测试、性能测试、安全测试、回归测试等多个维度去编写测试用例，用例才能有比较高的覆盖率，不容易漏测一些特殊场
景。
测试范围：如果需求是涉及多个终端（比如：App、小程序、PC端都涉及），或者需求是多方一起合作测试，最好单独拉一个模块写清楚：测试范围，提前划分好测试边界，确保信息对齐，各方的理解一致。
冒烟测试：抽出主流程冒烟测试用例，方便需求进测时先测试冒烟是否通过，并且冒烟用例也可以提供给研发自测使用。
用例分级：P1级用例、P2级用例、P3级用例，做好用例分级。测试过程中做好标记：测试通过、测试失败，便于统计进度。需要添加备注描述的，做好用例执行备注。
用例评审：比较重要的一个环节，需要拉齐测试leader、研发、产品一起评审，确认用例的正确性和完整性，排除因信息误差、理解偏差等导致错误的用例、用例覆盖率不全等问题。和研发约定好，开发需自测保证冒烟测试用例通过，才能达到提测标准。

用例平台：如果公司有专门的用例平台来管理整体的用例，也没关系，目前市面上常用的用例管理平台，或者公司自研的用例管理平台，基本都是支持Excel或者Xmind导入的。用例平台最好能支持将项目-需求-用例能关联起来存储，便于后续管理和回溯。也可以打通bug管理平台，建立用例和bug的关联关系。
关注即可免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！

一、用例设计1

1、接口测试概念

接口测试：测试系统间接口的一种测试，测试的对象主要是接口，主要是测试外部系统与所测系统之间以及内部系统之间的交互点

2、接口测试方法

a、可以通过开发脚本代码进行测试
b、可以通过开源免费的接口调用调试工具测试，如：Postman等。
c、可以通过App手动测试，结合抓包工具分析，如：Fillder/Charles等

3、接口测试范围

接口范围包括：
一、被测项目中同层之间的接口（如DAO层、Service层），一个接口调用了其他的接口。
二、外部系统与系统之间的交互点（如一个App调用了第三方支付宝的API）
三、各个子系统之间的交互点（如App客户端调用了服务端的Http接口）

被测接口范围：
通常接口会很多，接口测试范围的筛选，参考测试人力资源、项目特点、接口重要性与优先级来进行。其中第一种属内部接口，构造测试稍复杂需开发配合实施，通常优先覆盖第二、三种接口
接口测试的重点测试范围：
优先测试覆盖核心业务，复杂业务的接口

4、如何设计接口测试用例

接口测试出发点是被测接口逻辑存在错误，参考这个为出发点，更容易发现问题
设计接口测试用例，我们可简单的考虑两个基本要素，即：入参、出参，正确/错误的入参，逻辑判断后，接口是否做出正确的处理，返回正确的出参

接口测试用例有3类（逻辑测试，异常测试，路径测试）：
1）逻辑测试：主要是根据开发提供的接口文档来设计测试用例，接口文档包含的要素（前提条件，输入参数，参数类型，业务逻辑，返回输出描述等），此类主要测试在正常输入的情况下，是否能得出正确的输出结果。主要使用的用例设计方法是等价类划分，边界值等

2）异常测试：接口逻辑的测试中主要测试接口正常逻辑，即对外提供的接口服务是基本可用的，但仅逻辑测试不能保证数据的安全及程序接口在异常情况下的逻辑处理的正确性
(a) 空值,null;
(b) 参数属性(如：未赋值的参数)
(c) 异常业务参数(如：构造不满足业务异常业务参数)
(d) 参数个数、参数类型错误(如：接口文档中定义必填参数2个int,输入参数仅1个,类型非int)
3）路径测试：当被测接口的实现方法中，判断逻辑复杂分支多，且判断中又调用了其他的接口，此时必须要进行路径覆盖测试

5、接口测试关注点

6、接口自动化测试工具
1）Java(HttpClient) + Junit/TestNG;
2）Jmeter
3）SoapUI
4）Python requests/urllib 库;
......

二、用例设计2

1、优先级--针对所有接口

1.暴露在外面的接口，因为通常该接口会给第三方调用
2.供系统内部调用的核心功能接口
3.供系统内部调用非核心功能接口

2、优先级--针对单个接口

1.正向用例优先测试,逆向用例次之(通常情况，非绝对)
2.是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制

3、设计分析

通常，设计接口测试用例需要考虑以下几个方面：

1.是否满足前提条件
有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token；
逆向用例：针对是否满足前置条件(假设为n个条件)，设计0~n条用例

2.是否携带默认值参数
正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例

3.业务规则、功能需求
这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例

4.参数是否必填
逆向用例：针对每个必填参数，都设计1条参数值为空的逆向用例

5.参数之间是否存在关联
有些参数彼此之间存在相互制约的关系；
逆向用例：根据实际情况，可能需要设计0~n条用例

6.参数数据类型限制
逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例

7.参数数据类型自身的数据范围值限制
正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例；针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例

资源分享

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

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