CN106933709B - 一种测试方法及装置 - Google Patents

Abstract

本申请实施例公开了一种测试方法及装置，涉及计算机技术领域，其中，上述方法包括：获得测试资源，并确定待测试服务器，其中，所述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件；向所确定的待测试服务器发送测试指令，其中，所述测试指令，携带所述测试资源；接收所确定的待测试服务器反馈的测试数据，其中，所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试资源进行测试得到的测试数据。应用本申请实施例提供的方案进行测试，减轻了工作人员的工作压力，提高了测试效率。

Description

一种测试方法及装置

技术领域

本申请涉及计算机技术领域，特别涉及一种测试方法及装置。

背景技术

近年来随着计算机及网络技术的快速发展，云计算技术越来成熟，也得到了越来越广泛的应用。云计算服务提供商为向用户提供高质量的服务，通常会对云计算服务中涉及到的各个服务器的性能等方面进行测试，以全面、及时的了解各个服务器的状态。

现有技术中对各个服务器进行测试时，还是沿用传统的测试方法，通常由测试人员手动在一个一个服务器中部署相同的测试资源，然后启动测试程序一个一个服务器进行测试，一个指标一个指标地测试，均不能同时进行。当测试需求发生变化时，测试人员需逐台修改其中存储的测试资源，这样虽然能够实现对服务器的测试，但是在需要测试的服务器多的情况下，尤其是在云计算时代，服务器较多，分布环境较为复杂的情况下，测试人员通过手动的方式逐台测试已经不能满足现实的需求，测试人员工作压力大，影响测试效率，急需一套适合云计算领域的测试平台解决这一问题。

发明内容

本申请实施例公开了一种测试方法及装置，自动完成针对庞大服务器集群的获得多项测试结果的测试工作，以减轻测试人员的工作压力，提高测试效率。

为达到上述目的，本申请实施例公开了一种测试方法，所述方法包括：

获得测试资源，并确定待测试服务器，其中，所述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件；

向所确定的待测试服务器发送测试指令，其中，所述测试指令，携带所述测试资源；

接收所确定的待测试服务器反馈的测试数据，其中，所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试资源进行测试得到的测试数据。

在本申请的一种具体实现方式中，所述测试方法还包括：

根据所述测试数据生成针对所确定的待测试服务器的测试结果。

在本申请的一种具体实现方式中，所述根据所述测试数据生成针对所确定的待测试服务器的测试结果，包括：

获得所确定的待测试服务器的配置信息；

根据所述测试数据和所获得的配置信息，生成配置信息相同的待测试服务器在相同的测试项下的对比测试结果；

根据所生成的对比测试结果，生成针对所确定的待测试服务器的测试结果。

在本申请的一种具体实现方式中，所述获得测试资源，包括：

接收针对测试项的选择指令，其中，所述选择指令中包括：待测试项；

根据所述选择指令中包括的所述待测试项，获得测试资源。

在本申请的一种具体实现方式中，所述测试指令中还包括：针对待测试项的信息；

所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试指令中包括的针对待测试项的信息，确定待测试项，并按照预设的测试顺序，针对各个待测试项进行测试生成的测试数据。

在本申请的一种具体实现方式中，所述测试方法还包括：

接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息；

根据所接收的测试状态信息，生成测试状态提示信息；

展示所述测试状态提示信息。

在本申请的一种具体实现方式中，所述测试方法还包括：

接收待测试服务器按照预设的信息发送规则发送的配置信息。

在本申请的一种具体实现方式中，所述测试项，包括以下几项中的至少一项：

针对中央处理器CPU计算能力的测试项；

针对内存运行速度的测试项；

针对硬盘读写能力的测试项；

针对网络传输速率的测试项。

为达到上述目的，本申请实施例公开了一种测试装置，所述装置包括：

测试资源获得模块，用于获得测试资源，其中，所述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件；

服务器确定模块，用于确定待测试服务器；

测试指令发送模块，用于向所确定的待测试服务器发送测试指令，其中，所述测试指令，携带所述测试资源；

测试数据接收模块，用于接收所确定的待测试服务器反馈的测试数据，其中，所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试资源进行测试得到的测试数据。

在本申请的一种具体实现方式中，所述测试装置还包括：

