CN104424099B - 软件测试方法及系统 - Google Patents

Abstract

本发明实施例提供了一种软件测试方法及系统，所述测试方法包括：至少两个测试终端中的每个测试终端分别从测试任务数据集中获取未被执行过的单个测试任务；所述每个测试终端分别根据所述获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据集中记录所述所获取的测试任务的测试状态信息为处于测试状态；所述每个测试终端采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新所述测试任务的测试状态信息为已完成测试。采用所述测试方法及系统可以提高软件测试效率。

Description

软件测试方法及系统

技术领域

本发明涉及软件测试技术领域，尤其涉及一种软件测试方法及系统。

背景技术

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为整个软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。测试脚本一般是指一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。测试脚本按照一定的存放规则形成的集合称为测试脚本库。

传统的回归测试，通常是手工执行测试，通过人工调入测试脚本并执行。整个测试过程的测试时间T=单个脚本测试时间之和+人参加其中消耗的时间。

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。相比手工测试，通过自动化的测试方法具有更高效率。采用自动化测试方法，测试软件自动依次执行选定的测试脚本。整个测试过程的测试时间T=单个脚本测试时间之和。

但是，不论是手工测试，还是自动测试，都需要依次执行选定的测试脚本，因此在一次回归测试中含有大量测试脚本的情况时，回归测试将会消耗大量的时间，影响测试效率。

发明内容

本发明实施例解决的问题是如何提高软件测试效率。

为解决上述问题，本发明实施例提供一种软件测试方法，包括：

至少两个测试终端中的每个测试终端分别从测试任务数据集中获取未被执行过的单个测试任务；

所述每个测试终端分别根据所述获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据集中记录所述所获取的测试任务的测试状态信息为处于测试状态；

所述每个测试终端采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新所述测试任务的测试状态信息为已完成测试。

可选的，在所述测试任务数据集中记录所述所获取的测试任务的测试状态信息为处于测试状态时，还包括：

记录获取所述未测试脚本的测试终端的标识及与所述测试终端连接的承载器件的标识。

可选的，所述测试脚本库设置在所述测试终端、本地服务器或者网络侧的测试脚本库服务器上。

可选的，所述软件测试方法还包括：所述测试终端判断是否能够打开钥匙文件，并在打开钥匙文件时执行所述从测试脚本库中获取未测试脚本的操作。

可选的，所述软件测试方法还包括：所述测试终端在钥匙文件无法打开时，在预设次数阈值内进行随机时长的延迟，继续打开钥匙文件，并在打开次数超过所述预设次数阈值时，取消所述软件测试。

可选的，所述软件测试方法还包括：对于处于测试状态中的测试脚本，当接收到强制退出的指令时，设置强制退出标识并结束对所述软件的测试。

可选的，所述软件测试方法还包括：通过测试管理机将所述测试任务数据集发布至测试数据服务器。

可选的，所述软件测试方法还包括：通过测试管理机监控所述测试任务的测试信息。

为解决上述问题，本发明实施例还提供了一种软件测试系统，包括：至少两个测试终端，分别与承载有待测对象的承载器件连接，用于分别从测试任务数据集中获取未被执行过的单个测试任务，并分别根据所述获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据集中记录所述获取的未测试脚本的测试状态信息为处于测试状态，并采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新测试状态信息为已完成测试。

可选的，所述测试任务数据集分别存储在至少一个测试终端中。

可选的，所述测试终端还在所述测试任务数据集中记录与所述测试终端连接的承载器件的标识。

可选的，所述软件测试系统还包括：测试数据服务器，分别与所述各个测试终端连接，用于存储所述测试任务数据集。

可选的，所述测试终端还用于在所述所获取的测试任务的测试状态信息为处于测试状态时，在所述测试任务数据集中记录所述测试终端的标识以及与所述测试终端连接的承载器件的标识。

可选的，所述软件测试系统还包括：测试管理机，用于在软件测试前将所述测试任务数据集发布到所述测试数据服务器中。

可选的，所述测试管理机还用于监控所述测试任务的测试信息。

可选的，所述软件测试系统还包括：测试脚本库服务器，分别与所述测试终端连接，用于存储所述测试脚本。

可见，通过两个或两个以上的测试终端分别从测试任务数据集中获取未被执行过的单个测试任务，获取到所述单个测试任务对应的未测试脚本，且在测试任务数据集中记录所述所获取的测试任务的测试状态信息为处于测试状态，并采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，由于各个测试终端通过测试状态信息可以识别出未被测试的测试脚本，从而可以对各个测试任务进行并行测试，因此可以提高测试效率。

