CN111737138B - 测试环境的自动恢复系统及其方法 - Google Patents

Abstract

本公开提供一种测试环境的自动恢复系统，测试环境包括用于运行被测试对象的主主控组件、备主控组件以及业务板卡，所述自动恢复系统包括：脚本执行组件，用于与被测试对象的运行并行地执行测试脚本；串行接口，串行连接到所述测试环境，以便获得来自所述测试环境的反馈信息；异常事件获取组件，经由所述串行接口从所述测试环境获取被测试对象导致的异常事件，并对异常事件进行分类；以及重启组件，针对所获取的异常事件的类型，重启测试环境中出现异常事件的组件。

Description

测试环境的自动恢复系统及其方法

技术领域

本公开涉及测试环境的恢复系统和方法，尤其是涉及一种可自动恢复测试环境的系统和方法。

背景技术

目前，电子设备中广泛地使用各种应用来实现电子设备的各种功能，因此电子设备的正常功能的实现对内置软件要求越来越高。为此，需要对电子设备的软件进行预先测试，以避免软件中存在各种问题导致电子设备死机。目前通常采用软件测试框架对电子设备进行测试。

常用软件测试框架可以对各种对象进行测试，例如对web测试(selenium)、JavaGUI测试、启动0线程、Telnet、SSH等进行测试，这是测试可以使用关键字驱动(keyword-driven)、数据驱动(data-driven)和行为驱动开发(BDD)完成。这些测试框架与应用之间无关联性，支持不同的环境进行测试。通常测试脚本按照suite_setup、setup、case、teardown、suite_teardown的流程执行。执行脚本生成的结果报告和日志采用HTML格式，易于阅读。

当时，采用测试框架进行自动化测试过程中会遇到致命事件，例如运行被测试对象的主控或备用主控以及业务板卡都可能会由于被测试对象自身存在的系统性问题导致死机。当这种测试出现死机的时候，就需要人工及时进行恢复。中，当遇到自动化测试遇到致命事件时，传统的测试框架的恢复流程无自动恢复自动化测试环境，因此在人工干预之前，会导致测试系统在致命事件之后的测试脚本无法正常运行，而且脚本会在异常的环境下继续下发执行，会对当前测试环境的异常信息收集带来干扰，甚至丢失等，这会导致人们无法准确溯源被测试对象导致致命事件的原因。因此，传统的测试框架需要人工干预，进行手动恢复自动化测试环境，重新开始新一轮的自动化测试。从而达到对被测系统的自动化测试效果。这种传统人工恢复自动化测试环境中，测试人员在遇到被测系统发生致命事件后，首先对被测系统进行异常信息收集，然后，根据当前被测系统的异常状态人工判断异常产生的原因，然后进行针对性恢复。最后，人工恢复自动化测试环境后，重新进行脚本执行，最后得出测试报告，进行测试报告分析。

很显然，目前的这种传统测试系统和方法在致命事件发生后，后续脚本无法正常继续运行，自动化程度低，而且人工进行环境恢复，会增加人力投入、测试成本，代价高。另外，测试人员水平不一，恢复自动化测试环境有一定的主观操作，可能会对被测系统进行错误的恢复。发生致命事件后，脚本依旧在异常的环境下发执行，会对当前异常环境信息的收集带来干扰，甚至丢失，异常信息丢失，给分析自动化测试报告带来困难，对被测对象的修正不能起到针对性指导作用。

为此，人们期望有一种能够自动恢复自动化测试环境，提高自动化程度，增加自动化脚本的执行率的测试系统和方法。

发明内容

本公开的示例性实施例的目的在于克服现有技术中的上述的和/或其他的问题。因此，根据本公开的一个方面，提供了一种测试环境的自动恢复系统，测试环境包括用于运行被测试对象的主主控组件、备主控组件以及业务板卡，所述自动恢复系统包括：脚本执行组件，用于与被测试对象的运行并行地执行测试脚本；串行接口，串行连接到所述测试环境，以便获得来自所述测试环境的反馈信息；异常事件获取组件，经由所述串行接口从所述测试环境获取被测试对象导致的异常事件，并对异常事件进行分类；以及重启组件，针对所获取的异常事件的类型，重启测试环境中出现异常事件的组件。

