网页测试方法和装置与流程

文档序号:11654176阅读:247来源:国知局
网页测试方法和装置与流程

本申请涉及软件测试领域,尤其涉及一种网页测试方法和装置。



背景技术:

在实际应用中,技术人员通常会为可配置系统开发配置页面,用户可以通过浏览器登录所述配置页面,对所述可配置系统的参数等信息进行配置。以deepcache系统管理页面为例,deepcache系统管理页面是针对deepcache高速缓存加速系统的管理页面,用户可以通过浏览器登录deepcache系统管理页面,对deepcache高速缓存加速系统的部分参数进行配置等。deepcache系统管理页面中的各功能组件(例如:文本框、下拉框等)是否能正常工作是十分重要的,将直接影响用户的使用。目前,技术人员可以提前对所述功能组件进行功能测试,以检查各功能组件是否能正常工作。

相关技术中,在进行功能测试时,通常需要技术人员手动进行一次测试,网页测试工具可以记录技术人员对deepcache系统管理页面进行手动测试时执行的动作,例如:开启浏览器、登录页面、在某个文本框中输入数值并点击确定按钮等,并根据记录到的动作生成对应的测试脚本,后续网页测试工具可以基于所述测试脚本对deepcache系统管理页面进行自动测试。然而,一旦需要新增或删除某项功能测试,则需要技术人员重新对deepcache系统管理页面进行手动测试,以生成新的测试脚本,可扩展性差,且增加了人力成本。



技术实现要素:

有鉴于此,本申请提供一种网页测试方法和装置,以解决相关技术中针对待测试网页的测试可扩展性差的问题。

具体地,本申请是通过如下技术方案实现的:

第一方面,本申请提供一种网页测试方法,所述方法包括:

根据用户的功能测试指令,从预存的测试用例库中选取一个或多个测试用例添加至测试套件;

基于所述测试套件对待测试网页进行功能测试。

第二方面,本申请提供一种网页测试装置,其特征在于,所述装置包括:

用例选取单元,用于根据用户的功能测试指令,从预存的测试用例库中选取一个或多个测试用例添加至测试套件;

功能测试单元,用于基于所述测试套件对待测试网页进行功能测试。

分析上述技术方案可知,网络设备可以根据用户的功能测试指令所指定的测试用例,对待测试网页进行自动测试。采用这样的方式,用户仅需预先配置所要进行的功能测试,而无需对所述待测试网页进行手动测试,简化了网页测试的过程。如果需要新增或删除某项功能测试,则用户重新配置所要进行的功能测试即可,也无需重新对所述待测试网页进行手动测试,提高了网页测试的可扩展性,也节省了人力成本。

附图说明

图1是deepcache系统管理页面的一种示例;

图2是本申请一示例性实施例示出的一种网页测试方法的流程图;

图3是本申请一示例性实施例示出的一种网页测试装置所在设备的硬件结构图;

图4是本申请一示例性实施例示出的一种网页测试装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中,技术人员在对待测试网页进行功能测试时,可以先开启浏览器,并在浏览器的地址栏中输入所述待测试网页的网址,从而在浏览器中运行并显示所述待测试网页。当所述待测试网页显示在浏览器中后,技术人员可以根据所述待测试网页中所包括的功能组件的类型,对所述待测试网页进行手动的功能测试。

以deepcache系统管理页面为例,deepcache系统管理页面可以提供身份验证功能,因此技术人员可以先基于用户名和密码验证页面进行身份验证。在身份验证通过后,技术人员可以对显示在浏览器中的deepcache系统管理页面进行手动的功能测试。

