CN116795679A - 一种Web应用测试方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明实施例适用于计算机技术领域，提供了一种Web应用测试方法、装置、电子设备及存储介质，其中，Web应用测试方法包括：基于设定选择器定位待测试应用的目标元素；待测试应用为Web应用；基于目标元素生成至少一个页面元素模块；每一个页面元素模块表征待测试应用的一个测试页面对应的目标元素的集合；基于页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例；组织至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件；执行至少一个测试脚本文件，对待测试应用进行测试。

Description

一种Web应用测试方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种Web应用测试方法、装置、电子设备及存储介质。

背景技术

相关技术在生成测试脚本时，通常是采用将测试数据和具体业务逻辑融合在一起的脚本编写方式。这种方式编写出的测试脚本，在测试场景发生变化时，测试脚本的修改工作量大。且因重新定位目标元素会产生代码冗余，不方便后期维护。

发明内容

为了解决上述问题，本发明实施例提供了一种Web应用测试方法、装置、电子设备及存储介质，以至少解决相关技术测试效率低的问题。

本发明的技术方案是这样实现的：

第一方面，本发明实施例提供了一种Web应用测试方法，该方法包括：

基于设定选择器定位待测试应用的目标元素；所述待测试应用为Web应用；

基于所述目标元素生成至少一个页面元素模块；每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合；

基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例；

组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件；

执行所述至少一个测试脚本文件，对所述待测试应用进行测试。

在上述方案中，所述基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例，包括：

基于数据驱动模式确定所述至少两个测试用例中的各个测试用例的驱动数据；

基于所述页面元素模块中的目标元素的属性值、所述驱动数据和所述测试页面的各个功能模块的业务逻辑，生成所述测试页面的各个功能模块对应的至少两个测试用例；所述测试页面包括至少一个功能模块；

对应地，所述组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件，包括：

将同一个功能模块对应的至少两个测试用例部署在同一个测试脚本文件中，其中，该测试脚本文件中的每一个测试用例对应一种测试场景。

在上述方案中，所述生成各个测试页面对应的至少一个测试脚本文件，包括：

在执行结果为异步的测试用例对应的测试脚本文件中设置断言超时时间。

在上述方案中，所述组织所述至少两个测试用例，包括：

基于钩子Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作。

在上述方案中，所述基于Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作，包括：

若第一测试用例的执行依赖于第二测试用例的执行结果，则基于所述Hook函数设置所述第一测试用例的依赖条件；所述依赖条件表征所述第二测试用例的执行结果；所述至少两个测试用例包括：所述第一测试用例和所述第二测试用例。

在上述方案中，在基于设定选择器定位待测试应用的目标元素之前，所述方法还包括：

基于所述待测试应用的技术栈确定所述设定选择器；所述设定选择器与所述待测试应用的技术栈对应。

在上述方案中，在生成各个测试页面对应的至少一个测试脚本文件之后，所述方法还包括：

配置所述待测试应用对应的配置文件的第一参数；所述第一参数表征各个页面元素模块对应的测试脚本文件的路径；

对应的，所述执行所述至少一个测试脚本文件，对所述待测试应用进行测试，包括：

获取待测试应用对应的配置文件中的第一参数；

基于所述第一参数执行所述至少一个测试脚本文件。

第二方面，本发明实施例提供了一种Web应用测试装置，该装置包括：

定位模块，用于基于设定选择器定位待测试应用的目标元素；所述待测试应用为Web应用；

第一生成模块，用于基于所述目标元素生成至少一个页面元素模块；每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合；

第二生成模块，用于基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例；

第三生成模块，用于组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件；

执行模块，用于执行所述至少一个测试脚本文件，对所述待测试应用进行测试。

第三方面，本发明实施例提供了一种电子设备，包括处理器和存储器，所述处理器和存储器相互连接，其中，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行本发明实施例第一方面提供的Web应用测试方法的步骤。

第四方面，本发明实施例提供了一种计算机可读存储介质，包括：所述计算机可读存储介质存储有计算机程序。所述计算机程序被处理器执行时实现如本发明实施例第一方面提供的Web应用测试方法的步骤。

本实施例基于设定选择器定位待测试应用的目标元素，基于目标元素生成至少一个页面元素模块，每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合。基于页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例。组织至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件。执行至少一个测试脚本文件，对待测试应用进行测试。与相关技术将数据和具体业务逻辑融合在一起的脚本编写方式相比，本实施例以页面元素模块的形式组织目标元素，将测试页面涉及的目标元素归并到同一个页面元素模块中，可以实现测试数据和业务逻辑的分离。由于页面元素模块中只有目标元素，不包含具体的测试数据和业务逻辑，当页面设计发生更改时，我们只需要维护页面元素模块中的目标元素。针对Web设计或内容变化的场景，只需维护数据脚本即可，可以减少因定位目标元素的代码冗余，方便后期维护。

附图说明

图1是本发明实施例提供的一种Web应用测试方法的实现流程示意图；

图2是本发明实施例提供的一种Web应用测试流程的示意图；

图3是本发明实施例提供的一种脚本文件生成流程的示意图

图4是本发明实施例提供的一种web应用自动化装置的示意图；

图5是本发明实施例提供的一种Web应用测试装置的示意图；

图6是本发明一实施例提供的电子设备的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

Web应用是一种可以通过Web访问的应用程序，Web应用的最大好处是用户很容易访问应用程序，用户只需要有浏览器即可，不需要再安装其他软件。在Web应用领域，随着产品功能越来越丰富，版本迭代越来越快，为了能够提高产品的可靠性，需要对Web应用进行测试。

