做功能测试要接口测试吗（先接口测试还是功能测试）

本篇文章给大家谈谈做功能测试要接口测试吗，以及先接口测试还是功能测试对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享做功能测试要接口测试吗的知识，其中也会对先接口测试还是功能测试进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、在软件测试中，我已经熟练了业务功能测试，还需要学习接口测试吗？
• 2、从功能测试到接口测试，原来的技能可以通用
• 3、什么是接口测试？为什么要做接口测试

在软件测试中，我已经熟练了业务功能测试，还需要学习接口测试吗？

很高兴回答你的问题。

先说结论做功能测试要接口测试吗，是否要学习接口测试，做功能测试要接口测试吗我觉得是需要的。

首先来说，单纯的功能测试是很好做的，基本上就是对着软件点来点去，但如果仅是如此的话，那薪资是最低的。除非你比较满足于当前薪资水平，否则还是多学习点吧。然后，可能不但要学习接口自动化测试，最好是学习性能测试。一般人很少有机会接触性能测试，所以性能测试的薪资很高，但同样的性能测试要掌握的东西也是特别多的。另外，当前很流行的测试开发，也就是说测试也要会开发，这种是当前比较吃香的，但同样的要想做测试开发，其实还需要学习编程语言。不过学好了，10几，20k也没什么问题，我周围这样的同事大有人在的。

最后，我的建议就是能多学点就多学点，毕竟大家肯定都是想高薪的么，但想高薪，就要多付出。

从功能测试到接口测试，原来的技能可以通用

一、什么是接口业务 安全测试

业务安全测试是根据业务需求，针对业务安全规则展开的系统 功能测试 。业务安全测试作为该系统功能测试的重要组成部分，在 接口测试 过程中同样适用。区别于系统 漏洞 扫描、 SQL 注入防范等 技术 安全测试，针对接口展开的业务安全测试更加关注程序逻辑本身对于保障业务规则安全所进行的检查、校验、控制等功能方面的测试，例如银行业务中针对客户信息有效性、账户信息一致性的检查等等。

二、为什么要做接口业务安全测试

顾名思义，业务安全测试的目的自然是为了防范业务风险，提高接口的业务安全性。之所以针对接口测试再次强调业务安全测试，就不得不提到一个众所周知的“零信任原则”。

所谓零信任原则就是后端系统对于前端提供的请求报文保持不信任。简单讲就是作为后台服务方，时刻保持一种“总有前台想要害朕”的“迫害妄想症”，认为前端送过来的报文都是不靠谱的。

当然并不是说前端的系统真的不靠谱，很多系统前台都针对业务规则展开了细致的检查、控制，这也是我们在进行系统功能测试过程中最常设计的测试场景。那么我们为什么还要在接口测试中针对业务安全再展开一次测试呢？那是因为前后端系统调用过程中，特别是对客服务系统前后端交互过程中涉及报文拼装、传输等环节，很可能被别有用心的“坏人”利用，对报文进行篡改，从而产生业务风险。在一些交易场景中后端系统又很难辨别接收到的报文是否被篡改，因此需要对输入信息进行必要的检查校验，以提高业务安全性——当然可以通过各种技术手段对报文进行防篡改控制，这是技术安全层面的内容，这里不再展开。

在业务安全测试过程中，我们经常提到的就是“越权访问”。

举个例子，一个用户登录系统之后查询自己的账户信息，这是一个正常流程。如果这个过程中，用户通过篡改报文将自己的账号更换为其他人的账号，从而获得了其他人的账户信息，这就是越权访问中的“水平越权”。即用户利用系统缺陷访问了其他相同权限用户的私有数据。

与之相伴的还有“垂直越权”，即用户通过身份冒充等方法获取了诸如管理员权限等高于自身级别访问能力得越权。

三、怎么做接口业务安全测试

1.需求分析

既然是业务安全测试，“业务” 需求分析 是必不可少的。同系统功能测试一样，针对接口的业务安全测试也要我们根据业务需求提炼业务规则、梳理权限要求、设计测试场景。但由于接口的抽象性，我们还需要另一个十分重要的资料来帮助我们设计测试案例，那就是接口设计文档。

