集中配置管理系统测试报告的生成方法及装置与流程

本申请涉及系统测试技术领域，具体而言，涉及一种集中配置管理系统测试报告的生成方法及装置。

背景技术：

puppet是一种linux、unix平台的集中配置管理系统，使用ruby语言，可管理配置文件、用户、cron任务、软件包、系统服务等。puppet把这些系统实体称之为资源，puppet的设计目标是简化对这些资源的管理以及妥善处理资源间的依赖关系。

在实际生产环境中，将puppet的资源封装成模块来完成环境的部署。同其他代码一样，模块也需要进行测试才能够保证其功能的正确性。通常情况下，会采用手工方式来进行测试，整理bug，修复最后上线使用。但是手工方式的效率相对很低，会降低整个产品迭代上线的速度，因此引入自动化测试。在整个自动化测试的过程中，会自动完成相关用例的执行，收集执行的结果并整理成一份可读性较强的测试报告来反馈测试的情况。

puppet官方网站提供了一种开源的自动化测试化工具beaker，可用来调度虚拟测试环境来完成自动化测试。beaker是基于rspec的开发套件，rspec在执行完成后执行结果可以通过标准输出，json，xml甚至输出一份html文件来进行保存和展示。本文将rspec输出的json结果进行了保存，统计分析，最后渲染成一份可读性强的报告，克服rspec报告可读性不强的缺点，同时实现报告的可订阅功能。在相关技术里面有描述到，beaker是基于rspec的开发套件，rspec可支持json，xml，html这几种类型的报告。在现有的方案里面，经常使用到的就是利用rspec来输出一份html报告。然而，在rspec报告中可以比较直观的反应单个用例的执行结果，但是在一次自动化测试的过程中，需要的不仅仅是单个用例的测试情况。通常情况下，需要整体上了解测试的情况。总结rspec测试报告，有如下几方面的不足:没有整体上反应测试的情况，报告主要针对单个用例进行分析，不进行整体的统计分析；报告的可读性不好。对于json格式和xml格式的报告，对普通用户来说是完全不可读的，而其输出的html报告，把所有信息都糅合在一份报告中，很难理出用户关心的内容，尤其是执行错误的报告信息。在beaker测试过程中，会多次执行rspec命令，输出多份测试报告，现有技术暂时没有提供方式能够整合多份测试报告的结果。

针对相关技术中测试报告难以从整体上反映测试情况的问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请的主要目的在于提供一种集中配置管理系统测试报告的生成方法及装置，以解决相关技术中测试报告难以从整体上反映测试情况的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种集中配置管理系统测试报告的生成方法。该方法包括：检测集中配置管理系统的代码是否已更新；若检测到所述集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，所述多个待测试操作系统由所述集中配置管理系统配置；获取所述多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例；逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果；基于所述多个测试结果生成测试报告。

进一步地，基于所述多个测试结果生成测试报告包括：对所述多个测试结果进行分析，得到第一目标数据信息和第二目标数据信息，其中，所述第一目标数据信息中至少包括：测试用例的数量、测试失败的数量和测试成功的数量，所述第二目标数据信息中至少包括：每个待测试操作系统中每个模块的测试信息和对待测试操作系统中模块测试失败的信息；将所述第一目标数据信息和所述第二目标数据信息填充至预设模板中，生成所述测试报告。

进一步地，逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果之前，所述方法还包括：生成与每个待测试操作系统中每个模块对应的目标文件夹，其中，所述目标文件夹用于存储对应的模块的测试结果；确定每个目标文件夹的存储路径。

进一步地，逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果包括：确定当前正在执行测试用例的模块；基于所述当前正在执行测试用例的模块调整其测试结果指向的目标文件夹；将对当前正在执行测试用例的模块的测试结果逐条写入指向的所述目标文件夹下。

进一步地，在获取每个待测试操作系统中每个模块对应的测试用例之前，所述方法还包括：获取更新后的所述集中配置管理系统的代码；将所述集中配置管理系统的代码逐次同步至缓存区中；在获取每个待测试操作系统中每个模块对应的测试用例之后，所述方法还包括：将所述缓存区中更新后的代码移动至工作区，根据所述测试用例和所述更新后的代码对对应的模块进行测试，其中，所述工作区是所述集中配置管理系统的代码执行时的目录。