根据本公开的测试环境的自动恢复系统，其中所述异常事件获取组件通过向所述串行接口下发与被测试对象运行不相关的字符串获取串行接口反馈的信息来判断主主控组件的异常事件以及备主控组件的异常事件。

根据本公开的测试环境的自动恢复系统，其中所述异常事件获取组件通过向所述串行接口下发读取业务板卡的寄存器的指令来获取反馈信息来判断业务板卡的异常事件。

根据本公开的测试环境的自动恢复系统，其中括异常信息收集组件，基于异常事件的类型通过向所述串行接口发送回溯指令和读取指令，获取异常事件的信息或返回值。

根据本公开的测试环境的自动恢复系统，其中所述重启组件在主主控组件出现异常事件时，在先重启主主控组件后重启备主控组件，以及在仅备主控组件出现异常事件时，重启备主控组件。

根据本公开的测试环境的自动恢复系统，其中所述重启组件在业务板卡出现异常事件时，对业务板卡执行热插拔操作。

根据本公开的另一个方面，提供一种测试环境的自动恢复方法，所述测试环境包括用于运行被测试对象的主主控组件、备主控组件以及业务板卡，所述自动恢复方法包括：在脚本执行组件与被测试对象的运行并行地执行测试脚本过程中，通过串行连接到所述测试环境的串行接口获得来自所述测试环境的反馈信息；通过向所述串行接口下发与被测试对象运行不相关的字符串获取串行接口反馈的信息来判断主主控组件的异常事件以及备主控组件的异常事件，并对异常事件进行分类；以及通过重启组件针对所获取的异常事件的类型，重启测试环境中出现异常事件的组件。

根据本公开的测试环境的自动恢复方法，其还包括：通过所述异常事件获取组件向所述串行接口下发读取业务板卡的寄存器的指令来获取反馈信息来判断业务板卡的异常事件。

根据本公开的测试环境的自动恢复方法，其包括：

在重启发生异常事件的组件之前，通过异常信息收集组件基于异常事件的类型通过向所述串行接口发送回溯指令和读取指令，获取异常事件的信息或返回值。

根据本公开的测试环境的自动恢复方法，其中所述重启测试环境中出现异常事件的组件包括在主主控组件出现异常事件时，在先重启主主控组件后重启备主控组件，以及在仅备主控组件出现异常事件时，重启备主控组件。

根据本公开的测试环境的自动恢复方法，其中所述重启测试环境中出现异常事件的组件包括在业务板卡出现异常事件时，对业务板卡执行热插拔操作。

综上，采用根据本公开的自动恢复测试系统和方法，在自动测试系统执行脚本遇到被测对象发生致命事件时，无需手工干预即可以实现被测对象各个组成部件的重启。测试系统只需要对被测系统执行一次完整的脚本，即可输出完整的测试报告。减少人力投入，提高自动化程度。而且，采用根据本公开的自动恢复测试系统和方法，在被测对象发生致命事件后，可以根据异常类型自动收集异常信息、并自动恢复自动化测试环境。根进一步，采用根据本公开的自动恢复测试系统和方法，恢复自动化测试环境是基于对异常事件的有根据的判断，因此降低因为个人理性色彩导致的误恢复，增加自动化测试的可靠性。

附图说明

通过结合附图对于本公开的示例性实施例进行描述，可以更好地理解本公开，在附图中：

图1所示的是根据本公开实施例的自动恢复测试系统的示意性原理框图；以及

图2是示出根据本公开实施例的测试系统自动恢复方法的示意性流程图；

具体实施方式

以下将描述本公开的具体实施方式，需要指出的是，在这些实施方式的具体描述过程中，为了进行简明扼要的描述，本说明书不可能对实际的实施方式的所有特征均作详尽的描述。应当可以理解的是，在任意一种实施方式的实际实施过程中，正如在任意一个工程项目或者设计项目的过程中，为了实现开发者的具体目标，为了满足系统相关的或者商业相关的限制，常常会做出各种各样的具体决策，而这也会从一种实施方式到另一种实施方式之间发生改变。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本公开公开的内容相关的本领域的普通技术人员而言，在本公开揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本公开的内容不充分。