接口设计文档，一般应包括以下几部分内容：

·接口功能简介

对接口基本功能的简单介绍。

·输入输出参数说明

这部分内容包括了接口参数的字段类型、长度、取值范围等信息，是我们使用边界值等方法设计案例的重要信息来源。

同时还有一个接口设计原则需要我们重点关注，即“最小必需”原则。这里的最小必需原则可以从两方面去理解。一方面，就接口的输入来说，就是尽量少的从前端特别是依靠用户录入的方法获取输入信息。这一点是同前面提到的“零信任”迫害妄想症一脉相承的——录入的东西不靠谱，能通过后端系统从 数据库 里获取的就不要前台录入。另一方面，接口的输出在满足需求的情况下尽量减少冗余信息，从而避免不必要的信息暴露。是否满足最小必需原则也是我们在进行接口业务安全测试的时候需要关注的。

· 接口功能规则描述

这里应该描述了接口的主要功能、业务规则等，是我们设计场景案例的重点参考。

·错误信息描述

在进行接口业务安全测试时，为验证各种业务规则和权限控制，反向案例会占据很大比例。因此报错信息的描述是我们应该十分关注并需要在测试过程中同开发持续交流的内容。毕竟我们怎么知道案例预期结果里我们想要的报错信息就是我们想要的呢？哈哈。

2.案例设计

总结上面的描述，接口业务安全测试案例的设计可以从以下几方面着手：

·验证正向功能是否符合预期。

·边界值、等价类等方法对于接口参数的边界值、异常值进行测试，验证接口的容错能力。

·根据业务规则设计相应的反向案例，检查接口是否具备对应有效的控制逻辑。

·设计越权案例，检查身份校验、权限控制相关检查是否完备。

3.测试工具

针对接口测试，当下有Postman、 Jmeter 、Selenium等一众报文及 自动化测试 工具可供选择，可以根据需要和习惯选取。

四、谁来做接口业务安全测试

接口业务安全测试应该由谁来执行呢？让我们从两个方面来看这个问题：

接口消费方 vs 接口服务方

作为调用接口的消费方，应该对接口提出明确的功能需求，就像业务人员向开发人员提出系统功能需求一样。因此消费方在测试过程中更关注接口功能是否满足需要。

作为提供接口的服务方，提供的接口不光要满足服务方的功能需求，还应在输入合法性、业务规则、权限控制、身份认证等方面进行相应校验，提高接口的业务安全性。

因此从系统层面来看，接口业务安全测试应该是由服务方来完成的。

测试 vs 开发

在一个项目流程中，提到接口测试，往往联想到模块逻辑层面的调度调试，想到 单元测试 ，是开发者的工作。然而，我们这里谈到的接口业务安全测试，是站在业务规则的视角针对接口展开的功能测试。接口业务安全测试同单元测试的区别就如同系统功能测试和集成测试的区别一样，测试和开发的关注点是不同的。因此接口业务安全测试和接口单元测试是不能相互替代的。

另一方面，为提高接口业务安全质量，在接口设计上也需要开发多动些脑筋。比如接口的“最小必需”原则，就应该在接口设计阶段予以考虑，并同测试保持沟通。如果等到交付测试才思考这个问题，往往木已成舟，修改难度较大了。

当前，随着软件系统架构、技术的不断升级优化，对于 系统测试 环节的要求也越来越高，系统功能测试、系统 性能测试 、技术安全测试、业务安全测试、接口测试等等划分愈发精细，不断考验着我们测试人员的能力与智慧。

什么是接口测试？为什么要做接口测试

对于接口测试来说，项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的，并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。
接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码，所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。
输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长；
功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。
逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常； 异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。

关于做功能测试要接口测试吗和先接口测试还是功能测试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 做功能测试要接口测试吗的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于先接口测试还是功能测试、做功能测试要接口测试吗的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。