文摘

适当地实现web服务的性能,必须给它一个全面的测试。尽管一个弹性测试可以在传统的云测试系统,保证地理测试,支持真正的用户行为模拟仍然是一个问题。在本文中,我们提出一个基于众包模式测试系统进行分布式自动测试目标web服务器上。拟议中的crowdsourcing-based测试系统(CTS)提供了一个可靠的测试模型来模拟真实用户网页浏览行为在web浏览器的帮助下分散在世界各地。为了使整个测试过程的实际情况,提出了两种测试模式来模拟真实的用户活动。通过评估每一个资源自动的web服务,一个测试人员不仅可以发现内部问题也理解web服务的性能。此外,完整的地理测试与性能测量来自世界上不同地区。几个实验来验证执行CTS的功能和可用性。它说明了CTS是一个完整的和可靠的web服务测试系统,它提供了独特的功能,满足不同的需求。

1。介绍

宽带网络技术的发展,分布式系统和应用程序在面向服务的社会导致了巨大的变化。网络技术的发展,面向服务的应用程序已经成为我们日常生活不可或缺的一部分。rest式服务,它使用HTTP作为它的底层协议,被认为是现在最常见的和重要的形式的web应用程序(1]。通过使用一个可读的URL,人民有能力访问各种资源在互联网上,如网页、图片、视频文件,和多样化的信息资产。至于提供web服务的系统,它是不可避免的处理来自世界各地的成千上万的用户请求。如果web服务器的设计不是完美的,它将导致低性能,然后影响用户体验。因此,对于服务生命周期的阶段,每一个系统都应该正确测试之前被实现为一个服务。测试程序验证系统的性能是否足够好来满足用户的功能和可用性。

Web服务测试是软件测试的一种Web服务器上执行一系列测试如回归测试,性能测试,负载测试2- - - - - -4在特定的条件下)。web服务测试的帮助下,测试人员可以意识到web服务的弱点,提高缺陷。目前,web服务测试可分为两种形式,即:、单节点测试和云测试(5]。对于单节点测试,测试生成和执行本地终端或局域网内环境。通常,一堆线程将创建和使用进行测试任务像真实用户。然而,大多数web服务需要处理大量请求,限制数量的线程会很难模拟这样一个大规模的测试。至于云测试,也称为testing-as-a-service (taa),该测试利用云计算技术。测试服务将被安装在一个虚拟机,每个数据中心部署在位于世界各地的。然而,云测试以来地理考试的一些问题数量有限的全球数据中心并不足以构建环境与全球用户的实际情况相同。

众包(6,7最近]是一种新颖的分布式问题解决和生产模式,近年来也出现了新一代的信息技术。它是一个过程获得的想法通过寻求大量的人,志愿者或兼职员工,提供各种各样的能力,旨在实现一个更好的结果比传统的方式。一般来说,我们可以把众包作为一个虚拟的劳动力市场8),利用先进的互联网技术将工作外包给个人。因为工人是一大群人来自世界各地,使得有可能保持一个灵活的规模和产生不同的结果。基于众包的概念,因此,本文试图设计和实现一种新型的测试场景,不仅可以深入的核心结构一个web服务器来发现潜在的瓶颈也执行可靠的测试与真正的全球用户的行为。

在这篇文章中,一本小说名叫CTS crowdsourcing-based自动检测系统。的力量crowd-joining模型,我们利用全球终端用户提供的计算节点进行一系列的测试,比如性能测试、可用性测试、和地理测试。在CTS, web浏览器作为测试的接口节点负责之间的交互测试服务器端和目标web服务器。通过使用这个模型,测试人员可以节省他们的时间建立一个测试环境,减少主机的工作负载。因此我们的设计注重效率、可靠性、成本最小化和易用性。我们提出了自动测试系统的主要贡献如下:(1)真正的用户行为仿真能力。一般来说,传统的测试工具和服务专注于生成工作负载来测试web服务器与他们自己的测试基础设施。虽然它可以模拟用户请求使用并发线程,这种模拟不够好就像一个真正的用户的方式在网页浏览行为。在拟议的系统中,我们设计一个可靠的测试模型来模拟真实用户网页浏览行为在web浏览器的帮助下分散在世界各地(2)地理测试保证。与地理测试,测试人员能够执行web服务测试基于位置的服务(LBS) [9),能够使用最终用户的地理位置信息,提供相应的服务。该系统测试服务部署大量web浏览器与众包分布世界各地。通过这种方式,它不仅能真正支持地理测试,还进行大规模的负载测试,这是很难在单节点完成测试和云测试(3)全面的资源评价。模拟测试工作负载生成的传统测试服务是无法评估的功能和可用性最终用户实际获得的资源。即使可以添加额外的资源,测试人员还需要配置一个接一个或手动编写一些脚本。因此,为了找到真正的目标服务器的弱点和问题,提出了系统的目的是达到目标域中的每个资源都可以遍历和评估(4)提供详细的测试结果。该系统提供了两种测试模式对不同的测试目的,即。,覆盖模式和模拟模式。我们提供详细和可靠的测试结果通过采用该模式,使测试人员清楚地了解目标系统的总体形势

