CN101212759B - 一种手机软件集成测试方法 - Google Patents

Abstract

本发明公开了一种手机软件集成测试方法，用于对基于BREW开发平台的手机软件进行测试，包括：步骤11，基于待测软件模块函数的度分析模块重要程度，判断该模块是核心模块或非核心模块；步骤12，在BREW仿真测试环境中，利用不同的测试单元对所述核心模块和非核心模块分别进行测试；步骤13，根据所述步骤12的测试结果验证所有待测软件模块是否符合集成测试的入口条件，对符合入口条件的，执行步骤14，对不符合条件的则有待进一步改进，循环执行步骤12；步骤14，进行模块间的集成测试。本发明的方法将目标机上才能运行的手机软件程序通过适当修改移植成能够在计算机上运行的手机仿真程序，避开了对手机这一嵌入式系统直接实施集成测试的难点。

Description

一种手机软件集成测试方法

技术领域

本发明属于移动通信领域，尤其涉及基于BREW(Binary RuntimeEnvironment for Wireless)开发平台的手机软件的半自动化集成测试方法。

背景技术

当前国内手机生产商既面临着稳定提升产品质量、树立手机品牌的问题，又面临快速开发新产品，尽量压缩研发周期并以最快的速度响应不同层次不同地域的各类用户的需求，以求占领市场的迫切需要。

目前行业主要还是采用系统测试，而且更多的采用手工测试的方法。手机软件系统不同于一般计算机软件，它是一种开发编译环境和运行环境分离的嵌入式系统。由于不是在计算机上运行，因此不能象测试计算机软件那样通过直接在计算机上运行被测程序的方式进行软件的集成测试工作。这也是嵌入式软件测试的一个常见问题，因此开发过程往往采取退而求其次的方式，将测试过程后移，主要实施的是以嵌入式系统输入输出设备的操作和观察为特征的系统测试。这样就必然造成错误或缺陷在软件中存在一个较长的时间，造成缺陷修复成本居高不下。更为重要的是系统测试有其固有的缺陷，它没有一个清晰的停止准则，而且带有一定的盲目性，并且具有测试修复总成本高、研发后期测试效率低的弊端。如果只做系统测试往往造成产品发布时还存留部分严重故障，只有等到用户发现时才能通过高昂得多的事后升级方式来补救。

当前，决策者和研发人员也越来越认识到将测试尽量前移的必要性和对研发的重大意义。那么单元测试和集成测试的问题就愈来愈受到大家的重视。其中单元测试本应是软件开发人员的职责，但是由于项目进度压力，开发人员往往压缩甚至省去单元测试过程，这已经是当前手机研发过程中一个不争事实。那么对测试过程进行改进的重担就更多地落在了集成测试人员身上，因为单元测试能够发现的问题也留在了集成测试阶段。

而手机软件的集成测试又一直是困扰手机软件研发的一个难题。这其中一个主要原因是：

目前已有的手机软件集成测试方法多存在依赖于手工测试。效率低下的缺点，很难满足当前手机研发要求高、周期短的要求。并且手工方法往往对集成测试人员要求较高，需要对软件代码相当熟悉。因此，业界许多手机生产商都迫切希望能够找到一种高效通用的手机软件集成测试方法，以求尽量早的发现缺陷，提高测试效率，降低测试成本，缩短产品研发周期。

发明内容

本发明所要解决的技术问题在于提供一种半自动化的手机软件集成测试方法，采用该方法，使得手机软件的测试不过分依赖于集成测试人员对软件代码的熟悉程度；还有助于较大程度提高集成测试工作的效率，满足当前手机软件研发质量要求高、开发周期短的特点。

为达到上述目的，本发明提供的手机软件集成测试方法，用于对基于BREW开发平台的手机软件进行测试，该方法包括：

步骤11，基于待测软件模块函数的度分析模块重要程度，判断该模块是核心模块或非核心模块；

步骤12，在BREW仿真测试环境中，利用不同的测试单元对所述核心模块和非核心模块分别进行测试；

步骤13，根据所述步骤12的测试结果验证所有待测软件模块是否符合集成测试的入口条件，对符合入口条件的，执行步骤14，对不符合条件的则有待进一步改进，循环执行步骤12；

