大型软件中的QF快速集成机制及自动选择算法

向 尕 张仰森

(北京信息科技大学 北京 100192)

0 引 言

大型软件具有开发人员众多、软件规模大、复杂度高、模块多、补丁多、部分补丁依赖具体的硬件资源及软件配置参数等特点。比如电信领域，其中某一个网元的软件通常由数十、数百的工程师分模块来开发完成，软件的规模和复杂度都较高。软件进行质量的测试,是对软件质量的保障的十分重要的方式[1]。在大型软件产品发布交付之前的集成和验证阶段，会发现一些在前期单元测试和模块功能测试中无法发现的问题。为了修复这些问题，各个模块通常会提供快速补丁(Quick Fix，QF)。与此同时，这个阶段通常非常接近产品的交付时间点，目前为了缩短产品的交付周期，通常给系统集成和验证的时间很短，同时对按期交付的时间要求非常严格。因此，在大型软件开发中靠近交付时间点的集成验证阶段，快速集成QF，并且保证产品质量稳定、保证按期交付成为一个需要解决的重要问题。如果要多集成QF，则有可能延期交付。如果优先按时交付，则有可能无法集成所有的QF。

要将这些QF集成到产品中，传统的方法有三种：

(1) 在发布的产品中不包括这些QF，优先保证交付时间，等待后续发布的补丁包(Patch)来集成，这样的缺点显而易见，QF不能被迅速地集成到即将发布的产品中，无法保证提高产品的质量。

(2) 将这些QF加到产品发布中，重新编译软件模块，这样做的问题是有可能延迟交付时间、需要重新运行已完成的测试用例，更为严重的是，有可能引入新的问题,影响产品质量的稳定性。

(3) 提供文档，让终端用户手动安装QF，手动检查QF安装的日志文件，这无疑增加了用户安装的复杂度，增加了安装的时间，特别是在QF数目巨大的时候，这样将多耗费用户大量的时间，降低产品的质量形象。在文献[2]中，介绍了补丁分发管理系统来帮助用户选择和安装合适的补丁包。

因此，寻找快速的QF集成方法变得非常重要。有了快速的QF集成方法，即使在非常接近产品发布的时间点，仍然可以快速集成QF，从而既保证按期交付，又能提高产品软件质量。

1 QF快速集成机制

1.1 持续集成

众所周知，随着代码量的剧增，软件的复杂度随之增加，软件集成变得很困难。为了快速解决集成中的问题，保证每个软件模块能快速地被集成，持续集成的概念被提出并推广[3-6]。持续集成是一种敏捷开发的实践[7]。文献[8]讨论了持续集成中考虑测试用例合理执行顺序，以提高发现问题的效率，节省时间。文献[9]在持续集成中同时考虑到功能性测试和非功能性测试。文献[10]提到Travis CI系统的某些特性功能被误用。持续集成的主要目的是尽早地集成代码，文献[11]描述了特定领域的具体应用。尽早地、经常性地集成，能有效地提高软件质量，降低风险。这样能尽早发现问题，避免项目提交的失败和延迟[12-13]。另随着信息化应用水平日益提高，为用户提供及时、灵活的更新已是日益迫切的需求[4，13-14]。

通常而言，持续集成主要应用于开发阶段。主要包括以下关键点：

(1) 每日编译一次代码，这样能将最新的代码包括在软件包中。

(2) 增加自动测试，能快速验证基本功能和新代码。

(3) 在持续集成中，能尽早发现集成的问题。这样，软件工程师可以将主要精力专注于修复软件问题和开发新代码；而不需要将主要精力放在集成及发现集成中出现的问题。

1.2 基于QF模式的持续集成及测试