本文的其余部分如下:相关作品中描述的部分2。部分3介绍了CTS的设计,包括概念架构和测试模式。节4,说明了系统实现。一些实验来验证提出的可用性测试执行服务部分5。同时,讨论拟议中的模式之间的比较是在本节中给出。最终,这项工作中描述的结论部分6。

2。相关的工作

为了评估性能和web服务的能力,一个可靠的web服务测试方法是至关重要的。web服务测试的早期研究主要集中在自动化软件测试(10),测试创建和使用目标软件自动安装在一个单一的节点。之后,测试结果,关于错误的信息,收集和记录服务的使用不同的测试用例。一般来说,单节点测试工具创建大量的线程模拟并发请求到测试服务器。例如,Apache JMeter [11)是一个著名的web服务测试工具中创建大量线程模拟多个访问请求同时单个节点。它使测试人员验证web服务的正确性在高负载和衡量他们的表现。类似地,Httperf [12)是另一个web服务性能测试工具,提供了一个灵活的工具用于创建多个类型的HTTP负载。

云测试(13,14)是一个新兴模式的测试,利用云环境的大量资源向消费者提供测试服务。它被视为一种服务,它使用一个云计算平台部署在云基础设施之上的测试服务。由于云计算技术的优势,弹性资源配置、成本效率和高可用性,云测试解决现有的一些问题等单节点测试的使用有限的预算,成本高,用户的地理分布。使用云测试技术,测试人员可以灵活与分布式测试环境,模拟真实的用户执行大量的测试任务没有维持昂贵的硬件,并增加或减少计算资源根据测试要求。

SOASTA [15]和LoadStorm [16)工业云测试性能测试工具。他们提供很好的web GUI测试人员配置测试计划与测试平台。所有测试请求被发送通过虚拟机分散在全球的数据中心。测试完成后,测试人员可以查看结果从这些虚拟机直接收集。使用这些工具,测试人员可以随时随地按需执行自动化测试,开展大规模实时评价与一个可伸缩的web服务测试环境。最近,一些云测试服务也在学术界学者提出的。朱和张17)提出了一个协同测试的测试框架通过各种测试服务的协作任务已完成注册,发现,在运行时调用。为了提高web应用程序的负载测试的质量和性能,Shojaee et al。18)提出了一个云中的方法使用现有设施。没有初始成本的计算资源池,无限的数据存储、云计算和管理程序都集成提高负载测试的灵活性,时间和运营成本。燕et al。19)也选择web服务测试目标和发展一个负载测试平台,使负载测试过程要尽可能接近实际运行场景。在他们的设计,数量的并发请求和测试代理的地理分布是可定制的。然而,他们的taa平台开发基于云平台即服务(PaaS),因此,测试场景和测试客户端定制的灵活性是不确定的。增加测试客户端定制和测试场景的灵活性,Lo et al。20.)提出了一个IaaS-based云服务测试框架能够充分适应不同的通用测试目标和保证测试环境的灵活性。用户可以自定义测试场景涉及客户、网络拓扑结构和测试脚本。

虽然弹性测试可以保证在云测试服务上面所提到的,地理测试支持仍然是一个问题。VM的可用位置限制由于数据中心的分布属于IaaS提供商(例如,亚马逊)。另一方面,测试流可能受到的实际行为和政策的云服务提供商。vm迁移可能是由于测试正在进行根据云服务提供商的资源管理策略。来解决这个问题,我们提出一种新颖的在本文通过部署web服务测试系统测试服务众多web浏览器与众包分布世界各地。通过这种方式,该系统不仅能真正支持地理测试,还进行大规模的负载测试,这是很难在单节点完成测试和云测试。此外,可以保证可靠的测试模型来模拟真实用户网页浏览行为在web浏览器的帮助下分散在世界各地。

