一种多版本性能测试方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种多版本性能测试方法及装置。

背景技术：

目前，在对软件产品进行性能测试时，可基于为该软件产品选定的性能指标，测试获得各性能指标对应的测试数据，然后，根据测试场景，对获取的测试数据进行人工分析，以确定该软件产品的性能是否正常。其中，所述的性能指标可以是中央处理器(Central Processing Unit，CPU)利用率、磁盘利用率、网络利用率、内存消耗量等等。

但是，对于大中型软件产品，由于其通常包含了多个子系统和/或模块，架构复杂，因此，这些软件系统的研发周期较长，而且在整个研发周期内，可能会迭代开发以及发布多个版本，相应的，对各个版本也都要进行性能测试。在这种情况下，由于每个子系统和/或模块都有自己的性能指标，因此待测的性能指标总数量很多，而每发布一个新版本，都要对这些性能指标对应的测试数据重新进行人工分析，测试效率低下。

技术实现要素：

本申请实施例提供一种多版本性能测试方法，用以解决现有技术中对大中型软件产品的多个版本，进行的性能测试效率低下的问题。

本申请实施例提供一种多版本性能测试装置，用以解决现有技术中对大中型软件产品的多个版本，进行的性能测试效率低下的问题。

本申请实施例提供的一种多版本性能测试方法，包括：

获取待测版本的各性能指标的测试数据；

当确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配时，确定所述待测版本的性能正常，其中，所述该性能指标的基准值是根据所述待测版本的历史版本确定的。

本申请实施例提供的一种多版本性能测试装置，包括：

获取模块，用于获取待测版本的各性能指标的测试数据；

测试模块，用于当确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配时，确定所述待测版本的性能正常，以及用于确定所述该性能指标的基准值，其中，所述该性能指标的基准值是根据所述待测版本的历史版本确定的。

本申请实施例通过上述技术方案，若已根据待测版本的历史版本确定出了各性能指标的基准值，则对于待测版本的各性能指标的测试数据，不用逐个进行人工分析，而是通过将该测试数据与对应的基准值进行匹配，即可以确定该待测版本的性能是否正常，因此，提高了测试效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的多版本性能测试过程；

图2为在实际应用场景下，本申请实施例提供的多版本性能测试的详细过程；

图3为本申请实施例提供的多版本性能测试装置结构示意图。

具体实施方式

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

图1为本申请实施例提供的多版本性能测试过程，具体包括以下步骤：

S101：获取待测版本的各性能指标的测试数据。

S102：当确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配时，确定所述待测版本的性能正常，其中，所述该性能指标的基准值是根据所述待测版本的历史版本确定的。

本申请实施例提供的多版本性能测试的方法的执行主体可以是：用于对产品进行性能测试的服务器或终端。所述产品可以是软件产品、硬件产品、软件结合的产品、机械产品等等。所述服务器包括但不限于：个人计算机、大中型计算机、计算机集群等。所述终端包括但不限于：个人计算机、手机、平板电脑、智能手表、车载移动台等。所述的执行主体并不构成对本申请的限定，为了便于描述，本申请实施例均以执行主体是所述服务器为例进行说明。

测试包括功能测试和性能测试两大类。对于产品的功能测试，在执行功能测试之前，已经有明确的标准来判断测试数据是否符合预期。例如，假定一个按键功能为从本地机器向服务器提交输入的信息，则对该功能进行测试时，可以在本地机器上输入信息并按下该按键，然后，验证服务器是否接收到该输入信息，在这种情况下，所述的测试数据为该输入信息，以及服务器实际接收到的信息，显然，当这两个信息相同时，可确定该按键功能正常。

