测试数据的分析方法及装置与流程

1.本技术涉及计算机技术领域，特别涉及测试数据的分析方法。本技术同时涉及测试数据的分析装置，一种计算设备，以及一种计算机可读存储介质。

背景技术：

2.系统测试是针对整个系统的进行的测试，目的是验证系统是否满足了需求规格的定义，出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。比较常见的、典型的系统测试包括功能测试、性能测试、压力测试等。
3.目前，系统故障事件时常发生，但从当前系统的测试结果中，仅能获取到系统的各个服务器经过不断测试调整后的最终配置数据。而仅根据最终配置数据，是无法对不同时段的系统性能进行客观分析与比较，因此，就会投入大量人力、资源等，对系统故障进行排查，耗费较大的计算资源。

技术实现要素：

4.有鉴于此，本技术实施例提供了测试数据的分析方法。本技术同时涉及测试数据的分析装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的系统故障排查耗费大量的计算资源与人力的技术问题。
5.根据本技术实施例的第一方面，提供了一种测试数据的分析方法，包括：
6.接收针对目标系统的测试数据分析指令；
7.响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据；
8.基于所述历史配置数据对所述目标系统进行测试数据分析。
9.根据本技术实施例的第二方面，提供了一种测试数据的分析装置，包括：
10.指令接收模块，被配置为接收针对目标系统的测试数据分析指令；
11.数据获取模块，被配置为响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据；
12.数据分析模块，被配置为基于所述历史配置数据对所述目标系统进行测试数据分析。
13.根据本技术实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现所述测试数据的分析方法的步骤。
14.根据本技术实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现所述测试数据的分析方法的步骤。
15.本技术提供的测试数据的分析方法，接收针对目标系统的测试数据分析指令；响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据；基于所述历史配置数据对所述目标系统进行
测试数据分析。
16.本技术一实施例，在获取到对目标系统的测试数据分析指令之后，获取每次系统测试任务执行完毕后，目标系统对应的系统配置数据，在目标系统执行了至少两次测试任务时，不仅能够获得最后一次测试调整后的最终配置数据，还可获取到多次历史测试任务中目标系统对应的系统配置数据；实现了在不同时段系统出现故障时，可以通过历史测试任务中的系统配置数据，能够对系统故障问题进行客观分析与比较，提高了系统故障的排查速度，节省了部分计算资源。
附图说明
17.图1是本技术一实施例提供的一种测试数据的分析方法的场景示意图；
18.图2是本技术一实施例提供的一种测试数据的分析方法的流程图；
19.图3是本技术一实施例提供的一种应用于大促活动的测试数据的分析方法的处理流程图；
20.图4是本技术一实施例提供的一种测试数据的分析装置的结构示意图；
21.图5是本技术一实施例提供的一种计算设备的结构框图。
具体实施方式
22.在下面的描述中阐述了很多具体细节以便于充分理解本技术。但是本技术能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本技术内涵的情况下做类似推广，因此本技术不受下面公开的具体实施的限制。
23.在本技术一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术一个或多个实施例。在本技术一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本技术一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
24.应当理解，尽管在本技术一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本技术一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
25.首先，对本技术一个或多个实施例涉及的名词术语进行解释。
26.压力测试：指通过高并发数的请求对服务器进行承载力评估的测试。
27.压力测试任务：指单次对服务器进行压力测试的一系列脚本任务集合。
28.性能数据：指对压力测试中对服务器承载力进行评估的具体数据，常用的有单位时间事务次数、响应时间、数据吞吐量等。
29.服务器配置：指根据企业的实际需求针对安装有服务器操作系统的设备进行软件或者硬件的相应设置、操作，从而实现企业的业务活动需求。
30.限流：指在单位窗口时间内对单个接口请求或者方法调用限制固定次数以内。
31.限流配置：指服务器配置中限流所设置的互联网应用正常处理的最高固定次数，
超出固定次数的请求或者调用会被降级处理。
32.限流器：指根据不同的限流场景使用不同的限流方式的一系列不同的限流配置类型。
33.大促活动：简称大促，指短时间内会产生大量网络请求的互联网活动。
34.抓取工具：指通过网络请求等形式获取需要的数据信息的工具脚本。
35.自动化脚本工具：指在服务器定期自动运行的脚本工具。
36.caster平台：特指通用容器计算平台。
37.config平台：特指基础技术服务管理平台。
38.wiki文档：wiki指一种超文本系统，这种超文本系统支持面向社的协作式写作，同时也包括一组支持这种写作的辅助工具。具有方便维护、格式简单的特点。
39.系统测试是针对整个系统的进行的测试，目的是验证系统是否满足了需求规格的定义，出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。比较常见的、典型的系统测试包括功能测试、性能测试、压力测试等。
40.其中，压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能，如可靠性、稳定性等。例如，测试一个网络应用程序在不同的压力规模下的性能表现；可以通过增加并发操作的用户数量；或者不停地向网络应用程序发送请求；或一次性向网络应用程序发送特别大的数据等，来确定网络应用程序保持正常运行所能达到的最大状态，以确定系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力。
41.目前的压力测试过程中，没有对服务器数目、接口和方法限流数目等服务器配置的明确记录，通过wiki文档的形式人工维护，没有对每次压力测试任务执行的配置作记录，仅对最终结果进行记录，每次记录需要多名不同业务线的开发工程师共同维护文档，耗费大量人力，并且压力测试流程中每次任务执行时的详细配置信息也并没有留档储存，导致在比较相同压测任务在不同时段的性能数据时无法客观有效的进行评价。
42.基于此，本技术提出一种基于互联网请求的服务器配置归档的技术方案，实现简单并高效的自动化抓取服务器配置数据，辅助压测任务在不同时段的性能数据的客观比较，并大量节约人力、时间和硬件资源，提升测试效率。
43.在本技术中，提供了测试数据的分析方法，本技术同时涉及测试数据的分析装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。
44.参见图1，图1示出了本技术一实施例提供的一种测试数据的分析方法的场景示意图。
45.图1包括目标系统100、服务器102、参数配置平台104，其中，该目标系统100为需要进行系统测试的系统，包括不同应用场景下的系统架构，本实施例中对具体系统架构中的结构不作任何限定；服务器102可以理解为整个目标系统中能够执行系统测试任务的总服务器，可对目标系统中运行某一应用所涉及的服务器性能进行测试的总控服务器；参数配置平台104可以理解为维护目标系统100中的各个应用服务所配置的各种系统配置参数的平台，即整个目标系统中各种软硬件配置参数均可在参数配置平台104中进行配置并存储。
46.实际应用中，服务器102可接收到针对目标系统100的测试数据分析指令，并响应于该测试数据分析指令，从参数配置平台104中，获取该目标系统100的历史配置数据，其
中，该历史配置数据包括每次执行系统测试任务对应的系统配置数据，包括但不限定于服务器配置信息以及限流配置信息等；进一步地，在服务器102获取到每次系统测试任务执行完毕后，所确定的系统中各个参数配置数据，作为历史配置数据，并将该历史配置数据存储至服务器102的数据库中进行数据归档，便于后续在系统出现故障时，可以通过查询历史配置数据，对每次测试任务对应的系统配置数据进行数据分析，以评估分析系统性能。
47.需要说明的是，服务器配置信息可以理解为目标系统中所运行的服务器集的服务器运行数目或者容器运行个数等；限流配置信息可以理解为目标系统中各个服务器接口的限流值等，比如服务器接口能够处理请求的上限数。
48.本技术实施例提供的测试数据的分析方法，通过对目标系统中的每次执行测试任务对应的系统配置数据进行归档记录，以辅助测试任务在不同时段的性能数据的客观比较与分析，在大量节约人力、时间和硬件资源的情况下，还可提升系统测试效率。
49.图2示出了根据本技术一实施例提供的一种测试数据的分析方法的流程图，具体包括以下步骤：
50.需要说明的是，本技术实施例提供的测试数据的分析方法，以压力测试为例进行详细说明，但并不限制于系统的压力测试任务，还可包括功能测试任务等等；需要强调的是，为了能够准确地获取到历史测试任务中的系统配置数据，通过自动化地将每次执行压力测试任务时的配置数据进行归档，并录入数据库，便于后期压测任务的性能数据比较。
51.步骤202：接收针对目标系统的测试数据分析指令。
52.其中，测试数据分析指令可以理解为对系统测试任务的测试数据进行数据分析的指令。
53.实际应用中，目标系统的服务器可接收到针对该目标系统的测试数据分析指令，该服务器即可根据该测试数据分析指令完成对测试数据的分析任务。
54.需要说明的是，测试数据分析可以为周期性任务发起的任务，也可以为在特定场景下人工发起的任务；具体的，所述接收针对目标系统的测试数据分析指令，包括：
55.基于预设时间周期，接收针对目标系统的测试数据分析指令；或者
56.响应于目标用户的交互操作，接收针对目标系统的测试数据分析指令。
57.具体实施时，服务器每隔预设时间周期，可接收到对目标系统的测试数据分析指令，可理解为一种周期性日常发起的任务，比如每周一次这种低频次发起；或者服务器响应于目标用户在展示界面中的交互操作，而接收的针对目标系统的测试数据分析指令，可以理解为每天一次的高频次的发起的任务，进而根据接收到的测试数据分析指令，完成对测试数据的分析任务。
58.实际应用中，目标系统的压力测试任务可发生在不同的阶段，如果是在目标系统的大促期间，需要每间隔一段时间进行系统测试，以支持大促期间的系统承载，那么，系统就可以每间隔预设时间周期，接收到测试数据的分析指令，进而完成对测试任务对应的历史配置数据的自动化抓取；或者在大促期间的峰值阶段，也可响应于测试人员的交互操作，接收到测试任务对应的历史配置数据的自动化抓取，并利用历史配置数据对系统性能进行分析。
59.本技术实施例提供的测试数据的分析方法，通过周期性或者压力测试期间触发测试数据的分析，能够实时调整系统配置数据，以提升系统性能。
60.步骤204：响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据。
61.其中，历史配置数据可以理解为目标系统每次执行测试任务时，系统中服务器的各种配置数据；需要说明的是，由于每次系统测试并非是执行一次就能够使得系统达到最大性能，而是通过多次系统测试的执行，不断调整系统中各个服务器的参数信息等，以达到在当前状态下的较高性能即可，因此，历史配置数据即可理解为执行的多次系统测试中，每次执行完测试过程，系统对应的各个服务器的配置数据。
62.比如在此次测试任务中，一共执行了三次测试过程，分别为测试1、测试2以及测试3，那么每次执行完测试过程，都可获取到对应的系统配置数据，相应地，可获取到系统配置数据1、系统配置数据2以及系统配置数据3，因此，历史配置数据为系统配置数据1、系统配置数据2以及系统配置数据3，同时，系统配置数据3为本次测试任务中调配的最终配置数据。
63.为了能够准确地获取到每次系统测试后，系统服务器的各种配置数据，可通过自动化脚本工具方法，获取到目标系统的历史配置数据；具体的，所述获取所述目标系统的历史配置数据，包括：
64.确定所述目标系统的参数配置平台，其中，所述参数配置平台用于存储目标系统中应用对应的配置数据；
65.从所述参数配置平台中获取所述目标系统的历史配置数据。
66.实际应用中，服务器可先确定当前目标系统中存储配置参数的参数配置平台，该参数配置平台中可对系统中所有的配置数据进行查看、调配等，因此，为了能够准确地抓取到系统的配置数据，即可通过参数配置平台中获取。
67.需要说明的是，不同类型的参数配置平台，可适用于不同的数据抓取方式，才能更加快速地实现数据自动化抓取；具体的，所述从所述参数配置平台中获取所述目标系统的历史配置数据，包括：
68.确定所述参数配置平台的平台类型，基于所述平台类型确定数据抓取策略；
69.根据所述数据抓取策略，从所述参数配置平台中获取所述目标系统的历史配置数据。
70.其中，数据抓取策略可以理解为针对不同的参数配置平台确定的不同数据抓取工具，比如网络请求等形式获取需要的数据信息的工具脚本，包括但不限定于http请求方式、grpc流式传输或者ftp数据传输等形式。
71.实际应用中，服务器可通过确定参数配置平台的平台类型，确定对应的数据抓取策略，再根据数据抓取策略，从参数配置平台中获取目标系统的历史配置数据；比如，参数配置平台为系统的中控系统，可以通过接收请求的方式，主动抓取数据，即可确定数据抓取策略为通过http请求的方式获取参数配置平台中的数据。
72.基于此，该服务器可在获取系统的参数配置平台中的数据时，可根据不同的数据获取方式完成对数据的获取工作，本实施例对参数配置平台的类型以及对应的数据抓取策略均不作任何限定。
73.进一步地，为了便于对系统性能的分析，所获取的数据包括但不限于系统中服务器的运行数目以及各个服务器的各个接口的限流信息等，进而，实现对系统性能的分析；具
体的，所述参数配置平台包括服务器配置信息平台、限流配置信息平台；
74.相应地，所述从所述参数配置平台中获取所述目标系统的历史配置数据，包括：
75.从所述服务器配置信息平台中，获取所述目标系统的服务器配置信息；以及
76.从所述限流配置信息平台中，获取所述目标系统中服务器对应的限流配置信息。
77.其中，服务器配置信息平台可以理解为对系统的各个服务器集、cpu使用量、内存使用量、运行版本个数、容器情况等配置数据进行展示的平台，比如caster平台。
78.限流配置信息平台可以理解为对系统中各个服务器的接口限流器、限流数值以及配置文件信息等配置数据进行展示的平台，比如，config平台。
79.需要说明的是，目标系统中的参数配置平台，并不仅限于上述提供的两个配置信息平台，还可包括其他影响系统性能的配置平台，本实施例中对此不作具体限定。
80.实际应用中，服务器可从服务器配置信息平台中，利用数据抓取策略获取每次系统测试执行后，各个服务器对应的配置信息；同时，还可从限流配置信息平台中，利用数据抓取策略获取每次系统测试执行后，各个服务器对应的限流配置信息。
81.具体的，为了确定系统中服务器的承载力，可在每次系统测试后，获取执行测试流程时服务器的使用状况，即包括但不限定每个互联网应用在不同服务器集所运行的服务器数目；具体的，所述从所述服务器配置信息平台中，获取所述目标系统的服务器配置信息，包括：
82.从所述服务器配置信息平台中，获取所述目标系统中正在运行的服务器集标识、以及所述服务器集标识对应的服务器运行数目。
83.其中，服务器集标识可以理解为系统中互联网应用运行过程中，运行的服务器集标识，比如集代号为shylf-k8s、shjd-k8s等等。
84.实际应用中，服务器可从服务器配置信息平台中，利用数据抓取工具脚本，获取目标系统执行系统测试流程中正在运行的服务器集标识，以及每个服务器集标识对应的服务器运行数目。
85.下述表1可以在服务器配置信息平台的展示界面中，可以直观看到各个集的配置展示：
86.表1
87.集cpu使用内存使用运行版本个数容器情况shylf-k8s00mb00/0shjd-k8s80000163840mb110/10shwgq-k8s-cell01400000819200mb150/50
88.进而，服务器可获取服务器配置信息为集标识shylf-k8s，容器情况0/0、集标识shjd-k8s，容器情况10/10以及集标识shwgq-k8s-cell01，容器情况50/50。
89.此外，服务器还可从限流配置信息平台中，获取目标系统的各个服务器接口的限流信息等，以确定各个服务器的处理请求的最高次数等限流信息；具体地，所述从所述限流配置信息平台中，获取所述目标系统中各个服务器对应的限流配置信息，包括：
90.从所述限流配置信息平台中，获取所述目标系统中服务器接口对应的限流数值、以及限流值处理规则；
91.基于所述限流值处理规则对所述限流数值进行处理，获得所述目标系统中服务器
接口对应的限流配置信息。
92.其中，限流值处理规则可以理解为对服务器每个接口的处理请求限流数值进行计算，获得服务器的总限流值的处理规则，即根据系统中的限流器类型确定的计算限流数值的限流器公式，比如限流器类型为localtokenbasedlimiter，对应的限流器公式为limit＝permitspersecond；限流器类型为distributedfixedwindowlimiter，对应的限流器公式为limit＝maxpermits/timewindowinms*1000；限流器类型为distributedsimplefixedwindowlimiter，对应的限流器公式为n毫秒一次，仅作记录，不计算限流；限流器类型为distributedsimple2fixedwindowlimiter，对应的限流器公式为n毫秒一次，仅作记录，不计算限流。
93.实际应用中，服务器可从限流配置信息平台中，利用数据抓取工具脚本，获取目标系统中各个服务器接口对应的限流数值，以及限流器类型对应的限流器公式；并根据限流器公式对数据库接口的限流数值进行处理，获得目标系统中各个服务器接口对应的限流配置信息。
94.需要说明的是，通过预设的限流器公式对接口的限流数值进行计算的方式，仅为理论上确定服务器接口的最大限流量的方式，但在实际应用中，还需要考虑到系统服务器接口实际能够承载的最大限流量，进而确定出服务器接口最终实际的限流量。
95.进一步地，服务器可从限流配置信息平台中，获取每次系统测试对应的各个服务器接口的限流配置数据，比如集标识为shylf-k8s的集中，服务器1的接口a最大限流值为100、接口b最大限流值为200、接口c最大限流值为300等等，对每个接口的最大限流值均可从限流配置信息平台中获取。
96.更进一步地，在服务器获取到目标系统每次系统测试的服务器配置信息以及服务器对应的限流配置信息之后，还可将历史配置数据进行同一记录并存储至数据库进行归档，便于后续可通过查询归档数据，获取到系统在各个测试任务时对应的配置数据参数，以确定系统压力测试下的系统性能。
97.步骤206：基于所述历史配置数据对所述目标系统进行测试数据分析。
98.实际应用中，服务器还可对每次系统测试后的系统配置数据，进行系统测试数据的分析，以分析系统中各个服务器的最大承载力、能否支持较大的并发操作以及能否在短时间内处理大量的请求数据等网络应用程序保持正常运行所能达到的最大状态。
99.进而，服务器可将每次系统测试对应的历史配置数据录入数据库进行归档；具体的，所述基于所述历史配置数据对所述目标系统进行测试数据分析之后，还包括：
100.将历史配置数据存储至数据库的测试配置文件中，其中，所述测试配置文件用于存储所述目标系统的测试任务对应的系统配置信息。
101.实际应用中，服务器可将每次系统测试对应的系统配置数据录入数据库中，存储至目标系统的测试配置文件中，该测试配置文件专门用于存储目标系统的测试任务对应的系统配置数据；需要说明的是，单次归档配置数据的时长大约为30秒，并不会影响系统测试流程，同样地，也不会占用较大的内存空间。
102.通过将每次压力测试任务执行的系统配置数据进行归档存储，便于后续从数据库中对系统配置数据自动化抓取，在线上出现系统性能故障后，可快速排查故障原因，给后续配置数据变更作参考。
103.进一步地，服务器还可获取到对系统每次进行压力测试后，获得的性能测试结果，即可根据每次测试过程中系统的配置数据判定系统的这个性能测试结果是否达到最大限值，以确定系统在不同配置数据下的性能表现；具体的，所述基于所述历史配置数据对所述目标系统进行测试数据分析，包括：
104.获取所述目标系统的性能测试数据；
105.基于所述性能测试数据以及所述历史配置数据，对所述目标系统进行测试数据分析。
106.其中，性能测试数据可以理解为对目标系统中每次执行测试流程后的性能测试结果，比如单位时间执行事务次数、响应时间、数据吞吐量等，
107.实际应用中，服务器还可获取到每次系统测试的测试数据结果，比如，服务器1接口的处理请求效率为80％，进而，还可判定是否继续将系统配置数据进行调整，比如增大服务器1接口a的每秒请求的处理数量，从100调整为200，在下一次系统测试中，比较最终的测试数据结果是否提高。
108.另外，在系统出现系统故障之后，还获取每次系统测试的性能测试数据以及历史配置数据，并判定系统故障的原因；在系统版本迭代前后，也会影响系统配置数据的某些参数，因此，可通过每次系统测试对应的性能测试数据以及历史配置数据，完成对目标系统进行测试数据分析的任务。
109.需要说明的是，本实施例并非主要介绍对测试数据如何进行分析的过程，主要是对压力测试流程中，自动化抓取服务器运行数目、接口和方法限流数目等服务器配置，并归档存储；进一步地，在下一时段执行相同的压力测试任务时，还可自动抓取系统服务器配置数据，也进行数据归档，基于此，即可实现了比较相同压力测试任务在不同时段的性能数据时，能够客观有效的进行评价与分析。
110.综上，本技术实施例提供的测试数据的分析方法，使用自动化脚本工具，能够自动化地将每次执行压力测试任务时对应的配置数据进行归档，并录入数据，以辅助测试任务在不同时段的性能数据的客观比较与分析，在大量节约人力、时间和硬件资源的情况下，还可提升系统测试效率。
111.下述结合附图3，以本技术提供的测试数据的分析方法在大促活动的应用为例，对所述测试数据的分析方法进行进一步说明。其中，图3示出了本技术一实施例提供的一种应用于大促活动的测试数据的分析方法的处理流程图，具体包括以下步骤：
112.需要说明的是，大促活动为短时间内会产生大量网络请求的互联网活动；为了支持大促活动中系统能够正常运行，可预先对系统的承载力进行测试，并对测试数据进行分析，以便于出现系统故障时，能够及时排查故障原因，并为后续配置数据的变更提供参考。
113.步骤302：服务器响应于用户的交互操作，接收目标系统的测试数据分析指令。
114.步骤304：服务器响应于测试数据分析指令，对系统进行压力测试，获取每一次压力测试对应的系统配置数据。
115.需要说明的是，系统配置数据可通过自动化运行脚本完成数据自动化抓取，避免了人工记录系统配置数据出现的数据错误，数据漏记等不准确的情况发生。
116.步骤306：服务器对每一次压力测试对应的系统配置数据存储至数据库的配置文件中。
117.步骤308：服务器对每一次压力测试产出的性能数据进行记录，并存储至数据库。
118.步骤310：服务器根据性能数据以及系统配置数据，进行测试数据分析。
119.通过将每一次压力测试任务的系统配置数据与压力测试任务相关联，即可比较相同压力测试任务下，不同时段对应的系统配置数据，以确定当前系统的性能表现。
120.综上，通过对配置数据抓取工具，能够对周期性日常配置数据归档、以及压力测试期间配置数据归档，用于线上出现性能故障后快速排查故障原因，并给后续配置数据变更作参考。
121.与上述方法实施例相对应，本技术还提供了测试数据的分析装置实施例，图4示出了本技术一实施例提供的一种测试数据的分析装置的结构示意图。如图4所示，该装置包括：
122.指令接收模块402，被配置为接收针对目标系统的测试数据分析指令；
123.数据获取模块404，被配置为响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据；
124.数据分析模块406，被配置为基于所述历史配置数据对所述目标系统进行测试数据分析。
125.可选地，所述数据获取模块404，进一步被配置为：
126.确定所述目标系统的参数配置平台，其中，所述参数配置平台用于存储目标系统中应用对应的配置数据；
127.从所述参数配置平台中获取所述目标系统的历史配置数据。
128.可选地，所述参数配置平台包括服务器配置信息平台、限流配置信息平台；
129.可选地，所述数据获取模块404，进一步被配置为：
130.从所述服务器配置信息平台中，获取所述目标系统的服务器配置信息；以及
131.从所述限流配置信息平台中，获取所述目标系统中服务器对应的限流配置信息。
132.可选地，所述数据获取模块404，进一步被配置为：
133.确定所述参数配置平台的平台类型，基于所述平台类型确定数据抓取策略；
134.根据所述数据抓取策略，从所述参数配置平台中获取所述目标系统的历史配置数据。
135.可选地，所述数据获取模块404，进一步被配置为：
136.从所述服务器配置信息平台中，获取所述目标系统中正在运行的服务器集标识、以及所述服务器集标识对应的服务器运行数目。
137.可选地，所述数据获取模块404，进一步被配置为：
138.从所述限流配置信息平台中，获取所述目标系统中服务器接口对应的限流数值、以及限流值处理规则；
139.基于所述限流值处理规则对所述限流数值进行处理，获得所述目标系统中服务器接口对应的限流配置信息。
140.可选地，所述装置，还包括：
141.数据存储模块，被配置为将历史配置数据存储至数据库的测试配置文件中，其中，所述测试配置文件用于存储所述目标系统的测试任务对应的系统配置信息。
142.可选地，所述数据分析模块406，进一步被配置为：
143.获取所述目标系统的性能测试数据；
144.基于所述性能测试数据以及所述历史配置数据，对所述目标系统进行测试数据分析。
145.可选地，所述指令接收模块402，进一步被配置为：
146.基于预设时间周期，接收针对目标系统的测试数据分析指令；或者
147.响应于目标用户的交互操作，接收针对目标系统的测试数据分析指令。
148.本技术实施例提供的测试数据的分析装置，在获取到对目标系统的测试数据分析指令之后，获取每次系统测试任务执行完毕后，目标系统对应的系统配置数据，在目标系统执行了至少两次测试任务时，不仅能够获得最后一次测试调整后的最终配置数据，还可获取到多次历史测试任务中目标系统对应的系统配置数据；实现了在不同时段系统出现故障时，可以通过历史测试任务中的系统配置数据，能够对系统故障问题进行客观分析与比较，提高了系统故障的排查速度，节省了部分计算资源。
149.上述为本实施例的一种测试数据的分析装置的示意性方案。需要说明的是，该测试数据的分析装置的技术方案与上述的测试数据的分析方法的技术方案属于同一构思，测试数据的分析装置的技术方案未详细描述的细节内容，均可以参见上述测试数据的分析方法的技术方案的描述。
150.图5示出了根据本技术一实施例提供的一种计算设备500的结构框图。该计算设备500的部件包括但不限于存储器510和处理器520。处理器520与存储器510通过总线530相连接，数据库550用于保存数据。
151.计算设备500还包括接入设备540，接入设备540使得计算设备500能够经由一个或多个网络560通信。这些网络的示例包括公用交换电话网(pstn)、局域网(lan)、广域网(wan)、个域网(pan)或诸如因特网的通信网络的组合。接入设备540可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(nic))中的一个或多个，诸如ieee802.11无线局域网(wlan)无线接口、全球微波互联接入(wi-max)接口、以太网接口、通用串行总线(usb)接口、蜂窝网络接口、蓝牙接口、近场通信(nfc)接口，等等。
152.在本技术的一个实施例中，计算设备500的上述部件以及图5中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图5所示的计算设备结构框图仅仅是出于示例的目的，而不是对本技术范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。
153.计算设备500可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或pc的静止计算设备。计算设备500还可以是移动式或静止式的服务器。
154.其中，处理器520执行所述计算机指令时实现所述的测试数据的分析方法的步骤。
155.上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的测试数据的分析方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述测试数据的分析方法的技术方案的描述。
156.本技术一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算
机指令被处理器执行时实现如前所述测试数据的分析方法的步骤。
157.上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的测试数据的分析方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述测试数据的分析方法的技术方案的描述。
158.上述对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
159.所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-only memory)、随机存取存储器(ram，randomaccess memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
160.需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本技术所必须的。
161.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
162.以上公开的本技术优选实施例只是用于帮助阐述本技术。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本技术的内容，可作很多的修改和变化。本技术选取并具体描述这些实施例，是为了更好地解释本技术的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本技术。本技术仅受权利要求书及其全部范围和等效物的限制。

技术特征：

1.一种测试数据的分析方法，其特征在于，包括：接收针对目标系统的测试数据分析指令；响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据；基于所述历史配置数据对所述目标系统进行测试数据分析。2.根据权利要求1所述的方法，其特征在于，所述获取所述目标系统的历史配置数据，包括：确定所述目标系统的参数配置平台，其中，所述参数配置平台用于存储目标系统中应用对应的配置数据；从所述参数配置平台中获取所述目标系统的历史配置数据。3.根据权利要求2所述的方法，其特征在于，所述参数配置平台包括服务器配置信息平台、限流配置信息平台；相应地，所述从所述参数配置平台中获取所述目标系统的历史配置数据，包括：从所述服务器配置信息平台中，获取所述目标系统的服务器配置信息；以及从所述限流配置信息平台中，获取所述目标系统中服务器对应的限流配置信息。4.根据权利要求2所述的方法，其特征在于，所述从所述参数配置平台中获取所述目标系统的历史配置数据，包括：确定所述参数配置平台的平台类型，基于所述平台类型确定数据抓取策略；根据所述数据抓取策略，从所述参数配置平台中获取所述目标系统的历史配置数据。5.根据权利要求3所述的方法，其特征在于，所述从所述服务器配置信息平台中，获取所述目标系统的服务器配置信息，包括：从所述服务器配置信息平台中，获取所述目标系统中正在运行的服务器集标识、以及所述服务器集标识对应的服务器运行数目。6.根据权利要求3所述的方法，其特征在于，所述从所述限流配置信息平台中，获取所述目标系统中各个服务器对应的限流配置信息，包括：从所述限流配置信息平台中，获取所述目标系统中服务器接口对应的限流数值、以及限流值处理规则；基于所述限流值处理规则对所述限流数值进行处理，获得所述目标系统中服务器接口对应的限流配置信息。7.根据权利要求1所述的方法，其特征在于，所述基于所述历史配置数据对所述目标系统进行测试数据分析之后，还包括：将历史配置数据存储至数据库的测试配置文件中，其中，所述测试配置文件用于存储所述目标系统的测试任务对应的系统配置信息。8.根据权利要求7所述的方法，其特征在于，所述基于所述历史配置数据对所述目标系统进行测试数据分析，包括：获取所述目标系统的性能测试数据；基于所述性能测试数据以及所述历史配置数据，对所述目标系统进行测试数据分析。9.根据权利要求1所述的方法，其特征在于，所述接收针对目标系统的测试数据分析指令，包括：
基于预设时间周期，接收针对目标系统的测试数据分析指令；或者响应于目标用户的交互操作，接收针对目标系统的测试数据分析指令。10.一种测试数据的分析装置，其特征在于，包括：指令接收模块，被配置为接收针对目标系统的测试数据分析指令；数据获取模块，被配置为响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次测试任务对应的系统配置数据；数据分析模块，被配置为基于所述历史配置数据对所述目标系统进行测试数据分析。11.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述计算机指令时实现权利要求1-9任意一项所述方法的步骤。12.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该计算机指令被处理器执行时实现权利要求1-9任意一项所述方法的步骤。

技术总结

本申请提供测试数据的分析方法及装置，其中所述测试数据的分析方法包括：接收针对目标系统的测试数据分析指令；响应于所述测试数据分析指令，获取所述目标系统的历史配置数据，其中，所述历史配置数据包括至少两次执行测试任务对应的系统配置数据；基于所述历史配置数据对所述目标系统进行测试数据分析；实现了在不同时段系统出现故障时，可以通过历史测试任务中的系统配置数据，能够对系统故障问题进行客观分析与比较，提高了系统故障的排查速度，节省了部分计算资源。节省了部分计算资源。节省了部分计算资源。