3所示。系统设计

本节提供了一个概述和详细的概念提出了CTS crowdsourcing-based自动检测系统。本研究的主要目的是为web服务提供者提出参考平台测试和指定关键资源问题在他们的云服务。CTS的概念性架构和提出测试模式部分中所示3.1和3.2,分别。

3.1。概念架构

图1显示的概念架构提出了CTS web服务自动检测系统。它包含以下四个角色:(1)测试服务。测试服务基本上是需要测试的目标web服务(2)测试人员。测试人员是一个web开发人员希望找出问题发展网站或主管愿望理解web服务的性能。在概念架构,测试人员是一个基于浏览器的客户端组件在CTS负责指定相关的所有配置与测试平台测试和沟通,比如提交测试请求和检索的测试结果。此外,测试人员能够监测过程在测试运行时。CTS提供了一个简洁的web界面使测试人员设置所有参数在一个简单的方法和快速启动测试。此外,测试人员可以很容易地获得的试验结果的详细结果页面的网站评价的目的(3)测试节点。测试节点由最终用户自愿加入众包的测试。基本上,用户只需要登录到CTS试验节点,测试将由CTS自动进行。在概念体系结构中,客户端组件的测试节点也是一个基于浏览器的CTS的实际执行者的测试计划。测试节点负责与测试平台,如接受测试任务和发送测试结果。作为测试节点接收到测试任务时,它将生成工作负载测试服务根据分配的测试模式。然后,它将收集目标服务的反应指标和测试结果转发到测试平台(4)测试平台。测试平台的服务器端组件负责管理所有信息和连接的客户端组件:即。,测试人员和测试节点。一旦收到测试要求测试人员测试平台,它首先解析请求,并将所有测试需求的测试计划。然后,它收集的可用数量测试节点和部署相应的测试节点根据测试计划进行测试。此外,测试平台还负责所有测试结果从测试节点存储到数据库中

3.2。测试模式

在拟议的CTS系统中,测试人员和测试节点的客户端需要登录到测试平台,服务器端负责,接受测试的要求,部署测试任务,收集测试结果,并将测试结果存储到数据库中。为了使CTS可靠和完全足够,两种测试模式提出了在客户端进行测试,即。毯子模式和模拟模式。提出测试模式不仅使测试人员能够设计自己的测试与测试需求有效但也加强测试节点的能力,进行彻底的测试目标服务。以下部分描述提出的两个测试模式。

3.2.1之上。毯子模式

该模式的目的是自动执行至少一个测试所有资源都位于相同的目标测试服务器的域。通过使用这种模式下,测试人员可以找出错误背后的现有web服务器和理解web服务器的详细状况。在覆盖模式,测试人员应该首先设置的配置测试要求,包括提供输入测试服务的URL,这种测试的测试深度和叶资源的数量在每一层需要被测试。测试平台之后,将创建一个测试计划为这个特定的测试要求和选择合格的测试节点。然后,测试平台将部署测试任务对应的测试节点,等待每一个测试结果从不同的测试节点。

测试节点的毯子的工作流模式如图2。一旦测试节点接收到测试任务,它将证实测试配置的内容。然后,测试节点开始生成测试流从设定的测试条目URL。每一层,测试节点将解析URL和爬行的响应身体每个测试资源在同一水平上找到更多的可用资源(R)属于域的测试web服务器。如果有可用资源,测试节点将随机选择一个给定数量的叶资源设定的测试人员在配置目标资源(T)测试节点将选中的资源到另一个测试任务并继续做同样的测试场景。测试工作流将迭代地进行,直到没有更多的资源可以在某种程度上或当前级别数(N)到达测试人员安排的深度(D)。对于每个测试资源,测试节点将测试结果发送回服务器端CTS,如性能指标、时间戳、状态代码和国家代码指示测试节点的位置。

3.2.2。模拟模式

仿真的设计模式位于测试场景的想法像真实用户浏览网站的方式。通过使用这种模式,测试节点生成测试流量通过模拟用户行为,以便测试人员能够检查目标服务器的状态在一个现实世界的情况。此外,我们提出两个额外的类型在这种模式下基于用户行为的两个属性浏览网页:跳和时间。跳的行动转移从一个网页到另一个web页面。时间表示持续时间用户花在浏览特定网站。因此,希望模拟模式能模拟真实的用户行为根据多少啤酒花用户将同时浏览特定网站。时间模拟模式将模拟真实用户行为根据用户将多少次花在浏览特定网站。

