CN110515824A - 应用测试方法及装置 - Google Patents

Abstract

本说明书一个或多个实施例提供一种应用测试方法及装置，该方法可以包括：获取开发方发布的应用；当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

Description

应用测试方法及装置

技术领域

本说明书一个或多个实施例涉及应用测试技术领域，尤其涉及一种应用测试方法及装置。

背景技术

持续交付(Continuous Delivery)是一种DevOps(Development-Operations)方法论的软件开发实践。通过自动构建、部署、测试，可以将应用的代码快速、安全地部署到生产环境中。例如，在基于发布流水线的处理思路中，通过创建应用对应的发布流水线，可以将针对应用的发布流程划分为串联的若干发布阶段，从而实现对应用的快速、自动发布。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种应用测试方法及装置。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种应用测试方法，包括：

获取开发方发布的应用；

当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

根据本说明书一个或多个实施例的第二方面，提出了一种应用测试装置，包括：

获取单元，获取开发方发布的应用；

测试通知单元，当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

附图说明

图1是一示例性实施例提供的一种应用测试系统的架构示意图。

图2是一示例性实施例提供的一种应用测试方法的流程图。

图3是一示例性实施例提供的一种测试卡点配置界面的示意图。

图4是一示例性实施例提供的一种缺陷卡点配置界面的示意图。

图5是一示例性实施例提供的一种开发人员侧的发布监控界面的示意图。

图6是一示例性实施例提供的一种提测单查看界面的示意图。

图7是一示例性实施例提供的一种提测单展示界面的示意图。

图8是一示例性实施例提供的一种设备的结构示意图。

图9是一示例性实施例提供的一种应用测试装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

图1是一示例性实施例提供的一种应用测试系统的架构示意图。如图1所示，该系统可以包括服务器11、网络12、若干电子设备，比如该电子设备可以包括PC13、PC14。其中，服务器11在运行过程中，可以运行应用测试系统的服务端侧的程序，以实现相关的处理等功能；而PC13、PC14在运行过程中，可以运行应用测试系统的客户端侧的程序，以实现相关的展示、人机交互等功能，从而在服务器11与PC13、PC14之间配合实现该应用测试系统。

其中，服务器11可以为包含一独立主机的物理服务器，或者该服务器11可以为主机集群承载的虚拟服务器。电子设备除了上述的PC13、PC14之外，还可以包括下述其他类型的设备：手机、平板设备、笔记本电脑、掌上电脑(PDAs，Personal Digital Assistants)、可穿戴设备(如智能眼镜、智能手表等)等，本说明书一个或多个实施例并不对此进行限制。而对于PC13、PC14与服务器11之间进行交互的网络12，可以包括多种类型的有线或无线网络。在一实施例中，该网络12可以包括公共交换电话网络(Public Switched TelephoneNetwork，PSTN)和因特网。需要指出的是：应用测试系统的客户端的应用程序可以被预先安装在电子设备上，使得该客户端可以在该电子设备上被启动并运行；当然，当采用诸如HTML5技术的在线“客户端”时，无需在电子设备上安装相应的应用程序，即可获得并运行该客户端。

图2是一示例性实施例提供的一种应用测试方法的流程图。如图2所示，该方法可以包括以下步骤：

步骤202，获取开发方发布的应用。

步骤204，当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

在一实施例中，可以通过发布流水线的方式对应用进行发布。其中，发布流水线包括若干发布阶段，可以在至少一个发布阶段设置上述的测试卡点，以实现基于本说明书的协同方案。

在一实施例中，通过在应用的发布过程设置测试卡点，可以基于该测试卡点的触发条件的满足情况，自动向测试方发起测试通知，而无需开发方与测试方在线下沟通或告知，确保测试方能够及时对应用实施手工测试，实现了发布与手工测试之间的有效协同。例如，测试卡点的触发条件可以包括：应用在指定发布阶段(即运行环境)中构建完成、应用在指定发布阶段中部署成功等，可以根据实际情况或需求进行设定。