步骤14，进行模块间的集成测试。

上述手机软件集成测试方法，所述步骤11进一步包括：

步骤101，设定模块函数的度，所述度为入度和出度的总和，其中，入度为调用该函数的其他函数的个数，出度为该函数调用其他函数的个数。

步骤102，借助代码分析工具判断所述模块函数节点的度数，以此确定一组核心模块；

步骤103，在所述核心模块中进一步确定最重要的模块。

上述手机软件集成测试方法，在所述步骤103中确定最重要模块的步骤，包括：判断所述核心模块的函数是否是新增函数，是否是计算或流程复杂函数或是否是有较多修改的函数；如果是，则确认是最重要的模块。

上述手机软件集成测试方法，所述步骤12中，还包括创建BREW仿真测试环境的步骤，具体包括：

步骤201，创建一个可以编译通过或可在BREW仿真器运行的基于BREW的测试代码工程；

步骤202，创建能在所述测试代码工程中进行测试的单元测试工具；

步骤203，配置BREW的编译环境。

上述手机软件集成测试方法，所述步骤12中对所述核心模块进行测试的步骤，进一步包括：

步骤301，建立所述核心模块的程序流程图；

步骤302，确定所述核心模块函数需要关注的被调用形式、参数和全局变量；

步骤303，依据所述确定的被调用的形式列举该核心模块的使用场景并对被调用的场景进行分类，再依据所述需要关注的被调用形式并分析所述参数和全局变量的取值形成测试用例的数据集；

步骤304，依据所述的数据集编写相应的测试用例对所述核心模块进行测试并输出测试结果。

上述手机软件集成测试方法，所述步骤201是通过首先安装VC++6.0和C++Test，再安装BREW SDK软件开发包来创建所述测试代码工程的。

上述手机软件集成测试方法，所述步骤202中，所述单元测试工具是C++Test和/或CUnit。

上述手机软件集成测试方法，所述核心模块是基于所述CUnit单元测试工具进行测试的。

上述手机软件集成测试方法，所述非核心模块是基于C++test单元测试工具进行测试的。

上述手机软件集成测试方法，所述步骤14模块间的集成测试是基于改进的调用图集成的C++Test进行集成测试。

上述手机软件集成测试方法，所述改进的调用图集成是优先集成度数较小的节点，再在该基础上集成度数较多的节点。

上述手机软件集成测试方法，所述基于改进的调用图集成的C++Test进行集成测试的步骤，进一步包括：

步骤401，划分基于改进调用图集成的集成过程；

步骤402，为各待测单元模块添加第一个会话和头文件，并作适应性修改，使所述待测单元模块的程序成为一个可在创建的可编译通过和在BREW仿真器中运行的程序；

步骤403，在所述C++Test中为当前测试过程涉及的单元模块创建一个测试单元；

步骤404，利用所述C++Test自动生成测试用例，并添加或修改所述测试用例；

步骤405，运行测试并生成测试报告；

步骤406，判断测试会话是否全部完成，未完成循环执行步骤402，直至完成所述全部测试会话。

上述手机软件集成测试方法，所述步骤401中划分集成过程是优先从所述度数中高度数的节点中选择出作为大的集成测试过程测试主线索，再按主线索节点的度数由低到高的顺序采用基于改进的调用图集成测试过程，所述的主线索的节点要保证覆盖所有节点。

与现有技术相比，本发明的手机软件集成测试方法能带来如下有益效果：

(1)本方法将目标机上才能运行的手机软件程序通过适当修改移植成能够在计算机上运行的手机仿真程序，从而避开了对手机这一嵌入式系统直接实施集成测试的难点，而且也可以借助当前比较成熟的计算机测试工具(如众多的单元测试工具)开展集成测试；

(2)针对当前手机软件开发很少进行严格单元测试的实际情况，通过引入模块度的概念并借助CUnit单元测试框架和C++Test单元测试工具实施了有重点的单元模块测试，保证了集成测试的入口条件；

(3)为方便缺陷定位采用了改进的调用图方法，同时也可根据被测软件的复杂程度调整集成测试的粒度，加快测试进程；

(4)借助C++Test中能够创建测试单元的优点，可以方便地为一个集成测试过程中涉及的模块创建一个测试单元，不用手工创建桩和驱动而很容易地搭建起了集成测试环境，方便了集成(接口)测试。