在刚开始的时候,测试人员也应该设置的配置测试要求,包括提供输入测试服务的URL、啤酒花的数量虽然选择仿真类型作为跳,或模拟输入时的持续时间是时间。测试平台之后,将创建一个测试计划为这个特定的测试要求和选择合格的测试节点。然后,测试平台将部署测试任务对应的测试节点,等待每一个测试结果从不同的测试节点。

测试节点的工作流仿真模式类似于毛毯模式。然而,对于resource-selecting阶段,测试节点只会选择一个资源在每个水平测试在这种模式下。此外,它需要等待11秒开始下一个测试流程。操作模拟符合用户浏览行为的研究基于眼动跟踪web页面(21]。研究表明,用户平均需要11秒前在一个web页面切换到另一个web页面。最后,完成整个测试的条件取决于什么类型的模拟。跳的仿真模式,测试过程将终止当完成测试流程的数量等于啤酒花设定的测试人员的数量。模拟模式,整个测试将不会停止,直到过程期间持续时间设定的测试人员。

4所示。系统实现

提出了系统的总体软件架构图所示3,设计了两个主要模块:服务器端和客户端。服务器端模块中数据收集器和服务提供者的角色,也负责与客户端会话管理和信息交换;客户端模块负责用户界面的表示,与服务端通信,测试管理在不同的测试模式。服务器端模块使用节点的实现。js (22)构建的核心组件,包括一个事件控制器,测试经理,节点管理器,HTTP服务器和数据库服务器。客户端模块由一个客户端控制器,资源解析器,和测试处理程序,由JavaScript和HTML5实现。

4.1。服务器端模块

