本发明配置文件的升级测试装置一个实施例的结构示意图；
[0029] 图8为本发明配置文件的升级测试装置另一个实施例的结构示意图。
【具体实施方式】
[0030] 下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终 相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考 附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。相反， 本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同 物。
[0031] 图1为本发明配置文件的升级测试方法一个实施例的流程图，如图1所示，该配置 文件的升级测试方法可以包括：
[0032] 步骤101，获得启动的应用中的配置文件。
[0033] 进一步地，在步骤101之前，需要先安装App，然后启动App，使程序铺开配置文件。 具体地，可以通过Java遍历安装包目录，每次获取一个App，然后用adb命令进行安装。然 后可以通过"adb am start包名"这条命令启动安装的App，使程序铺开配置文件。
[0034] 具体地，获得启动的应用中的配置文件可以为：通过shell命令将配置文件拷贝 到本地个人计算机（Personal Computer;以下简称：PC)上。举例来说，可以通过以下命 令将配置文件拷贝到 PC 上，"/data/data/com. cleanmaster. mguard/shared_prefs/com. cleanmaster. mguard. update. UpdateManager. xml'，〇
[0035] 其中，"/data/"目录下的文件为手机系统保护文件，不能直接拷贝到PC上。可以 先通过cp命令将"/data/"目录下的文件拷贝到"/sdcard"根目录，再用adb pull命令拷 贝到PC。
[0036] 以上仅为获得启动的应用中的配置文件的一种示例，本实施例并不仅限于此，本 实施例对获得启动的应用中的配置文件的方式不作限定。
[0037] 步骤102,对上述配置文件进行解析，获得上述配置文件的第一关键信息，上述第 一关键信息包括上述配置文件的第一版本号和上述第一版本号所对应的版本的升级时间。
[0038] 具体地，对上述配置文件进行解析，获得上述配置文件的第一关键信息可以为：加 载自定义文件解析类，通过加载的自定义文件解析类对上述配置文件进行解析，获得上述 配置文件的第一关键信息。
[0039] 其中，上述文件解析类，可以扩展，也可以根据不同的配置文件类型进行修订。另 外，承载第一关键信息的关键字段也可以根据业务内容定制。
[0040] 例如，想解析下面一段中"Versi〇n_data"字段的内容，可以采用图2所示的方式 获得，图2为本发明配置文件的升级测试方法中获得第一关键信息的方式一个实施例的示 意图。
[0041]
[0042] 从图2中可以看出，获得的第一关键信息中包括第一版本号和第一版本号所对应 版本的升级时间等信息。
[0043] 步骤103,触发上述配置文件进行升级，在上述配置文件升级之后，获得升级后的 配置文件的第二关键信息，上述第二关键信息包括升级后的配置文件的第二版本号和上述 第二版本号所对应版本的升级时间。
[0044] 本实施例中，触发上述配置文件进行升级可以为：通过点击某个按钮，进行下拉操 作或者等待一段时间触发配置文件进行升级，本实施例对触发上述配置文件进行升级的方 式不作限定。
[0045] 具体地，本步骤中获得升级后的配置文件的第二关键信息的方式与步骤102中获 得第一关键信息的方式相同，在此不再赘述。
[0046] 步骤104,根据第一关键信息和第二关键信息确定上述配置文件的升级情况。
[0047] 具体地，根据第一关键信息和第二关键信息确定上述配置文件的升级情况可以 为：如果第二关键信息中的第二版本号与第一关键信息中的第一版本号相同，或者第二关 键信息中的第二版本号不是升级的目的版本号，则确定上述配置文件升级失败；或者，
[0048] 如果第二关键信息中的第二版本号为升级的目的版本号，但第二关键信息中第二 版本号所对应版本的升级时间不正确，则确定上述配置文件升级成功，但升级时间不正确； 或者，
[0049] 如果第二关键信息中的第二版本号为升级的目的版本号，并且第二关键信息中第 二版本号所对应版本的升级时间正确，则确定上述配置文件升级成功，并且升级时间正确。
[0050] 举例来说，假设配置文件的第一版本号为1.0,升级的目的版本号为1.3,如果第 二版本号仍为I. 〇,则可以确定升级失败，未检测到升级；如果第二版本号为I. 2,则可以确 定升级失败，未升级到目的版本号。如果第二版本号为1.3,但是升级时间不准确（例如：7 月6日升级的，显示升级时间为7月7日），则可以确定升级成功，但升级时间不准确。只有 当第二版本号为1. 3,并且升级时间准确时，才可以确定升级成功，并且升级时间准确。
[0051] 根据第一关键信息和第二关键信息确定上述配置文件的升级情况的一个实例可 以如图3所示，图3为本发明配置文件的升级测试方法中确定升级情况一个实例的示意图。
[0052] 上述配置文件的升级测试方法中，获得配置文件升级前后的关键信息之后，根据 配置文件升级前后的关键信息确定配置文件的升级情况，从而实现了对配置文件的升级进 行自动化测试，节约了人工成本，并降低了人工比对的出错率，提高了测试准确率和测试效 率。
[0053] 进一步地，图4为本发明配置文件的升级测试方法另一个实施例的流程图，如图4 所示，步骤104之后，还可以包括：
[0054] 步骤401，在上述配置文件升级后，对上述应用的核心模块进行崩溃测试。
[0055] 具体地，可以通过判定系统最上层的活动组件（activity)是否为对应核心模块 的预定activity名称，来确定该核心模块是否崩溃。
[0056] 举例来说，垃圾清理模块的activity名称为"com. cleanmaster. functionactivity. JunkManagerActivity"，此作为预期结果；然后通过adb命令打开上述 垃圾清理模块，利用 "shell dumpsys activity |grep 'mFocusedActivity" 获取当前最上 层的activity名称，作为实际结果；然后判断实际结果是否与预期结果一致，如果一致，则 可以确定垃圾清理模块无崩溃；如果不一致，则可以确定垃圾清理模块崩溃。
[0057] 上述方式仅为对上述应用的核心模块进行崩溃测试的一种示例，本实施例并不仅 限于此，本实施例对进行崩溃测试所采用的方式不作限定，只要可以对上述应用的核心模 块进行崩溃测试即可。
[0058] 步骤402,将上述配置文件的升级情况，或者将上述配置文件的升级情况和上述应 用的核心模块的崩溃测试结果存入数据库，并输出测试报告。
[0059] 具体地，可以按照测试机型、测试时间、升级结果和/或崩溃情况等维度，将测试 数据存入数据库，并输出Excel格式的测试报告，测试报告的一个示例可以如图5所示，图 5为本发明配置文件的升级测试方法中测试报告一个示例的示意图。
[0060] 当然，以上仅为测试报告的一个示例，本实施例对测试报告的格式不作限定，对测 试报告所包含的维度也不作限定，只要包含配置文件的升级情况即可。
[0061] 步骤403,对数据库中保存的测试报告进行数据分析，形成多种形式的报表。
[0062] 具体地，可以从升级成功率、升级步调和/或升级稳定性等方面进行数据挖掘，以 指导后续工作