CN105677571B - 移动终端软件兼容性测试装置及方法 - Google Patents

Abstract

本发明公开了一种移动终端软件兼容性测试装置，包括：第一接收测试模块，用于接收用户输入的整机软件兼容性测试指令，并根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告；生成模块，用于根据该测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；第二接收测试模块，用于接收用户基于该待重新测试列表输入的重新测试指令，并根据该重新测试指令对该移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。本发明还公开了一种移动终端软件兼容性测试方法。采用本发明，可将对失败项进行重新测试得到的测试结果自动写入到测试报告中，提高测试效率。

Description

移动终端软件兼容性测试装置及方法

技术领域

本发明涉及测试领域，尤其涉及一种移动终端软件兼容性测试装置及方法。

背景技术

随着软件技术的发展，移动终端上的软件越来越多，移动终端上的软件运行在软件系统上。软件系统各式各样，不同厂商、研发组织或机构开发的软件系统可能不同，为了使得不同厂商、研发组织或机构开发的软件系统能在移动终端上正常运行，需要对软件系统进行CTS测试(Compatibility Test Suite，CTS，软件兼容性测试)，如果测试通过，则认为该软件系统上基本可以运行不同组织、机构开发的APP。在现有技术中，在进行CTS测试时，虽然不同的软件系统的测试项可能不同，但是软件系统包括的测试项的数量非常庞大，总体数量从两万项到几十不等。

传统的CTS测试方法分为整机、单包、单类、单方法等测试法，缺乏有效的整合，不能将测试结果同时体现在一个报告中。比如测试整机过程中，在对失败项进行重新测试时，测试某个单包，单包的测试结果是单独的，没有体现到整机的测试结果中，需要将单包的测试项手动更改到整机的测试结果中；这样做费时费力，而且还容易出错，对测试人员也会造成很大的压力，测试效率低。

发明内容

本发明的主要目的在于提出一种移动终端软件兼容性测试装置及方法，旨在解决现有技术中，在软件兼容性测试过程中，对失败项进行重新测试时，需要将该重新测试的测试结果手动修改到整机的测试结果中，导致测试效率低的技术问题。

为实现上述目的，本发明提供一种移动终端软件兼容性测试装置，该装置包括：

第一接收测试模块，用于接收用户输入的整机软件兼容性测试指令，并根据所述整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，所述测试报告包括所述软件系统的所有测试项的测试结果；

生成模块，用于根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；

第二接收测试模块，用于接收用户基于所述待重新测试列表输入的重新测试指令，并根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

可选的，所述生成模块包括：

第一生成单元，用于根据所述测试报告获取测试结果为测试失败的测试项，生成初始待重新测试列表；

判断单元，用于判断所述初始待重新测试列表中是否存在豁免项；

第二生成单元，用于在所述初始待重新测试列表中存在豁免项时，将所述待重新测试列表中的豁免项删除，生成待重新测试列表。

可选的，所述重新测试指令是失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项。

可选的，所述重新测试指令是包重新测试指令，所述第二接收测试模块包括：

接收单元，用于接收用户基于所述待重新测试列表输入的包重新测试指令；

获取单元，用于根据包重新测试指令获取所述移动终端的软件系统对应的待测试包；

测试单元，用于对所述待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

可选的，所述测试单元，还用于：

遍历所述待测试包的所有测试项，从所述待测试包中的所有测试项中确定待测试的测试项；

对所述确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

此外，为实现上述目的，本发明还提出一种移动终端软件兼容性测试方法，其特征在于，该方法包括：

接收用户输入的整机软件兼容性测试指令，并根据所述整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，所述测试报告包括所述软件系统的所有测试项的测试结果；

根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；

接收用户基于所述待重新测试列表输入的重新测试指令，并根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

可选的，根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表的步骤包括：

根据所述测试报告获取测试结果为测试失败的测试项，生成初始待重新测试列表；

判断所述初始待重新测试列表中是否存在豁免项；

若所述初始待重新测试列表中存在豁免项，则将所述待重新测试列表中的豁免项删除，生成待重新测试列表。

可选的，所述重新测试指令是失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项。

可选的，所述重新测试指令是包重新测试指令，所述接收用户基于所述待重新测试列表输入的重新测试指令，根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中的步骤包括：

接收用户基于所述待重新测试列表输入的包重新测试指令；

根据包重新测试指令获取所述移动终端的软件系统对应的待测试包；

对所述待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

可选的，对所述待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中的步骤包括：

遍历所述待测试包的所有测试项，从所述待测试包中的所有测试项中确定待测试的测试项；