测试结果生成模块，用于根据所述测试数据生成针对所确定的待测试服务器的测试结果。

在本申请的一种具体实现方式中，所述测试结果生成模块，包括：

配置信息获得子模块，用于获得所确定的待测试服务器的配置信息；

对比结果生成子模块，用于根据所述测试数据和所获得的配置信息，生成配置信息相同的待测试服务器在相同的测试项下的对比测试结果；

测试结果生成子模块，用于根据所生成的对比测试结果，生成针对所确定的待测试服务器的测试结果。

在本申请的一种具体实现方式中，所述测试资源获得模块，包括：

选择指令接收子模块，用于接收针对测试项的选择指令，其中，所述选择指令中包括：待测试项；

测试资源获得子模块，用于根据所述选择指令中包括的所述待测试项，获得测试资源。

在本申请的一种具体实现方式中，所述测试指令中还包括：针对待测试项的信息；

所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试指令中包括的针对待测试项的信息，确定待测试项，并按照预设的测试顺序，针对各个待测试项进行测试生成的测试数据。

在本申请的一种具体实现方式中，所述测试装置还包括：

状态信息接收模块，用于接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息；

提示信息生成模块，用于根据所接收的测试状态信息，生成测试状态提示信息；

提示信息展示模块，用于展示所述测试状态提示信息。

在本申请的一种具体实现方式中，所述测试装置还包括：

配置信息接收模块，用于接收待测试服务器按照预设的信息发送规则发送的配置信息。

在本申请的一种具体实现方式中，所述测试项，包括以下几项中的至少一项：

针对中央处理器CPU计算能力的测试项；

针对内存运行速度的测试项；

针对硬盘读写能力的测试项；

针对网络传输速率的测试项。

由以上可见，本申请实施例中提供的方案中，测试人员根据自身的测试需求，向测试平台输入配置文件，然后管理服务器根据配置文件获得测试资源，并确定待测试服务器后，向所确定的多个待测试服务器发送测试指令，各个待测试服务器接收到上述测试指令后，根据测试指令中携带的测试资源进行测试，得到测试数据，然后将上述测试数据发送给管理服务器，管理服务器将测试数据汇总统计，形成可以阅读的表格和数据展示在用户界面上。由于各个待测试服务器进行测试的测试资源均来自于管理服务器发送的测试指令，所以，当测试需求发生变化时，只需要测试人员修改一次管理服务器中的测试资源即可，无需逐台多次修改测试资源，因此，能够减轻工作人员的工作压力，提高测试效率。

附图说明

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

图1为本申请实施例提供的第一种测试方法的流程示意图；

图2为本申请实施例提供的第二种测试方法的流程示意图；

图3为本申请实施例提供的第三种测试方法的流程示意图；

图4为本申请实施例提供的第一种测试装置的结构示意图；

图5为本申请实施例提供的第二种测试装置的结构示意图；

图6为本申请实施例提供的第三种测试装置的结构示意图。

具体实施方式

由于现有技术中对多台服务器进行测试时，通常采用测试人员逐台服务器手动部署测试资源的方式进行测试，一旦测试需求发生变化，测试人员需要逐台服务器修改测试资源，测试人员工作压力大，测试效率低。鉴于此，本申请实施例提供了一种测试方法及装置。

下面先从总体上介绍本申请实施例提供的测试方法，该测试方法包括：

获得测试资源，并确定待测试服务器；

向所确定的待测试服务器发送测试指令；

接收所确定的待测试服务器反馈的测试数据。

其中，上述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件，上述测试指令、携带上述测试资源和上述测试数据的关联关系是：待测试服务器接收到测试指令后，根据上述测试资源进行测试得到测试数据。

需要说明的是，上述各个步骤的执行主体可以理解为测试系统中的管理服务器，该测试系统包括一台管理服务器和多台待测试服务器，其中，上述管理服务器可以理解为是从功能性上进行定义的服务器，另外，该管理服务器与上述各个待测试服务器对应不同的物理机，这样可以有效保证测试过程中管理服务器所进行的工作不会影响测试结果。管理服务器的功能是负责测试装置的运行，测试装置还包括但不限于实时更新的待测试服务器列表、多种测试方案数据库。测试人员登陆到测试装置中，在测试装置提供的界面上输入当前的测试需求，比如在界面的引导下输入各种参数，指定拟测试的待测试服务器等测试需求，测试装置根据测试人员的输入内容形成一个一个的配置文件，根据该配置文件从多种测试方案数据库中选择适合的测试方案，每个测试方案是适合特定的某个或某群待测试服务器的，然后将测试方案分发到各自特定的待测试服务器进行测试。

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