附图说明

图1是本集成测试方法实施步骤的流程图；

图2是创建BREW仿真测试环境的流程图；

图3是基于CUnit的核心模块测试的流程图；

图4是基于改进调用图集成的C++Test接口测试的流程图。

具体实施方式

在图1中揭示了本发明的一种半自动化的手机软件集成测试方法。该通用的基于BREW平台的手机软件集成测试方法的实施步骤具体描述如下：

步骤S11，基于待测软件模块的度分析模块的重要程度，确定该软件的核心模块和非核心模块；

步骤S12，在BREW仿真测试环境中，用不同的测试单元对所述核心模块和非核心模块分别进行测试，所述的不同测试单元包括CUnit和C++Test测试单元；

步骤S13，根据所述步骤S12的测试结果验证所有模块是否符合集成测试的入口条件，即是否所有模块都通过单元测试，通过测试即符合条件，执行步骤S14，否则对不符合条件的模块进行改进，循环执行步骤S12；

步骤S14，进行模块间的集成测试。

上述步骤S11中，基于待测软件模块的度分析模块的重要程度，确定该软件的核心模块和非核心模块；具体实施如下：

首先定义函数的度。定义函数的入度indeg(n)为调用函数n的其它函数的个数；函数的出度outdeg(n)为函数n调用的其它函数的个数；函数的度deg(n)为调用该函数和该函数调用的所有函数的总个数，即入度和出度的总和：deg(n)＝indeg(n)+outdeg(n)。

函数度的分析可以很容易借助代码分析查看工具(如SourceInsight)计算得到。某个函数节点的度数越高，则该函数模块的扇入扇出数越大，与其它模块的耦合程度也就越高，即与其它模块的交互关系越多，接口调用越频繁，而这些正是我们开展集成测试工作需要重点关注的目标。因此，可以根据函数节点的度数划分函数的重要程度，这里按如下方式定义了函数(模块)的重要级别：若度数为1或2，重要级别为1(不重要)；若度数为3或4，重要级别为2(一般)；若度数大于等于5，重要级别为3(重要)。可以根据实际代码的情况调整级别数或每个级别的度数区间，总体目标是要识别出一组范围合适、选择得当、符合实际的核心模块。

这里首先标记度数大于4的模块，作为候选重点模块。为了进一步对上述模块进行筛选，再根据如下三个规则中满足任一个，即被确定为最重要的模块，以此对所有函数进一步筛选确定需要用CUnit测试的最重要模块：

(1)是否是新增函数；

(2)是否是计算或流程复杂函数；

(3)是否有较多修改。

另外，由于形入XXDlgHandler或XXHandEvent的对话框或事件处理函数模块多半会成为候选重点模块，但是因为主要是Switch结构的业务流程分支，若不便于一开始做测试，也可以放在接口集成测试阶段做。因此结合上述两个过程可以确定一组需要CUnit重点测试的重点模块范围。

参考图2，上述步骤S12中，所述BREW仿真测试环境的创建步骤具体包括：

步骤S121：VC++6.0安装。VC++6.0主要用于创建一个可以编译通过或可在BREW仿真器运行的基于BREW的测试代码工程。使得C++Test能够对测试程序进行分析、创建测试桩、调用执行测试用例、和对失败测试用例的调试。任何一个模块在能够进行C++Test测试之前必须为之创建一个可编译通过或可运行的测试代码工程。

步骤S122：C++Test安装。C++Test是一个C/C++单元测试工具，自动测试任何C/C++类、函数或部件，而不需要编写一个测试用例、测试驱动程序或测试桩调用。C++Test能够自动测试代码构造(白盒测试)、测试代码的功能性(黑盒测试)和维护代码的完整性(回归测试)。这些都方便了测试工作的开展。

步骤S123：BREW SDK(软件开发包)安装。为了将手机上的代码移植到计算机上，需要创建一个能够在BREW仿真器上运行的基于BREW的测试代码工程，因此需要在安装VC++6.0后安装BREW SDK(2.0或3.0)。