相关技术基于Selenium对Web应用进行自动化测试，Selenium是一个用于Web应用程序测试的工具，Selenium的技术原理是通过与浏览器建立通信，测试脚本通过WebDriverAPI发送HTTP请求至浏览器驱动，浏览器驱动接收HTTP请求后，基于其中内置的HTTP server服务端转换成对应的操作指令，根据上述操作指令对浏览器进行操控，然后浏览器将对应的操作结果返回给浏览器驱动。这种测试方法需要浏览器安装WebDriver，而且不同内核的浏览器需要安装不同的WebDriver。在对多个浏览器同时进行测试时，需要启动多线程或者多个容器，否则无法在多个浏览器下并行执行。由于需要在不同的浏览器安装不同的WebDriver，而且测试脚本与被测应用程序需要经历域名解析、三次握手等繁琐的交互过程，使得测试效率较低。

其次，相关技术在生成测试脚本时，通常是采用将测试数据和具体业务逻辑融合在一起的脚本编写方式。这种方式编写出的测试脚本，在测试场景发生变化时，测试脚本的修改工作量大。且因重新定位目标元素会产生代码冗余，不方便后期维护。

针对上述相关技术的缺点，本发明实施例提供了一种Web应用测试方法，能够提高测试效率。为了说明本发明所述的技术方案，下面通过具体实施例来进行说明。

图1是本发明实施例提供的一种Web应用测试方法的实现流程示意图，所述Web应用测试方法的执行主体为电子设备，电子设备包括台式电脑、笔记本电脑和服务器等。在实际应用中，该Web应用测试方法可以应用在浏览器中，直接在电子设备终端执行测试命令，即可打开浏览器执行本实施例的测试步骤。

参考图1，Web应用测试方法包括：

S101，基于设定选择器定位待测试应用的目标元素；所述待测试应用为Web应用。

这里，待测试应用是Web应用，用户可以通过浏览器访问Web应用。

选择器用于定位目标元素的代码所在位置，比如目标元素为一个用于输入账户信息的登陆框，选择器可以定位该登陆框的代码在HTML文件中的位置。选择器的类型有很多，例如，在层叠样式表(CSS，Cascading Style Sheets)中，目标选择器有“:target”。

在一实施例中，在基于设定选择器定位待测试应用的目标元素之前，所述方法还包括：

基于所述待测试应用的技术栈确定所述设定选择器；所述设定选择器与所述待测试应用的技术栈对应。

本实施例根据待测试应用使用的技术栈，确定设定选择器定位待测试应用的目标元素。例如，如果是使用原生JS开发的网页，则可以基于CSS选择器或测试脚本文件的JS代码定位目标元素；对于使用类似React或者Vue前端框架的网页，则可以基于特定于框架的实体Selector定位目标元素，例如使用React的组件树或Aurelia的元素绑定定位目标元素。针对通过Selector机制不容易获取到的信息，比如当前网页地址中的锚点、窗口的滚动位置、视图的宽度、偏移量、主机名称等信息，本实施例因为测试脚本文件与待测试应用运行在同一环境，因此可使用ClientFunctionAPI获取待测试应用的环境信息，该方式使得目标元素的获取不再仅能根据Selector选择器，使得测试脚本内容更灵活。

S102，基于所述目标元素生成至少一个页面元素模块；每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合。

本实施例按照页面元素模块的形式组织待测试应用的目标元素，将一个测试页面所涉及的目标元素都归并到一个集合中，这个集合称为页面元素模块。待测试应用可以包括多个测试页面，每个测试页面对应一个页面元素模块，每一个页面元素模块中存储有该测试页面涉及的目标元素。

这样做的目的是为了实现数据和业务逻辑的分离，本实施例以页面元素模块的形式组织目标元素，页面元素模块中只有目标元素，不包含具体的测试数据和业务逻辑。当页面设计发生更改时，我们只需要维护页面元素模块中的目标元素。针对Web设计或内容变化的场景，只需维护数据脚本即可，可以减少因定位目标元素的代码冗余，方便后期维护。

S103，基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例。

在页面元素模块中，只存储有目标元素的属性值，不包含具体的测试数据和业务逻辑。属性值包括：目标元素的类型、名称、尺寸、外观、字体样式等。

根据测试需求，根据目标元素的属性值配置目标元素，包括对目标元素设置事件、填充驱动数据以及设置断言，以此生成测试用例。例如，目标元素为登陆框，根据登陆框的属性值为该登陆框配置驱动数据，比如一个驱动数据为“用户名123456，密码111111”。其中，驱动数据可以为覆盖所有测试场景，按照类型规则生成的JSON文件。

这里，由测试需求决定具体生成多少个测试用例，针对测试页面中的一项功能，可以生成多个测试用例。一个测试页面可以对应多个测试用例，这些测试用例归属于1个或多个测试脚本文件，其中每个测试脚本文件可以对测试页面中的一个功能进行测试，比如登陆框的登陆功能。

在一实施例中，所述基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例，包括：

基于数据驱动模式确定所述至少两个测试用例中的各个测试用例的驱动数据；

基于所述页面元素模块中的目标元素的属性值、所述驱动数据和所述测试页面的各个功能模块的业务逻辑，生成所述测试页面的各个功能模块对应的至少两个测试用例；所述测试页面包括至少一个功能模块；

对应地，所述组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件，包括：

将同一个功能模块对应的至少两个测试用例部署在同一个测试脚本文件中，其中，该测试脚本文件中的每一个测试用例对应一种测试场景。