图1为本申请实施例提供的第一种测试方法的流程示意图，该方法包括：

S101：获得测试资源，并确定待测试服务器。

其中，上述测试资源可以理解为：在针对各个测试项对待测试服务器进行测试时需要的文件。

具体的，上述测试项可以包括以下几项中的至少一项：

针对CPU(Central Processing Unit，中央处理器)计算能力的测试项；

针对内存运行速度的测试项；

针对硬盘读写能力的测试项；

针对网络传输速率的测试项。

本申请只是以上述为例进行说明，实际应用中测试项并不仅限于上述几项。

举例而言，上述测试项可以是：

单线程下，内存使用情况分别为：1G、2G、4G、8G、16G、32G等情况下，针对CPU计算能力的测试项；

双线程下，内存使用情况分别为：1G、2G、4G、8G、16G、32G等情况下，针对CPU计算能力的测试项等等。

可以理解的，对待测试服务器进行测试时，可以采用开发人员自行开发的软件进行测试，还可以采用已有的测试工具进行测试，本申请并不对此进行限定。鉴于此，在本申请的一种可选实现方式中，上述测试资源中可以包括测试工具安装文件、测试代码文件等等，另外，上述测试资源中还可以包括配置文件等信息，其中，上述配置文件可以用于规定待测试服务器的IP(Internet Protocol，网络之间互连的协议)地址、登录用户名、密码、选择测试硬盘、选择测试CPU、选择测试内存等等，本申请并不对上述测试资源中所包含的具体内容进行限定。

实际应用中，对待测试服务器进行测试时，可以测试服务器的多个方面，而由于每一测试项的具体内容不同，所以，所采用的测试工具可能会不同，因此，上述测试资源中所包括的测试工具安装文件可以是针对各个测试项的不同安装文件。再者，一些情况下，虽然测试项相同，但是由于操作系统种类不同或者操作系统的版本不同，也可能会对应不同的测试工具，所以，上述测试资源中所包括的测试工具安装文件还可以是针对不同操作系统、不同操作系统版本的安装文件。

作为本发明的一个优选实施例，由于针对某个测试项的测试方案已经较为复杂，现有技术中均是针对不同的测试项提供有针对性的测试方案，比如测试CPU性能的话，就只测试CPU性能，不能同时对内存进行测试。本申请的测试工具安装文件针对的是多种测试项的，例如，上述测试工具安装文件可以是：用于测试CPU计算能力的安装文件windows版、用于测试CPU计算能力的安装文件安卓版(支持安卓5.1以上版本)、用于测试CPU计算能力的安装文件安卓版(支持安卓5.1以下版本)、用于测试内存运行速度的安装文件等等。

本领域内的技术人员可以理解的是，测试过程之所以能够在不需要测试人员干预的情况下顺利进行，其背后必定有已经定义好的测试规则支撑，而测试规则通常情况下是需要通过程序代码来实现的，也就是前面提及的测试代码文件。该测试代码文件可以用于规定针对各个测试项的测试参数，可以用于规定各个测试项的测试顺序等等。

具体的，上述测试资源可以以包文件的形式存在，以便于后续向各个待测试服务器发送该测试资源，当然也可以以其他形式存在，本申请并不对此进行限定。

获得上述测试资源包时，一种情况下，可以理解为从其他服务器或者设备获得的，另一种情况下，可以理解为，测试人员在管理服务器中编辑得到的。

在本申请的一种可选实现方式中，获得测试资源时，还可以是根据接收到的针对测试项的选择指令获得的，具体的，该选择指令中需包括：待测试项，管理服务器接收到上述选择指令后，根据选择指令中包括的待测试项，获得测试资源。这种情况下，获得的测试资源可以仅仅包括与上述待测试项相关的测试资源，而无需包括所有可能的测试资源，这样能够一定程度上限定上述测试资源的大小，有利于加快后续向待测试服务器发送测试指令的速度。

