CN105095074B - 配置文件的升级测试方法和装置 - Google Patents

Abstract

本发明提出一种配置文件的升级测试方法和装置，该配置文件的升级测试方法包括：获得启动的应用中的配置文件；对所述配置文件进行解析，获得所述配置文件的第一关键信息，所述第一关键信息包括所述配置文件的第一版本号和所述第一版本号所对应的版本的升级时间；触发所述配置文件进行升级，在所述配置文件升级之后，获得升级后的配置文件的第二关键信息，所述第二关键信息包括升级后的配置文件的第二版本号和所述第二版本号所对应版本的升级时间；根据所述第一关键信息和所述第二关键信息确定所述配置文件的升级情况。本发明实现了对配置文件的升级进行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效率。

Description

配置文件的升级测试方法和装置

技术领域

本发明涉及测试技术领域，尤其涉及一种配置文件的升级测试方法和装置。

背景技术

现有技术中，移动终端中安装的应用(Application；以下简称：App)的配置文件升级之后，对配置文件的进行升级测试时，现有技术一般采用人工查看配置文件，进行一次的结果校验，具体地，可以用第三方工具或者adb命令一层层的找到指定的文件，打开指定的文件后，在众多的标签中肉眼寻找关键标签。

现有技术提供的另一种对配置文件进行升级测试的方案是根据用户界面(UserInterface；以下简称：UI)层的结果，反推云端库升级的情况，具体地，可以通过查看App的某一功能是否改变，反推云端库升级是否成功。

但是，人工查看配置文件的方案，效率低下，并且出错率较高；而通过UI层的结果反推云端库升级的情况的方案，问题反馈不及时，影响测试结果的及时性，且容易存在漏洞。

发明内容

本发明的目的旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明的第一个目的在于提出一种配置文件的升级测试方法。该方法根据配置文件升级前后的关键信息确定配置文件的升级情况，实现了对配置文件的升级进行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效率。

本发明的第二个目的在于提出一种配置文件的升级测试装置。

为了实现上述目的，本发明第一方面实施例的配置文件的升级测试方法，包括：获得启动的应用中的配置文件；对所述配置文件进行解析，获得所述配置文件的第一关键信息，所述第一关键信息包括所述配置文件的第一版本号和所述第一版本号所对应的版本的升级时间；触发所述配置文件进行升级，在所述配置文件升级之后，获得升级后的配置文件的第二关键信息，所述第二关键信息包括升级后的配置文件的第二版本号和所述第二版本号所对应版本的升级时间；根据所述第一关键信息和所述第二关键信息确定所述配置文件的升级情况。

结合第一方面，在第一方面的第一种可能的实现方式中，所述根据所述第一关键信息和所述第二关键信息确定所述配置文件的升级情况包括：如果所述第二关键信息中的第二版本号与所述第一关键信息中的第一版本号相同，或者所述第二关键信息中的第二版本号不是升级的目的版本号，则确定所述配置文件升级失败；或者，如果所述第二关键信息中的第二版本号为升级的目的版本号，但所述第二关键信息中所述第二版本号所对应版本的升级时间不正确，则确定所述配置文件升级成功，但升级时间不正确；或者，如果所述第二关键信息中的第二版本号为升级的目的版本号，并且所述第二关键信息中所述第二版本号所对应版本的升级时间正确，则确定所述配置文件升级成功，并且升级时间正确。

结合第一方面或者第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述对所述配置文件进行解析，获得所述配置文件的第一关键信息包括：加载自定义文件解析类，通过加载的自定义文件解析类对所述配置文件进行解析，获得所述配置文件的第一关键信息。

结合第一方面或者第一方面的第一种可能的实现方式，在第一方面的第三种可能的实现方式中，所述根据所述第一关键信息和所述第二关键信息确定所述配置文件的升级情况之后，还包括：在所述配置文件升级后，对所述应用的核心模块进行崩溃测试。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述对所述应用的核心模块进行崩溃测试之后，还包括：将所述配置文件的升级情况，或者将所述配置文件的升级情况和所述应用的核心模块的崩溃测试结果存入数据库，并输出测试报告。

