Skip to main content

5 篇博文 含有标签「自动化测试

View All Tags

· 16 分钟阅读

校验系统的正确性和可靠性时,仅靠用例场景无法覆盖全生产环境下的所有场景,需要一套引流工具,在系统正式上线前用线上的请求测试待上线系统,在正常请求下了解是否有报错、在数倍请求下了解系统的性能瓶颈。常用的引流工具有GoReplay、tcpcopy等。

猪齿鱼效能平台自动化测试模块流量回归测试功能,主要使用GoReplay录制产品界面中的操作产生的HTTP请求及响应用于生成流量文件,然后将其导入Choerodon平台生成用例进行管理与执行。本文通过GoReplay的介绍及GoReplay在猪齿鱼效能平台中的实践,帮助大家理解猪齿鱼流量回归测试的概念及使用。

关于GoReplay

GoReplay,原名叫gor,因为其易上手,且功能比较全所以我们使用GoReplay进行流量录制。GoReplay是在投入生产之前使用真实流量测试应用程序最简单和最安全的方式。

随着应用程序的增长,测试所需的工作量也呈指数增长。GoReplay提供了重复使用现有流量进行测试的简单想法,这使得它非常强大。可以分析和记录应用程序流量,且不影响应用,消除了将第三方组件置于关键路径中带来的风险。

GoReplay的安装

  1. 下载地址:https://github.com/buger/goreplay/releases

  2. 然后在环境中输入指令:

--wget https://github.com/buger/goreplay/releases/download/v1.1.0/gor_1.1.0_x64.tar.gz

这样我们就能获取到gor_1.1.0_x64.tar.gz压缩文件,。

  1. 然后对其解压输入指令:

--tar vxf gor_1.1.0_x64.tar.gz

文件解压过分我们得到了一个gor文件;我们将gor文件移动到path环境下,这样我们就可以使用gor命令进行流量录制了。

GoReplay的基本指令

  • --input-raw - 用于捕获HTTP流量,您应该指定IP地址或接口和应用程序端口。
  • --input-file- 接受之前使用的文件--output-file
  • --input-tcp - 如果您决定将来自多个转发器Gor实例的流量转发给它,则由Gor聚合实例使用。

可用输出:

  • --output-http - 重放HTTP流量到给定的端点,接受基础URL。

  • --output-file - 记录传入的流量到文件。

  • --output-tcp- 将传入数据转发给另一个Gor实例。

  • --output-stdout - 用于调试,输出所有数据到stdout。

GoReplay在猪齿鱼平台的实践

1. 录制流量

1.1 首先我们先在服务器中安装Gor_1.1.0

1.2 然后输入命令以下命令:

sudo nohup gor --input-raw :8080 \ # 监听服务的端口(默认网关的端口为8080) -http-allow-method GET \ # 只录制GET,POST,PUT,DELETE四种方法的请求 -http-allow-method POST \ -http-allow-method PUT \ -http-allow-method DELETE \ -input-raw-track-response \ # 捕获响应报文 -input-raw-timestamp-type PCAP_TSTAMP_HOST \ # 指定时间戳格式 -input-raw-buffer-size 32mb \ # 控制用于持有TCP包的系统缓存大小 -prettify-http \ # 自动解码 Content-Encoding:gzip 和 Transfer-Encoding:chunked的请求和响应 -output-file-append \ # 追加到文件,使得最终只生成一个.gor文件 -output-file requests.gor & # 指定结果文件名称

这些命令的含义是监听服务的端口并开始录制指定的请求类型的请求,例如这里录制的请求类型是:GET,PSOT,PUT和DELETE。捕获响应报文并把这些请求追加到文件,像这里生成的文件名叫“requests.gor”。

1.3 在命令执行后,输出如下:

这里显示的【1】19436是gor程序的进程PID,在我们录制完成后可以利用此PID进行终止gor。

1.4 这时gor已经开始进行流量录制了,此时测试人员可以开始在被测系统进行测试,此段时间的测试发出的请求会被录制。

测试人员在正式录制相关的功能之前,建议刷新页面以请求 self 接口获取当前用户信息,这个接口的响应便于之后导入流量文件时解析用例,如果既没有录制到 self 接口,也没有在导入时提供用户信息获取接口,则在无法解析请求所属用户的情况下,请求生成的用例会被忽略。

1.5 在录制一段时间的流量后,我们执行以下命令终止gor的录制输入一下命令:

sudo kill -15 ${gor进程PID}

像我们这里的输入sudo kill -15 ${19436}命令就可以终止gor进程。

1.6 此时,可以看到执行录制指令的目录下,得到一份文件名为 requests.gor 的流量文件。到此,录制完毕。

2.导入流量文件

2.1 我们进入猪齿鱼流量回归测试页面:

2.2 点击流量回归测试右上方的导入流量文件,进入流量导入界面:

2.3选择选择用于放置生成用例的目录,我们这里选择的是测试合集目录,点击上传按钮,上传我们刚才录制的requests.gor文件,确定上传文件后,下方会立刻生成一条文件的导入记录。

如果导入用例为0条,可能有以下原因:

①录制期间,被测系统未关闭主键加密功能;

②录制期间,未请求 self 接口获取用户信息,且导入时未提供用户信息获取接口;

③提供用户信息获取接口,但是录制的流量文件时间过长,超过了用户的 Token 过期时间,导致流量文件中涉及到的请求的认证信息已经过期了,无法识别用户,所以无法生成用例;

④所有的请求都不是 json 类型的请求

⑤所有的请求的方法都不是 GET、POST、PUT或DELETE

2.4 待文件导入成功后,所选的目录下将会生成对应的用例。列表中会展示各个用例对应的路径、请求方式、菜单、用户以及请求时间。

  • 路径:即用例中请求的路径。
  • 请求方式:即用例中请求的请求方式。
  • 菜单:即用例中对应请求所属的菜单。
  • 用户:即在录制过程中,执行此次请求的用户名。
  • 请求时间:即录制过程中,该请求对应的执行时间。