进一步地，所述集中配置管理系统的代码包括多个分支代码，将所述集中配置管理系统的代码逐次同步至缓存区中包括：确定待同步至所述缓存区中的当前分支代码；判断在所述缓存区中是否存在以所述当前分支代码命名的文件夹；如果在所述缓存区中不存在以所述当前分支代码命名的文件夹，在所述缓存区中创建以当前分支代码命名的文件夹，并将所述当前分支代码同步至所述缓存区中以所述当前分支代码命名的文件夹下。

为了实现上述目的，根据本申请的另一方面，提供了一种集中配置管理系统测试报告的生成装置。该装置包括：检测单元，用于检测集中配置管理系统的代码是否已更新；确定单元，用于若检测到所述集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，所述多个待测试操作系统由所述集中配置管理系统配置；第一获取单元，用于获取所述多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例；测试单元，用于逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果；生成单元，用于基于所述多个测试结果生成测试报告。

进一步地，所述生成单元包括：分析模块，用于对所述多个测试结果进行分析，得到第一目标数据信息和第二目标数据信息，其中，所述第一目标数据信息中至少包括：测试用例的数量、测试失败的数量和测试成功的数量，所述第二目标数据信息中至少包括：每个待测试操作系统中每个模块的测试信息和对待测试操作系统中模块测试失败的信息；填充模块，用于将所述第一目标数据信息和所述第二目标数据信息填充至预设模板中，生成所述测试报告。

进一步地，所述装置还包括：第二获取单元，用于在获取每个待测试操作系统中每个模块对应的测试用例之前，获取更新后的所述集中配置管理系统的代码；同步单元，用于将所述集中配置管理系统的代码逐次同步至缓存区中；所述装置还包括：移动单元，用于在获取每个待测试操作系统中每个模块对应的测试用例之后，将所述缓存区中更新后的代码移动至工作区，根据所述测试用例和所述更新后的代码对对应的模块进行测试，其中，所述工作区是所述集中配置管理系统的代码执行时的目录。

进一步地，所述集中配置管理系统的代码包括多个分支代码，所述同步单元包括：确定模块，用于确定待同步至所述缓存区中的当前分支代码判断模块，用于判断在所述缓存区中是否存在以所述当前分支代码命名的文件夹；同步模块，用于在所述缓存区中不存在以所述当前分支代码命名的文件夹的情况下，在所述缓存区中创建以当前分支代码命名的文件夹，并将所述当前分支代码同步至所述缓存区中以所述当前分支代码命名的文件夹下。

为了实现上述目的，根据本申请的另一方面，提供了一种存储介质，所述存储介质包括存储的程序，其中，所述程序执行上述任意一项所述的集中配置管理系统测试报告的生成方法。

为了实现上述目的，根据本申请的另一方面，提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述任意一项所述的集中配置管理系统测试报告的生成方法。

为了实现上述目的，根据本申请的另一方面，提供了一种终端，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行上述任意一项所述的集中配置管理系统测试报告的生成方法。

通过本申请，采用以下步骤：检测集中配置管理系统的代码是否已更新；若检测到集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，多个待测试操作系统由集中配置管理系统配置；获取多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例；逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果；基于多个测试结果生成测试报告，解决了相关技术中测试报告难以从整体上反映测试情况的问题。通过在检测到集中配置管理系统的代码已更新时，触发对待测试操作系统进行测试，并基于测试得到的多个测试结果生成测试报告，进而达到了生成的测试报告可以从整体上反映测试情况的效果。

附图说明

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

图1是根据本申请实施例提供的集中配置管理系统测试报告的生成方法的流程图；

图2是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中缓存区结构的示意图；

图3是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中代码从缓存区搬运到工作区的示意图；

图4是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中测试用例结构图；

图5是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中测试结果保存目录的示意图；

图6是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中软链接结构的示意图；

图7是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中测试结果样式的示意图；

图8是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中第一目标数据信息的示意图；

图9是根据本申请实施例提供的集中配置管理系统测试报告的生成方法中第二目标数据信息的示意图；以及

图10是根据本申请实施例提供的集中配置管理系统测试报告的生成装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：

vagrant：一个基于ruby的工具，用于创建和部署虚拟化开发环境。它使用oracle的开源virtualbox虚拟化系统，使用chef创建自动化虚拟环境。

