一种自动化回归测试方法及装置

技术领域

本发明涉及计算机技术领域，特别涉及一种自动化回归测试方法及装置。

背景技术

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

随着业务复杂度的增加，以及敏捷项目流程下的频繁发版，测试人员需要大量的时间进行页面基础功能的回归测试，这对于测试人员来说，必须投入大量时间来进行回归测试，系统测试、维护升级等阶段的成本显著增加。然而，对于现有技术来说，自动化回归测试的难点在于，测试人员在操作页面进行测试时，会自行等待元素的出现、页面的切换、处理各种异常弹窗以及点击不成功后的再次点击、刷新页面等操作，而代码却做不到同样的灵活自如；另外，自动化回归测试通常仅能显示最终的结果，不能给测试人员提供整个测试过程中各个环节的细节，不便于问题的追溯。

发明内容

本申请提供了一种自动化回归测试方法及系统，以解决现有技术需要投入大量测试时间来进行重复性测试回归的问题。

第一方面，本申请提供了一种自动化回归测试方法，所述方法包括：

获取触发指令，根据触发指令确定测试用例集以及测试环境；

按顺序采用测试用例集中的测试用例初始化页面，到达指定页面；

调用底层封装的初始化driver方法初始化浏览器；所述初始化driver方法包括显示等待操作或隐式等待操作；

若初始化driver成功，则进行页面配置元素读取操作；

调用所述页面配置元素对应的共用方法进行页面配置加载；

加载测试用例中case的测试数据；

调用封装进行页面操作，直到操作完成；

当测试用例集中的所有测试用例均操作完成，调用集成的allure模块生成测试报告。

在一些实施例中，所述方法还包括：

若初始化driver失败，判断当前测试用例的执行次数是否达到第一最大重试次数；

若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

在一些实施例中，所述方法还包括：

获取所述调用所述页面配置元素对应的共用方法进行页面配置加载步骤的加载结果；若所述加载结果为加载失败，则判断当前测试用例的执行次数是否达到第一最大重试次数；

若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

在一些实施例中，所述方法还包括：

获取所述调用封装进行页面操作的操作结果；若所述操作结果为未完成，则判断调用封装进行页面操作的操作次数是否达到第二最大重试次数；

若是，则继续执行判断当前测试用例的执行次数是否达到第一最大重试次数的步骤；若否，则重新执行所述调用封装进行页面操作的步骤。

在一些实施例中，所述方法还包括：

将所述初始化driver失败、加载失败、操作结果为未完成的相关日志记录添加到测试报告中。

在一些实施例中，所述方法还包括：

当执行某一测试用例操作完成后，清理与该测试用例对应的初始化数据。

第二方面，本申请还提供了一种自动化回归测试装置，包括：

触发单元，被配置为获取触发指令，根据触发指令确定测试用例集以及测试环境；

初始化单元，被配置为按顺序采用测试用例集中的测试用例初始化页面，到达指定页面；

浏览器单元，被配置为调用底层封装的初始化driver方法初始化浏览器；所述初始化driver方法包括显示等待操作或隐式等待操作；

元素读取单元，被配置为若初始化driver成功，则进行页面配置元素读取操作；

加载单元，被配置为调用所述页面配置元素对应的共用方法进行页面配置加载；以及加载测试用例中case的测试数据；

页面操作单元，被配置为调用封装进行页面操作，直到操作完成；

报告生成单元，被配置为当测试用例集中的所有测试用例均操作完成，调用集成的allure模块生成测试报告。

在一些实施例中，所述元素读取单元还被配置为：

若初始化driver失败，判断当前测试用例的执行次数是否达到第一最大重试次数；

若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

在一些实施例中，所述加载单元还被配置为：

获取所述调用所述页面配置元素对应的共用方法进行页面配置加载步骤的加载结果；若所述加载结果为加载失败，则判断当前测试用例的执行次数是否达到第一最大重试次数；

若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

在一些实施例中，所述页面操作单元还被配置为：

获取所述调用封装进行页面操作的操作结果；若所述操作结果为未完成，则判断调用封装进行页面操作的操作次数是否达到第二最大重试次数；

若是，则继续执行判断当前测试用例的执行次数是否达到第一最大重试次数的步骤；若否，则重新执行所述调用封装进行页面操作的步骤。

在一些实施例中，所述报告生成单元还被配置为：

将所述初始化driver失败、加载失败、操作结果为未完成的相关日志记录添加到测试报告中。

