Jmeter接口测试：快速编写可行脚本几个建议【欢迎讨论补充】

提高编写接口测试脚本的几个关键字：

0.拆分    1. 模板    2. 规律     3. 复用【ctrl+c， ctrl+v】

项目背景：

        一个版本增加100个接口，如何在一周内完成测试并发布？  场景很简单，时间起来实际上很困难。

T0：将困难的问题，拆分成小问题

        工作中一个困难的问题，是由很多小问题缠绕在一起导致的。想要解决问题，就需要知道我们面临的到底是哪些问题。

        增加100个接口：可以分解成以下几个小问题：

问题1：接口类型多【Get、Post、Patch、Delete】、

问题2：接口涉及业务多【场景1、场景2、场景3】、

问题3：接口操作流程不一【起始（无承前步骤），中间（有承前步骤，有结尾步骤），结尾（只有承前步骤）】

很多朋友在分析问题的时候，比较喜欢用一个非常概括性的词汇，比如“工作量大”。这种问题分析实际上是没有定位到问题的根本，对自己而言难以想出解决方案，对上级而言，这种概括性的结论也会导致上层出现判断失误。当然，也有很小一部分人为了个人想法而夸大工作的难度，不过我相信肯看这篇文章的朋友肯定不会这么想。

        继续分析另外一个因素：在一周内完成测试并发布：

问题1：需要多少资源【多少人？人的素质？完成截止日期：周五or周日】

问题2：测试完成度【全部？只完成重点？】

问题3：开发配合情况【准时提测？快速关闭bug？】

        想要做到分析到位，需要有已经完成同类工作的经验，根据这些经验设想完成工作的场景，所能面临的问题，分析到某个场景的时候，感觉设想不了或者不清晰，就明确下。细心的朋友应该会发现，两个分析方面，都分析了3个问题，在这3个问题的基础上还有更细的划分。个人起了个好记的名字，3点式分析法，只分析一个方面太笼统，分析太多方面没重点，一个问题拆分成3个问题，如果分析的依然不到位，就在不到位的点再进行一次3点式分析。这种分析方式，可以发现问题产生的原因，掌握规律，知道了规律，问题也就解决了一半了。

T1：简单的事情，模板化

        测试接口，基本上每天都和脚本打交道。实际上每个版本都在将相似的测试内容转化为脚本最终执行，渐渐的，总结了一套适用于已知工作场景的公共脚本。这样在写新的脚本时，不需要关注接口部分应该测哪些内容，降低漏测风险的同时，将更多精力集中在如何覆盖全面的场景以及优化脚本的执行效率，覆盖范围。

        测试模板基于Jmeter，数据库使用的是Postgre。

        脚本分为3个部分：1. 测试计划    2. 基础配置   3. 测试思路

1. 测试计划

        测试计划，用于描述脚本测试目的，测试范围，编写人，引入jar包等内容

1. 测试名称及说明：描述接口测试的目的，项目开始时间，结束时间，开发负责人，测试负责人，测试过程中的重要问题等，有记录价值的内容都需要记录在案

2. 项目基础信息配置：所有接口都需要使用到的数据，维护在此处。当然也可以在每个线程里单独加用户自定义配置，书写在这主要是为了提高维护效率

3. 运行配置：修改为勾选：Run Thread Groups consecutively。配置项影响的是查看结果树显示内容，配置完了会先执行完一个线程内的所有脚本，再指向下一个脚本。

4. 引入jar包：需要扩展功能的时候，引入jar包。目前涉及到引入的只有数据库驱动。其他数据库的驱动，请自行想办法下载，postgres可直接在官网下载：https://jdbc.postgresql.org/download.html   

2. 基础配置

        基础配置主要配置http头部信息、数据库配置、结果树、HTTP请求默认值

1. http头部信息，配置访问必须携带的消息。每个项目要求可能不同，不确定要用什么，可以和开发确认

2. 数据库配置：

Database URL：jdbc:postgresql://172.18.11.25:8875/DB_CC?characterEncoding#UTF-8

其中ip，端口，初始数据库，请分别修改“172.18.11.25”、“8875”、“DB_CC”

JDBC Driver class：如果是postgres，请选择：org.postgresql.Driver   。如果是使用的其他数据库，需要调整为对应数据库。

Username、Password，对应账号密码

3. 查看结果树，放在配置配置里，方便使用

4. Http请求默认值：配置请求的ip、端口、url等信息，如果所有接口使用的一致，可以实现一次配置，终身保修的好处

3. 测试思路

        根据脚本测试的测试思路，共分为了5个模块：

1. 基础功能：只填写必填项，验证接口能够运行，用于做冒烟测试

2. 字段必填项验证：不填写一个必填项，验证接口能够校验

3. 字段内容验证：填写所有必填项的基础上，每次填写一个非必填项，验证非必填项的入库等操作

4. 字段边界值验证：对设置了边界值的字段，做最大长度，最大长度+1的数据，验证超长字段无法入库有提示

5. 全量字段验证：包含所有字段的，验证数据入库。

        这部分内容比较复杂，与本文主题无关，感兴趣之后另行整理~

总结：

        这套模板包含了一个接口测试所需要的所有内容，每个项目都可以使用，只需要根据项目的测试内容，酌情的删减测试范围即可。目前笔者已知的内容，就这么多，还有其他建议，可以评论回复~一起讨论共同进步

篇幅问题，先整理这么多，规律和复用之后介绍。

当然，如果能做到上面的这两点，拆分问题以及用例模板，已经能够大大的提高脚本编写效率了。