下面是关于接口需求文档-接口测试
做测试的同仁们都有过这种体会，企业要实施接口测试，按正常规范路子走都是基于开发编写的接口需求文档实施接口自动化测试，但也也有些公司因研发流程不规范没有编写接口文档，或者接口文档未能基于项目及时更新，这时候要实施接口测试应该如何入手呢？
第一，如果没有接口文档大概可以基于产品或者项目功能测试业务逻辑进行分析，然后用抓包工具将每个接口抓取下来，整理到接口测试用例文档当，也是就自动编写了一份接口文档。
通过项目实践抓包比接口文档中的接口更靠谱，但是它有个缺点就是实施接口自动化测试的时间较长。
因为遇到不懂的业务逻辑你需要分析需求或者与后端开发人员沟通来获取业务的相关加密解密的数据。
例如：现大部分网站登录都采用了加密或者解密的相关算法，常见的加密方法有sha256、rsa、Md5等相关的加密算法。
没有接口自动化实施经验的同学在这块容易碰壁，有过接口自动化实施经验的同学就懂得如何与开发商沟通获取相关的接口加密信息，甚至有些测试人员能够说服开发帮测试编写接口加密或者解密程序来测试接口的完整性。
你必须得会一款接口抓包工具，现在市场上接口抓包工具非常多，例如：浏览器自带的F12、Fiddler、JMeter、Fiddler、Charles、HttpWatch等都能满足业务需求。
第三，实施接口测试前最好结合具体工作目标分析哪些业务较稳定再开展工作，不然接口代码写完后，复用性范围有限，需要更很多时间来维护脚本。
第四，最好公司有接口测试平台，所有的数据都能在平台实施工作，一般大型公司都有自己的接口测试平台，接口测试适用范围主要用在冒烟测试阶段，可以帮助大家自动跑冒烟流程，这也是一种提升工作效率的好方法。
综上所述，要想实施接口自动化的方法有很多，但前提是你必须得具备一定的接口测试基础与业务需求分析的能力，结合现有产品理清业务逻辑，借助接口测试工具就能完成相关的接口自动化测试实施，当然代码能力强的同学也可以使用Python自己编写接口测试框架。
一、什么是接口
百科上对接口的定义：API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。两个独立的系统，它们的数据或程序是独立的，这就使得它们无法直接访问对方的数据库或程序（两个独立的数据相当于两个独立的家庭，每个家庭肯定是不允许外人随便进入的，否则会发生偷窃等后果严重的事件）。但是某些业务场景下，独立的系统之间又必须相互共享数据或共用一套程序逻辑，如统一业务流程上的不同业务操作系统，下游系统的业务依赖于上游系统的数据。既然如此为什么不把它们设计成一个系统，这样不就没有上面的问题了吗？这是因为有的业务流程很长很复杂，如果设计成一个系统，整个系统变得很庞杂，不论是功能设计、开发维护都很难。因此一般都会把虽然有上下游业务关系但又有清晰边界的业务划分成独立的系统实现，如采购系统和仓储系统。此外，很多时候我们需要获取的数据是我们外部其他公司拥有的数据，更不可能设计成同一个系统了。基于以上两点：接口就是两个独立系统之间同步数据或访问对方程序的途径。二、如何设计接口
1. 搞清楚是主动访问还是被动请求：
一是我方是数据的使用方，需要主动从对方获取数据；二是我方是数据的提供方，需要主动将数据同步给对方。主动访问时无需做接口，而是访问对方的接口，要搞清楚的问题是：我们需要在什么节点访问对方的接口？是用户触发某个操作的时候实时去访问？还是没有实时性要求，只是周期性地访问？若我方是数据的使用方且需要的数据是用户使用某个功能必须的数据，因此必须在用户操作时实时去访问对方的接口获取数据并展示给用户，典型的有我们注册某网站时获取验证码的功能。若我方是数据的使用方且需要的数据是一些跟用户实时操作无关的基础数据，如客服系统需要从其他业务系统获取用户的基础数据，以在系统中的某些功能下展示用户的信息（如客服在处理客诉等问题时，需要知道客户的一些详细信息，这些信息只有业务系统有）。这种情况下，一般会新增一个脚本定时（如两小时一次）访问对方的接口将数据获取过来存储到自己的数据库，在用到的时候直接从自己数据库获取并展示。若我方是数据的提供方且提供的数据是下游系统需要的实时要求高的数据则更多地用实时同步；若是基础数据，则选择周期性同步的方式。一是我方是数据提供方，需要对方来获取数据；二是我方是数据使用方，需要对方主动将数据同步过来。被动请求需要提供接口供对方访问，此时要搞清楚：让对方来访问的时候，需要提供什么样的参数？根据他提供的参数我们需要返回什么数据？这些数据从哪里取值？若有一些数据的来源是本系统，其他系统需要使用这些数据，则可提供接口让其他系统通过访问接口获取这些数据。若我方是数据使用方且让对方将数据主动同步过来，此种场景典型如——我们是业务的下游，上游系统产生数据后，需要将数据同步到下游系统让流程继续进行，并且流程的及时性要求高，不能有延迟。这种情况下，只有上游系统知道什么节点产生了数据，因此只有等他产生数据后主动推送给下游系统，因为下游系统因无法知道数据生成的时间，也就无法及时去获取数据，这时最好的方式是让对方主动将数据同步过来。2. 搞清楚数据交互的实时性要求
a. 对于我方是数据使用方的情况，要根据业务的需要决定获取数据的实时性。如上文所说，如果是用户使用功能时需要的数据就是即时性访问。如果是定期获取基础数据，根据我们对数据准确性的要求和对方数据变更的频率决定获取的周期。如我们对数据的准确性要求不是100%的要求，且对方的数据变更频率也不是很高，则周期可设计得长一些，如每天一次，每几个小时一次等。b. 对于我方是数据提供方的情况，则以对方的业务需要为准，但是对于获取数据的访问量大等特殊情况，应在需求中或评审中做好说明和交代，以帮助开发设计更满足需要的接口。3. 选择合适的接口方式
结合接口的不同类型和实时性要求两方面，可以选择合适的接口实现方式：是一个中间件，数据提供方将数据放到中间件，数据获取方从中间件中获取数据。针对向多个系统同步基础数据的需要，消息队列是最适合的方式。若选择这种同步方式，要注意的一点是：增量同步还是全量同步，若是增量同步，对方是增量获取还是全量获取？若是全量同步，在什么情况下，对方应该更新数据，什么情况下应该更新数据？数据同步方直接访问数据获取方的数据表将数据写入对应的表中，这种方式实时性最高，若对数据的准确性要求很高，此方式是很好的数据同步方式。一般在功能设计中常用的接口是此种方式，双方通过http地址保持数据同步和通信。在设计具体的数据同步接口时，具体的方式产品经理不用关注，由开发根据需求设计合理的方式，然后产品可帮助开发一起确定所选方式是否满足业务需要。除非业务上有特殊要求，则在需求中可指定具体的方式。三、如何编写接口文档
不同的接口使用场景，需要关注的点和交代清楚的规则不一样，以主动/被动+数据使用方/数据获取方的维度，有以下四种情况：1. 如果是向对方系统主动推送数据，则可按以下方式整理接口需求
2. 如果是对方主动来获取数据，则可按以下方式整理接口需求
3. 如果是被动接收对方推送的数据，则可按以下方式整理接口需求
4. 如果主动从对方获取数据，则可按以下方式整理接口需求
以上就是小编为大家整理的接口需求文档-接口测试
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
评论列表
收藏起来，接口需求文档确实需要有一个编写规范统一起来，这样才能真正发挥作用