CN104794049B - 应用程序测试方法和装置 - Google Patents

Abstract

本发明公开了一种应用程序测试方法和装置。该应用程序测试方法包括确定待测试应用程序的测试类型；获取与待测试应用程序的测试类型相应的测试用例；获取测试用例的工作流程；以及按照测试用例的工作流程对测试用例执行测试。通过本发明，解决了现有技术中对应用程序进行测试的准确性比较低的问题，进而达到了提高应用程序测试准确性的效果。

Description

应用程序测试方法和装置

技术领域

本发明涉及测试领域，具体而言，涉及一种应用程序测试方法和装置。

背景技术

在应用程序投放市场之前，往往需要对应用程序进行稳定性测试，以保证在应用程序投入市场之后在各种终端和***（例如Windows phone8）中稳定运行，避免出现程序错误。

现有技术中，通常随机模拟触发应用程序的使用过程，并对随机触发到的功能进行测试，但是，由于测试过程中的随机性导致无法对应用程序中的所有功能进行全面覆盖，使得应用程序的某些功能无法被测试到，从而导致测试结果不准确。

针对现有技术中对应用程序进行测试的准确性比较低的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例的主要目的在于提供一种应用程序测试方法和装置，以解决现有技术中现有技术中对应用程序进行测试的准确性比较低的问题。

为了实现上述目的，根据本发明实施例的一个方面，提供了一种应用程序测试方法。该方法包括：确定待测试应用程序的测试类型；获取与待测试应用程序的测试类型相应的测试用例；获取测试用例的工作流程；以及按照测试用例的工作流程对测试用例执行测试。

为了实现上述目的，根据本发明实施例的另一方面，提供了一种应用程序测试装置。该装置包括：第一确定单元，用于确定待测试应用程序的测试类型；第一获取单元，用于获取与待测试应用程序的测试类型相应的测试用例；第二获取单元，用于获取测试用例的工作流程；以及执行单元，用于按照测试用例的工作流程对测试用例执行测试。

通过本发明实施例，采用确定待测试应用程序的测试类型；获取与待测试应用程序的测试类型相应的测试用例；获取测试用例的工作流程；以及按照测试用例的工作流程对测试用例执行测试的方法，通过获取测试用例的工作流程，按照测试用例的工作流程进行测试，由于获取了测试用例的工作流程，并按照工作流程执行测试，按照测试用例的工作流程执行测试覆盖性更好，从而解决了现有技术中对应用程序进行测试的准确性比较低的问题，进而达到了提高应用程序测试准确性的效果。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的应用程序测试方法的流程图；

图2是根据本发明实施例的进行第一测试类型的测试方法的流程图；

图3是根据本发明实施例的进行第二测试类型的测试方法的流程图；

图4是根据本发明实施例的进行随机测试的测试方法的流程图；

图5是根据本发明实施例的应用程序测试装置的示意图；

图6是根据本发明实施例的进行第一测试类型的测试装置的示意图；以及

图7是根据本发明实施例的进行第二测试类型的测试装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例提供了一种应用程序测试方法。

图1是根据本发明实施例的应用程序测试方法的流程图。如图所示，该应用程序测试方法包括如下步骤：

步骤S101，确定待测试应用程序的测试类型。

在开发出应用程序之后，通常会对开发得到的应用程序进行稳定性测试，应用程序通过稳定性测试之后，该应用程序在投入市场之后才能在不同的***环境状态下稳定的运行。

待测试应用程序包括QQ浏览器、微信、QQ音乐等应用程序，但不限于这些应用程序，对应于与不同***的应用程序进行稳定性测试，例如对Windows phone8***中运行的QQ浏览器进行稳定性测试。

测试类型包括专项测试和随机性测试等测试类型，其中，专项测试是针对一个应用程序的一个功能进行的压力测试，随机性测试是针对一个应用程序进行的覆盖性测试，随机对应用程序的各个功能进行测试，从而获得一个应用程序的整体稳定性。

以QQ浏览器为例：

在进行QQ浏览器的稳定性测试时，可以针对包括多窗口、二维码、网页访问和导航、书签等功能进行测试，如果测试类型为专项测试，则针对上述多个功能中的任意一个功能进行专项测试，如果测试类型为随机测试，则针对上述多个功能中的每个功能进行随机测试。

通过专项测试可以测试应用程序在执行某一个功能时的占用内存情况、该功能的执行时间和是否与其他应用程序有冲突的问题，通过随机测试可以模拟自然情况下使用该应用程序时的占用内存情况、执行时间以及应用程序冲突的问题，根据测试结果对应用程序进行改进和优化，从而提高应用程序的稳定性。

步骤S102，获取与待测试应用程序的测试类型相应的测试用例。

测试用例包括模拟待测试应用程序的工作流程的程序，下面以QQ浏览器为例对该步骤进行说明：

对QQ浏览器进行专项测试：

进行专项测试的测试用例包括模拟QQ浏览器的使用过程，包括点击QQ浏览器图表打开浏览器、输入网址打开网页、调用菜单和调用书签等使用动作。如果对打开QQ浏览器的时间进行专项测试，可以调用该测试用例，并执行该测试用例，在模拟QQ浏览器打开浏览器的过程中，记录该打开浏览器动作的执行时间，通过反复打开QQ浏览器并记录打开QQ浏览器的时间，对记录的打开QQ浏览器的执行时间进行分析，并针对分析结果对应用程序或者测试用例进行优化。

需要说明的是，测试用例可以根据待测应用程序的功能进行调整，在对QQ浏览器进行专项测试的例子中，测试用例可以只记录触发图表打开QQ浏览器，触发关闭图表关闭QQ浏览器这个工作流程，还可以记录触发图表打开QQ浏览器，然后打开新的网页，最后关闭QQ浏览器这个工作流程，还可以是其他更复杂的工作流程。