请参考图1,为deepcache系统管理页面的一种示例。在deepcache系统管理页面中,通常包括有列表框101、文本框102、下拉框103、单选框104四种功能组件。技术人员可以分别针对这四种功能组件进行功能测试,以检查各功能组件是否能正常工作。举例来说,技术人员可以在用于配置最小缓存资源大小的文本框中输入100至102400这个取值范围内的一个数值,并点击确定按钮(图中未示出),以向deepcache高速缓存加速系统下发对应的配置指令。如果后续技术人员检查到所述系统中的最小缓存资源大小的参数值变为输入的数值,则说明该文本框处于正常工作状态;如果技术人员检查到所述系统中的最小缓存资源大小的参数值未变为输入的数值,则说明该文本框未处于正常工作状态。

网页测试工具(如seleniumide等)可以记录技术人员对待测试网页进行手动测试时执行的动作,例如:开启浏览器并在浏览器地址栏输入网址、登录页面、在某个文本框中输入数值并点击确定按钮等,并根据记录到的动作生成对应的测试脚本,后续网页测试工具可以执行所述测试脚本,以模拟技术人员对所述待测试网页进行手动测试时所执行的动作,从而可以实现对所述待测试网页自动测试,而无需技术人员再次进行手动测试。

然而,由于所述测试脚本通常无法由技术人员手动修改,因此如果需要新增或删除某项功能测试,则需要技术人员重新对所述待测试网页进行手动测试,网页测试工具可以更新所述测试脚本,再基于更新后的测试脚本对所述待测试网页进行自动测试。

举例来说,为了简化用户的配置过程,删除了deepcache系统管理页面中的单选框104,而将所有类型的配置项列举在单一页面中,则相应地,也需要在原先生成的测试脚本中删除针对单选框的功能测试,以避免误报错。此时,需要技术人员重新对所述待测试网页进行手动测试,网页测试工具可以重新记录技术人员所执行的动作,并根据重新记录到的动作生成对应的测试脚本,后续网页测试工具可以基于重新生成的测试脚本对deepcache系统管理页面进行自动测试。

此外,如果网页测试工具生成的测试脚本存在错误,例如:网页测试工具误将技术人员的双击动作记录为单击动作,就会生成错误的测试脚本,后续无法基于生成的测试脚本对待测试网页进行正确的测试。

综合来看,相关技术中,对待测试网页进行功能测试所采用的方式,存在可扩展性差,准确度也不够高的问题。

与相关技术类似,本申请技术方案在对待测试网页进行功能测试时,也需要先开启浏览器,并在浏览器的地址栏中输入所述待测试网页的网址,从而在浏览器中运行所述待测试网页。与相关技术不同的是,本申请技术方案中,这些动作都是通过执行技术人员预先编写的测试脚本模拟实现的,而无需技术人员对所述待测试网页进行手动测试。当某项动作无法正常实现或者发生变化时,例如:当待测试网页的网址发生变化时,技术人员可以修改、完善预先编写的测试脚本,从而使该动作得以正常实现,提高了网页测试的准确度。

如下为基于seleniumwebdriver(网页测试工具)并采用python(编程语言)编写的测试脚本的部分代码的一种示例:

self.driver=webdriver.firefox()

self.driver.implicitly_wait(10)

self.base_url="https://10.121.15.251"

driver=self.driver

driver.get(self.base_url)

login.login(self)

其中,“self.driver=webdriver.firefox()”用于开启火狐浏览器,“self.base_url="https://10.121.15.251"”用于在火狐浏览器中运行deepcache系统管理页面,“login.login(self)”用于登录deepcache系统管理页面。

假设待测试页面为deepcache系统管理页面,则通过执行上述部分代码,即可实现浏览器的开启,以及待测试网页的运行。

后续,本申请技术方案可以根据用户(或技术人员)的功能测试指令所指定的测试用例,对所述待测试网页进行自动测试。其中,所述测试用例也可以是由技术人员预先编写的测试脚本,用于对功能组件进行功能测试。这样,可以由用户自行选择需要对待测试网页进行的功能测试,大大提高了网页测试的可扩展性。

请参考图2,为本申请一示例性实施例示出的一种网页测试方法的流程图。所述方法可以应用在网络设备上,包括如下步骤:

步骤201:根据用户的功能测试指令,从预存的测试用例库中选取一个或多个测试用例添加至测试套件。

步骤202:基于所述测试套件对待测试网页进行功能测试。

在本实施例中,技术人员在为每一种功能组件编写好对应的测试用例后,可以将所有的所述测试用例保存至测试用例库中。

网络设备可以为用户提供功能测试的配置页面,用户可以通过所述配置页面提前选择需要对待测试网页进行的一项或多项功能测试,并点击所述配置页面中的确认按钮,以确认完成对功能测试的配置。网络设备在检测到用户点击确认按钮的动作后,可以视为接收到功能测试指令,并确定用户所选择的各项功能测试。后续,网络设备可以从所述测试用例库中,选取所述各项功能测试分别对应的测试用例,并将所述测试用例添加至测试套件中。

具体地,网络设备在所述功能测试指令是局部功能测试指令时,可以将所述局部功能测试指令指定的测试用例添加至所述测试套件。举例来说,假设用户选择的功能测试仅为文本框测试和单选框测试,则网络设备可以将这两项功能测试所对应的测试用例添加至所述测试套件。

如下为基于seleniumwebdriver并采用python编写的测试脚本的部分代码的另一种示例:

testunit=unittest.testsuite()

testunit.addtest(testradiobutton_media("test_unabled"))

testunit.addtest(testradiobutton_media("test_enabled_by_day"))

testunit.addtest(testradiobutton_media("test_enabled_by_week"))

其中,“testunit=unittest.testsuite()”用于创建测试套件,后三行代码均可以用于将测试用例添加至创建的测试套件中。

此外,网络设备还可以在所述配置页面中为用户提供全局功能测试选项,当用户需要对所述待测试网页进行全局的功能测试时,可以选择所述全局功能测试选项,并点击所述确认按钮。网络设备在确定用户的功能测试指令为全局功能测试指令时,可以在预设的第一存储地址内查找测试用例,并将查找到的测试用例添加至所述测试套件。其中,所述第一存储地址可以为所述测试用例库的存储地址。

如下为基于seleniumwebdriver并采用python编写的测试脚本的部分代码的另一种示例:

其中,“test_dir='.\\test_case'”用于定义可供查找的文件夹,该文件夹对应的存储地址即为所述第一存储地址。“discover=unittest.defaulttestloader.discover(test_dir,pattern='test*.py',top_level_dir=none)”用于在所述存储地址内查找文件名为test*.py形式的测试脚本文件,并将这些测试脚本文件作为测试用例。后五行代码则可以用于将查找到的测试用例添加至所述测试套件。

网络设备在完成浏览器的开启和所述待测试网页的运行后,可以执行所述测试套件,从而可以根据用户所选择的功能测试,对所述待测试网页进行功能测试。

在实际应用中,网络设备可以按照各测试用例之间的执行次序,从所述测试套件中选取一个测试用例作为当前测试用例。其中,所述执行次序可以由技术人员预先设置,也可以根据各测试用例添加至所述测试套件的时间排列,即较早添加至所述测试套件的测试用例的执行次序在前,较晚添加至所述测试套件的测试用例的执行次序在后。网络设备在选取出当前测试用例后,可以基于所述当前测试用例对所述待测试网页进行功能测试,并将所述当前测试用例从所述测试套件移除。在完成所述当前测试用例的执行后,网络设备可以继续从已移除所述当前测试用例的测试套件中重新选取一个测试用例作为新的当前测试用例,这样可以避免测试用例的重复执行,造成设备性能的浪费和测试时间的增加。

为了保证测试用例之间的独立性,避免测试用例之间互相干扰,导致误判,网络设备可以在基于所述当前测试用例对所述待测试网页进行功能测试后,对所述待测试网页进行初始化处理。具体地,网络设备可以在完成所述当前测试用例的执行后,退出所述待测试网页,并关闭浏览器。后续,网络设备可以重新开启浏览器,并重新运行所述待测试网页,以基于重新选取出的当前测试用例对所述待测试网页进行功能测试。