本发明实施例的配置文件的升级测试方法，获得配置文件升级前后的关键信息之后，根据配置文件升级前后的关键信息确定配置文件的升级情况，从而实现了对配置文件的升级进行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效率。

为了实现上述目的，本发明第二方面实施例的配置文件的升级测试装置，包括：获得模块，用于获得启动的应用中的配置文件；解析模块，用于对所述获得模块获得的配置文件进行解析，获得所述配置文件的第一关键信息，所述第一关键信息包括所述配置文件的第一版本号和所述第一版本号所对应的版本的升级时间；触发模块，用于触发所述配置文件进行升级；所述解析模块，还用于在所述配置文件升级之后，获得升级后的配置文件的第二关键信息，所述第二关键信息包括升级后的配置文件的第二版本号和所述第二版本号所对应版本的升级时间；确定模块，用于根据所述解析模块获得的所述第一关键信息和所述解析模块获得的所述第二关键信息确定所述配置文件的升级情况。

结合第二方面，在第二方面的第一种可能的实现方式中，所述确定模块，具体用于当所述第二关键信息中的第二版本号与所述第一关键信息中的第一版本号相同，或者所述第二关键信息中的第二版本号不是升级的目的版本号时，确定所述配置文件升级失败；或者，当所述第二关键信息中的第二版本号为升级的目的版本号，但所述第二关键信息中所述第二版本号所对应版本的升级时间不正确时，确定所述配置文件升级成功，但升级时间不正确；或者，当所述第二关键信息中的第二版本号为升级的目的版本号，并且所述第二关键信息中所述第二版本号所对应版本的升级时间正确时，确定所述配置文件升级成功，并且升级时间正确。

结合第二方面或者第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，所述解析模块，具体用于加载自定义文件解析类，通过加载的自定义文件解析类对所述配置文件进行解析，获得所述配置文件的第一关键信息。

结合第二方面或者第二方面的第一种可能的实现方式，在第二方面的第三种可能的实现方式中，所述装置还包括：崩溃测试模块，用于在所述配置文件升级后，对所述应用的核心模块进行崩溃测试。

结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，所述装置还包括：输出模块，用于将所述配置文件的升级情况，或者将所述配置文件的升级情况和所述应用的核心模块的崩溃测试结果存入数据库，并输出测试报告。

本发明实施例的配置文件的升级测试装置，解析模块获得配置文件升级前后的关键信息之后，确定模块根据配置文件升级前后的关键信息确定配置文件的升级情况，从而实现了对配置文件的升级进行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效率。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明配置文件的升级测试方法一个实施例的流程图；

图2为本发明配置文件的升级测试方法中获得第一关键信息的方式一个实施例的示意图；

图3为本发明配置文件的升级测试方法中确定升级情况一个实例的示意图；

图4为本发明配置文件的升级测试方法另一个实施例的流程图；

图5为本发明配置文件的升级测试方法中测试报告一个示例的示意图；

图6(a)～图6(b)为本发明配置文件的升级测试方法一个示例的逻辑示意图；

图7为本发明配置文件的升级测试装置一个实施例的结构示意图；

图8为本发明配置文件的升级测试装置另一个实施例的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

图1为本发明配置文件的升级测试方法一个实施例的流程图，如图1所示，该配置文件的升级测试方法可以包括：

步骤101，获得启动的应用中的配置文件。

进一步地，在步骤101之前，需要先安装App，然后启动App，使程序铺开配置文件。具体地，可以通过Java遍历安装包目录，每次获取一个App，然后用adb命令进行安装。然后可以通过“adb am start包名”这条命令启动安装的App，使程序铺开配置文件。

具体地，获得启动的应用中的配置文件可以为：通过shell命令将配置文件拷贝到本地个人计算机(Personal Computer；以下简称：PC)上。举例来说，可以通过以下命令将配置文件拷贝到PC上，“/data/data/com.cleanmaster.mguard/shared_prefs/com.cleanmaster.mguard.update.UpdateManager.xml”。

其中，“/data/”目录下的文件为手机系统保护文件，不能直接拷贝到PC上。可以先通过cp命令将“/data/”目录下的文件拷贝到“/sdcard”根目录，再用adb pull命令拷贝到PC。

