一种新应用的测试方法及装置与流程

本发明涉及应用测试的技术领域，尤其涉及对预上线的新应用进行测试的技术。

背景技术：

日常互联网检索服务，均以接口的形式向服务端发送请求，拿到返回结果后，经过一定的处理呈现给用户。

现有移动端测试方案，不论是移动端前端功能的变更，还是服务端的变更对移动端的影响，都是通过在手机移动端对变更后的应用进行测试，通过界面测试，需要手动遍历各个场景，多靠手动测试完成，其测试效率及准确性有待提升。并且回归测试案例一般是结合具体功能构造测试数据，而非用户的真实数据，测试结果可能存在遗漏，因此也无法确定该新应用是否兼容原应用上的已有功能。

针对服务接口变更频繁，为了保证新服务的测试质量，可以通过对新老服务返回结果进行diff测试，可以快速准确的保证新服务的更新，没有影响到线上的老功能。

技术实现要素：

本发明实施例提出了解决上述对待上线新应用进行测试时存在问题的技术方案，提供一种对新应用及原应用同时进行测试，并通过比较测试结果判定新应用是否兼容原应用的技术方案。

在一个方面，本发明实施例提供了一种新应用的测试方法，包括：

在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试环境；

向所述两台测试终端上的应用发送相同的用户请求；

比较所述新应用的测试结果与原应用的测试结果是否一致，若一致则所述新应用通过测试。

进一步地，所述在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试环境包括：在其中一台测试终端上安装新应用，在另一台上安装原应用，并将所述应用中的待测试功能相关参数设置一致。

进一步地，所述用户请求为获取的用户向线上应用发送的请求。

进一步地，所述比较所述新应用的测试结果与原应用的测试结果是否一致包括：比较两种测试结果的展现内容及展现方式是否一致。

进一步地，所述比较测试结果是否一致的具体方法为，对两台测试终端展现的测试结果进行截图，比较两个截图的相似度，当其相似度到达一定阈值时，则认为测试结果一致，若一致说明新应用的该功能兼容原应用的该功能。

在另一个方面，本发明实施例提供了一种新应用的测试装置，所述装置包括：部署模块、发送模块、结果获取模块、测试模块及比较模块；

所述部署模块，用于在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试模块；

所述发送模块，用于向测试新应用的测试模块及测试原应用的测试模块发送相同的用户请求；

所述结果获取模块，用于从测试模块获取所述新应用及原应用的测试结果；

所述比较模块，用于比较所述新应用的测试结果与原应用的测试结果是否一致，若一致则所述新应用通过测试。

所述部署模块在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试模块包括：测试模块一，在其中一台测试终端上安装新应用，测试模块二，在另一台上安装原应用，并将所述应用中的待测试功能相关参数设置一致。

进一步地，所述装置还包括请求抓取模块，用于抓取测试请求，所述测试请求为用户向线上应用发送的请求。

进一步地，所述比较模块比较所述新应用的测试结果与原应用的测试结果是否一致包括：比较两种测试结果的展现内容及展现方式是否一致。

进一步地，所述比较模块比较两种测试结果是否一致具体包括：对两台测试终端展现的测试结果进行截图，比较两个截图的相似度，当其相似度到达一定阈值时，则认为测试结果一致，若一致说明新应用的该功能兼容原应用的该功能。

本发明通过部署类似生产环境的预发布环境和diff测试环境，搜集真实的用户操作请求，同时访问两个环境的新应用和原应用，分析响应结果的差异，快速判断新应用是否对老功能造成影响，可用于接口类的所有测试领域。

附图说明

下面将参照附图描述本发明的具体实施例，其中：

图1示出了本发明实施例一中新应用测试方法的流程示意图；

图2示出了本发明实施例二中新应用测试装置的结构示意图；

图3示出了本发明实施例三中新应用测试方法的流程示意图；

图4示出了本发明实施例四中新应用测试方法的流程示意图。

具体实施方式

为了使本发明的技术方案及优点更加清楚明白，以下结合附图对本发明的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本发明的一部分实施例，而不是所有实施例的穷举。并且在不冲突的情况下，本说明中的实施例及实施例中的特征可以互相结合。

