一种测试方法以及测试平台与流程

本申请涉及信息技术领域，尤其涉及一种应用于代码测试的测试方法以及测试平台。

背景技术

当前，随着移动互联网的迅速发展，越来越多的移动互联网产品的发布节奏不断变快并且对质量的要求也越来越高，那么如何量化评估产品的发布质量变得尤为重要；且随着代码插桩变得越来越容易，代码覆盖率被越来越多的测试团队引用作为重要的评估手段之一。

技术实现要素：

本申请的实例提出了一种测试方法。该测试方法包括：接收测试终端发送的第一覆盖率文件；其中，所述第一覆盖率文件包括被测试应用程序名称、版本号以及被执行覆盖的代码的行号；根据所接收的第一覆盖率文件的版本号以及自身存储的第二覆盖率文件的版本号将接收的第一覆盖率文件和自身存储的第二覆盖率文件进行数据整合，更新第二覆盖率文件；以及根据更新后的第二覆盖率文件生成覆盖率报告。

本申请的实例还提出了一种测试平台。该测试平台包括：

覆盖率文件收集服务器，用于接收测试终端发送的覆盖率文件；其中，所述覆盖率文件包括被测试应用程序名称、版本号以及被执行覆盖代码的行号；以及

覆盖率报告生成服务器，用于根据所接收的第一覆盖率文件的版本号以及自身存储的第二覆盖率文件的版本号将接收的第一覆盖率文件和自身存储的第二覆盖率文件进行数据整合，更新第二覆盖率文件；以及根据更新后的第二覆盖率文件生成覆盖率报告。

本申请的实例还提出了一种计算机可读存储介质，其上存储有计算机指令，其中，该计算机指令被处理器执行时实现上述方法的步骤。

通过上述测试方案和测试平台，测试人员可以随时下载测试包，随时进行测试，并可以随时将自身通过测试得到的覆盖率文件反馈给测试平台进行覆盖率数据整合，而且并不限制多个测试人员进行测试的测试包的版本必须相同。这样的测试流程更加贴合现阶段应用程序快速以及测试的需求，而且允许多人同时对同一应用程序的不同部分进行并行测试，实现快速测试。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实例的系统结构示意图；

图2为本申请一实例的测试方法的流程图；

图3为本申请一实例的将从测试终端接收的覆盖率文件和测试平台自身存储的覆盖率文件进行数据整合的方法流程图；

图4为本申请另一实例的测试方法的流程图；

图5为本申请又一实例的测试方法的流程图；

图6为本申请一实例的测试平台的结构示意图；

图7为本申请一实例的服务器的结构示意图。

具体实施方式

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

为了描述上的简洁和直观，下文通过描述若干代表性的实施例来对本发明的方案进行阐述。实施例中大量的细节仅用于帮助理解本发明的方案。但是很明显，本发明的技术方案实现时可以不局限于这些细节。为了避免不必要地模糊了本发明的方案，一些实施方式没有进行细致地描述，而是仅给出了框架。下文中，“包括”是指“包括但不限于”，“根据……”是指“至少根据……，但不限于仅根据……”。下文中没有特别指出一个成分的数量时，意味着该成分可以是一个也可以是多个，或可理解为至少一个。

本发明的发明人在研究的过程发现，现有的技术方案中最常见的是对应用程序的代码进行插桩然后生成单一的测试包，并对其进行测试，同时生成对应的覆盖率文件，但是这个方案目前只对测试团队非常小的规模(比如1人)会有效果。一旦测试团队人数达到2人或2人以上，上述方案将会缺乏应对能力；并且当测试人员需要更换测试包的时候，也无法实现及时测试，对实际生产的指导意义不强。

为了解决上述问题，本申请的实例提出了一种测试平台，该测试平台一方面能够解决多人并行测试的问题，且可以适应不断更新的持续集成测试包代码开发环境，并可以针对测试覆盖情况提示测试人员补增测试用例进行补充测试使其代码覆盖率数据达标。另一方面，该测试平台可以全方位贴合研发流程，适应速度更快和规模更大的应用程序的开发环境。

在本申请的一些实例中，上述测试平台可以对各个测试人员上传的在测试过程中生成覆盖率文件进行数据整合进而可以确定测试过程的代码覆盖率，例如差异化代码覆盖率，从而可以对应用软件的测试工作进行监控和管理。其中，差异化代码覆盖率对应于基于版本的增量开发模式，其具体含义是指对本次版本与上次版本的差异化代码进行测试后，得到此次测试被覆盖代码行数与差异化代码总行数的比值。通过差异化代码覆盖率可以了解到针对被测试应用程序的更新部分的代码测试情况。

图1显示了本申请一些实例所述的测试平台所应用的系统结构示意图。如图1所示，本申请的系统至少包括：研发管理服务器11、测试平台12、测试终端13、网络14以及代码管理工具(svn，子版本subversion的简称)服务器15。

在本申请的一些实例中，上述svn服务器15用于对应用程序的各个版本的代码文件进行管理。具体而言，svn服务器15可以接收并保存研发人员通过svn客户端上传的一条或者多条代码修改记录(svnlog)。其中，代码修改记录中可以包括一条或多条被修改代码的说明(具体可以为被修改代码实现的功能的说明和/或解决的需求的说明)以及具体的被修改的代码文件。此外，svn服务器15可以根据研发人员通过svn客户端上传的代码文件维护某个应用程序在不同版本下的完整代码文件。