进一步地，在所述测试任务数据集中记录所述所获取的测试任务的状态信息为处于测试状态时，记录获取所述未测试脚本的测试终端的标识及与所述测试终端连接的测试对象的标识，可以更快速地识别出哪个测试终端对应的待测对象发生了错误，便于排除由于测试终端、承载器件等的硬件原因或者网络连接故障等非测试软件本身原因导致的错误，使得测试人员可以更快速地识别出测试错误出现的原因，从而可以进一步提高软件测试效率。

通过将测试脚本库设置在本地服务器或者网络侧的测试脚本库服务器，可以节约各个测试终端的存储资源，且可保证测试版本的统一性，避免由于测试版本引发的错误。

通过钥匙文件进行身份验证，可以增强测试的安全性能。

而对于处于测试状态中的测试脚本，当接收到强制退出的指令时，设置强制退出标识并结束对所述软件的测试，使得测试人员可以对测试进程进行控制，或者可以强制结束无法完成的测试，可以方便测试人员使用。

此外，通过测试管理机将测试任务数据集发布至测试数据服务器，或者通过测试管理机监控测试任务的测试信息，使得测试人员可以同时对多台测试终端的运行状况进行很好的监控，对整个测试进程进行管理，因此上述方案可以更方便测试人员使用。

附图说明

图1是本发明实施例中一种软件测试系统结构示意图；

图2是本发明实施例中一种软件测试方法流程图；

图3是本发明实施例中另一种软件测试系统结构示意图；

图4是本发明实施例中又一种软件测试系统结构示意图；

图5是本发明实施例中另一种软件测试方法流程图；

图6是本发明实施例中测试终端打开钥匙文件流程示意图；

图7是本发明实施例中测试终端获取测试任务的流程示意图；

图8是本发明实施例中强制退出软件测试流程图。

具体实施方式

在现有的软件回归测试中，不论是手工执行，还是自动执行，都是依次执行选定的每一个测试脚本，即各个测试脚本是串行执行，因此在一次回归测试中含有大量测试脚本时，回归测试将会消耗大量的时间，测试效率较低。

为解决上述问题，本发明实施例提供了一种软件测试方法及系统，在所述测试系统中，两个或两个以上的测试终端分别与承载有待测对象的承载器件连接，所述两个或两个以上的测试终端分别从测试任务数据集中获取未被执行过的单个测试任务，获取到单个测试任务对应的未测试脚本，且在测试任务数据集中记录所获取的测试任务的测试状态信息为处于测试状态，并采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试。由于各个测试终端通过测试任务数据集中的测试状态信息可以识别出未被识别的测试脚本，从而可以对各个测试任务进行并行测试，因此可以提高测试效率。

在具体实施中，所述测试任务数据集以及测试脚本库可以保存在测试终端上，也可以保存在测试终端之外的设备上，例如，所述测试任务数据集可以保存在本地服务器或者远程服务器中。所述测试脚本库也可以保存各个测试终端上，或者保存在本地服务器或者远程的测试脚本库服务器上。

为使本发明的上述目的、特征和优点能够更为明显易懂，下面结合附图对本发明的具体实施例做详细的说明。

参照图1所示的本发明实施例中一种软件测试系统结构示意图，所述软件测试系统100包括至少两个测试终端101，所述测试终端101分别与承载有待测对象的承载器件102连接，各个测试终端101之间可以相互连接，也可以没有连接关系。

在具体实施中，所述待测对象即为待测试软件，承载有所述待测试软件的承载器件可以为烧录了所述待测试软件的具体芯片产品，也可以为其他存储了所述待测试软件的产品。

所述至少两个测试终端101用于分别从测试任务数据集中获取未被执行过的单个测试任务，并分别根据所述获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据集中记录所述获取的未测试脚本的测试状态信息为处于测试状态，并采用所获取的未测试脚本对与所述测试终端连接的承载器件102中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新测试状态信息为已完成测试。

当各个测试终端之间没有连接关系时，每个测试终端中保存一个测试任务数据集，所述各个测试终端中保存的测试任务数据集可以相同，也可以不同。如果采用相同的测试任务数据集，预先为每个测试终端分配好需要执行的测试任务，可以根据每一项测试需要的测试时长、测试终端处理性能等进行分配。如果采用不同的测试任务数据集，可以在每个测试终端中设置所述测试终端对应的测试任务数据集。