为便于理解上述的技术方案，提供一个具体的实施例。云计算服务提供商在管理服务器上部署测试系统，该测试系统提供用户界面。测试人员可以在界面上面输入测试项，比如输入要对哪几台待测试服务器进行测试，例如选择30台待测试服务器进行测试。然后测试人员在界面上面选择2个测试类型，即测试CPU和内存的性能，但没有选择测试硬盘的性能。测试人员点击确定后，测试系统开始对测试需求进行处理。测试系统逐一准备测试资源，比如将测试人员的测试需求做成一个文件；生成配置文件；生成多个测试工具的安装文件，如用于测试CPU计算能力的安装文件windows版、用于测试CPU计算能力的安装文件安卓版(支持安卓5.1以上版本)、用于测试CPU计算能力的安装文件安卓版(支持安卓5.1以下版本)；生成测试方案数据库，测试方案数据库中有适合多种操作系统软件和硬件环境的测试方案。测试系统将测试资源打包封装后分别分发给30台待测试服务器。假设这30台待测试服务器的操作系统分别是window7、Linux、windowXP、window10。为了使得本次测试结果具有可比较性，每台待测试服务器从测试工具中应当选择统一适用的测试软件和统一的测试方案，以确保公平。测试系统将根据所有待测试服务器的硬软件环境，判断出从测试方案数据库中选择哪一套测试方案不仅符合本台待测试服务器，还要符合统一性的要求，根据测试方案再选择将统一的测试工具安装在待测试服务器上面，待测试服务器执行安装、测试。30台待测试服务器同步进行测试，这将提高测试效率，节约测试时间。管理服务器每10秒钟向每台待测试服务器发送请求，如果待测试服务器完成了本次测试工作，收到请求后会将结果反馈给管理服务器，管理服务器收到反馈结果后进行记录。如果管理服务器向待测试服务器发送的请求没有得到应答，则管理服务器认为该台待测试服务器出现了不可预测的故障，请求次数达到一定阈值后，认为该台待测试服务器需要中止测试，然后管理服务器终止对本台待测试服务器的测试工作，并询问测试人员是否继续测试，或者管理服务器重新发放测试用的封装包给该台待测试服务器，重新测试一次，如果中止测试的次数达到一定阈值，则管理服务器停止对该台服务器的测试，并写入反馈结果中。管理服务里收到30台待测试服务器的反馈结果后，将所有结果整合，以表格、饼图、曲线图等方式展现在界面上供测试人员查看。为方便测试人员了解各台待测试服务器的进度，管理服务器通过界面展示各待测试服务器动态的任务条、动态的测试进度的进程状态供测试人员查看，测试人员可以方便地了解当前时间各台待测试服务器的测试进度到哪里了，出现了什么问题需要人工参与。在测试过程中，测试人员可以通过管理服务器提供的用户界面随时终止任意一台待测试服务器的测试工作。

在上面具体实施例中，封装包中封装了所有可能用到的测试方案，比如适合window7操作系统的测试方案，适合32位系统类型的测试方案等等。在待测试服务器端再根据待测试服务器的本机硬软件环境选择其中适合的测试方案。但是作为一个具体实施例，管理服务器设计为在管理服务器处先对30台待测试服务器的硬软件环境做统计，计算得到一套能够公平测试30台待测试服务器的统一方案放入配置文件中，然后将所有所有的测试方案和该配置文件等全部封装，封装后再分发给30台待测试服务器，30台待测试服务器收到封装包后，再从测试方案中按照配置文件中指出的统一测试方案，结合自身硬软件的具体情况选择一套具体的测试方案对本台待测试服务器进行测试。这么做的优点是，随时调整测试方案的时候，不用再次封装新的封装包给待测试服务器，而是直接为待测试服务器更换成新配置文件即可。

作为另外一个具体实施例，在整个测试过程中，管理服务器也可以设计为不向每台待测试服务器发送请求，而是等待待测试服务器自己主动反馈测试结果，这样可以节省管理服务器的物理资源和带宽资源，但是这么做的缺点是不能随时掌握待测试服务器的状态，当待测试服务器宕机后不能快速发现和尽快处理。