步骤S124：BREW编译环境配置。程序会用到BREW平台的相关接口，代码会引用相关头文件，需要在VC++6.0的工具->选项菜单中添加这些公用的头文件目录和对应的源代码目录。另外，如果手机软件开发的BREW平台版本高于嵌入到VC++6.0开发编译环境中的BREW平台版本时，为了编译成高版本的BREW接口，还需要将VC++6.0的工程->设置->C++中BREW头文件目录的路径修改为更高BREW SDK版本的头文件目录的路径。

对于步骤S11确定的核心模块是基于所述CUnit单元测试工具进行测试的。

CUnit是一个在C语言中编写、管理和运行单元测试的系统。它作为一个静态库，可以链接到用户测试代码中。CUnit采用一种简单的框架创建测试结构，并提供一组丰富的断言集测试公共数据类型。另外，CUnit还提供了几个不同的接口来运行测试和报告结果，同时允许用户动态地运行测试和查看结果的交互接口。

选择CUnit测试核心模块的好处在于只需要编写较少的测试用例就能测试多种情况，这主要是由于CUnit中引入了断言的缘故。另外，CUnit除具有测试输入输出参数和全局变量的功能外，还能够通过对源代码做适当调整(如将局部变量调整成全局变量)后，测试单元内部任一局部变量。因此对于核心代码或算法可以采用CUnit开发详细的测试用例，在任一版本构建以后运行上述测试用例，保证该版本中的修改没有影响到软件的核心功能。

对所述核心模块的测试步骤参考图3所示，具体包括：

步骤S131：画出核心模块的程序流程图；

步骤S132：确定需要关注的调用形式、参数和全局变量；

步骤S133：依据所述确定的被调用的形式(如直接调用、回调函数、取消定时器或参数取值组合情况等)列举该核心模块的使用场景并对被调用的场景进行分类，再依据所述需要关注的被调用形式并分析所述参数和全局变量的取值形成测试用例的数据集；

步骤S134：依据所述的数据集通过CUnit编写相应的测试用例；

步骤S135：基于CUnit对所述核心模块进行测试并输出测试结果。

对于步骤11确定的非核心模块是基于C++test测试工具进行测试。C++Test的优点在于快速高效，避免手工开发测试驱动和测试用例导致耗费大量时间。C++Test基于内置的智能测试用例生成技术生成广谱测试用例，每个测试用例和每次测试运行都会提供各种覆盖率指标信息(如语句覆盖、分支覆盖、条件覆盖等)。因而可以设定相应的覆盖率指标通过C++Test完成非核心模块的测试。实践也证明覆盖率指标对于各种层次的测试都具有重要意义，覆盖率不仅可以揭示实现错误，还可以揭示设计错误。因此是一种可行和有效的模块测试方法。非核心单元模块的测试用例库通过在多个版本测试中不断积累形成。每次版本构建以后，运行上述非核心模块的测试用例，保证各非核心模块在选定的覆盖率指标下是正确的。

对非核心模块的测试采取如下步骤：首先建立基于BREW的测试代码工程；其次添加并修改被测单元模块及其头文件；然后基于C++Test的进行静态和动态测试并自动生成C++Test测试报告。

C++Test用于非核心模块的测试的好处在于能够极大地提高测试效率，不需要用户编写任何测试驱动、桩调用函数、测试用例，就能够达到满足要求的测试结果。

这样，通过基于CUnit的核心模块测试和基于C++Test的非核心模块的测试能够迅速验证完所有模块是否达到下一步接口测试的入口条件，为单元模块间的集成测试打下坚实基础，使得集成测试能够专注于模块间的接口测试，而不会过多考虑单元是否可靠，发现问题时也易于定位。

另外，下一步的接口测试也是基于C++Test进行，因此大多数步骤是相同的，对于相同的部分，下文中就不再赘述。

上述步骤S14进行模块间的集成(接口)测试是基于改进调用图集成的C++Test接口测试。

具体实施步骤如图4中所示。