当各个测试终端之间有连接关系时，可以仅在其中一个测试终端中存储各个测试终端需要的测试任务数据集。这样，在测试过程中，每个测试终端可以从保存了所述测试任务数据集的测试终端中获取未执行的单个测试任务，以及所述单个测试任务对应的测试脚本的路径，从而可以从测试脚本库中获取到对应的未测试脚本。将测试任务数据集保存在一个测试终端上，可以节约存储资源。

本实施例中，可以在每个测试终端中都保存一个测试脚本库，测试终端不需要从其他设备中获取测试脚本，可以提高测试效率，节约网络传输资源。

参照图2所示的软件测试方法流程图，以下具体说明上述测试系统的工作原理：

S201，每个测试终端分别从存储的测试任务数据集中获取未被执行过的单个测试任务。

S202，所述每个测试终端分别根据所述获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的测试脚本，在测试任务数据集中记录所述所获取的测试任务的状态信息为处于测试状态。

在具体实施中，测试任务数据集中设置需要测试终端执行的测试任务，每个测试任务可以对应一个测试脚本，因此可以直接在所述测试任务数据集中保存所述测试脚本的测试路径。

为了便于识别所述测试脚本是否被执行过，可以在所述测试任务数据集中记录所述测试脚本的测试状态信息。例如，可以设置所述测试脚本是否已经被执行或者执行中的标识信息。这样，测试终端在获取到一个未测试脚本后，即可将所述测试任务数据集中对应的测试状态信息更新为处于测试状态或者相应的标识信息。

S203，所述每个测试终端采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新所述测试任务的测试状态信息为已完成测试。

可以理解的是，在具体应用过程中，可能出现有些测试故障，导致测试无法完成的情况（例如陷入死循环），或者测试人员需要临时退出测试，为解决这一问题，方便用户使用，当接收到输入的强制退出的指令时，可以设置强制退出标识，并结束对所述软件的测试。

从本实施例可以看出，通过多个测试终端并行执行测试任务，相对于一个测试设备独立运行的情况，可以提高测试效率。

在具体实施中，上述多个测试终端可以分布在不同的地点，通过分布式设置测试终端，可以实现不同区域的测试人员对软件同时进行测试，因此可以进一步提高测试效率。

参照图3所示的本发明实施例中的另一种软件测试系统结构示意图，所述软件测试系统包括多个测试终端301，分别与所述测试终端301连接的承载有待测对象的承载器件302，以及分别与所述测试终端连接的测试数据服务器303。

与前述实施例的不同之处在于，各个测试终端还分别与测试数据服务器相连，其中测试数据服务器中可以保存统一的测试任务数据集，所述测试任务数据集中除了存储每个测试任务对应的测试脚本的存储路径以及所述测试脚本的测试状态外，还可以存储测试每个脚本的测试终端的标识，以及与所述测试终端连接的承载器件的标识。

在软件测试过程中，测试终端根据测试任务数据集中的测试状态信息获取到处于未测试状态的测试脚本时，即可将所述测试脚本的测试状态信息修改为处于测试状态，并记录所述获取所述未测试脚本的测试终端的标识，以及与所述测试终端连接的承载器件的标识。

通过修改测试任务数据集中的测试状态信息，可以避免各个测试终端之间重复获取同一测试脚本，实现各个测试终端的并行测试。而记录获取测试脚本的测试终端的标识，可以快速识别出哪个测试终端对应的待测对象发生了错误，便于排除由于测试终端、承载器件等的硬件原因，或者网络连接故障等非测试软件本身原因导致的错误，可以使测试人员更快速地识别出测试错误出现的原因，进一步提高软件测试效率。

在本实施例中，测试脚本库可以设置在所述测试终端中，也可以设置在测试数据服务器中。在具体实施中，也可以将测试数据服务器中的测试脚本库同步到各个测试终端之后再进行软件测试。

测试终端在每完成一项测试任务后，可以在所述测试任务数据集中记录下所述测试任务对应的测试结果，更新所述测试任务的测试状态信息。为便于测试人员分析统计，如果测试结果失败，还可以给出测试失败的原因给出每一项测试任务的执行时间等。例如，测试人员根据测试执行时间可以判断测试结果是否正常，以及判断软件是否有进一步优化的空间等。