在本申请的一些实例中，上述研发管理服务器11可以是持续集成服务器，可以从svn服务器15获取被测试应用程序某个版本的代码文件，并通过插桩操作生成以被测应用程序的名称和版本号为标识的待测试的测试包。在本申请的一些实例中，上述研发管理服务器11可以按照预先设定频率根据从svn服务器15获取的代码文件并生成测试包，比如，研发管理服务器11可以每天或每半天根据获取的代码文件生成测试包。

在本申请的一些实例中，上述测试终端13可以包括但不限于智能手机、pad、笔记本电脑以及个人电脑等智能终端设备。这些测试终端上都安装有操作系统，包括但不限于：android操作系统、symbian操作系统、windowsmobile操作系统、以及苹果iphoneos操作系统等等。测试终端13主要用于从研发管理服务器11获取测试包，安装并测试上述测试包，生成覆盖率文件，并将在测试过程中生成的覆盖率文件发送给测试平台12。其中，覆盖率文件可以包括被测试应用程序的名称、版本号以及被测试应用程序中被本次测试执行覆盖的代码的行号。在一些实例中，上述覆盖率文件还可以包括本次测试的代码段。

在本申请的一些实例中，上述测试平台12可以实现如下功能：将从测试人员接收的覆盖率报告进行数据整合，并根据数据整合结果生成代码覆盖率报告。在一些实例中，上述测试平台12可以包括：覆盖率文件收集服务器101以及覆盖率报告生成服务器102。其中，上述覆盖率文件收集服务器101可以接入外部网络，并仅可以由被授权的终端访问，主要用于从测试终端13收集不同测试人员的通过测试生成的覆盖率文件。覆盖率报告生成服务器102可以接入内部局域网，可以从覆盖率文件收集服务器101上获取覆盖率文件、进行数据整合，并根据数据整合结果生成覆盖率报告。在进行数据整合的过程中测试平台12可以随时从svn服务器15拉取被测应用程序某个版本的代码文件。

此外，上述测试平台12还可以实现测试任务分配的功能，此时，测试平台12进一步包括测试管理服务器103。该测试管理服务器103可以接入内部局域网，可以用于从svn服务器15中获取研发人员上传的代码修改记录(svnlog)，将上述代码修改记录作为测试任务发布出去。同时，测试平台12还将提供测试任务认领界面，供测试人员认领自己的测试任务，并且在测试人员认领测试任务后，针对代码修改记录其对应的测试人员。此外，测试管理服务器103还可以进一步为测试负责人提供测试任务分配界面，使测试负责人可以对没有被认领的代码修改记录进行二次分配。

需要说明的是，上述测试平台12包括的覆盖率文件收集服务器101、覆盖率报告生成服务器102以及测试管理服务器103可以物理上独立存在，也可以集成在一台服务器上完成，在此不做限定。

上述网络14可以包括有线网络和无线网络，用于实现研发管理服务器11、测试平台12以及测试终端13之间的链接和通信。如图1所示，在接入网一侧，测试终端11可以通过无线的方式或者有线的方式接入到网络14；而在核心网一侧，测试平台12和研发管理服务器11一般是通过有线方式连接到网络14的。当然，测试平台12和研发管理服务器11也可以通过无线方式连接到网络14。

基于上述图1所示的系统结构以及测试平台12的结构，本申请的实例提供了一种测试方法，可以确定测试过程的代码覆盖率。图2示出了本申请实例提供的测试方法的流程图。如图2所示，该方法可以由测试平台12执行，包括以下步骤：

步骤201：接收测试终端13发送的覆盖率文件。

在本申请的实例中，测试平台12将从一个或多个测试中的13分别接收一个或多个覆盖率文件。

其中，如前所述，所述覆盖率文件是测试终端13在测试某个代码修改记录后生成的。该覆盖率文件可以包括被测试的应用程序的名称和版本号，例如，以被测试的应用程序的名称和版本号为标识，其中还可以包括被测试应用程序中被本次测试执行覆盖的代码的行号。在本申请的一些实例中，上述覆盖率文件中还可以包括被测试的代码段。在本申请的实例中，可以将覆盖率文件中包含的被测试应用程序中被本次测试执行覆盖的代码的行号称为覆盖率数据。

通常情况下，研发人员为了满足被测应用程序用户新的需求或者为了修复被测应用程序缺陷，会修改该被测应用程序代码文件中的一行或者多行。并且，在代码修改完成后，上述研发人员会通过svn客户端向svn服务器15上传一条或者多条被修改的代码修改记录以及对应的代码文件。其中，每个代码修改记录包括上述一条或多条被修改代码的说明等内容。

测试人员在认领或者被分配代码修改记录后将对认领或者分配的代码修改记录进行测试，并在测试完成后根据测试结果生成覆盖率文件，以标识此次测试的应用程序的名称、版本和此次测试执行覆盖的代码的行号等信息。如前所述，通常覆盖率文件可以以被测试的应用程序的名称和版本号为标识，文件中还可以包括被测试应用程序中被本次测试执行覆盖的代码的行号，甚至还可以包括被测试的代码段。

