CN105608382A - 软件维护方法与软件问题判定方法以及其相应的装置 - Google Patents

Abstract

本发明涉及计算机软件安全检测和控制技术，具体而言，尤其涉及一种软件维护方法及其相应的装置，还涉及一种软件问题判定方法及其相应的装置。所述软件维护方法，包括以下步骤：获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据；依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求；接收该远程服务器推送的关联于该软件问题的升级包；以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。本发明利用因软件产生的日志数据进行统计学分析，辅以相关技术手段，可以有效实现软件的问题检测和自动升级维护。

Description

软件维护方法与软件问题判定方法以及其相应的装置

技术领域

本发明涉及计算机软件安全检测和控制技术，具体而言，尤其涉及一种软件维护方法及其相应的装置，还涉及一种软件问题判定方法及其相应的装置。

背景技术

计算机软件的漏洞或其他安全隐患甚至其他有关个性化体验隐患等问题的检测，有两种较为常见的方式，一种是在软件开发后期由程序员进行查漏，另一种是通过在软件中预置意见征集页面和功能模块来达到收集用户反馈的效果。实践中，前一种方式，局限于个别程序员的洞察力和测试手段，后一种方式的效果取决于用户的个人意愿，效果甚微。

一旦发现软件存在漏洞之类的问题，软件开发商如果能够及时发现，便可以及时修补漏洞或者改进程序，推出新版本加以替换，保护终端设备的安全，巩固软件的占有率。但是，上面的两种方式对于发现软件存在的漏洞和隐患的收效是不显著的，因而，依赖于传统的方式无法达到及时发现软件使用过程中产生的问题的目的。

具体到终端设备上，其应用程序繁多，同类软件的可替代性均非常高，并且，软件的版本更替也非常频繁，有时用户不胜其烦。频繁的软件更新对整个互联网的带宽消耗也是一种资源的浪费。因而，进一步带来的问题便是如何对软件存在的问题进行精准定位，在实现这种功能的前提下，便可更有针对性地对软件进行升级，以最小的升级流量来完成软件的有效更新。然而，由于现有技术中并不存在相对应的技术方案，故难以满足这种现实和潜在需求。

发明内容

本发明的首要目的旨在解决上述至少一个问题，提供一种软件维护方法及其相应的装置，以便在软件使用过程中及时发现其潜藏或存在的各类安全和非安全问题。

进一步，作为对上述首要目的的扩展，还期望实现对所述存在问题的软件的高效升级。

本发明的另一目的在于提供一种软件问题判定方法及其相应的装置，以便利用云端优势，为终端软件提供软件问题判定机制。

进一步，作为对上述另一目的的扩展，还期望实现引导解决存在问题的软件的便利升级。

为了实现上述各种目的，本发明相应采用如下各种技术方案：

本发明提供的一种软件维护方法，包括以下步骤：

获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据；

依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据；

通过解析所述结果数据确定相应的软件问题。

根据本发明的一个实施例所揭示，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的用户操作事件行为进行打点产生。

根据本发明的一个实施例所揭示，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的运行过程事件行为进行打点产生。

较佳的，所述日志数据按照属于其所属的宿主模块的事实属性进行归类，或按照不同的事件行为进行归类。

进一步，所述依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据的步骤，在本机中完成执行，或者提交到远程服务器执行并从该远程服务器获取相应的结果。

具体的，所述预设规则按照卡方检验法设置，在数学统计过程中按照如下子步骤处理：

利用预存储的大数据确定卡方检验法的理论频数，利用本机各类型日志数据确定相应的实际频数；

利用各类型实际频数分别与理论频数差值平方与理论频数之比的累计之和，确定实际频数对应的卡方值；

当所述卡方值与预定阈值不符时，判定本机软件存在该些类型对应的问题。

较佳的，所述软件问题至少包括如下两种定义任意之一：其一用于表征功能模块的使用率降低；其二用于表征功能模块的故障率提高。

进一步，本方法还包括如下步骤：

向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求；

接收该远程服务器推送的关联于该软件问题的升级包；

以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。

较佳的，所述升级包仅包含该软件所具有的部分功能模块相对应的替换文件。

较佳的，该软件的安装包采用分包安装技术封装，包含多个子包，所述升级包中包括与该安装包相对应的一个或多个子包。

可选的，以升级包的文件替换安装包的文件时，以静默或与用户交互的方式进行安装。

本发明提供的一种软件维护装置，包括：

获取单元，用于获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据；

统计单元，用于依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据；

判定单元，用于通过解析所述结果数据确定相应的软件问题。

根据本发明的一个实施例所揭示，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的用户操作事件行为进行打点产生。

根据本发明的一个实施例所揭示，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的运行过程事件行为进行打点产生。

较佳的，所述日志数据按照属于其所属的宿主模块的事实属性进行归类，或按照不同的事件行为进行归类。