本实施例以数据驱动模式构造驱动数据，编写测试场景相同仅驱动数据不一致的测试用例，实现一个测试脚本文件覆盖多个测试场景的需要，一个测试脚本文件使用不同的驱动数据来执行，驱动数据和测试行为进行了完全的分离，这样的测试脚本设计模式称为数据驱动。

一个测试页面包括至少一个功能模块，比如一个测试页面中包括登陆功能模块和注销功能模块，每一个功能模块都可以通过测试脚本文件来对其进行功能测试。

在本实施例中，一个驱动数据对应一个测试用例，测试脚本文件包括多个测试用例，测试脚本文件中的每个测试用例都对应一种测试场景。比如登陆功能模块，不同用户的登陆功能的业务逻辑是相同的，不同的是输入的用户的身份信息，用户的身份可以是管理员，可以是普通用户，也可以是会员用户，其中每一种类型的用户身份都对应一种测试场景。登陆功能可以用一个测试脚文件本来测试，该测试脚本文件中可以包括多个测试用例，每一个测试用例对应一种类型的用户身份，在执行测试脚本文件时，可以实现一个测试脚本文件完成多种类型的用户身份的登陆测试。

在实际应用中，可以通过Mock构造尽可能多的驱动数据，以便覆盖更多的使用场景。

本实施例使用数据驱动模式设计测试用例，一个测试逻辑可以供多条驱动数据复用，代码复用率高，避免编写重复代码。数据与测试脚本文件分离，某条测试用例失败时不会影响其他测试用例，异常排查效率高。

S104，组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件。

测试用例是为实施测试而向被测试应用提供输入数据、操作、各种环境设置以及期望结果的一个特定的集合，测试脚本文件由若干个测试用例组成，通过页面元素模块对应的测试用例，可以生成该页面元素模块对应的测试脚本文件。

一个测试页面可以对应多个测试脚本文件，每个测试脚本文件可以对应多个测试用例，将至少两个测试用例中归属于同一个测试脚本文件的测试用例组织到一起，得到一个测试脚本文件。比如针对测试页面中的某一个功能模块，该功能模块对应一个测试脚本文件，该功能可以由该测试脚本文件中的多个测试用例来测试。

在一实施例中，所述生成各个测试页面对应的至少一个测试脚本文件，包括：

在执行结果为异步的测试用例对应的测试脚本文件中设置断言超时时间。

断言(assertion)是一种在程序中的一阶逻辑(如：一个结果为真或假的逻辑判断式)，目的为了表示与验证软件开发者预期的结果，当程序执行到断言的位置时，对应的断言应该为真。若断言不为真时，程序会中止执行，并给出错误信息。

在同步功能测试中，可以在测试操作之后立即执行断言。但是Web上的有些功能测试是异步的，这意味着不能在用户操作之后立即得到预期的效果。

例如，在页面到达最终状态之后，被测试的页面可能需要一些时间向服务器发送请求以获取所需的数据，或者由用户执行操作来调用动画。所有这些间隔时间都不能预先计算，因为它们取决于各种因素，比如计算机性能、网络连接速度等。

在这种情况下，如果在测试操作之后立即执行断言，就会得到一个不确定的结果，至少是不稳定的。因此要使得异步功能测试更加稳定，就需要添加断言超时时间。

本实施例在测试脚本文件中配置断言超时时间，在执行测试用例时如果得到异步执行结果，在断言超时时间内对异步执行结果进行验证。

验证包括：将实际的结果与预期的结果通过断言方法对比，比如是否符合预期的类型，是否包含了某个DOM节点，节点个数是否相同等。

在断言超时时间内对异步执行结果进行验证，如果断言没有通过，测试不会立即失败。在这之后，断言多次重试传递，如果在断言超时期间断言无法验证成功，则测试失败。

通过增加断言超时时间，降低了网络、环境等对测试结果的影响。

在一实施例中，所述组织所述至少两个测试用例，包括：

基于钩子Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作。

本实施例通过钩子函数(API Hook)设置测试用例的执行环境，包括设置测试用例的前置执行操作和/或后置执行操作，还包括设置每条测试用例执行结束后的初始化状态。比如，一个测试用例的前置执行操作是点击登录按钮，则可以通过Hook函数设置该点击操作，在执行该测试用例时，通过Hook函数自动触发该点击操作。

在一实施例中，所述基于Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作，包括：

若第一测试用例的执行依赖于第二测试用例的执行结果，则基于所述Hook函数设置所述第一测试用例的依赖条件；所述依赖条件表征所述第二测试用例的执行结果；所述至少两个测试用例包括：所述第一测试用例和所述第二测试用例。

这里，第一测试用例和第二测试用例具有嵌套关系，即第一测试用例的执行依赖于第二测试用例的执行结果，也就是说在执行第一测试用例时，必须要先执行第二测试用例得到执行结果，才能执行第一测试用例。这样测试用例无法进行独立测试，多个关联的测试用例需要全部执行，这样影响了测试效率。而且不便于测试用例的维护，对某个测试用例进行维护，也要同时维护其他关联的测试用例。

本实施例通过Hook函数设置第一测试用例的执行环境，比如设置第一测试用例的初始页面URL、执行结束后的初始化状态、前置执行操作或后置执行操作。第一测试用例的执行依赖于第二测试用例的执行结果，所以通过钩子函数设置第二测试用例的执行结果，在第一测试用例执行时，通过Hook函数获取第二测试用例的执行结果，而不用第二测试用例真正去执行。