作为另外一个具体实施例，当待测试服务器测试的过程中遇到宕机、执行错误时，待测试服务器可以再从测试方案数据库中挑选一个备选测试方案重新测试，并在测试结果中标记，然后反馈给管理服务器。这么做的好处是，遇到宕机后仍然可以有一套备选方案供执行测试，可以不影响其他同步测试的进程，能够在测试人员的预期时间完成测试，如果测试人员对于备选方案的测试结果不满意，可以在用户界面上面针对该台测试服务器重新做一次测试，以弥补上次的不足，为了满足这种需求，管理服务器会记录上一次测试的测试方案，以方便下次测试时候提供给测试人员选择。

作为一个具体的实施例，管理服务器收到一个待测试服务器的反馈结果，就在界面上面进行显示，而不必等待所有结果都收到后再显示，提高了反馈速度。

由前面的描述可以得知，测试系统中存在多台待测试服务器，一种可选实现方式中，本步骤中确定的待测试服务器，可以将该测试系统中包含的所有待测试服务器。

另外，由于每次进行测试时，测试项可能会有所不同，所以，可能并不是该测试系统中的所有待测试服务器均符合测试需要，鉴于此，本步骤中确定的待测试服务器可以是该测试系统中包含的所有待测试服务器的一部分。具体的，可以根据测试需求中的待测试项确定。可以理解的，每一台待测试服务器均对应其自身的配置信息，根据待测试项确定待测试服务器时，可以根据各台待测试服务器的配置信息进行确定。

S102：向所确定的待测试服务器发送测试指令。

其中，上述测试指令，携带上述测试资源。

由于本步骤中向所确定的待测试服务器发送的测试指令是同一测试指令，所以所确定的各个待测试服务器接收到的测试资源是相同的测试资源，因此，保证了测试过程中各个待测试服务器测试资源的统一性。

另外，这种情况下向所确定的待测试服务器发送测试指令时，虽然所确定的待测试服务器可能是多个待测试服务器，但是只发送一次测试指令即可，省去了逐台部署测试资源的繁琐过程。

进一步的，当测试需求发生变化时，只需要在管理服务器中修改上述测试资源，并根据修改后的测试资源重新向所确定的待测试服务器发送测试指令即可，显然避免了逐台在待测试服务器中手动修改测试资源的繁琐过程。逐台在待测试服务器中手动修改测试资源时，不仅测试人员的工作量大，而且还可能会出现修改错误，导致各台服务器的测试资源不一致等情况出现，而本实施例中，由于是在管理服务器中统一进行的资源修改，所以，测试人员的只需修改一次测试资源即可，这样不仅测试人员的工作压力小，而且能够有效保证各台待测试服务器中的测试资源一致。

S103：接收所确定的待测试服务器反馈的测试数据。

其中，上述测试数据为：待测试服务器接收到测试指令后，根据上述测试资源进行测试得到的测试数据。

具体的，上述测试数据可以是对待测试服务器进行测试得到的原始测试数据，当然，也可以是经过特定处理后的测试数据，例如，进行了评分处理后的测试数据等等。

另外，上述测试数据中还可以包括：待测试服务器的配置信息等等，这样管理服务器可以更加准确的掌握待测试服务器测试时的实际配置信息。

可以理解的，对待测试服务器进行测试时，可能会成功的对待测试服务器进行测试，也可能由于编译错误、操作系统不兼容等等因素引起测试失败，鉴于此，上述测试数据可以是成功对待测试服务器进行测试时生成的测试数据，也可以是对待测试服务器测试失败时生成的错误提示数据等等，这样测试人员不仅可以得到成功测试情况下的测试数据，还能够了解到哪些服务器出现了测试错误以及出现错误的原因等等。

由于上述测试资源可以是根据待测试项获得的测试资源，所以，待测试服务器接收到测试指令后，根据测试指令中包括的测试资源、按照预定的测试顺序逐条进行测试即可，并获得测试过程中生成的测试数据。