在一实施例中，可以自动创建提测单，所述提测单包含所述应用在发布过程中的上下文信息；然后，可以向所述测试方发送所述提测单，以实现上述的发起测试通知，使得测试方可以基于该提测单对应用实施测试。

在一实施例中，可以通过任意方式向测试方发送测试通知。例如，当采用如图1所示的系统架构时，可由服务器11向测试方使用的电子设备(该电子设备上登录有测试方的注册账号)发送该测试通知。再例如，可以通过如邮件、短信、即时通讯消息等方式向测试方发送测试通知，本说明书并不对此进行限制。

在一实施例中，提测单的内容可以包括以下至少之一：提测变更信息、提测需求信息、发布部署说明信息等，本说明书并不对此进行限制。

在一实施例中，所述提测单的至少一部分内容可以提取自所述应用的发布单，比如上述的提测变更信息、提测需求信息等。提测单的内容还可以来自应用的部署过程(或其他方面)，比如上述的发布部署说明信息等，本说明书并不对此进行限制。

在一实施例中，测试方可以为应用创建相应的测试计划，该测试计划包含若干测试用例，以使得测试方可以据此对该应用实施相应的测试。一种情况下，可以获取所述测试方预先创建的所述测试计划，所述测试计划被关联至所述应用；然后，根据所述测试计划与所述应用之间的关联关系，自动将所述测试计划绑定至所述提测单，使得测试方可以预先创建测试计划，有助于提升测试的效率。并且，基于测试计划与提测单之间的绑定关系，测试方可以基于提测单快速确定出所需采用的测试计划，无需费时寻找，同样有助于提升测试的效率。另一种情况下，可以在测试方获得应用的提测单之后，根据该提测单包含的上下文信息创建相应的测试计划，以用于对应用进行测试。

在一实施例中，测试卡点可以限制对应用的发布过程。例如，在所述测试卡点的通过条件未被满足时，阻止对所述应用进行继续发布；而当所述测试卡点的通过条件被满足时，允许对所述应用进行继续发布，从而通过测试卡点使得测试方的测试能够作用于应用的发布过程，使得应用的发布过程与测试之间建立起逻辑上的关联性、而并非完全独立的两个过程。例如，测试卡点的通过条件可以包括：测试完成(不考虑测试结果的内容)、测试结果未发现缺陷、测试结果不存在指定类型或指定优先级的缺陷等，可以根据实际情况或需求进行设定。

在一实施例中，测试卡点也可以不限制对应用的发布过程，比如在测试方实施测试的同时，该应用可以实施相应的发布过程，从而有助于提升效率。

在一实施例中，可以在应用的发布过程中设定质量卡点，以根据质量情况限制该应用的发布。例如，当所述应用的发布过程中存在预设的质量卡点，且所述质量卡点的通过条件未被满足时，阻止对所述应用进行继续发布；当所述质量卡点的通过条件被满足时，允许对所述应用进行继续发布。

在一实施例中，所述质量卡点的通过条件可以包括：所述应用不存在指定类型或指定优先级的质量缺陷。其中，所述质量缺陷可以包括以下至少之一：所述测试方对所述应用实施测试确定的新质量缺陷、所述应用先前遗留的历史质量缺陷。其中，质量卡点与测试卡点相配合，由测试方对应用进行测试得到的测试结果，确定该应用是否满足质量卡点的通过条件。

在一实施例中，当所述应用的发布过程运行至所述质量卡点处，且所述质量卡点的通过条件未被满足时，可以向所述开发方发起修复通知，以由所述开发方对所述应用进行修复更新。在完成修复更新后，可以重新向测试方发起测试通知，使得测试方针对修复更新后的应用进行测试，从而根据得到的测试结果确定该修复更新后的应用能否满足质量卡点的通过条件；经过一次或多次的修复更新后，直至最后一次修复更新后的应用满足质量卡点的通过条件。