节点。js是用来完成服务器端模块的功能,因为它是轻量级的和有效的在设置后端环境中使用大量的嵌入式模块和第三方模块。此外,节点。js利用事件驱动和非阻塞I / O模型,这使得它有效的处理各种各样的连接问题。一些核心组件的客户端模块详细描述如下:(1)事件控制器。对于面向服务的系统,必须处理各种来自最终用户的请求。为了解决服务器端和客户端之间的通信,我们利用第三方WebSocket模块(23从最终用户)来管理所有连接。除了常见的事件相关的连接,我们还定义自己的事件来处理各种各样的互斥事件引发的客户端或暗示的服务器端。其中一些事件相关的工作任务,其中一些是用来帮助节点管理器和测试经理执行服务命令或过程不同的通知。事件控制器将采取相应的行动立即按照特定事件名称只要确认测试或测试的任何事件节点。名为“test_request”为例,一个事件将触发测试经理准备部署测试任务时,一个事件称为“node_info”将传输的信息测试节点到节点管理器更新节点列表,和一个“test_result_query”事件从测试人员将寻找一个特定的测试结果数据库中根据给定的测试ID(2)节点管理器。节点管理器负责管理节点和测试人员进行测试。每个节点上放置备用工作任务将被保存到一个列表。一些关于各类节点信息将由这个模块,包括身份证、操作系统、浏览器类型、地理位置、估计带宽。除了节点信息管理、节点管理器负责选择可用测试节点请求按照测试的要求和提供的信息选择测试节点测试经理。只要测试任务准备和提供合适的测试节点的请求从测试经理发表,节点管理器将首先检查当前节点的数量以保证其正确性。然后,节点管理器将从节点列表中选择相应的测试节点之间的平衡的政策下节点每个节点的利用率和负载平衡(3)测试经理。测试经理处理任何请求相关的功能测试。测试任务对象将被创建并被推到一个测试列表中为测试请求触发事件时。所有参数在测试配置将存储在测试任务。测试经理是不可或缺的组成部分,因为它不仅管理所有测试任务要求不同测试人员也相应的测试节点部署所有测试任务。一旦事件控制器接收一个测试要求一个测试人员,测试配置形式在测试请求将被转移到测试经理。然后,测试经理将命令测试节点来执行他们的测试流根据指定的测试模式后获得可用的实例测试节点的节点管理器。当测试任务正在进行中,测试经理负责监督测试进度的任务和收集所有测试结果从不同的测试节点发回(4)Http服务器。我们利用表达模块提供的软件包管理器的节点。js实现平台的主机。表达提供了一个薄层web应用程序的基本功能,这使得它容易处理常见的web应用程序,如反应POST和GET、基本身份验证,cookie操作。此外,简单的语法表达简化实现的复杂性。Http模块负责构建web服务提供者环境和扮演的角色。它提供了一个接口,使最终用户能够获得测试平台,验证有效用户来自世界各地(5)数据库服务器。各种数据的存储,我们选择MongoDB [24作为我们的平台的数据库。MongoDB是一个面向文档的数据库也归类为NoSQL数据库。通过使用类json文档与所谓的BSON格式,它使数据操作更有效率和更容易。数据库服务器是节点的支持下实现的。js模块可以连接到MongoDB服务器和采取行动等传统数据库插入、更新、删除和查询在数据库服务器上。我们创建三个文件存储所有信息在线测试的目的节点,测试内容和测试结果。测试人员能够获取测试结果的帮助下数据库模块

4.2。客户端模块

客户端模块是一个web应用程序提供了一个接口测试人员和测试节点的加入,成为我们平台的一个成员。开发人员可以登录目标测试服务器上测试人员进行测试。为测试节点,终端用户欢迎来自世界各地参加我们的测试平台和贡献他们的空闲计算资源来帮助进行有价值的和有意义的测试任务。以下组件大多是用现代web技术实现CSS等静态布局,JavaScript处理的动态功能测试、收费和HTML5的静态和动态特性。(1)客户端控制器。该组件是分为两个部分:控制网络与服务器端接口和消息交换。界面控制部分,我们使用html 5和CSS来构造界面。测试人员可以清楚地理解如何操作功能标签,要么导致测试人员做测试的配置和提交请求或提供测试人员测试结果的仪表板。动态操作和交互表示依靠JavaScript和jQuery的技术。消息交换部分,使用此模块与服务器端进行通信的WebSocket协议(25]。测试人员和测试节点一起都需要初始化客户端实例和连接到事件控制器。控制器连接到事件发生后,客户端控制器将继续等待消息从事件控制器和转发的测试数据(2)资源解析器。负责资源解析器解析响应的测试资源获得更多的资源位于目标服务器,然后为下一阶段生成另一个测试任务。我们在这个组件实现一个网络爬虫。下面的描述将实施分为四个步骤:(一)首先,组件将继续分析每个响应文本发送单独的测试资源为了解析更多的超链接到测试处理程序完成一定的测试任务(b)超链接的资源解析器将URL规范化在第一步,发现的过程将相对URL转换为绝对URL。然后,它明星选择资源位于域归一化目标服务器的url(c)在这个阶段,重复资源以及那些被测试将从列表中被淘汰。此外,在当前任务目标资源将被记录为目的的未来删除处理过程(d)在最后一步,目标资源在候选人资源将决定然后放入另一个测试任务接下来的测试过程(3)测试处理程序。测试处理程序负责生成测试流发送HTTP请求发送到目标服务器。该模块实现通过使用Web Worker (26HTML5内指定,它在后台执行不会扰乱了正常运行的浏览器。测试流程的一部分,我们使用一个Web API称为Xmlhttprequest (27)发送每个http请求跨源资源共享的机制(歌珥)[28]。每个测试流启动时,测试处理程序将计算每个测试资源的性能度量响应到达之前。除此之外,每个请求的状态代码可用响应头。200意味着目标资源的代码可以访问成功。超时的地位也可以测量与超时时间设置为30秒。测试流程是响应文本终于到了,然后测试处理程序将响应文本转发给资源解析器,将所有检索到的数据,包括时间戳,状态代码,和性能结果,目标资源的测试结果,并将测试结果发送回服务器端

5。实验结果和讨论

在本节中,我们进行三个实验的目的是验证功能和评估我们的CTS crowdsourcing-based自动检测系统的可用性。提出下的实验测试模式:模式和模拟模式。通过这些实验,我们的目标是识别独立测试模式,使测试结果之间的区别。覆盖率的测试结果包含状态、性能测量、地理测量,和错误报告。性能测量包括三个测量,例如,延迟,响应时间和处理时间。起始时间的延迟意味着时间要求的到达时间响应。响应时间是指往返时间(RTT)之间的测试节点和目标服务器。处理时间从延迟,通过减法和响应霜代表的访问时间回应的结果。在实验中,来自10个国家的30名志愿者被邀请参加CTS试验节点。测试的目标服务是博物馆国立交通大学图书馆提供的服务(29日]。在这个实验中,测试是不同的模式进行不同的配置。全面的详细的实验结果模式,与跳模拟模式,模拟模式随着时间的推移介绍部分5.1,5.2,5.3,分别。部分5.4将讨论CTS的可用性在两种测试模式三个实验的结果。

5.1。毯子模式

第一个实验是在毯子下面模式进行。在测试配置,测试节点数量设置为20,和深度的值和叶资源数量都指定为30。目标服务的主要web页面使用的条目URL整个实验。表1的测试结果显示模式的命中率。在测试期间,被发现在目标服务器上的资源总数是1343,和1337年资源测试。的命中率是99.55%,几乎覆盖整个领域的目标服务器。

表2给三个平均的统计性能度量。整体测量,平均延迟时间是188.81毫秒的最小和最大值2 ms和9761 ms。的响应时间、最大是31063 ms,最低是3。在平均水平,它要求3189.12毫秒完成测试任务。处理时间的情况相当一样的响应时间。大约需要3秒加载的内容资源。

数据4- - - - - -6显示层模式的平均地理测量结果来自10个国家的延迟,响应时间和处理时间。从图4,结果从台湾执行最好的与各国18.31毫秒的延迟,而来自瑞典导致延迟最高为630.19 ms。除此之外,从亚洲国家广泛excel在延迟相比其他大陆国家。图5显示的区域评价响应时间。我们可以看到,大多数国家都至少需要1秒在访问一个资源。特别是,美国和韩国的性能不符合性能延迟。响应时间是5871.55和4287.67女士女士对美国和韩国,分别,这是超过其他国家所需的时间。然而,新加坡演出(270.19 ms)和台湾(48.25 ms)压倒其他地区。图6给出了概述根据不同国家的平均处理时间。至于平均处理时间,它几乎是一样的响应时间。美国最高的一个是5644.21毫秒,和台湾仍执行最好的29.94毫秒。

图7显示测试节点的分布和超时请求。原因导致区域之间的差异取决于测试节点的数量在一个地区和每个测试节点实际达到的水平。在这个实验中,美国大多数测试启动的国家(2306年),和测试节点生成最小测试从瑞典(139)。至于测试超时,超时的案件有531来自7个国家。韩国(130)和美国(339)国家超时。超时的原因可能由于距离等情况下,资源的大小,和带宽。

表3列表中存在的错误和异常结果的例子目标服务器,包括未找到,禁止访问,和重定向问题。重定向问题意味着它无效时做重定向浏览器发送请求基于安全问题。在这个实验中,我们发现有5个资源不可用,1错误造成的访问被禁止和11例外由于重定向问题。

5.2。模拟模式与跳

第二个实验与模拟仿真模式下进行类型作为跳。我们选择20个测试节点来模拟真实用户行为探索web内容基于web页面之间的切换时间。啤酒花的数量设置为18,配置基于用户行为的研究在网页浏览Leslie et al。30.]。他们的研究表明的平均数量在一个特定的网站上浏览网页的用户是18岁。因此,我们的实验的结果更接近实际情况。

表4显示了测试结果的模拟模式跳的命中率。在测试期间,被发现在目标服务器上的资源总数是238,和101年资源测试。的命中率是42%。表5给出了统计三个平均绩效评估指标的模拟模式跳。整体测量,平均延迟时间是620.49毫秒的最小和最大值6和9833女士,女士。的响应时间、平均是936.34毫秒。最大值是10430 ms,最小值是7,女士不一样高,在毯子的实验模式。处理时间,所有测试节点可以接收响应文本在6秒,平均315.84毫秒。

数据8- - - - - -10显示的平均地理测量的结果模拟模式从10个国家。图8表明,来自台湾的评估(187.19 ms)、澳门(274.89 ms)比那些来自其他国家。最高的延迟是瑞典(1244.83 ms)和澳大利亚(1253.64 ms)。延迟在所有地区有一个上升趋势相比,第一个实验的结果。图9显示的地理测量响应时间。从德国获得的往返时间(1530.97 ms),巴西(1616.39 ms)和澳大利亚(1590.61 ms)提出了相同的结果。最高的一个出现在瑞典女士(1992.22)。测量在别人大多是1秒。对于不同国家的平均处理时间,人物10表明,测量从亚洲国家如日本女士(65.69),新加坡(129.78 ms)和韩国(145.22 ms)相当低,巴西(1037.44 ms)的性能是最差的。

图11说明了测试节点的分布和超时请求。在这个实验中,至少测试启动的地区是瑞典(18),巴西(18)、澳门(18)和测试节点执行测试大部分来自美国(72年)。至于测试超时,有0超时的情况也发生在任何国家。这表明目标服务器可以保留某些优质服务最终用户的情况下在这个实验。此外,只有1访问被禁止的错误在这个实验发现表中列出6。

5.3。模拟模式随着时间的推移

最后一个实验是模拟模式下进行仿真类型随着时间的。通过这个实验,我们生成上下文的基础上停留时间,用户花在浏览一些web服务器的内容。有20个测试节点用于执行脚本模拟真实用户的行为。从研究的结果由莱斯利等。30.),这表明平均浏览一个网站的时间是9分钟。因此,我们让运行间隔设置为9分钟。通过这种方式,实验的环境会更接近实际情况。