下面首先介绍采用的集成策略。调用图是一种有向图，集成测试可以模仿单元测试中使用程序图的方式使用调用图，采用成对集成或相邻集成。成对集成是对调用图中的每条边生成一个集成测试对话(集成一次)，其思想是不必开发桩和驱动器，而使用实际代码，从而免除了桩/驱动器的开发工作。相邻集成是借助拓扑学中的相邻的概念。有向图中，节点邻居包括所有直接前驱节点和所有后继节点(这分别对应节点的驱动器和桩集合)。集成测试会话数等于有向图中所有的邻居数量。而邻居＝节点-汇节点，其中汇节点指出度为零的节点。因而集成测试会话数大大减少，并且避免了桩和驱动的开发。

基于调用图集成测试的最大缺点是缺陷隔离问题，尤其是对有大量邻居的情况。因此这里采用一种折中的改进的调用图集成策略。基本思想是先优先集成邻居数较小的节点，再在此基础上累加集成邻居数较多的节点。因为邻居数正好对应步骤S11模块重要程度分析中的度数，所以度数越高的节点越应该晚集成，以方便缺陷定位，度数越小的节点越早集成。具体步骤如下：

a)集成过程划分。优先从高度数节点中选择几个分别作为大的集成测试过程的主线索(可能会添加几个处于上层而度数又较小的节点)，并保证覆盖所有节点。如可以将对话框和事件处理函数作为主线进行集成过程划分，并且保证覆盖所有节点。

b)单一集成过程。按主线索的度数由低到高(大致顺序，同一层次可以并行)的顺序采用基于改进的调用图集成策略完成每一个大的集成测试过程，以加快集成速度。而且可以根据项目进度需要灵活选择集成测试的粒度，比如上述被选为集成主线对话框个数如果已经比较多，而且为了在时间紧迫条件下优先考虑测试的完整性，然后才考虑缺陷定位的难易程度时，可以对每一个主线下涉及的函数不再细分测试会话过程，而是采取一次性集成，从而依次完成一个中等规模的集成测试过程，以加快集成速度。故本测试策略也可视项目进度灵活应用，而且可以多人并行配合完成。也可以一人负责，实行逐步累加集成。

接口测试的步骤和非核心模块的测试步骤大致相同，不同之处在于：

(1)为了充分测试接口的交互，除C++Test自动生成的测试用例外还需要设计一些专门的用例，本方案中可以采用一种通过依次分析测试线索、测试需求和测试规格说明书的方法并参考业界提供的测试需求大纲(用于检测常见错误)的方法来设计测试用例。

(2)每个测试过程中包含不止一个单元模块，为了让父模块调用子模块时调用的是实际的代码，而不是桩调用模块，需要为每个测试过程创建一个测试单元，将待测模块涉及到的各模块添加到单元中再测试。

具体的测试过程如下：

步骤S141：基于改进调用图集成的集成过程划分；

步骤S142：添加第一个会话涉及的各单元模块及其头文件，并做适应性修改，使之成为一个可以编译通过和在BREW Simulator(仿真器)中运行的程序；

步骤S143：在C++Test中为该测试过程涉及的单元模块创建一个测试单元；

步骤S144：利用C++Test自动生成测试用例，并添加或修改C++Test生成的测试用例

步骤S145：运行测试并生成测试报告；

步骤S146：对其它测试会话重复步骤S142～步骤S145，直至完成所有测试会话。

该手机软件集成测试方法将目标机上运行的手机软件程序移植成计算机上运行的手机仿真程序，然后采用成熟的单元测试工具C++Test和CUnit单元测试框架开展集成测试。模块测试中引入模块度的概念并借助CUnit单元测试框架和C++Test单元测试工具实施了有重点的单元模块测试。保证了集成测试的入口条件。接口测试中为方便缺陷定位采用了改进的调用图方法，并利用了单元测试工具C++Test中能够创建测试单元的优点，不通过手工创建桩和驱动而很容易地搭建起了集成测试环境，水到渠成地完成了集成测试。

该方法首先不过分依赖于集成测试人员对软件代码的熟悉程度又较大程度提高集成测试工作的效率，顺应了当前手机软件研发质量要求高、开发周期短的特点。

虽然本发明已以上述实施例揭露如上，然其并非用以限定本发明，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (13)

1.一种手机软件集成测试方法，用于对基于BREW开发平台的手机软件进行测试，其特征在于，该方法包括：

步骤11，基于待测软件模块函数的度分析模块重要程度，判断该模块是核心模块或非核心模块；