为了便于理解，下面以在软件产品的发布过程中穿插测试任务为例，对本说明书一个或多个实施例的技术方案进行说明。假定软件产品为应用X，在应用X的开发过程中涉及到针对该应用X的发布与手工测试过程：例如用户A为应用X的开发人员、用于提供开发出的应用X的软件代码，用户B为应用X对应的测试人员、用于针对该应用X实施手工测试。在一实施例中，可以通过基于本说明书的应用管理系统，实现与该应用X相关的操作，以及实现本说明书的技术方案；例如，该应用管理系统可以运行于服务器中，并通过PC等电子设备向用户A、用户B等工作人员呈现相应的人机交互界面，以查看相关内容、实施相关操作等。

当应用X发生更新(比如基于新的开发需求、基于历史版本的缺陷修复等，本说明书并不对此进行限制)时，应用X的产品经理或项目经理或其他人员可以通过上述的应用管理系统对更新后的应用X设置相应的测试卡点，以实现开发人员用户A与测试人员用户B之间的协同处理。例如，图3是一示例性实施例提供的一种测试卡点配置界面的示意图；如图3所示，可以配置测试卡点所处的环境，比如“预发”、“日常”、“Beta”、“正式”等，譬如图3中选取了环境“日常”，使得应用X可以在该环境“日常”触发相应的手工测试过程。

在一实施例中，可以配置测试卡点的触发条件。如图3所示，备选的触发条件可以包括“构建完成”、“部署成功”等，本说明书并不对此进行限制。其中，“构建完成”表明应用X在环境“日常”(以图3中选取的环境“日常”进行举例说明)中完成“构建”阶段后，即可触发测试卡点，从而向用户B发起相应的测试通知，使得用户B实施手工测试。类似地，“部署成功”表明应用X在环境“日常”中完成“部署”阶段后，即可触发测试卡点，从而向用户B发起相应的测试通知，使得用户B实施手工测试。

在一实施例中，可以配置测试卡点是否作为流程卡点。如图3所示，当测试卡点被配置为流程卡点时，可以进一步配置该测试卡点的通过条件，比如该通过条件可以包括“测试完成”、“测试通过”等，使得该测试卡点被触发且通过条件尚未被满足之前，应用X的发布过程将暂停，直至该通过条件被满足后才能够继续发布。例如，当通过条件为“测试完成”时，在用户B对应用X的手工测试完成后即可认为该通过条件被满足；当通过条件为“测试通过”时，在用户B对应用X的手工测试完成后，需要进一步确定测试结果是否满足预定义条件，比如该预定义条件可以包括不存在缺陷、不存在指定类型或指定优先级的缺陷等，并在测试结果满足该预定义条件时才确定满足“测试通过”。当测试卡点未被配置为流程卡点(即选取图3中的“否”)时，该测试卡点仅用于对测试人员用户B发起测试通知，而不会限制应用X的发布过程。

图4是一示例性实施例提供的一种缺陷卡点配置界面的示意图；如图4所示，缺陷卡点也可以称为质量卡点，用于对应用X的代码质量进行监控管理；其中，与测试卡点相类似的，可以将该缺陷卡点配置为流程卡点，并配置相应的通过条件，比如该通过条件可以为“无P1缺陷(即不存在P1优先级的缺陷)”等，从而使得应用X的发布过程在该通过条件未被满足之前暂停，而在该通过条件被满足之后继续发布。以及，也可以将该缺陷卡点配置为非流程卡点，使得该缺陷卡点仅用于对应用X的代码质量进行监控，而不会限制应用X的发布过程。