而对于产品的性能测试，由于根据测试场景的不同(测试场景的构成因素包括但不限于负载、使用的操作系统、传输线路、温度等等)，产品的性能表现可能不同，则在执行性能测试之前，可能无法确定产品的性能达到什么程度，也即，对于产品的性能是否正常，并没有明确的判断标准。仍以上里继续说明，假定继续测试该按键的性能指标“响应时间”，一般的，当在本地机器上输入的信息类型、信息量不同时，所获得的响应时间的测试数据也不同，可能为 0.01秒、也可能为0.1秒等。因此，对于执行性能测试后获得的测试数据，通常需要结合测试场景，人工分析这些测试数据是否正常，其中，所述性能指标可以是CPU利用率、磁盘利用率、网络利用率、内存消耗量等等。进一步的，对于大中型软件产品，会迭代开发以及发布多个版本，相应的，对各个版本也都要进行性能测试，由于其每个子系统和/或模块都有自己的性能指标，因此待测的性能指标总数量很多，而每开发一个新版本，都要对这些性能指标对应的测试数据重新进行人工分析，测试效率低下，成本高昂。

基于上述问题，在本申请实施例中，在性能测试过程中，不一一地对待测产品的每个版本的测试数据都进行人工分析，而是仅根据已有的各性能指标的测试数据，确定各性能指标的基准值，进而，可以基于所述基准值，测试和评定待测版本的性能，可以提高效率，降低人工成本。例如，对于性能指标“CPU利用率”或“内存占用率”，其基准值可以是一个明确的百分比数值，如40％、60％、100％等。

在本申请实施例中，可以基于待测版本的历史版本确定各性能指标的基准值(各基准值也可以合称为性能基线)。例如，基于初始版本的测试数据，或者，基于待测版本的上一个版本的测试数据，或者，基于多个历史版本的测试数据，等等，生成各性能指标的基准值。当然，也可不基于测试数据生成各性能指标的基准值，而是由产品的设计者和开发者直接指定各性能指标的基准值。当然，在实际应用中，由于产品在开发过程中在不断变化，为了提高各性能指标的基准值的可靠性和适用性，可以根据版本的变化对已确定的基准值进行调整或修正。

在本申请实施例中，可以采用不同的具体实施方式，确定测试数据是否与对应的基准值匹配。例如，在选定坐标系下，将各性能指标的基准值和待测版本的各性能指标的测试数据分别视为一个集合，并将这两个集合向量化，判断测试数据的集合对应的向量与基准值的集合对应的向量之间的距离是否大于预设阈值，若是，则确定测试数据与基准值匹配，否则，确定测试数据与基准 值不匹配；也可以分别判断每个测试数据与对应的基准值之间的接近程度，若接近程度均大于预设阈值，则确定该测试数据与对应的基准值匹配，否则，确定该测试数据与对应的基准值不匹配，等等。

通过上述方法，若已根据待测版本的历史版本确定出了各性能指标的基准值，则对于待测版本的各性能指标的测试数据，不用逐个进行人工分析，而是通过将该测试数据与对应的基准值进行匹配，即可以确定该待测版本的性能是否正常，因此，提高了测试效率。

在本申请实施例中，对于上述步骤S102，按照如下方法，确定所述该性能指标的基准值：通过执行预设的测试脚本，对所述待测版本的历史版本进行测试，获取所述历史版本的该性能指标的测试数据，根据所述测试脚本中定义的测试场景，对所述历史版本的该性能指标的测试数据进行分析，确定出该性能指标的基准值。

当然，对于某些产品的测试，可能无法利用测试脚本进行测试，而是要手工进行测试，则在这样的情况下，可以在服务器上对手工测试时的测试场景进行记录，以用于后续版本的测试。

进一步的，由于在性能测试中可能选定了多个测试场景，而对于不同的测试场景，同一个版本的性能表现也有差异，例如，对于某软件产品的待测版本，在测试场景1中，该待测版本的并发用户数为100，而在测试场景2中，并发用户数为10000，则该待测版本在测试场景1的性能，很可能大大低于在测试场景1的性能。在这种情况下，若基于在测试场景1下确定的各性能指标的基准值，判断在测试场景2下待测版本的性能是否正常，是不可靠的。