beaker：puppetlabs中一款开源的自动化测试工具，用于测试大型复杂的puppet系统。它可以通过本地的虚拟主机或者云平台来搭建测试环境，一旦测试环境运行起来，beaker可以用重复的方式来执行测试用例。

erb：embeddedruby是ruby的一项功能，允许开发者很方便的根据模板生成任何类型任何数量的文本。模板本身与ruby代码合并，通过文本中嵌入的变量来进行替换和控制，使得模板很容易编写和维护。

git：一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。

实施例1

根据本申请的实施例，提供了一种集中配置管理系统测试报告的生成方法。

图1是根据本申请实施例的集中配置管理系统测试报告的生成方法的流程图。如图1所示，该方法包括以下步骤：

步骤s101，检测集中配置管理系统的代码是否已更新。

本申请的实施例中，一旦集中配置管理系统(puppet)中的代码发生变化(即检测到集中配置管理系统的代码已更新)，检测到更新后利用beaker来进行自动化测试，，在本申请实施例中的预先在gitlab上配置了一个钩子(hook)，利用gitlab的钩子(hook)功能，每次有代码提交会发送一个post请求给测试机，触发自动化测试。在本步骤中判断集中配置管理系统的代码发生变化，即为检测集中配置管理系统的代码是否已更新。

步骤s102，若检测到集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，多个待测试操作系统由集中配置管理系统配置。

在本申请中的待测试操作系统由集中配置管理系统配置。一旦检测到集中配置管理系统的代码已更新，由集中配置管理系统配置的操作系统的相关配置就会发生变化，因此，需要对其进行测试，因此，若检测到集中配置管理系统的代码已更新，则确定需要根据集中配置管理系统的代码进行测试的操作系统，将其作为待测试操作系统，这里确定多个待测试操作系统的原因是因为集中配置管理系统可以应用于不同的操作系统。

步骤s103，获取多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例。

由于每个待测试操作系统中包括多个模块，在对每个操作系统进行测试时会将具体的模块进行拆分，针对具体的模块采用对应的测试用例，因此一次测试完成需要运行多组测试用例。因此，在检测到集中配置管理系统的代码已更新后，需要获取多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例。

可选地，为了避免正在进行的测试代码被后面提交的测试代码所覆盖，在本申请实施例提供的集中配置管理系统测试报告的生成方法中，在获取每个待测试操作系统中每个模块对应的测试用例之前，该方法还包括：获取更新后的集中配置管理系统的代码；将集中配置管理系统的代码逐次同步至缓存区中；在获取每个待测试操作系统中每个模块对应的测试用例之后，该方法还包括：将缓存区中更新后的代码移动至工作区，根据测试用例和更新后的代码对对应的模块进行测试，其中，工作区是集中配置管理系统的代码执行时的目录。

例如，在测试机收到来自于gitlab的消息时，在本申请实施例中同步gitlab上的代码到测试机的缓存区，在正式开始测试时，将代码从缓存区移动到工作区，根据测试用例和更新后的代码对对应的模块进行测试。

可选地，在本申请实施例提供的集中配置管理系统测试报告的生成方法中，集中配置管理系统的代码包括多个分支代码，将集中配置管理系统的代码逐次同步至缓存区中包括：确定待同步至缓存区中的当前分支代码；判断在缓存区中是否存在以当前分支代码命名的文件夹；如果在缓存区中不存在以当前分支代码命名的文件夹，在缓存区中创建以当前分支代码命名的文件夹，并将当前分支代码同步至缓存区中以当前分支代码命名的文件夹下。

例如，在缓存区里，以代码分支为名创建文件夹，在文件夹里面存放了此分支的代码。缓存区结构的示意图，如图2所示。例如有4个分支代码在缓存区中，分别为branch_a、branch_b、branch_c和branch_d，代码的更新分为两种情况：当前更新的分支代码还在缓存区中，这种情况表明此分支的代码还未来得及测试，又有新的提交，此时新提交的代码会去覆盖已经存在的代码。例如branch_a已经存在缓存区，当有程序继续向branch_a提交代码时，此时新的代码会覆盖branch_a这个目录。当前更新的分支代码在缓存区不存在，此时会以当前分支为名创建文件夹，并且把当前分支的代码同步到此文件夹。如果图2中所示的branch_d之前不存在，假如当前更新的分支为branch_d，则创建branch_d文件夹，然后将代码同步到此文件夹中。