对于记录触发图表打开QQ浏览器，然后打开新的网页，最后关闭QQ浏览器这个工作流程，除了可以对打开QQ浏览器的执行时间进行记录之外，还可以记录新网页的打开时间，并针对新网页的打开时间进行分析，并根据分析结果对应用程序或者测试用例进行优化。

从以上的说明可以看出，对于一个应用程序的一个功能进行专项测试可以利用一个进行专项测试的测试用例进行稳定性测试，对于一个进行专项测试的测试用例可以针对一个应用程序的一个或者多个功能进行稳定性测试。

对QQ浏览器进行随机测试：

进行随机测试的测试用例包括应用程序处于不同功能状态下的流程。QQ浏览器包括书签状态、历史状态和下载状态等状态，进行随机测试的测试用例包括书签状态、历史状态和下载状态等状态之间的跳转关系，例如，书签状态与历史状态之间的相互切换，历史状态与下载状态之间的相互切换，书签状态与下载状态之间的相互切换，利用该测试用例可以测试应用程序在不同功能状态下进行切换的占用内存情况、执行时间以及异常退出等非正常状态，并记录这些非正常的状态，根据记录的内容优化应用程序或者测试用例。

需要指出的是，对QQ浏览器进行随机测试的各种状态包括但不限于书签状态、历史状态和下载状态，这里只是为了举例说明，并不用于限制本发明实施例的技术方案。在下面的描述中还有对进行专项测试和随机测试的详细叙述，此处不做过多赘述。

步骤S103，获取测试用例的工作流程。

在获取与待测试应用程序的测试类型相应的测试用例之后，获取测试用例的工作流程，以按照测试用例的工作流程对测试用例进行测试。

测试用例的工作流程与应用程序的工作流程对应一致，测试用例模拟应用程序的工作流程，使得对测试用例的测试结果能够真实反映应用程序的性能，例如，应用程序出现异常或者占用内存过大。

针对一个应用程序的某个功能进行专项测试可以获取针对该专项测试的测试用例进行稳定性测试，针对多个功能进行的随机测试可以获取针对该随机测试的测试用例进行覆盖性测试。

进行专项测试的测试用例包括与专项测试对应的功能的工作流程，进行随机测得的测试用例包括与随机测试对应的多个功能之间跳转的工作流程。

步骤S104，按照测试用例的工作流程对测试用例执行测试。

每个测试用例都有其工作流程，按照其工作流程对测试用例执行测试，能够对测试用例中的所有节点进行测试，以避免出现漏测的情况。

进行专项测试的测试用例可以测试一个应用程序的某个功能的稳定性，进行随机测试的测试用例可以测试一个应用程序整体供能的稳定性，有更加广泛的覆盖性。通过专项测试可以判断一个应用程序的某个功能在运行过程中的占用内存情况、执行时间以及是否出现异常等情况，通过随机测试可以判断一个程序作为整体在进行功能切换时的占用内存情况、执行时间以及是否出现异常等情况，在执行测试用例进行测试时，可以记录测试结果，以便对测试结果进行分析。

通过本发明实施例的应用程序测试方法，采用确定待测试应用程序的测试类型；获取与待测试应用程序的测试类型相应的测试用例；获取测试用例的工作流程；以及按照测试用例的工作流程对测试用例执行测试的方法，通过获取测试用例的工作流程，按照测试用例的工作流程进行测试，由于获取了测试用例的工作流程，并按照工作流程执行测试，按照测试用例的工作流程执行测试覆盖性更好，从而提高了应用程序测试准确性的效果。进一步地，上述实施例提供的应用程序测试方法，通过对应用程序进行专项测试以获得应用程序的单一功能的稳定性，通过对应用程序进行随机测试以获得应用程序在功能切换时的稳定性，对应用程序或者测试用例进行优化。不论是专项测试还是随机测试，按照应用程序的工作流程进行的测试，因此，能够对该应用程序的所有功能进行覆盖测试，不会出现漏测的情况，以保证测试结果的准确性，为优化应用程序提供了准确可靠的依据，从而有效保证应用程序的稳定性，避免应用程序投入市场后出现不稳定的问题。

图2是根据本发明实施例的进行第一测试类型的测试方法的流程图。如图所示，在确定需测试应用程序的测试类型之前，该应用程序测试方法还包括如下步骤：

步骤S201，提示用户选择测试类型。

测试类型包括第一测试类型和第二测试类型，第一测试类型为图1所示实施例中提到的专项测试，第二测试类型为图1所示实施例中提到的随机测试。专项测试是针对一个应用程序的一个功能进行的压力测试，随机性测试是针对一个应用程序进行的覆盖性测试。

用户可以根据待测试应用程序的需要选择对待测试应用程序的某个功能进行专项测试，也可以对待测试应用程序的整体进行随机测试。

步骤S202，判断用户选择的测试类型是否是第一测试类型，其中，第一测试类型对应的测试为对应用程序的第一功能进行测试。

判断用户选择的测试类型为第一测试类型之后，利用第一测试类型对待测试应用程序的第一功能进行测试。这里的第一功能应该理解为待测试应用程序中的任一功能。

对QQ浏览器进行专项测试时，第一功能包括但不限于下述内容：多窗口、二维码、网页访问、程序窗口的导航和书签等。

对微信进行专项测试时，第一功能包括但不限于下述内容：通讯录、朋友圈、扫一扫、游戏中心等。

对QQ音乐进行专项测试时，第一功能包括但不限于下述内容：在线听歌、歌曲下载、桌面歌词等。

上述应用程序以及第一功能只是为了举例说明，应该理解的是，本发明实施例提供的测试方法还可以应用于其他相同或者等同的应用程序或者功能。