在一些实例中，关于代码修改记录向测试人员的分配也可以由测试平台12实现，也即测试平台12将从svn服务器15接收待测试的代码修改记录，并发布给一个或多个测试人员。为了实现测试任务的分配，测试平台12可以提供测试任务认领界面，供测试人员认领进行测试的代码修改记录。具体的，测试平台12可以从研发管理服务器11上的代码管理工具中获取代码修改记录，生成代码修改记录列表；接收测试人员输入的关键字，并根据所述关键字以及代码修改记录的说明从代码修改记录列表中搜索并显示与所述关键字相关的代码修改记录；以及响应于所述测试人员的认领操作，在所述代码修改记录上添加所述测试人员的身份标识。通过为代码修改记录添加测试人员身份标识的操作表示所述代码修改记录被所述测试人员认领，将由该测试人员在其测试终端上对所述代码修改记录进行测试。

比如，某测试人员负责“播放”模块的测试，他可以在测试平台提供的web页面上搜索关键字“播放”，测试平台12接收到“播放”关键字后，会根据所获取的代码修改记录的说明在代码修改记录列表中搜索与“播放”相关的代码修改记录，并显示出来。上述测试人员可以点击认领以认领显示出来的与“播放”相关的代码修改记录，测试平台12响应于上述认领操作，在被认领的代码修改记录上添加上述测试人员的身份标识，标识所述代码修改记录被上述测试人员认领。

更进一步的，由于一些代码修改记录解决的需求可以分配给不同的测试人员，会造成一些代码修改记录的漏选，也即没有测试人员认领，也就需要测试负责人的二次分配。针对这一问题，测试平台12还可以进一步为测试负责人提供测试任务分配界面，供测试负责人进行测试任务分配。具体地，测试平台12响应于测试负责人的查询操作，筛选出来并显示没有添加测试人员身份标识的代码修改记录；响应于所述测试负责人在某个代码修改记录上添加的测试人员的身份标识的操作，在相应的代码修改记录上添加测试负责人添加的测试人员的身份标识，以完成所有的代码修改记录的分配。当然，测试负责人还可以通过该测试任务分配界面查看所有测试任务的分配情况，而且测试平台12也应当允许测试负责人更改某个代码修改记录的测试人员，从而实现测试任务的宏观调配和管理。

步骤202：根据所接收的覆盖率文件的版本号以及自身存储的覆盖率文件的版本号将接收的覆盖率文件和自身存储的覆盖率文件进行数据整合，更新自身存储的覆盖率文件。

在本申请的一些实例中，为了整合针对不同版本测试包测试生成的覆盖率文件，测试平台将存储有与最新版本代码文件对应的覆盖率文件，例如，该覆盖率文件可以以被测应用程序的名称和版本号为标识，并包括例如该版本代码文件的代码中已被执行覆盖的代码的行号等等。此外，测试平台12还可以存储与上述覆盖率文件的版本号对应的代码文件。根据该覆盖率文件，测试平台12可以将自身存储的代码文件的代码进行分类，具体可分为：可以被执行覆盖的代码、不可以被执行覆盖的代码、以及已被执行覆盖的代码。上述覆盖率文件可以是测试平台12在数据整合过程中生成并保存下来的。例如，如果是在新应用程序第一个版本的测试之前，则测试平台12所保存的覆盖率文件可能为空，并可以在后续对该应用程序的覆盖率文件进行数据整合的过程中不断更新自身保存的覆盖率文件，使之对应该新应用程序的第一个版本。又例如，在进行差异化代码测试之前，测试平台12所保存的覆盖率文件可以是对应上一版本的覆盖率文件，并可以在后续对新版本的覆盖率文件进行数据整合的过程中不断更新自身保存的覆盖率文件，使之对应当前的版本。需要说明的是，测试平台12也可以不存储与自身存储覆盖率文件的版本号对应的代码文件，而在需要时，根据自身存储覆盖率文件的版本号实时从svn服务器15获取对应的代码文件。

在一些实例中，测试平台12的覆盖率文件收集服务器101将从一个或者多个测试终端13收集一个或多个覆盖率文件并缓存，然后等待覆盖率生成服务器102来拉取上述一个或多个覆盖率文件。需要说明的是，在本申请的实例中，由于是多个测试人员并行进行测试，而且由于各个测试人员从研发管理服务器11下载的测试包的时间可能不同，因此，各个测试人员所下载的测试包的版本也可能不同。也就是说，覆盖率文件收集服务器101从各个测试终端13收集的覆盖率文件所对应的测试包的版本可能相同也可能不同。因此，测试平台12在对覆盖率文件以及自身保存的覆盖率文件进行数据整合时首先需要考虑版本的问题。具体而言，测试平台12首先要根据覆盖率文件的版本进行数据映射，将接收到的覆盖率文件或自身保存的覆盖率文件中的覆盖率数据映射为这些版本中相对最新版本的代码的覆盖率数据。这种数据映射的过程可以称作数据清洗。这个数据清洗的工作可以由覆盖率生成服务器102来完成。

具体而言，在本申请的一些实例中，覆盖率生成服务器102可以每次从覆盖率文件收集服务器101上拉取一个覆盖率文件，称为第一覆盖率文件，并将所述第一覆盖率文件的版本号与自身保存的第二覆盖率文件的版本号进行比较，如果相同，则将第一覆盖率文件和第二覆盖率文件进行合并，并将合并后的覆盖率文件作为第二覆盖率文件保存；如果第一覆盖率文件的版本号小于第二覆盖率文件的版本号，则将第一覆盖率文件中的覆盖率数据映射至第二覆盖率文件的版本，再将第一覆盖率文件和第二覆盖率文件进行合并，并将合并后的覆盖率文件作为第二覆盖率文件保存；如果第一覆盖率文件的版本号大于第二覆盖率文件的版本号，则将第二覆盖率文件中的覆盖率数据映射至第一覆盖率文件的版本，再将第一覆盖率文件和第二覆盖率文件进行合并，并将合并后的覆盖率文件作为第二覆盖率文件保存。覆盖率生成服务器102可以循环执行上述过程，直至覆盖率文件收集服务器101收集的所有覆盖率文件都与自身的覆盖率文件进行了整合。此后，覆盖率生成服务器102可以根据整合后的覆盖率数据生成覆盖率报告。上述整个数据整合过程也可以循环执行，从而周期性地生成覆盖率报告，其执行的频率可以根据需求任意设定，比如每隔5分钟整合一次等等。