较佳的，所述统计单元运行于本机中或者运行于远程服务器中，由本机提交到该远程服务器执行并从该远程服务器获取相应的结果。

进一步，所述预设规则按照卡方检验法设置，在所述统计单元中构造如下模块进行运行：

频数确定模块，被配置为利用预存储的大数据确定卡方检验法的理论频数，利用本机各类型日志数据确定相应的实际频数；

卡方值确定模块，被配置为利用各类型实际频数分别与理论频数差值平方与理论频数之比的累计之和，确定实际频数对应的卡方值；

判定模块，被配置为当卡方值与预定阈值不符时，判定本机软件存在该些类型对应的问题。

较佳的，所述软件问题至少包括以下两种定义任意之一：其一用于表征功能模块的使用率降低；其二用于表征功能模块的故障率提高。

进一步，本装置还包括如下单元：

请求单元，用于向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求；

接收单元，用于接收该远程服务器推送的关联于该软件问题的升级包；

升级单元，用于以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。

较佳的，所述升级包仅包含该软件所具有的部分功能模块相对应的替换文件。

具体的，该软件的安装包采用分包安装技术封装，包含多个子包，所述升级包中包括与该安装包相对应的一个或多个子包。

可选的，以升级包的文件替换安装包的文件时，以静默或与用户交互的方式进行安装。

本发明提供的一种软件问题判定方法，包括如下步骤：

接收请求判定软件问题的用户请求，从中解析出针对特定软件所产生日志数据而统计得出的若干问题类型日志数据的实际频数；

依据预设规则，从预设数据库的数据中确定属于该软件的理论频数，利用所述理论频数和实际频数，以卡方检验法计算得出该些问题类型的实际频数对应的卡方值；

在所述卡方值与预定阈值不符时，判定该软件存在该些类型相对应的问题，并反馈相对应的结果数据。

进一步，所述预设数据库中，包括有依据所述软件的若干历史版本在运行时产生的日志数据以卡方检验法统计而得的所述理论频数及相应的卡方值，以此作判定该软件是否存在该些类型相对应的问题时的预定阈值的比较基准。

具体的，该些问题类型的实际频数对应的卡方值的具体计算方式，在于依据该些实际频数与所述理论频数的差值平方与所述理论频数之比的累计之和而确定。

较佳的，所述预设数据库中包括有不同卡方值范围与软件问题具体性质之间对应关系的数据记录，其中的卡方值范围限定所述的预定阈值，通过查找该些数据记录确定相应的软件问题。

较佳的，在所反馈的结果数据中，包含用于升级所述软件的升级包的链接。

具体的，所述升级包仅包含用于局部替换所述软件的安装包的部分文件。

本发明提供的一种软件问题判定装置，包括：

请求接收单元，用于接收请求判定软件问题的用户请求，从中解析出针对特定软件所产生日志数据而统计得出的若干问题类型日志数据的实际频数；

远程统计单元，用于依据预设规则，从预设数据库的数据中确定属于该软件的理论频数，利用所述理论频数和实际频数，以卡方检验法计算得出该些问题类型的实际频数对应的卡方值；

远程判定单元，在所述卡方值与预定阈值不符时，判定该软件存在该些类型相对应的问题，并反馈相对应的结果数据。

进一步，所述预设数据库中，包括有依据所述软件的若干历史版本在运行时产生的日志数据以卡方检验法统计而得的所述理论频数及相应的卡方值，以此作判定该软件是否存在该些类型相对应的问题时的预定阈值的比较基准。

具体的，该些问题类型的实际频数对应的卡方值的具体计算方式，在于依据该些实际频数与所述理论频数的差值平方与所述理论频数之比的累计之和而确定。

较佳的，所述预设数据库中包括有不同卡方值范围与软件问题具体性质之间对应关系的数据记录，其中的卡方值范围限定所述的预定阈值，通过查找该些数据记录确定相应的软件问题。

较佳的，在所反馈的结果数据中，包含用于升级所述软件的升级包的链接。

较佳的，所述升级包仅包含用于局部替换所述软件的安装包的部分文件。

相比现有技术，本发明的方案具有以下优点：

1、本发明通过对软件自身产生的日志数据进行分析，利用数学功能对其进行统计，实现了利用日志数据分析判定软件安全问题和非安全问题的功能。程序员在进行程序开发时，可以在软件的各个功能模块中植入用于产生事件日志的代码，或者，由软件对操作系统的事件日志进行跟踪，将与本软件在时间上关联的事件日志进行数学统计，获得不同问题类型的日志数据的实际频数，通过本机或者远程服务器来对这些实际频数进行统计学上的分析，最终有利于确定产生该些日志数据的若干问题类型所对应的软件问题，这些问题显然包括但不限于软件自身存在的技术漏洞、安全和操作上的隐患以及用户体验问题等。由此可见，软件通过对日志数据这一常见数据类型的利用，可以用于判定自身存在的问题，以便后续反馈这些问题给有关方面，从而在技术上对该软件不断改进和完善。