步骤S203，如果确定用户选择的测试类型是第一测试类型，则确定待测试应用程序的测试类型为第一测试类型。

确定待测试应用程序的测试类型为第一测试类型之后，按照第一测试类型获取测试用例，并根据获取到的测试用例进行相应的测试。

以下结合QQ浏览器中的二维码专项测试进行说明。

专项测试二维码验证使用二维码的过程是否会卡死，是否稳定。

首先，在确定对二维码的测试为专项测试之后，获取测试用例，然后按照获取的测试用例执行测试任务。其中，获取的测试用例包括执行二维码打开步骤和执行二维码退出步骤。在测试用例中还设置有时间值，设置的时间值为打开二维码和退出二维码的时间间隔，该时间值可以设置为50ms～1000ms之间的任一正整数，例如第一次打开二维码之后，间隔50ms退出二维码，再经过100ms重新打开二维码，再经过400ms关闭二维码，每次打开二维码和退出二维码的时间可以为50ms～1000ms之间的任一正整数，每个间隔时间可以相同或者不同。

以下结合QQ浏览器中页面访问的专项测试进行说明。

对页面访问的专项测试能够验证在访问页面时是否会出现卡死，测试访问页面时的内存占用率，以及是否会出现异常（例如退出程序）情况。

用于测试页面访问的测试用例包括测试用网页池，该网页池中包括白名单网址、站点导航网址、快速链接网址、书签和历史记录网址等。首先，利用该测试用例模拟新窗口打开、后台窗口打开、当前窗口打开等动作，如果利用该测试用例测试测试错误页面，在执行测试网页池中的任一网页之后，如果测试该网页的结果达到预定的结果，则从网页池中删除该网页，如果测试该网页的结果没有达到预定的结果，则保留该网页，并反复进行测试。

在测试的过程中记录占用内存轨迹、异常或者警告等情况，用于在任务结束之后对测试结果进行分析。当然，在测试过程中，如果发现内存占用过大或者异常情况过多可以随时终止或者暂停测试，在经过测试分析之后，可以停止当次测试或者在测试异常排除之后继续进行测试。

在对应用程序进行测试之后，记录测试日志，并对该测试日志进行分析，根据分析结果针对应用程序或者测试用例进行优化。

图3是根据本发明实施例的进行第二测试类型的测试方法的流程图。如图所示，在确定需测试应用程序的测试类型之前，该应用程序测试方法还包括如下步骤：

步骤S301，提示用户选择测试类型。

测试类型包括第一测试类型和第二测试类型，第一测试类型为图1所示实施例中提到的专项测试，第二测试类型为图1所示实施例中提到的随机测试。

用户可以根据待测试应用程序的需要选择对待测试应用程序的某个功能进行专项测试，也可以对待测试应用程序的整体进行随机测试，随机测试可以测试多个功能在切换过程中的占用内存情况或者切换异常等。

步骤S302，判断用户选择的测试类型是否是第二测试类型，其中，第二测试类型对应的测试为对应用程序进行覆盖性测试。

判断用户选择的测试类型为第二测试类型之后，利用第二测试类型对待测试应用程序进行覆盖性测试。这里的覆盖性测试理解为随机测试能够覆盖待测试应用程序中的所有功能，对每个功能都能进行测试。

步骤S303，如果确定用户选择的测试类型是第二测试类型，则确定待测试应用程序的测试类型为第二测试类型。

确定待测试应用程序的测试类型为第二测试类型之后，按照第二测试类型获取测试用例，并根据获取到的测试用例进行相应的测试。

确定待测试应用程序的测试类型为第二测试类型之后，对应用程序进行覆盖性测试的具体方法在下面的实施例中有详细描述，此处不做赘述。

进一步地，如果确定用户选择的测试类型是第二测试类型，按照所述测试用例的工作流程对所述测试用例执行测试包括：获取待测试应用程序的状态，判断待测试应用程序的状态是否为第一状态，如果确定待测试应用程序的状态为第一状态，则在第一状态下，随机执行第一事件，判断第一状态是否转换为第二状态，如果确定第一状态转换为第二状态，则随机执行第二事件。

本发明实施例中随机测试的过程如下：

应用程序启动时，有一个初始状态，然后随机执行某个事件，到达某个状态后，又随机执行某个事件。

本实施例中使用的目标应用程序是QQ浏览器，QQ浏览器一般分为但不局限于起始页面，网页页面，书签页面，历史页面，下载页面，设置页面，菜单页面，二维码页面等八个页面。起始页面一般是网址的快捷方式；网页页面一般是呈现网页本身；书签页面一般是存放用户保存的书签；历史页面记录着用户浏览过的网页；下载页面包括正在下载和已下载的内容；设置页面用于设置浏览器一些基本属性与功能；菜单页面包括菜单栏和网页长按菜单；二维码页面用于执行浏览器二维码功能。八个页面对应八个状态即初始状态，页面状态，书签状态，历史状态，下载状态，设置状态，菜单状态，二维码状态。在每个状态下，也有很多子状态，比如在页面状态下，就包括长按菜单状态、旋屏状态、全屏状态等，具体的子状态的测试逻辑和八大状态的处理逻辑一致，可以用本发明实施例提供的测试方法进行测试。通过模拟不同状态的切换过程，可以无限次对不同状态进行切换，并且在切换过程中保证不同状态都被覆盖，从而使得应用程序被全面测试，不遗漏任何一个功能。

进行随机测试的具体状态图如图4所示，图中选取了QQ浏览器的主要状态，而非全部状态，需要说明的是，这里的QQ浏览器只是方便对本发明实施例进行说明，并不限制本发明实施例仅用于QQ浏览器，还可以是其他浏览器客户端。