3.用例批量处理

3.1 由于我们通过导入流量文件得到的用例内,各个请求使用的ID参数在之后的执行过程中会产生变化。因此我们需要通过用例批量处理的功能将用例内各个请求路径、请求参数、请求体中的ID参数替换为变量。

在此之前,我们还需要选择一个POST类型的请求,将其响应体中生成的ID作为变量提取出来,以供后续的用例进行引用。

首先在页面左侧的树结构内选中一个流量回归集合,而后点击顶部的用例批量处理按钮,右侧会出现批量处理的页面。

3.2使用搜索栏进行用例筛选,支持的搜索方式有:

  • 输入搜索条件查询:可搜索任意内容,下方的列表中将会显示出路径、请求与响应中含有搜索值的对应用例。
  • 快速筛选:预置的快速筛选为含数值用例,可直接搜索出路径、请求与响应中含有数值的所有用例,用于帮助进一步缩小ID查询范围。同时,保存的自定义筛选条件也将存放到快速筛选的下拉框中。
  • 请求方式筛选:允许筛出GET、POST、PUT与DELETE类型的用例请求。
  • 用例状态筛选:支持筛选出处理完成未处理状态的用例请求。
  • 正则筛选:支持使用正则表达式来筛选出满足条件的用例请求。
  • 目录筛选:支持筛选出各个目录下的用例请求。
  • 菜单筛选:支持筛选出对应菜单下的用例请求。
  • 具体字段:用于指定搜索值的定位生效区域。支持定位到:路径、请求头、请求参数、请求体、响应头与响应体。

3.3提取页面中的变量,在此界面中,需要将生成ID的用例请求找到,并将其响应体中的ID参数作为变量提取出来。具体步骤如下:

​ 1.通过搜索栏中的各个选项定位到目标用例。

此处的一般步骤为: - 在快速筛选的搜索栏中选择含数值用例,先筛出所有含有数值的用例。 - 在具体字段中,选择为:POST,以筛出目标用例。 - 选择想要处理的功能块所在的菜单,或在搜索条件中输入相关内容,来进一步缩小搜索的范围。 - 最后,在筛出的用例请求中逐一找出目标用例。

​ 2.勾选出一个目标用例,点击下方的添加变量提取的按钮,右侧会弹出变量提取的界面。

  1. 选择提取的来源:一般为响应体JSON,此处需根据提取的目标变量的位置与格式而定;支持选择响应体JSON、响应体XML、响应体文本与响应头。

  2. 输入变量名称:此处输入的变量名称,会作为后续用例引用的变量。

  3. 选择器:需通过选择器定位到提取的变量所在的位置。

变量提取成功后,还需要对请求中使用了ID参数的用例进行批量的ID替换,将其替换为提取出的变量。 使用此功能,可以批量地将可以配置的参数提取为变量,例如提取请求中常见的项目ID、租户ID或者其它的资源ID。

  • 值替换功能:

    • 选择替换区域:支持选择路径、请求参数、请求头、请求体、响应头、响应体;用于定位所有选中的用例需要进行替换的具体区域。

    • 输入源值:即之前的ID参数的准确值。后续会将这个ID数值替换为已经提取出的变量。

    • 输入替换值:在此输入需要引用的变量即可。

      例:之前提取出的变量名称为id,此处就输入:${id}

  • 用例状态替换:直接在下拉框中选择需要将所选的用例请求变为的目标状态;对于已经处理完成的用例请求,直接批量将其置为处理完成的状态即可。回到列表之后,这些用例的状态就变为了处理完成

总结

猪齿鱼全场景效能平台流量回归测试通过GoReplay批量录制产品界面操作,并将得到的用例进行集中管理,便于后续进行批量的回归测试,从很大程度上减轻了测试人员编写脚本、收集测试数据等重复且耗时的工作,提升团队的测试效能。

参考资料

欢迎免费试用SaaS企业版

试用链接:https://choerodon.com.cn/register-organization/#/

关于Choerodon猪齿鱼

Choerodon猪齿鱼是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

更多内容

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

Choerodon猪齿鱼官方社区用户交流群,此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得,群同步更新版本更新等信息,大家可以加群讨论交流。

请添加Choerodon猪齿鱼小助手微信:hand-c7n

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 19 分钟阅读

JMeter简介

JMeter 的特性:

  • 对于多种协议的功能测试和性能测试
    • Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
    • SOAP / REST Webservices
    • FTP
    • Database via JDBC
    • LDAP
    • Message-oriented middleware (MOM) via JMS
    • Mail - SMTP(S), POP3(S) and IMAP(S)
    • Native commands or shell scripts
    • TCP
    • Java Objects
  • 提供了测试录制
  • 提供 CLI 模式
  • 提供 HTML 报告
  • 完全的可移植性和百分百的纯 Java
  • 提供多线程支持,模拟多用户
  • 高扩展性

    这一节内容译自 JMeter 首页: https://jmeter.apache.org/index.html

笔者实验环境

JMeter是Java语言的实现,也就是纯Java应用,所以JMeter理论上可以运行于任何对应的Java环境可用的环境上。 | 类型 | 值 | | :--------- | :------------------------------------------- | | Java版本 | java version "1.8.0_181" (要求Java8及以上) | | JMeter版本 | 5.4.1 | | 操作系统 | Ubuntu 20.04(GNOME 3.36.5) | | 内核版本 | Linux version 5.8.0-43-generic |

下载