除非另作定义，权利要求书和说明书中使用的技术术语或者科学术语应当为本公开所属技术领域内具有一般技能的人士所理解的通常意义。本公开专利申请说明书以及权利要求书中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“一个”或者“一”等类似词语并不表示数量限制，而是表示存在至少一个。“包括”或者“包含”等类似的词语意指出现在“包括”或者“包含”前面的元件或者物件涵盖出现在“包括”或者“包含”后面列举的元件或者物件及其等同元件，并不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，也不限于是直接的还是间接的连接。

图1所示的是根据本公开实施例的测试环境的自动恢复系统的示意性原理框图。如图1所示，测试环境的自动恢复系统100与测试环境200之间通过串行接口130进行信号传输。测试环境200包括用于运行被测试对象的主主控组件210、备主控组件220以及业务板卡230，所述业务板卡230包含逻辑存储器231用于存储被测试对象的运行业务的逻辑控制数据。在被测试对象运行过程中，由于各种运行原因，主主控组件210、备主控组件220以及业务板卡230都可能存在挂死的情形。被测试对象可能是软件本身或内置软件，例如web、JavaGUI、启动0线程、Telnet、SSH等等。为了进行适应的测试，人们会为该测试任务提供专门的测试脚本。自动恢复系统100的脚本运行组件110通过与被测对象并行执行测试脚本来开启对被测对象的运行情况的测试并获得测试结果。具体而言，异常事件获取组件120在脚本运行组件110测试脚本执行到TEARDOWN阶段会经由串行接口130向被测环境中的主主控组件210或备主控组件220下发一个不影响被测对象运行的不相关的字符串(不影响功能即可)，此时串行接口130会进入KDB(内核调试(KENERL DEBUG)，即KDB>)，KDB提供了丰富的命令实现运行控制、内存操纵、寄存器操纵、断点设置、堆栈跟踪等许多功能。对此，本公开不再赘述。

异常事件获取组件120在向主主控组件210下发不相关字符串之后捕获串行接口130回显的信息并与正则表达式r‘(？im)kdb’进行匹配。若匹配成功即主主控发生死机，反之则没发生死机。同样，判断备主控组件220是否发生挂死的方法与判断主主控是否挂死的方法相同。由于主主控组件110在运行被测试对象时，会将运行数据同步到备主控组件120，因此，在主主控组件挂死的情况下，备主控组件120也会出现同样的挂死情况。异常事件获取组件120在测试脚本执行到TEARDOWN阶段会经由串行接口130通过命令行对业务板卡230中的逻辑存储器231进行读取，并将读取数据与正常值(0XFFFFFFFF)进行对比。当与正常值不一致时，则判断业务板卡或其中的FPGA发生了挂死，反之则正常。例如，当读取相关寄存器为0X12341234时，与正常值0XFFFFFFFF不一致，则发生了逻辑挂死。

为了针对挂死的被测对象进行后续针对性诊断并进行针对性修改，需要获得导致挂死的具体信息。为此，根据本公开的测试环境恢复系统100的异常信息收集组件150在获得异常事件获取组件120的判断结果时，基于异常事件获取组件120对异常事件的分类，通过向所述串行接口130发送回溯指令和读取指令，获取异常事件的信息或返回值。具体而言，当判断主主控组件210挂死时，异常信息收集组件150向串行接口130下发btc、dmesg100指令，以便串行接口130执行这些指令进行异常信息收集。同样，在判断备主控组件220发生挂死时，异常信息收集组件150向串行接口130下发btc、dmesg 100指令，以便串行接口130执行这些指令进行异常信息收集。如果判断业务板卡230的FPGA挂死时，异常信息收集组件150向串行接口130下发信息读取指令，以便串行接口130对相关寄存器的返回值进行存储。异常信息收集组件150收集异常信息需发生在自动恢复环境步骤之前，以防止恢复环境后，异常信息的丢失。