表7显示了测试结果的模拟模式随着时间的推移,命中率。在测试期间,被发现在目标服务器上的资源总数是259,和121年资源测试。的命中率是46.72%。表8给出了统计三个平均绩效评估指标的仿真模式随着时间的推移。对整个测量,平均延迟611.46毫秒的最小和最大值13457 ms和ms。的响应时间、最大价值是15340 ms和最小值是8毫秒。响应时间和处理时间的平均值是942.18和330.72女士,女士。基本上,结果类似于那些在第二个实验中。

数据12- - - - - -14显示的平均地理测量的结果与时间从10个国家模拟模式。从图12,结果从台湾和澳门是最好的与158.06毫秒的延迟和162.7毫秒,分别在所有国家,而从瑞典导致延迟最高为1633.63 ms。此外,德国的延迟值(813.99 ms),巴西(885.96 ms)和澳大利亚(799.42 ms)差不多,大约有800 ms。图13显示的地理测量响应时间。我们可以看到,条件相当一样的延迟。来自日本的结果(571.07 ms)、韩国(808.61 ms),和新加坡(559.45 ms)落在中间的地方。然而,瑞典女士(2550.68)仍然是地区用户获得最糟糕的经验。图中所示的平均处理时间14,评估的国家位于亚洲的表现比那些来自其他国家。值得什么巴西女士(804.18)是在低性能显然处理时间。最好的结果来自于台湾(43.15 ms)。