在一实施例中，测试卡点与缺陷卡点可能存在一定关联。例如，测试卡点会触发提醒用户B对应用X实施手工测试，该手工测试的测试结果可能发现应用X存在一个或多个缺陷，也可能并未发现任何缺陷。那么，手工测试发现的缺陷，可能会分别导致测试卡点不满足“测试通过”、缺陷卡点不满足“无P1缺陷”；或者，也可能手工测试发现的缺陷会导致测试卡点不满足“测试通过”，但由于该缺陷的优先级并未达到P1级别，因而缺陷卡点可以满足“无P1缺陷”；或者，还可能存在其他情况，此处不再一一列举。

在一实施例中，测试卡点与缺陷卡点可能并无关联。例如，测试卡点会触发提醒用户B对应用X实施手工测试，但该手工测试的测试结果可能并未发现应用X的缺陷，因而测试卡点可以确认为“测试通过”。但是，应用X在此之前可能存在其他缺陷，关于这些缺陷是否已经被修复或仍然存在，可以通过缺陷卡点进行验证。

在一实施例中，在应用X不存在先前遗漏缺陷的情况下，可以仅设置测试卡点、无需设置缺陷卡点，既可以自动通知用户B对应用X实施手工测试，又可以通过对测试卡点的“通过条件”的合理配置，对手工测试得到的缺陷进行合理监控，比如将通过条件配置为“无P1缺陷”，即可实现与图4所示缺陷卡点类似的卡点效果。

假定针对应用X预先配置了如图3-4所示的测试卡点和缺陷卡点，而用户A可以正常发起对应用X的发布流程。图5是一示例性实施例提供的一种开发人员侧的发布监控界面的示意图。如图5所示，用户A可以在发布监控界面500中监控应用X的发布过程，比如应用X在环境“日常”中已经完成了“构建”、“发布准入”、“日常部署”等步骤。由于在如图3所示的实施例中，测试卡点的所处环境为“日常”、触发条件为“部署成功”，因而在“日常部署”步骤之后，该测试卡点被自动触发，以向作为测试人员的用户B发起测试通知。

在一实施例中，当检测到应用X在环境“日常”中满足触发条件“部署成功”时，应用管理系统可以自动确定针对该应用X的测试人员为用户B，并触发向用户B的测试通知。例如，应用管理系统可以自动生成针对该应用X的提测单，并将该提测单发送至用户B，使得用户B及时获知需要针对该应用X实施手工测试；或者，应用管理系统可以向用户B发送诸如“请针对应用X实施手工测试”等提示信息，使得用户B及时获知需要针对该应用X实施手工测试；或者，应用管理系统可以通过其他方式通知用户B对应用X实施手工测试，本说明书并不对此进行限制。其中，应用管理系统可以通过一种或多种渠道向用户B发起测试通知，比如应用管理系统内部的消息收发渠道，或者邮件、即时通讯应用、短信等外部渠道，本说明书并不对此进行限制。

以应用管理系统向用户B发送针对应用X的提测单为例。在如图5所示的发布监控界面500中，用户A可以确定应用X的发布过程已经中止于“提测”步骤，并且可以通过触发“查看提测单详情”选项，唤出如图6所示的提测单查看界面600，以针对该提测单的详情内容进行查看。另外，如果用户B长时间没有反馈手工测试的情况，用户A还可以通过手动触发发布监控界面500中的“重新提测”选项，重新向用户B发送提测单，从而重新向该用户B发起测试通知。

在一实施例中，提测单查看界面600可以包括该应用X在发布过程中的上下文信息，以便于用户B了解该应用X的情况。例如，该上下文信息可以包括如图6所示的“提测变更”信息、“提测需求”信息等，这些信息可以由应用管理系统从应用X的发布单中提取得到，以用于自动生成该提测单。以及，该上下文信息还可以包括“发布部署说明”等与部署相关的信息，或者还可以包括其他类型的信息，本说明书并不对此进行限制。