以上仅为获得启动的应用中的配置文件的一种示例，本实施例并不仅限于此，本实施例对获得启动的应用中的配置文件的方式不作限定。

步骤102，对上述配置文件进行解析，获得上述配置文件的第一关键信息，上述第一关键信息包括上述配置文件的第一版本号和上述第一版本号所对应的版本的升级时间。

具体地，对上述配置文件进行解析，获得上述配置文件的第一关键信息可以为：加载自定义文件解析类，通过加载的自定义文件解析类对上述配置文件进行解析，获得上述配置文件的第一关键信息。

其中，上述文件解析类，可以扩展，也可以根据不同的配置文件类型进行修订。另外，承载第一关键信息的关键字段也可以根据业务内容定制。

例如，想解析下面一段中“version_data”字段的内容，可以采用图2所示的方式获得，图2为本发明配置文件的升级测试方法中获得第一关键信息的方式一个实施例的示意图。

从图2中可以看出，获得的第一关键信息中包括第一版本号和第一版本号所对应版本的升级时间等信息。

步骤103，触发上述配置文件进行升级，在上述配置文件升级之后，获得升级后的配置文件的第二关键信息，上述第二关键信息包括升级后的配置文件的第二版本号和上述第二版本号所对应版本的升级时间。

本实施例中，触发上述配置文件进行升级可以为：通过点击某个按钮，进行下拉操作或者等待一段时间触发配置文件进行升级，本实施例对触发上述配置文件进行升级的方式不作限定。

具体地，本步骤中获得升级后的配置文件的第二关键信息的方式与步骤102中获得第一关键信息的方式相同，在此不再赘述。

步骤104，根据第一关键信息和第二关键信息确定上述配置文件的升级情况。

具体地，根据第一关键信息和第二关键信息确定上述配置文件的升级情况可以为：如果第二关键信息中的第二版本号与第一关键信息中的第一版本号相同，或者第二关键信息中的第二版本号不是升级的目的版本号，则确定上述配置文件升级失败；或者，

如果第二关键信息中的第二版本号为升级的目的版本号，但第二关键信息中第二版本号所对应版本的升级时间不正确，则确定上述配置文件升级成功，但升级时间不正确；或者，

如果第二关键信息中的第二版本号为升级的目的版本号，并且第二关键信息中第二版本号所对应版本的升级时间正确，则确定上述配置文件升级成功，并且升级时间正确。

举例来说，假设配置文件的第一版本号为1.0，升级的目的版本号为1.3，如果第二版本号仍为1.0，则可以确定升级失败，未检测到升级；如果第二版本号为1.2，则可以确定升级失败，未升级到目的版本号。如果第二版本号为1.3，但是升级时间不准确(例如：7月6日升级的，显示升级时间为7月7日)，则可以确定升级成功，但升级时间不准确。只有当第二版本号为1.3，并且升级时间准确时，才可以确定升级成功，并且升级时间准确。

根据第一关键信息和第二关键信息确定上述配置文件的升级情况的一个实例可以如图3所示，图3为本发明配置文件的升级测试方法中确定升级情况一个实例的示意图。

上述配置文件的升级测试方法中，获得配置文件升级前后的关键信息之后，根据配置文件升级前后的关键信息确定配置文件的升级情况，从而实现了对配置文件的升级进行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效率。

进一步地，图4为本发明配置文件的升级测试方法另一个实施例的流程图，如图4所示，步骤104之后，还可以包括：

步骤401，在上述配置文件升级后，对上述应用的核心模块进行崩溃测试。

具体地，可以通过判定系统最上层的活动组件(activity)是否为对应核心模块的预定activity名称，来确定该核心模块是否崩溃。

举例来说，垃圾清理模块的activity名称为“com.cleanmaster.functionactivity.JunkManagerActivity”，此作为预期结果；然后通过adb命令打开上述垃圾清理模块，利用“shell dumpsys activity|grep‘mFocusedActivity”获取当前最上层的activity名称，作为实际结果；然后判断实际结果是否与预期结果一致，如果一致，则可以确定垃圾清理模块无崩溃；如果不一致，则可以确定垃圾清理模块崩溃。