对所述确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

本发明提供的移动终端软件兼容性测试装置及方法，该装置包括：第一接收测试模块，用于接收用户输入的整机软件兼容性测试指令，并根据所述整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，所述测试报告包括所述软件系统的所有测试项的测试结果；生成模块，用于根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；第二接收测试模块，用于接收用户基于所述待重新测试列表输入的重新测试指令，并根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中；可将对失败项进行重新测试得到的测试结果自动写入到测试报告中，提高测试效率。

附图说明

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图；

图2为本发明移动终端软件兼容性测试装置的一实施例的结构示意图；

图3为本发明移动终端软件兼容性测试装置中的生成模块的详细结构示意图；

图4为本发明移动终端软件兼容性测试装置中的第二接收测试模块的详细结构示意图；

图5为本发明移动终端软件兼容性测试方法的第一实施例的流程示意图；

图6为本发明移动终端软件兼容性测试方法的第二实施例的流程示意图；

图7为本发明移动终端软件兼容性测试方法的第三实施例的流程示意图；

图8为本发明移动终端软件兼容性测试方法的第四实施例的流程示意图；

图9为本发明移动终端软件兼容性测试方法的第五实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

移动终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意。

移动终端100可以包括无线通信单元110、A/V(音频/视频)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的移动终端，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述移动终端的元件。

无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信装置或网络之间的无线电通信。

A/V输入单元120用于接收音频或视频信号。用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元151上时，可以形成触摸屏。

感测单元140检测移动终端100的当前状态，(例如，移动终端100的打开或关闭状态)、移动终端100的位置、用户对于移动终端100的接触(即，触摸输入)的有无、移动终端100的取向、移动终端100的加速或将速移动和方向等等，并且生成用于控制移动终端100的操作的命令或信号。例如，当移动终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。识别模块可以是存储用于验证用户使用移动终端100的各种信息并且可以包括用户识别模块(UIM)、客户识别模块(SIM)、通用客户识别模块(USIM)等等。另外，具有识别模块的装置(下面称为“识别装置”)可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与移动终端100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。

输出单元150可以包括显示单元151等等。

显示单元151可以显示在移动终端100中处理的信息。例如，当移动终端100处于电话通话模式时，显示单元151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(UI)或图形用户界面(GUI)。当移动终端100处于视频通话模式或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的UI或GUI等等。

同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(LCD)、薄膜晶体管LCD(TFT-LCD)、有机发光二极管(OLED)显示器、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为TOLED(透明有机发光二极管)显示器等等。根据特定想要的实施方式，移动终端100可以包括两个或更多显示单元(或其它显示装置)，例如，移动终端可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制移动终端的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于再现(或回放)多媒体数据的多媒体模块181，多媒体模块181可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，己经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。

如图1中所示的移动终端100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信装置以及基于卫星的通信装置来操作。

基于上述移动终端硬件结构，提出本发明移动终端软件兼容性测试装置各个实施例。

参照图2，图2为本发明移动终端软件兼容性测试装置的一实施例的结构示意图，该装置包括：

第一接收测试模块10，用于接收用户输入的整机软件兼容性测试指令，并根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，该测试报告包括该软件系统的所有测试项的测试结果；

生成模块20，用于根据该测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；

第二接收测试模块30，用于接收用户基于该待重新测试列表输入的重新测试指令，并根据该重新测试指令对该移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

该移动终端的软件系统可以为安卓系统，该第一接收测试模块10接收用户输入的整机软件兼容性测试指令，在一实施例中，该整机软件兼容性测试指令为：run cts--planCTSname。

该第一接收测试模块10根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，具体的，对该软件系统中的所有测试项都进行测试，对每一个测试项得到一个测试结果，根据各个测试项的测试结果生成测试报告；每一个测试项的测试结果为测试成功、测试失败或未执行，其中：未执行表示在对测试项进行测试时，由于其它因素的影响，导致没有完成对该测试项的测试。

软件系统包括多个包、多个类、多个方法、多个测试项等，其中，一个包中可包括多个类，一个类中可包括多个方法，一个方法中可包括多个测试项。

可选的，该测试报告为xml文档。一个软件系统对应一个测试报告，该测试报告的文件名可根据该软件系统的名称确定，如在一实施例中，该软件系统的名称为Android5.0，则该软件系统对应的测试报告的文件名为Android5.0.xml，其中，该测试报告的主文件名为Android 5.0，该测试报告的扩展名为xml。