在一实施例中，用户B需要创建针对应用X的测试计划，从而根据该测试计划实施手工测试。例如，用户B在接收并查看到如图7所示的提测单展示界面700后，可以根据该提测单展示界面700示出的上下文信息，创建针对该应用X的测试计划，并通过提测单展示界面700内的“关联测试计划”选项，将该测试计划关联至该提测单，以使得该测试计划被应用于针对应用X实施手工测试。其中，测试计划中可以包括一个或多个测试用例，该测试用例为针对应用X的验证点，可以执行该验证点，并根据执行结果(执行成功或执行失败)来确定测试是否成功。

除了根据提测单展示界面700创建测试计划并手动关联至应用X之外，用户B可以预先创建测试计划，并声明该测试计划与应用X之间的关联关系，比如将测试计划与应用X的ID、代码地址等进行关联，使得应用管理系统自动创建出针对应用X的提测单后，可以根据该关联关系自动将测试计划与该提测单进行绑定，而无需用户B实施手动绑定。

在一实施例中，通过测试计划对应用X进行手工测试得到相应的测试结果，并根据该测试结果对测试卡点的通过条件的满足情况，确定是否能够通过测试卡点；以及，根据应用X所包含缺陷的情况(来自测试结果或者历史缺陷)，确定其对于缺陷卡点的通过条件的满足情况，从而确定是否能够通过缺陷卡点。

在一实施例中，当测试卡点或缺陷卡点未能顺利通过时，应用管理系统可以向作为开发人员的用户A发起修复通知，以由用户A针对应用X所存在的问题进行修复更新。在完成修复后，用户A可以提交修复后的应用X；其中，用户A可以针对该修复后的应用X向用户B重新发起提测，或者由应用管理系统在收到修复后的应用X后自动向用户B重新发起提测，以由用户B重新实施手工测试，从而确定先前的问题是否已经被解决，测试卡点和缺陷卡点是否可以正常通过。

图8是一示例性实施例提供的一种设备的示意结构图。请参考图8，在硬件层面，该设备包括处理器802、内部总线804、网络接口806、内存808以及非易失性存储器810，当然还可能包括其他业务所需要的硬件。处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行，在逻辑层面上形成应用测试装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图9，在软件实施方式中，该应用测试装置可以包括：

获取单元91，获取开发方发布的应用；

测试通知单元92，当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

可选的，

还包括：创建单元93，创建提测单，所述提测单包含所述应用在发布过程中的上下文信息；

所述测试通知单元92具体用于：向所述测试方发送所述提测单。

可选的，所述提测单的内容包括以下至少之一：提测变更信息、提测需求信息、发布部署说明信息。

可选的，所述提测单的至少一部分内容提取自所述应用的发布单。

可选的，还包括：

测试计划获取单元94，获取所述测试方预先创建的所述测试计划，所述测试计划被关联至所述应用；

绑定单元95，根据所述测试计划与所述应用之间的关联关系，将所述测试计划绑定至所述提测单。

可选的，还包括：

第一发布管理单元96，在所述测试卡点的通过条件未被满足时，阻止对所述应用进行继续发布；在所述测试卡点的通过条件被满足时，允许对所述应用进行继续发布。

可选的，还包括：

第二发布管理单元97，在所述应用的发布过程中存在预设的质量卡点，且所述质量卡点的通过条件未被满足时，阻止对所述应用进行继续发布；在所述质量卡点的通过条件被满足时，允许对所述应用进行继续发布。

可选的，所述质量卡点的通过条件包括：所述应用不存在指定类型或指定优先级的质量缺陷。

可选的，所述质量缺陷包括以下至少之一：所述测试方对所述应用实施测试确定的新质量缺陷、所述应用先前遗留的历史质量缺陷。

可选的，还包括：

修复通知单元98，在所述应用的发布过程运行至所述质量卡点处，且所述质量卡点的通过条件未被满足时，向所述开发方发起修复通知，以由所述开发方对所述应用进行修复更新。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (20)

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

获取开发方发布的应用；

当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

2.根据权利要求1所述的方法，其特征在于，

还包括：创建提测单，所述提测单包含所述应用在发布过程中的上下文信息；