这样可以使得每个测试用例“模块化”，测试用例之间进行逻辑隔离，测试用例可以独立进行测试，而不依赖于其他测试用例，提高了测试效率。而且在对测试用例进行维护时，只需要维护当前测试用例，不需要同时维护多个测试用例，便于测试用例的维护。

在实际应用中，还可以使用Hook在路由拦截中使用用户角色机制指定当前测试的用户角色，实现用户角色的任意切换，实现对于不同权限用户的测试要求。

每个测试脚本文件执行结束后，都会初始化测试用例规定的状态，可以通过钩子函数指定多个测试用例的公共逻辑，比如指定测试组中所有测试用例的起始页面。

S105，执行所述至少一个测试脚本文件，对所述待测试应用进行测试。

通过上述步骤，可以得到各个测试页面对应的至少一个测试脚本文件，通过执行其中一条或多条测试脚本文件，可以对待测试应用的功能进行测试。

在执行测试脚本文件对待测试应用进行测试时，首先通过页面元素模块确定测试脚本文件对应的目标元素，然后通过设定定位器定位目标元素，最后根据测试用例中的驱动数据对目标元素进行测试。

本实施例基于设定选择器定位待测试应用的目标元素，基于目标元素生成至少一个页面元素模块，每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合。基于页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例。组织至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件。执行至少一个测试脚本文件，对待测试应用进行测试。与相关技术将数据和具体业务逻辑融合在一起的脚本编写方式相比，本实施例以页面元素模块的形式组织目标元素，将测试页面涉及的目标元素归并到同一个页面元素模块中，可以实现测试数据和业务逻辑的分离。由于页面元素模块中只有目标元素，不包含具体的测试数据和业务逻辑，当页面设计发生更改时，我们只需要维护页面元素模块中的目标元素。针对Web设计或内容变化的场景，只需维护数据脚本即可，可以减少因定位目标元素的代码冗余，方便后期维护。

在一实施例中，在生成各个测试页面对应的至少一个测试脚本文件之后，所述方法还包括：

配置所述待测试应用对应的配置文件的第一参数；所述第一参数表征各个页面元素模块对应的测试脚本文件的路径；

对应的，所述执行所述至少一个测试脚本文件，对所述待测试应用进行测试，包括：

获取待测试应用对应的配置文件中的第一参数；

基于所述第一参数执行所述至少一个测试脚本文件。

这里，每一个待测试应用都对应一个配置文件，配置文件可以在不同的浏览器中加载，避免了需要针对不同内核的浏览器编写配置文件。配置文件中记载了该待测试应用需要执行的测试脚本文件。在实际应用中，配置文件中还可以配置：并发执行的浏览器、错误截图保存路径、测试报告格式、隔离模式、智能等待时间、断言超时时间和页面加载超时时间等信息。

在实际应用中，配置文件可以是JS(JavaScript)格式。不同的浏览器都可以直接加载JS格式的配置文件，可以得到配置文件中的信息。

在本实施例中，待测试应用和测试脚本文件都是浏览器可以直接运行的格式文件，比如，待测试应用对应的是一个超文本标记语言(HTML，HyperTextMarkup Language)文件，测试脚本文件是JS格式，这样待测试应用和测试脚本文件可以同时运行在浏览器中。

在一实施例中，配置文件中的第一参数指script标签的src属性，script标签用于定义客户端脚本，比如JavaScript。src属性用于规定外部脚本文件的统一资源定位系统(URL，Uniform ResourceLocator)，基本所有主流浏览器都支持src属性。在本发明实施例中，src属性指向待测试应用对应的至少一个测试脚本文件的URL地址。

例如，一个第一参数的示例为：<script src＝"demo_script.js"></script>。

相关技术在执行测试用例时，需要通过命令行指定测试脚本文件的相对路径，如果需要执行多个测试脚本文件，则需要在命令行中输入较多的测试脚本文件路径，过程相对繁琐，而且人工输入容易出现错误。本实施例将测试脚本文件的路径放置在配置文件的src属性中指定，可以避免在命令行中输入较多的测试脚本路径，避免人工输入，提高测试效率。

基于所述待测试应用对应的HTML文件中的第一参数，执行所述至少一个测试脚本文件，对所述待测试应用进行测试；所述HTML文件中的第一参数指向所述至少一个测试脚本文件的地址。

在本实施例中，配置文件和HTML文件中都配置有第一参数，配置文件中的第一参数用于告诉测试人员待测试应用有哪些测试脚本文件，HTML文件中的第一参数则用于执行具体的测试脚本文件。通过获取配置文件中的第一参数，可以得到待测试应用对应的测试脚本文件的地址，然后基于待测试应用对应的HTML文件中的第一参数，可以执行这些测试脚本文件，实现对待测试应用进行自动化测试。

在实际应用中，HTML文件中的第一参数可以指script标签的src属性。通过HTML文件中script标签的src属性，执行src属性指向的测试脚本文件，可以实现在浏览器中执行测试脚本文件和待测试应用。由于src属性是HTML文件中script标签的属性，这个属性不受域名限制，不存在跨域问题，因此测试脚本文件和待测试应用可以在浏览器内部实现交互，这样可以测试脚本文件不需要经历域名解析、三次握手等繁琐的交互过程，即可到达待测试应用，进而实现高效测试的效果。

如果需要在多个浏览器下并行执行测试脚本文件，由于测试脚本文件和待测试应用都在浏览器中执行，浏览器不需要安装WebDriver，这样节省了测试时间，提高了测试效率。

在本实施例中，配置文件可以在多个浏览器中加载，不需要针对不同的浏览器编写配置文件。本实施例提高了页面测试的兼容性，能够成功兼容绝大多数浏览器，能够兼容所有基于JS支持的浏览器，相比较于现有技术具有更高的兼容性。