虽然上述测试资源可以根据待测试项获得，但是另一方面，考虑到防止遗漏向测试服务器发送测试资源，上述测试资源还可以包含所有测试资源。这种情况下，可以将针对待测试项的信息随着测试指令一起发送至所确定的各个待测试服务器。具体的上述针对待测试项的信息可以是以参数的形式随着测试指令一起发送至所确定的各个待测试服务器的，还可以是以文件的形式随着测试指令一起发送至所确定的各个待测试服务器的，本申请并不对此进行限定。

基于上述情况，上述测试数据可以为：待测试服务器接收到测试指令后，根据该测试指令中包括的针对待测试项的信息，确定待测试项，并按照预设的测试顺序，针对各个待测试项进行测试生成的测试数据。

具体的，为保证管理服务器能够记录各个待测试服务器的准确信息，上述测试方法还可以包括：

接收待测试服务器按照预设的信息发送规则发送的配置信息。

由以上可见，本实施例中提供的方案中，管理服务器获得测试资源，并确定待测试服务器后，向所确定的待测试服务器发送测试指令，各个待测试服务器接收到上述测试指令后，根据测试指令中携带的测试资源进行测试，得到测试数据，然后将上述测试数据发送给管理服务器。由于各个待测试服务器进行测试的测试资源均来自于管理服务器发送的测试指令，所以，当测试需求发生变化时，只需要测试人员修改一次管理服务器中的测试资源即可，无需逐台多次修改测试资源，因此，能够减轻工作人员的工作压力，提高测试效率。

在本申请的一种具体实现方式中，参见图2，提供了第二种测试方法的流程示意图，与前述实施例相比，本实施例中，上述测试方法还包括：

S104：根据上述测试数据生成针对所确定的待测试服务器的测试结果。

由于所确定的各个待测试服务器接收到的测试指令是同一测试指令，测试资源是相同的测试资源，且所确定的各个待测试服务器的配置信息也可能具有相同的配置信息，为便于测试人员查看测试结果，在本申请的一种较佳实现方式中，根据上述测试数据生成针对所确定的待测试服务器的测试结果时，可以先获得所确定的待测试服务器的配置信息，然后根据上述测试数据和所获得的配置信息，生成配置信息相同的待测试服务器在相同的测试项下的对比测试结果，并根据所生成的对比测试结果，生成针对所确定的待测试服务器的测试结果。

具体的，获得所确定的待测试服务器的配置信息时，可以通过以下几种方式获得：

第一种情况下：管理服务器中记录有所有待测试服务器的配置信息，此时可以直接根据上述记录的配置信息获得所确定的待测试服务器的配置信息；

第二种情况下：管理服务器根据所确定的待测试服务器的标识等信息，向所确定的各个待测试服务器发送配置信息获得请求，所确定的各个待测试服务器接收到配置信息获得请求后，将其自身的配置信息反馈给管理服务器；

第三种情况下：上述测试数据中还可以包含其对应待测试服务器的配置信息，这样，直接从待测试数据中解析得到该待测试服务器的配置信息即可。

由于实际应用中各个待测试服务器可能会发生硬件更新等现象，上述第二种、第三种情况能够有效保证各个待测试服务器的配置信息为测试数据对应的配置信息。

由以上可见，本实施例提供的方案中，管理服务器接收到测试数据后生成测试结果，这样能够使得测试人员更加直观的了解测试情况，进一步减轻了测试人员的工作压力，提高了用户体验。

在本申请的另一种具体实现方式中，参见图3，提供了第三种测试方法的流程示意图，与前述实施例相比，本实施例中，上述测试方法还包括：

S105：接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息。

上述测试状态信息中可以包括：是否为正常测试状态的标识、是否为异常测试状态的标识、测试进度信息等等。

S106：根据所接收的测试状态信息，生成测试状态提示信息。

本步骤中可以对所接收的测试状态信息进行分析，确定测试异常的服务器数量等等，进而生成提示信息，以使得测试人员快速掌握测试情况。

例如，测试人员需要对1000台待测试服务器进行测试，整个测试过程需要10个小时，开始测试测试5分钟后，各个待测试服务器反馈了测试状态信息，经过对这些信息进行整理发现600台待测试服务器出现了测试错误，测试人员看到这样的情况后可以快速断定测试存在问题，进而停止对1000台待测试服务器的测试，查找原因重新测试。若待测试服务器不反馈上述测试状态信息，测试人员只能在10个小时候发现测试存在问题，这样会浪费测试时间，降低测试效率。