下面将结合具体的示例以及附图详细说明上述数据整合过程。图3显示了本申请一个实例所述的将从测试终端13接收的覆盖率文件和测试平台12自身存储的覆盖率文件进行数据整合的方法流程图。需要说明的是，在本例中，测试平台12会对从测试终端13接收的一个或多个覆盖率文件逐一地和自身存储的覆盖率文件进行数据整合。为了描述方便，将从测试终端13接收的覆盖率文件称为第一覆盖率文件；将自身存储的覆盖率文件称为第二覆盖率文件。此外，在本例中，为了描述简单，还将覆盖率文件对应的代码文件的版本号简称为覆盖率文件的版本号。而且，在本例中，假设测试平台12存储有第二覆盖率文件版本号对应的代码文件。如图3所示，该方法可以包括如下步骤：

步骤301：将第一覆盖率文件的版本号与第二覆盖率文件的版本号进行比较，如果所述第一覆盖率文件的版本号大于第二覆盖率文件的版本号，则执行步骤302；如果所述第一覆盖率文件的版本号小于第二覆盖率文件的版本号，则执行步骤303；如果所述第一覆盖率文件的版本号等于第二覆盖率文件的版本号，则执行步骤304。

步骤302：根据第一覆盖率文件对应的代码文件以及第二覆盖率文件对应对应的代码文件，将第二覆盖率文件中记录的已执行覆盖的代码的行号更新为第一覆盖率文件对应的代码文件中对应代码的行号，然后执行步骤304。

在一些实例中，当第一覆盖率文件的版本号大于第二覆盖率文件的版本号时，说明测试平台12自身存储的代码文件并不是最新版本的，因此，需要进行代码文件的更新，因此，在这种情况下，测试平台12可以根据第一覆盖率文件的版本号，从svn服务器15获取与第一覆盖率文件的版本号对应的代码文件。

在本申请的一些实例中，测试平台12将根据第二覆盖率文件中记录的已执行覆盖的代码的功能在获取的代码文件中找到对应功能的代码段，建立新、旧版本的代码文件中对应代码段的映射关系。接下来，测试平台12根据新、旧版本的代码文件中对应代码段的映射关系建立新、旧版本的代码文件中对应代码段的行号之间的映射关系。从而，根据上述建立的行号之间的映射关系，测试平台12可以将第二覆盖率文件中记录的已执行覆盖的代码的行号更新为所获取的代码文件中对应代码的行号。经过上述替换操作，第二覆盖率文件中的覆盖率数据将对应第一覆盖率文件的版本，也即第一覆盖率文件和更新后的第二覆盖率文件均将对应二者中较新的版本。

例如，在所述第一覆盖率文件的版本号大于所述第二覆盖率文件的版本号的情况下，也即第一覆盖率文件的版本高于第二覆盖率文件的版本的情况下，在所述第一覆盖率文件中记录的已执行覆盖的实现“播放”功能的代码的行号为10、11、12，而所述第二覆盖率文件中记录的已执行覆盖的实现“播放”功能的代码的行数为21、22、23，则通过上述步骤302和步骤303测试平台12可以将建立第一覆盖率文件对应的代码文件中实现“播放”功能的代码段与自身记录的代码文件中实现“播放”功能的代码段的映射关系，从而建立两个代码文件包行号10、11、12和21、22、23之间的映射关系。建立上述映射关系之后，测试平台12即可将所述第二覆盖率文件中记录的已执行覆盖的代码的行号21、22、23替换为10、11、12。

通过上述过程，测试平台12可以实现将第二覆盖率文件中的覆盖率数据映射至第一覆盖率文件的版本。

步骤303:根据第二覆盖率文件对应的代码文件以及第一覆盖率文件对应的代码文件，将第一覆盖率文件中记录的已执行覆盖的代码的行号更新为第二覆盖率文件所对应代码文件中对应代码的行号，然后执行步骤304。

上述替换操作的具体过程可以参考步骤303的描述。也即测试平台12将根据第一覆盖率文件中记录的已执行覆盖的代码的功能在自身存储的代码文件中找到对应功能的代码段，建立新、旧版本的代码文件中对应代码段的映射关系。接下来，测试平台12再根据新、旧版本的代码文件中对应代码段的映射关系建立新、旧版本的代码文件中对应代码段的行号之间的映射关系。从而，根据上述建立的行号之间的映射关系，测试平台12可以将第一覆盖率文件中记录的已执行覆盖的代码的行号更新为自身存储的代码文件中对应代码的行号。经过上述替换操作，第一覆盖率文件中的覆盖率数据将对应第二覆盖率文件的版本，也即第一覆盖率文件和第二覆盖率文件均将对应二者中较新的版本。

