CN107368395B - 自动化测试的方法及系统 - Google Patents

Abstract

本发明公开了一种自动化测试的方法及系统，涉及数据加密技术领域，为解决现有测试方式耗费大量时间和精力的问题而发明。本发明的方法包括：所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。本发明适合应用在硬件锁测试的过程中。

Description

自动化测试的方法及系统

技术领域

本发明涉及数据加密技术领域，尤其涉及一种自动化测试的方法及系统。

背景技术

软件开发商为了保护软件，防止他人购买盗版软件，以及非法破解软件，通常会对软件进行加密保护。目前常用的对软件加密保护的方式有采用如软件锁、硬件锁、云锁等加密锁对软件加密。对于任何一种锁的发布或者版本的升级都需要对其进行测试。其中，硬件锁的测试通常包括在常用的多种操作系统上进行安装服务组件，插入硬件锁后，测试硬件锁是否被正确检测，服务组件服务是否正确开启等等。目前硬件锁的测试主要是由人工完成的，因此整个测试过程需要花费大量时间和精力，使测试的效率较低。

发明内容

鉴于上述问题，本发明提供一种自动化测试的方法及系统，为了提高硬件锁测试的效率。

为解决上述技术问题，第一方面，本发明提供了一种自动化测试的方法，所述方法应用于自动测试框架中，所述自动测试框架包括一台控制机和至少一台测试机，所述控制机和所述测试机均安装有软件测试自动化框架staf，所述方法包括：

所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；

在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；

所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述方法还包括：

所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

覆盖安装后，所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送重启命令；

所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别，包括：

所述控制机通过staf向所述各个测试机发送调用python程序的命令；

所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

第二方面，本发明还提供了一种自动化测试的系统，所述系统应用于自动测试框架中，所述自动测试框架包括一台控制机和至少一台测试机，所述控制机和所述测试机均安装有软件测试自动化框架staf，所述系统包括：

发送单元，用于所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；

安装单元，用于在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；

检查单元，用于所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述系统还包括：

覆盖安装单元，用于所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

所述检查单元，还用于所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述系统还包括：

重启单元，用于所述控制机通过staf向所述各个测试机发送重启命令；

所述检查单元，还用于所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述系统还包括：

关机重启单元，用于所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述检查单元，还用于所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述系统还包括：

休眠重启单元，用于所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述检查单元，还用于所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

可选的，所述检查单元包括：

第一发送模块，用于所述控制机通过staf向所述各个测试机发送调用python程序的命令；

第一检查模块，用于所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

第二发送模块，用于所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

第二检查模块，用于所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

借由上述技术方案，本发明提供的自动化测试的方法及系统，构造了一套自动化测试框架，该自动化测试框架能够使用软件测试自动化框架staf中的命令，实现控制机向不同操作系统的测试机发送测试相关的命令，使测试机可以根据发送的命令自动执行相应的测试操作，整个测试过程中不需要人工的干预，因此大大的节省了测试的时间和精力，提高了测试的效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种自动化测试的方法流程图；

图2示出了本发明实施例提供的另一种自动化测试的方法流程图；

图3示出了本发明实施例提供的一种自动化测试的系统的组成框图；

图4示出了本发明实施例提供的另一种自动化测试的系统的组成框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了提高硬件锁测试的效率，本发明实施例提供了一种自动化测试的方法，如图1所示，该方法包括：

首先需要说明的是，本实施例中的方法应用于自动测试框架中，该自动测试框架包括一台控制机和至少一台测试机，所述控制机和所述测试机均安装有软件测试自动化框架staf。

101、控制机通过staf的发送文件命令，将服务组件发送给各个测试机。

首先需要说明的是，本实施例中的软件自动化框架staf是在开源的STAF(Software TestAutomation Framework)框架的基础上构建的自动化测试方案。本步骤中的各个测试机分别装有不同的操作系统，由于被测试的服务组件发布后可能会应用到不同的操作系统中，因此需要在发布前在所有可能的操作系统上进行测试，本步骤中的不同的操作系统包含目前常用的操作系统。另外需要说明的是，各个测试机中都安装有staf，本实施例中服务组件为使用硬件锁加密所需的许可工具，其中服务组件用于与硬件锁通信。本实施例中不仅对服务组件进行测试，同时也对硬件锁的识别等进行测试。

