发布新日志

  • 接口自动化测试平台

    2020-03-10 13:01:04

    接口自动化测试平台,免费**地址:test.ironz.com
  • 支持案例自动生成的接口测试平台

    2020-03-01 12:38:54

    IRON TEST支持接口类型丰富、案例自动生成、案例管理,定时回归执行,测试报告自动发送功能。地址:test.ironz.com
  • 为什么接口自动化测试的投入产出比最高,收益最大?

    2019-09-12 13:22:50

           测试的边际成本会随着缺陷发现率的提高而提高,这一规律也适用于自动化测试,在自动化测试金字塔模式中提到的3种自动化测试类型,(UI、接口测试、单元测试)随着自动化覆盖率的提升,自动化的成本也呈现指数式上升。按照这个思路进行拓展,可以得出单元测试,接口测试和UI测试的自动化测试,在相同的自动化率前提下,UI的成本最高、其次是API,Unit则最低。


           经济学中有另外一个著名的理论叫做边际效益递减。当做一项投资,随着投资量的增加,单位投资增量所带来的单位收益是越来越少的,甚至在某个临界点之后,这个收益有可能是负数。而这个零界点,就是投资收益最大的点。在这个点之前的所有投资,都可以扩大总收益,而在超过之后继续进行投资,就不那么明智了。

        按照这个思路,针对三种不同类型的自动化测试,可以获得三个零界点。而总收益最大的点在接口测试上,随后是单元测试,UI测试则最低。
      如果从测试效果上看,接口测试和UI/单元测试相比,有很多优势。 对于单元测试来说,通常单元测试是针对代码进行的测试,而接口测试是在测试一个活的,经过部署的系统。 另外,单个接口测试与单个单元测试用例相比,也可以覆盖更多的代码。更重要的是,接口测试也可以是面向业务的测试,通过接口进行业务层面的测试。
      而相比UI自动化用例,接口测试更加的简单直接,执行效率更高。 
           因此,将大部分自动化投资用于接口测试,可以获得最高的投资回报。再结合持续测试与持续集成等最佳实践,在团队之间彼此共享测试用例、测试框架或者平台。
           接口测试中目前常用的工具包括Jmeter,Postman,这2款工具在多人协调工作方面不太好,测试人员共同完成一个任务费时费力,尤其对成熟的企业。另外对不同接口类型的支持方面这2款工具也不太好,需要现开发,例如postman主要支持rest接口,Jmeter支持dubbo需要提供额外的jar包支持。
         基于上面的问题,这里有提供一款接口智能测试平台,不仅不需要懂代码,使用简单,对测试人员要求低,而且解决了postman和Jmeter中遇到的各种问题,还支持多人协同,支持加解密等扩展功能,满足成熟企业的要求。免费地址:https://test.ironz.com/welcome
    之后下载镜像,启动并绑定账号就可正常使用,关键是这一切都是免费的。
  • HTTP header详解

    2017-11-13 17:19:46

    就整个网络资源传输而言,包括message-header和message-body两部分。
    首先传递message- header,即http header消息 。
    http header 消息通常被分为4个部分:general  header, request header, response header, entity header。
    根据维基百科对http header内容的组织形式,大体分为Request和Response两部分。

    Requests部分

    Header解释示例
    Accept指定客户端能够接收的内容类型Accept: text/plain, text/html
    Accept-Charset浏览器可以接受的字符编码集。Accept-Charset: iso-8859-5
    Accept-Encoding指定浏览器可以支持的web服务器返回内容压缩编码类型。Accept-Encoding: compress, gzip
    Accept-Language浏览器可接受的语言Accept-Language: en,zh
    Accept-Ranges可以请求网页实体的一个或者多个子范围字段Accept-Ranges: bytes
    AuthorizationHTTP授权的授权证书Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    Cache-Control指定请求和响应遵循的缓存机制Cache-Control: no-cache
    Connection表示是否需要持久连接。(HTTP 1.1默认进行持久连接)Connection: close
    CookieHTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。Cookie: $Version=1; Skin=new;
    Content-Length请求的内容长度Content-Length: 348
    Content-Type请求的与实体对应的MIME信息Content-Type: application/x-www-form-urlencoded
    Date请求发送的日期和时间Date: Tue, 15 Nov 2010 08:12:31 GMT
    Expect请求的特定的服务器行为Expect: 100-continue
    From发出请求的用户的EmailFrom: user@email.com
    Host指定请求的服务器的域名和端口号Host: www.zcmhi.com
    If-Match只有请求内容与实体相匹配才有效If-Match: “737060cd8c284d8af7ad3082f209582d”
    If-Modified-Since如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
    If-None-Match如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变If-None-Match: “737060cd8c284d8af7ad3082f209582d”
    If-Range如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为EtagIf-Range: “737060cd8c284d8af7ad3082f209582d”
    If-Unmodified-Since只在实体在指定时间之后未被修改才请求成功If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
    Max-Forwards限制信息通过代理和网关传送的时间Max-Forwards: 10
    Pragma用来包含实现特定的指令Pragma: no-cache
    Proxy-Authorization连接到代理的授权证书Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    Range只请求实体的一部分,指定范围Range: bytes=500-999
    Referer先前网页的地址,当前请求网页紧随其后,即来路Referer: http://www.zcmhi.com/archives/71.html
    TE客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息TE: trailers,deflate;q=0.5
    Upgrade向服务器指定某种传输协议以便服务器进行转换(如果支持)Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    User-AgentUser-Agent的内容包含发出请求的用户信息User-Agent: Mozilla/5.0 (Linux; X11)
    Via通知中间网关或代理服务器地址,通信协议Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
    Warning关于消息实体的警告信息Warn: 199 Miscellaneous warning

    Responses 部分 

    Header解释示例
    Accept-Ranges表明服务器是否支持指定范围请求及哪种类型的分段请求Accept-Ranges: bytes
    Age从原始服务器到代理缓存形成的估算时间(以秒计,非负)Age: 12
    Allow对某网络资源的有效的请求行为,不允许则返回405Allow: GET, HEAD
    Cache-Control告诉所有的缓存机制是否可以缓存及哪种类型Cache-Control: no-cache
    Content-Encodingweb服务器支持的返回内容压缩编码类型。Content-Encoding: gzip
    Content-Language响应体的语言Content-Language: en,zh
    Content-Length响应体的长度Content-Length: 348
    Content-Location请求资源可替代的备用的另一地址Content-Location: /index.htm
    Content-MD5返回资源的MD5校验值Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
    Content-Range在整个返回体中本部分的字节位置Content-Range: bytes 21010-47021/47022
    Content-Type返回内容的MIME类型Content-Type: text/html; charset=utf-8
    Date原始服务器消息发出的时间Date: Tue, 15 Nov 2010 08:12:31 GMT
    ETag请求变量的实体标签的当前值ETag: “737060cd8c284d8af7ad3082f209582d”
    Expires响应过期的日期和时间Expires: Thu, 01 Dec 2010 16:00:00 GMT
    Last-Modified请求资源的最后修改时间Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
    Location用来重定向接收方到非请求URL的位置来完成请求或标识新的资源Location: http://www.zcmhi.com/archives/94.html
    Pragma包括实现特定的指令,它可应用到响应链上的任何接收方Pragma: no-cache
    Proxy-Authenticate它指出认证方案和可应用到代理的该URL上的参数Proxy-Authenticate: Basic
    refresh应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持)
     

     

    Refresh: 5; url=
    http://www.zcmhi.com/archives/94.html
    Retry-After如果实体暂时不可取,通知客户端在指定时间之后再次尝试Retry-After: 120
    Serverweb服务器软件名称Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
    Set-Cookie设置Http CookieSet-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
    Trailer指出头域在分块传输编码的尾部存在Trailer: Max-Forwards
    Transfer-Encoding文件传输编码Transfer-Encoding:chunked
    Vary告诉下游代理是使用缓存响应还是从原始服务器请求Vary: *
    Via告知代理客户端响应是通过哪里发送的Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
    Warning警告实体可能存在的问题Warning: 199 Miscellaneous warning
    WWW-Authenticate表明客户端请求实体应该使用的授权方案WWW-Authenticate: Basic
  • 接口测试基础

    2017-11-13 16:28:05

    什么是接口测试:

    接口测试是项目测试的一部分,正如其名,它测试的主要对象是接口,是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。

    接口测试的目的:

    接口测试的目的是测试接口,尤其是那些与系统相关联的外部接口,测试的重点是要检查数据的交换,传递和控制管理过程,还包括处理的次数。外部接口测试一般是作为系统测试来看待的。

    如何进行接口测试:

    不是所有的团队都可以在一个隔离的测试环境中进行测试工作的,因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试。等等这些都增加了实际测试执行中遇到的风险,但有些时候是可以避免的。

    如何设计接口测试用例

      首先,明确出发点。和所有的测试一样,接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向,你的设计行为就会尽量朝这个方向发展,更易发现问题,不会出现大方向的偏差。

      其次,选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口,每个接口如果分别测试,那将是很痛苦的一件事情,不光繁琐浪费,而且任何一个内部接口的变动,都将导致我们用例的不可用。这里推荐把整个系统作为一个整体,选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象,以此为测试对象的用例将有很好的健壮性,并且更高效。另外,根据数据的流向,又可将这些最外层的接口分为两类:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用,模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出时的状态如何,此时系统又是什么状态都是我们所应该验证的。

      然后,确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要什么样的功能。此两个功能一定要准确详细,用例的设计要严格按照测试对象功能设计才是正确的用例。

      最后当出发点、对象、功能都确定了,就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。

      接口测试用例设计和其他测试用例设计一样,都应该本着尽可能的发现bug的目标。用例设计的内容应该包括:主要测试功能点、测试环境、测试数据、执行操作以及预期结果。

      1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。用例在设计环境上有一个原则即:设计真实而危险的环境,不忽视偶发环境。真实,即你的用例在测试某种功能时,应该去思考这种情况发生时内部、外部环境是什么,通过各种手段将最准确的环境模拟出来。危险,即在这种环境下系统出问题的概率会很大。在设计用例环境时,如果两种环境都能达到你本用例的要求,更推荐选择更危险的环境。所谓偶发,即这种环境出现的概率很小。不要因为这种环境很少出现就无视它,开发很可能也是这种想法,此处很有可能隐藏着问题。

      2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计学问大,不要在设计、准备测试用例的数据上偷懒。要通过好的测试数据使用例查错的功能充分发挥。接口参数数据需对每个参数根据测试接口的实际的功能进行分析,在符合业务逻辑的情况下进行逻辑组合排列,不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据,使用例更容易发现问题。

      3)测试功能点,如果一个接口功能复杂时推荐对接口用例进行结构划分,这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。

      4)接口测试用例执行操作非常简单,就是所测接口的调用。

      5)预期结果验证,这也是接口用例设计的很关键的一步,应该细而不冗余。所谓细,用例中应详细列出应该验证的点。每个用例均需验证,不要因为前几个用例有验证就认为全部是正确的。避免一个用例中重复做相同的验证,提高测试用例的效率。


Open Toolbar