该生成模块20遍历该测试报告中各个测试项的测试结果，从该测试报告中选择出测试结果是测试失败的测试项，即从该测试报告中选择出需要重新测试的测试项，生成待重新测试列表。

该待重新测试列表中的各个测试项可能属于同一个方法；也可能属于不同的方法，但是属于同一个类；也可以属于不同的类，但是属于同一个包；也可能属于不同的包。

该重新测试指令是失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项。用户可根据实际需要输入对应的重新测试指令，如当希望对待重新测试列表中的所有测试项进行测试，则可对输入失败项重新测试指令，则该第二接收测试模块30接收失败项重新测试指令，并根据该失败项重新测试指令对待重新测试列表中的所有测试项都进行测试，得到新测试结果，新测试结果为测试成功、测试失败或未执行，其中：未执行表示在对测试项进行测试时，由于其它因素的影响，导致没有完成对该测试项的测试。在一实施例中，该失败项重新测试指令为run cts--continue-session id，其中id是测试报告的唯一标识。

具体的，该第二接收测试模块30通过tradefed脚本接收该重新测试指令，再将该接收的重新测试指令传送给由CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole进行参数分析、拆解，然后调用相应的java包中的类去进一步处理，然后返回测试结果，该测试结果即为新测试结果，再将该新测试结果写入测试报告中，即将重新测试得到的新测试结果整合到测试报告中，对该测试报告中的对应测试项的测试结果进行更新。

该重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名。在该步骤中，可根据该重新测试指令中的测试报告的唯一标识，确定需要将该新测试结果写入到的测试报告。该测试报告的唯一标识可通过list-r命令获取。

采用上述实施例，通过第一接收测试模块10，用于接收用户输入的整机软件兼容性测试指令，并根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，该测试报告包括该软件系统的所有测试项的测试结果；生成模块20，用于根据该测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；第二接收测试模块30，用于接收用户基于该待重新测试列表输入的重新测试指令，并根据该重新测试指令对该移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中；可将对失败项进行重新测试得到的测试结果自动写入到测试报告中，提高测试效率。

进一步的，如图3所示，该生成模块20包括：

第一生成单元21，用于根据该测试报告获取测试结果为测试失败的测试项，生成初始待重新测试列表；

判断单元22，用于判断该初始待重新测试列表中是否存在豁免项；

第二生成单元23，用于在该初始待重新测试列表中存在豁免项时，将该待重新测试列表中的豁免项删除，生成待重新测试列表。

该第一生成单元21遍历该测试报告中的各个测试项的测试结果，从该测试报告中选择出测试结果是测试失败的测试项，生成初始待重新测试列表，即在该步骤中，不管该测试失败的测试项是否是豁免项，都将其挑选出来，加入到初始待重新测试列表中。

该豁免项即为可不测试的测试项，在软件系统中的测试项非常多，其中有些测试项可不用测试，通常的，该豁免项为在大部分的软件系统中都测试失败的测试项，如，有100个软件系统，某个测试项在这100个软件系统中进行软件兼容性测试时，测试结果中有99个测试失败，则说明该某个测试项一般无法通过软件兼容性测试，则可将该某个测试项设置为豁免项。

该判断单元22可先获取预置的豁免项列表，再将该初始待重新测试列表与该豁免项列表进行比对，判断该初始重新测试列表中的测试项是否存在该豁免项列表中，若该初始重新测试列表中的测试项存在该豁免项列表中，则认为该初始重新测试列表中存在豁免项。可选的，该豁免项列表可保存在xls文档中。

该第二生成单元23将该待重新测试列表中的豁免项删除，具体的，可根据该豁免项列表确定该待重新测试列表中的豁免项，再将该确定的豁免项从该待重新测试列表中删除，生成待重新测试列表。即该待重新测试列表中的各个测试项需要进行重新测试。

进一步的，该重新测试指令是包重新测试指令，如图4所示，该第二接收测试模块30包括：

接收单元31，用于接收用户基于该待重新测试列表输入的包重新测试指令；

获取单元32，用于根据包重新测试指令获取该移动终端的软件系统对应的待测试包；

测试单元33，用于对该待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

该包重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名，该包重新测试指令还包括待测试包的包名。

用户可根据该待重新测试列表中的测试项的分布情况，确定输入失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项，当该待重新测试列表中的测试项属于多个类，但是属于同一个包，则用户可以输入包重新测试指令，可避免用户频繁的输入类重新测试指令，如该待重新测试列表中的测试项属于10个类，这10个类都属于同一个包，则通过输入包重新测试指令时，只需要输入一次指令，而通过输入类重新测试指令，则需要输入十次指令。