例如，在所述第一覆盖率文件的版本号小于所述第二覆盖率文件的版本号的情况下，也即第一覆盖率文件的版本低于第二覆盖率文件的版本的情况下，在所述第一覆盖率文件中记录的已执行覆盖的实现“播放”功能的代码的行数为10、11、12，而自身保存的代码文件中实现“播放”功能的代码的行数为21、22、23，则通过上述步骤304建立第一覆盖率文件对应的代码文件中实现“播放”功能的代码的行数10、11和12与自身存储的代码文件中实现“播放”功能的代码的行数21、22和23的对应关系，从而将所述第一覆盖率文件中记录的已执行覆盖的代码的行号10、11、12替换为21、22、23。

通过上述过程，测试平台12可以实现将第一覆盖率文件中的覆盖率数据映射至第二覆盖率文件的版本。

步骤304：将第一覆盖率文件中的已执行覆盖的代码的行号与第二覆盖率文件中已执行覆盖的代码的行号进行合并，得到合并后的已执行覆盖的代码行号集合。

在本申请的一些实例中，上述合并可以具体为求并集操作，也即将第一覆盖率文件中的已执行覆盖的代码的行号与第二覆盖率文件中已执行覆盖的代码的行号求并集。例如，第一覆盖率文件中的已执行覆盖的代码的行号为10、11和12；第二覆盖率文件中已执行覆盖的代码的行号为21、22和23，则合并后得到的已执行覆盖的代码的行号为10、11、12、21、22和23。

步骤305：用合并后的已执行覆盖的代码行号集合替换第二覆盖率文件中记录的已执行覆盖的代码的行号，以更新第二覆盖率文件。

通过上述步骤的操作，测试平台12可以将拉取的第一覆盖率文件的覆盖率数据整合到第二覆盖率文件中，一方面使得测试平台12存储的覆盖率文件的版本是二者中最新的，另一方面使得测试平台12存储的覆盖率文件中包含了第一覆盖率文件中的覆盖率数据。

进一步，通过重复执行上述步骤，测试平台12可以将测试平台12从测试终端13接收的所有覆盖率文件一一整合至自身存储的覆盖率文件之内，而且可以保证测试平台12上存储的覆盖率文件对应最新版本的代码文件。接下来，测试平台12即可根据上述覆盖率文件获得对应最新版本的覆盖率报告。

需要说明的是，图3的方法同样适用于测试平台12不存储有第二覆盖率文件版本号对应的代码文件的情况，也即在图3所示的方法中如果需要使用第二覆盖率文件的版本号对应的代码文件，则可以根据版本号直接从svn服务器15上获取对应的代码文件。而且，图3的方法也不限制第一覆盖率文件中是否包含被测的代码。在实际应用中，如果第一覆盖率文件中包含被测的代码，则可以直接根据该代码进行后续的数据清洗过程；而如果第一覆盖率文件中不包含被测的代码，则测试平台12可以随时根据第一覆盖率文件的版本号从svn服务器15获取该版本的代码文件从而进行后续的数据清洗过程。

下面将返回图2继续描述图2所述的测试方法。

步骤203：根据自身存储的覆盖率文件生成覆盖率报告。

如前所述，覆盖率文件中包含已执行覆盖的代码的行号，因此，可以根据该行号的数量得到覆盖率报告。该覆盖率报告可以包含每个代码修改记录的代码覆盖率、差异化代码覆盖率、某个功能模块的代码覆盖率和/或整个被测应用软件的整体代码覆盖率等等。这些代码覆盖率可以表明在对代码的不同划分粒度下，代码测试的覆盖情况，比如，代码修改记录的代码覆盖率代表一个代码修改记录在测试中被执行覆盖的情况；功能模块的代码覆盖率代表某个功能模块在测试中被执行覆盖的情况；差异化代码覆盖率代表当前版本和上一版本的代码相比之后代码中差异化的部分在测试中被执行覆盖的情况；而整体代码覆盖率是指整个被测应用程序代码在测试中的执行覆盖情况。这些覆盖率从不同层面反映了同一版本代码的测试覆盖情况。

在一些实例中，上述代码修改记录的代码覆盖率可以为代码修改记录对应的代码段中已被执行覆盖的代码的行数与该代码修改记录所对应代码段的总行数的商。上述差异化代码覆盖率为被测应用程序的两个不同版本差异代码中被执行覆盖的代码的行数与总的差异代码行数的商。上述功能模块的代码覆盖率为被测应用程序的某个功能模块对应的代码段中被执行覆盖的代码的行数与该功能模块对应的代码段的总行数的商。上述整体代码覆盖率数据为被测应用程序中被执行覆盖的代码的行数与被测应用程序的总行数的商。根据通过上述数据整合过程得到的覆盖率文件可以确定上述几种代码覆盖率，从而得到代码覆盖率报告。