在测试过程中，每个测试终端上可以实时显示测试进程，以对软件测试过程进行更好的监控。例如，可以根据测试人员需要，显示所选取的待测试软件的名称及版本号、测试终端状态、当前执行脚本、当前脚本执行时间，总脚本数、当前版本序号，总体测试进度等其中一项或多项信息。

还可以在测试终端控制界面中设置专门的控制按钮来控制测试进程，例如，可以设置其中测试终端按钮启动测试，还可以设置关闭测试按钮用于测试人员强制关闭正在进行中的测试任务。

在具体实施中，为了更好地对多个测试终端进行管理，可以设置专门的测试管理机，参照图4所示的本发明实施例中的又一种软件测试系统结构示意图，包括至少两个测试终端401，分别与所述测试终端401连接的测试数据服务器403以及测试管理机404，测试管理机404通过有线或者无线网络也可以与测试数据服务器403连接，每个测试终端401与一个承载有待测对象的承载器件402连接。

在测试前，可以由测试管理机404将所述测试任务数据集发布至测试数据服务器。在测试过程中，测试管理机可以对所有测试终端的测试任务的测试信息进行监控。例如，可以向测试人员显示完成的测试脚本数，以及完成的测试脚本中通过测试的个数和失败的个数，总共需要测试的测试脚本数，以及已完成比例，还可以实时显示每个测试终端中当前测试的测试脚本的名称或路径等标识信息。可以自动刷新测试状态，也可以由用户手动刷新。

在本发明实施例中，测试任务数据集可以是一个xls表格文件的形式，也可以是其他的文件形式或者是数据库形式，以下实施例中以一个xls表格文件的形式进行说明：

参照图5所示的软件测试方法流程图，以下通过具体步骤进行详细说明：

S501，测试终端判断钥匙文件是否能够打开，如果是，则执行步骤S502；如果否，则结束测试流程。

本实施例中，测试任务列表是一个xls表格文件的形式，可以使用一个txt文本作为多个测试终端互斥访问所述xls表格文件的钥匙文件。

S502，测试终端访问测试数据服务器，打开测试任务列表文件。

在具体实施中，需要测试的任务可以放置在一个xls表格文件中，所有需要测试的任务可以保存在一个数据表中，也可以保存在多个数据表中，例如，各个测试任务分别保存在一个独立的数据表中。

S503，测试终端从测试任务列表中找到选取的测试任务数据表。

S504，判断所述测试任务数据表中是否还有未测试脚本，如果是，则执行步骤S505；如果否，则执行步骤S515。

在具体实施中，可以在测试任务数据表中针对每个测试任务，可以将所述测试任务对应的测试脚本的测试路径作为所述测试任务的标识。

还可以在所述测试任务数据表中设置测试任务的测试状态信息，通过设置测试状态信息或者相应的标识信息，识别所述测试任务对应的测试脚本是否被使用。例如，如果测试任务数据表中所述测试任务对应的测试状态信息栏显示为空或者“处于未测试状态”，则将所述测试任务对应的测试脚本作为未测试脚本。

S505，所述测试终端根据从所述获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据表中记录所述所获取的测试任务的测试状态信息。

在获取到未测试脚本后，将所述未测试脚本对应的测试状态信息更新为：处于测试状态。

本实施例中，还可以在所述测试任务数据表中记录获取所述未测试脚本的测试终端的标识，以及承载器件的标识。

S506，关闭测试任务列表。

S507，关闭钥匙文件。

S508，判断脚本是否解析成功，如果是，则执行步骤S509；如果否，则执行步骤S510。

S509，判断测试是否完成，如果是，则执行步骤S510；如果否，则执行步骤S518。

S510，钥匙文件是否成功打开，如果是，则执行步骤S511；如果否，则结束流程。

S511，打开测试任务列表。

S512，在所述测试任务列表中记录测试结果，更新所述测试任务的测试状态信息。

S513，关闭测试任务列表。

S514，关闭钥匙文件，并返回执行步骤S501，执行对下一个未测试脚本的测试。

S515，关闭测试任务列表。

S516，关闭钥匙文件。

S517，显示测试结束的提示信息。

S518，判断是否检测到强制退出标识，如果是，则执行步骤S519；如果否，则执行步骤S509。

S519，判断钥匙文件是否能够成功打开，如果是，则执行步骤S518；如果否，则结束测试流程。

S520，打开钥匙文件。

S521，打开测试任务列表。

S522，清除所述测试任务对应的测试状态信息。

S523，关闭测试任务列表。