使用staf的发送文件命令，将服务组件发送给多个计算机，是为了使各个测试机能够进行服务组件的安装，本步骤中发送的服务组件是指服务组件对应的安装包。

102、在各个测试机上插入硬件锁后，控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中。

由步骤101可知，服务组件用于与硬件锁通信，因此服务组件的测试需要事先将硬件锁插入到各个测试机上。由步骤101可知，每个测试机中已经接收到了服务组件的安装包，因此在控制机通过staf发送执行静默安装命令后，会自动根据服务组件的安装包将服务组件安装到每个测试机中。

本步骤中的静默安装命令是指安装时无需任何用户干预，直接按默认设置安装，这样也是保证了在整个的测试过程中不需要任何的人工干预。

103、各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

在发送执行静默安装命令之后，等待预设时段后，即等待服务组件安装完成后，自动触发各个测试机检测安装的服务组件是否可以正常启动，具体的对于是否能够正常启动的判断是通过返回的检查结果判定的。同时还需要检查插入的与服务组件通信的硬件锁是否可以被正常识别，硬件锁是否可以被正常识别的判断，也是通过返回的检查结果判定的。具体的判断服务组件是否正常启动以及硬件锁是否被正常识别的的原理与通常的软件测试中测试软件正常启动以及硬件被识别的原理的是相同的。

本发明实施例提供的自动化测试的方法，构造了一套自动化测试框架，该自动化测试框架能够使用软件测试自动化框架staf中的命令，实现控制机向不同操作系统的测试机发送测试相关的命令，使测试机可以根据发送的命令自动执行相应的测试操作，整个测试过程中不需要人工的干预，因此大大的节省了测试的时间和精力，提高了测试的效率。

进一步的，作为对图1所示实施例的细化及扩展，本发明实施例还提供了另一种自动化测试的方法，如图2所示。

201、控制机通过staf的发送文件命令，将服务组件发送给各个测试机。

本步骤的实现方式与图1步骤101的实现方式相同，此处不再赘述。

202、在各个测试机插入硬件锁后，控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中。

本步骤的实现方式与图1步骤102的实现方式相同，此处不再赘述。

203、控制机通过staf向各个测试机发送调用python程序的命令，使各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动。

调用python程序是为了检查测试机中安装的服务组件的版本是否正确，具体的检查测试机中安装的服务组件的版本是否正确是检查安装的服务组件的主程序的版本号是否正确，判断的依据是获取主程序的版本号并与正确的版本号进行比对，若一致则正确，若不一致则不正确。正确的版本号是根据实际的需求设定的。若版本号不正确，则无需对服务组件是否能够正常启动进行检查；若版本号正确，则继续检查服务组件是否正常启动。检查服务组件是否正常启动包括检查服务组件是否可以正常打开以及打开后服务是否能够正常启动，在实际应用中检查服务组件是否正常启动的方式可以是任意一种测试软件是否正常启动的方式，本实施例中给出一种检查服务组件是否能够正常启动的方式：启动服务组件的主程序，判断是否可以正常启动，若可以正常启动则表示服务组件可以正常打开；在服务组件打开后，查找服务组件对应的监听端口，判断是否可以成功连接到该监听端口，若可以成功连接到该监听端口，则表示服务组件服务可以正常启动。其中，需要说明的是，通常软件在开发时会设置默认的监听端口。

另外，无论计算机中安装的服务组件的版本是否正确以及服务组件是否正确启动，都会返回对应的提示信息供参考。

204、控制机通过staf向各个测试机发送调用硬件锁接口程序的命令，使各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

由于本实施例中的服务组件用于与硬件锁通信，因此在检查服务组件可以正常启动后，还需要检查插入的硬件锁是否可以正常识别。具体的检查硬件锁是否可以正常识别的方式为：发送运行调用硬件锁接口(Application Program Interface，API)程序，调用硬件锁API程序不限定是某一种具体的程序，只要是在运行时可以调用硬件锁API的程序即可，为了测试的简便，通常会选择较简单的硬件锁的使用实例作为调用硬件锁API的程序。在调用硬件锁API程序运行后，根据程序的运行结果判断硬件锁是否是否可以被正常识别，具体在对于调用硬件锁API程序会设置预设的正确运行结果，因此在获取当前运行结果后，将当前运行结果与预设正确运行结果进行比对，若一致则表示硬件锁可以被正常识别，若不一致则表示硬件锁无法正常识别。无论硬件锁是否可以被正常识别，都会返回相应的提示信息供参考。