发明人在发明过程中注意到：移动端的应用功能更新，都是通过界面测试，需要手动遍历各个场景，不论是移动端对应的后台服务的接口变更还是移动端功能调整，都需要在手机移动端回归老的功能逻辑，目前对于这种测试多是手动测试，需要提高测试效率。

针对上述不足，本发明实施例提出了一种对新应用进行测试的方法，下面进行说明。

本发明依赖的环境：生产环境(多台线上服务器)、用于测试新应用的预发布环境、用于测试原应用的diff环境。这里的应用可以指应用软件、后台为软件运行服务的服务器等，原应用指目前已在线上运行的应用，新应用指在原应用基础上更新或扩展的应用。

本发明提供一种在测试终端上对应用进行测试的方法及装置，在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试环境，向所述两台测试终端上的应用发送相同的测试请求，比较所述新应用的测试结果与原应用的测试结果是否一致，若一致则所述新应用通过测试。

实施例一

图1示出了本发明实施例进行新服务测试的方法，如图所示，包括：

步骤11，在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试环境；并配置不同的主机，使其分别指向测试新应用的测试终端和测试原应用的测试终端；

该步骤中，部署测试环境包括，对待测试应用的各参数进行设置，两种测试环境下被测试功能对应各参数设置需一致，若新应用在原应用基础上进行了功能扩展，本次测试是对新应用进行是否兼容原应用的测试，因此，参数设置时需将被测试的新应用对应的参数设置成与diff环境中原应用的参数一致。如果新应用相对原应用参数有减少，则关闭原应用中此参数相关功能。

步骤12，向两台测试终端上的待测试应用发送相同的测试请求；

步骤13，从两台测试终端分别获取应用的测试结果，并对结果进行比较，从而判定新应用中的老功能是否兼容老服务。

比较新应用的测试结果与原应用的测试结果是否一致包括：比较两种测试结果的展现内容及展现方式是否一致。

进一步地，所述比较测试结果是否一致的具体方法包括：对两台测试终端展现的测试结果进行截图，比较两个截图的相似度，当其相似度到达一定阈值时，则认为测试结果一致，若一致说明新应用的该功能兼容原应用的该功能。

进一步地，在步骤12之前还包括：

步骤1A，生成测试请求，该测试请求用于向被测试的新应用及原应用发送；

具体地，该测试请求可以是用户向线上应用发送的用户请求，为了拿到尽可能真实的请求数据，可以采用tcpcopy(一种请求复制工具)将生产环境的请求(即流量)复制一份，也可以通过抓取线上的log，使用测试脚本拼接用户真实请求；

上述步骤11、步骤1A执行的先后顺序不做限定，可以是步骤11在前，或步骤1A在前，或二者同时进行。

实施例二

基于同一发明构思，本发明实施例中还提供了一种对新应用进行测试的装置，如图2所示，该装置可以包括：

部署模块、发送模块、测试模块、结果获取模块及比较模块；

部署模块，用于在两台测试终端上分别为更新后的新应用以及更新前的原应用部署测试模块(即上述实施例一中所述的测试环境)；具体部署内容可以包括，测试模块一，在其中一台测试终端上安装新应用，测试模块二，在另一台上安装原应用，对新应用及原应用中待测试功能的各个参数进行设置，对于待测功能对应的参数两种环境下设置应保持一致。

发送模块，向两台测试终端的测试模块发送测试请求，包括向测试模块一(新应用测试模块)及测试模块二(如diff测试模块)发送相同的测试请求。

结果获取模块，用于从测试模块获取根据测试请求反馈的测试结果，包括从测试模块一以及测试模块二获取测试结果。结果获取模块获取测试结果的具体方式包括：对测试终端展现的测试结果进行截图，并将截图发送至比较模块。

比较模块，用于对比两个测试模块的测试结果是否一致；包括比较两种测试结果的展现内容及展现方式是否一致。具体方式可以包括：接收结果获取模块发来的截图，比较两个截图的相似度，当其相似度到达一定阈值时，则认为测试结果一致，若一致说明新应用的该功能兼容原应用的该功能。