在一些实施例中，还包括：

清理单元，被配置为当执行某一测试用例操作完成后，清理与该测试用例对应的初始化数据。

本申请提供了一种自动化回归测试方法，包括获取触发指令，根据触发指令确定测试用例集以及测试环境；按顺序采用测试用例集中的测试用例初始化页面，到达指定页面；调用底层封装的初始化driver方法初始化浏览器；所述初始化driver方法包括显示等待操作或隐式等待操作；若初始化driver成功，则进行页面配置元素读取操作；调用所述页面配置元素对应的共用方法进行页面配置加载；加载测试用例中case的测试数据；调用封装进行页面操作，直到操作完成；当测试用例集中的所有测试用例均操作完成，调用集成的allure模块生成测试报告。本申请的方案，让功能变动时，可以修改尽量少的代码来完成case的维护。如仅仅是页面布局发生变动，只需要修改元素定位配置。而操作流程变动，则可以通过修改页面模块来达成。

本申请通过一种分层设计、参数化测试数据、配置化元素定位、页面操作模块与用例模块分离来解决自动化回归测试中稳定性的问题，其中，通过重试机制来解决web UI自动化过程常常出现的元素定位不到、操作时元素失效、元素被遮挡、页面加载不完成、页面操作时间不确定等导致自动化用例不稳定的问题。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一种自动化回归测试方法应用场景图；

图2为本申请一种自动化回归测试方法的执行流程图。

具体实施方式

参见图1，为本申请一种自动化回归测试方法应用场景图；

本申请的方法是通过图1所示的框架所实现的，其中主要包括五个基础模块：底层浏览器驱动封装模块、页面操作模块、配置模块、用例模块和用例运行模块。其中，

底层浏览器驱动封装模块(也可称底层封装模块)：主要负责封装底层的selenium浏览器驱动方法，封装各种元素操作，添加元素等待方法，元素操作重试方法，从而确保能正常的实现元素定位。在本申请中，元素是指web页面的控件，可以是输入框、按键、按钮等。

Selenium测试直接在浏览器中运行，就像真实用户所做的一样。Selenium测试可以在Windows、Linux和Macintosh上的Internet Explorer、Chrome和Firefox中运行。其他测试工具都不能覆盖如此多的平台。通过编写模仿用户操作的Selenium测试脚本，可以从终端用户的角度来测试应用程序。通过在不同浏览器中运行测试，更容易发现浏览器的不兼容性。

页面操作模块(也可称页面模块)：封装页面的基本操作，例如登陆、点击购买等，封装实现各种操作的操作单元，以便在不同的case中使用。

配置模块：根据配置模块中的配置，可以定位到页面元素，当只有元素定位修改时，维护者只需要修改配置模块，即可以让case正常运行。

用例模块：测试用例的组织模块，通过调用底层封装，可以更方便地在上层组织测试用例，便于对测试用例的管理与编写。同时，用例模块还提供了操作失败重试、记录日志、测试用例运行失败后重试等功能。

用例运行模块(pytest runner)：采用pytest框架，在本层中通过控制测试用例的执行顺序，可以通过定制，来给不同的测试用例打不同的标签，例如smoke，regress等，将不同的case集应用到不同的场景。

采用事先建立好的上述框架，在实际应用过程中，本申请所述的自动化回归测试方法可由图2所示的流程图进行说明，方法具体包括：

步骤一：获取触发指令，根据触发指令确定测试用例集以及测试环境；在本实施例中，触发指令是通过预设的jenkins定时任务触发或者通过操作者(自动化用例使用者)手动点击触发，用例运行模块(pytest runner)可以根据该触发选择不同的执行环境，以及根据用户不同的需求执行相应的测试用例，用户的需求可以是冒烟或回归。

步骤二：按顺序采用测试用例集中的测试用例初始化页面，到达指定页面；在本步骤中，先由用例运行模块规定测试用例集中测试用例的预设执行顺序，对于每一个测试用例，均采用后续步骤执行，其中，用例模块生成初始化相关的页面信息，以及相关初始化数据，页面操作模块根据初始化数据执行初始化相应页面，到达指定页面的操作。

步骤三：调用底层封装的初始化driver方法初始化浏览器；所述初始化driver方法包括显示等待操作或隐式等待操作；具体的，当初始化浏览器后，系统将启动相应的页面元素等待程序、设置显示等待及隐式等待，直至初始化过程结束。

