接口测试

此文章作为工作中用到的jmeter接口测试相关内容简述，方便日后查阅参考，如有理解描述有误之处，欢迎指出。 首先Jmeter环境准备网上有很多教程，在此不多做赘述； 1.接口简述 接口可理解为从客户端到服务器的通道，客户端发送请求到服务器是通过接口实现的； 2.抓包 在无接口文档或文档描述清晰度不够，验证请求入参及相应信息时，web端可直接在浏览器使用F12查看network信息；需勾选Presever log选项；抓取页面所有的HTTP、HTTPS的请求；pc客户端或app可借助Charles、fiddle等相关抓包工具获取相应信息； 3.接口测试实例 以登录为例，输入用户名、密码，完成登录，跳转首页 测试过程中有些数据经常发生变化，如登录后需要验证状态sessionID或token，测试时就需通过关联（第二个请求需要的参数需要从第一个请求返回数据中获取）继续后续测试，不同用户或不同时间相应值也不同，也涉及 1⃣️jmeter测试计划中（以汉化版讲解）创建线程组 PS：线程组中可以创建多个请求 2⃣️线程组右键->添加->Sampler->HTTP请求（登录页） 。配置相应登录页面信息，域名或IP、端口号、协议（HTTP、HTTPS）、方法（get、post等）、路径，添加参数名及相应值（账号、密码） PS：配置密码参数时，需按照实际项目需要，数值配置明文或秘文

　　一个完整的开发流程应该有这四步：分析->设计->编码->测试。很多开发团队往往只有编码这边，弱化了其他步骤，他们拿到需求就开始写代码， 写着写着发现有问题，要么是遇到一个难点解决不了，要么是发现要返回修改以前写过的代码， 要么是发现有大量的重复代码，又不知道怎么封装，只能将错就错。做好了分析和设计编码时就不会有这么多问题， 做好了测试产品bug就少，产品质量才高。 下面我分别详细讲解一下这四步。 分析 　　分析的时候，我们要分析需求和难点。 　　分析需求的方法是做需求陈述处理，前面我提到过， 要区分做什么和怎么做，把这两部分独立出来，做什么是固定不变的， 而怎么做可能会经常变。我们再熟悉一下举的那个例子：我们要做一个成员列表（如图1-44），产品经理告诉我们要按姓名拼音排序。 图1-44 成员列表的例子 　　我们有时候不能直接听产品经理的，如果真写死成按姓名拼音排序就没有可扩展性了，比如某一天产品经理又告诉你需要把VIP会员提前，那么你只能再去修改排序的程序。这个需求始终不变的是排序，按姓名拼音只是排序的一种方法，我们在设计数据库时应该把排序字段设置为数字而不是拼音，再写一个拼音转换为数字的算法即可，这样在后面排序规则变化，比如VIP会员要提前，只是修改对应用户数据库的排序字段数值即可，不用大改程序。 　　我们可以用xmind做需求分析，

一、集成测试概念 集成测试也叫组装测试、联合测试、子系统测试或部件测试，是在单元测试的基础上，将所有函数按照概要设计要求组装成为子系统或系统所进行的测试；它和单元测试所关注的范围是不同的，因此，它们在发现问题的集合上包含有不相交的区域，不能使用集成测试来替代单元测试，反之亦然。 二、集成测试关注点 1.模块间的接口 把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 全局数据结构是否有问题，会不会被异常修改； 2.集成后的功能 各个子功能组合起来，能否达到预期要求的父功能； 一个模块的功能是否会对另一个模块的功能产生不利的影响； 单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。 三、集成测试的层次 四、集成测试策略的主要模式 现有一个模块包含以下几个函数，将以此为例讲解每种模块的运作方式： 1.大爆炸集成方式 *** 这种方式中，首先对每个模块分别进行单元测试，然后再把所有单元组装在一起进行测试，最终得到要求的软件系统，如图所示： 缺点： a.这种一次性组装方式试图在辅助模块的协助下，在模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大； b.在发现错误的时候，其问题定位和修改都比较困难； c.即使被测系统能够被一次性集成