上述方式仅为对上述应用的核心模块进行崩溃测试的一种示例，本实施例并不仅限于此，本实施例对进行崩溃测试所采用的方式不作限定，只要可以对上述应用的核心模块进行崩溃测试即可。

步骤402，将上述配置文件的升级情况，或者将上述配置文件的升级情况和上述应用的核心模块的崩溃测试结果存入数据库，并输出测试报告。

具体地，可以按照测试机型、测试时间、升级结果和/或崩溃情况等维度，将测试数据存入数据库，并输出Excel格式的测试报告，测试报告的一个示例可以如图5所示，图5为本发明配置文件的升级测试方法中测试报告一个示例的示意图。

当然，以上仅为测试报告的一个示例，本实施例对测试报告的格式不作限定，对测试报告所包含的维度也不作限定，只要包含配置文件的升级情况即可。

步骤403，对数据库中保存的测试报告进行数据分析，形成多种形式的报表。

具体地，可以从升级成功率、升级步调和/或升级稳定性等方面进行数据挖掘，以指导后续工作。

图6(a)～图6(b)为本发明配置文件的升级测试方法一个示例的逻辑示意图，图6(a)～图6(b)给出了本发明图1和图4提供的配置文件的升级测试方法的一个执行逻辑。

上述配置文件的升级测试方法可以应用在云端下发配置文件的测试场景中，实现了对配置文件升级的自动化测试，节约了人工成本，减少了人工比对的出错风险，从而降低了测试的出错率，并且提升了测试效率，良好的实时性检测和优雅的结果输出，可以第一时间反馈测试结果。另外，可以对数据进行持久化积累，为数据挖掘、数据分析和工作指导提供了基础数据。

图7为本发明配置文件的升级测试装置一个实施例的结构示意图，本实施例中的配置文件的升级测试装置可以作为测试服务器，或者测试服务器的一部分实现本发明图1所示实施例的流程，如图7所示，该配置文件的升级测试装置可以包括：获得模块71、解析模块72、触发模块73和确定模块74；

其中，获得模块71，用于获得启动的应用中的配置文件；具体地，获得模块71获得启动的应用中的配置文件可以为：通过shell命令将配置文件拷贝到本地PC上。举例来说，获得模块71可以通过以下命令将配置文件拷贝到PC上，“/data/data/com.cleanmaster.mguard/shared_prefs/com.cleanmaster.mguard.update.UpdateManager.xml”。

其中，“/data/”目录下的文件为手机系统保护文件，不能直接拷贝到PC上。获得模块71可以先通过cp命令将“/data/”目录下的文件拷贝到“/sdcard”根目录，再用adb pull命令拷贝到PC。

以上仅为获得模块71获得启动的应用中的配置文件的一种示例，本实施例并不仅限于此，本实施例对获得模块71获得启动的应用中的配置文件的方式不作限定。

解析模块72，用于对获得模块71获得的配置文件进行解析，获得上述配置文件的第一关键信息，上述第一关键信息包括上述配置文件的第一版本号和上述第一版本号所对应的版本的升级时间；本实施例中，解析模块72，具体用于加载自定义文件解析类，通过加载的自定义文件解析类对上述配置文件进行解析，获得上述配置文件的第一关键信息。其中，上述文件解析类，可以扩展，也可以根据不同的配置文件类型进行修订。另外，承载第一关键信息的关键字段也可以根据业务内容定制。

触发模块73，用于触发上述配置文件进行升级；具体地，触发模块73触发上述配置文件进行升级可以为：触发模块73通过点击某个按钮，进行下拉操作或者等待一段时间触发配置文件进行升级，本实施例对触发上述配置文件进行升级的方式不作限定。

这时，解析模块72，还用于在上述配置文件升级之后，获得升级后的配置文件的第二关键信息，上述第二关键信息包括升级后的配置文件的第二版本号和上述第二版本号所对应版本的升级时间；

确定模块74，用于根据解析模块72获得的第一关键信息和解析模块72获得的第二关键信息确定上述配置文件的升级情况。