S524，关闭钥匙文件。

S525，退出测试软件。

本实施例中，打开所述钥匙文件是作为可以打开测试任务列表的前提条件，即：如果可以打开所述钥匙文件，则可进一步执行打开测试任务列表的操作，如果不能打开所述钥匙文件，则无法进一步执行打开测试任务列表的操作，因此称为钥匙文件。而如果其中一个测试终端正在访问所述钥匙文件，则其他测试终端无法访问所述钥匙文件，因此也无法同时打开所述测试任务列表，故采用所述钥匙文件实现各个测试终端的互斥访问，避免各个测试终端同时抢占同一个未测试脚本。

从本实施例可以看出，通过设置钥匙文件，可以避免多个测试终端同时打开测试任务列表，抢占同一个未测试脚本，因此可以使资源分配更加合理，提高测试效率。而在获取到测试脚本时，通过在测试任务列表中记录获取所述测试脚本的测试终端的标识，以及与所述测试终端连接的承载器件的标识，可以使用户更快速地识别出哪个测试终端对应的带测对象发生了错误，也可以排除由于测试终端、承载器件等的硬件原因，或者网络连接故障等非测试软件本身原因导致的错误，因此可以更快速地识别出测试错误出现的原因，提高软件测试效率。

为使本领域技术人员更好地理解和实现本发明实施例，以下通过一个测试终端的访问过程来说明如何通过钥匙文件来实现各个测试终端的互斥访问，参照图6，具体步骤如下：

S601，测试终端打开钥匙文件。

S602，钥匙文件是否成功打开，如果是，则执行步骤S603；如果否，则执行步骤S604。

S603，测试终端退出访问钥匙文件的子程序。

S604，随机延时0～1s。

S605，判断尝试次数是否超过100次，如果是，则执行步骤S606；如果否，则执行步骤S601。

S606，显示报错信息并退出。

如果钥匙文件能够成功打开，则说明当前没有别的测试终端访问测试任务列表；如果当前钥匙文件无法成功打开，则认为当前时刻有别的测试终端访问所述测试任务列表，通过设置一个小的时延，例如本实施例中的1s以内的随机时延，之后再次访问，即可避免多个测试终端同时抢占一个未测试脚本的情况出现。而为每个测试终端的连续访问次数设置一个预设次数阈值，例如本实施例中的所设置的100次，可以适应测试终端较多的情况，以避免所有测试终端中的任意两个测试终端抢占资源的情况方式，从而可以更合理地利用资源，提高资源利用效率。

参照图7，为本发明实施例中测试终端获取测试任务的流程图，具体包括如下步骤：

S701，测试终端在启动后访问测试任务列表，判断钥匙文件是否能够成功打开，如果是，则执行步骤S702；如果否，则执行步骤S706。

在具体实施中，可以在一个测试任务列表中保存多个项目的测试任务，每个测试项目的每个测试任务可以采用一个独立的测试任务数据表进行保存。

S702，测试终端打开测试任务列表。

S703，测试终端遍历读取测试任务数据表，选择下拉组合框。

测试终端访问测试任务数据表，读取测试任务数据表的标识，例如测试任务数据表的名称，填充到测试终端的任务执行的下拉框中，用户可以根据下拉框中的信息，选择本次测试哪个任务。

S704，打开测试任务数据表。

S705，关闭钥匙文件。

S706，显示报错信息。

在具体应用中，用户通过本发明实施例中的方法即可在各个测试终端选择各个测试终端所需要执行的测试任务，之后各个测试终端即可按照图5所示的测试流程执行软件测试。

在如图5所示的软件测试过程中，也可以根据需要强制退出软件测试参照图8所示的本发明实施例中强制退出软件测试流程图，具体可以按照以下步骤执行：

S801，接收到用户输入的强制退出指令，则执行步骤S802。

在具体实施中，可以在测试终端设置专门的测试界面接收用户输入的操作指令，例如强制关闭或者退出指令。

S802，确定软件测试是否已经启动运行且尚未结束，如果是，则执行步骤S803；如果否，则执行步骤S805。

S803，确认是否强制退出，如果是，则执行步骤S804，如果否，则结束流程。

S804，设置强制退出标识并退出。

通过设置强制退出标识，如图5所示的步骤S516，测试终端在检测到强制退出标识时，则可执行后续步骤，退出对所述测试任务的测试，并清除测试任务列表中的测试状态信息，使得其他测试终端可以对所述测试任务进行测试。