但是上述持续集成的思想用于交付之前的系统集成和验证阶段，仍不能满足所有需求。自动测试可以覆盖基本功能测试，但是对于一些组合的场景、复杂的场景，以电信领域的软件产品为例，针对特定运营商某些场景的软件更新和修改的测试，或者不适合自动测试场景的测试用例，仍然需要手动测试，如果全部模块重新编译，理论上说为了保证软件产品的质量，所有手动测试都需要重新验证。这在时间和人力成本上几乎不可接受。因此在实际中，通常会选择小部分有代表性的测试用例，重新运行。这样做的问题在于以个例代替整体，存在质量风险。因此本文提出一种基于QF模式的持续集成及测试机制。在开发通信产品的过程中，整个集成和测试阶段(甚至在非常靠近软件产品发布的时间点)，一旦发现软件问题，由相应模块提供QF,并被快速集成，然后部署在运行的机器上，以便未进行完的测试用例继续在此机器上运行，并验证此QF修复的问题。与开发阶段不同，不采用整个模块重新编译，避免重新安装部署，可以减少反复重新安装的时间，减少整个模块替换引入新软件问题的潜在风险。在这个过程中，我们需要权衡并尽量找到最优的平衡点：在保证产品总体质量的同时，尽可能多地集成QF。要做到这一点，需要尽量地让QF的停止提交时间靠近产品最后发布的时间，与此同时，要严格地保证产品质量。不能因为集成了某一个QF，导致产品质量的严重衰退。这样，才可以实现平稳迅速地集成更多的QF的目标(如图1和图2所示)，既能大力改善产品质量，又能避免延长测试时间，避免延期发布产品。

T1：产品开发阶段 T2：产品的系统集成及验证阶段

T3：Patch(QFs)集成及测试阶段 D1：产品交付时间点

D2：Patch交付时间点

对比以上图1和图2,我们可以清楚地看到，相比较传统的集成测试模式，基于QF模式的持续集成能减少T3时间段的Patch集成测试工作，提高在D1点交付的产品质量。

综上，基于QF模式的持续集成方式具有如下优点：

(1) 在发布产品之前，能尽快地集成所有已有的QF。这能够显著地提高产品质量。

(2) 所有子模块软件包不需重新编译交付，也不需要重新部署安装，节省大量集成与验证时间。

(3) 已经验证过的测试用例无须重新测试，这样能保证软件包质量没有衰退。在剩下的测试中主要关注未测试过的测试用例，以及QF所提供的软件修复。

2 QF自动选择算法

基于前文所述的基于QF的持续集成模式，我们进一步研究QF自动选择算法。

2.1 安装过程分析

大型软件的安装过程相对比较复杂，部署步骤多，而且与具体的硬件资源、软件模块等配置相关。我们按照产品的安装过程，将所有安装过程分为n个步骤，同时将所有QF分为n+1个集合(P0,P1,…,Pn-1)。如图3所示。

根据安装过程，将QF集合分为n个子集合。

All_QF={P0,P1,…,Pn-1}

其中:

P0={fx,fx+1,…,fx+l}

P1={fy,fy+1,…,fy+m}

⋮

Pn-1={fz,fz+1,…,fz+k}

式中：

(x,y,z,l,m,n,k)∈N

fi(i∈(x,x+1,…,x+l,y,y+1,…,y+m,z,z+1,…,z+k)

fi是来自不同的模块QF。为方便问题讨论，设每个fi的安装需要约4条命令完成(包括拷贝、检查cksum值、解压、安装等)。如图4所示。将QF按照集合All_QF={P0,P1,…,Pn-1}来安装，可以减少命令单独执行。所有QF的安装简化为n条命令。

在前面所述的n个固定的点，通过输入固定的n条命令，在P0，P1,…，Pn-1集合中所包含的所有QF将被自动安装好。这样多个QF的安装本来需要[(l+1)+(m+1)+…+(k+1)]×4条命令，缩减为n个固定的命令(n的大小取决于安装步骤数目大小)。显而易见，当n较小，而QF数目([(l+1)+(m+1)+…+(k+1)]×4)较大时，此方法的优势更为明显。这n条命令可以被集成到正常安装和升级的步骤中，如果某两个步骤之间，没有QF要被安装，则可以使Px为空。这样做的好处是接口统一。

2.2 算法步骤

算法目标：考虑到每个QF适用于不同的软件模块、安装的特定步骤、平台、服务器类型和操作系统类型等，在安装每个QF时，自动检测以上信息，自动选择并部署所需的QF，无须用户做出人工判断。

算法输入：

1) 全体QF集合：

{fx,fx+1,…，fx+l,fy,fy+1,…，fy+m,…,fz,fz+1,…，fz+k}，

其中:

(x,y,z,l,m,n,k)∈N

fi(i∈(x,x+1,…,x+l,y,y+1,…,y+m,z,z+1,…,z+k)

2) 每个QF都有一组属性标签：

fiAttribute=[software_module,apply_phase,

servertype,OStype,…]

算法输出：

All_QF={P0,P1,…,Pn-1}

其中:

P0={fx,fx+1,…,fx+l}

P1={fy,fy+1,…,fy+m}