在一实施例中，该包重新测试指令为：run cts-p<package_name>id1id2，其中package_name表示待测试包的包名，id1表示软件系统的测试报告的唯一标识，id2表示唯一标识为id1的测试报告中名为<package_name>的第id2个包，若该测试报告中不存在同名的包，则该id2为1，若有同名包且要测试第2个同名的包，则id2为2，依次类推。

具体的，该接收单元31通过tradefed脚本接收该包重新测试指令。

具体的，该获取单元32通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole对tradefed脚本接收的包重新测试指令进行参数分析、拆解，获取到该移动终端的软件系统对应的待测试包。

具体的，该测试单元33通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole调用相应的java包中的类去对该待测试包进行测试，然后返回测试结果，该测试结果即为新测试结果，并将测试结果自动写入该测试报告中。可通过该包重新测试指令确定需要写入的测试报告。

进一步的，该测试单元33，还用于：

遍历该待测试包的所有测试项，从该待测试包中的所有测试项中确定待测试的测试项；

对该确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

该测试单元33遍历该待测试包的所有测试项，从该待测试包中选择出豁免项，将该待测试包中的除豁免项以外的其它测试项确定为待测试的测试项，即该待测试包的豁免项不需要再次进行测试。该豁免项的测试结果为在对该软件系统进行初步测试时的测试结果。

该测试单元33对该确定的待测试的测试项进行测试，得到各个待测试项的新测试结果，根据该各个待测试的测试项的新测试结果更新该测试报告，即对该测试报告中的该各个待测试的测试项的测试结果进行更新。

进一步的，该重新测试指令是类重新测试指令，该接收单元31，还用于接收用户基于该待重新测试列表输入的类重新测试指令；该获取单元32，还用于根据类重新测试指令获取该移动终端的软件系统对应的待测试类；该测试单元33，还用于对该待测试类的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中。

该类重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名，该类重新测试指令还包括待测试类的类名。

用户可根据该待重新测试列表中的测试项的分布情况，确定输入失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项，当该待重新测试列表中的测试项属于多个方法，但是属于同一个类，则用户可以输入类重新测试指令，可避免用户频繁的输入方法重新测试指令，如该待重新测试列表中的测试项属于10个方法，这10个方法都属于同一个类，则通过输入类重新测试指令时，只需要输入一次指令，而通过输入方法重新测试指令，则需要输入十次指令。

在一实施例中，该类重新测试指令为：run cts–c<class_name>id1id2，其中class_name表示待测试类的类名，id1表示软件系统的测试报告的唯一标识，id2表示唯一标识为id1的测试报告中名为<class_name>的第id2个类，若该测试报告中不存在同名的类，则该id2为1，若有同名类且要测试第2个同名的类，则id2为2，依次类推。

具体的，该接收单元31通过tradefed脚本接收该类重新测试指令。

具体的，该获取单元32通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole对tradefed脚本接收的类重新测试指令进行参数分析、拆解，获取到该移动终端的软件系统对应的待测试类。

具体的，该测试单元33通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole调用相应的java包中的类去对该待测试类进行测试，然后返回测试结果，该测试结果即为新测试结果，并将测试结果自动写入该测试报告中。可通过该类重新测试指令确定需要写入的测试报告。

进一步的，该测试单元33，还用于遍历该待测试类的所有测试项，从该待测试类中的所有测试项中确定待测试的测试项；及对该确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

该测试单元33遍历该待测试类的所有测试项，从该待测试类中选择出豁免项，将该待测试类中的除豁免项以外的其它测试项确定为待测试的测试项，即该待测试类的豁免项不需要再次进行测试。该豁免项的测试结果为在对该软件系统进行初步测试时的测试结果。

该测试单元33对该确定的待测试的测试项进行测试，得到各个待测试项的新测试结果，根据该各个待测试的测试项的新测试结果更新该测试报告，即对该测试报告中的该各个待测试的测试项的测试结果进行更新。

进一步的，该重新测试指令是方法重新测试指令，该接收单元31，还用于接收用户基于该待重新测试列表输入的方法重新测试指令；该获取单元32，还用于根据方法重新测试指令获取该移动终端的软件系统对应的待测试方法；该测试单元33，还用于对该待测试方法的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中。

该方法重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名，该方法重新测试指令还包括待测试方法的方法名。

用户可根据该待重新测试列表中的测试项的分布情况，确定输入失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项，当该待重新测试列表中的测试项属于同一个方法，则用户可以输入方法重新测试指令。