S805，测试终端上运行的测试软件退出。

通过强制退出可以在整个测试任务未完成的情况下，使某个测试终端退出对某个测试任务的测试，在对多个测试项目进行测试时，可以采用上述强制退出的方式调节投入的测试终端的个数，合理分配测试终端。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims (15)

1.一种软件测试方法，其特征在于，包括：

至少两个测试终端中的每个测试终端分别判断钥匙文件是否能够打开，并在确定钥匙文件能够打开时，打开所述钥匙文件，并打开所述钥匙文件对应的测试任务数据集，从所述测试任务数据集中获取未被执行过的单个测试任务；

所述每个测试终端分别根据获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据集中记录所获取的测试任务的测试状态信息为处于测试状态；

所述每个测试终端采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新所述测试任务的测试状态信息为已完成测试；

关闭测试任务数据集；

关闭所述测试任务数据集对应的钥匙文件；

其中，所述钥匙文件在被一个测试终端访问时，其他测试终端无法打开所述钥匙文件以及所述钥匙文件对应的测试任务数据集。

2.如权利要求1所述的软件测试方法，其特征在于，在所述测试任务数据集中记录所获取的测试任务的测试状态信息为处于测试状态时，还包括：

记录所获取的未测试脚本的测试终端的标识及与所述测试终端连接的承载器件的标识。

3.如权利要求1所述的软件测试方法，其特征在于，所述测试脚本库设置在所述测试终端、本地服务器或者网络侧的测试脚本库服务器上。

4.如权利要求1所述的软件测试方法，其特征在于，还包括：所述测试终端在钥匙文件无法打开时，在预设次数阈值内进行随机时长的延迟，继续打开钥匙文件，并在打开次数超过所述预设次数阈值时，取消所述软件测试。

5.如权利要求1所述的软件测试方法，其特征在于，还包括：

对于处于测试状态中的测试脚本，当接收到强制退出的指令时，设置强制退出标识并结束对所述软件的测试。

6.如权利要求1所述的软件测试方法，其特征在于，还包括：

通过测试管理机将所述测试任务数据集发布至测试数据服务器。

7.如权利要求6所述的软件测试方法，其特征在于，还包括：

通过测试管理机监控所述测试任务的测试信息。

8.一种软件测试系统，其特征在于，包括：至少两个测试终端，分别与承载有待测对象的承载器件连接，用于分别判断钥匙文件是否能够打开，并在确定钥匙文件能够打开时，打开所述钥匙文件，并打开所述钥匙文件对应的测试任务数据集，从所述测试任务数据集中获取未被执行过的单个测试任务，并分别根据获取到的未被执行过的单个测试任务对应的测试脚本的路径，分别从测试脚本库中获取对应的未测试脚本，在测试任务数据集中记录获取的未测试脚本的测试状态信息为处于测试状态，并采用所获取的未测试脚本对与所述测试终端连接的承载器件中的待测对象进行测试，在所述测试任务数据集中记录所述测试任务的测试结果信息，并更新测试状态信息为已完成测试，之后，依次关闭测试任务数据集，关闭所述测试任务数据集对应的钥匙文件；其中，所述钥匙文件在被一个测试终端访问时，其他测试终端无法打开所述钥匙文件以及所述钥匙文件对应的测试任务数据集。

9.如权利要求8所述的软件测试系统，其特征在于，所述测试任务数据集分别存储在至少一个测试终端中。

10.如权利要求9所述的软件测试系统，其特征在于，所述测试终端还在所述测试任务数据集中记录与所述测试终端连接的承载器件的标识。

11.如权利要求8所述的软件测试系统，其特征在于，还包括：测试数据服务器，分别与所述测试终端连接，用于存储所述测试任务数据集。

12.如权利要求11所述的软件测试系统，其特征在于，所述测试终端还用于在所获取的测试任务的测试状态信息为处于测试状态时，在所述测试任务数据集中记录所述测试终端的标识以及与所述测试终端连接的承载器件的标识。

13.如权利要求11所述的软件测试系统，其特征在于，还包括：测试管理机，用于在软件测试前将所述测试任务数据集发布到所述测试数据服务器中。

14.如权利要求13所述的软件测试系统，其特征在于，所述测试管理机还用于监控所述测试任务的测试信息。

15.如权利要求8所述的软件测试系统，其特征在于，还包括：测试脚本库服务器，分别与所述测试终端连接，用于存储所述测试脚本。