⋮

Pn-1={fz,fz+1,…,fz+k}

算法描述：

1) 输入全体QF集合：{fx,fx+1,…,fx+l,fy,fy+1,…,fy+m,…,fz,fz+1,…,fz+k}。

2) 输入每个QF集合都有一组属性标签fiAttribute=[software_module,apply_phase,servertype,OStype]。

3) 获取目标平台的具体硬件资源、软件配置、服务器类型、操作系统类型等信息。

4) for each QF:

将属性标签与获取的信息相匹配。

如果匹配成功：

QF放入合适的子集合Pii∈{0,1,…,n-1}。

否则：

跳过该QF,并给出提示信息，此QF未能分入合适的子集合。

5) QF遍历完成，结束退出。

算法复杂度约为O(QF_number)，其中QF_number为QF的数目，因此算法复杂度接近于多项式。在现有的硬件资源条件下，运行速度很快。

另考虑到日志内容繁多，为减少人工检查安装日志的时间，支持自动检查安装日志，可以对每一个QF，进行特定关键字搜索，以确定所有QF安装成功，无报错信息。

综上，这种QF的自动安装机制及自动选择算法，具有以下优点：

(1) 所有的QF可以自动安装，不需要用户在安装时手动输入命令。

(2) 根据服务器配置类型、配置参数等具体信息，支持自动选择适用的QF，并自动地安装。

(3) QF安装的日志，能自动检查，发现安装失败的QF，无须人工检查。

(4) 合适的体系结构，让QF的集成简单方便，无须太多编码工作。

(5) 大大减少了QF的安装时间。

3 系统设计及测试结果分析

3.1 系统设计及实现

基于前文提出的QF快速集成机制及自动选择算法，我们设计实现了如图5所示系统结构。

(1) 软件模块1-n，是大型软件产品的软件模块,提供QF。

(2) QF快速集成模块：负责将QF集成。提供统一的文件来处理每个QF。设计统一的QF处理结构，以及针对每个QF的配置文件。这样能将集成新QF的工作量减到最少。每次集成无须新加代码，只需要将QF内容及相应的配置文件定义好，拷贝至指定目录下即可。

(3) QF库：用于存放所有的QF和每个QF的配置文件，配置文件用于程序根据具体的服务器配置等，自动选择需要安装使用的QF。每个QF按照如下模板提供QF的属性标签，作为自动选择算法模块的输入：

softwaremodule=; applyphase=; servertype=;OStype=;…

流程如图6所示。

(4) QF安装自动检测模块：对一个QF，可以自动检测安装是否成功，日志是否无错误和异常。

3.2 测试结果及分析

我们通过部署8个版本的软件包，收取相关的数据。我们分别收集了部署本文机制方法和没有部署的各项数据，进行比较和分析。为方便讨论，按照QF数目从小到大的顺序，对软件版本进行了重新排序。

1) 安装部署QF时间显著减少。为了客观计算减少的时间，忽略掉其他影响安装的时间，我们在收集数据时，仅计算用户或系统调用命令所耗费的时间。

如图7所示。我们可以看到，引入基于QF模式的集成机制及自动选择算法后，QF安装的时间减少了10～142分钟；而且QF数量越多，节省的时间就越多。当有多套系统需要部署和升级的时候，节省的时间成倍增长。

2) 检查安装日志的时间显著减少。我们收集了检查安装日志的时间并进行对比。以前用户需要一个一个检查QF安装日志，以便确定每个QF安装成功。引入日志自动检测机制后，可以由系统对安装日志进行自动检查，确保QF安装正确，用户只需要检查日志自动检查的总结日志。总结日志非常简单，只包括对每一个QF安装结果的说明，成功或失败。因此能减少大量手动检查日志的时间。如图8所示。

3) 产品质量提升。如图9所示，横坐标表示每个Load，纵坐标表示对应于每个Load集成的QF数目。显而易见，集成的QF数目越多，修复的软件问题越多，产品质量也更好。

4 结 语

本文提出一种基于QF的快速集成机制，并设计实现基于此机制的QF自动选择算法。实验及实践证明，可快速集成QF，具有不延迟产品发布时间、提高产品软件质量的优点；与此同时，能够节省用户的安装时间，减少人工检查安装日志的时间；适用于大型软件的交付集成及验证，推荐进一步推广使用。下一步，研究集成测试序列生成方法[15-16]在持续集成中的应用。