在这个实验中,如图15,该地区最测试发射是在美国(111)、和测试节点执行最少的测试来自瑞典(19)。实际上,甚至测试分布在大部分地区。没有超时情况发生在所有国家都在实验中。是一样的,在第二个实验中,代表稳定的服务提供到目标服务器,和用户能够顺利探索的内容。有4个错误被发现在这个实验中,表中列出9。

5.4。讨论

实验结果在不同的测试模式表明,该测试系统CTS可以做一个完整的测试在目标服务器上。在本节中,我们将讨论四个能力的系统和提出的可用性测试模式根据三个实验的结果。

5.4.1之前。资源评价

依照测试结果在命中率方面,我们的目标来评估每一个资源的目标服务器的毯子下真正实现模式和模拟模式。测试人员可以查看所有的测试资源的协助下提供的可视化图CTS。命中率是关键点来验证每个结果的完整性。命中率越高,范围越大的测试目标服务。图16显示的比较测试资源的数量和三个实验间的命中率。的实验结果,毯子模式显示了更高比例的测试资源总发现资源比,通过两个实验的模拟模式。毯子的原因是模式,多个资源将被放入测试任务在每个层面上,且只有一个模拟模式的资源将被评估。因此,如果测试人员的目的是执行一个全面的测试,覆盖模式是合适的方法来满足需求。

5.4.2。性能测量

图17显示了测试结果的对比下的性能测量实验。它可以发现,延迟的结果,响应时间,和处理时间似乎是相同的测试在模拟模式下运行时类型跳和时间,这意味着该系统可以满足实际需求状况通过模拟真实用户的网络浏览活动。结果在毯子下面模式进行的,它会导致很长时间花在处理测试节点和目标服务器之间的响应数据虽然更低的延迟。原因在于,有大量的测试流生成的测试节点在同一时间。此外,他们中的大多数是图像和视频文件的大小非常大,目标服务器需要消耗大量的计算资源和花更多的时间在获取这些文件在不同的磁盘扇区和转发。此外,测试节点间带宽速度和距离的因素和目标服务器也可能导致过高的测量。超时的结果还表明,测试节点从几个国家不能够成功地获得整个响应数据在一段时间。因此,适用于测试人员给负载测试或压力测试使用的毯子模式,而模拟模式可以用来了解实时的状态情况。