在异常信息收集完成之后，重启组件140针对所获取的异常事件的类型，重启测试环境中出现异常事件的组件。具体而言，重启组件140经由串行接口130向对应发生异常事件的组件发送重启指令。例如，当主主控组件210出现挂死异常事件时，向主主控组件210发送重启指令，随后向备主控组件220发送重启指令。这样使得重启后的主主控组件210与备主控组件220依然彼此保持信息同步。此外在有些情况下，由于主主控组件210与备主控组件220两者之间的同步可能导致备主控组件220自身单独挂死。此时，只需要向备主控组件220发送重启指令即可。当业务板卡230中的FPGA挂死时，重启组件140他那个锅串行接口130向业务板卡发送重启命令，使业务板卡230执行热插拔操作从而实现恢复。需要注意的是，当出现多种挂死现象时，需要按照主主控组件210、备主控组件220以及业务板卡230的顺序依次进行重启。

可选择地，本公开的测试环境的自动恢复系统100还可以包括脚本联动数据库，通过在该脚本联动数据库中存入各种被测对象的异常特征、异常信息收集手段和恢复环境的方法。异常信息收集组件150无需经由串行接口130向测试环境获取具体异常信息，而只需要搜索脚本联动数据库就可以获得对应的被测对象的异常特征、异常信息收集手段和恢复环境的方法，从而记录相应的异常信息并指令重启组件140发出对应的重启指令。

在所有异常事件对应的组件或业务板卡都执行完成重启之后，脚本执行组件110立即自动执行下一对象进行自动测试。如此反复进行异常事件的获取和判断，并自动对测试环境中的异常组件进行重启。如果没有任何异常事件，脚本执行组件110会基于脚本循环执行对不同对象的测试脚本，直到所有被测试对象在测试环境中执行完毕。

图2是示出根据本公开实施例的测试系统自动恢复方法的示意性流程图。如图2所示，首先，在步骤S210处，脚本执行组件110执行测试脚本，脚本中针对一个被测试对象，通常包含三部分，启动部分SETUP、CASE以及TEARDOWN部分或者SUITE SETPU、SUITE以及SUITETEARDOWN。每次在TEARDOWN的结束环节，在步骤S220处，异常事件获取组件120通过串行接口向测试环境200发送与测试对象不相关的字符串，以便获得测试环境的响应，并基于响应判断测试对象在被测试过程中是否导致异常事件。并随后基于该响应在步骤S230处判断导致的异常事件的类型。具体而言，异常事件获取组件120在向主主控组件210下发不相关字符串之后捕获串行接口130回显的信息并与正则表达式r‘(？im)kdb’进行匹配。若匹配成功即主主控发生死机，反之则没发生死机。同样，判断备主控组件220是否发生挂死的方法与判断主主控是否挂死的方法相同。由于主主控组件110在运行被测试对象时，会将运行数据同步到备主控组件120，因此，在主主控组件挂死的情况下，备主控组件120也会出现同样的挂死情况。异常事件获取组件120在测试脚本执行到TEARDOWN阶段会经由串行接口130通过命令行对业务板卡230中的逻辑存储器231进行读取，并将读取数据与正常值(0XFFFFFFFF)进行对比。当与正常值不一致时，则判断业务板卡或其中的FPGA发生了挂死，反之则正常。例如，当读取相关寄存器为0X12341234时，与正常值0XFFFFFFFF不一致，则发生了逻辑挂死。

随后，针对不同的异常事件，在步骤S231、S232以及S233处，经由串行接口130分别对主主控组件210的异常挂死、备主控组件220异常挂死以及业务板卡的业务逻辑异常挂死进行信息采集并进行标记。在进行异常事件的信息采集完成后，在步骤S241、S242以及S243处，重启组件140针对不同的异常事件，经由串行接口130向各个异常事件发生的组件发送重启指令。具体而言，重启组件140经由串行接口130向对应发生异常事件的组件发送重启指令。例如，当主主控组件210出现挂死异常事件时，在步骤S241处，向主主控组件210发送重启指令，随后向备主控组件220发送重启指令。这样使得重启后的主主控组件210与备主控组件220依然彼此保持信息同步。此外在有些情况下，由于主主控组件210与备主控组件220两者之间的同步可能导致备主控组件220自身单独挂死。此时，在步骤S242处，只需要向备主控组件220发送重启指令即可。当业务板卡230中的FPGA挂死时，在步骤S243处，重启组件140他那个锅串行接口130向业务板卡发送重启命令，使业务板卡230执行热插拔操作从而实现恢复。需要注意的是，当出现多种挂死现象时，需要按照主主控组件210、备主控组件220以及业务板卡230的顺序依次进行重启。