205、控制机通过staf再次向各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中。

本步骤是覆盖安装测试，由于一个软件在初始开发后，通常会不断更新版本来满足用户更多的需求。在版本更新时会涉及覆盖安装，因此本实施例中的服务组件也需要进行覆盖安装测试。具体的测试过程为：控制机通过staf再次向各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中。本步骤的具体的实现方式与步骤202的实现方式相同，此处不再赘述。

206、覆盖安装后，各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

覆盖安装后还需要重新进行安装的服务组件是否正常启动以及硬件锁是否被正常识别的检查，具体的检查的过程与上述步骤203以及步骤204中检查服务组件是否正常启动以及硬件锁是否被正常识别的方式相同，此处不再赘述。

207、控制机通过staf向各个测试机发送重启命令。

在实际的应用中，因为会存在软件在第一次安装正常，然后重启启动计算机后，出现软件无法正常启动等问题。因此为了避免在用户使用服务组件过程中发生上述的问题，需要发送重启命令，为了后续检查测试机在重启后已经安装的服务组件是否还可以正常的启动以及硬件锁是否还可以被正常识别。

208、各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

测试机重启后自动安装的服务组件是否正常启动以及硬件锁是否被正常识别的方式与上述步骤203以及步骤204中检查服务组件是否正常启动以及硬件锁是否被正常识别的方式相同，此处不再赘述。

209、控制机通过staf向各个测试机发送关机命令，并在经过第一预设时段后继续向各个测试机发送开机命令。

在实际的应用中，因为会存在软件在第一次安装正常，然后关机重新启动计算机后，出现无法正常启动等问题。所以需要在服务组件安装后，还需要进行关机重启测试。具体的步骤209以及210就是测试在测试机关机重启后已经安装的服务组件是否可以继续正常启动以及硬件锁是否可以被正常识别。

本步骤中测试机的关机以及重启都是根据命令自动进行的，这样才可以保证整个测试过程的自动化。测试机关机后重启时需要通过唤醒网卡实现计算机的重启，因此需要发送网卡唤醒命令来使测试机重启。其中第一预设时段是根据正常的关机时间设置的，第一预设时段一定大于正常的关机时间，比如第一预设时段可以设置为5min、10min或者其他时长，实际应用中可以根据需求自由设定。

210、各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

测试机关机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别的方式与上述步骤203以及步骤204中检查服务组件是否正常启动以及硬件锁是否被正常识别的方式相同，此处不再赘述。

211、控制机通过staf向各个测试机发送休眠命令，并在经过第二预设时段后继续向各个测试机发送唤醒命令。

在实际的应用中，因为会存在软件在第一次安装正常，然后在计算机休眠重新唤醒后，出现无法正常启动等问题。所以需要在服务组件安装后，还需要进行休眠重启测试。具体步骤211以及212就是测试在测试机休眠重启后已经安装的服务组件是否可以继续正常启动以及硬件锁是否可以被正常识别。

本步骤中测试机的休眠以及重启都是根据命令自动进行的，这样才可以保证整个测试过程的自动化。测试机休眠后重启时通过唤醒网卡实现计算机的重启，因此需要发送网卡唤醒命令来使测试机重启。其中第二预设时段可以根据需求自由设定设置，比如可以设置为5min、10min或者其他时长。

212、各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

测试机休眠重新运行后自动检查测试机中安装的服务组件是否正常启动以及硬件锁是否被正常识别的方式与上述步骤203以及步骤204中检查服务组件是否正常启动以及硬件锁是否被正常识别的方式相同，此处不再赘述。

进一步的，作为对上述图1和图2所示方法的实现，本发明实施例另一实施例还提供了一种自动化测试的系统，用于对上述图1和图2所示的方法进行实现。该系统实施例与前述方法实施例对应，为便于阅读，本系统实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的系统能够对应实现前述方法实施例中的全部内容。如图3所示，该系统包括：发送单元31、安装单元32以及检查单元33。

发送单元31，用于所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；

