就按上面写

截取一段：

测试奇谭：什么是介面测试？这篇文章让你明白?

zhuanlan.zhihu.com图标

但是做介面测试，你还得考虑其他场景：

01 入参出参

你是否发现我上面贴图中的一个细节？

插头请求时，说了一句"我需要美标"，插孔回应"我是美标介面"。

像不像打仗的暗号——「土豆土豆，呼叫红薯」，「我是红薯，土豆请讲」。

因此，你需要这样设计你的用例，

步骤：A用户（未注册），假扮自己是已注册用户（修改入参），请求注销介面。期望：失败，给出合理提示
————————
步骤：A用户（已注册），请求注销介面，系统告诉A注销失败（修改出参）。期望：给出合理提示

02 介面安全

即，不能像上一个场景，随意让用户修改入参请求，要保障业务和系统的安全、保障数据的正确。

一般来说，使用https请求+验签机制（验证码、sign、时间戳、Token等），可以规避这个问题。

步骤：拿乱写的入参请求注册介面。 期望：失败，给出合理提示
————————
步骤：拿乱写的入参请求注销介面。 期望：失败，给出合理提示

03 请求超时场景

即，请求介面，一直没有拿到介面的结果。

步骤：网路不好的情况，A用户（未注册），请求注册介面。期望：超时，给出合理提示
————————
步骤：网路不好的情况，A用户（已注册），请求注销介面。 期望：超时，给出合理提示

04 后端服务异常场景

即，介面后面的服务无法正常使用。

步骤：资料库无法使用的情况，A用户（未注册），请求注册介面。期望：失败，给出合理提示
————————
步骤：资料库无法使用的情况，A用户（已注册），请求注销介面。 期望：失败，给出合理提示

05 并发场景

类似于性能测试。

步骤：多个用户（未注册），同时请求注册介面。期望：都能成功
————————
步骤：多个用户（已注册），同时请求注销介面。 期望：都能成功

上面的内容，我只是做了一个引子，引导你去考虑这些场景。当然，实际工作中要考虑的，远不止这一些，还有分散式场景下的非同步、同步任务问题，幂等问题，介面兼容问题，降级问题等等。

太多了……

但是，你也别害怕，这些场景是根据你实际工作情况来的。

比如，分散式场景下的同步、非同步等，在金融领域使用较多，需要对此精通的介面测试工程师，如果你不在这个行业，了解它即可，没必要深究。

问同事要个模板，让他给你讲一下业务，一下就懂

谢邀，测试用例可以用来衡量一个项目的测试质量，测试工程师需要熟练掌握测试用例的编写技巧，尽可能覆盖任何异常的测试点。主要功能模块测试的测试用例设计方法包括：等价类划分、边界值分析、错误推测法、因果图和判定表、场景法、正交实验法，这些方法的具体应用请参考下文：

行者AI：功能测试用例设计方法分享?

zhuanlan.zhihu.com图标编辑于 01-20继续浏览内容知乎发现更大的世界打开Chrome继续测试小盒测试小盒一个喜欢动漫的小测试

入职后可以和同事要个模板，或者直接参考同事写过的测试用例样式，内容的话，你需要先看下公司业务和你负责的模块需求，然后通过你学习到的一些设计测试用例的方法，然后开始编写测试用例的方法。我最近在做总结，关于用例的设计方法在我的文章中有写了一些，可以做下参考。

入职后可以和同事要个模板，或者直接参考同事写过的测试用例样式，内容的话，你需要先看下公司业务和你负责的模块需求，然后通过你学习到的一些设计测试用例的方法，然后开始编写测试用例的方法。我最近在做总结，关于用例的设计方法在我的文章中有写了一些，可以做下参考。

功能测试用例编写方法业界有以下几类：等价类、边界值、错误推断、因果图、判定表等。可以百度搜索一下，网上挺多案例的。刚开始可以依葫芦画瓢，带著方法从模仿开始。

介面测试用例编写重点在介面返回的断言设置（即期望值和实际值的比对），一般返回从以下几个点考虑：

1、返回码断言（必要要求、基本）

2、返回内容断言，断言返回业务重点代表栏位key （期望要求，最好）

3、所查即所增，如果是一个新增介面，最好从资料库把数据查询出来就行断言。这样能准确的的判断出资料库的处理是ok的避免介面返回处理正常实际数据落库有问题的情况（推荐要求，更好）

最后说下，不管是功能测试用例还是介面测试用例，都免不了一个测试用例的基本结构。一个完整的用例结构包括：前置条件，测试步骤，期望结果和后置步骤。希望在写用例的时候，保证结构完整，并应用各种用例设计方法，写出简洁高效高质量的用例！

实在是用语言不知道该怎么描述，不过这张图可以看看

推荐阅读：
相关文章