初始状态：通过点击应用软件图标启动应用程序，进入到浏览器初始状态，在初始状态下，用户可以通过点击网址快捷方式进入页面状态，可以通过输入框进入页面状态，用户点击工具栏可以进入到页面状态、书签状态、历史状态、下载状态、设置状态、菜单状态等状态。

页面状态：通过工具栏可以进入到起始状态、书签状态、历史状态、下载状态、设置状态、菜单状态等状态，如果窗口被全部关闭也直接进入初始状态。当然，在该状态下，可以进行一些状态内的操作，如打开新的链接，新建、关闭和切换窗口等。

书签状态：点击某个书签直接进入页面状态，点击同步书签按钮可以进入设置状态，当然可以在页面内执行书签管理的相关操作。执行返回操作可以回到初始状态或页面状态。

历史状态：点击某个历史记录进入页面状态，对某个历史记录进行长按，选择添加书签，则进入书签状态，执行返回操作可以回到初始状态或页面状态。

设置状态：该状态下主要是一些功能的选择与配置，如果点击用户反馈、产品介绍或在线更新则进入到页面状态。执行返回操作可以回到初始状态或页面状态。

下载状态：对下载进度与下载内容进行运行、查看和管理等。执行返回操作可以回到初始状态或页面状态。

菜单状态：点击二维码按钮，进入二维码状态。执行返回操作可以回到初始状态或页面状态。

二维码状态：执行返回操作可以回到初始状态或页面状态。

下面结合图4以初始状态、网页状态、菜单状态为例对随机测试进行说明。

步骤S1，判断当前状态。

步骤S2，判断当前状态是否为初始状态。

步骤S3，如果当前状态为初始状态，则选择初始状态下的下个流程对应的功能状态（例如菜单状态）进行测试。

步骤S4，在测试结束之后，将当前状态由初始状态修改为菜单状态，然后执行步骤S1，如果判断出当前的状态不是初始状态，则执行步骤S5。

步骤S5，判断当前状态是否为页面状态，如果当前状态是页面状态，则选择页面状态下的下个流程对应的功能状态进行测试，如果当前状态不是页面，则执行步骤S6。

步骤S6，判断当前状态是否为菜单状态，如果当前状态是菜单状态，则选择菜单状态下的下个流程对应的功能状态进行测试，如果当前状态不是页面，则执行其他步骤，此处省略其他流程的步骤。

随机测试可以随机对一个应用程序的功能进行测试，但是随机的过程模拟该应用程序自然执行时的流程进行测试，可以对应用程序的每个功能进行测试，从而遍历一个应用程序中的所有功能并进行测试，从而能够保证待测试应用程序的稳定性。

优选地，在按照所述测试用例的工作流程对所述测试用例执行测试之后，所述应用程序测试方法还包括：将按照所述测试用例的工作流程对所述测试用例执行测试得到的测试结果保存在待测试应用程序所处的终端内；从终端中导出测试结果；获取测试结果的分析结果；利用分析结果优化应用程序和/或测试用例。

在得到测试结果之后，将测试结果保存在待测试应用程序所处的终端内，并对测试结果进行分析，对测试结果进行分析的程序可以待测试应用程序以外的应用程序，通过终端中的程序对测试结果进行分析之后，从终端中导出分析结果，并根据分析结果对应用程序或者测试用例进行优化。

测试结果记录了应用程序在测试过程中出现异常或者占用内存过大，根据测试结果显示的问题对应用程序进行相应的优化，如果在测试过程中出现应用程序在长周期中无测试问题，则优化相应的测试用例，因此，可以根据测试结果优化应用程序或者测试用例，在二者都需要进行优化时则可以优化应用程序和测试用例。

在本发明实施例中，测试结果可以以日志的形式存在，日志可以分为以下几类：时间统计日志，内存统计日志，警告统计日志，页面访问日志，异常统计日志，特殊统计日志等。时间统计主要统计启动时间，页面切换时间，网页打开时间，一些特殊功能执行时间等；内存统计是指每隔1秒，输出当前应用程序耗费的内存。警告统计是指程序逻辑错误的地方；异常统计是指程序异常；页面访问是指页面访问的成功数；特殊统计是指需要对某个模块有单独的统计需求。

通过以上方法，可以对应用程序进行针对单一功能的专项测试，还可以针对整个应用程序的整体稳定性进行的随机测试，无论是专项测试还是随机测试，都按照测试用例的工作流程进行测试，可以测试用例中的所有功能，从而保证了应用程序的功能都能够被测得，进而提高了测试结果的准确性。

本发明实施例还提供了一种应用程序测试装置。

本发明实施例的应用程序测试方法可以通过本发明实施例所提供的应用程序测试装置来执行，本发明实施例的应用程序测试装置也可以用于执行本发明实施例所提供的应用程序测试方法。

图5是根据本发明实施例的应用程序测试装置的示意图。如图所示，该应用程序测试装置包括第一确定单元10、第一获取单元20、第二获取单元30和执行单元40。

第一确定单元10用于确定待测试应用程序的测试类型。

在开发出应用程序之后，通常会对开发得到的应用程序进行稳定性测试，应用程序通过稳定性测试之后，该应用程序在投入市场之后才能在不同的***环境状态下稳定的运行。

待测试应用程序包括QQ浏览器、微信、QQ音乐等应用程序，但不限于这些应用程序，对应于与不同***的应用程序进行稳定性测试，例如对Windows phone8***中运行的QQ浏览器进行稳定性测试。

测试类型包括专项测试和随机性测试等测试类型，其中，专项测试是针对一个应用程序的一个功能进行的压力测试，随机性测试是针对一个应用程序进行的覆盖性测试，随机对应用程序的各个功能进行测试，从而获得一个应用程序的整体稳定性。

以QQ浏览器为例：