因此，在实际应用中，也可以根据历史版本在每个测试场景下的测试数据，分别确定一组各性能指标的基准值，则在对待测版本进行测试时，应基于选定的测试场景，在该测试场景下获取的测试数据集，以及与该测试场景对应的各性能指标的基准值，来评定该待测版本的性能是否正常。当然，也可以根据测试场景之间的差异，对在某测试场景下确定的各基准值中的一部分基准值进行 调整后，直接用于另一个测试场景中，而不用再完整地执行一次确定各性能指标的基准值的过程，这样的话，可以提高服务器的测试效率。

另外，本申请对根据所述测试脚本中定义的测试场景，对所述历史版本的该性能指标的测试数据进行分析，确定出该性能指标的基准值这个过程的具体实施方式并不做限定。在此仅列举出两种可行的具体实施方式。第一，由开发人员或测试人员根据自身经验确定并在服务器上设置的；第二，服务器或终端获取执行的测试脚本中的各个参数，根据为每个参数预设的性能影响权值，确定出该测试脚本中的测试场景对性能指标的影响程度，进而，确定出该性能指标预期的取值范围，以及在该取值范围内选定某个取值作为该性能指标的基准值。

在本申请实施例中，对于上述步骤S101，获取待测版本的各性能指标的测试数据，具体包括：通过执行预设的测试脚本，对所述待测版本进行测试，获取所述待测版本的各性能指标的测试数据。根据前面的说明，在测试待测版本时，可以沿用根据待测版本的历史版本确定各性能指标的基准值历史版本时所使用的测试脚本，这样的话，可以保证测试场景相同，基于各性能指标的基准值对待测版本进行测试的可靠性。

进一步的，根据选定的历史版本确定出各性能指标的基准值后，可以将各性能指标的基准值用于测试后续的待测版本。但是，在版本数量较多的情况下，版本号相差较大的版本之间的性能可能相差也较大，因此，当某个待测版本在所述选定的历史版本的基础之上修改程度较大时，之前确定出各性能指标的基准值可能不再适用，则可以根据所述某个待测版本，重新确定各性能指标的基准值，用于后续测试。

在本申请实施例中，前面列举了步骤S102若干可行的具体实施方式，下面对其中一种进行详细说明。确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配，具体包括：当确定所述待测版本的每个性能指标的测试数据与该性能指标的基准值之差的绝对值均不超过预设阈值时，确定所 述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配。或者，也可以判断所述待测版本的每个性能指标的测试数据，是否均落在包含了对应基准值的预设取值区间之内，若是，则确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配，其中，可以根据选定的测试场景，对所述预设阈值或所述预设取值区间进行合理设定。

在本申请实施例中，对于待测产品的每个版本进行测试的性能指标也可以发生变更，例如，在历史版本中测试性能指标A、性能指标B和性能指标C，而在待测版本中有可能变更为测试性能指标B、性能指标C和性能指标D，可以根据性能指标B和性能指标C的基准值，测试待测版本的性能指标B、性能指标C是否正常，而对于待测版本的性能指标D，由于没有对应的基准值，则可以对待测版本的性能指标D的测试数据单独进行分析，以确定该测试数据是否正常，并可以根据分析结果确定性能指标D的基准值，可用于以后对待测版本的后续版本进行测试。

另外，需要说明的是，所述的性能测试又可以细分为常规性能测试、压力测试、负载测试等类型的测试等等，对于上述各种类型的性能测试，可能采用的不同的测试场景，也可能测试不同的性能指标，而本申请实施例提供的性能测试方法均可适用。

根据上述说明，以对某软件产品进行性能测试中的压力测试为例，在图2中示出了本申请实施例提供的多版本性能测试的详细过程。具体包括以下步骤：

S201：为待测的软件产品的各个子系统分别选定性能指标。

假定该软件产品由1～n个子系统构成，其中，n为大于1的正整数。为每个子系统都选定一组相同的待测性能指标，包括：CPU利用率、网络利用率、磁盘利用率、响应时间、吞吐量、JAVA相关性能指标等等。

S202：当该软件产品的初始版本测试准备就绪时，通过执行预设的压力测试脚本，对待测的软件产品的初始版本进行压力测试，也即，分别对初始版本 的各个子系统进行压力测试，获得各个子系统的各性能指标的压力测试数据(合称为：压力测试数据集)。