在一实施例中，该方法重新测试指令为：run cts–c<class_name>-m<method_name>id1id2，其中class_name表示待测试方法所在类的类名，method_name表示待测试方法的方法名，id1表示软件系统的测试报告的唯一标识，id2表示唯一标识为id1的测试报告中名为<method_name>的第id2个方法，若该测试报告中不存在同名的方法，则该id2为1，若有同名方法且要测试第2个同名的方法，则id2为2，依次类推。

具体的，该接收单元31通过tradefed脚本接收该方法重新测试指令。

具体的，该获取单元32通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole对tradefed脚本接收的方法重新测试指令进行参数分析、拆解，获取到该移动终端的软件系统对应的待测试方法。

具体的，该测试单元33通过该CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole调用相应的java包中的类去对该待测试方法进行测试，然后返回测试结果，该测试结果即为新测试结果，并将测试结果自动写入该测试报告中。可通过该方法重新测试指令确定需要写入的测试报告。

进一步的，该测试单元33，还用于遍历该待测试方法的所有测试项，从该待测试方法中的所有测试项中确定待测试的测试项，及对该确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

该测试单元33遍历该待测试方法的所有测试项，从该待测试方法中选择出豁免项，将该待测试方法中的除豁免项以外的其它测试项确定为待测试的测试项，即该待测试方法的豁免项不需要再次进行测试。该豁免项的测试结果为在对该软件系统进行初步测试时的测试结果。

该测试单元33对该确定的待测试的测试项进行测试，得到各个待测试项的新测试结果，根据该各个待测试的测试项的新测试结果更新该测试报告，即对该测试报告中的该各个待测试的测试项的测试结果进行更新。

本发明进一步提供一种移动终端软件兼容性测试方法。

参照图5，图5为本发明移动终端软件兼容性测试方法的第一实施例的流程示意图，该方法包括：

S10、接收用户输入的整机软件兼容性测试指令，并根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，该测试报告包括该软件系统的所有测试项的测试结果。

该移动终端的软件系统为安卓系统，在该步骤中，接收用户输入的整机软件兼容性测试指令，在一实施例中，该整机软件兼容性测试指令为：run cts--plan CTSname。

根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，具体的，对该软件系统中的所有测试项都进行测试，对每一个测试项得到一个测试结果，根据各个测试项的测试结果生成测试报告；每一个测试项的测试结果为测试成功、测试失败或未执行，其中：未执行表示在对测试项进行测试时，由于其它因素的影响，导致没有完成对该测试项的测试。

软件系统包括多个包、多个类、多个方法、多个测试项等，其中，一个包中可包括多个类，一个类中可包括多个方法，一个方法中可包括多个测试项。

可选的，该测试报告为xml文档。一个软件系统对应一个测试报告，该测试报告的文件名可根据该软件系统的名称确定，如在一实施例中，该软件系统的名称为Android5.0，则该软件系统对应的测试报告的文件名为Android5.0.xml，其中，该测试报告的主文件名为Android 5.0，该测试报告的扩展名为xml。

S20、根据该测试报告获取测试结果为测试失败的测试项，生成待重新测试列表。

遍历该测试报告中各个测试项的测试结果，从该测试报告中选择出测试结果是测试失败的测试项，即从该测试报告中选择出需要重新测试的测试项，生成待重新测试列表。

该待重新测试列表中的各个测试项可能属于同一个方法；也可能属于不同的方法，但是属于同一个类；也可以属于不同的类，但是属于同一个包；也可能属于不同的包。

S30、接收用户基于该待重新测试列表输入的重新测试指令，并根据该重新测试指令对该移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

该重新测试指令是失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项。用户可根据实际需要输入对应的重新测试指令，如当希望对待重新测试列表中的所有测试项进行测试，则可对输入失败项重新测试指令，则在该步骤中，接收失败项重新测试指令，并根据该失败项重新测试指令对待重新测试列表中的所有测试项都进行测试，得到新测试结果，新测试结果为测试成功、测试失败或未执行，其中：未执行表示在对测试项进行测试时，由于其它因素的影响，导致没有完成对该测试项的测试。在一实施例中，该失败项重新测试指令为run cts--continue-session id，其中id是测试报告的唯一标识。

具体的，在该步骤中，tradefed脚本接收该重新测试指令，再将该接收的重新测试指令传送给由CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole进行参数分析、拆解，然后调用相应的java包中的类去进一步处理，然后返回测试结果，该测试结果即为新测试结果，再将该新测试结果写入测试报告中，即将重新测试得到的新测试结果整合到测试报告中，对该测试报告中的对应测试项的测试结果进行更新。