2、进一步，本发明为存在问题的软件提供了技术上的更新方案，在判定软件存在问题之后，可以自动获取并下载升级包，对软件进行全面或者局部的升级，使得软件能够更为及时地得以修复，从而大大提高软件的安全性能。对于一些用户体验欠佳的软件，通过分析其日志数据的实际频数，也可以加以发现，随之推出新版本更新之，对提高软件的用户体验和用户粘性也奠定了坚实的基础。

3、本发明的实现思路以卡方检验法为基础，特别是适宜在远程服务器中加以实现，利用同一软件不同版本在海量的终端中安装运行时产生的软件数据，对这些数据进行深挖掘，可以获得更为有代表性的理论频数，当个别终端上运行的所述软件的某个版本的进程需要进行所述的问题判定时，运用卡方检验法，利用其产生各种问题类型的日志数据有关的实际频数与远程服务器上的理论频数之间的关系，便可确定相应的卡方值，继而在远程服务器的预设数据库中查询与该卡方值相对应的数据记录，便可以快速而又精准地确定相应的软件问题。甚至，进一步还可由服务器主动推送相关联的升级包，使所述的软件得以快速修改，显然，大大提高了软件智能化更新的便利度。

显然，上述有关本发明优点的描述是概括性的，更多的优点描述将体现在后续的实施例揭示中，以及，本领域技术人员也可以本发明所揭示的内容合理地发现本发明的其他诸多优点。

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

附图说明

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

图1为本发明一种软件维护方法的一个实施例的流程示意图；

图2为本发明一种软件问题判定方法的流程示意图；

图3为本发明的软件维护方法中的步骤S12的一个实施例的流程示意图；

图4为本发明一种软件维护方法的扩展实施例的流程示意图；

图5为本发明一种软件维护装置的一个实施例的结构示意图；

图6为本发明一种软件问题判定装置的结构示意图；

图7为本发明的软件维护装置中的统计单元12的一个实施例的结构示意图；