步骤12，在BREW仿真测试环境中，利用不同的测试单元对所述核心模块和非核心模块分别进行测试；

步骤13，根据所述步骤12的测试结果验证所有待测软件模块是否符合集成测试的入口条件，对符合入口条件的，执行步骤14，对不符合条件的则有待进一步改进，循环执行步骤12；

步骤14，进行模块间的集成测试。

2.根据权利要求1所述的手机软件集成测试方法，其特征在于，所述步骤11进一步包括：

步骤101，设定模块函数的度，所述度为入度和出度的总和，其中，入度为调用该函数的其他函数的个数，出度为该函数调用其他函数的个数。

步骤102，借助代码分析工具判断所述模块函数节点的度数，以此确定一组核心模块；

步骤103，在所述核心模块中进一步确定最重要的模块。

3.根据权利要求2所述的手机软件集成测试方法，其特征在于，在所述步骤103中确定最重要模块的步骤，包括：判断所述核心模块的函数是否是新增函数，是否是计算或流程复杂函数或是否是有较多修改的函数；如果是，则确认是最重要的模块。

4.根据权利要求1、2或3所述的手机软件集成测试方法，其特征在于，所述步骤12中，还包括创建BREW仿真测试环境的步骤，具体包括：

步骤201，创建一个可以编译通过或可在BREW仿真器运行的基于BREW的测试代码工程；

步骤202，创建能在所述测试代码工程中进行测试的单元测试工具；

步骤203，配置BREW的编译环境。

5.根据权利要求1、2或3所述的手机软件集成测试方法，其特征在于，所述步骤12中对所述核心模块进行测试的步骤，进一步包括：

步骤301，建立所述核心模块的程序流程图；

步骤302，确定所述核心模块函数需要关注的被调用形式、参数和全局变量；

步骤303，依据所述确定的被调用的形式列举该核心模块的使用场景并对被调用的场景进行分类，再依据所述需要关注的被调用形式并分析所述参数和全局变量的取值形成测试用例的数据集；

步骤304，依据所述的数据集编写相应的测试用例对所述核心模块进行测试并输出测试结果。

6.根据权利要求4所述的手机软件集成测试方法，所述步骤201是通过首先安装VC++6.0和C++Test，再安装BREW SDK软件开发包来创建所述测试代码工程的。

7.根据权利要求4所述的手机软件集成测试方法，其特征在于，所述步骤202中，所述单元测试工具是C++Test和/或CUnit。

8.根据权利要求7所述的手机软件集成测试方法，其特征在于，所述核心模块是基于所述CUnit单元测试工具进行测试的。

9.根据权利要求7所述的手机软件集成测试方法，其特征在于，所述非核心模块是基于C++test单元测试工具进行测试的。

10.根据权利要求1所述的手机软件集成测试方法，其特征在于，所述步骤14模块间的集成测试是基于改进的调用图集成的C++Test进行集成测试，其中，所述改进的调用图集成是优先集成度数较小的节点，再在该基础上集成度数较多的节点。

11.根据权利要求10所述的手机软件集成测试方法，其特征在于，所述改进的调用图集成是优先集成度数较小的节点，再在该基础上集成度数较多的节点。

12.根据权利要求10所述的手机软件集成测试方法，其特征在于，所述基于改进的调用图集成的C++Test进行集成测试的步骤，进一步包括：

步骤401，划分基于改进调用图集成的集成过程；

步骤402，为各待测单元模块添加第一个会话和头文件，并作适应性修改，使所述待测单元模块的程序成为一个可在创建的可编译通过和在BREW仿真 器中运行的程序；

步骤403，在所述C++Test中为当前测试过程涉及的单元模块创建一个测试单元；

步骤404，利用所述C++Test自动生成测试用例，并添加或修改所述测试用例；

步骤405，运行测试并生成测试报告；

步骤406，判断测试会话是否全部完成，未完成循环执行步骤402，直至完成所述全部测试会话。

13.根据权利要求12所述的手机软件集成测试方法，其特征在于，所述步骤401中划分集成过程是优先从所述度数中高度数的节点中选择出作为大的集成测试过程测试主线索，再按主线索节点的度数由低到高的顺序采用基于改进的调用图集成测试过程，所述的主线索的节点要保证覆盖所有节点。 

Images