该重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名。在该步骤中，可根据该重新测试指令中的测试报告的唯一标识，确定需要将该新测试结果写入到的测试报告。该测试报告的唯一标识可通过list-r命令获取。

采用上述实施例中，接收用户输入的整机软件兼容性测试指令，并根据该整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，该测试报告包括该软件系统的所有测试项的测试结果；根据该测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；接收用户基于该待重新测试列表输入的重新测试指令，并根据该重新测试指令对该移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中；可将对失败项进行重新测试得到的测试结果自动写入到测试报告中，提高测试效率。

参照图6，图6为本发明移动终端软件兼容性测试方法的第二实施例的流程示意图。

基于上述移动终端软件兼容性测试方法的第一实施例，该步骤S20包括：

S21、根据该测试报告获取测试结果为测试失败的测试项，生成初始待重新测试列表。

遍历该测试报告中的各个测试项的测试结果，从该测试报告中选择出测试结果是测试失败的测试项，生成初始待重新测试列表，即在该步骤中，不管该测试失败的测试项是否是豁免项，都将其挑选出来，加入到初始待重新测试列表中。

S22、判断该初始待重新测试列表中是否存在豁免项，若该初始待重新测试列表中存在豁免项，则执行步骤S23。

该豁免项即为可不测试的测试项，在软件系统中的测试项非常多，其中有些测试项可不用测试，通常的，该豁免项为在大部分的软件系统中都测试失败的测试项，如，有100个软件系统，某个测试项在这100个软件系统中进行软件兼容性测试时，测试结果中有99个测试失败，则说明该某个测试项一般无法通过软件兼容性测试，则可将该某个测试项设置为豁免项。

在该步骤中，可先获取预置的豁免项列表，再将该初始待重新测试列表与该豁免项列表进行比对，判断该初始重新测试列表中的测试项是否存在该豁免项列表中，若该初始重新测试列表中的测试项存在该豁免项列表中，则认为该初始重新测试列表中存在豁免项。可选的，该豁免项列表可保存在xls文档中。

S23、将该待重新测试列表中的豁免项删除，生成待重新测试列表。

在该步骤中，将该待重新测试列表中的豁免项删除，具体的，可根据该豁免项列表确定该待重新测试列表中的豁免项，再将该确定的豁免项从该待重新测试列表中删除，生成待重新测试列表。即该待重新测试列表中的各个测试项需要进行重新测试。

参照图7，图7为本发明移动终端软件兼容性测试方法的第三实施例的流程示意图。

基于上述移动终端软件兼容性测试方法的第一实施例或第二实施例，该重新测试指令是包重新测试指令，该步骤S30包括：

S31、接收用户基于该待重新测试列表输入的包重新测试指令。

该包重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名，该包重新测试指令还包括待测试包的包名。

用户可根据该待重新测试列表中的测试项的分布情况，确定输入失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项，当该待重新测试列表中的测试项属于多个类，但是属于同一个包，则用户可以输入包重新测试指令，可避免用户频繁的输入类重新测试指令，如该待重新测试列表中的测试项属于10个类，这10个类都属于同一个包，则通过输入包重新测试指令时，只需要输入一次指令，而通过输入类重新测试指令，则需要输入十次指令。

在一实施例中，该包重新测试指令为：run cts-p<package_name>id1id2，其中package_name表示待测试包的包名，id1表示软件系统的测试报告的唯一标识，id2表示唯一标识为id1的测试报告中名为<package_name>的第id2个包，若该测试报告中不存在同名的包，则该id2为1，若有同名包且要测试第2个同名的包，则id2为2，依次类推。

具体的，在该步骤中，通过tradefed脚本接收该包重新测试指令。

S32、根据包重新测试指令获取该移动终端的软件系统对应的待测试包。

具体的，在该步骤中，CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole对tradefed脚本接收的包重新测试指令进行参数分析、拆解，获取到该移动终端的软件系统对应的待测试包。

S33、对该待测试包的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中。

具体的，在该步骤中，通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole调用相应的java包中的类去对该待测试包进行测试，然后返回测试结果，该测试结果即为新测试结果，并将测试结果自动写入该测试报告中。可通过该包重新测试指令确定需要写入的测试报告。

进一步的，对该待测试包的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中的步骤包括：

S331、遍历该待测试包的所有测试项，从该待测试包中的所有测试项中确定待测试的测试项。