本实施例中，确定模块74，具体用于当上述第二关键信息中的第二版本号与上述第一关键信息中的第一版本号相同，或者上述第二关键信息中的第二版本号不是升级的目的版本号时，确定上述配置文件升级失败；或者，当上述第二关键信息中的第二版本号为升级的目的版本号，但上述第二关键信息中上述第二版本号所对应版本的升级时间不正确时，确定上述配置文件升级成功，但升级时间不正确；或者，当上述第二关键信息中的第二版本号为升级的目的版本号，并且上述第二关键信息中所述第二版本号所对应版本的升级时间正确时，确定上述配置文件升级成功，并且升级时间正确。

举例来说，假设配置文件的第一版本号为1.0，升级的目的版本号为1.3，如果第二版本号仍为1.0，则确定模块74可以确定升级失败，未检测到升级；如果第二版本号为1.2，则确定模块74可以确定升级失败，未升级到目的版本号。如果第二版本号为1.3，但是升级时间不准确(例如：7月6日升级的，显示升级时间为7月7日)，则确定模块74可以确定升级成功，但升级时间不准确。只有当第二版本号为1.3，并且升级时间准确时，确定模块74才可以确定升级成功，并且升级时间准确。

具体地，确定模块74根据第一关键信息和第二关键信息确定上述配置文件的升级情况的一个实例可以如图3所示。

上述配置文件的升级测试装置中，解析模块72获得配置文件升级前后的关键信息之后，确定模块74根据配置文件升级前后的关键信息确定配置文件的升级情况，从而实现了对配置文件的升级进行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效率。

图8为本发明配置文件的升级测试装置另一个实施例的结构示意图，与图7所示的配置文件的升级测试装置相比，不同之处在于，图8所示的配置文件的升级测试装置还可以包括：

崩溃测试模块75，用于在上述配置文件升级后，对上述应用的核心模块进行崩溃测试。具体地，崩溃测试模块75可以通过判定系统最上层的活动组件(activity)是否为对应核心模块的预定activity名称，来确定该核心模块是否崩溃。

举例来说，垃圾清理模块的activity名称为“com.cleanmaster.functionactivity.JunkManagerActivity”，此作为预期结果；然后通过adb命令打开上述垃圾清理模块，利用“shell dumpsys activity|grep‘mFocusedActivity”获取当前最上层的activity名称，作为实际结果；然后判断实际结果是否与预期结果一致，如果一致，则崩溃测试模块75可以确定垃圾清理模块无崩溃；如果不一致，则崩溃测试模块75可以确定垃圾清理模块崩溃。

上述方式仅为崩溃测试模块75对上述应用的核心模块进行崩溃测试的一种示例，本实施例并不仅限于此，本实施例对崩溃测试模块75进行崩溃测试所采用的方式不作限定，只要可以对上述应用的核心模块进行崩溃测试即可。

进一步地，上述配置文件的升级测试装置还可以包括：

输出模块76，用于将上述配置文件的升级情况，或者将上述配置文件的升级情况和上述应用的核心模块的崩溃测试结果存入数据库，并输出测试报告。具体地，输出模块76可以按照测试机型、测试时间、升级结果和/或崩溃情况等维度，将测试数据存入数据库，并输出Excel格式的测试报告，测试报告的一个示例可以如图5所示。当然，以上仅为测试报告的一个示例，本实施例对测试报告的格式不作限定，对测试报告所包含的维度也不作限定，只要包含配置文件的升级情况即可。

另外，上述配置文件的升级测试装置还可以对数据库中保存的测试报告进行数据分析，形成多种形式的报表。具体地，可以从升级成功率、升级步调和/或升级稳定性等方面进行数据挖掘，以指导后续工作。

上述配置文件的升级测试装置可以应用在云端下发配置文件的测试场景中，实现了对配置文件升级的自动化测试，节约了人工成本，减少了人工比对的出错风险，从而降低了测试的出错率，并且提升了测试效率，良好的实时性检测和优雅的结果输出，可以第一时间反馈测试结果。另外，可以对数据进行持久化积累，为数据挖掘、数据分析和工作指导提供了基础数据。