S107：展示上述测试状态提示信息。

由以上可见，本实施例提供的方案中，管理服务器接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息，并根据这些测试状态信息，生成测试状态提示信息，展示上述测试状态提示信息。这样有助于测试人员及时了解测试情况，进而进一步提高测试效率。

与上述测试方法相对应，本申请实施例还提供了一种测试装置。

图4为本申请实施例提供的第一种测试装置的结构示意图，该装置包括：

测试资源获得模块401，用于获得测试资源，其中，所述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件；

服务器确定模块402，用于确定待测试服务器；

测试指令发送模块403，用于向所确定的待测试服务器发送测试指令，其中，所述测试指令，携带所述测试资源；

测试数据接收模块404，用于接收所确定的待测试服务器反馈的测试数据，其中，所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试资源进行测试得到的测试数据。

具体的，所述测试资源获得模块401可以包括：

选择指令接收子模块，用于接收针对测试项的选择指令，其中，所述选择指令中包括：待测试项；

测试资源获得子模块，用于根据所述选择指令中包括的所述待测试项，获得测试资源。

具体的，所述测试指令中还可以包括：针对待测试项的信息；

所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试指令中包括的针对待测试项的信息，确定待测试项，并按照预设的测试顺序，针对各个待测试项进行测试生成的测试数据。

具体的，所述测试装置还可以包括：

配置信息接收模块，用于接收待测试服务器按照预设的信息发送规则发送的配置信息。

具体的，所述测试项可以包括以下几项中的至少一项：

针对中央处理器CPU计算能力的测试项；

针对内存运行速度的测试项；

针对硬盘读写能力的测试项；

针对网络传输速率的测试项。

由以上可见，本实施例中提供的方案中，管理服务器获得测试资源，并确定待测试服务器后，向所确定的待测试服务器发送测试指令，各个待测试服务器接收到上述测试指令后，根据测试指令中携带的测试资源进行测试，得到测试数据，然后将上述测试数据发送给管理服务器。由于各个待测试服务器进行测试的测试资源均来自于管理服务器发送的测试指令，所以，当测试需求发生变化时，只需要测试人员修改一次管理服务器中的测试资源即可，无需逐台多次修改测试资源，因此，能够减轻工作人员的工作压力，提高测试效率。

在本申请的一种具体实现方式中，参见图5，提供了第二种测试装置的结构示意图，与前述实施例相比，本实施例中，上述测试装置还包括：

测试结果生成模块405，用于根据所述测试数据生成针对所确定的待测试服务器的测试结果。

具体的，所述测试结果生成模块405可以包括：

配置信息获得子模块，用于获得所确定的待测试服务器的配置信息；

对比结果生成子模块，用于根据所述测试数据和所获得的配置信息，生成配置信息相同的待测试服务器在相同的测试项下的对比测试结果；

测试结果生成子模块，用于根据所生成的对比测试结果，生成针对所确定的待测试服务器的测试结果。

由以上可见，本实施例提供的方案中，管理服务器接收到测试数据后生成测试结果，这样能够使得测试人员更加直观的了解测试情况，进一步减轻了测试人员的工作压力，提高了用户体验。

在本申请的另一种具体实现方式中，参见图6，提供了第三种测试装置的结构示意图，与前述实施例相比，本实施例中，上述测试装置还包括：

状态信息接收模块406，用于接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息；

提示信息生成模块407，用于根据所接收的测试状态信息，生成测试状态提示信息；

提示信息展示模块408，用于展示所述测试状态提示信息。

由以上可见，本实施例提供的方案中，管理服务器接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息，并根据这些测试状态信息，生成测试状态提示信息，展示上述测试状态提示信息。这样有助于测试人员及时了解测试情况，进而进一步提高测试效率。

对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机可读取存储介质中，这里所称得的存储介质，如：ROM/RAM、磁碟、光盘等。

以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。

Claims (16)

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

获得测试资源，并确定待测试服务器，其中，所述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件；

向所确定的待测试服务器发送测试指令，其中，所述测试指令，携带所述测试资源；