遍历该待测试包的所有测试项，从该待测试包中选择出豁免项，将该待测试包中的除豁免项以外的其它测试项确定为待测试的测试项，即该待测试包的豁免项不需要再次进行测试。该豁免项的测试结果为在对该软件系统进行初步测试时的测试结果。

S332、对该确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

在该步骤中，对该确定的待测试的测试项进行测试，得到各个待测试项的新测试结果，根据该各个待测试的测试项的新测试结果更新该测试报告，即对该测试报告中的该各个待测试的测试项的测试结果进行更新。

参照图8，图8为本发明移动终端软件兼容性测试方法的第四实施例的流程示意图。

基于上述移动终端软件兼容性测试方法的第一实施例或第二实施例，该重新测试指令是类重新测试指令，该步骤S30包括：

S34、接收用户基于该待重新测试列表输入的类重新测试指令。

该类重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名，该类重新测试指令还包括待测试类的类名。

用户可根据该待重新测试列表中的测试项的分布情况，确定输入失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项，当该待重新测试列表中的测试项属于多个方法，但是属于同一个类，则用户可以输入类重新测试指令，可避免用户频繁的输入方法重新测试指令，如该待重新测试列表中的测试项属于10个方法，这10个方法都属于同一个类，则通过输入类重新测试指令时，只需要输入一次指令，而通过输入方法重新测试指令，则需要输入十次指令。

在一实施例中，该类重新测试指令为：run cts–c<class_name>id1id2，其中class_name表示待测试类的类名，id1表示软件系统的测试报告的唯一标识，id2表示唯一标识为id1的测试报告中名为<class_name>的第id2个类，若该测试报告中不存在同名的类，则该id2为1，若有同名类且要测试第2个同名的类，则id2为2，依次类推。

具体的，在该步骤中，通过tradefed脚本接收该类重新测试指令。

S35、根据类重新测试指令获取该移动终端的软件系统对应的待测试类。

具体的，在该步骤中，通过CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole对tradefed脚本接收的类重新测试指令进行参数分析、拆解，获取到该移动终端的软件系统对应的待测试类。

S36、对该待测试类的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中。

具体的，在该步骤中，该CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole调用相应的java包中的类去对该待测试类进行测试，然后返回测试结果，该测试结果即为新测试结果，并将测试结果自动写入该测试报告中。可通过该类重新测试指令确定需要写入的测试报告。

进一步的，对该待测试类的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中的步骤包括：

S361、遍历该待测试类的所有测试项，从该待测试类中的所有测试项中确定待测试的测试项。

遍历该待测试类的所有测试项，从该待测试类中选择出豁免项，将该待测试类中的除豁免项以外的其它测试项确定为待测试的测试项，即该待测试类的豁免项不需要再次进行测试。该豁免项的测试结果为在对该软件系统进行初步测试时的测试结果。

S362、对该确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

在该步骤中，对该确定的待测试的测试项进行测试，得到各个待测试项的新测试结果，根据该各个待测试的测试项的新测试结果更新该测试报告，即对该测试报告中的该各个待测试的测试项的测试结果进行更新。

参照图9，图9为本发明移动终端软件兼容性测试方法的第五实施例的流程示意图。

基于上述移动终端软件兼容性测试方法的第一实施例或第二实施例，该重新测试指令是方法重新测试指令，该步骤S30包括：

S37、接收用户基于该待重新测试列表输入的方法重新测试指令。

该方法重新测试指令包括测试报告的唯一标识，该测试报告的唯一标识可以为该测试报告的主文件名，该方法重新测试指令还包括待测试方法的方法名。

用户可根据该待重新测试列表中的测试项的分布情况，确定输入失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项，当该待重新测试列表中的测试项属于同一个方法，则用户可以输入方法重新测试指令。

在一实施例中，该方法重新测试指令为：run cts–c<class_name>-m<method_name>id1id2，其中class_name表示待测试方法所在类的类名，method_name表示待测试方法的方法名，id1表示软件系统的测试报告的唯一标识，id2表示唯一标识为id1的测试报告中名为<method_name>的第id2个方法，若该测试报告中不存在同名的方法，则该id2为1，若有同名方法且要测试第2个同名的方法，则id2为2，依次类推。

具体的，在该步骤中，通过tradefed脚本接收该方法重新测试指令。

S38、根据方法重新测试指令获取该移动终端的软件系统对应的待测试方法。

具体的，在该步骤中，CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole对tradefed脚本接收的方法重新测试指令进行参数分析、拆解，获取到该移动终端的软件系统对应的待测试方法。

S39、对该待测试方法的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中。