在本申请的一些实例中，为了进行应用程序的整体测试，使得测试结果达标，还可以进一步根据上述代码覆盖率报告来调整测试任务。具体而言，测试平台12可以预先设置代码修改记录代码覆盖率合格阈值、模块代码覆盖率合格阈值、差异化代码覆盖率合格阈值和/或整体代码覆盖率合格阈值。上述阈值的大小可以根据实际情况或者经验设置，并且可以根据测试需要进行动态调整，比如都设置为70％等。如此，在测试平台12生成代码覆盖率报告之后，将所述报告中的各个代码覆盖率和其对应的覆盖率合格阈值进行比较，如果大于或等于其对应的覆盖率合格阈值，则说明测试通过。而如果小于其对应的覆盖率合格阈值，则说明测试不通过。此时，需要提示相关测试人员，以使其补增覆盖率测试用例重新进行测试。在一些实例中，上述相关的测试人员可以根据在测试任务认领和/或测试任务分配过程中为代码修改记录添加的测试人员的身份标识来确定。例如，如果通过上述比较过程发现某些代码修改记录的代码覆盖率小于代码修改记录的覆盖率合格率阈值，则说明这些代码修改记录的测试工作不达标，需要通知这些代码修改记录对应的测试人员进行重新测试或者补充测试。而如果通过上述比较过程发现某些功能模块的代码覆盖率小于功能模块的覆盖率合格率阈值，则说明这些功能模块的测试工作不合格，需要通知这些功能模块对应的测试人员功能模块测试不达标，并可以根据各个代码修改记录的代码覆盖率，向测试人员显示低覆盖率的代码修改记录，并提示测试人员需针对所述低覆盖率的代码修改记录补增测试用例并执行测试以重新生成覆盖率直至整体测试达标。类似的，如果差异化代码覆盖率小于差异化代码覆盖率合格阈值或整体代码覆盖率小于整体代码覆盖率合格阈值，则提示所有测试人员测试不达标，并可以根据各个代码修改记录的代码覆盖率，向测试人员显示低覆盖率的代码修改记录，并提示测试人员需针对所述低覆盖率的代码修改记录补增测试用例并执行测试以重新生成覆盖率直至整体测试达标。需要说明的是，以上依据代码修改记录的代码覆盖率、差异化代码覆盖率、整体覆盖率以及功能模块代码覆盖率的测试检查方法，在整个测试过程中，可以交替迭代的检查，也可以根据不同的测试人员的习惯以及侧重点不同可以侧重检查，最终实现各种代码覆盖率同时达标，也即都大于其对应的覆盖率阈值的时候，才能认为整体测试通过。而且，上述低覆盖率的代码修改记录可以是一个相对的概念也可以是一个绝对的概念。例如，测试平台12可以对各个代码修改记录的覆盖率进行排序，得到覆盖率最低的n个代码修改记录，并提示这些代码修改记录对应的测试人员。此时，低覆盖率就是一个相对的概念。又例如，测试平台12可以将各个代码修改记录的覆盖率与一个预先确定的阈值(可以与之前设定的代码修改记录的合格阈值相同或者不同)进行比较，得到低于该阈值的m个代码修改记录，并提示这些代码修改记录对应的测试人员。此时，低覆盖率就是一个绝对的概念。

图4示出了本申请实例提供的一种测试方法的流程图。如图4所示，该方法可以由测试终端13执行，包括以下步骤：

步骤401：从研发管理服务器11获取待测试的测试包。

在一些实例中，研发管理服务器11通过其上的代码管理工具获取研发人员上传的代码文件，并生成以被测应用程序名称和版本号为标识的待测试的测试包。因此，在本例中，测试终端13可以将从研发管理服务器11下载待测试的测试包并安装到自身的系统中，以使测试人员进行后续的测试。

步骤402：响应于测试人员的测试操作，将所述测试操作映射到上述测试包具体的代码上，也即覆盖到具体的代码上，并生成覆盖率文件。

在一些实例中，上述测试人员可以根据预先设计的测试用例，在所述测试终端13上进行测试操作，测试终端13会通过插桩代码将上述测试操作映射到具体的代码上，也即将上述测试操作覆盖到具体的代码上，同时根据测试操作覆盖的具体代码生成覆盖率文件，记录在测试中被执行覆盖的代码的行号。

例如，某位测试人员负责“首页”模块，该测试人员会根据预先设计好的测试用例，在测试终端上显示的“首页”页面上进行相应的测试操作，比如点击“首页”的登录按钮等等，响应于上述点击登录按钮操作，测试终端13可以执行相关点击登录的代码以进行测试其是否存在缺陷，同时通过插桩代码可以将用户点击登录按钮的操作映射到被测试代码中与点击登录相关联的代码段，确定在上述操作中被执行覆盖的代码的行号，并记录在生成的覆盖率文件中。

步骤403：将所述覆盖率文件发送给测试平台12。

在测试人员完成针对某个代码修改记录或者是某项功能的测试后，测试终端13会将在测试过程中生成的覆盖率文件提交给测试平台12。

通过上述方法，测试终端13可以随时从研发管理服务器11下载测试包，随时进行测试，并将自身通过测试得到的覆盖率文件随时反馈给测试平台12进行覆盖率数据整合，而且不限制多个并行测试人员所测试的测试包的版本必须相同。这样的测试流程更加贴合现阶段应用程序快速开发以及快速测试的需求，而且允许多人同时对同一应用程序的不同部分进行并行测试，实现快速测试。

更进一步，由于测试平台12还为测试人员提供了测试任务认领界面，测试终端13还可以进一步响应于测试人员的测试任务查询操作向测试人员显示满足测试人员查询条件的(例如，通过关键字查询)待测试的代码修改记录，供测试人员认领；以及响应于测试人员的认领操作将代码修改记录的标识以及测试人员的身份标识反馈给测试平台，由测试平台记录代码修改记录的测试人员。

通过上面这种测试任务的创建以及分配过程，可以方便对代码测试的任务进行管理，提高测试效率，使之更加贴合现阶段应用程序快速开发以及快速测试的需求。

下面将进一步结合附图和一个具体的示例对测试平台的操作过程进行详细说明。图5显示了代码测试过程的一个示例。如图5所示，该代码测试过程主要包括以下步骤：