5.4.3。地理测试

高分布和强大的贡献全球人群,测试人员可以收集大量的测试数据提供的测试节点从几个国家,这使得测试平台,分析不同表现基于测试节点的位置。通过示范地理分布测量和请求,实验显示不同的结果。结果对某些国家中保持相同的实验。然而,一些国家的排名的性能可能会发生戏剧性的变化。这种差异源于两个条件:第一个是测试节点的数量分布在每个国家。如果有测试节点的分布不均,导致的结果可能是不可靠的。我们可以看到,美国和日本的请求数量远远超过其他国家,如瑞典和新加坡在第一个实验中。这种情况下可能会导致相反的结果由于分布不平衡的要求。另一个条件是由于每个测试节点将获得不同数量的资源。测试可用资源将从测试节点来测试不同节点在每个级别。 Some test nodes might finish the entire test early if no more resource can be found, and some would run the complete process according to the test configuration. These cases are more possible to happen in the blanket mode since more than one resource would be put into the test task randomly. Figure18显示测试请求和超时毯子的分布模式。它可以发现,有531个超时情况下在毯子来自7个国家模式,而没有超时情况发生在所有国家在模拟的实验模式。结果,如果测试人员执行地理测试,使用模拟模式可以满足这样的要求,更适合于毛毯的使用模式。

5.4.4。错误检测

除了服务能力的评价、测试平台也配备的能力识别错误隐藏在目标服务。根据实验结果,有些问题确实存在,但在测试服务。几个可用的资源不是由于失效链接或不正确的路径名。此外,资源标识符的表达有问题,容易被利用的目标用户,也通过实验发现。

此外,结果说明了一些例外,发生在访问资源的过程。在实验中,大多数资源标识符的异常,由于重定向。因为我们将HTTP请求发送到目标服务器的支持下跨源资源共享(歌珥),有一些限制和问题与歌珥。大多数web浏览器是不允许而使用歌珥请求处理重定向条件,原因就是安全问题。没有任何安全保障的未知位置响应头内的资源表示,web浏览器需要取消接触任何风险的重定向。此外,响应头没有访问控制的迹象也将被视为无效的请求歌珥的规范。这些网络错误分为例外。

图19显示结果的比较发现错误和异常在不同的测试模式。它可以发现更多的错误检测到使用毯子模式比使用模拟模式。原因是更多的资源评估和综合测试可以用毯子模式进行。因此,测试人员可以选择使用毯子模式如果他们期待完整的错误检测结果。

6。结论

提出了一种新颖的分布式crowdsourcing-based CTS测试系统,以确保目标web服务的自动测试。CTS构造一个可靠的测试平台通过众包,测试人员能够在全球部署web服务测试web浏览器。CTS中提出了两种测试模式:毛毯模式是用来给一个广泛的测试所有的资源都保存在目标服务器上的模拟模式能够提供类似人类的情况下为了使拟人化测试实际情况。为了验证功能和可用性的CTS,几个实验正在进行。实验结果表明,该系统能够使目标服务器上的一个完整的测试和测试模式可以深入评估目标服务。它还表明,CTS web服务测试系统是一个完整的、可靠的,它提供了独特的功能,满足不同的需求,执行可用性测试、性能测试、可伸缩性测试、和地理测试。

不可避免的是,目前,志愿者加入我们的实验的数量并不足以形成相当大的规模与众包的概念模型。因此,为了利用全球用户的能力和更有效的测试,在未来,我们必须筹集更多的激励措施来提高我们的服务的普及和促进其强大的功能。

数据可用性

使用的数据来支持本研究的结果包括在本文中。

的利益冲突

作者宣称没有利益冲突。

确认

这项工作是支持的基金从中国的国家自然科学基金(批准号61702102和61702102)和福建省自然科学基金(批准号2018 j05100)和部分由科学技术部(大多数)的台湾(授予107 - 2623 - e - 009 - 006 d)。