所述的初始版本可以是该软件产品第一轮发布的版本。

S203：通过对该测试脚本和该压力测试数据集进行分析，分别为每个子系统的每个性能指标确定出对应的基准值。

例如，为性能指标“CPU利用率”确定出的基准值可以为40％或50％等等，为性能指标“响应时间”确定出的基准值可以为0.01秒或0.05秒等等。显然，各子系统的同一个性能指标的基准值既可以相同，也可以不同。

S204：当该软件产品的后续版本(可以是本申请中所述的待测版本)测试准备就绪，且确定该后续版本待测的性能指标未发生变更时，通过执行步骤S202中的测试脚本，对该后续版本进行压力测试，获取与该后续版本对应的压力测试数据集。

所述的后续版本可以是在该软件产品第一轮发布的版本之后的任一版本。

S205：针对上述每个性能指标，确定该压力测试数据集中与该性能指标对应的测试数据，以及所述性能基线包含的该性能指标的基准值，并判断为每个性能指标确定出的测试数据与基准值之差的绝对值是否均不超过预设阈值。

假定性能指标“CPU利用率”确定为70％，且对应的预设阈值为5％。则当性能指标“CPU利用率”对应的测试数据为在65％～75％这个取值区间内时(也即，与基准值70％的正负偏差不超过预设阈值5％)，可确定对性能指标“CPU利用率”的测试结果是正常的，类似的，当上述所有性能指标的测试结果均正常时，可确定该后续版本在压力测试下的性能正常，当至少有一个上述性能指标的测试结果不正常时，可确定该后续版本在压力测试下的性能异常。

S206：当判断结果为是时，可以确定该后续版本在压力测试下的性能正常，当判断结果为否时，可以确定该后续版本在压力测试下的性能异常，可进一步地针对异常的性能指标进行修复后，再次对该后续版本执行压力测试。

本申请实施例提供的多版本性能测试方法，除了可以用于测试之外，还可 以用于对各种系统的性能的实时监控和自动告警，这样的话，可以不用通过人工监控系统性能，而是由服务器或终端实时监控各种系统的性能是否正常，并可以向用户通知和告警，从而，不仅减轻了用户的负担，也提高了所述各种系统所在设备的可靠性。

以上为本申请实施例提供的多版本性能测试方法，基于同样的思路，本申请实施例还提供相应的多版本性能测试装置，如图3所示。

图3为本申请实施例提供的多版本性能测试装置结构示意图，具体包括：

获取模块301，用于获取待测版本的各性能指标的测试数据；

测试模块302，用于当确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配时，确定所述待测版本的性能正常，以及用于确定所述该性能指标的基准值，其中，所述该性能指标的基准值是根据所述待测版本的历史版本确定的。

所述获取模块301具体用于，通过执行预设的测试脚本，对所述待测版本进行测试，获取所述待测版本的各性能指标的测试数据。

所述测试模块302具体用于，通过执行所述测试脚本，对所述待测版本的历史版本进行测试，获取所述历史版本的该性能指标的测试数据，根据所述测试脚本中定义的测试场景，对所述历史版本的该性能指标的测试数据进行分析，确定出该性能指标的基准值。

所述测试模块302具体用于，当确定所述待测版本的每个性能指标的测试数据与该性能指标的基准值之差的绝对值均不超过预设阈值时，确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配。

具体的上述如图3所示的装置可以位于终端、服务器上。

本申请实施例提供一种多版本性能测试方法及装置，该方法获取待测版本的各性能指标的测试数据，当确定所述待测版本的每个性能指标的测试数据均与该性能指标的基准值匹配时，确定所述待测版本的性能正常，其中，所述该性能指标的基准值是根据所述待测版本的历史版本确定的。通过上述技术方 案，若已根据待测版本的历史版本确定出了各性能指标的基准值，则对于待测版本的各性能指标的测试数据，不用逐个进行人工分析，而是通过将该测试数据与对应的基准值进行匹配，即可以确定该待测版本的性能是否正常，因此，提高了测试效率，降低了测试成本。

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

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

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

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

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

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

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

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

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

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