步骤501：测试平台12从研发管理服务器11获取代码修改记录，生成代码修改记录列表。

步骤502：接收测试人员在测试任务认领界面输入的包含关键字的测试任务查询请求，并根据所述关键字搜索代码修改记录列表，并显示与所述关键字相关的代码修改记录。

步骤503：响应于所述测试人员的认领操作，在所述代码修改记录上添加所述测试人员的身份标识，以表示所述代码修改记录被所述测试人员认领。

步骤504：响应于测试负责人在测试任务分配界面上输入的测试任务查询操作，显示没有添加测试人员身份标识的代码修改记录。

步骤505：响应于所述测试负责人在代码修改记录添加的测试人员的身份标识的操作，在所述代码修改记录上添加所述测试人员的身份标识，以完成所有的代码修改记录的分配。

步骤506：接收一个或多个测试终端13在测试完所述代码修改记录后发送的一个或多个第一覆盖率文件。

步骤507：分别将所述一个或多个第一覆盖率文件的版本号与测试平台12自身保存的第二覆盖率文件的版本号比较，如果所述第一覆盖率文件的版本号大于所述第二覆盖率文件的版本号，则执行步骤508；如果所述第一覆盖率文件的版本号小于所述第二覆盖率文件的版本号，则执行步骤509；如果所述第一覆盖率文件的版本号等于所述第二覆盖率文件的版本号，则执行步骤510。

步骤508：从svn服务器15获取与第一覆盖率文件的版本号对应的代码文件，根据获取的代码文件以及自身保存的第二覆盖率文件对应的代码文件，将第二覆盖率文件中记录的已执行覆盖的代码的行号更新为所获取的代码文件中对应代码的行号，然后执行步骤510。

步骤509:根据自身存储的代码文件以及第一覆盖率文件中的已执行覆盖的代码的行号所对应的代码，将第一覆盖率文件中记录的已执行覆盖的代码的行号更新为自身存储的第二覆盖率文件所对应代码文件中对应代码的行号，然后执行步骤510。

步骤510：将第一覆盖率文件中的已执行覆盖的代码的行号与第二覆盖率文件中已执行覆盖的代码的行号进行合并，得到合并后的已执行覆盖的代码行号集合，并用合并后的已执行覆盖的代码行号集合替换第二覆盖率文件中记录的已执行覆盖的代码的行号。

步骤511：根据所述第二覆盖率文件生成覆盖率报告。

该覆盖率报告中可以包括各个代码修改记录的代码覆盖率、各个功能模块的代码覆盖率、差异化代码覆盖率以及整体代码覆盖率之一或其组合。

步骤512：根据预先设置的代码修改记录的代码覆盖率合格阈值，将所述覆盖率报告中的代码修改记录的代码覆盖率和所述代码修改记录的代码覆盖率合格阈值进行比较，如果所述代码修改记录的代码覆盖率大于或等于所述代码修改记录的代码覆盖率合格阈值，则将对应的代码修改记录标注为测试通过；如果所述代码修改记录的代码覆盖率小于所述代码修改记录的代码覆盖率合格阈值，则执行步骤513。

步骤513：提示该代码修改记录的测试人员所述代码修改记录的覆盖率不合格，以使其补增覆盖率测试用例。

步骤514：根据预先设置的功能模块/差异化/整体代码覆盖率合格阈值；将所述覆盖率报告中的功能模块/差异化/整体代码覆盖率和所述功能模块/差异化/整体代码覆盖率合格阈值进行比较，如果功能模块/差异化/整体代码覆盖率大于或等于所述整体代码覆盖率合格阈值，则提示测试人员整体测试达标；如果功能模块/差异化/整体代码覆盖率小于所述整体代码覆盖率合格阈值，则执行步骤515。

步骤515：提示测试人员功能模块/差异化/整体测试不达标，并且为所述测试人员列出低覆盖率的代码修改记录，提示所述低覆盖率的代码修改记录对应的测试人员补增测试用例并测试以重新生成覆盖率，直至功能模块/差异化/整体测试达标。

在本申请的一些实例中，测试平台12可以按照每个代码修改记录对应的代码覆盖率来进行排序，为测试人员列出代码覆盖率最低的前n个代码修改记录，提示这些代码修改记录的测试人员进行补充测试。亦或者，测试平台12显示代码覆盖率小于预先设定的代码修改记录的代码覆盖率合格阈值的m个代码修改记录，提示这些代码修改记录的相关测试人员进行补充测试。

对应以上测试方法，本申请还提供了实现上述方法的测试平台600。

在本申请的一些实例中，上述实现测试平台600可由图6所示的结构图实现，包括覆盖率文件收集服务器601和覆盖率报告生成服务器602，其中，各服务器的功能如下：

覆盖率文件收集服务器601，用于接收测试终端13发送的第一覆盖率文件；

覆盖率报告生成服务器602，用于根据所接收的第一覆盖率文件的版本号以及自身存储的第二覆盖率文件的版本号将第一覆盖率文件和自身存储的第二覆盖率文件进行数据整合，更新第二覆盖率文件，并根据第二覆盖率文件生成覆盖率报告。

在一些实例中，上述测试平台600还可以实现测试任务分配的功能，此时测试平台600还可以进一步包括测试管理服务器603，用于将从研发管理服务器11待测试的代码修改记录，并发布给一个或多个测试人员。