步骤四：判断初始化driver是否成功，若初始化driver成功，则由页面操作模块和底层封装模块共同完成页面配置元素读取操作；若初始化失败，则要判断当前测试用例的执行次数是否达到第一最大重试次数；第一最大重试次数是允许当前测试用例被重复执行的最大次数，数值可自行设定，例如三次，当不满三次时，均可以通过重新执行该测试用例，以重新获取初始化结果，若已满三次则跳过该测试用例的执行，直接进行下一个测试用例的执行。

相应的，上述步骤为，若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新执行所述初始化页面的步骤。

步骤五：调用所述页面配置元素对应的共用方法进行页面配置加载；在本实施例中，所述的共用方法是根据不同的元素类型统计出的可适用于同一类元素的配置方法，或者是对于同一类元素的统一的方法。其中，配置模块配置有页面定位控件的配置文件，该配置文件采用yaml文件格式。在页面封装模块初始化时，调用配置模块代码加载该配置文件。设计思路为：在selenium中，元素定位需要locator和by两个元素，所以在设计时，为每个控件添加这两个配置。同时添加元素名称及des，以便于后期维护时开发者可以快速识别相应的控件定位元素用途。

login:第一行，表示元素的名称。

login.des:元素说明，便于后期维护。

login.by:定位方式。所支持的定位方式可以是“id”“xpath”“link text”“partial link”“text”“name”“tag name”“class name”“css selector”等等。

login.locator:定位元素。

上述加载过程中，加载可能失败，因此，在一种可行性实施例中，需要获取加载的结果，一旦加载失败，则判断当前测试用例的执行次数是否达到第一最大重试次数；同样可以采用允许当前测试用例被重复执行的最大次数来判断是否需要重新执行该测试用例。

相应的步骤为，若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

步骤六：当页面配置加载完成后，将按照顺序执行用例模块中的case，并由配置模块加载测试用例中case的测试数据，随后，用例模块将按代码顺序调用页面方法执行测试用例，以及调用页面模块的封装进行页面操作。

步骤七：底层封装模块调用封装对页面进行操作，并判断操作是否完成，如果完成，表示该测试用例执行已完成，可以按顺序继续执行下一条测试用例；但是如果因为一些原因导致操作失败，此时仍然需要进行重试操作，因此，在一种实施例中，需要获取所述调用封装进行页面操作的操作结果；若所述操作结果为未完成，则判断调用封装进行页面操作的操作次数是否达到第二最大重试次数；其中，第二最大重试次数是指对页面操作允许重试的最大次数，例如三次，当不满三次时，均可以通过重新执行页面操作，以重新获取操作结果，若已满三次，则需要继续执行判断当前测试用例的执行次数是否达到第一最大重试次数的步骤，看是否还可以通过重新执行当前测试用例来使得最终的页面操作完成。

步骤八：当测试用例集中的所有测试用例均操作完成，调用集成的allure模块生成测试报告。在生成的测试报告中，可以快速查看自动化case的执行情况，例如执行相关数据，成功失败情况等。更佳的实施例中，可以在每次初始化driver失败、加载失败、操作结果为未完成时，自动将失败界面截图保存，并将失败有关信息以及截图、保护相应的相关日志记录均添加到测试报告中，可以有效帮助测试人员记录问题和定位问题所在。

由上述技术方案可知，本申请通过一种分层设计、参数化测试数据、配置化元素定位、页面操作模块与用例模块分离来解决自动化回归测试中稳定性的问题，其中，通过重试机制来解决web UI自动化过程常常出现的元素定位不到、操作时元素失效、元素被遮挡、页面加载不完成、页面操作时间不确定等导致自动化用例不稳定的问题。具体的，重试机制体现在：

第一层：初始化阶段，selenium的显示等待及隐式等待。如果控制定位不到，重试，直到超时、超次异常。

第二层：在底层浏览器驱动封装模块中，所有元素定位操作均引入重试机制，在第一层重试失败的情况下，再次重试，增加稳定性。

第三层：在用例运行模块中增加重试机制，如果用例执行失败，则重试执行。本层重试，进一步增加了用例的稳定性。本层重试，增加了环境的初始化和清理操作，可以排除环境问题引发的一些用例失败原因。

同时，由上述技术方案还可知，在上述方法中，通过页面操作模块来封装一个功能的一组操作，例如登陆操作，会封装在登陆页面中。用例模块只需要调用页面操作中的登陆方法，传入用户名及密码，检测是否登陆即完成相应的测试操作。并且从图2可知，本申请的方法是通过多页面同组件(同一模块)的复用来实现目的，对于不同页面入口的登陆模块，使用同一个页面操作模块即可。