本申请通过获取配置文件中的第一参数，可以得到待测试应用对应的测试脚本文件的路径，然后执行这些测试脚本文件，实现对待测试应用进行测试。本申请可以在浏览器内部实现测试脚本文件和待测试应用的交互，测试脚本文件不需要经历域名解析、三次握手等繁琐的交互过程，即可到达待测试应用，进而实现高效测试的效果。并且由于测试脚本文件和待测试应用都在浏览器中执行，浏览器不需要安装WebDriver，这样节省了测试时间，提高了测试效率。

在一实施例中，所述执行各个页面元素模块对应的测试脚本文件，对所述待测试应用进行测试，包括：

基于设定的验证码识别库获取所述待测试应用的验证码数据；

基于获取到的验证码数据和用户信息，对所述待测试应用进行自动化登陆测试。

在自动化登陆测试中，有些场景(比如在防暴力破解的登录页面)会需要验证码进行验证。目前普遍的Web应用测试方法会通过在请求头中设置cookie跳过用户鉴权，这样使得登录页面的测试还是需要人工介入，需要人工输入验证码，导致测试效率不高。

这里，设定的验证码识别库可以是光学字符识别(OCR，Optical CharacterRecognition)库，针对需要验证码的用户自动登录场景，本实施例通过调用基于特征提取方法的OCR库，读取canvas创建的至少包括位图、灰度信息的随机验证码数据，将验证码数据和用户信息通过表单数据提交表单发送给服务端，服务端根据接收的验证码与保存在后端Session对比决定是否允许用户登录进入系统首页，解决了现有技术无法在使用防暴力破解的登录页面实现自动化测试场景的问题。

在一实施例中，测试脚本文件还支持超时等待机制，可以在配置文件中设置选择器的超时等待时长。

受到资源受限或网络延迟的影响，选择器可能找不到目标元素，这时测试报告会显示测试失败。这时需要一种延时机制，来使脚本的运行速度与程序的响应速度相匹配，超时等待机制就为了解决这个问题。在获取目标元素时，通过增加超时等待时长，使得测试稳定性更高。

在一实施例中，所述配置文件包括测试报告格式；在执行所述至少一个测试脚本文件，对所述待测试应用进行测试之后，所述方法还包括：

基于所述配置文件中配置的测试报告格式，生成测试报告。

对于测试脚本文件的测试结果，可以在配置文件中配置测试报告的格式和存储路径，测试结果可以以HTML或者repoter格式发送给浏览器驱动，最终形成测试报告保存在配置文件设置的存储路径下。

在测试脚本文件执行结束后，清除cookie和保存在本地缓存中的测试数据，以避免对后续测试操作造成影响。

参考图2，图2是本发明实施例提供的一种Web应用测试流程的示意图，Web应用测试流程包括：

第一步，在配置文件中配置需要运行的测试脚本文件。

具体可以在配置文件中通过配置src属性指定要执行的测试脚本文件。还可以在配置文件中配置browsers属性指定需要并行执行的浏览器；配置screenshots属性配置错误自动截图以及存放路径；分别通过selectorTimeout、assertionTimeout和pageLoadTimeout属性配置目标元素查找超时时间、校验超时时间以及页面加载超时时间。

第二步，基于Web应用的技术栈，确定选择器定位目标元素。

如果是使用原生JS开发的网页，则基于CSS选择器或客户端JS代码定位目标元素；对于使用类似React或者Vue前端框架的网页，则基于特定于框架的实体Selector定位目标元素。

针对通过Selector机制不容易获取到的客户端信息，类如当前网页地址中的锚点、窗口的滚动位置、视图的宽度、偏移量、主机名称等信息，因为测试程序与被测系统运行在同一环境，因此可使用ClientFunctionAPI获取当前被测系统的环境信息，该方式使得目标元素的获取不再仅能根据Selector选择器，使得脚本内容更灵活。

为实现数据和业务逻辑的分离，即页面元素或设计发生更改时，我们只需要维护页面元素模块中的目标元素。本发明以页面元素模块模式组织整个业务流程涉及到的目标元素，在JS测试脚本文件中声明Page类，在Page类中的构造函数中通过选择器以及类名、id或者文本内容等定义所有测试业务逻辑涉及到的目标元素，并在测试脚本文件中导出它的实例以便在其他业务程序中引用。

第三步，以数据驱动模式构建测试脚本文件。

根据上述导出的实例数据以及具体业务流程，以数据驱动测试模式编写场景相同仅驱动数据不一致的测试用例，实现一个测试用例覆盖多个测试场景的需要。

此外，调用基于特征提取方法的OCR库，读取canvas创建的随机验证码数据，实现自动登录Web应用。

并在测试用例中设置断言超时时间，对于类似HTTP请求的异步操作，通过Promise构造函数将异步执行结果返回，并根据异步执行结果触发绑定的回调函数，也可以通过await关键字设置需要依赖异步操作结果进行的后续操作。在执行测试脚本文件时，将实际的结果与预期的结果通过断言方法对比，比如是否符合预期的类型，是否包含了某个DOM节点，节点个数是否相同等。对于操作结果异步返回的，需要在断言方法中设置断言超时时间，在断言未通过的情况下，不会直接标志测试失败或成功，断言会多次重试传递，每次请求获取实际的属性值，如果超过断言时间仍无法通过验证，则该条测试用例失败。测试结果以html或者repoter格式发送给浏览器驱动，最终形成测试报告保存在配置文件设置的存储路径下。