当在工作区的执行的任务测试完毕之后，将缓存区中最早缓存的代码移动到工作区，执行测试任务。如图3所示，代码从缓存区搬运到工作区，左边虚线框表示被移动的文件夹在执行移动操作后就不再出现在缓存区。

步骤s104，逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果。

在多个操作系统上需要分别执行测试用例，例如10个操作系统，测试用例有100条，10个操作系统每个都需要把这100条测试用例运行一次，因此需要运行100*10＝100次。在进行用例设计时，将测试用例根据具体的功能来进行分组，例如10条测试用例测试网络相关功能，4条用例防火墙操作等等。如图4所示，在执行测试用例时，依次在宿主机上开启测试虚拟机，例如debian7，然后按照模块(网络模块，防火墙模块)依次再执行测试用例，每次执行测试用例后会返回当前测试用例的执行结果。

可选地，为了将测试结果进行有序组织，在本申请实施例提供的集中配置管理系统测试报告的生成方法中，逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果之前，该方法还包括：生成与每个待测试操作系统中每个模块对应的目标文件夹，其中，目标文件夹用于存储对应的模块的测试结果；确定每个目标文件夹的存储路径。逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果包括：确定当前正在执行测试用例的模块；基于当前正在执行测试用例的模块调整其测试结果指向的目标文件夹；将对当前正在执行测试用例的模块的测试结果逐条写入指向的目标文件夹下。

在测试过程中，每执行一个测试用例时，都会产生一个当前测试用例的测试结果。为了在后期整理结果时方便知道某个测试结果是具体某台操作系统中执行某个模块中的测试用例产生的。在本申请实施例中在具体用例执行时，在本申请实施例中设置一个总的调度模块，该调度模块负责调度具体的测试操作系统执行具体的测试用例。而具体的执行依靠的是执行测试用例，同时报告也是这个测试用例产生的。

在本申请中将测试用例与测试结果进行设置关联。具体地，调度模块在开始执行时，会根据需要执行的操作系统及模块初始化一个文件夹。例如图4中需要在debian7，debian8，debian9中分别执行网络模块，防火墙模块以及文件权限模块。将初始化出来一个如图5所示的目录结构。例如，测试结果保存目录为reports文件夹，初始化完成之后在reports目录下将会根据测试的操作系统类型，初始化出debian7，debian8，debian9三个目录，然后在debian7，debian8，debian9三个目录下分别会存在network，filewall以及filepermission三个文件。在调度模块开始调度某个虚拟机开始执行用例时，调度模块会做执行两件任务，第一，调度模块会在此操作系统对应的文件目录创建一个指向文件夹的软链接，在本申请实施例中将此软链接命名为linkmachine。当现在需要开始在debian7虚拟机执行时，将linkmachine指向debian7目录，此时的效果是，当访问reports/linkmachine时，实际访问的是reports/debian7目录。第二，调度模块会在reports/debian7中创建一个指向文件的软链接，将其命名为linkmodule，例如现在测试的是network模块中的测试用例，则linkmodule指向network文件。此时当访问reports/linkmachine/linkmodule这个文件，实际上访问的是reports/debian7/network文件，如图6所示。

顶层模块在每次调度执行时，会根据当前运行的测试系统和模块更改指针指向，例如执行debian8操作系统中的firewall模块，则会将linkmachine指向debian8文件夹，将linkmodule指向firewall文件。具体执行测试的实例只需要将测试结果逐条写入到reports/linkmachine/linkmodule文件中。

需要说明的是，为了减小了系统性能的开销，提升测试处理效率，在本申请实施例中也可以将测试生成的测试结果直接作为一个变量保存起来。

步骤s105，基于多个测试结果生成测试报告。

根据多个测试结果整理出一份可视化程度高的测试报告。生成的测试报告可以从整体上反映测试情况的效果。

可选地，在本申请实施例提供的集中配置管理系统测试报告的生成方法中，基于多个测试结果生成测试报告包括：对多个测试结果进行分析，得到第一目标数据信息和第二目标数据信息，其中，第一目标数据信息中至少包括：测试用例的数量、测试失败的数量和测试成功的数量，第二目标数据信息中至少包括：每个待测试操作系统中每个模块的测试信息和对待测试操作系统中模块测试失败的信息；将第一目标数据信息和第二目标数据信息填充至预设模板中，生成测试报告。