为了使测试结果对于用户而言更加直观可见,网络设备还可以根据所述测试套件中各个测试用例的测试结果生成测试报告,并将所述测试报告保存至预设的第二存储地址,以供用户查看。需要说明的是,用于存储测试报告的所述第二存储地址与用于存储测试用例的前述第一存储地址不同。

如下为基于seleniumwebdriver并采用python编写的测试脚本的部分代码的另一种示例:

其中,“filename='e:\\result.html'”用于定义测试报告的保存路径,该保存路径对应的存储地址即为所述第二存储地址,后四行代码则可以用于定义生成的测试报文的格式。

在本实施例中,所述测试报告可以包括测试执行时刻、测试执行时长、测试用例名称、测试结果等信息。其中,测试结果可划分为三类:pass(测试用例通过)、fail(测试用例没有通过)、error(测试用例的执行过程中出现了错误)。网络设备可以以不同颜色显示这三类测试结果,例如:pass为绿色,fail为棕黄色,error为红色,从而使展示给用户的测试报告更为直观。网络设备还可以将测试用例划分不同类别,例如:将针对列表框的测试用例划分为一类,将针对文本框的测试用例划分为另一类别,以此类推。网络设备在将测试报告展示给用户时,可以将同一类别的测试用例和对应的测试结果设置为可折叠或展开,从而使所述测试报文更为简洁、清晰。此外,网络设备还可以分别统计各类测试结果所对应的测试用例的数量,并将统计结果展示给用户。

由上述实施例可见,网络设备可以根据用户的功能测试指令所指定的测试用例,对待测试网页进行自动测试。采用这样的方式,用户仅需预先配置所要进行的功能测试,而无需对所述待测试网页进行手动测试,简化了网页测试的过程。如果需要新增或删除某项功能测试,则用户重新配置所要进行的功能测试即可,也无需重新对所述待测试网页进行手动测试,提高了网页测试的可扩展性,也节省了人力成本。

与前述网页测试方法的实施例相对应,本申请还提供了网页测试装置的实施例。

本申请网页测试装置的实施例可以应用在网络设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在网络设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图3所示,为本申请网页测试装置所在网络设备的一种硬件结构图,除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的网络设备通常根据该网页测试的实际功能,还可以包括其他硬件,对此不再赘述。

请参考图4,为本申请一示例性实施例示出的一种网页测试装置的框图。所述网页测试装置400可以应用于图3所示的网络设备中,包括:

用例选取单元401,用于根据用户的功能测试指令,从预存的测试用例库中选取一个或多个测试用例添加至测试套件;

功能测试单元402,用于基于所述测试套件对待测试网页进行功能测试。

在一个可选的实施例中,所述用例选取单元401可以包括:

第一选取子单元4011,用于当所述功能测试指令是局部功能测试指令时,将所述局部功能测试指令指定的测试用例添加至所述测试套件;

第二选取子单元4012,用于当所述功能测试指令是全局功能测试指令时,在预设的第一存储地址内查找测试用例,并将查找到的测试用例添加至所述测试套件。

在另一个可选的实施例中,所述功能测试单元402可以包括:

第三选取子单元4021,用于按照各测试用例之间的执行次序,从所述测试套件中选取一个测试用例作为当前测试用例;

功能测试子单元4022,用于基于所述当前测试用例对所述待测试网页进行功能测试,并将所述当前测试用例从所述测试套件中移除,以继续从所述测试套件中重新选取一个测试用例作为当前测试用例。

在另一个可选的实施例中,所述装置400还可以包括:

初始化单元403,用于在基于所述当前测试用例对所述待测试网页进行功能测试后,对所述待测试网页进行初始化处理。

在另一个可选的实施例中,所述装置400还可以包括:

报告生成单元404,用于根据所述测试套件中各个测试用例的测试结果生成测试报告,并将所述测试报告保存至预设的第二存储地址。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。

对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1