第四步，以模块化模式组织上一步获得的测试用例，得到测试脚本文件。

“模块化”即通过钩子函数(API Hook)设置测试用例的执行条件，比如以Hook方式设置公共初始页面URL、每条测试用例执行结束后的初始化状态，以及每条测试用例的前置或后置操作。这样可以使得每个测试用例“模块化”，测试用例之间逻辑隔离，测试用例可以独立进行测试，不依赖于其他测试用例，提高了测试效率。而且在对测试用例进行维护时，只需要维护当前测试用例，不需要同时维护多个测试用例，便于测试用例的维护。

第五步，根据业务场景执行测试脚本文件。

针对多种使用场景，本发明可通过本地命令行一键执行一条或多条测试脚本文件；或将测试脚本文件上传至自动化装置中，通过GUI界面操作启动测试用例；也可以通过将测试脚本部署在容器中，实现在远程Linux主机终端下运行测试的需求。

在本地通过命令行一键执行，该方式可以指定单独运行一条或多条测试脚本文件，方便研发人员使用；如果有其他测试研发人员共同参与，则可以通过自动化装置中的测试用例创建单元上传测试脚本文件到对应的类别下，等所有实例上传完成，可通过系统的启动键一键执行，反复多次执行，并通过测试操作报告的结果得出较为准确的性能值。针对本地主机未安装浏览器的情形，依然可以执行测试用例，本发明可以将测试脚本部署在容器中，实现在远程Linux主机终端下用chrome或者Firefox的headless方式运行测试的需求，在容器内通过命令行运行浏览器。

第六步，输出测试报告。

执行测试脚本文件，并按照配置文件中指定的测试报告格式生成测试报告。

本实施例通过执行配置文件中的第一参数指向的测试脚本文件，可以在浏览器内部实现测试脚本文件和待测试应用的交互，测试脚本文件不需要经历域名解析、三次握手等繁琐的交互过程，即可到达待测试应用，进而实现高效测试的效果。并且浏览器不需要安装WebDriver，这样节省了测试时间，提高了测试效率。与现有的测试框架定位目标元素相比，本实施例通过Client FunctionAPI可以获取与网页运行系统环境变量相关的内容，扩展了目前的选择器局限性，且在获取目标元素时，提供了超时等待机制，使得测试稳定性更高。针对需要验证码登录的测试场景，与现有测试框架需要在请求头中设置cookie跳过用户鉴权相比，本实施例调用OCR库自动识别验证码并与用户信息一起通过表单提交数据至服务端，可以实现自动化登录与测试。与现有测试框架中将数据和具体业务逻辑融合在一起的脚本编写方式相比，本实施例以页面元素模块组织测试用例，实现数据和具体业务分离，针对Web设计或内容变化的场景，只需维护数据脚本即可，减少因定位目标元素的代码冗余，方便后期维护。针对测试场景相同的测试，本实施例通过数据驱动测试模式编写测试用例，通过在测试用例中通过导入驱动数据，实现一个测试用例覆盖多个测试场景，且支持在测试用例中添加断言超时时间，降低了网络、环境等对测试结果的影响，使得测试更加灵活，覆盖场景更全，测试可靠性更高。

参考图3，图3是本发明实施例提供的一种脚本文件生成流程的示意图，脚本文件生成流程包括：

导入目标元素实例。

在JS数据脚本文件中声明Page类，在Page类的构造函数中通过选择器以及类名、id或者文本内容等定义所有测试业务逻辑涉及到的目标元素target1、target2...，并在数据脚本文件中导出它的实例以便在其他业务程序中引用。

导入驱动数据。

在业务逻辑脚本文件中，导入上述步骤中导出的Page类实例。针对业务逻辑相同的测试用例，本发明通过数据驱动测试模式构造驱动数据，并在脚本逻辑文件中引入，该模式使得针对场景扩展的测试需求，更新驱动数据即可，逻辑代码更易维护。

控制器函数对目标元素执行逻辑操作。

控制器函数根据逻辑执行对应的操作，包括点击、键入、滚动等。

判断是否异步。

判断测试脚本文件是否包括异步操作。

调用Promise构造函数。

如果是异步，对于类似HTTP请求的异步操作，调用Promise构造函数将异步操作结果返回，并根据异步操作结果触发绑定的回调函数，也可以通过await关键字设置需要依赖异步操作结果进行的后续操作。

如果不是异步，通过控制器函数设置断言。

判断预期结果是否和测试结果一致。

操作完成后，需要控制器函数调用断言API，将实际的操作结果与预期结果通过断言方法比对，比如判断是否符合预期的类型，是否包含了某个DOM节点，节点个数是否相等。

如果预期结果和测试结果一致，输出测试报告；如果不一致，判断是否超过断言时间。

对于操作结果异步返回的，需要在断言方法中设置断言时间，在断言未通过的情况下，不会直接标志测试失败或成功，断言会多次重试传递，每次请求获取实际的属性值，如果超过断言时间仍无法通过验证，则该条测试用例失败。

如果超过断言时间，输出测试报告。

测试结果以html或者repoter格式发送给浏览器驱动，最终形成测试报告保存在配置文件设置的路径下。

参考图4，图4是本发明实施例提供的一种web应用自动化装置的示意图。如图4所示，web应用自动化装置包括用户登录模块、用户管理模块、分类管理模块、创建模块组成。

其中，用户登录模块实现用户登录系统功能，用户根据用户名和密码登录系统。

用户管理模块分为管理员和普通用户，管理员可以增加、删除用户，并针对不同的账号进行授权。管理员分为监控员或操作员，监控员只能通过该装置查看测试并下载报告，不能操作测试脚本文件。