本文主要介绍 JMeter 的快速入门,故其它环境由读者自行准备

  1. 进入官网页面(https://jmeter.apache.org/download_jmeter.cgi)选择合适的镜像源,下载二进制分发文件;
  2. 将压缩文件解压到本地后,JMeter 解压后得到的目录的路径称为 JMETER_HOME; ##JMeter文件简单介绍
文件路径(相对于 JMETER_HOME 目录)文件描述
bin文件夹,里面存放可执行文件
docs帮助文档目录
extras扩展插件目录,目录下的文件提供了对ant的支持
libJMeter用到的jar包
bin/jmeter在linux和unix系统中启动JMeter客户端的可执行文件(本身是shell脚本)
bin/jmeter-server在linux和unix系统中启动JMeter服务进程的可执行文件(本身是shell脚本)
bin/jmeter.propertiesJMeter的配置文件
bin/jmeter.batWindows下启动JMeter客户端的可执行文件
bin/jmeter-server.batWindows下启动JMeter服务进程的可执行文件

启动JMeter的用户界面

进入 JMETER_HOME 目录下的 bin 目录,执行以下命令启动 JMeter 的 GUI 模式:

./jmeter

几秒后,界面打开如下:

JMeter主要概念简介

概念简介
测试计划测试计划描述了JMeter需要执行的一系列步骤
线程组线程组定义了执行的用户池(以并发方式模拟多个用户)
jmx文件对应于一个测试计划的以(.jmx)结尾的文件,文件中是以xml格式组织的JMeter程序特定数据结构
采样器(sample)采样器可以对执行的目标进行采样(HTTP,JDBC等类型)
前置处理器(pre-processor)对采样器进行前置处理(提供用户参数,等待指定时间等)
后置处理器(post-processor)对采样器进行后置处理(结果提取器等)
断言(assertions)对采样器得到的结果进行断言(响应时间断言,响应数据断言,响应的结构断言等)
逻辑控制器(Logic controller)以逻辑的形式控制测试计划的执行步骤(If, While等)
监听器(listener)在采样器执行结束后,监听器会被通知,一般监听器用于处理结果数据(展示结果数据,聚合图表等)
配置元素(config element)能够为测试计划进行一些配置(请求头配置,通用请求配置,认证配置,变量配置等)

JMeter主要功能元素简介(Http测试相关)

JMeter 界面操作大部分是单击鼠标右键会弹出下拉菜单进行元素的添加

线程组

右键测试计划添加

组件截图:

组件参数说明:

参数名称取值及含义
错误后的动作继续(继续执行之后的步骤)、启动下一循环、停止线程(仅此线程)、停止测试(等正在执行的采样器执行结束后停止测试)、立即停止测试
线程数要模拟的用户数量
Ramp-Up时间(秒)预热时长。用于在执行的时间内将所有配置的数量的线程启动完毕。例如10s,线程数为10,则每隔1s启动一个线程(第一个线程总是立即启动的,如果总线程数为1,则无论预热时长取值多少,都等效于0)
循环次数永远(循环不停止)、指定数字(指定次数循环之后,停止执行)
每次循环同一用户吗?是/否

HTTP请求默认值

鼠标右键单击线程组元素,从配置元件(config element)下拉项中添加

这个组件用于为作用范围内的HTTP采样器提供默认值。

组件参数说明:

参数名称取值及含义
协议是http协议还是https协议
服务器名称或IP域名或者IP地址
端口号服务器的端口号
路径URL中的path部分
内容编码HTTP请求所使用的字符集编码
参数HTTP请求参数
消息体数据默认的请求体的数据

用户定义的变量

鼠标右键单击线程组元素,从配置元件中选择添加

这个组件用于在线程中定义变量,可以在其它地方使用 ${variableName} 的语法进行引用。

在下列界面点击 添加 按钮添加一行变量名和值即可定义一个变量。

HTTP采样器

鼠标右键单击线程组元素,从采样器条目中选择

HTTP采样器可以使用 HTTP 请求的形式对被测系统进行采样(发起请求)。这个组件中很多数据和上文提到的 HTTP请求默认值 组件中的很多属性相同,如果此采样器在 HTTP请求默认值 组件作用范围内,则采样器中为空的属性会填入默认值,不为空的属性会覆盖 HTTP请求默认值 组件中相同的属性(就近)。

组件参数说明:

参数名称取值及含义
协议是http协议还是https协议
服务器名称或IP域名或者IP地址
端口号服务器的端口号
路径URL中的path部分
内容编码HTTP请求所使用的字符集编码
参数HTTP请求参数(URL中的查询参数)
消息体数据请求体的数据
请求方法GET、POST、PUT、DELETE等HTTP方法
文件上传用于上传文件
自动重定向勾选表示自动重定向。表示下游的HTTP协议处理器会自动的重定向,所以重定向中间的过程对JMeter是不可见的。且只能用于GET和HEAD方法。POST和PUT方法会被拒绝。
跟随重定向勾选后表示跟随重定向(仅当自动重定向未勾选时有效)。如果设置,JMeter的采样器会对响应进行处理,且会追踪过程中的每次重定向,并将最后一个未重定向的请求和响应作为最外层的采样数据,其它的请求的数据作为这个采样数据的附加信息。(最大重定向次数为20)
使用KeepAlive勾选后,JMeter会设置请求头 Connection: keep-alive 。但是这个选项是否生效还和JMeter的HTTP实现有关

响应断言

鼠标右键单击采样器,点击【添加-断言-响应断言】选项添加

响应断言可以为采样器所得的结果进行断言,以逻辑(等于、包含、正则匹配等)对包括响应头、响应码、响应体等在内的内容进行断言,以校验采样器的输出是否符合测试者的预期。

组件参数说明:

参数名称取值及含义
Name断言的名称
Apply to选定断言的作用范围,一般是用到 Main sample only 选项,Main sample 指的就是这个断言所属的采样器,而 sub samples 指的是由这个采样器产生的子采样器,比如 HTTP 采样器的高级选项 -- 获取内置的资源,就会产生子采样器。
Field to Test指的是需要进行断言的目标。Text Response 指的是从服务器获得的整个响应作为文本(响应体)。Response Code 是响应码 (例如200)。Response Message 是响应消息(例如OK)。Response Headers 是响应头。Request Headers 指的是请求头。Request Data指的是请求的所有数据作为文本(请求体)。URL sampled 是采样的 URL。Document 指的是 View Results Tree 组件的 Document 部分一样的以特定规则提取出的文档。
Ignore status忽略响应的状态码。一般 4xx 和 5xx 是默认认为是失败的。如果不设置,总的 sample 的结果是由状态码的成功失败和断言的结果的结合。如果设置了,就会设置状态为成功,再进行断言(注意:如果设置了这个参数,要把这个断言放在第一个,否则会清除前面的断言的失败结果)
Pattern Matching Rules对于给定的模式串,使用怎样的规则。Contains 包含模式串 (模式串被看作正则表达式)。Matches 表示正则匹配的 match (模式串被看作正则表达式)。Equals 表示相等(大小写敏感,模式串被看作纯文本)。Substring 表示被测文本包含给定的模式串 (模式串被看作纯文本)。两种逻辑符号: Not 和 Or 。Not 表示对结果取反。 Or 表示匹配规则对于给定的一系列模式串成立一个那断言就是 OK 的。
Patterns to Test用来测试的模式串列表。可以点击 Add 按钮添加多个模式串。如果是正则表达式则是 Perl5-style 的正则表达式且没有封闭的括号的形式。

JSON变量提取

右键单击请求,Add -- Post Processors -- Json Extractor 添加 JSON 提取器元素

JSON 提取器可以用于从响应体中的 JSON 结构中提取指定位置的属性为变量。

组件参数说明:

参数名称取值及含义
Name展示用的描述性的名字
Names of created variables创建的变量的一个或多个名称(多个以逗号分隔),数量要对应 JSON Path 表达式
JSON Path Expressions一个或多个 JSON path 表达式 (多个以逗号分隔),数量和变量数目要匹配。(表达式的写法参考下文)
Default Values一个和多个默认值(多个以逗号分隔)。如果某个 JSON path 表达式没有返回值就用对应位置的默认值。数量和变量数一致
Match No. (0 for Random)如果 JSON path 表达式可以取得多个值,该取哪个。0 表示随机;-1 表示提取所有的结果(会生成多个变量,名为 _N,N从1开始);X表示提取指定位置的结果,从1开始,如果X大于结果的数量,则返回空(会尝试使用默认值)
Compute concatenation var如果勾选,表示如果有多个结果得到,会将他们逗号分隔,放入名为 _ALL 的变量

JSON path 写法: $ 符号表示根元素,. 表示取属性,[0] 表示取数组对象的第一个元素 ( [1]就是第二个)。

例如:

{
"user": {
"names": ["Jack", "Jacky"],
"age": 10
}
}

对于以上 JSON ,使用表达式 $.user.names[0] 即可提取出 Jack 这个值。 更详细的信息可以参考: https://jsonpath.com/

查看结果树元素

这个元素是用于使用 JMeter 界面进行请求执行时查看请求的执行情况的,他可以查看到请求的请求报文和响应报文以及断言情况等信息。详情参考下文。

JMeter使用示例

接下来,我们使用上面学到的知识,实现这么一个场景:查询 Gitee 上猪齿鱼仓库下的贡献者, 然后提取出指定的一个贡献者名称,用第二个请求获取贡献者的信息。

使用的 Gitee 的两个接口为

  • GET https://gitee.com/open-hand/choerodon/contributors_count?ref=0.23.0

响应体结构为(我们需要获取的贡献者名称的 JSON path 为 $.contributors[0].username):

{
"status": 1,
"contributors_count": "16",
"contributors": [
{
"username": "example1"
}
]
}
  • GET https://gitee.com/{贡献者名称}

创建测试计划

打开 Jmeter 会有个默认的测试计划

创建线程组

右键鼠标单击测试计划,点击 Add > Threads (Users) > Thread Group 添加线程组元素。其中填入以下值:

创建 HTTP 默认值配置元素

鼠标右键单击线程组,Add > Config Element > Http Request Defaults 添加配置元素。填入值如下:

创建 HTTP 采样器获取贡献者列表

右键单击线程组,Add > Sampler > HTTP Request 添加采样器(填入path和添加一个parameter):

添加响应提取器

右键单击请求采样器,Add > Post Processors > JSON extractor 添加元素如下,因为某些用户在 gitee 并不存在,这里我们将提取 JSON path 为 $.contributors[4].username (也就是第五个贡献者)的用户名值放入变量 contributorName

添加查看结果树元素到请求下

右键单击采样器,Add > Listener > View Results Tree 添加查看结果树如下:

添加 HTTP 采样器请求特定的贡献者信息

右键单击线程组,Add > Sampler > HTTP Request 添加采样器(这里在 path 属性填入 ${contributorName} 用于引用上一个请求提取出的变量):

添加查看结果树元素到请求下

右键单击采样器,Add > Listener > View Results Tree 添加查看结果树如下:

点击绿色三角形进行执行

点击执行按钮后,会提示我们先将文件保存后再执行,选择一个合适的目录保存后,点击执行按钮,此时绿色的执行按钮会变成灰色,同时右上角会开始计时,这表明请求正在执行,等按钮再次变成绿色时,说明执行结束了。

查看执行结果

点击第一个请求的 查看结果树 元素可以查看这个请求的执行结果:

可以看到响应体的信息为:

查看第二个请求的请求数据,可以看到请求成功,且可以看到请求路径的 ${contributorName} 已经渲染为第一个请求提取到的值 handchoerodon

总结

JMeter 提供了 HTTP 采样器,各种断言机制,配置机制以及变量提取机制,可以帮助进行我们模块化的接口测试,使得系统更加健壮。

扩展资料

参考文档

  1. JMeter Get Started
  2. JMeter组件说明

· 13 分钟阅读

UI 测试是一种测试类型,也称为用户界面测试,通过该测试,我们检查应用程序的界面是否工作正常或是否存在任何妨碍用户行为且不符合书面规格的 BUG。了解用户将如何在用户和网站之间进行交互以执行 UI 测试至关重要,通过执行 UI 测试,测试人员将尝试模仿用户的行为,以查看用户将如何与程序进行交互,并查看网站的运行情况是否如预期的那样,是否有缺陷。

在上次的自动化测试系列(二)中为大家大体介绍了API测试的概念及在猪齿鱼中的实践展开,本文主要围绕UI测试进行概念介绍及Choerodon中的实践展开。

下面为大家详细介绍猪齿鱼提供的UI测试功能:

什么是 UI 测试

UI 测试涵盖了用户交互部分,包括用户关注的网站结构和视觉部分。Web 网站包含许多来自 CSS,JavaScript 和许多其他语言的不同 Web 元素,网站元素可以连接到屏幕、键盘、鼠标或用户用于与网站进行交互的任何其他工具,UI 测试则捕获这些元素并对其进行测试和声明。

在执行 UI 测试时,需要注意确保应用程序不存在任何跨浏览器兼容性问题。由于每个浏览器都使用不同的浏览器引擎,并且可能不支持相同的 CSS 功能。因此,确保UI 在所有主要浏览器上无缝呈现非常重要。在不同的浏览器上进行测试称为跨浏览器测试,可以帮助测试人员在所有主要浏览器和设备(包括手机,平板电脑等)的多种组合下测试其网站。

手动或自动,如何选择?

与其他任何类型的测试一样,UI 测试也可以手动或通过自动化执行。手动测试要求测试人员在每个元素上手动执行每个测试。例如,测试输入字段将需要针对任何差异一次又一次地键入不同的值。如果网站 UI 的组件较少​​,则最好通过手动过程进行 UI 测试,快速地完成。但它不适合复杂的网站,用户界面丰富的网站使手动 UI 测试则非常低效,费时且容易出错。

适合UI自动化测试的场景

不是所有的测试场景都适合用自动化测试来实现,对此,可以参考以下的标准辅助判断:

  • 项目的需求不会频繁变动
  • 页面的 UI 已经进入稳定阶段
  • 项目周期足够长
  • 大量回归的测试任务

其中,有些项目是明显不适合使用 UI 自动化测试的,例如视频播放器,音乐播放器等交动性强,并发依赖强的软件。

UI自动化测试的优点

UI自动化测试过程简化了创建UI测试、运行测试以及查看结果的过程,开发和测试团队选择自动化UI测试的原因有很多,最值得注意的包括:

  • 时间 – 手动测试速度很慢,无法与许多开发过程保持同步。
  • 成本 – 手动测试需要大量资源且成本很高。
  • 准确性 – 执行重复性任务时,手动测试容易出现更多错误。相反,自动化减少了这些错误的机会。
  • 规模化 – 执行复杂的迭代时,很难依靠手动测试。
  • 趋势 – 大多数组织已经意识到如何从自动化测试中受益,因此,跳上自动化潮流的压力越来越大。

UI自动化测试设计原则

  • 一个测试用例完成一个功能点测试(常用):一个手工用例对应一个自动化测试用例;
  • 一个脚本是一个完整的场景;
  • 脚本之间独立,不能有依赖(脚本间相互隔离):例如与登陆状态相关的用例:个人中心、订单详情、下单购物等,如果脚本之间不独立,相互依赖,在登陆的测试脚本失败的情况下,会导致个人中心、订单详情、下单购物的测试脚本全军覆灭,后续修复与维护成本高;
  • 设置合适的检查点:通过断言判断用例的成功与否;
  • 设计良好的框架:Python 常用的测试框架有 unittest 与 pytest,利用框架,及对共用的测试模块进行封装,减少自动化测试脚本维护的工作量;

WEB端UI测试工具介绍

API测试用例主要由4个部分组成,分别是:用例的基础信息、前置步骤、请求脚本以及断言。

UTF

UTF( Unified Functional Testing) = QTP( Quick Test Pro) + ST( Service Test)由 HP 公司开发。它是一种企业级的自动测试工具,提供了强大易用的录制回放功能,同时兼容对象识别模式与图像识别模式两种识别方式,支持 B/S 与 C/S 两种架构的软件测试,是目前主流的自动化测试工具。主要是用于回归测试和同一软件的新版本测试。

Robot Framework

是一款基于 Python 语言编写的自动化测试框架,具备良好的可扩展性,支持关键字驱动,可以同时测试多种类型的客户端或者接口,可以进行分布式测试。

Selenium

Selenium概要

Selenium 也是一个用于 Web 应用程序测试的工具,支持多平台、多浏览器、多语言去实现自动化测试,目前在 Web 自动化领域应用最为广泛。

Selenium 是最广泛使用的开源 Web UI(用户界面)自动化测试套件之一,最初由杰森·哈金斯(Jason Huggins)于 2004 年开发,作为 Thought Works 的内部工具。Selenium 支持跨不同浏览器,平台和编程语言的自动化。

Selenium功能特性

  • Selenium 是一个开源和可移植的 Web 测试框架。
  • Selenium IDE 为创作测试提供了回放和录制功能,而无需学习测试脚本语言。
  • 它可以被视为领先的基于云的测试平台,可帮助测试人员记录他们的操作并将其导出为可重复使用的脚本,并具有易于理解且易于使用的界面。
  • Selenium 支持各种操作系统,浏览器和编程语言。如下列表:
    • 编程语言: C# ,Java,Python,PHP,Ruby,Perl 和 JavaScript
    • 操作系统:Android,iOS,Windows,Linux,Mac,Solaris。
    • 浏览器:谷歌浏览器,Mozilla Firefox,Internet Explorer,Edge,Opera,Safari 等。
  • 它还支持并行测试执行,从而减少了时间并提高了测试效率。
  • Selenium 可以与 Ant 和 Maven 等框架集成,用于源代码编译。
  • Selenium 还可以与 TestNG 等测试框架集成,以进行应用程序测试和生成报告。
  • 与其他自动化测试工具相比,Selenium 需要的资源更少。
  • WebDriver API 已经尝试集于 Selenium 中,这是对 Selenium 进行的最重要的修改之一。
  • Selenium Web 驱动程序不需要服务器安装,测试脚本直接与浏览器交互。
  • Selenium 命令根据不同的类进行分类,使其更易于理解和实现。
  • Selenium Remote Control(RC)与 WebDriver API 一起被称为 Selenium 2.0。此版本旨在支持充满活力的网页和 Ajax。

Selenium三大优点

  • 速度:时间是每家公司的主要资源,自动化测试可以节省很多时间。Selenium Automation 测试要求我们只编写一次测试,然后一次又一次地运行它们,而不会以不同的值和不同的方案进行任何干预。
  • 准确性:只要测试编写正确,Selenium Automation 测试就可以帮助我们正确执行测试。手动测试的主要缺点是容易发生人为错误。
  • 透明度:Selenium Automation 测试还有助于快速生成报告,并在测试完成后立即与团队共享。另一方面,手动测试需要时间来提取结果并手动报告结果以通过软件或手动生成报告。

Choerodon UI测试

安装

若在Choerodon 中使用 UI 测试,需要先安装Selenium IDE 。

Selenium IDE(集成开发环境)是 Selenium Suite 下的开源 Web 自动化测试工具。与 Selenium WebDriver 和 RC 不同,它不需要任何编程逻辑来编写其测试脚本,而只需记录与浏览器的交互以创建测试用例。之后,可以使用播放选项重新运行测试用例。 注意:Selenium IDE 仅作为 Firefox 和 Chrome 插件提供,它无法在 Firefox 和 Chrome 以外的浏览器上记录测试用例。记录的测试脚本也可以导出到 C#,Java,Ruby 或 Python 等编程语言。

Firefox 浏览器

Chrome 浏览器

使用

在 Chrome 浏览器上使用 Selenium IDE 录制与回放脚本

1、打开 IDE,初始化界面如图:

2、创建并开始录制,输入录制的 web 地址

3、录制完成,右击测试用例,保存或导出。Selenium IDE 保存的都是.side 的单文件

Choerodon 中的 UI 测试是通过 Selenium IDE 中录制生成的 side 文件导入系统中,在 UI 测试界面中生成对应的测试用例与步骤;而后便能直接执行对应的测试文件来对界面 UI 操作进行测试,可以直观的看到生成的测试报告。

总结

UI测试是软件测试周期的重要组成部分,是改善用户体验和客户满意度的重要驱动力,大多数最终用户更关心他们实际看到和触摸的内容。因此,这也是为什么UI或用户界面变得如此重要,从而进行UI测试的原因。

· 11 分钟阅读

在上次的自动化测试系列(一)中为大家大体介绍了自动化测试的概念,本文主要针对API测试的概念及API测试在Choerodon猪齿鱼中的实践展开。

API(应用程序编程接口)测试是一种软件测试,可以直接在API级别执行验证。它是集成测试的一部分,它确定API是否满足测试人员对功能,可靠性,性能和安全性的期望。与UI测试不同,API测试是在没有GUI的消息层执行的。

什么是API测试

接口(API)是各种系统功能的基础,一旦接口出现问题可能会引起许多系统功能的问题并且不容易定位。而接口测试则帮助节省了测试成本,促进了测试前移。如图所示,在软件的自动化测试金字塔中,越是底层的测试,越是能够提前发现Bug,而在底层发现的这些Bug造成的影响往往也会更大。所以,我们倡导测试前移,也就是说,在金字塔中层级越低,占的比重应该更大。(但是在实际工作中,单元测试对技术专业性要求更高,很多情况下都是由开发来实施,因此我们可以先选择接口测试来更早地介入测试。)

其次,接口测试相较于传统的功能测试,接口测试能够更好地解决系统测试的复杂度问题,同时避免了UI层可能不稳定的问题,以此来提高测试人员的工作效率。

通过将API测试任务集成至应用流水线,Choerodon平台实现了接口测试的自动化。

怎样使用Choerodon API测试功能?

本次旨在为大家介绍在Choerodon猪齿鱼 V0.24.0商业版中API测试相关的功能。

API测试用例管理

Choerodon中的接口测试模块通过集成Jmeter,实现了API用例的添加、归集、管理与执行的功能。其中支持基于接口URL或Swagger文档快速编排接口测试用例,而导入或添加API测试用例的整个过程免代码编写,技术门槛低,适合敏捷团队中各个角色使用。

  • 创建API测试用例

API测试用例主要由4个部分组成,分别是:用例的基础信息、前置步骤、请求脚本以及断言。

  • 前置步骤用于为执行用例请求做前置准备,分为:前置请求、生成随机数据、前置等待3种类型。
  • 请求脚本中包含了:选择请求方式、维护URL、维护请求头、请求参数或请求体,同时还能从对应的响应结果中提取出变量供后续的用例引用。
  • 断言用于对用例执行后的响应结果做判断,判断请求执行后的响应结果是否满足我们的预期。若满足,则称之为:通过断言;不满足,则为:不满足断言;
  • 导入API测试用例

导入用例的功能支持将已有的接口及其相关信息批量快速地导入到用例库中,并自动生成符合规范的API测试用例。目前支持Swagger导入用例cURL导入用例方式。

  • Swagger导入用例支持输入Swagger URL从Swagger中批量导入API测试文档中已经维护的接口信息。

  • cURL导入用例支持从浏览器(如chrome、safari)中复制请求为cURL格式,并将其粘贴进图中的命令行中即可。

  • 执行API测试用例

执行API测试用例时,需选择API测试用例,并支持选择API测试任务-任务配置页面已经维护好的任务配置,同时支持在此基础上进行修改,或者直接输入各项配置。

执行配置中设置的参数支持用于此次执行的所有用例,避免重复多次的维护相同的用例信息。

API测试任务

API测试任务是某些特定用例的集合(这里可以是产品的某个版本中的API测试用例,或者是其中某个功能块的API测试用例的集合);从API测试用例库中选择用例创建API测试任务成功后,便能以API测试任务为整体来执行该任务。此外,应用流水线中也集成了API测试任务,从而实现了API测试的自动化执行。

  • 创建API测试任务

创建API测试任务时,需选择API测试用例,作为API测试任务中执行的对象。支持选择API测试任务-任务配置页面已经维护好的任务配置,同时支持在此基础上进行修改,或者直接输入各项配置作为此任务的通用配置。

任务配置中设置的参数支持用于API测试任务中执行的用例,避免重复多次的维护相同的用例信息。

  • API测试任务记录

API测试任务菜单下,可查看所有API测试任务的执行记录,除此之外,还支持查看直接通过执行用例而产生的用例执行的记录。

测试记录中包含了两部分,分别是:执行概览与执行结果详情;

1. 执行概览:其中包括记录的编号、执行结果、执行者、开始时间、执行耗时、用例通过率、执行成功的用例数、执行失败的用例数。
2. 执行结果详情:即每个用例的执行详情查看;其中包括:用例请求的基本信息(请求方式、URL)、用例执行状态、开始时间、执行耗时、断言的通过情况、请求头、请求体、状态码、响应头以及响应体。

  • 任务配置管理

任务配置用于为执行用例或执行API测试任务提供基础的配置,其中包括:全局请求头配置、全局请求配置、授权管理配置以及用户变量配置,以此来避免在多个用例中频繁重复地配置这些参数。

  • 流水线中集成API测试任务

流水线中API测试任务目前仅支持Choerodon商业版能选择。当API测试任务触发后,会立刻执行选中的测试任务。

注意:该类型的CD任务仅Choerodon商业版可用。

  • 选择添加此类型任务后,首先需要填写任务名称、配置触发分支;触发分支的匹配方式支持:分支类型匹配、正则匹配、精确匹配以及精确排除。
  • 选择API测试任务:此处仅支持选择项目下已有的API测试任务。

总结

持续测试是DevOps流程中重要的一环,而API测试能帮助实现测试前移,从而帮助团队降低测试成本,更快地发现缺陷与问题。

关于猪齿鱼

Choerodon猪齿鱼作为全场景效能平台,是基于的Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷,持续交付,容器环境,微服务,DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而转变,更替代地交付更稳定的软件。

更多内容

大家可以通过以下社区途径了解Choerodon猪齿鱼文档,最新动态,产品特性:

【Choerodon官网】

https://choerodon.io/zh/

【汉得开放平台】

https://open.hand-china.com/

【汉得开放论坛】

https://openforum.hand-china.com/

也可以加入Choerodon猪齿鱼官方社区用户交流群,交流猪齿鱼使用心得,Docker,微服务,K8S,敏捷管理等相关理论实践心得,群同步更新版本更新等信息,大家可以加群讨论交流。

①-Choerodon猪齿鱼官方交流(已满);

②-Choerodon猪齿鱼官方交流(可加);【微信号发至客服邮箱[email protected],运营小伙伴拉您入官方交流群】

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 16 分钟阅读

当今激烈的商业竞争中,企业中的服务和产品需要更快速的版本迭代和高质量的软件交付,同时减少完成项目所需的成本和时间,不少企业引入了DevOps概念来提升软件研发交付效率。DevOps是开发和运营的结合,代表着一种文化和实践,强调了软件开发人员(Dev)和信息技术(IT)运营与维护(O&M)专业人员(Ops)的协作和交流,同时促进了软件交付和基础架构变更。它旨在建立一种文化和环境,使软件构建,测试和发布可以更加方便,频繁和可靠地进行。DevOps中的测试是自动化的,不同于传统的手工测试,自动化测试通过测试工具或者框架,录制编写测试脚本,对软件功能进行测试,能够快速检测错误并查找可能对用户体验产生负面影响的问题,从而更快的发布高质量产品。

本文通过介绍自动化测试体系概念,带你了解自动化测试在实现高质量产品方面的重要作用。具体内容如下:

  • 什么是自动化测试
  • 为什么要进行自动化测试
  • 手工测试和自动化测试之间的区别
  • 自动化测试如何与DevOps相适应
  • Choerodon猪齿鱼如何进行自动化测试

什么是自动化测试?

自动化测试是使用工具、脚本和软件对重复、预定义的操作来执行测试用例的过程。由于自动化测试是通过自动化工具完成的,因此在增加总体测试覆盖率的同时,它在探索性测试中花费的时间更少,在维护测试脚本时花费的时间更多。

自动化测试的基本概念是测试金字塔。它演示了如何解决项目的自动化测试:构成金字塔基础的哪些部分首先要进行测试,以及在金字塔最后阶段剩下什么?

按照测试金字塔的模式,首先是单元测试层,即开发人员在编写代码时经常执行的代码测试。然后是API测试所属的服务器层。稍后,当前端完成时,将进行UI测试。

图:三层测试自动化金字塔

自动化测试的类型

  • 冒烟测试: 针对每个版本或每次需求变更后,在正式测试前,对产品或系统的一次简单的验证性测试;
  • 单元测试: 对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作;
  • 集成测试: 是组装软件的系统测试技术,按设计要求把通过单元测试的各个模块组装在一起之后,进行综合测试以便发现与接口有关的各种错误;
  • 功能测试: 是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求,比如说逻辑功能测试,界面测试,易用性测试,安装/卸载测试,兼容性测试等;
  • 性能测试: 通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
  • 回归测试: 指修改了旧代码后,重新测试以确认修改没有引入新的错误或导致其他代码产生错误;
  • 数据驱动测试: 一种在软件测试过程中使用的方法,用于描述直接测试的输入、可验证输出的条件表,以及测试环境的设置还有控制编码的过程;
  • 黑盒测试: 又称为功能测试、数据驱动测试或基于规格说明书的测试,是一种从用户观点出发的测试主要测到的错误类型有:不正确或遗漏的功能;接口、界面错误;性能错误;数据结构或外部数据访问错误;初始化或终止条件错误等等。

为什么要进行自动化测试?

自动化测试是软件开发生命周期的重要组成部分, 主动修复错误需要对基础代码进行的每个小更改都进行测试和重新测试。随着时间的流逝,回归测试的数量将会增加,测试人员将承受很大的压力,而创新和增长的时间会越来越少。此外,至少有四个因素导致测试成本上升:

  • 跨设备、系统和平台进行测试的需求不断增加。 将测试范围从例如一个Web浏览器扩展到两个或扩展到包含移动设备会影响工作量。
  • 测试用例的数量不断增加。 随着每次产品更新,涵盖更多功能所需的测试用例数量都会增加。新功能会影响需要重新测试的现有功能;常见的回归测试问题。

  • 发布管道的成熟。 团队不希望仅进行一次回归测试,而是希望在发布管道的多个阶段运行测试。这有助于为开发人员提供最快的反馈,但同时也需要大量测试。
  • 管理层希望增加发布数量。 为了保持其最新产品的市场地位,企业希望确保软件质量并更快速的迭代产品。 面对测试成本的增加,为了改变测试不可持续的局面,团队可以引入自动化测试以减轻测试人员的重复、不可预测、繁琐的任务。

通过自动化测试可以带来以下好处:

  • 提高生产率: 可以高精度执行更多测试,产品功能测试的范围更广;
  • 快速反馈: 在软件开发生命周期(SDLC)中更快,更早地执行测试时,反馈也可以更快地提供给开发人员;
  • 加快产品版本迭代: 更快的测试执行和连续的反馈循环可以缩短总体SDLC,并提高发布频率;
  • 成本效率::优化资源后,可以降低成本;
  • 更高的敏捷性和市场响应能力: 较短的发布周期使企业可以更好地响应变化并确定资源的优先级;
  • 降低人为错误的风险: 自动化测试可满足回归测试需求,将人为错误的风险降到最低;
  • 提高交付质量: 高效测试可最大程度地扩大测试范围,提高产品质量;
  • 更高的工作满意度: 由于消除了高度重复的任务,测试人员可以体验到更高的工作满意度。

手动和自动化测试之间的区别

在快速且连续的产品开发中,手动测试是验证终端用户工作流程的最有效方法。但实际情况是,手工测试并不能完全做到重测每个功能,持续测试工作中需要编写快速且频繁运行的自动化测试,找出生产版本中的缺陷。

通过以下对比,让我们来了解测试工作中手工测试与自动化测试之间的区别:

特征手动测试自动化测试
准确性和可靠性精度低,手动测试更容易出现人为错误使用工具和脚本的准确性很高
所需时间手动测试比自动化慢,手动运行测试耗时多自动化运行测试用例的速度明显快于人力资源
投资成本成本低初始成本比手动测试高
用法适用于探索性,可用性和临时测试适用于回归测试,性能测试,负载测试
体验首次使用手动测试执行测试用例很顺利,但面对频繁变化的需求,捕获回归缺陷能力有限能快速适应代码频繁更改的测试

自动化测试如何与DevOps相适应

DevOps中持续测试是软件产品交付管道中执行自动化测试的过程,其目的是获取有关最新构建或预发布的版本中业务风险的快速连续反馈。然后,可以使用此信息来确定软件产品是否已准备好在任何给定时间通过交付管道进行升级。由于测试提早开始并连续执行,因此减少了发现和修复缺陷所需的时间和精力,可以提高交付高质量软件(满足对可接受风险水平的期望的软件)的速度和频率,并减少技术负担。

持续测试包括对功能需求非功能需求的验证,均与自动化测试有关。对于功能测试,持续测试通常涉及单元测试,API测试,集成测试和系统测试非功能性测试涉及诸如静态代码分析,安全性测试,性能测试等实践。

Choerodon猪齿鱼如何进行自动化测试

Choerodon猪齿鱼目前支持的自动化测试有:API测试、性能测试、流量回归测试、UI测试,允许测试人员通过关键测试信息来完成测试操作,无需编程。

ChoerodonAPI测试模块通过集成Jmeter,实现了API用例的添加、归集、管理与执行的功能。其中支持基于接口URL或Swagger文档快速编排接口测试用例,而导入或添加API测试用例的整个过程免代码编写,技术门槛低,适合敏捷团队中各个角色使用。

Choerodon性能测试也是通过集成Jmeter测试工具,支持用户在已有的测试任务基础上调整执行参数(线程数、预热时长、循环数)来对系统的各项性能指标进行测试,从而发现性能瓶颈与性能缺陷,以便更好地优化系统或产品的整体性能。

Choerodon流量回归测试适用于:批量录制产品界面操作并将得到的用例进行集中管理,以便后续进行批量的回归测试。此功能通过使用Goreplay录制产品界面中的操作生成流量文件,然后将其导入Choerodon平台生成用例进行管理与执行。

ChoerodonUI测试适用于:测试人员通过插件录制web应用的界面操作,生成对应的测试用例与步骤;而后便能直接执行对应的测试文件来对界面UI操作进行测试。

结论

自动化测试能够提高测试人员的工作效率并且优化测试速度,提高软件产品的准确性和稳定性,代替人工完成各种业务场景,使资源最大化利用,增加软件的信任度。希望以上关于自动化测试的概念对你有所帮助。

关于猪齿鱼

Choerodon猪齿鱼作为全场景效能平台,是基于的Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷,持续交付,容器环境,微服务,DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而转变,更替代地交付更稳定的软件。

更多内容

大家可以通过以下社区途径了解Choerodon猪齿鱼文档,最新动态,产品特性:

【Choerodon官网】

https://choerodon.io/zh/

【汉得开放平台】

https://open.hand-china.com/

【汉得开放论坛】

https://openforum.hand-china.com/

也可以加入Choerodon猪齿鱼官方社区用户交流群,交流猪齿鱼使用心得,Docker,微服务,K8S,敏捷管理等相关理论实践心得,群同步更新版本更新等信息,大家可以加群讨论交流。

①-Choerodon猪齿鱼官方交流(已满);

②-Choerodon猪齿鱼官方交流(可加);【微信号发至客服邮箱[email protected],运营小伙伴拉您入官方交流群】

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。