图8为本发明一种软件维护装置的扩展实施例的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(PersonalCommunicationsService，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(PersonalDigitalAssistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(GlobalPositioningSystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(MobileInternetDevice，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本技术领域技术人员可以理解，这里所使用的远端网络设备，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(CloudComputing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何通信方式实现通信，包括但不限于，基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。

需要指出的是，本发明的技术方案，理念上与操作系统的选型无关，对于windows、android、IOS等操作系统均适用。但为说明的便利，以下将主要以Android为例进行说明。

请参阅图1，本发明提供的一种软件维护方法，包括以下步骤：

步骤S11，获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据。

软件在开发时，可以植入产生日志数据的代码，或者，软件运行时，可以由操作系统监控软件的运行而产生对应于该软件运行过程所进行的操作而产生日志数据，无论何种方式产生日志数据，均与该软件在运行时的进程相关联。并且，以面向对象的设计原则中，这些日志数据通常是对应于不同事件行为而产生的。而且，软件的一种事件行为可能对应一种或多种问题类型，因此而产生一个或多个日志数据；同一份日志数据也可能对应于一个或多个事件行为而产生，而一份日志文件则通常表征一种问题类型。事件行为与问题类型、日志数据之间的对应关系，视彼此的公知的事实关系而定，为本领域技术人员所当然理解。所述的事件行为，可能是软件进程的生命周期内因为执行指令而触发的，也可能是受用户的操作而触发的。通常，以Android系统下的软件为例，一个软件包括多个功能模块，如Activity组件，一个Activity组件用于展示一个用户界面，其背后是相应的各类函数。该用户界面可以响应于用户操作而产生事件行为，其函数在运行时执行诸如调用接口函数或者各类资源时，也可产生所述的事件行为。本领域技术人员对此原理应当能予以理解，恕不赘述。

如前所述，所述日志数据的产生需要预先设置打点功能。一种方式中，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的用户操作事件行为进行打点产生。例如在上述的一个Activity组件的点击事件函数中写入实现日志数据打点的代码，在运行时，便可响应于对该用户界面的点击事件而产生一个预设了相对应的日志数据。另一种方式中，上述用于实现打点的代码预置于某些并非由系统定义的函数中，由技术人员灵活确定，使得所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的运行过程事件行为进行打点产生。例如，在一个后台功能模块中，当运行到特点指令之后即执行一次打点，产生相应的日志数据，起到类似于软件调试中的预设调试点的效果。

对所述问题类型的分类，可以依照一定的原则，由本领域技术人员灵活确定。例如，所述日志数据按照属于其所属的宿主模块的事实属性进行归类，由此，用于实现同一应用功能的若干个组件可以预置相同的打点代码，使得作用于该应用功能不同组件的操作事件可以产生相同的问题类型的日志数据，有利于通过多个相关组件确定某一应用功能是否存在某种问题，典型地如获知该应用功能的使用频度。又如，所述日志数据按照不同的事件行为进行归类，在不同的组件的相同事件行为中植入所述的同一打点代码，同理可以将问题类型与事件行为建立起对应性。本领域技术人员参照此处的揭示，足以知晓本步骤的具体实现。

步骤S12，依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据。

所述的日志数据，在计算机存储时，首先是以日志记录的方式存在的，可以存储于系统的日志数据库中，也可以存储于软件自行预置的日志文件中。通过对相应的数据库或文件的读取，可以获得包括问题类型与记录条数之类的日志数据。

本发明主要采用统计学上公知的卡方检验法对所述的日志数据进行数学处理，可以采用至少两种实施方式来实现本步骤，一种是通过远程服务器来实现，另一种则可在终端本机上执行实现。两种方式的原理相同，只是数据分布关系不同，也即视后述的用于进行统计决策的大数据特别是理论频数是存在于本机中还是存在于远程服务器而决定执行卡方检测法所在的空间位置。

对于前述的第一种方式，终端本机可以先行确定各问题类型日志数据的实际频数，利用这些信息打包成请求判定软件问题的用户请求，提交到远程服务器做统计学分析。

为此而引入揭示本发明的一种软件问题判定方法，以便实现所述的卡方检验法，具体对应于前述的第一种方式。如图2所示，该方法包括如下步骤：

步骤S21，接收请求判定软件问题的用户请求，从中解析出针对特定软件所产生日志数据而统计得出的若干问题类型日志数据的实际频数。

所述的用户请求被远程服务器接收后，远程服务器可以对应从中解析其中的实际频数信息，这些信息是对应于终端的特定软件的多个问题类型而统计得出的，因此具有针对性。对这些实际频数加以卡方检验，得出的结果数据自然是对应于所述特定软件的。

步骤S22，依据预设规则，从预设数据库的数据中确定属于该软件的理论频数，利用所述理论频数和实际频数，以卡方检验法计算得出该些问题类型的实际频数对应的卡方值。

所述的预设规则，便是依照卡方检验法所灵活确定的算法。所述预设数据库中，包括有依据所述软件的若干历史版本在运行时产生的日志数据以卡方检验法统计而得的所述理论频数及相应的卡方值，以此作判定该软件是否存在该些类型相对应的问题时的预定阈值的比较基准。所述预设数据库中包括有不同卡方值范围与软件问题具体性质之间对应关系的数据记录，其中的卡方值范围限定所述的预定阈值，通过查找该些数据记录确定相应的软件问题。应当注意的是，软件问题未必同于与日志数据相对应的所述问题类型，软件问题可以是程序员预先归类划分的各种不同性质的内容，当然也可以与所述问题类型存在逻辑上的关联性甚至具有相同的表述，但彼此不应混为一谈，软件问题表现在数据记录上是独立于所述的问题类型的。较佳的，所述软件问题至少包括如下两种定义任意之一：其一用于表征功能模块的使用率降低；其二用于表征功能模块的故障率提高。

所述诸多问题类型的实际频数对应的卡方值的具体计算方式，在于依据该些实际频数与所述理论频数的差值平方与所述理论频数之比的累计之和而确定。此一计算方式为卡方检验法的基本原理，实践中，可以灵活变通，对其中所用的参数、变量进行灵活设置。由此可见，远程服务器可以依据用户请求所包含的实际频数，结合采集和加工的大数据并以此确定的理论频数，将所述的实际频数转换为卡方值。

步骤S23，在所述卡方值与预定阈值不符时，判定该软件存在该些类型相对应的问题，并反馈相对应的结果数据。

如前所述，所述的预定阈值由所述预设数据库的大数据，也即预先从各终端采集的数据，计算出其正常的卡方值来确定，可以是一个具体的数值，也可以是一个数值范围，以此来框限依据实际频数所计算得出的卡方值所对应的软件问题。由此，利用依据实际频数计算得出的卡方值，便可在该数据库中查找出相对应的软件问题，这些软件问题对应于终端上产生的某些问题类型，远程服务器将这个软件问题的说明打包成结果数据，发送给终端，终端便可以据以进行后续处理。

以上的有关在远程服务器中实现卡方检验法的第一种方式，充分揭示了卡方检验法在本发明中的结合实现方式。而对于主要在终端本机中实现的第二种方式，主要也同于第一种方式，其异同之处说明如下：

终端本机中实现所述预设规则，同理按照卡方检验法设置。如图3所揭示，步骤S121，所述的大数据预存储在终端本机中，同理也已利用这些大数据确定了卡方检验法所需的理论频数，终端需要进行卡方检验时，即利用本机各类型日志数据确定相应的实际频数；继而，步骤S122，终端利用各类型实际频数分别与理论频数差值平方与理论频数之比的累计之和，确定实际频数对应的卡方值；最后，步骤S123，通过参照前述的第一种方式，查询本机预置的软件问题与卡方值之间的对应关系，当所述卡方值与预定阈值不符时，判定本机软件存在该些类型对应的问题,由此便可确定相应的软件问题，从而形成所述的结果数据。

由此可见，无论何种方式，终端均可获得相应的结果数据，这个结果数据中包含已经判定的相应的软件问题。

需要强调的是，与预定阈值不符，可以是依据实际频数确定的卡方值大于某一阈值也可以是小于某一阈值，或者大于或小于一个阈值范围。本领域技术人员应当知晓此一变通。

步骤S13，通过解析所述结果数据确定相应的软件问题。

由于所述结果数据包含了已经判定的软件问题，因此，可以进一步从所述结果数据中解析出该软件问题，并由终端据此按照默认设置或者与用户交互接收用户指令后，做进一步的处理。例如下载软件的升级包、显示软件类型的报告等。

进一步，可以为本发明的软件维护方法提供进一步的解决方案，解决其依据软件问题实现软件自动升级的问题，完成软件的智能维护。可以预见，这种方式适用于终端与远端服务器互相配合，由远端服务器完成卡方校验的情况。请参阅图4，具体体现在如下后续步骤：

步骤S14，向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求。

客户端确定软件存在特定问题之后，便可以向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求。需要注意的是，这里的远程服务器，不仅可以是前述用于实现卡方校验的远程服务器，也可以是第三方远程服务器，这里的服务器主要用于存储软件升级包并提供软件升级包的下载服务。

需要指出的是，有两种情况可以实现这种下载。其一是前述用于实现卡方校验的远程服务器在判定软件存在特定问题时，可以从其数据库预存的对应的软件升级包链接记录中，查找与该特定问题相对应的链接，并将该链接包含在所述反馈给终端的结果数据中，由终端接收该结果数据并解析出所述的链接，然后向升级包所在的远程服务器发起此一下载请求。另一种方式是终端的所述软件默认了存储软件升级包的远程服务器的接口，据此，通过该接口提交此一请求，存储软件升级包的远程服务器收到该请求后，即可据之确定软件问题及其对应的升级包。无论采用何种方式，均是本领域技术人员所知晓的惯用手段，能够实现依据一个下载请求而建立数据传输的方案。从而，存储软件升级包的远程服务器便能向该终端推送相应的升级包。

步骤S15，接收该远程服务器推送的关联于该软件问题的升级包。

继而，终端开始接收存储软件升级包的远程服务器推送的升级包数据，这一过程即公知技术中的下载的过程。需要指出的是，本发明中的软件的安装包适宜采用分包技术进行封装，分包时，可以针对软件的单个应用功能(功能模块)而设计独立的子包，使一个软件包含多个这样的子包，甚至可以将每个子包对应于一个活动组件(Activity)，具体视分包技术的需要而定。由此，软件的升级包可以是针对每个分包进行设计，精确对应到软件的功能模块或者对应到具体组件。安装包与升级包内部，均以文件的形式存在，因此，本质上，升级包仅包含用于局部替换安装包中的一部分文件的相对应替换文件。当然，一个升级包中也可以包含多个所述的子包，视导致软件问题的子包数量而定。确定一个软件问题后，存储软件升级包的远程服务器，可以根据软件问题而提供一个精确对应的升级包进行推送，终端由此接收到的升级包便是轻量型的，可以大大节约网络带宽和提高升级效率。

步骤S16，以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。

完成所述的软件升级包下载后，以分包技术相应的安装技术，安装所述的升级包，使得软件安装包中的部分涉及升级所需的文件被升级包中的相应文件所替换。具体而言，如Android的APK格式安装包，其中的代码文件classes.dex被分包为classes.dex_1,classes.dex_2……此外还包括配置文件Androidmanifest.ini，而升级包中包含了classes.dex_1与Androidmanifest.ini，则可以将这两个文件与安装包所包含的文件进行替换并重新签名，最终完成该安装包的重新打包和安装。

进而，基于软件的模块化思维，本发明对应上述各种方法提供若干种装置如下：

请参阅图5，本发明提供的一种软件维护装置，其包括获取单元11、统计单元12以及判定单元13，各单元所实现的功能概述如下：

所述的获取单元11，用于获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据。

软件在开发时，可以植入产生日志数据的代码，或者，软件运行时，可以由操作系统监控软件的运行而产生对应于该软件运行过程所进行的操作而产生日志数据，无论何种方式产生日志数据，均与该软件在运行时的进程相关联。并且，以面向对象的设计原则中，这些日志数据通常是对应于不同事件行为而产生的。而且，软件的一种事件行为可能对应一种或多种问题类型，因此而产生一个或多个日志数据；同一份日志数据也可能对应于一个或多个事件行为而产生，而一份日志文件则通常表征一种问题类型。事件行为与问题类型、日志数据之间的对应关系，视彼此的公知的事实关系而定，为本领域技术人员所当然理解。所述的事件行为，可能是软件进程的生命周期内因为执行指令而触发的，也可能是受用户的操作而触发的。通常，以Android系统下的软件为例，一个软件包括多个功能模块，如Activity组件，一个Activity组件用于展示一个用户界面，其背后是相应的各类函数。该用户界面可以响应于用户操作而产生事件行为，其函数在运行时执行诸如调用接口函数或者各类资源时，也可产生所述的事件行为。本领域技术人员对此原理应当能予以理解，恕不赘述。

如前所述，所述日志数据的产生需要预先设置打点功能。一种方式中，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的用户操作事件行为进行打点产生。例如在上述的一个Activity组件的点击事件函数中写入实现日志数据打点的代码，在运行时，便可响应于对该用户界面的点击事件而产生一个预设了相对应的日志数据。另一种方式中，上述用于实现打点的代码预置于某些并非由系统定义的函数中，由技术人员灵活确定，使得所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的运行过程事件行为进行打点产生。例如，在一个后台功能模块中，当运行到特点指令之后即执行一次打点，产生相应的日志数据，起到类似于软件调试中的预设调试点的效果。

对所述问题类型的分类，可以依照一定的原则，由本领域技术人员灵活确定。例如，所述日志数据按照属于其所属的宿主模块的事实属性进行归类，由此，用于实现同一应用功能的若干个组件可以预置相同的打点代码，使得作用于该应用功能不同组件的操作事件可以产生相同的问题类型的日志数据，有利于通过多个相关组件确定某一应用功能是否存在某种问题，典型地如获知该应用功能的使用频度。又如，所述日志数据按照不同的事件行为进行归类，在不同的组件的相同事件行为中植入所述的同一打点代码，同理可以将问题类型与事件行为建立起对应性。本领域技术人员参照此处的揭示，足以知晓本获取单元11的具体实现。

所述的统计单元12，依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据。

所述的日志数据，在计算机存储时，首先是以日志记录的方式存在的，可以存储于系统的日志数据库中，也可以存储于软件自行预置的日志文件中。通过对相应的数据库或文件的读取，可以获得包括问题类型与记录条数之类的日志数据。

本发明主要采用统计学上公知的卡方检验法对所述的日志数据进行数学处理，可以采用至少两种实施方式来实现本统计单元12，一种是通过远程服务器来实现，另一种则可在终端本机上执行实现。两种方式的原理相同，只是数据分布关系不同，也即视后述的用于进行统计决策的大数据特别是理论频数是存在于本机中还是存在于远程服务器而决定执行卡方检测法所在的空间位置。

对于前述的第一种方式，终端本机可以先行确定各问题类型日志数据的实际频数，利用这些信息打包成请求判定软件问题的用户请求，提交到远程服务器做统计学分析。

为此而引入揭示本发明的一种软件问题判定装置，以便实现所述的卡方检验法，具体对应于前述的第一种方式。如图6所示，该装置包括请求接收单元21、远程统计单元22以及远程判定单元23，各单元所实现的具体功能揭示如下：

所述的请求接收单元21，接收请求判定软件问题的用户请求，从中解析出针对特定软件所产生日志数据而统计得出的若干问题类型日志数据的实际频数。

所述的用户请求被远程服务器接收后，远程服务器可以对应从中解析其中的实际频数信息，这些信息是对应于终端的特定软件的多个问题类型而统计得出的，因此具有针对性。对这些实际频数加以卡方检验，得出的结果数据自然是对应于所述特定软件的。

所述的远程统计单元22，用于依据预设规则，从预设数据库的数据中确定属于该软件的理论频数，利用所述理论频数和实际频数，以卡方检验法计算得出该些问题类型的实际频数对应的卡方值。

所述的预设规则，便是依照卡方检验法所灵活确定的算法。所述预设数据库中，包括有依据所述软件的若干历史版本在运行时产生的日志数据以卡方检验法统计而得的所述理论频数及相应的卡方值，以此作判定该软件是否存在该些类型相对应的问题时的预定阈值的比较基准。所述预设数据库中包括有不同卡方值范围与软件问题具体性质之间对应关系的数据记录，其中的卡方值范围限定所述的预定阈值，通过查找该些数据记录确定相应的软件问题。应当注意的是，软件问题未必同于与日志数据相对应的所述问题类型，软件问题可以是程序员预先归类划分的各种不同性质的内容，当然也可以与所述问题类型存在逻辑上的关联性甚至具有相同的表述，但彼此不应混为一谈，软件问题表现在数据记录上是独立于所述的问题类型的。较佳的，所述软件问题至少包括如下两种定义任意之一：其一用于表征功能模块的使用率降低；其二用于表征功能模块的故障率提高。

所述诸多问题类型的实际频数对应的卡方值的具体计算方式，在于依据该些实际频数与所述理论频数的差值平方与所述理论频数之比的累计之和而确定。此一计算方式为卡方检验法的基本原理，实践中，可以灵活变通，对其中所用的参数、变量进行灵活设置。由此可见，远程服务器可以依据用户请求所包含的实际频数，结合采集和加工的大数据并以此确定的理论频数，将所述的实际频数转换为卡方值。

所述的远程判定单元23，用于在所述卡方值与预定阈值不符时，判定该软件存在该些类型相对应的问题，并反馈相对应的结果数据。

如前所述，所述的预定阈值由所述预设数据库的大数据，也即预先从各终端采集的数据，计算出其正常的卡方值来确定，可以是一个具体的数值，也可以是一个数值范围，以此来框限依据实际频数所计算得出的卡方值所对应的软件问题。由此，利用依据实际频数计算得出的卡方值，便可在该数据库中查找出相对应的软件问题，这些软件问题对应于终端上产生的某些问题类型，远程服务器将这个软件问题的说明打包成结果数据，发送给终端，终端便可以据以进行后续处理。

以上的有关在远程服务器中实现卡方检验法的第一种方式，充分揭示了卡方检验法在本发明中的结合实现方式。而对于主要在终端本机中实现的第二种方式，主要也同于第一种方式，其异同之处说明如下：

终端本机中实现所述预设规则，同理按照卡方检验法设置。如图7所示，所述的大数据预存储在终端本机中，同理也已利用这些大数据确定了卡方检验法所需的理论频数，终端需要进行卡方检验时，即利用本机各类型日志数据确定相应的实际频数，这部分功能由终端的统计单元12中构造的频数确定模块实现121；继而，终端借助其统计单元12构造的卡方值确定模块122，利用各类型实际频数分别与理论频数差值平方与理论频数之比的累计之和，确定实际频数对应的卡方值，最后，通过统计单元12构造的判定模块123参照前述的第一种方式，查询本机预置的软件问题与卡方值之间的对应关系，当所述卡方值与预定阈值不符时，判定本机软件存在该些类型对应的问题,由此便可确定相应的软件问题，从而形成所述的结果数据。

由此可见，无论何种方式，终端均可获得相应的结果数据，这个结果数据中包含已经判定的相应的软件问题。

需要强调的是，与预定阈值不符，可以是依据实际频数确定的卡方值大于某一阈值也可以是小于某一阈值，或者大于或小于一个阈值范围。本领域技术人员应当知晓此一变通。

所述的判定单元13，用于通过解析所述结果数据确定相应的软件问题。

由于所述结果数据包含了已经判定的软件问题，因此，可以进一步从所述结果数据中解析出该软件问题，并由终端据此按照默认设置或者与用户交互接收用户指令后，做进一步的处理。例如下载软件的升级包、显示软件类型的报告等。

进一步，可以为本发明的软件维护装置提供进一步的解决方案，解决其依据软件问题实现软件自动升级的问题，完成软件的智能维护。可以预见，这种方式适用于终端与远端服务器互相配合，由远端服务器完成卡方校验的情况。请参阅图8，所述软件维护装置具体体现在进一步包括请求单元14、接收单元15以及升级单元16，各单元所实现的功能体现如下：

所述的请求单元14，用于向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求。

客户端确定软件存在特定问题之后，便可以向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求。需要注意的是，这里的远程服务器，不仅可以是前述用于实现卡方校验的远程服务器，也可以是第三方远程服务器，这里的服务器主要用于存储软件升级包并提供软件升级包的下载服务。

需要指出的是，有两种情况可以实现这种下载。其一是前述用于实现卡方校验的远程服务器在判定软件存在特定问题时，可以从其数据库预存的对应的软件升级包链接记录中，查找与该特定问题相对应的链接，并将该链接包含在所述反馈给终端的结果数据中，由终端接收该结果数据并解析出所述的链接，然后向升级包所在的远程服务器发起此一下载请求。另一种方式是终端的所述软件默认了存储软件升级包的远程服务器的接口，据此，通过该接口提交此一请求，存储软件升级包的远程服务器收到该请求后，即可据之确定软件问题及其对应的升级包。无论采用何种方式，均是本领域技术人员所知晓的惯用手段，能够实现依据一个下载请求而建立数据传输的方案。从而，存储软件升级包的远程服务器便能向该终端推送相应的升级包。

所述的接收单元15，用于接收该远程服务器推送的关联于该软件问题的升级包。

继而，终端开始接收存储软件升级包的远程服务器推送的升级包数据，这一过程即公知技术中的下载的过程。需要指出的是，本发明中的软件的安装包适宜采用分包技术进行封装，分包时，可以针对软件的单个应用功能(功能模块)而设计独立的子包，使一个软件包含多个这样的子包，甚至可以将每个子包对应于一个活动组件(Activity)，具体视分包技术的需要而定。由此，软件的升级包可以是针对每个分包进行设计，精确对应到软件的功能模块或者对应到具体组件。安装包与升级包内部，均以文件的形式存在，因此，本质上，升级包仅包含用于局部替换安装包中的一部分文件的相对应替换文件。当然，一个升级包中也可以包含多个所述的子包，视导致软件问题的子包数量而定。确定一个软件问题后，存储软件升级包的远程服务器，可以根据软件问题而提供一个精确对应的升级包进行推送，终端由此接收到的升级包便是轻量型的，可以大大节约网络带宽和提高升级效率。

所述的升级单元16，用于以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。

完成所述的软件升级包下载后，以分包技术相应的安装技术，安装所述的升级包，使得软件安装包中的部分涉及升级所需的文件被升级包中的相应文件所替换。具体而言，如Android的APK格式安装包，其中的代码文件classes.dex被分包为classes.dex_1,classes.dex_2……此外还包括配置文件Androidmanifest.ini，而升级包中包含了classes.dex_1与Androidmanifest.ini，则可以将这两个文件与安装包所包含的文件进行替换并重新签名，最终完成该安装包的重新打包和安装。

综上所述，本发明利用因软件产生的日志数据进行统计学分析，辅以相关技术手段，可以有效实现软件的问题检测和自动升级维护。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种软件维护方法，其特征在于，包括以下步骤：

获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据；

依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据；

通过解析所述结果数据确定相应的软件问题。

2.根据权利要求1所述的方法，其特征在于，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的用户操作事件行为进行打点产生。

3.根据权利要求1所述的方法，其特征在于，所述日志数据具体依据针对该软件的不同功能页面相对应的功能模块的运行过程事件行为进行打点产生。

4.根据权利要求1所述的方法，其特征在于，所述日志数据按照属于其所属的宿主模块的事实属性进行归类，或按照不同的事件行为进行归类。

5.根据权利要求1所述的方法，其特征在于，所述预设规则按照卡方检验法设置，在数学统计过程中按照如下子步骤处理：

利用预存储的大数据确定卡方检验法的理论频数，利用本机各类型日志数据确定相应的实际频数；

利用各类型实际频数分别与理论频数差值平方与理论频数之比的累计之和，确定实际频数对应的卡方值；

当所述卡方值与预定阈值不符时，判定本机软件存在该些类型对应的问题。

6.根据权利要求1至5中任意一项所述的方法，其特征在于，本方法还包括如下步骤：

向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求；

接收该远程服务器推送的关联于该软件问题的升级包；

以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。

7.一种软件维护装置，其特征在于，包括：

获取单元，用于获取本软件的进程响应于不同事件行为产生的多种问题类型的日志数据；

统计单元，用于依据预设规则处理所述日志数据，使所述日志数据经数学统计获得相应的结果数据；

判定单元，用于通过解析所述结果数据确定相应的软件问题。

8.根据权利要求7所述的装置，其特征在于，本装置还包括如下单元：

请求单元，用于向远程服务器提交将下载与所确定的软件问题相对应的升级包的请求；

接收单元，用于接收该远程服务器推送的关联于该软件问题的升级包；

升级单元，用于以所述升级包的文件替换该软件的安装包中相对应的文件，完成该软件的升级。

9.一种软件问题判定方法，其特征在于，包括如下步骤：

接收请求判定软件问题的用户请求，从中解析出针对特定软件所产生日志数据而统计得出的若干问题类型日志数据的实际频数；

依据预设规则，从预设数据库的数据中确定属于该软件的理论频数，利用所述理论频数和实际频数，以卡方检验法计算得出该些问题类型的实际频数对应的卡方值；

在所述卡方值与预定阈值不符时，判定该软件存在该些类型相对应的问题，并反馈相对应的结果数据。

10.一种软件问题判定装置，其特征在于，包括：

请求接收单元，用于接收请求判定软件问题的用户请求，从中解析出针对特定软件所产生日志数据而统计得出的若干问题类型日志数据的实际频数；

远程统计单元，用于依据预设规则，从预设数据库的数据中确定属于该软件的理论频数，利用所述理论频数和实际频数，以卡方检验法计算得出该些问题类型的实际频数对应的卡方值；

远程判定单元，在所述卡方值与预定阈值不符时，判定该软件存在该些类型相对应的问题，并反馈相对应的结果数据。