在进行QQ浏览器的稳定性测试时，可以针对包括多窗口、二维码、网页访问和导航、书签等功能进行测试，如果测试类型为专项测试，则针对上述多个功能中的任意一个功能进行专项测试，如果测试类型为随机测试，则针对上述多个功能中的每个功能进行随机测试。

通过专项测试可以测试应用程序在执行某一个功能时的占用内存情况、该功能的执行时间和是否与其他应用程序有冲突的问题，通过随机测试可以模拟自然情况下使用该应用程序时的占用内存情况、执行时间以及应用程序冲突的问题，根据测试结果对应用程序进行改进和优化，从而提高应用程序的稳定性。

第一获取单元20用于获取与待测试应用程序的测试类型相应的测试用例。

测试用例包括模拟待测试应用程序的工作流程的程序，下面以QQ浏览器为例对该步骤进行说明：

对QQ浏览器进行专项测试：

进行专项测试的测试用例包括模拟QQ浏览器的使用过程，包括点击QQ浏览器图表打开浏览器、输入网址打开网页、调用菜单和调用书签等使用动作。如果对打开QQ浏览器的时间进行专项测试，可以调用该测试用例，并执行该测试用例，在模拟QQ浏览器打开浏览器的过程中，记录该打开浏览器动作的执行时间，通过反复打开QQ浏览器并记录打开QQ浏览器的时间，对记录的打开QQ浏览器的执行时间进行分析，并针对分析结果对应用程序或者测试用例进行优化。

需要说明的是，测试用例可以根据待测应用程序的功能进行调整，在对QQ浏览器进行专项测试的例子中，测试用例可以只记录触发图表打开QQ浏览器，触发关闭图表关闭QQ浏览器这个工作流程，还可以记录触发图表打开QQ浏览器，然后打开新的网页，最后关闭QQ浏览器这个工作流程，还可以是其他更复杂的工作流程。

对于记录触发图表打开QQ浏览器，然后打开新的网页，最后关闭QQ浏览器这个工作流程，除了可以对打开QQ浏览器的执行时间进行记录之外，还可以记录新网页的打开时间，并针对新网页的打开时间进行分析，并根据分析结果对应用程序或者测试用例进行优化。

从以上的说明可以看出，对于一个应用程序的一个功能进行专项测试可以利用一个进行专项测试的测试用例进行稳定性测试，对于一个进行专项测试的测试用例可以针对一个应用程序的一个或者多个功能进行稳定性测试。

对QQ浏览器进行随机测试：

进行随机测试的测试用例包括应用程序处于不同功能状态下的流程。QQ浏览器包括书签状态、历史状态和下载状态等状态，进行随机测试的测试用例包括书签状态、历史状态和下载状态等状态之间的跳转关系，例如，书签状态与历史状态之间的相互切换，历史状态与下载状态之间的相互切换，书签状态与下载状态之间的相互切换，利用该测试用例可以测试应用程序在不同功能状态下进行切换的占用内存情况、执行时间以及异常退出等非正常状态，并记录这些非正常的状态，根据记录的内容优化应用程序或者测试用例。

需要指出的是，对QQ浏览器进行随机测试的各种状态包括但不限于书签状态、历史状态和下载状态，这里只是为了举例说明，并不用于限制本发明实施例的技术方案。在下面的描述中还有对进行专项测试和随机测试的详细叙述，此处不做过多赘述。

第二获取单元30用于通过执行获取的测试用例进行测试，得到测试结果。

在获取与待测试应用程序的测试类型相应的测试用例之后，通过执行获取的测试用例进行测试。

对于一个应用程序的一个功能进行专项测试可以利用一个进行专项测试的测试用例进行稳定性测试，对于一个进行专项测试的测试用例可以针对一个应用程序的一个或者多个功能进行稳定性测试。

进行专项测试的测试用例可以测试一个应用程序的某个功能的稳定性，进行随机测试的测试用例可以测试一个应用程序整体供能的稳定性，有更加广泛的覆盖性。通过专项测试可以判断一个应用程序的某个功能在运行过程中的占用内存情况、执行时间以及是否出现异常等情况，通过随机测试可以判断一个程序作为整体在进行功能切换时的占用内存情况、执行时间以及是否出现异常等情况，在执行测试用例进行测试时，可以记录测试结果，以便对测试结果进行分析。

执行单元40用于利用测试结果优化应用程序和/或测试用例。

测试结果记录了应用程序在测试过程中出现异常或者占用内存过大，根据测试结果显示的问题对应用程序进行相应的优化，如果在测试过程中出现应用程序在长周期中无测试问题，则优化相应的测试用例，因此，可以根据测试结果优化应用程序或者测试用例，在二者都需要进行优化时则可以优化应用程序和测试用例。

通过本发明实施例的应用程序测试装置，由于获取了测试用例的工作流程，并按照工作流程执行测试，按照测试用例的工作流程执行测试覆盖性更好，从而提高了应用程序测试准确性的效果。进一步地，通过上述实施例提供的应用程序测试装置，通过对应用程序进行专项测试以获得应用程序的单一功能的稳定性，通过对应用程序进行随机测试以获得应用程序在功能切换时的稳定性，对应用程序或者测试用例进行优化。不论是专项测试还是随机测试，按照应用程序的工作流程进行的测试，因此，能够对该应用程序的所有功能进行覆盖测试，不会出现漏测的情况，以保证测试结果的准确性，为优化应用程序提供了准确可靠的依据，从而有效保证应用程序的稳定性，避免应用程序投入市场后出现不稳定的问题。

图6是根据本发明实施例的进行第一测试类型的测试装置的示意图。如图所示，该测试装置包括第一提示单元11、第一判断单元21和第二确定单元31。

第一提示单元11用于在确定待测试应用程序的测试类型之前，提示用户选择测试类型。测试类型包括第一测试类型和第二测试类型，第一测试类型为图1所示实施例中提到的专项测试，第二测试类型为图1所示实施例中提到的随机测试。