购物商城接口测试案例 1、接口说明： 调用商品到购物车接口 2、请求方式： HTTP POST请求 3. 接口地址： /ecshop/upload/flow.php?step=add_to_cart 4. 请求参数： 1) 输入参数： JSON数据格式： 2) 请求示例： POST /ecshop/upload/flow.php?step=add_to_cart HTTP/1.1 Host: 192.168.126.134 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Accept: text/html,application/xhtml+xml,application/xml;q=0. 9, / ;q=0.8 Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Referer: http://192.168.126.134/ecshop/upload/goods.php?id=1 Content-Length: 69

开发过程中，写出的接口方法需要测试。为了测试这些方法，需要从Spring环境中拿到这些接口方法所属的类的实例对象。所以需要编写SpringBoot的测试方法。下面以测试mybatis-plus接口为例编写测试方法，项目名：SpringbootFeatures. 1、pom文件 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.2.2.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 测试相关 --> <dependency> <groupId>org.springframework.boot<

目录导航 一.测试用例编写规范 1、测试用例编写目的 2、适用范围 3、测试用例 4、用例设计方法 5、测试用例设计的原则 6、用例设计步骤 二.测试规范 1、接口功能测试：用来保证接口功能的正确性 2、局部数据结构测试（不常用）：用来保证接口中的数据结构是正确的 3、边界条件测试 4、代码覆盖率 5、各条错误处理测试：保证每一个异常都经过测试 三.实施方案 1、idea安装junit插件 2、添加pom依赖： 3、命名 4、几种常用的注解（导org.junit.jupiter包） 5、断言 6、参数化测试 7、MockMvc使用(模拟controller请求接收) 8、几个方法的简单说明： 9、增加app服务的验证签名之后的junit修改 四.验收方法 五.CI流程中需要增加的项目 1、pom依赖 2、profile 3、测试代码中profile的使用 4、测试数据的规范 六.集成方案 1、安装JDK 2、安装Jenkins 3、配置Jenkins 4、新建测试项目 一.测试用例编写规范 1、测试用例编写目的 （1）为用例的质量负责，使用例编写工作能够有序、合理； （2）统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性； （3）能有效的提高系统所有功能点的覆盖率。 2、适用范围 适用于人员：用于测试人员阅读和执行

前言： 　　本文主要针对http接口进行测试，使用Jmeter工具实现。 　　Jmter工具设计之初是用于做性能测试的，它在实现对各种接口的调用方面已经做的比较成熟，因此，本次直接使用Jmeter工具来完成对Http接口的测试。 一、开发接口测试案例的整体方案： 第一步：我们要分析出测试需求，并拿到开发提供的接口说明文档； 第二步：从接口说明文档中整理出接口测试案例，里面要包括详细的入参和出参数据以及明确的格式和检查点。 第三步：和开发一起对接口测试案例进行评审。 第四步：结合开发库，准备接口测试案例中的入参数据和出参数据，并整理成csv格式的文件。 第五步：结合接口测试案例文档和csv格式的数据文档，做接口测试案例的自动化案例开发。 二、接口自动化适用场景： 目前设计的自动化接口测试案例有两个运行场景： 　　1. 测试前置、开发自测：一个新的自动化接口测试案例开发完成后，直接发给接口对应的开发，安排在开发本地环境执行，一旦开发确认完成接口开发，就开始执行接口测试案例，基本上可以实时拿到测试结果，方便开发快速做出判断。【开发本地运行的方式就是打开JMeter工具，导入JMX文件，开始执行可。】 　　2. 回归测试：开发本地测试通过后，或整个需求手工测试通过后，把自动化的接口测试案例做分类整理，挑选出需要纳入到回归测试中的案例，在持续集成环境重新准备测试数据