进一步地，该装置还包括请求抓取模块，用于抓取测试请求，上述测试请求可以是用户向线上应用发送的用户请求，也可以是临时生成的请求。

采用本提案的技术方案，对检索服务的测试，可通过构造请求样例，发送请求到服务器，通过解析服务器返回的数据，进行功能的验证。然后，检索服务及数据库更新相对频繁，除了基本的回归测试，还可以通过引入线上的真实流量，查看新、老服务的返回结果差异，来保证新应用中老功能的正确性；如果对于老功能，新服务接口返回的结果和老服务接口返回的结果一致，则认为新应用验证通过。

实施例三：

针对测试终端(本实施例中测试终端为移动终端)上运行的某个应用的某个功能进行更新，对更新后的新应用中未变的接口测试，例如：上报接口(客户端的进入页面、打开页面中的推广图片或者打开页面中的推广app，会给后台收集数据的服务发送请求，来达到监控移动端行为的目的)，进行对上报接口进行测试。测试流程如图3所示，包括以下步骤：

步骤31，在两台移动终端上分别部署用于测试原应用及更新后的新应的测试环境，如在其中一台移动终端上安装原应用，在另一台上安装新应用。并将两台移动终端上该应用被测试功能相关的参数设置一致。而其他配置参数配置为默认或者关闭，从而减少对该功能的外界影响。

步骤32，向两台移动终端上的新应用及原应用进行相同的操作集合，操作集合可以通过使用monkey指令(Android SDK提供了monkey接口，用于支持黑盒自动化测试的场景，可以模拟点击按键，触摸屏幕，滑动屏幕等操作)自动操作；同时，使用数据分析脚本(自己写)，对后台收集数据的服务对两台移动终端的数据进行收集。

步骤33，获取后台收集数据的服务器的结果，自动对比两台移动终端上报数据的差异，一致则说明新应用的该功能兼容原应用的该功能。

进一步地，还可以包括以下步骤：

步骤3A：生成测试请求，该测试请求可以是用户向线上应用发送的用户请求。

步骤31、步骤3A执行的先后顺序不做限定，可以是步骤31在前，或步骤3A在前，或二者同时进行。

实施例四：

针对app分发系统的服务(类似小米市场、豌豆荚等，可以下载app的应用商店)，对于分发app的正确性验证。

本次功能修改点：对app分发系统服务增加了新页签的接口，比如之前有游戏、工具页签，本次新增了社交页签，在此页签下呈现给用户的都是社交类的app，如QQ、微信、微博等app，对之前分类页签(如游戏、工具页签)的检索未改变，本次测试在于验证app分发系统的逻辑正确性，通过验证之前已有页签的搜索结果进行验证。测试流程如图4所示，包括以下步骤：

步骤41，将新开发的应用部署到预发布环境，将对老页签(如游戏、工具页签)的相关的配置参数设置好，其他配置参数配置为默认或者关闭，从而减少对老功能的外界影响。

将生产环境当前应用部署到diff测试环境，配置功能参数与预发布环境中的相同，如果新应用对原应用参数有增加，则保证新应用中此参数相关功能关闭；如果新应用相对老服务参数有减少，则将原应用中此参数相关功能关闭，以保住两种测试环境下应用对应参数设置一致。

步骤42，对预发布环境和diff环境，均发送上述步骤中的查询请求(该查询请求即为测试请求)；

步骤43，获取每个查询请求返回的结果，根据结果判定新应用是否通过测试；

结果列表中按照diff测试环境中返回的app个数、内容、顺序，对比预发布环境中相应app个数、内容、顺序，如果返回的app个数、内容、顺序均一样，则认为新应用的老功能验证通过。针对本次新增的社交分类的app，单独写相关的测试案例，进行测试，测试通过，则本次测试全部通过。

进一步地，还可以包括以下步骤：

步骤4A，从生产环境抓取一小时的日志，根据app分发系统服务的请求参数接口标准，将日志数据一条条复原为真实的用户的真实查询请求url。

步骤41、步骤4A执行的先后顺序不做限定，可以是步骤41在前，或步骤4A在前，或二者同时进行。

为了描述的方便，以上所述装置的各部分以功能分为各种模块或单元分别描述。当然，在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。