用户可以根据待测试应用程序的需要选择对待测试应用程序的某个功能进行专项测试，也可以对待测试应用程序的整体进行随机测试。

第一判断单元21用于判断用户选择的测试类型是否是第一测试类型，其中，第一测试类型对应的测试为对应用程序的第一功能进行测试。

判断用户选择的测试类型为第一测试类型之后，利用第一测试类型对待测试应用程序的第一功能进行测试。这里的第一功能应该理解为待测试应用程序中的任一功能。

对QQ浏览器进行专项测试时，第一功能包括但不限于下述内容：多窗口、二维码、网页访问、程序窗口的导航和书签等。

对微信进行专项测试时，第一功能包括但不限于下述内容：通讯录、朋友圈、扫一扫、游戏中心等。

对QQ音乐进行专项测试时，第一功能包括但不限于下述内容：在线听歌、歌曲下载、桌面歌词等。

上述应用程序以及第一功能只是为了举例说明，应该理解的是，本发明实施例提供的测试方法还可以应用于其他相同或者等同的应用程序或者功能。

第二确定单元31用于在确定用户选择的测试类型是第一测试类型时，确定待测试应用程序的测试类型为第一测试类型。

确定待测试应用程序的测试类型为第一测试类型之后，按照第一测试类型获取测试用例，并根据获取到的测试用例进行相应的测试。

以下结合QQ浏览器中的二维码专项测试进行说明。

专项测试二维码验证使用二维码的过程是否会卡死，是否稳定。

首先，在确定对二维码的测试为专项测试之后，获取测试用例，然后按照获取的测试用例执行测试任务。其中，获取的测试用例包括执行二维码打开步骤和执行二维码退出步骤。在测试用例中还设置有时间值，设置的时间值为打开二维码和退出二维码的时间间隔，该时间值可以设置为50ms～1000ms之间的任一正整数，例如第一次打开二维码之后，间隔50ms退出二维码，再经过100ms重新打开二维码，再经过400关闭二维码，每次打开二维码和退出二维码的时间可以为50ms～1000ms之间的任一正整数，每个间隔时间可以相同或者不同。

以下结合QQ浏览器中页面访问的专项测试进行说明。

对页面访问的专项测试能够验证在访问页面时是否会出现卡死，测试访问页面时的内存占用率，以及是否会出现异常（例如退出程序）情况。

用于测试页面访问的测试用例包括测试用网页池，该网页池中包括白名单网址、站点导航网址、快速链接网址、书签和历史记录网址等。首先，利用该测试用例模拟新窗口打开、后台窗口打开、当前窗口打开等动作，如果利用该测试用例测试测试错误页面，在执行测试网页池中的任一网页之后，如果测试该网页的结果达到预定的结果，则从网页池中删除该网页，如果测试该网页的结果没有达到预定的结果，则保留该网页，并反复进行测试。

在测试的过程中记录占用内存轨迹、异常或者警告等情况，用于在任务结束之后对测试结果进行分析。当然，在测试过程中，如果发现内存占用过大或者异常情况过多可以随时终止或者暂停测试，在经过测试分析之后，可以停止当次测试或者在测试异常排除之后继续进行测试。

在对应用程序进行测试之后，记录测试日志，并对该测试日志进行分析，根据分析结果针对应用程序或者测试用例进行优化。

图7是根据本发明实施例的进行第二测试类型的测试装置的示意图。如图所述，该测试装置包括第二提示单元21、第二判断单元22和第三确定单元23。

第二提示单元21用于在确定待测试应用程序的测试类型之前，提示用户选择测试类型。测试类型包括第一测试类型和第二测试类型，第一测试类型为图1所示实施例中提到的专项测试，第二测试类型为图1所示实施例中提到的随机测试。

用户可以根据待测试应用程序的需要选择对待测试应用程序的某个功能进行专项测试，也可以对待测试应用程序的整体进行随机测试，随机测试可以测试多个功能在切换过程中的占用内存情况或者切换异常等。

第二判断单元22用于判断用户选择的测试类型是否是第二测试类型，其中，第二测试类型对应的测试为对应用程序进行覆盖性测试。

判断用户选择的测试类型为第二测试类型之后，利用第二测试类型对待测试应用程序进行覆盖性测试。这里的覆盖性测试理解为随机测试能够覆盖待测试应用程序中的所有功能，对每个功能都能进行测试。

第三确定单元23用于在确定用户选择的测试类型是第二测试类型时，则确定待测试应用程序的测试类型为第二测试类型。

确定待测试应用程序的测试类型为第二测试类型之后，按照第二测试类型获取测试用例，并根据获取到的测试用例进行相应的测试。

确定待测试应用程序的测试类型为第二测试类型之后，对应用程序进行覆盖性测试的具体方法在下面的实施例中有详细描述，此处不做赘述。

进一步地，第二获取单元30包括获取模块、第一判断模块、第一执行模块、第二判断模块和第二执行模块。

获取模块用于在确定用户选择的测试类型是第二测试类型时，获取待测试应用程序的状态，第一判断模块用于判断待测试应用程序的状态是否为第一状态，第一执行模块用于在确定待测试应用程序的状态为第一状态时，在第一状态下，随机执行第一事件，第二判断模块，用于判断第一状态是否转换为第二状态，第二执行模块，用于在确定第一状态转换为第二状态，则随机执行第二事件。

本发明实施例中随机测试的过程如下：

应用程序启动时，有一个初始状态，然后随机执行某个事件，到达某个状态后，又随机执行某个事件。