具体地，测试完成之后，测试结果将会被组织成如图7的形式，每个模块中的测试用例执行结果将会保存在对应的模块文件中，例如，在debian7中执行network模块中的n_case_1的结果将会被保存在debian7目录下的network文件中，记录成n_caseresult_1这一条记录。结果统计从测试系统和模块两个维度进行统计，扫描某个操作系统例如debian7目录下所有的文件，然后逐条读取文件中的执行结果。整体上统计此次执行总共的用例数，执行失败数和成功数。并且分模块来整理成功失败的用例数，对于失败的用例还会将失败的原因进行统计。

根据上述汇总的数据渲染出一份直观的测试报告。可以采用静态网页是展示报告的形式，会将静态网页制作成一个报告的模板，在测试完成之后，将数据填充在模板中则可渲染出测试报告。

在本申请实施例中的静态网页主要包括两个页面，一个是信息总览页面，至少包括测试用例的总数，成功多少，失败多少。另一个则为各个操作系统下的详细测试信息，里面至少包括具体模块的测试信息，失败用例的信息。如图8所示，图8为本申请实施例生成的测试报告的示意图。

在本申请中的预设模板是利用上述的静态网页，将一些数据提取出来，然后更换成rubyerb的语法。可以将上述的操作系统，测试用例执行情况制作成如图9所示的预设模板。图9中的is_success，passed这些都是erb模板变量。

在每次测试完成之后，利用汇总的测试数据，填充到上述的预设模板中，例如is_success＝”失败”，passed＝120填充到模板中，即可渲染成本申请实施例中的测试报告。通过上述操作，实现了整理自动化测试的结果，包括执行失败和成功的统计条目，失败用例对应模块或者接口的相关信息，用于后续问题的跟进和调试。

在本申请实施例中利用beaker-rspec作为核心的测试技术，在此基础上以vagrant作为测试的载体来运行测试，解决多个操作系统的测试问题。通过新增或者修改模块，提交到git之后自动触发测试的运行，在测试过程中根据不同的操作系统来对测试结果进行归类。最终进行汇总和分析，渲染成一份可读性强且包含调试信息的测试报告，进而达到了生成的测试报告可以从整体上反映测试情况的效果。

综上所述，本申请实施例提供的集中配置管理系统测试报告的生成方法，通过检测集中配置管理系统的代码是否已更新；若检测到集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，多个待测试操作系统由集中配置管理系统配置；获取多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例；逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果；基于多个测试结果生成测试报告，解决了相关技术中测试报告难以从整体上反映测试情况的问题。通过在检测到集中配置管理系统的代码已更新时，触发对待测试操作系统进行测试，并基于测试得到的多个测试结果生成测试报告，进而达到了生成的测试报告可以从整体上反映测试情况的效果。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例2

本申请实施例还提供了一种集中配置管理系统测试报告的生成装置，需要说明的是，本申请实施例的集中配置管理系统测试报告的生成装置可以用于执行本申请实施例所提供的用于集中配置管理系统测试报告的生成方法。以下对本申请实施例提供的集中配置管理系统测试报告的生成装置进行介绍。

图10是根据本申请实施例的集中配置管理系统测试报告的生成装置的示意图。如图10所示，该装置包括：检测单元10、确定单元20、第一获取单元30、测试单元40和生成单元50。

具体地，检测单元10，用于检测集中配置管理系统的代码是否已更新。

确定单元20，用于若检测到集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，多个待测试操作系统由集中配置管理系统配置。

第一获取单元30，用于获取多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例。

测试单元40，用于逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果。

生成单元50，用于基于多个测试结果生成测试报告。

本申请实施例提供的集中配置管理系统测试报告的生成装置，通过检测单元10检测集中配置管理系统的代码是否已更新；确定单元20若检测到集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，多个待测试操作系统由集中配置管理系统配置；第一获取单元30获取多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例；测试单元40逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果；生成单元50基于多个测试结果生成测试报告，解决了相关技术中测试报告难以从整体上反映测试情况的问题。通过在检测到集中配置管理系统的代码已更新时，触发对待测试操作系统进行测试，并基于测试得到的多个测试结果生成测试报告，进而达到了生成的测试报告可以从整体上反映测试情况的效果。