具体的，在该步骤中，通过该CTS测试框架中的tradefed.jar中的com.android.cts.tradefed.command.CtsConsole调用相应的java包中的类去对该待测试方法进行测试，然后返回测试结果，该测试结果即为新测试结果，并将测试结果自动写入该测试报告中。可通过该方法重新测试指令确定需要写入的测试报告。

进一步的，对该待测试方法的测试项进行重新测试，得到新测试结果，并将测试结果自动写入该测试报告中的步骤包括：

S391、遍历该待测试方法的所有测试项，从该待测试方法中的所有测试项中确定待测试的测试项。

遍历该待测试方法的所有测试项，从该待测试方法中选择出豁免项，将该待测试方法中的除豁免项以外的其它测试项确定为待测试的测试项，即该待测试方法的豁免项不需要再次进行测试。该豁免项的测试结果为在对该软件系统进行初步测试时的测试结果。

S392、对该确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入该测试报告中。

在该步骤中，对该确定的待测试的测试项进行测试，得到各个待测试项的新测试结果，根据该各个待测试的测试项的新测试结果更新该测试报告，即对该测试报告中的该各个待测试的测试项的测试结果进行更新。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例该的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (8)

1.一种移动终端软件兼容性测试装置，其特征在于，该装置包括：

第一接收测试模块，用于接收用户输入的整机软件兼容性测试指令，并根据所述整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，所述测试报告包括所述软件系统的所有测试项的测试结果；

生成模块，用于根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；

第二接收测试模块，用于接收用户基于所述待重新测试列表输入的重新测试指令，并根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中；其中，所述重新测试指令包括测试报告的唯一标识；

其中，所述生成模块包括：

第一生成单元，用于根据所述测试报告获取测试结果为测试失败的测试项，生成初始待重新测试列表；

判断单元，用于判断所述初始待重新测试列表中是否存在豁免项；

第二生成单元，用于在所述初始待重新测试列表中存在豁免项时，将所述待重新测试列表中的豁免项删除，生成待重新测试列表。

2.如权利要求1所述的移动终端软件兼容性测试装置，其特征在于，所述重新测试指令是失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项。

3.如权利要求2所述的移动终端软件兼容性测试装置，其特征在于，所述重新测试指令是包重新测试指令，所述第二接收测试模块包括：

接收单元，用于接收用户基于所述待重新测试列表输入的包重新测试指令；

获取单元，用于根据包重新测试指令获取所述移动终端的软件系统对应的待测试包；

测试单元，用于对所述待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

4.如权利要求3所述的移动终端软件兼容性测试装置，其特征在于，所述测试单元，还用于：

遍历所述待测试包的所有测试项，从所述待测试包中的所有测试项中确定待测试的测试项；

对所述确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

5.一种移动终端软件兼容性测试方法，其特征在于，该方法包括：

接收用户输入的整机软件兼容性测试指令，并根据所述整机软件兼容性测试指令对移动终端的软件系统进行初步测试，生成测试报告，所述测试报告包括所述软件系统的所有测试项的测试结果；

根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表；

接收用户基于所述待重新测试列表输入的重新测试指令，并根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中；其中，所述重新测试指令包括测试报告的唯一标识；

其中，根据所述测试报告获取测试结果为测试失败的测试项，生成待重新测试列表的步骤包括：

根据所述测试报告获取测试结果为测试失败的测试项，生成初始待重新测试列表；

判断所述初始待重新测试列表中是否存在豁免项；

若所述初始待重新测试列表中存在豁免项，则将所述待重新测试列表中的豁免项删除，生成待重新测试列表。

6.如权利要求5所述的移动终端软件兼容性测试方法，其特征在于，所述重新测试指令是失败项重新测试指令、包重新测试指令、类重新测试指令、方法重新测试指令中的任一项。

7.如权利要求6所述的移动终端软件兼容性测试方法，其特征在于，所述重新测试指令是包重新测试指令，所述接收用户基于所述待重新测试列表输入的重新测试指令，根据所述重新测试指令对所述移动终端的软件系统对应的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中的步骤包括：

接收用户基于所述待重新测试列表输入的包重新测试指令；

根据包重新测试指令获取所述移动终端的软件系统对应的待测试包；

对所述待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。

8.如权利要求7所述的移动终端软件兼容性测试方法，其特征在于，对所述待测试包的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中的步骤包括：

遍历所述待测试包的所有测试项，从所述待测试包中的所有测试项中确定待测试的测试项；

对所述确定的待测试的测试项进行重新测试，得到新测试结果，并将新测试结果自动写入所述测试报告中。