本实施例中使用的目标应用程序是QQ浏览器，QQ浏览器一般分为但不局限于起始页面，网页页面，书签页面，历史页面，下载页面，设置页面，菜单页面，二维码页面等八个页面。起始页面一般是网址的快捷方式；网页页面一般是呈现网页本身；书签页面一般是存放用户保存的书签；历史页面记录着用户浏览过的网页；下载页面包括正在下载和已下载的内容；设置页面用于设置浏览器一些基本属性与功能；菜单页面包括菜单栏和网页长按菜单；二维码页面用于执行浏览器二维码功能。八个页面对应八个状态即初始状态，页面状态，书签状态，历史状态，下载状态，设置状态，菜单状态，二维码状态。在每个状态下，也有很多子状态，比如在页面状态下，就包括长按菜单状态、旋屏状态、全屏状态等，具体的子状态的测试逻辑和八大状态的处理逻辑一致，可以用本发明实施例提供的测试方法进行测试。通过模拟不同状态的切换过程，可以无限次对不同状态进行切换，并且在切换过程中保证不同状态都被覆盖，从而使得应用程序被全面测试，不遗漏任何一个功能。

进行随机测试的具体状态图如图4所示，图中选取了QQ浏览器的主要状态，而非全部状态，需要说明的是，这里的QQ浏览器只是方便对本发明实施例进行说明，并不限制本发明实施例仅用于QQ浏览器，还可以是其他浏览器客户端。

初始状态：通过点击应用软件图标启动应用程序，进入到浏览器初始状态，在初始状态下，用户可以通过点击网址快捷方式进入页面状态，可以通过输入框进入页面状态，用户点击工具栏可以进入到页面状态、书签状态、历史状态、下载状态、设置状态、菜单状态等状态。

页面状态：通过工具栏可以进入到起始状态、书签状态、历史状态、下载状态、设置状态、菜单状态等状态，如果窗口被全部关闭也直接进入初始状态。当然，在该状态下，可以进行一些状态内的操作，如打开新的链接，新建、关闭和切换窗口等。

书签状态：点击某个书签直接进入页面状态，点击同步书签按钮可以进入设置状态，当然可以在页面内执行书签管理的相关操作。执行返回操作可以回到初始状态或页面状态。

历史状态：点击某个历史记录进入页面状态，对某个历史记录进行长按，选择添加书签，则进入书签状态，执行返回操作可以回到初始状态或页面状态。

设置状态：该状态下主要是一些功能的选择与配置，如果点击用户反馈、产品介绍或在线更新则进入到页面状态。执行返回操作可以回到初始状态或页面状态。

下载状态：对下载进度与下载内容进行运行、查看和管理等。执行返回操作可以回到初始状态或页面状态。

菜单状态：点击二维码按钮，进入二维码状态。执行返回操作可以回到初始状态或页面状态。

二维码状态：执行返回操作可以回到初始状态或页面状态。

下面结合图4以初始状态、网页状态、菜单状态为例对随机测试进行说明。

步骤S1，第一判断模块判断当前状态。

步骤S2，第一判断模块判断当前状态是否为初始状态。

步骤S3，第一执行模块用于在当前状态为初始状态时，选择初始状态下的下个流程对应的功能状态（例如菜单状态）进行测试。

步骤S4，在测试结束之后，将当前状态由初始状态修改为菜单状态，然后执行步骤S1，如果判断出当前的状态不是初始状态，则执行步骤S5。

步骤S5，第二判断模块判断当前状态是否为页面状态，如果当前状态是页面状态，则选择页面状态下的下个流程对应的功能状态进行测试，如果当前状态不是页面，则执行步骤S6。

步骤S6，判断当前状态是否为菜单状态，如果当前状态是菜单状态，第二执行模块选择菜单状态下的下个流程对应的功能状态进行测试，如果当前状态不是页面，第二执行模块执行其他步骤，此处省略其他流程的步骤。

随机测试可以随机对一个应用程序的功能进行测试，但是随机的过程模拟该应用程序自然执行时的流程进行测试，可以对应用程序的每个功能进行测试，从而遍历一个应用程序中的所有功能并进行测试，从而能够保证待测试应用程序的稳定性。

优选地，应用程序测试装置包括：保存单元，用于在按照所述测试用例的工作流程对所述测试用例执行测试之后，将按照所述测试用例的工作流程对所述测试用例执行测试得到的测试结果保存在所述待测试应用程序所处的终端内，导出单元包括用于从终端中导出测试结果，第三获取单元，用于获取测试结果的分析结果，优化单元，用于利用分析结果优化测试用例。

在得到测试结果之后，将测试结果保存在待测试应用程序所处的终端内，并对测试结果进行分析，对测试结果进行分析的程序可以待测试应用程序以外的应用程序，通过终端中的程序对测试结果进行分析之后，从终端中导出分析结果，并根据分析结果对应用程序或者测试用例进行优化。

测试结果记录了应用程序在测试过程中出现异常或者占用内存过大，根据测试结果显示的问题对应用程序进行相应的优化，如果在测试过程中出现应用程序在长周期中无测试问题，则优化相应的测试用例，因此，可以根据测试结果优化应用程序或者测试用例，在二者都需要进行优化时则可以优化应用程序和测试用例。

在本发明实施例中，测试结果可以以日志的形式存在，日志可以分为以下几类：时间统计日志，内存统计日志，警告统计日志，页面访问日志，异常统计日志，特殊统计日志等。时间统计主要统计启动时间，页面切换时间，网页打开时间，一些特殊功能执行时间等；内存统计是指每隔1秒，输出当前应用程序耗费的内存。警告统计是指程序逻辑错误的地方；异常统计是指程序异常；页面访问是指页面访问的成功数；特殊统计是指需要对某个模块有单独的统计需求。