分类管理模块允许将测试脚本文件按照功能进去区分，属于相同类别的测试脚本文件属于同一类别，该模块展示测试脚本文件列表，一条测试脚本文件列表由脚本功能、脚本名称、上传时间、执行时长，以及操作栏组成，操作栏允许对测试脚本文件执行启动、暂停、删除、查看结果等操作。可以在同一类别处点击全部执行键实现该分类下的测试脚本文件的全部执行，也可以单独执行一条测试脚本文件。在操作栏中还可以暂停测试脚本文件执行，或这查看测试脚本文件执行结果，也可以点击删除按钮删除测试脚本文件，并可以通过点击分类列表管理模块中的创建按钮在该分类下增加测试脚本文件。

创建模块包括分类选择下拉框，实例功能描述输入框，以及脚本名称输入框，研发人员可以通过点击浏览按钮，加载本地写好的实例脚本文件，然后点击上传，上传成功后，该测试脚本文件会在对应的分类下展示。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

需要说明的是，本发明实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

另外，在本发明实施例中，“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

参考图5，图5是本发明实施例提供的一种Web应用测试装置的示意图，如图5所示，该装置包括匹配模块和组合模块。

定位模块，用于基于设定选择器定位待测试应用的目标元素；所述待测试应用为Web应用；

第一生成模块，用于基于所述目标元素生成至少一个页面元素模块；每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合；

第二生成模块，用于基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例；

第三生成模块，用于组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件；

执行模块，用于执行所述至少一个测试脚本文件，对所述待测试应用进行测试。

在一实施例中，所述第二生成模块基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例，包括：

基于数据驱动模式确定所述至少两个测试用例中的各个测试用例的驱动数据；

基于所述页面元素模块中的目标元素的属性值、所述驱动数据和所述测试页面的各个功能模块的业务逻辑，生成所述测试页面的各个功能模块对应的至少两个测试用例；所述测试页面包括至少一个功能模块；

对应地，所述组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件，包括：

将同一个功能模块对应的至少两个测试用例部署在同一个测试脚本文件中，其中，该测试脚本文件中的每一个测试用例对应一种测试场景。

在一实施例中，所述第三生成模块生成各个测试页面对应的至少一个测试脚本文件，包括：

在执行结果为异步的测试用例对应的测试脚本文件中设置断言超时时间。

在一实施例中，所述第三生成模块组织所述至少两个测试用例，包括：

基于钩子Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作。

在一实施例中，所述第三生成模块基于Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作，包括：

若第一测试用例的执行依赖于第二测试用例的执行结果，则基于所述Hook函数设置所述第一测试用例的依赖条件；所述依赖条件表征所述第二测试用例的执行结果；所述至少两个测试用例包括：所述第一测试用例和所述第二测试用例。

在一实施例中，所述装置还包括：

确定模块，用于基于所述待测试应用的技术栈确定所述设定选择器；所述设定选择器与所述待测试应用的技术栈对应。

在一实施例中，所述装置还包括：

配置模块，用于配置所述待测试应用对应的配置文件的第一参数；所述第一参数表征各个页面元素模块对应的测试脚本文件的路径；

对应的，所述执行模块执行所述至少一个测试脚本文件，对所述待测试应用进行测试，包括：

获取待测试应用对应的配置文件中的第一参数；

基于所述第一参数执行所述至少一个测试脚本文件。

实际应用时，所述匹配模块和组合模块可通过电子设备中的处理器，比如中央处理器(CPU，Central Processing Unit)、数字信号处理器(DSP，Digital SignalProcessor)、微控制单元(MCU，Microcontroller Unit)或可编程门阵列(FPGA，Field－Programmable Gate Array)等实现。

需要说明的是：上述实施例提供的Web应用测试装置在进行测试时，仅以上述各模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的模块完成，即将装置的内部结构划分成不同的模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的Web应用测试装置与Web应用测试方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述Web应用测试装置可以是镜像文件形式，该镜像文件被执行后，可以以容器或者虚拟机的形式运行，以实现本申请所述的Web应用测试方法。当然也不局限为镜像文件形式，只要能够实现本申请所述的Web应用测试方法的一些软件形式都在本申请的保护范围之内，比如还可以为云计算平台中hypervisor(虚拟机监控器)中所实现的软件模块。

基于上述程序模块的硬件实现，且为了实现本申请实施例的方法，本申请实施例还提供了一种电子设备，上述Web应用测试方法由电子设备的处理器实现。图6为本申请实施例电子设备的硬件组成结构示意图，如图6所示，电子设备包括：

通信接口，能够与其它设备比如网络设备等进行信息交互；

处理器，与所述通信接口连接，以实现与其它设备进行信息交互，用于运行计算机程序时，执行上述电子设备侧一个或多个技术方案提供的方法。而所述计算机程序存储在存储器上。

当然，实际应用时，电子设备中的各个组件通过总线系统耦合在一起。可理解，总线系统用于实现这些组件之间的连接通信。总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图6中将各种总线都标为总线系统。

在本申请中，电子设备可以是单个硬件设备，也可以是多个硬件设备组成的集群，比如云计算平台。所谓云计算平台是把多个独立的服务器物理硬件资源组织成池化资源的一种集群设备，它对外提供所需要的虚拟资源和服务。

本申请实施例中的存储器用于存储各种类型的数据以支持电子设备的操作。这些数据的示例包括：用于在电子设备上操作的任何计算机程序。