完成重启之后，在步骤S250处，继续执行下针对下一个测试对象的测试脚本。当在步骤S220处确定没有异常发生时，直接进入步S250进行下一个测试对象的测试脚本的执行。在连续执行完成所有测试对象的测试脚本之后，在步骤S260处，输出整个测试过程的测试报告。

以上结合具体实施例描述了本公开的基本原理，但是，需要指出的是，对本领域的普通技术人员而言，能够理解本公开的方法和装置的全部或者任何步骤或者部件，可以在任何计算装置(包括处理器、存储介质等)或者计算装置的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本公开的说明的情况下运用他们的基本编程技能就能实现的。

因此，本公开的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。所述计算装置可以是公知的通用装置。因此，本公开的目的也可以仅仅通过提供包含实现所述方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本公开，并且存储有这样的程序产品的存储介质也构成本公开。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。

还需要指出的是，在本公开的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本公开的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (4)

1.一种测试环境的自动恢复系统，测试环境包括用于运行被测试对象的主主控组件、备主控组件以及业务板卡，所述自动恢复系统包括：

脚本执行组件，用于与被测试对象的运行并行地执行测试脚本；

串行接口，串行连接到所述测试环境，以便获得来自所述测试环境的反馈信息；

异常事件获取组件，通过向所述串行接口下发与被测试对象运行不相关的字符串，并在测试脚本执行到TEARDOWN阶段时，经由所述串行接口通过命令行对业务板卡中的逻辑存储器进行读取，并由此通过反馈的信息来判断主主控组件的异常事件以及备主控组件的异常事件，并对异常事件进行分类，并将读取数据与正常值进行对比，以便当与正常值不一致时，则判断业务板卡或其中的FPGA发生了挂死，反之则判断为正常；以及

重启组件，在主主控组件出现异常事件时，在先重启主主控组件后重启备主控组件，以及在仅备主控组件出现异常事件时，重启备主控组件，或者在业务板卡出现异常事件时，对业务板卡执行热插拔操作，从而重启测试环境中出现异常事件的组件。

2.根据权利要求1所述的测试环境的自动恢复系统，还包括异常信息收集组件，基于异常事件的类型通过向所述串行接口发送回溯指令和读取指令，获取异常事件的信息或返回值。

3.一种测试环境的自动恢复方法，所述测试环境包括用于运行被测试对象的主主控组件、备主控组件以及业务板卡，所述自动恢复方法包括：

在脚本执行组件与被测试对象的运行并行地执行测试脚本过程中，通过串行连接到所述测试环境的串行接口获得来自所述测试环境的反馈信息；

通过向所述串行接口下发与被测试对象运行不相关的字符串，并在测试脚本执行到TEARDOWN阶段时，经由所述串行接口通过命令行对业务板卡中的逻辑存储器进行读取，并由此通过反馈的信息来判断主主控组件的异常事件以及备主控组件的异常事件，并对异常事件进行分类，并将读取数据与正常值进行对比，以便当与正常值不一致时，则判断业务板卡或其中的FPGA发生了挂死，反之则判断为正常；以及

通过重启组件，在主主控组件出现异常事件时，在先重启主主控组件后重启备主控组件，以及在仅备主控组件出现异常事件时，重启备主控组件，或者在业务板卡出现异常事件时，对业务板卡执行热插拔操作，从而重启测试环境中出现异常事件的组件。

4.根据权利要求3所述的测试环境的自动恢复方法，还包括：

在重启发生异常事件的组件之前，通过异常信息收集组件基于异常事件的类型通过向所述串行接口发送回溯指令和读取指令，获取异常事件的信息或返回值。

Images