在本申请中，对于测试数据的组合，仍以登陆举例，如用户名有长度限制，特殊字符限制等，可组成大量用例，此时可以将用例数据放入配置模块中，执行时，就可以完成所有用例数据的执行。如此，如果对于用户名密码等数据类的功能修改，可通过修改测试数据来完成自动化用例的维护工作。且在新增测试用例时，自动化用例开发者也不必在case层中添加大量的、仅测试数据不同的重复代码，显著提高了用例开发效率。

在本申请中，用于执行测试用例的模块在测试数据时同样能够复用。对于同一组测试数据，如30条不同的下单测试数据，既可以用在下单测试中，也可以用在下单历史记录检查，活跃订单，托送检测等其他测试用例中。

本申请中的用例模块，其主要功能是组装测试用例，将用例模块与页面操作模块分离开来，是为了多次复用测试数据以及配合页面操作模块的操作。例如写20条登陆用例时，只需要写一个登陆case即可，大大减少了代码量。

并且，由于用例模块与页面操作模块的分离，相当于各个web页面都有登陆页面操作，这样就可以通过调用不同的入口方法，之后复用已有登陆页面操作模块的方法即可。

也就是说，本申请中的分层设计，使得每一层的模块都能大量复用，大大减少了代码量，提升了web UI自动化框架的可维护性。

由上述技术方案可知，本申请提供了一种自动化回归测试方法，包括获取触发指令，根据触发指令确定测试用例集以及测试环境；按顺序采用测试用例集中的测试用例初始化页面，到达指定页面；调用底层封装的初始化driver方法初始化浏览器；所述初始化driver方法包括显示等待操作或隐式等待操作；若初始化driver成功，则进行页面配置元素读取操作；调用所述页面配置元素对应的共用方法进行页面配置加载；加载测试用例中case的测试数据；调用封装进行页面操作，直到操作完成；当测试用例集中的所有测试用例均操作完成，调用集成的allure模块生成测试报告。本申请的方案，让功能变动时，可以修改尽量少的代码来完成case的维护。如仅仅是页面布局发生变动，只需要修改元素定位配置。而操作流程变动，则可以通过修改页面模块来达成。

对应于上述方法，本申请还提供了一种自动化回归测试装置，包括：

触发单元，被配置为获取触发指令，根据触发指令确定测试用例集以及测试环境；

初始化单元，被配置为按顺序采用测试用例集中的测试用例初始化页面，到达指定页面；

浏览器单元，被配置为调用底层封装的初始化driver方法初始化浏览器；所述初始化driver方法包括显示等待操作或隐式等待操作；

元素读取单元，被配置为若初始化driver成功，则进行页面配置元素读取操作；

加载单元，被配置为调用所述页面配置元素对应的共用方法进行页面配置加载；以及加载测试用例中case的测试数据；

页面操作单元，被配置为调用封装进行页面操作，直到操作完成；

报告生成单元，被配置为当测试用例集中的所有测试用例均操作完成，调用集成的allure模块生成测试报告。

进一步的，所述元素读取单元还被配置为：

若初始化driver失败，判断当前测试用例的执行次数是否达到第一最大重试次数；

若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

进一步的，所述加载单元还被配置为：

获取所述调用所述页面配置元素对应的共用方法进行页面配置加载步骤的加载结果；若所述加载结果为加载失败，则判断当前测试用例的执行次数是否达到第一最大重试次数；

若是，则停止执行当前测试用例，开始执行下一测试用例；若否，则重新所述执行初始化页面的步骤。

进一步的，所述页面操作单元还被配置为：

获取所述调用封装进行页面操作的操作结果；若所述操作结果为未完成，则判断调用封装进行页面操作的操作次数是否达到第二最大重试次数；

若是，则继续执行判断当前测试用例的执行次数是否达到第一最大重试次数的步骤；若否，则重新执行所述调用封装进行页面操作的步骤。

进一步的，所述报告生成单元还被配置为：

将所述初始化driver失败、加载失败、操作结果为未完成的相关日志记录添加到测试报告中。

进一步的，还包括：

清理单元，被配置为当执行某一测试用例操作完成后，清理与该测试用例对应的初始化数据。

上述装置在执行方法过程中的作用效果可参见上述方法中的说明，在此不再赘述。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由本申请的权利要求指出。