通过以上装置，可以对应用程序进行针对单一功能的专项测试，还可以针对整个应用程序的整体稳定性进行的随机测试，无论是专项测试还是随机测试，都按照测试用例的工作流程进行测试，可以测试用例中的所有功能，从而保证了应用程序的功能都能够被测得，进而提高了测试结果的准确性。

本发明实施例还提供了一种计算机存储介质。该计算机存储介质可存储有程序，该程序用于执行上述的应用程序测试方法中的部分或全部步骤。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种应用程序测试方法，其特征在于，包括：

确定待测试应用程序的测试类型，其中，所述测试类型包括第一测试类型和第二测试类型，所述第一测试类型对应的测试为针对所述应用程序的一个功能进行压力测试的专项测试，所述第二测试类型对应的测试为针对所述应用程序进行覆盖性测试，所述覆盖性测试为对所述应用程序中的每个功能进行随机测试；

获取与所述待测试应用程序的测试类型相应的测试用例；

获取所述测试用例的工作流程，其中，进行所述专项测试的测试用例包括与所述专项测试对应的功能的工作流程，进行所述随机测试的测试用例包括与所述随机测试对应的多个功能之间跳转的工作流程；以及

按照所述测试用例的工作流程对所述测试用例执行测试；

其中，在所述测试类型为第二测试类型时，所述按照所述测试用例的工作流程对所述测试用例执行测试包括：获取所述待测试应用程序的状态；判断所述待测试应用程序的状态是否为第一状态；如果确定所述待测试应用程序的状态为所述第一状态，则在所述第一状态下，随机执行第一事件；判断所述第一状态是否转换为第二状态；如果确定所述第一状态转换为所述第二状态，则随机执行第二事件。

2.根据权利要求1所述的应用程序测试方法，其特征在于，在确定待测试应用程序的测试类型之前，所述应用程序测试方法还包括：

提示用户选择测试类型；

判断用户选择的测试类型是否是所述第一测试类型，其中，所述第一测试类型对应的测试为对所述应用程序的第一功能进行测试；以及

如果确定用户选择的测试类型是所述第一测试类型，则确定待测试应用程序的测试类型为所述第一测试类型。

3.根据权利要求1所述的应用程序测试方法，其特征在于，在确定待测试应用程序的测试类型之前，所述应用程序测试方法还包括：

提示用户选择测试类型；

判断用户选择的测试类型是否是所述第二测试类型，其中，所述第二测试类型对应的测试为对所述应用程序进行覆盖性测试；以及

如果确定用户选择的测试类型是所述第二测试类型，则确定待测试应用程序的测试类型为所述第二测试类型。

4.根据权利要求1所述的应用程序测试方法，其特征在于，在按照所述测试用例的工作流程对所述测试用例执行测试之后，所述应用程序测试方法还包括：

将按照所述测试用例的工作流程对所述测试用例执行测试得到的测试结果保存在所述待测试应用程序所处的终端内；

从所述终端中导出所述测试结果；

获取所述测试结果的分析结果；以及

利用所述分析结果优化所述应用程序和/或所述测试用例。

5.一种应用程序测试装置，其特征在于，包括：

第一确定单元，用于确定待测试应用程序的测试类型，其中，所述测试类型包括第一测试类型和第二测试类型，所述第一测试类型对应的测试为针对所述应用程序的一个功能进行压力测试的专项测试，所述第二测试类型对应的测试为针对所述应用程序进行覆盖性测试，所述覆盖性测试为对所述应用程序中的每个功能进行随机测试；

第一获取单元，用于获取与所述待测试应用程序的测试类型相应的测试用例；

第二获取单元，用于获取所述测试用例的工作流程，其中，进行所述专项测试的测试用例包括与所述专项测试对应的功能的工作流程，进行所述随机测试的测试用例包括与所述随机测试对应的多个功能之间跳转的工作流程；以及

执行单元，用于按照所述测试用例的工作流程对所述测试用例执行测试；

其中，所述装置还用于：在所述测试类型为第二测试类型时，获取所述待测试应用程序的状态；判断所述待测试应用程序的状态是否为第一状态；如果确定所述待测试应用程序的状态为所述第一状态，则在所述第一状态下，随机执行第一事件；判断所述第一状态是否转换为第二状态；如果确定所述第一状态转换为所述第二状态，则随机执行第二事件。

6.根据权利要求5所述的应用程序测试装置，其特征在于，所述应用程序测试装置还包括：

第一提示单元，用于在确定待测试应用程序的测试类型之前，提示用户选择测试类型；

第一判断单元，用于判断用户选择的测试类型是否是所述第一测试类型，其中，所述第一测试类型对应的测试为对所述应用程序的第一功能进行测试；以及

第二确定单元，用于在确定用户选择的测试类型是所述第一测试类型时，确定待测试应用程序的测试类型为所述第一测试类型。

7.根据权利要求5所述的应用程序测试装置，其特征在于，所述应用程序测试装置还包括：

第二提示单元，用于在确定待测试应用程序的测试类型之前，提示用户选择测试类型；

第二判断单元，用于判断用户选择的测试类型是否是所述第二测试类型，其中，所述第二测试类型对应的测试为对所述应用程序进行覆盖性测试；以及

第三确定单元，用于在确定用户选择的测试类型是所述第二测试类型时，则确定待测试应用程序的测试类型为所述第二测试类型。

8.根据权利要求5所述的应用程序测试装置，其特征在于，所述应用程序测试装置还包括：

保存单元，用于在按照所述测试用例的工作流程对所述测试用例执行测试之后，将按照所述测试用例的工作流程对所述测试用例执行测试得到的测试结果保存在所述待测试应用程序所处的终端内；

导出单元，用于从所述终端中导出所述测试结果；

第三获取单元，用于获取所述测试结果的分析结果；以及

优化单元，用于利用所述分析结果优化所述应用程序和/或所述测试用例。