首先需要说明的是，本实施例中的软件自动化框架staf是在开源的STAF(Software TestAutomation Framework)框架的基础上构建的自动化测试方案。本步骤中的各个测试机分别装有不同的操作系统，由于被测试的服务组件发布后可能会应用到不同的操作系统中，因此需要在发布前在所有可能的操作系统上进行测试，本步骤中的不同的操作系统包含目前常用的操作系统。另外需要说明的是，各个测试机中都安装有staf，本实施例中服务组件为使用硬件锁加密所需的许可工具，其中服务组件用于与硬件锁通信。本实施例中不仅对服务组件进行测试，同时也对硬件锁的识别等进行测试。

使用staf的发送文件命令，将服务组件发送给多个计算机，是为了使各个测试机能够进行服务组件的安装，本步骤中发送的服务组件是指服务组件对应的安装包。

安装单元32，用于在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；

由于服务组件用于与硬件锁通信，因此服务组件的测试需要事先将硬件锁插入到各个测试机上。由发送单元31可知，每个测试机中已经接收到了服务组件的安装包，因此在控制机通过staf发送执行静默安装命令后，会自动根据服务组件的安装包将服务组件安装到每个测试机中。

其中静默安装命令是指安装时无需任何用户干预，直接按默认设置安装，这样也是保证了在整个的测试过程中不需要任何的人工干预。

检查单元33，用于所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

在发送执行静默安装命令之后，等待预设时段后，即等待服务组件安装完成后，自动触发各个测试机检测安装的服务组件是否可以正常启动，具体的对于是否能够正常启动的判断是通过返回的检查结果判定的。同时还需要检查插入的与服务组件通信的硬件锁是否可以被正常识别，硬件锁是否可以被正常识别的判断，也是通过返回的检查结果判定的。具体的判断服务组件是否正常启动以及硬件锁是否被正常识别的的原理与通常的软件测试中测试软件正常启动以及硬件被识别的原理的是相同的。

如图4所示，所述系统还包括：

覆盖安装单元34，用于所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

所述检查单元33，还用于所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

如图4所示，所述系统还包括：

重启单元35，用于所述控制机通过staf向所述各个测试机发送重启命令；

所述检查单元33，还用于所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

如图4所示，所述系统还包括：

关机重启单元36，用于所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述检查单元33，还用于所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

如图4所示，所述系统还包括：

休眠重启单元37，用于所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述检查单元33，还用于所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

如图4所示，所述检查单元33包括：

第一发送模块331，用于所述控制机通过staf向所述各个测试机发送调用python程序的命令；

第一检查模块332，用于所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

调用python程序是为了检查测试机中安装的服务组件的版本是否正确，具体的检查测试机中安装的服务组件的版本是否正确是检查安装的服务组件的主程序的版本号是否正确，判断的依据是获取主程序的版本号并与正确的版本号进行比对，若一致则正确，若不一致则不正确。正确的版本号是根据实际的需求设定的。若版本号不正确，则无需对服务组件是否能够正常启动进行检查；若版本号正确，则继续检查服务组件是否正常启动。检查服务组件是否正常启动包括检查服务组件是否可以正常打开以及打开后服务是否能够正常启动，在实际应用中检查服务组件是否正常启动的方式可以是任意一种测试软件是否正常启动的方式，本实施例中给出一种检查服务组件是否能够正常启动的方式：启动服务组件的主程序，判断是否可以正常启动，若可以正常启动则表示服务组件可以正常打开；在服务组件打开后，查找服务组件对应的监听端口，判断是否可以成功连接到该监听端口，若可以成功连接到该监听端口，则表示服务组件服务可以正常启动。其中，需要说明的是，通常软件在开发时会设置默认的监听端口。

另外，无论计算机中安装的服务组件的版本是否正确以及服务组件是否正确启动，都会返回对应的提示信息供参考。

第二发送模块333，用于所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

第二检查模块334，用于所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

由于本实施例中的服务组件用于与硬件锁通信，因此在检查服务组件可以正常启动后，还需要检查插入的硬件锁是否可以正常识别。具体的检查硬件锁是否可以正常识别的方式为：发送运行调用硬件锁接口(Application Program Interface，API)程序，调用硬件锁API程序不限定是某一种具体的程序，只要是在运行时可以调用硬件锁API的程序即可，为了测试的简便，通常会选择较简单的硬件锁的使用实例作为调用硬件锁API的程序。在调用硬件锁API程序运行后，根据程序的运行结果判断硬件锁是否是否可以被正常识别，具体在对于调用硬件锁API程序会设置预设的正确运行结果，因此在获取当前运行结果后，将当前运行结果与预设正确运行结果进行比对，若一致则表示硬件锁可以被正常识别，若不一致则表示硬件锁无法正常识别。无论硬件锁是否可以被正常识别，都会返回相应的提示信息供参考。