需要说明的是，在本发明的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(Programmable Gate Array；以下简称：PGA)，现场可编程门阵列(Field ProgrammableGate Array；以下简称：FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (6)

1.一种配置文件的升级测试方法，其特征在于，包括：

获得启动的应用中的配置文件；

对所述配置文件进行解析，获得所述配置文件的第一关键信息，所述第一关键信息包括所述配置文件的第一版本号和所述第一版本号所对应的版本的升级时间；

触发所述配置文件进行升级，在所述配置文件升级之后，获得升级后的配置文件的第二关键信息，所述第二关键信息包括升级后的配置文件的第二版本号和所述第二版本号所对应版本的升级时间；

根据所述第一关键信息和所述第二关键信息确定所述配置文件的升级情况；

对所述应用的核心模块进行崩溃测试；

将所述配置文件的升级情况，或者将所述配置文件的升级情况和所述应用的核心模块的崩溃测试结果，按照测试机型、测试时间、升级结果和/或崩溃情况的维度存入数据库，并输出测试报告。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一关键信息和所述第二关键信息确定所述配置文件的升级情况包括：

如果所述第二关键信息中的第二版本号与所述第一关键信息中的第一版本号相同，或者所述第二关键信息中的第二版本号不是升级的目的版本号，则确定所述配置文件升级失败；或者，

如果所述第二关键信息中的第二版本号为升级的目的版本号，但所述第二关键信息中所述第二版本号所对应版本的升级时间不正确，则确定所述配置文件升级成功，但升级时间不正确；或者，

如果所述第二关键信息中的第二版本号为升级的目的版本号，并且所述第二关键信息中所述第二版本号所对应版本的升级时间正确，则确定所述配置文件升级成功，并且升级时间正确。

3.根据权利要求1或2所述的方法，其特征在于，所述对所述配置文件进行解析，获得所述配置文件的第一关键信息包括：

加载自定义文件解析类，通过加载的自定义文件解析类对所述配置文件进行解析，获得所述配置文件的第一关键信息。

4.一种配置文件的升级测试装置，其特征在于，包括：

获得模块，用于获得启动的应用中的配置文件；

解析模块，用于对所述获得模块获得的配置文件进行解析，获得所述配置文件的第一关键信息，所述第一关键信息包括所述配置文件的第一版本号和所述第一版本号所对应的版本的升级时间；

触发模块，用于触发所述配置文件进行升级；

所述解析模块，还用于在所述配置文件升级之后，获得升级后的配置文件的第二关键信息，所述第二关键信息包括升级后的配置文件的第二版本号和所述第二版本号所对应版本的升级时间；

确定模块，用于根据所述解析模块获得的所述第一关键信息和所述解析模块获得的所述第二关键信息确定所述配置文件的升级情况；

崩溃测试模块，用于在所述配置文件升级后，对所述应用的核心模块进行崩溃测试；

输出模块，用于将所述配置文件的升级情况，或者将所述配置文件的升级情况和所述应用的核心模块的崩溃测试结果，按照测试机型、测试时间、升级结果和/或崩溃情况的维度存入数据库，并输出测试报告。

5.根据权利要求4所述的装置，其特征在于，

所述确定模块，具体用于当所述第二关键信息中的第二版本号与所述第一关键信息中的第一版本号相同，或者所述第二关键信息中的第二版本号不是升级的目的版本号时，确定所述配置文件升级失败；或者，当所述第二关键信息中的第二版本号为升级的目的版本号，但所述第二关键信息中所述第二版本号所对应版本的升级时间不正确时，确定所述配置文件升级成功，但升级时间不正确；或者，当所述第二关键信息中的第二版本号为升级的目的版本号，并且所述第二关键信息中所述第二版本号所对应版本的升级时间正确时，确定所述配置文件升级成功，并且升级时间正确。

6.根据权利要求4或5所述的装置，其特征在于，

所述解析模块，具体用于加载自定义文件解析类，通过加载的自定义文件解析类对所述配置文件进行解析，获得所述配置文件的第一关键信息。