可选地，在本申请实施例提供的集中配置管理系统测试报告的生成装置中，生成单元50包括：分析模块，用于对多个测试结果进行分析，得到第一目标数据信息和第二目标数据信息，其中，第一目标数据信息中至少包括：测试用例的数量、测试失败的数量和测试成功的数量，第二目标数据信息中至少包括：每个待测试操作系统中每个模块的测试信息和对待测试操作系统中模块测试失败的信息；填充模块，用于将第一目标数据信息和第二目标数据信息填充至预设模板中，生成测试报告。

可选地，在本申请实施例提供的集中配置管理系统测试报告的生成装置中，该装置还包括：第二获取单元，用于在获取每个待测试操作系统中每个模块对应的测试用例之前，获取更新后的集中配置管理系统的代码；同步单元，用于将集中配置管理系统的代码逐次同步至缓存区中；其中，该装置还包括：移动单元，用于在获取每个待测试操作系统中每个模块对应的测试用例之后，将缓存区中更新后的代码移动至工作区，根据测试用例和更新后的代码对对应的模块进行测试，其中，工作区是集中配置管理系统的代码执行时的目录。

可选地，在本申请实施例提供的集中配置管理系统测试报告的生成装置中，集中配置管理系统的代码包括多个分支代码，同步单元包括：确定模块，用于确定待同步至缓存区中的当前分支代码；判断模块，用于判断在缓存区中是否存在以当前分支代码命名的文件夹；同步模块，用于在缓存区中不存在以当前分支代码命名的文件夹的情况下，在缓存区中创建以当前分支代码命名的文件夹，并将当前分支代码同步至缓存区中以当前分支代码命名的文件夹下。

所述集中配置管理系统测试报告的生成装置包括处理器和存储器，上述检测单元10、确定单元20、第一获取单元30、测试单元40和生成单元50等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来生成集中配置管理系统测试报告。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)，存储器包括至少一个存储芯片。

本发明实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现所述集中配置管理系统测试报告的生成方法。

本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行所述集中配置管理系统测试报告的生成方法。

本发明实施例提供了一种终端，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行所述的集中配置管理系统测试报告的生成方法。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：检测集中配置管理系统的代码是否已更新；若检测到所述集中配置管理系统的代码已更新，确定多个待测试操作系统，其中，所述多个待测试操作系统由所述集中配置管理系统配置；获取所述多个待测试系统中的每个待测试操作系统中每个模块对应的测试用例；逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果；基于所述多个测试结果生成测试报告。

基于所述多个测试结果生成测试报告包括：对所述多个测试结果进行分析，得到第一目标数据信息和第二目标数据信息，其中，所述第一目标数据信息中至少包括：测试用例的数量、测试失败的数量和测试成功的数量，所述第二目标数据信息中至少包括：每个待测试操作系统中每个模块的测试信息和对待测试操作系统中模块测试失败的信息；将所述第一目标数据信息和所述第二目标数据信息填充至预设模板中，生成所述测试报告。

逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果之前，所述方法还包括：生成与每个待测试操作系统中每个模块对应的目标文件夹，其中，所述目标文件夹用于存储对应的模块的测试结果；确定每个目标文件夹的存储路径。

逐次采用每个测试用例对对应的模块进行测试，得到多个测试结果包括：确定当前正在执行测试用例的模块；基于所述当前正在执行测试用例的模块调整其测试结果指向的目标文件夹；将对当前正在执行测试用例的模块的测试结果逐条写入指向的所述目标文件夹下。

在获取每个待测试操作系统中每个模块对应的测试用例之前，所述方法还包括：获取更新后的所述集中配置管理系统的代码；将所述集中配置管理系统的代码逐次同步至缓存区中；在获取每个待测试操作系统中每个模块对应的测试用例之后，所述方法还包括：将所述缓存区中更新后的代码移动至工作区，根据所述测试用例和所述更新后的代码对对应的模块进行测试，其中，所述工作区是所述集中配置管理系统的代码执行时的目录。

所述集中配置管理系统的代码包括多个分支代码，将所述集中配置管理系统的代码逐次同步至缓存区中包括：确定待同步至所述缓存区中的当前分支代码；判断在所述缓存区中是否存在以所述当前分支代码命名的文件夹；如果在所述缓存区中不存在以所述当前分支代码命名的文件夹，在所述缓存区中创建以当前分支代码命名的文件夹，并将所述当前分支代码同步至所述缓存区中以所述当前分支代码命名的文件夹下。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

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

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

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

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

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

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