本发明实施例提供的自动化测试的系统，构造了一套自动化测试框架，该自动化测试框架能够使用软件测试自动化框架staf中的命令，实现控制机向不同操作系统的测试机发送测试相关的命令，使测试机可以根据发送的命令自动执行相应的测试操作，整个测试过程中不需要人工的干预，因此大大的节省了测试的时间和精力，提高了测试的效率。

所述自动化测试系统包括处理器和存储器，上述发送单元31、安装单元32以及检查单元33等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来提高用户需求分析结果的准确性。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash

RAM)，存储器包括至少一个存储芯片。

本发明实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，可选的，所述方法还包括：

所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

覆盖安装后，所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送重启命令；

所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别，包括：

所述控制机通过staf向所述各个测试机发送调用python程序的命令；

所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

本发明实施例中的设备可以是服务器、PC、PAD、手机等。

本发明实施例还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，可选的，所述方法还包括：

所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

覆盖安装后，所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送重启命令；

所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述方法还包括：

所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

进一步的，所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别，包括：

所述控制机通过staf向所述各个测试机发送调用python程序的命令；

所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

1.一种自动化测试的方法，其特征在于，所述方法应用于自动测试框架中，所述自动测试框架包括一台控制机和至少一台测试机，所述控制机和所述测试机均安装有软件测试自动化框架staf，所述方法包括：

所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；

在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；

所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

覆盖安装后，所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述控制机通过staf向所述各个测试机发送重启命令；

所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别，包括：

所述控制机通过staf向所述各个测试机发送调用python程序的命令；

所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。

7.一种自动化测试的系统，其特征在于，所述系统应用于自动测试框架中，所述自动测试框架包括一台控制机和至少一台测试机，所述控制机和所述测试机均安装有软件测试自动化框架staf，所述系统包括：

发送单元，用于所述控制机通过staf的发送文件命令，将服务组件发送给各个测试机，其中，所述服务组件用于与硬件锁通信；

安装单元，用于在各个测试机插入硬件锁后，所述控制机通过staf向所述各个测试机发送执行静默安装命令，使服务组件安装到各个测试机中；

检查单元，用于所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

8.根据权利要求7所述的系统，其特征在于，所述系统还包括：

覆盖安装单元，用于所述控制机通过staf再次向所述各个测试机发送执行静默安装命令，使服务组件覆盖安装到各个测试机中；

所述检查单元，还用于所述各个测试机自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

9.根据权利要求7所述的系统，其特征在于，所述系统还包括：

重启单元，用于所述控制机通过staf向所述各个测试机发送重启命令；

所述检查单元，还用于所述各个测试机重启后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

10.根据权利要求7所述的系统，其特征在于，所述系统还包括：

关机重启单元，用于所述控制机通过staf向所述各个测试机发送关机命令，经过第一预设时段后所述控制机通过staf向所述各个测试机发送开机命令；

所述检查单元，还用于所述各个测试机再次开机后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

11.根据权利要求7所述的系统，其特征在于，所述系统还包括：

休眠重启单元，用于所述控制机通过staf向所述各个测试机发送休眠命令，经过第二预设时段后所述控制机通过staf向所述各个测试机发送唤醒命令；

所述检查单元，还用于所述各个测试机运行后自动检查安装的服务组件是否正常启动以及硬件锁是否被正常识别。

12.根据权利要求7至11中任一项所述的系统，其特征在于，所述检查单元包括：

第一发送模块，用于所述控制机通过staf向所述各个测试机发送调用python程序的命令；

第一检查模块，用于所述各个测试机接收到所述调用python程序的命令后，检查安装的服务组件的版本是否正确以及检查服务组件是否正确启动；

第二发送模块，用于所述控制机通过staf向所述各个测试机发送调用硬件锁接口程序的命令；

第二检查模块，用于所述各个测试机运行用于调用硬件锁接口的程序，以检查插入的硬件锁是否正常识别。