在一些实例中，上述测试管理服务器603还将提供测试任务认领界面，供测试人员认领需要进行测试的代码修改记录。具体地，测试管理服务器603从研发管理服务器11获取代码修改记录，生成代码修改记录列表；接收测试人员在测试任务认领界面输入的包含关键字的测试任务查询请求，并根据所述关键字搜索代码修改记录列表，并显示与所述关键字相关的代码修改记录；以及响应于所述测试人员的认领操作，在所述代码修改记录上添加所述测试人员的身份标识，以表示所述代码修改记录被所述测试人员认领。

在一些实例中，上述测试管理服务器603，进一步为测试负责人提供测试任务分配界面，供测试负责人进行测试任务分配。具体地，测试平台12响应于测试负责人的查询操作，筛选出来并显示没有添加测试人员身份标识的代码修改记录；响应于所述测试负责人在某个代码修改记录上添加的测试人员的身份标识的操作，在以完成所有的代码修改记录的分配。

在一些实例中，覆盖率报告生成服务器602可以包括数据清洗模块以及数据合并模块；其中，所述数据清洗模块用于从所述覆盖率文件收集服务器上拉取一个第一覆盖率文件，并将所述第一覆盖率文件的版本号与自身保存的第二覆盖率文件的版本号进行比较，如果相同，则将第一覆盖率文件和第二覆盖率文件提交给数据合并模块进行数据合并；如果第一覆盖率文件的版本号小于第二覆盖率文件的版本号，则将第一覆盖率文件中的覆盖率数据映射至第二覆盖率文件的版本，再将映射后的第一覆盖率文件和第二覆盖率文件提交给数据合并模块进行数据合并；如果第一覆盖率文件的版本号大于第二覆盖率文件的版本号，则将第二覆盖率文件中的覆盖率数据映射至第一覆盖率文件的版本，再将第一覆盖率文件和映射后的第二覆盖率文件提交给数据合并模块进行数据合并。所述数据合并模块用于将第一覆盖率文件和第二覆盖率文件进行合并，并将合并后的覆盖率文件作为第二覆盖率文件保存。

在一些实例中，上述覆盖率报告生成服务器602可以根据覆盖率文件中记录的被执行覆盖的行号的数量得到覆盖率报告。该覆盖率报告可以包含每个代码修改记录的代码覆盖率、差异化代码覆盖率、某个功能模块的代码覆盖率和/或整个被测应用软件的整体代码覆盖率。

在一些实例中，上述覆盖率报告生成服务器602可以进一步包括反馈模块，用于设置代码修改记录的代码覆盖率合格阈值；以及将所述代码覆盖率报告中的代码覆盖率和所述代码覆盖率合格阈值进行比较，如果所述代码覆盖率大于或等于所述代码覆盖率合格阈值，则提示测试人员代码测试通过；如果所述代码覆盖率小于所述代码覆盖率合格阈值，则提示所述测试人员代码测试不通过。

需要说明的是，上述测试平台600包括的覆盖率文件收集服务器601、覆盖率报告生成服务器602以及测试管理服务器603可以物理上独立存在，也可以集成在一台服务器上完成，在此不做限定。

图7示出了本发明一个实施例提供的服务器的结构示意图。该服务器可以是测试平台600中的服务器。具体来讲：

服务器700包括中央处理单元(cpu)701、包括随机存取存储器(ram)702和只读存储器(rom)703的系统存储器704，以及连接系统存储器704和中央处理单元701的系统总线705。服务器700还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(i/o系统)706，和用于存储操作系统713、应用程序714和其他程序模块715的大容量存储设备707。

基本输入/输出系统706包括有用于显示信息的显示器708和用于用户输入信息的诸如鼠标、键盘之类的输入设备709。其中显示器708和输入设备709都通过连接到系统总线705的输入输出控制器710连接到中央处理单元701。基本输入/输出系统706还可以包括输入输出控制器710以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器710还提供输出到显示屏、打印机或其他类型的输出设备。

大容量存储设备707通过连接到系统总线705的大容量存储控制器(未示出)连接到中央处理单元701。大容量存储设备707及其相关联的计算机可读介质为服务器700提供非易失性存储。也就是说，大容量存储设备707可以包括诸如硬盘或者cd-rom驱动器之类的计算机可读介质(未示出)。

不失一般性，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括ram、rom、eprom、eeprom、闪存或其他固态存储其技术，cd-rom、dvd或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器704和大容量存储设备707可以统称为存储器。

根据本发明的各种实施例，服务器700还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器700可以通过连接在系统总线705上的网络接口单元711连接到网络712，或者说，也可以使用网络接口单元711来连接到其他类型的网络或远程计算机系统(未示出)。

上述存储器还包括一个或者一个以上的程序，一个或者一个以上程序存储于存储器中，被配置由cpu执行。

另外，本发明的每一个实施例可以通过由数据处理设备如计算机执行的数据处理程序来实现。显然，数据处理程序构成了本发明。此外，通常存储在一个存储介质中的数据处理程序通过直接将程序读取出存储介质或者通过将程序安装或复制到数据处理设备的存储设备(如硬盘和或内存)中执行。因此，这样的存储介质也构成了本发明。存储介质可以使用任何类型的记录方式，例如纸张存储介质(如纸带等)、磁存储介质(如软盘、硬盘、闪存等)、光存储介质(如cd-rom等)、磁光存储介质(如mo等)等。

因此本发明还提供了一种存储介质，其中存储有数据处理程序，该数据处理程序用于执行本发明上述方法的任何一种实施例。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。