接收所确定的待测试服务器反馈的测试数据，其中，所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试资源进行测试得到的测试数据，当所述待测试服务器测试的过程中遇到宕机、执行错误时，所述测试数据中携带有标记，所述标记用于标记所述待测试服务器选用的测试方案为备选测试方案。

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

根据所述测试数据生成针对所确定的待测试服务器的测试结果。

3.根据权利要求2所述的方法，其特征在于，所述根据所述测试数据生成针对所确定的待测试服务器的测试结果，包括：

获得所确定的待测试服务器的配置信息；

根据所述测试数据和所获得的配置信息，生成配置信息相同的待测试服务器在相同的测试项下的对比测试结果；

根据所生成的对比测试结果，生成针对所确定的待测试服务器的测试结果。

4.根据权利要求1所述的方法，其特征在于，所述获得测试资源，包括：

接收针对测试项的选择指令，其中，所述选择指令中包括：待测试项；

根据所述选择指令中包括的所述待测试项，获得测试资源。

5.根据权利要求1所述的方法，其特征在于，所述测试指令中还包括：针对待测试项的信息；

所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试指令中包括的针对待测试项的信息，确定待测试项，并按照预设的测试顺序，针对各个待测试项进行测试生成的测试数据。

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

接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息；

根据所接收的测试状态信息，生成测试状态提示信息；

展示所述测试状态提示信息。

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

接收待测试服务器按照预设的信息发送规则发送的配置信息。

8.根据权利要求1-7中任一项所述的方法，其特征在于，所述测试项，包括以下几项中的至少一项：

针对中央处理器CPU计算能力的测试项；

针对内存运行速度的测试项；

针对硬盘读写能力的测试项；

针对网络传输速率的测试项。

9.一种测试装置，其特征在于，所述装置包括：

测试资源获得模块，用于获得测试资源，其中，所述测试资源为：在针对各个测试项对待测试服务器进行测试时需要的文件；

服务器确定模块，用于确定待测试服务器；

测试指令发送模块，用于向所确定的待测试服务器发送测试指令，其中，所述测试指令，携带所述测试资源；

测试数据接收模块，用于接收所确定的待测试服务器反馈的测试数据，其中，所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试资源进行测试得到的测试数据。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

测试结果生成模块，用于根据所述测试数据生成针对所确定的待测试服务器的测试结果。

11.根据权利要求10所述的装置，其特征在于，所述测试结果生成模块，包括：

配置信息获得子模块，用于获得所确定的待测试服务器的配置信息；

对比结果生成子模块，用于根据所述测试数据和所获得的配置信息，生成配置信息相同的待测试服务器在相同的测试项下的对比测试结果；

测试结果生成子模块，用于根据所生成的对比测试结果，生成针对所确定的待测试服务器的测试结果。

12.根据权利要求9所述的装置，其特征在于，所述测试资源获得模块，包括：

选择指令接收子模块，用于接收针对测试项的选择指令，其中，所述选择指令中包括：待测试项；

测试资源获得子模块，用于根据所述选择指令中包括的所述待测试项，获得测试资源。

13.根据权利要求9所述的装置，其特征在于，所述测试指令中还包括：针对待测试项的信息；

所述测试数据为：待测试服务器接收到所述测试指令后，根据所述测试指令中包括的针对待测试项的信息，确定待测试项，并按照预设的测试顺序，针对各个待测试项进行测试生成的测试数据。

14.根据权利要求9所述的装置，其特征在于，所述装置还包括：

状态信息接收模块，用于接收所确定的待测试服务器按照预设的时间间隔反馈的测试状态信息；

提示信息生成模块，用于根据所接收的测试状态信息，生成测试状态提示信息；

提示信息展示模块，用于展示所述测试状态提示信息。

15.根据权利要求9所述的装置，其特征在于，所述装置还包括：

配置信息接收模块，用于接收待测试服务器按照预设的信息发送规则发送的配置信息。

16.根据权利要求9-15中任一项所述的装置，其特征在于，所述测试项，包括以下几项中的至少一项：

针对中央处理器CPU计算能力的测试项；

针对内存运行速度的测试项；

针对硬盘读写能力的测试项；

针对网络传输速率的测试项。

Images