所述向所述应用的测试方发起测试通知，包括：向所述测试方发送所述提测单。

3.根据权利要求2所述的方法，其特征在于，所述提测单的内容包括以下至少之一：提测变更信息、提测需求信息、发布部署说明信息。

4.根据权利要求2所述的方法，其特征在于，所述提测单的至少一部分内容提取自所述应用的发布单。

5.根据权利要求2所述的方法，其特征在于，还包括：

获取所述测试方预先创建的所述测试计划，所述测试计划被关联至所述应用；

根据所述测试计划与所述应用之间的关联关系，将所述测试计划绑定至所述提测单。

6.根据权利要求1所述的方法，其特征在于，还包括：

在所述测试卡点的通过条件未被满足时，阻止对所述应用进行继续发布；

在所述测试卡点的通过条件被满足时，允许对所述应用进行继续发布。

7.根据权利要求1所述的方法，其特征在于，还包括：

在所述应用的发布过程中存在预设的质量卡点，且所述质量卡点的通过条件未被满足时，阻止对所述应用进行继续发布；

在所述质量卡点的通过条件被满足时，允许对所述应用进行继续发布。

8.根据权利要求7所述的方法，其特征在于，所述质量卡点的通过条件包括：所述应用不存在指定类型或指定优先级的质量缺陷。

9.根据权利要求8所述的方法，其特征在于，所述质量缺陷包括以下至少之一：所述测试方对所述应用实施测试确定的新质量缺陷、所述应用先前遗留的历史质量缺陷。

10.根据权利要求7所述的方法，其特征在于，还包括：

在所述应用的发布过程运行至所述质量卡点处，且所述质量卡点的通过条件未被满足时，向所述开发方发起修复通知，以由所述开发方对所述应用进行修复更新。

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

获取单元，获取开发方发布的应用；

测试通知单元，当所述应用的发布过程中存在预设的测试卡点，且所述测试卡点的触发条件被满足时，向所述应用的测试方发起测试通知，以由所述测试方对所述应用实施测试。

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

还包括：创建单元，创建提测单，所述提测单包含所述应用在发布过程中的上下文信息；

所述测试通知单元具体用于：向所述测试方发送所述提测单。

13.根据权利要求12所述的装置，其特征在于，所述提测单的内容包括以下至少之一：提测变更信息、提测需求信息、发布部署说明信息。

14.根据权利要求12所述的装置，其特征在于，所述提测单的至少一部分内容提取自所述应用的发布单。

15.根据权利要求12所述的装置，其特征在于，还包括：

测试计划获取单元，获取所述测试方预先创建的所述测试计划，所述测试计划被关联至所述应用；

绑定单元，根据所述测试计划与所述应用之间的关联关系，将所述测试计划绑定至所述提测单。

16.根据权利要求11所述的装置，其特征在于，还包括：

第一发布管理单元，在所述测试卡点的通过条件未被满足时，阻止对所述应用进行继续发布；在所述测试卡点的通过条件被满足时，允许对所述应用进行继续发布。

17.根据权利要求11所述的装置，其特征在于，还包括：

第二发布管理单元，在所述应用的发布过程中存在预设的质量卡点，且所述质量卡点的通过条件未被满足时，阻止对所述应用进行继续发布；在所述质量卡点的通过条件被满足时，允许对所述应用进行继续发布。

18.根据权利要求17所述的装置，其特征在于，所述质量卡点的通过条件包括：所述应用不存在指定类型或指定优先级的质量缺陷。

19.根据权利要求18所述的装置，其特征在于，所述质量缺陷包括以下至少之一：所述测试方对所述应用实施测试确定的新质量缺陷、所述应用先前遗留的历史质量缺陷。

20.根据权利要求17所述的装置，其特征在于，还包括：

修复通知单元，在所述应用的发布过程运行至所述质量卡点处，且所述质量卡点的通过条件未被满足时，向所述开发方发起修复通知，以由所述开发方对所述应用进行修复更新。