Jmter工具设计之初是用于做性能测试的，它在实现对各种接口的调用方面已经做的比较成熟，因此，本次直接使用Jmeter工具来完成对Http接口的测试。 一、开发接口测试案例的整体方案： 第一步：我们要分析出测试需求，并拿到开发提供的接口说明文档； 第二步：从接口说明文档中整理出接口测试案例，里面要包括详细的入参和出参数据以及明确的格式和检查点。 第三步：和开发一起对接口测试案例进行评审。 第四步：结合开发库，准备接口测试案例中的入参数据和出参数据，并整理成csv格式的文件。 第五步：结合接口测试案例文档和csv格式的数据文档，做接口测试案例的自动化案例开发。 二、接口自动化适用场景： 目前设计的自动化接口测试案例有两个运行场景： 　　1. 测试前置、开发自测：一个新的自动化接口测试案例开发完成后，直接发给接口对应的开发，安排在开发本地环境执行，一旦开发确认完成接口开发，就开始执行接口测试案例，基本上可以实时拿到测试结果，方便开发快速做出判断。【开发本地运行的方式就是打开JMeter工具，导入JMX文件，开始执行可。】 　　2. 回归测试：开发本地测试通过后，或整个需求手工测试通过后，把自动化的接口测试案例做分类整理，挑选出需要纳入到回归测试中的案例，在持续集成环境重新准备测试数据，并把案例纳入到持续集成的job中来，这些用于回归的接口测试案例需要配置到持续集成平台自动运行。 三

对于web接口测试来说有哪些测试要点： 　　1、请求是否正确，默认请求成功是200，如果请求错误也能返回404、500等。 　　2、检查返回数据的正确性与格式；json是一种非常创建的格式。 　　3、接口的安全性，一般web都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。 　　4、接口的性能，web接口同样注重性能，这直接影响用户的使用体验。如果我搜索一个关键字半天结果都没返回，果断弃用。 接口测试的用例设计出了要验证正常功能之外，还需要考虑其他的一些情况，总结起来，接口测试的用例设计可以从以下几个方面入手： 1. 功能用例设计 服务端的接口与客户端的功能是对应的，那么这个接口是否能提供给客户端某个特定功能所需要的数据自然是我们需要验证的地方，功能性用例的主要目的是帮助我们验证该接口最初设计的功能是否被实现以及该功能是否按照规定的接口文档进行实现等等。 2. 业务逻辑用例设计 业务逻辑方面的测试用例主要是针对服务端接口的处理逻辑进行的用例设计，这种用例设计不是针对某个功能点是否实现，而是对接口的处理逻辑以及一些相互依赖的业务进行验证，通常依照接口的逻辑流程图来进行。举一个例子，购物系统中的两个动作：登录和下单操作，这两个业务是相互依赖的，下单操作必须在登录完成后（登录状态下），否则无法完成下单，这个时候我们就可以设计这样一条 case：没有登录的状态下进行下单操作

1.现有的单元 测试 框架 单元测试是保证程序正确性的一种有效的测试手段，对于不同的开发语言，通常都能找到相应的单元框架。 借助于这些单测框架的帮助，能够使得我们编写单元测试用例的过程变得便捷而优雅。框架帮我们提供了case的管理，执行，断言集，运行参数，全局事件工作，所有的这些使得我们只需关注：于对于特定的输入，被测对象的返回是否正常。 那么，这些xUnit系列的单元测试框架是如何做到这些的了？分析这些框架，发现所有的单元测试框架都是基于以下的一种体系结构设计的。 如上图所示，单测框架中通常包括TestRunner, Test, TestResult, TestCase, TestSuite, TestFixture六个组件。 TestRuner：负责驱动单元测试用例的执行，汇报测试执行的结果，从而简化测试 TestFixture：以测试套件的形式提供setUp()和tearDown()方法，保证两个test case之间的执行是相互独立，互不影响的。 TestResult：这个组件用于收集每个test case的执行结果 Test：作为TestSuite和TestCase的父类暴露run()方法为TestRunner调用 TestCase：暴露给用户的一个类，用户通过继承TestCase，编写自己的测试用例逻辑 TestSuite：提供suite功能管理testCase