精华内容
下载资源
问答
  • 1.简介 在这篇文章里,我们来学习一下接口测试用例设计,主要是来学习...这里不再赘述,想详细了解的可以看一下Python的接口自动化用例设计。宏哥在这里,换一个角度来说接口测试的用例设计,首先我们看一下接口...

    1.简介

      在这篇文章里,我们来学习一下接口测试用例设计,主要是来学习一些用例设计要点。其实说白了,接口用例设计和功能用例设计差不多,照猫画虎即可。不要把它想象的多么高大上,多么的难,其实一样,以前怎么设计,现在就怎么设计,和黑盒测试设计测试用例半斤八两。这里不再赘述,想详细了解的可以看一下Python的接口自动化用例设计。宏哥在这里,换一个角度来说接口测试的用例设计,首先我们看一下接口测试的范围。

    2.接口测试范围

    2.1功能测试:验证产品逻辑是否正确

      功能测试是我们接口测试时候相当重要的一部分,接口的功能都没实现,后边的异常、性能就更加谈不上了。其实接口测试和在web页面、或者移动端操作那些按钮、输入框是一样的。按钮将绑定的参数通过接口传过去,而输入框是将你输入的参数通过接口传过去。接口测试是在产品还没有开发好按钮和输入框,你手动写参数通过工具或者其他方法传过去,验证是否可以得到期望的。

      下边的这八种接口功能测试的8种方法和web页面的测试用例的设计方法一模一样的,这个都是测试的基础知识,不知道的自己可以单独查询一下各种方法的概念及其的用法。

    5ecd4ef2b974d219691166543b7eb833.png

    2.2异常测试

    1cf2a8a6e343d9235029df7c3bbfe945.png

    null : 是开发过程中特定指的一个对象为空的端符,就是一个空对象,不指向任何内存地址

    " " : 指一个空字符串,代表该对象有值,指向一个空地址

    数据类型:例如我们有个年龄的字段要求传的是ini类型的值,我们给它传的是字符串。这就是数据类型异常。8中基本数据类型,我们传一个不符合规定的数据类型。

    负载均衡架构:测试某一个后台(Tomcat 4)挂了,挂了之后 Tomcat4的请求会直接返回一个错误(前台1个nginx ,后台多个 Tomcat),测试是否会返回这个错误,能否会使用户访问失败;一段时间后,想让 Tomcat4 重新加入,判断能否重新加入集群中并正确处理所有请求。

    冷热备份:冷备份不常见,热备份:前面有4个Tomca,后面有4个Tomca备份,如果Tomca4挂了,判断Tomca4的备份能否顶替之前的,仍然保持4个服务器存活;当Tomca4 正常后,判断能够成为Tomca4的备份。

    1.3性能测试(狭义)

    a29d82afd24b33d203cd667369325c80.png

    负载测试:我发了好多请求,看看能不能正常发出去,再看看服务器端能不能正常处理这些发过来的请求。

    稳定性测试:比如我跑服务跑了好长时间,比如24h、一周等,看看能不能将程序压垮等等。

    3.自动化接口测试范围

    a8cf766e707980462a49e68b3f74c1e2.png

      为什么在这里没有涉及到前边接口测试的环境异常和功能测试。在这里宏哥做了细分,这部分主要是有其他的测试负责的,比如:环境异常测试,一般需要我们协调和运维配合。需要他们把环境部署成和线上一样的架构,以及硬件、内存等等。由于各个公司的资源和重视不一样,但是最差了也得是等比例缩小的一个初始化的模型。这样做的接口测试才有意义。性能测试也可以自动化测试,这个也有专门的测试,当然了,你也可以进行一些简单的测试,如果你是全栈测试,那么这三部分你都精通那最好了。这里宏哥主要介绍的围绕的功能测试和数据异常测试。

    4.自动化接口测试用例设计

      这里宏哥通过具体实例说明一下。自动化接口测试原则:你能够把你设计的接口测试用例映射成一张表。因为映射成一张表你才可以更好的方便的操作,并且可以自动加载它。

    4.1接口自动化用例设计示例:登录

    环境异常测试时需要运维小伙伴配合测试的,此暂时不做描述
    以常见的登录界面为例

    输入:用户名:邮箱或者手机号码
    输入:密码:6-16位的长度,区分大小写,不能用空格

    首先,我们先要知道接口测试用例的规则,与功能测试用例不同,不需要描述测试步骤。我们需要描述id(序号)、目标URL、username、password、协议状态码(可写可不写)、程序状态码(开发返回成功的状态码)、返回内容(例如success)、实际结果、执行状态(自定义,例如0:失败。1:成功)。根据如上内容,可以把这个整理成一个表中,如上字段作为表头。按照正常数据和异常数据维护成Excel就可以。

    218a6105f50d616aad2a3ab15163d8ca.png

    数据异常:null、“”、特殊符号(&、*)

    PS:红色框圈住的针对执行SQL时数据截断的情况。

    select username,password from user where username = """ 中间的单引号将会截断,抛出异常。

    设计用例表头时,将中文转换成英文,方便程序做映射时处理,同时也方便写入代码中。

    5.环境异常测试

      前边虽然说需要协调运维的小伙伴配合测试环境异常,但是在这里你可以提前考虑一下,什么事情都要向到前边,未雨绸缪。不要等出事了临时抱佛脚。

    5.1简单web架构集群

    c3279ce285c403ef728155d77755e3f4.png

      上图是一个简单的web部署架构。接口测试主要是前台传递参数,后台接口参数并处理返回期望的结果。简单的描述一下上边的架构:用户通过web页面发送请求到nginx,nginx接收到请求不作任何处理,将请求分发到后台的tomcat1、tomcat2、tomcat3服务器上。服务器处理请求后,将结果返回到web页面,用户看到结果。

    这里分发是有规律的,不是一同乱分发,那样还不得有的服务器先得没事干,有的服务器累死了,分发原则:根据userid来进行区分。

    例如:取余,当余数为0时,分发到1,当余数为1时,分发到2,到余数为2时,分发到3。

    环境异常条件:tomcat2服务器挂掉了,专业点就是宕机了。假如此时有9个用户,他们的userid分别是:1,2,3,4,5,6,7,8,9。此时恰好是1用户把tomcat2给玩挂了。

    5.2环境异常测试示例:

    2b25a57427cef9953f9f61d8abb2636a.png

       结合上图:宏哥来描述一下,这个环境异常的场景,根据这个场景设计的测试用例。用户1将服务器tomcat2玩挂机了,恰好此时用户1又发出请求,所以此时用户1的请求期望结果只能发送到tomcat1或者tomcat3上。服务器挂机以后运维团队收到告警,快速修复tomcat2服务器(例如重启),当下一次用户4发送请求的时候,由于tomcat2正常所以预期结果还是正常环境了分发到tomcat2上。这里我们主要是观察一下tomcat2是否可以正常加入到集群中。这些策略可以提前和运维的小伙伴定好了进行测试。

     5.3如何确定分发到那台服务器

      方法:通过日志查看有没有分发到,例如:用户1分发2上,即使访问成功但是没有日志,那么这就是一个bug,和我们之前定好的均衡策略有冲突。其他的都类似。

    6.小结

       好了,以上就是今天分享的知识,宏哥这里只是做了简单的讲解。希望大家喜欢。

      宏哥一分钟,姿势涨不停  - 本期完 -欢迎分享朋友圈~4295a96561b3a4ec09e773565678b3fe.png我是北京宏哥很高兴认识你们

                                                                            ~看完点个“在看”,养成好的习惯

    展开全文
  • 测试技术的应用不仅限于功能测试、自动化测试、性能测试、可用性(用户体验)测试随着测试左移与右移的发展,还引入了数据分析(用户行为)、线上质量运营等方向,相信还会衍生出更多的方向,比如正在逐步发展壮大的算法...

    题外:新年Flag

    f1a8d7a1b62480bb7a42f1936adaa29d.png

    大年初一,立个Flag。19年希望能够持续关注测试及相关行业的发展,不断加深对测试的理解,专注于测试技术在测试左移与测试右移的应用与创新。

    测试技术的应用不仅限于功能测试、自动化测试、性能测试、可用性(用户体验)测试随着测试左移与右移的发展,还引入了数据分析(用户行为)、线上质量运营等方向,相信还会衍生出更多的方向,比如正在逐步发展壮大的算法测试。

    自动化测试的认知

    一些错误的认知:

    1. 使用自动化完全替代手工测试。
    2. 使用自动化测试发现更多的新BUG。

    应该形成怎样的认知:

    1. 自动化测试的目的不单纯是为了减少或者替代手工测试,而是为了测试人员能够做更多更有意义的测试,比如更深入的需求分析、测试设计或者对测试右移的投入;减少或抽调人力投入;适应开发模式的转变,比如类敏捷、devops模式下的频繁迭代、持续部署。
    2. 自动化测试是用来验证以前能够正常工作的功能是否依旧可以正常工作。

    为何自动化测试

    1b1423c049bb3b8feb8a4ddf0b8e0a50.png

    要清楚不是为了自动化而自动化,是为了实现一套解决方案来解决某些问题而开展某种自动化 ,肯定是解决某些测试过程中的问题而引入自动化测试。既然选择自动化解决某些问题,首先要清楚自动化测试的利与弊,如下:

    1. 关于成本,机器资源成本代替人力成本,一定程度解决了重复性的测试执行成本问题。
    2. 关于效率,提高测试执行效率,缩短测试周期,一定程度解决了测试周期随版本迭代次数的增加(功能点增加)而增长的问题。
    3. 关于测试覆盖,通过自动化测试工具的录制回放及数据驱动来测试功能,可以提高测试覆盖率,一定程度解决了回归测试中测试覆盖率低的问题。
    4. 关于发现问题,自动化测试具有较好的一致性和可重复性, 一定程度解决了手工反复执行过程中的一致性的问题。
    5. 关于流程,自动化测试工具作为一种角色引入到整个测试流程中,提高测试执行流畅性。

    1. 关于人员,额外要求测试人员具备定测试开发能力,引入了对测试人员能力要求较高的问题。
    2. 关于成本,自动化测试开发成本因选择自动化框架(或工具)而异,但都具有较高的开发成本,引入了开发成本的问题。
    3. 关于维护, 随着版本迭代和功能变更,引入了自动化代码的开发维护的问题。
    4. 关于发现问题,受其本身的局限性(大多应用在回归测试、稳定版本场景中), 自动化测试发现问题较少。

    工欲善其事必先利其器

    IT行业甚至其它行业的产品都是能够做到自动化的,所以是否自动化不是能与不能的问题,而是是否存在合适的时间或阶段以及合适方式去做的问题,实施自动化测试之前需要对产品开发过程进行分析,同时自动化测试是一把双刃剑, 所以通常自动化的开展需要同时满足以下条件:

    • 软件需求变动不频繁(超过10%的变动是频繁变动,当然10%不是一个定值)
    • 项目周期足够长
    • 自动化测试用例可重复使用

    通常适合于软件测试自动化开展的场景如下:

    • 回归测试,重复单一的测试操作造成了不必要的浪费

    上文中也提到肯定是解决某些测试过程中的问题而引入自动化测试,如果是为了自动化而自动化,无疑它将是失败的。

    何为自动化测试

    28997ff5919103dbbd9dc457698c0bc7.png

    自动化测试是把以人为驱动的测试行为转化为机器执行代码的一种过程。

    通常,在设计测试用例并完成评审之后 ,由测试人员根据测试用例一步步执行侧试,得到实际结果与期望结果的比较。

    在此过程中,为了降低人力、时间或硬件资源的投入,提高测试执行效率,便引入了自动化测试的概念。

    飞机还是大炮

    框架、工具的选择是我们确认开展自动化后首先面临的问题。之前网上有个梗,泡面煮着吃是没有灵魂的,当然这是一种调侃。自动化测试开展一定要结合被测系统的特点进行选择,不顾被测系统(系统框架)特性、场景而盲目选择自动化测试框架(或工具), 它是没有灵魂的,自动化失败概率会相对高很多。

    下面我们先简单的介绍一下自动化开展的几种自动化测试驱动框架。

    首先我们需要明白自动化测试框架更倾向于一种设计思想 ,这种思想指导工具的使用或者自研开发,并且不是只能使用仅仅一种框架,结合被测系统本身特性一般是选择多种测试框架的组合,来满足测试和设计需求(开发、维护角度)。


    录制回放测试框架

    录制回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。

    • 优点:对测试人员测试开发能力要求最低,通过录制就可以得到所需脚本。
    • 缺点:一般不具有逻辑判断的能力 ,可维护性差 ,效率低。
    • 适应场景:不推荐,传统的UI自动化测试逐步弱化。关于U自动化,一定要清楚 被测系统是否满足开展自动化的条件,在被测系统变动频繁的项目中,开展UI自动化无疑是挖了一个很大的坑,其后期维护工作足以让大心疲惫,被迫放弃自动化测试。

    测试库构架框架

    测试库构架框架的核心思想可以概括为系统功能操作和业务逻辑的解耦。将所有的针对测试系统支持的功能操作封装在测试库中,测试脚本调用测试库的同时传递外部的测试数据,测试库的编写由自动化测试发工程编写(可以不懂业务),负责控件的变更和维护, 测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写,负责业务逻辑、测试数据的变更和维护。

    • 优点:被测试系统无论是哪层发生变化(代码层或业务层等),只需要相应的人员进行变更维护即可。
    • 缺点:变更引起的维护工作同时附加在自动化测试开发工程师与业务测试人员身上,维护代码建级大。
    • 适应场景:基于各种自动化开展方式(基于工具如Jemet或不基于工具的自研研发+持续集成)一般都会应用该框架。

    数据驱动的自动化测试框架

    数据驱动的核心思想可以概括为数据(测试数据、配置数据)与代码解耦。该种框架的原理是采用了数据驱动脚本进行测试,数据驱动脚本是将数据输入存储在独立的数据文件中,脚本只存代码,运行时脚本的输入直接从文件中读取,如此相同的脚本(代码模版)可以运行于不同的测试用例中,实现了代码与数据的分离。

    • 优点:对于业务人员由面向代码的开发转换为面向配置的设计(参数组合设计), 降低了开发难度与开发成本,同时提高了测试用例的易扩展性,可以快速扩展相似测试,实现了自动化代码不随用例的增长而增
    • 缺点:测试脚本的维护由自动化测试开发工程师负责,要求懂自动化编程和业务逻辑,初始测试脚本设计成本较大,具有一定局限性 (针对相同的测试内容并具有相同的测试逻辑).
    • 适用场景:更适应于测试内容测试逻相重复度高,被测对象对测试用例易扩展性、可复用性要求较高的场景。

    关键字驱动的自动化测试框架

    关键字驱动是对数据驱动的逻相扩展,它的核心思想可以概括为数据代码流程(逻辑)解耦,同时完成了代码与测试描述(针对被测对象的测试描述)的映射。该框架的原理是基于数据驱动的基础上,完成了对被测对象的拆分、抽象、 封装使之映射成一个“关键词” (测试描述),编写测试用例时,仅需要对关键词进行组合 ,即可完成不同场景的测试用例开发。

    • 优点:对于业务手工测试人员,由面向代码或配置的开发转化为面向自然语言(测试描述)的开发,最大程度的降低了开发难度与维护成本,同时提高了测试用例的易扩展性、易组织性,实现了自动化代码不随用例的增长而增多。
    • 缺点:对测试人员的测试开发能力以及业务了解程度要求很高。
    • 适用场景:被测对象包含复杂业务流程(逻辑),当然复杂的能做简单的更ok。

    仅仅从实现上讲,很多种自动化测试框架(或工具)都可以开展自动化,或者说任意一种也不是很勉强, 所以在自动化框架(或工具)的选择上,不是人为核心的(我会什么, 或有哪种框架比较好掌握),而是以被测对象为本来选择自动化框架(或工具)。

    以目标为导向

    a63ca7678c91f5d5a24e9d2218501fd3.png

    着重考虑自动化覆盖率、效率提升率、投资回报率(ROI)、效率转换等指标,按季度或产品版本为周期,进行持续性的评估,以便感知落地后的自动化测试是否持续性的发挥着原定作用,通常我们会收集一下数据并依据此设定不同等级进行评定,以便区分优劣,具体如下:

    • 自动化覆盖率 = 当前版本该项目自动化测试点/当前版本该项目所有测试点。
    • 效率提升率 = 1- 单轮次自动化执行时间/单轮次手动执行时间(针对被自动化测试所覆盖的用例而言)
    • 标准盈余时间 = (单轮次手工执行时间-单轮次自动化执行时间)*自动化执行次数
    • 实际盈余时间 = 结合标准盈余时间估算
    • 投资回报率(ROI) = (标准盈余时间/自动化测试开发投入时间)*100%
    • 效率转换 = 对实际盈余时间的分配及相关产出

    自动化测试前移

    106f802f5178125c4a76acc10aa8a686.png

    随着敏捷、devops等开发模式的引入,软件交付周期逐渐缩短,相对传统的自动化测试准入原则,已不能满足现有的发展要求,比如“版本功能相对稳定后开展自动化测试”。此时,我们提出了自动化测试前移的设想,基于这个设想我们首先要解决哪些问题?

    1. 开发成本,由于自动化前移,会影响前期对测试设计、分析的时间投入。
    2. 维护成本,由于自动化前移,由于接口或设计调整而引入的自动化用例变更维护的可能性更大。

    因此自动化测试前移是否具备可行性,取决于开发成本和维护成本的是否在可以缩减到一定范围内,这同样也涉及到自动化测试的可持续性问题。

    自动化测试策略

    依托合适的自动化测试框架,进行自动化测试设计来解决。这里我们主要基于关键字驱动的自动化测试框架进行自动化测试设计,其中有几个设计细节可以借鉴一下,比如:

    将接口自动化测试分解为请求响应关键字、响应体特定内容提取关键字、数据校验关键字等几个模块:

    • 其中请求响应关键字支持http、https协议的多种请求方式,同时支持JSON、xml等响应体的校验(如,接口响应体为JSON类型时,针对特定Key进行校验或跳过特定Key进行校验),请求响应关键字的参数包含,URL、请求方式、请求体、期望结果,此时通过该关键字可以实现所有类似接口的自动化测试;
    • 特定内容提取关键字支持特定内容的提取,以便在集成接口自动化测试场景下,提取上游接口响应体特定内容,作为下游接口参数输入;
    • 数据库校验关键字支持多种类型数据库的增删改查,以及查询结果与期望结果比对等功能;
    • 基于关键字驱动的自动化测试框架一定程度解决了随着用例数量的增加维护代码量也越来越多的问题。

    如何实现不输入期望的自动化测试用例开发模式?,

    • 比如针对幂等性接口,我们在初次运行的时候,重复调用接口10次,然后区分响应体不发生变化的内容和发生变化的内容,再根据不发生变化的内容自动生成期望,回填到用例中,这样大大就提高了自动化的开发效率。

    除此之外,关键字驱动的自动化测试,还解决了测试人员与测试开发人员的解耦问题,即测试人员负责用例设计,对产品质量负责。测试开发人员负责框架和关键字维护,对测试效率负责。

    940ec328542ca2ff9509f8f64dfc0f25.png
    展开全文
  • 接口测试分为分为单接口测试和多接口业务串联测试接口测试本质是测试接口传入正确的或错误的参数,服务端的处理逻辑是否正确。1. 其中单接口测试分为业务等价类测试、参数规则边界测试和安全测试三个维度:(1)...

    接口测试分为分为单接口测试和多接口业务串联测试,接口测试本质是测试接口传入正确的或错误的参数,服务端的处理逻辑是否正确。

    1. 其中单接口测试分为业务等价类测试、参数规则边界测试和安全测试三个维度:

    (1)业务等价类测试。业务等价类分为单接口的有效等价类和单接口的无效等价类。例如登录接口,在用户名和密码输入合法的前提下,有效等价类是“正确的用户名 + 正确的密码”这一组合,无效等价类包括“正确的用户名 + 错误的密码”、“错误的用户名 + 错误的密码”、“错误的用户名 + 正确的密码”等组合。需要注意的是,我们不仅要找出所有的“有效等价类”(有效等价类毕竟是最常见的业务流程,往往不会忘记),也要找出所有的“无效等价类”。

    (2)参数规则边界测试。参数规则边界测试是对接口请求体参数、字段,基于需求的边界值做限制。例如登录的用户名和密码中,字符类型和字符长度限制。在不多数互联网公司,这类限制大多由前端处理。但严格来讲,不仅前端要处理参数、字段的边界,服务端也是需要在接口层级做参数、字段边界的校验的。因为服务端的校验才是最可靠的;此外,基于前后端的C/S架构、B/S架构,如果在服务端做了参数规则校验,那么新开发的各个客户端,就算没有处理对应逻辑,也是不会出现错误数据的,而客户端处理的话,就需要对各个类型的客户端限制参数字段的边界。

    (3)安全测试。为防止任何人随意调用接口,我们会给接口加上鉴权限制,这就需要测试接口的安全性。比如接口header里加token和不加token,加cookie和不加cookie等。

    2. 多接口业务串联测试

    接口之间是有业务关联的,例如订单创建后,订单支付接口应该可以拿最新的订单号支付成功;而订单支付成功后,订单详情接口应该要能拿到最新的订单支付状态,即依赖于订单支付接口的数据,都能够获取到正确的数据。

    在单接口测试通过的基础上,再去测试多接口业务串联测试。单接口测试通过,代表单个接口的代码处理没有问题,这时候把业务相关联的接口串联起来,测试通过就代表业务流程没有问题。

    测试工具我们选择Jmeter、Postman等都可以。

    在做好接口测试后,我们可以对单接口进行封装,实现接口自动化测试(推荐在产品需求第一次开发时,就可以写接口测试的脚本,接口测试通过后,单接口测试的脚本可以直接集成到接口自动化脚本中,非常高效方便)。接口自动化测试方法、框架有很多,如果代码基础比较薄弱,推荐的方法是采用Jmeter + Ant + Jenkins + Git + 邮件服务器的方式来实现。该方法的优点是:

    1. 对代码要求不高,非常有利于开发基础不强的测试团队;2. 测试数据、测试用例通过Json文件来管理,且可以和测试脚本一起可以实现分布式管理、多端开发接口测试脚本;3. Jenkins 定时发送测试报告,并基于日志定位问题。

    如果有Python基础,采用Python + Request + Jenkins + Git + 邮件服务器来做接口自动化,也会很灵活。

    展开全文
  • 涉及接口自动化测试,文章旨在帮助小公司想开展自己独立的接口自动化测试环境,主要从接口自动化测试是什么,接口自动化测试适应哪些公司哪些项目,接口自动化环境怎么搭建以及怎么进行接口自动化测试展开,最终达到...
    211a4aefa8a7e53682dfa9a1b000352f.gif

    摘要

    本文主要依据之前测试经验,涉及接口自动化测试,文章旨在帮助小公司想开展自己独立的接口自动化测试环境,主要从接口自动化测试是什么,接口自动化测试适应哪些公司哪些项目,接口自动化环境怎么搭建以及怎么进行接口自动化测试展开,最终达到帮助测试人员写成一条接口自动化测试用例的目的。

      测试按照不同的测试标准有不同的测试划分:

    • 按照测试阶段,可以划分为:单元测试,集成测试,系统测试,验收测试;

    • 按照测试升入层次,可以划分为:黑盒测试,白盒测试,灰盒测试;

    • 按照测试对象,可以划分为:性能测试,安全测试,兼容性测试,文档测试,易用性测试(用户体验测试),业务测试,界面测试,安装测试;

    • 按照测试方法,可以划分为:自动化测试,功能测试;

      不知道大家目前在做什么类型的测试工作呢? 可能大部分测试人员日常测试工作都是涉及上面的多个方面,今天我主要讨论下接口测试,涉及的是接口自动化测试,接口测试涉及程序的输入输出,接口自动化测试是利用TestNG测试框架,对程序的输入输出进行校验的测试工作。

      那么接口自动化测试可以为哪些公司提供测试服务呢?接口自动化测试其实和手工测试本质上测试内容是一致的,一般自动化测试都是针对比较稳定的程序,对于不经常进行变动的程序开展测试工作,接口自动化测试工作也是如此,主要是对已经完成大部分程序开发和测试的模块,对其中的部分改造的存量功能开展的测试工作,主要适用于接口类的测试工作,测试用例主要从手工测试用例中挑选,从中选择可以进行接口自动化测试的用例开展接口自动化测试工作。如果你们公司项目相对比较稳定,大部分项目主要是二次开发那可能就比较适用,最好是一个项目可以拆分为一个一个的相互之间相互独立又相互影响的应用,因为接口自动化测试大部分是涉及程序之间的接口应用;但是对于一个版本的改动导致程序改的面目全非,或者自动化主要是为了界面类服务的就不适用这套框架。

      搭建这套自动化测试环境复杂吗?搭建这套自动化测试环境主要分为以下三个方面,主要为:

      一、主环境,公司层面搭建的测试环境,主自动化测试环境;

      二、被测系统,主要是之前进行手工测试需要的系统环境,最好能有专门进行自动化测试的环境,如果资源有限也可以使用目前在用的被测环境;

      三、本地测试人员测试需要安装的软件;JDK,Eclipse等,具体可以参照以下图解:

    0030bd623c0f8bc89f2d6a87bf693ca6.png

      如果你们公司的系统适应这套自动化测试环境,并且测试人员已经按照要求把自动化测试环境搭建好了,现在怎么写接口自动化测试用例呢?接下来会讲到一条自动化测试用例怎么编写,以及怎么将自动化测试用例提交到环境上让自动化牵头人统计到,首先写自动化的时候可以首先完成下面材料的准备工作:接口文档(类名,方法名),jar包文件;接口文档可以问开发人员要,也可以自己去触发程序检查日志获得;Jar包文件可以直接让开发人员打包发给你,这个自己不太好获得,写完自动化测试用例之后自己上传到测试环境中。

    这里首先需要说明几点注意事项

    第一,虽然我们是自动化测试,也会用到开发人员使用到的Eclipse,Jdk等工具,但是这里面并不会涉及到很复杂的代码要求,并不需要测试人员和开发人员那样了解代码,代码要求其实不高,甚至也可以说没有代码要求,所以测试人员不需要担心自己没有大码底子,写不了这套框架的自动化测试用例,担心到时候写自动化的时候无从开展。

    第二,对数据库要求比较高,如果数据库基本薄弱这块相对会有点问题,所以写自动化之前前提是你是位比较了解数据库的测试人员。

      写自动化测试用例涉及哪些步骤呢?编写这套自动化测试用例测试人员需要准备什么呢?步骤有哪些呢?主要有以下操作步骤:

    第一、自动化测试环境

      如果在上面你已经把自动化测试环境搭建好了,其实节省了我们很多时间,然后需要确定好准备写哪个功能,哪个模块,最好能确定写哪个类下面的哪个方法,计划写什么用例,校验哪些点,对应前台的界面是哪些等,问开发人员要到对应功能的Jar包和接口文档等;

    第二、下载自动化测试工程(project)

      这个工程是我们的环境基础,我们在对应自己应用下面新增本次测试用例;

    第三、自动化编写涉及哪些文件

      3.1.JAVA文件(主程序,调用入参和数据准备文件);

      3.2.XLS文件(数据池文件);

      3.3.Dubbo文件(配置文件,配置自动化调度);

      3.4.Jar包(上面提到的问开发要的自动化Jar包,打包的程序,主要是一些类和方法);

      3.5.调度文件(自动化统计配置文档,包括每日新增自动化数量,新增模块,谁新增的以及失败自动化整改情况);3.6.接口定义文件(定义请求通讯区和应答通讯区);

    第四、自动化编写

      步骤一:将工程下载下来之后将Jar包上传,然后进行加载;

      自动化编写步骤二:可以复制和自己模块差不多功能点的JAVA文件,修改里面的ID,类名,方法名;其实除了类名,方法名,其他的代码调用公共方法,引用相同的包这些都是一样了,为了减少工作量,其他的复制就可以;

    第五、自动化工作流程

      XLS文件(数据池文件)里面主要是进行自动化编写的数据准备,包括请求通讯区和应答通讯区,因为我们的自动化工作流程主要为以下图示工作流程图,所以会涉及到请求通讯区和应答通讯区的数据和文件,数据池文件主要包括一些自动化案例执行前的Before class数据准备和自动化用例执行后的After class数据清理,是一系列的SQL代码,这里要求对数据库的SQL语句比较熟悉:

         接口自动化测试工作流程

      通过JAVA文件调用JAR包文件-->通过接口定义文件和数据池文件-->拼成一个报文(也可以叫map文件)-->往服务器(被测系统)发送-->等待服务器响应-->

      -->如果上送的内容与远程服务器一致,断言通过,测试用例执行通过;

      -->如果上送的内容与远程服务器不一致,断言不通过,测试用例执行不通过;

    6a89d84db165a17140724030a3657415.png 

    第六、断言

      这里面有个概念:断言,可能写过自动化测试用例的同行比较熟悉这个概念,没有接触过的可能就比较生疏了,这里统一解释下,断言其实对于我们这套接口自动化测试来说就是一个个独立的程序分支,可以借助于以下场景去帮助理解:业务场景:一个新增界面,要求新增用户,约束规则:已经注销的用户不能新增,新增过的用户不能重复新增;那么这个用例你会怎么设计呢?

    思路:写的类:1.针对重复用户,Before class:首先在用户信息表里面先数据库插入一条用户数据,需要先清理,怕插入时报主键冲突等错误,保证环境是干净的,清理是请求通讯区的数据准备操作Before class,然后执行插入操作,最后在应答通讯区在对应字段里面写入和插入数据完全一致的记录,这样在调用程序的时候就会报错:“该用户已经存在”,error code和error message会依据之前已经定义的接口文档抛出对应的错误,这条用例就是我们的一个断言,也就是一条接口自动化测试用例,执行完这条自动化之后我们需要对插入数据库的代码执行清理操作,这也是一个比较好的编写自动化测试用例的习惯,主要也是怕给数据库造成太多的脏数据,导致测试环境混乱,不利于后面测试。同理我们对注销的操作也是一样的,只是数据准备存在差异,涉及的表不同,这里面的话程序的判断接口是注销,则我们需要在注销涉及的表里面插入一条记录,然后前台在新增的时候会有对应的error message:“已经注销的用户不能新增”。

    第七、自动化测试用例统计

      已经写好的自动化测试用例我们需要进行提交,提交之前必须确保本地执行通过,没有失败的测试用例提交到环境上面,如果有失败的测试用例需要按照console的输出提示进行调试,调试完成没有问题提交GIT,这里面还是得说下这个git是个很好的东西,它只会出现那些你新增的内容在提交界面,然后你选择你刚刚编辑过的新增和有改动的代码提交到环境上面,这样后续就可以让自动化统计工具自动统计到,因为我们之前是每月有自动化编写要求的,所以必须在规定的时间将自动化测试用例提交到环境上去,至此我们的自动化测试用例算新增完成,后期的工作主要是维护,后期如果测试环境部署新的代码也是需要定期更新我们的自动化测试脚本。

      上面已经简单介绍了接口自动化测试用例是什么,接口自动化测试用例适合哪些公司的什么类型系统,接口自动化测试环境怎么搭建,怎么开展接口自动化测试,以及怎么编写一条接口自动化测试用例,希望本次介绍的接口自动化接口测试-TEST-NG框架可以帮助你们顺利完成自动化测试框架选择和搭建,可以对大家后期的自动化测试工作有所帮助,也希望大家可以分享自己公司目前在使用的自动化测试框架,最终我希望每家公司每个产品都可以找到一个适合自己本公司本产品的自动化测试框架,进而最终解放人力成本,让人力资源去做更多更有意义和更有价值的工作。

    ......

    本文选自《51测试天地》第53期电子杂志

    210cfe3026bff9c9ce2413031c6f7c63.gif

    2f2a94159e824daa2bde7312cf79043d.png

    推荐阅读

    点击阅读☞当一个测试工程师准备找工作,需要准备什么?

    点击阅读☞腾讯视频Mac App自动化测试实践

    点击阅读☞2019年前5大Java自动化测试框架

    点击阅读☞使用TestCafe进行Web自动化测试

    点击阅读☞2019年你不得不知的测试自动化新趋势……

    9767c4a14ab0e0a543ea97d17ddfa633.gif797100a449a8c41e529f2ddb8b13b624.gifaaf8d15e1d7ccacb3a14e4ff43f24f02.png爱我请给我好看!797100a449a8c41e529f2ddb8b13b624.gif
    展开全文
  • 接口测试分为分为单接口测试和多接口业务串联测试接口测试本质是测试接口传入正确的或错误的参数,服务端的处理逻辑是否正确。 其中单接口测试分为业务等价类测试、参数规则边界测试和安全测试三个维度: (1)...
  • 为了应对此种架构下的业务迭代,很多QA团队开始推广接口自动化,甚至是自研接口测试框架。选型一个好的接口测试框架可以抽象公共功能,有效应对业务变化,降低接口实现成本。但对于强业务相关的测试团队来说,迭代...
  • 为什么要做接口测试 接口测试本质上是功能测试的一种,属于后端服务器测试。但是它的影响范围要远广于web,app层面。原因很简单,因为目前很多公司,服务架构都是多端共用一套接口。和用户直接交互的UI界面,web,...
  • 第1章 接口自动化测试整体认知 了解什么是接口和为什么要接口测试。并且知道接口自动化测试应该学习哪些技术以及接口自动化测试的落地过程。 第2章 接口测试的用例设计 了解在接口测试中应该进行哪些测试,接口...
  • 导语万物皆可pipeline,流程自动化解放生产力。在DevOps的pipeline中,我们发现测试环节也需要一套流水线化的能力,来保证研发流程的大批pipeline稳定高品质交付。本文将主要介绍下devops中如何构建高水平全面的测试...
  • 出于各种花里胡哨的原因,今天给大家整一个简单又有成就感的接口自动化学习吧。不皮了,进入正题。本文中用到的技术点有:Python基础、Django基础、Request库、一丢丢前端基础。(考虑到大家零基础,所以文中代码...
  • 原标题:Python3接口自动化测试开发实战课程简介:是否想学习接口自动化框架开发,是否想实现当你点击一个按钮以后,拿...学习完本课程后,大家可以使用pyhon3做接口自动化测试框架的开发。时间在哪里?不要总想不行...
  • 做自动化测试时,经常会对一整套业务流程进行一组接口上的测试,这时候接口之间经常会有数据依赖,那么具体要怎么实现这个依赖呢。思路如下:抽取之前接口的返回值存储到全局变量字典中。初始化接口请求时,解析...
  • Newman+Postman实现接口自动化测试 目录 1 Newman插件介绍 3 1.1 插件简介 3 1.2 Newman安装 3 1.3 基本命令介绍 3 2 Postman工具使用 4 2.1 界面介绍 4 2.2 添加环境...
  • (简单记录,有问题请指出)直接用java语言对接口进行测试有很多便利的地方,比如说复杂的参数、部署服务、扩展性等 下面我用两种方式简单列举下java直接往http接口发送参数,进行接口测试一、方式一,简单不规范此...
  • 1、需求某API,GET方法,token,mobile,email三个参数token为必填项mobile,email 必填其中1项mobile为手机号,email为email格式2、方案针对上面的API,在做接口测试时,需要的测试用例动辄会多达10+...
  • 最全面的Java接口自动化测试实战第1章 接口自动化测试整体认知了解什么是接口和为什么要接口测试。并且知道接口自动化测试应该学习哪些技术以及接口自动化测试的落地过程。第2章 接口测试的用例设计了解在接口测试...
  • 今天聊得是自动化测试与测试用例的编写,首先来聊一聊框架(Framework)。 框架是工程学上一个非常重要的概念。在计算机和软件工程领域,我们可以轻松列举出一些耳熟能详的框架。例如,Windows软件开发框架.NET,Web...
  • 做自动化测试时,经常会对一整套业务流程进行一组接口上的测试,这时候接口之间经常会有数据依赖,那么具体要怎么实现这个依赖呢。思路如下:抽取之前接口的返回值存储到全局变量字典中。初始化接口请求时,解析...
  • 接口自动化测试实战这是一个从0到1的过程,一步一步搭建的测试接口框架,本教程从开始写框架的思路,和实现过程深入解析,并且深入到了每个相关的的各个细节,不论你是刚入门的菜鸟,还是一个懂编码经验的工程师,...
  • 目录1、接口自动化的意义(为何作这个框架)2、准备工3、框架流程及逻辑4、各模块介绍5、具体使用1、接口自动化的意义(为何作这个框架)新版本上线时以前版本的功能须要进行回归测试,致使大量的重复性手工测试。...
  • 接口定义:接口普遍有两种意思,一种是API(Application Program Interface),应用编程接口,它是一组定义、...接口测试中的接口指的是API。为什么要使用接口:假如公司的产品前端开发还没开发完,接口开发好了。有天...
  • 做自动化测试时,经常会对一整套业务流程进行一组接口上的测试,这时候接口之间经常会有数据依赖,那么具体要怎么实现这个依赖呢。 思路如下: 抽取之前接口的返回值存储到全局变量字典中。 初始化接口请求时,...
  • 接口定义:接口普遍有两种意思,一种是API(Application Program Interface),应用编程接口,它是一组定义、...接口测试中的接口指的是API。为什么要使用接口:假如公司的产品前端开发还没开发完,接口开发好了。有天...
  • 做自动化测试时,经常会对一整套业务流程进行一组接口上的测试,这时候接口之间经常会有数据依赖,那么具体要怎么实现这个依赖呢。思路如下:抽取之前接口的返回值存储到全局变量字典中。初始化接口请求时,解析...
  • JMeter怎么做接口测试_自动化

    千次阅读 2019-08-05 17:08:33
      说道自动化测试,肯定想到的步骤肯定是   1. 给他一个接口地址   2. 点击一个按钮   3. 输出一份测试报告   嗯,说这这样说,但是现在的JMeter还没有那么智能,能做到的是AppScan。   下面介绍一下...
  • 接口测试的方式有很多,比如可以用工具...在我们项目的初期,我们采用的是jmeter进行接口测试,当时觉得这个工具上手简单,团队成员学习成本低,并且接口测试的脚本稍微调整一下还可以用来性能测试。针对这个工...
  • 做自动化测试时,经常会对一整套业务流程进行一组接口上的测试,这时候接口之间经常会有数据依赖,那么具体要怎么实现这个依赖呢。思路如下:抽取 之前接口的返回值存储到 全局变量字典中。初始化接口请求时,解析 ...
  • 例如:一键将接口请求转为测试用例介绍了开源的mitmproxy录制转化为接口测试用例,postman接口用例转化为python自动化测试用例文章记录了如何把postman的测试用例转化为python的接口自动化的测试用例,那么今天呢,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 390
精华内容 156
关键字:

接口自动化测试怎么做的