可以理解，存储器可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read OnlyMemory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，CompactDisc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，RandomAccessMemory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static RandomAccess Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static RandomAccess Memory)、动态随机存取存储器(DRAM，Dynamic RandomAccess Memory)、同步动态随机存取存储器(SDRAM，Synchronous DynamicRandomAccess Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，DoubleDataRate Synchronous Dynamic RandomAccess Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic RandomAccess Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic RandomAccess Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus RandomAccess Memory)。本申请实施例描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本发明实施例还提供了一种云计算平台，包括用于Web应用测试方法的数据处理软件模块，所述数据处理软件模块用于实现如本发明实施例提供的Web应用测试方法的步骤。

云计算平台是采用计算虚拟化、网络虚拟化、存储虚拟化技术把多个独立的服务器物理硬件资源组织成池化资源的一种业务形态，它是一种基于虚拟化技术发展基础上软件定义资源的结构，可以提供虚拟机、容器等形态的资源能力。通过消除硬件与操作系统之间的固定关系，依赖网络的连通统一资源调度，然后提供所需要的虚拟资源和服务，是一种新型的IT，软件交付模式，具备灵活，弹性，分布式，多租户，按需等特点。

目前的云计算平台支持几种服务模式：

SaaS(Software as a Service，软件即服务)：云计算平台用户无需购买软件，而改为租用部署于云计算平台的软件，用户无需对软件进行维护，软件服务提供商会全权管理和维护软件；

PaaS(Platform as a Service，平台即服务)：云计算平台用户(此时通常为软件开发商)可以在云计算平台提供的架构上建设新的应用，或者扩展已有的应用，同时却不必购买开发、质量控制或生产服务器；

IaaS(Infrastructure as a Service，基础架构即服务)：云计算平台通过互联网提供了数据中心、基础架构硬件和软件资源，IaaS模式下的云计算平台可以提供服务器、操作系统、磁盘存储、数据库和/或信息资源。

上述本申请实施例揭示的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、DSP，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器，处理器读取存储器中的程序，结合其硬件完成前述方法的步骤。

可选地，所述处理器执行所述程序时实现本申请实施例的各个方法中由电子设备实现的相应流程，为了简洁，在此不再赘述。

在示例性实施例中，本申请实施例还提供了一种存储介质，即计算机存储介质，具体为计算机可读存储介质，例如包括存储计算机程序的第一存储器，上述计算机程序可由电子设备的处理器执行，以完成前述方法所述步骤。计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置、电子设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

另外，在本申请实例中，“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种Web应用测试方法，其特征在于，所述方法包括：

基于设定选择器定位待测试应用的目标元素；所述待测试应用为Web应用；

基于所述目标元素生成至少一个页面元素模块；每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合；

基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例；

组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件；

执行所述至少一个测试脚本文件，对所述待测试应用进行测试。

2.根据权利要求1所述的方法，其特征在于，所述基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例，包括：

基于数据驱动模式确定所述至少两个测试用例中的各个测试用例的驱动数据；

基于所述页面元素模块中的目标元素的属性值、所述驱动数据和所述测试页面的各个功能模块的业务逻辑，生成所述测试页面的各个功能模块对应的至少两个测试用例；所述测试页面包括至少一个功能模块；

对应地，所述组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件，包括：

将同一个功能模块对应的至少两个测试用例部署在同一个测试脚本文件中，其中，该测试脚本文件中的每一个测试用例对应一种测试场景。

3.根据权利要求1所述的方法，其特征在于，所述生成各个测试页面对应的至少一个测试脚本文件，包括：

在执行结果为异步的测试用例对应的测试脚本文件中设置断言超时时间。

4.根据权利要求1所述的方法，其特征在于，所述组织所述至少两个测试用例，包括：

基于钩子Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作。

5.根据权利要求4所述的方法，其特征在于，所述基于Hook函数，设置各个测试用例的前置执行操作和/或后置执行操作，包括：

若第一测试用例的执行依赖于第二测试用例的执行结果，则基于所述Hook函数设置所述第一测试用例的依赖条件；所述依赖条件表征所述第二测试用例的执行结果；所述至少两个测试用例包括：所述第一测试用例和所述第二测试用例。

6.根据权利要求1所述的方法，其特征在于，在基于设定选择器定位待测试应用的目标元素之前，所述方法还包括：

基于所述待测试应用的技术栈确定所述设定选择器；所述设定选择器与所述待测试应用的技术栈对应。

7.根据权利要求1所述的方法，其特征在于，在生成各个测试页面对应的至少一个测试脚本文件之后，所述方法还包括：

配置所述待测试应用对应的配置文件的第一参数；所述第一参数表征各个页面元素模块对应的测试脚本文件的路径；

对应的，所述执行所述至少一个测试脚本文件，对所述待测试应用进行测试，包括：

获取待测试应用对应的配置文件中的第一参数；

基于所述第一参数执行所述至少一个测试脚本文件。

8.一种Web应用测试装置，其特征在于，包括：

定位模块，用于基于设定选择器定位待测试应用的目标元素；所述待测试应用为Web应用；

第一生成模块，用于基于所述目标元素生成至少一个页面元素模块；每一个页面元素模块表征所述待测试应用的一个测试页面对应的目标元素的集合；

第二生成模块，用于基于所述页面元素模块中的目标元素的属性值，生成对应的测试页面的至少两个测试用例；

第三生成模块，用于组织所述至少两个测试用例，生成各个测试页面对应的至少一个测试脚本文件；

执行模块，用于执行所述至少一个测试脚本文件，对所述待测试应用进行测试。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的Web应用测试方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1至7任一项所述的Web应用测试方法。