一种打包测试装置、方法及计算机可读存储介质与流程

1.本发明涉及软件测试领域，更详细地说，涉及一种提高软件自动化测试成功率的打包测试装置、方法及计算机可读存储介质。


背景技术：

2.在软件生命周期中的任何一个阶段,只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时,还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
3.回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中,更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。


技术实现要素：

4.发明要解决的问题
5.在自动化测试流程中，打包过程和回归测试是密不可分的。目前的自动化测试流程是开始打包，然后将打出来的新包进行回归测试。这种方法只能排查出打包过程中报的error，而不能检查出其他原因导致的打包失败，容错率较低。
6.本发明鉴于上述实际情况，提供一种提高软件自动化测试成功率的打包测试装置、方法及计算机可读存储介质。
7.用于解决问题的方案
8.为了达到上述目的，本发明所涉及的打包测试装置，包括：获取部，其经由互联网或无线网络从一个或多个客户端接收或下载程序代码；处理部，所述处理部包括：打包模块，其对从所述获取部获取的程序代码打包，并自动生成与所述程序代码打包相关联的库文件，所述库文件包含一个或多个用于识别打包是否成功的识别信息；比较模块，其逐项比较所述库文件中的识别信息与基准测试文件中的识别信息，并对比较结果的一致性进行标识；以及判断模块，其基于所述比较模块的比较结果判断程序代码是否打包成功。
9.在一种实现方式中，所述打包测试装置还包括：通知部，其用于在所述判断模块判断为程序代码打包成功的情况下，输出程序代码打包成功的通知信息。
10.在一种实现方式中，所述打包测试装置还包括：存储部，其用于根据预先设定的程序代码存储路径存储所获取的程序代码。
11.在一种实现方式中，所述识别信息包括用于识别打包是否成功的一个或多个特定的数字、关键字、字段、标识符或其组合。
12.在一种实现方式中，所述判断模块在所述库文件中的识别信息与基准测试文件中的识别信息完全一致的情况下，判断为程序代码打包成功。
13.在一种实现方式中，所述判断模块在所述库文件中的识别信息与基准测试文件中的识别信息至少有一处不一致的情况下，判断所述库文件中的不一致的识别信息是良性信息还是错误信息，其中，所述良性信息是通过过滤不会导致打包失败的信息，所述错误信息是导致打包失败的信息。
14.在一种实现方式中，所述通知部将比较模块对库文件中的识别信息与基准测试文件中的识别信息的比较、标记的结果与所述判断模块对库文件中的各识别信息的判定结果相关联的存储，并生成打包测试报告。
15.在一种实现方式中，所述打包测试装置还包括回归测试定时校正模块，所述回归测试定时校正模块根据程序代码打包的结束定时动态调整回归测试的开始时间。
16.另外，本发明所涉及的打包测试方法，包括如下步骤：获取步骤，经由互联网或无线网络从一个或多个客户端接收或下载程序代码；打包步骤，对所获取的程序代码进行打包，并自动生成与所述程序代码打包相关联的库文件，所述库文件包含一个或多个用于识别打包是否成功的识别信息；比较步骤，逐项比较所述库文件中的识别信息与基准测试文件中的识别信息，并对比较结果的一致性进行标识；判断步骤，基于所述比较结果判断程序代码是否打包成功。
17.发明的效果
18.根据本发明，通过预先对程序代码的打包结果进行测试，能够避免软件自动化测试流程不会因为打包失败导致的软件测试效率低下。此外，通过自动化打包测试，不需要人为介入进行参数配置，实现快速打包测试功能，减少了沟通成本，提高开发效率。
19.另外，根据本发明，通过根据打包测试结果对回归测试定时进行自动调整，不会让自动化测试流程因为打包过程的超前或滞后导致服务器利用率低或回归测试失败，提高了自动化测试流程的容错率。
附图说明
20.图1是表示本发明打包处理系统的整体结构框图。
21.图2是表示本发明客户端的功能模块框图。
22.图3是表示本发明客户端生成程序代码及库文件的流程图。
23.图4是表示本发明打包测试装置的功能模块的框图。
24.图5是表示本发明打包测试工序的流程图。
具体实施方式
25.下面，参照附图来详细说明本发明所涉及的打包测试系统及方法的优选实施方式。
26.图1是示出按照本发明实施方式的打包处理系统的整体结构的一例的框图。
27.参照图1，打包测试系统包括一个或多个客户端1(10、11、12
…
,)、网络3以及一个或多个打包测试装置2(例如中央服务器、云服务器)。
28.所述一个或多个打包测试装置2经由一个或多个网络3而连接至诸如一个或多个远程客户端10、11、12
…
。在一种实现方式中，一个或多个客户端1与一个或多个打包测试装置2之间采用b/s(browser/server，网页/服务器)结构进行开发，这种结构可以减轻客户端的运行压力，用户操作也比较简单。
29.一个或多个打包测试装置2可以包括存储装置和处理器。一个或多个打包测试装置2可以是任何合适的计算装置，其例如包括应用服务器和托管可由远程客户端访问的网站的web服务器、云端服务器。存储装置可以包括诸如外部硬盘阵列或固态存储器等的任何非暂时性计算机可读存储介质。存储装置可以包括内部存储装置，其可以是诸如硬盘或固态存储器等的非暂时性计算机可读存储介质，用于存储在由处理器执行时实现这里描述的特征的相关部分的软件指令。处理器可以包括中央处理单元(cpu)、图形处理单元(gpu)等。处理器可被实现为单个半导体芯片或多于一个芯片。
30.网络3可以包括因特网、蜂窝网络、广域网(wan)、局域网(lan)等的任意组合。经由网络3的通信可以通过有线和/或无线连接来实现。客户端1可以是用于经由网络来发送和/或接收数据的任何合适的电子装置。
31.客户端1可以例如是网络连接计算装置，诸如个人计算机、笔记本计算机、个人数字助理(pda)、平板计算机等。
32.所述客户端1和打包测试装置2可分别包括输入/输出装置，所述输出装置可以包括显示器、扬声器、外部端口等。显示器可以是用于输出可见光的任何合适的装置，诸如液晶显示器(lcd)、发光聚合物显示器(lpd)、发光二极管(led)、有机发光二极管(oled)等。输入装置可以包括键盘、鼠标、追踪球、静物照相机或摄像机、触摸板等。触摸板可以覆盖有或集成有显示器以形成触敏显示器或触摸屏。
33.本发明实施例所述客户端1的系统基于eclipse构建，eclipse是一个开发源代码的、基于java的可扩展开发平台，它本身只是一个框架和一组服务，用于通过插件构成开发环境。eclipse平台为工具提供者(tools provider)提供一套使用机制和一组需要遵循的规则，从而使得开发出的工具之间实现无缝的集成。这些机制通过定义api接口、类和方法提供给用户使用。更确切地说，eclipse中的每样东西都是插件。
34.eclipse sdk(软件开发者包)是eclipse platform、jdt和pde所生产的组件合并，它们可以一次下载。这些部分在一起提供了一个具有丰富特性的开发环境，允许开发者有效地建造可以无缝集成到eclipse platform中的工具。eclipse sdk由eclipse项目生产的工具和来自其它开放源代码的第三方软件组合而成。eclipse项目生产的软件以gpl发布，第三方组件有各自自身的许可协议。
35.客户端1可以通过内部的一个或多个处理器所执行的、存储在存储介质中的一个或多个软件指令来实现。
36.如图2所示，客户端1包括：输入部100，其用于接收用户通过键盘、鼠标等进行的指令输入操作；处理部102，其包括：目标程序生成模块1021，其配置为根据用户基于输入部的操作输入的代码指令来生成一组或多组目标程序，以及目标程序导出模块1022，其将所存储的所述目标程序生成模块生成的目标程序及对应的版本号导出；存储部103，其配置为存储已开发的目标程序代码的一部分或全部；优选的，所述储存部103还将各应用程序代码与其对应的附加信息相关联的存储，所述附加信息包括程序代码版本号、开发者、程序代码生成时间、程序代码大小等；显示部105，其通过目标程序开发界面展现生成的代码和/或运行结果；通信部104与一个或多个打包测试装置2通信，用于向一个或多个打包测试装置2发送代码打包请求，将应用程序代码及对应与其对应的附加信息发送至一个或多个打包测试装置2。
37.所述客户端1的具体工作流程图请参阅图3所示，具体包括步骤：
38.步骤s301：开发人员在客户端启动eclipse工具进行源代码开发工作，处理部102中的程序代码生成模块1021基于开发人员的操作指令生成一个或多个程序代码和/或与所述程序代码相关联的日志文件，所述日志文件包括程序代码存储目录、生成日期、编译方式，版本号、开发环境，开发者、程序代码大小、预设打包类型
…
；
39.步骤s302：程序代码验证模块1022对所生成的程序代码进行规范性、功能性验证，接着，将验证通过的程序代码存储至存储器中；
40.步骤s303：一旦程序代码验证通过，客户端1自动通过通信部104向测试装置2发送打包、测试请求，触发测试装置2获取待测应用程序的代码及相关开发日志文件。
41.在一种可选的实现方式中，客户端1以预定的定时或时间间隔自动通过通信部104向测试装置2发送打包、测试请求。
42.在具体实施当中，所述打包请求为http请求，所述打包请求中包含程序代码所在的svn目录信息和/或需要打包类型。在一种实现方式中，由于现有的移动终端系统主要为ios和android，所述打包类型主要包括ipa格式和apk格式。需要说明的是，根据不同系统和安装包的格式要求，本发明显然还可以推广到其他的系统当中，不应视为对本发明的限制。
43.步骤s304：客户端1接收从测试装置返回的应答信息，利用程序代码导出模块1023将已验证的程序代码导出，并通过上传组件upload将程序代码及对应与其对应的日志文件通过通信部104上传至测试装置或云存储服务。
44.如图4所示，测试装置2包括：获取部201，其用于从一个或多个客户端1获取待测应用程序的最新代码；存储部202，其用于根据预先设定的程序代码存储目录信息存储所获取的程序代码及其关联的日志文件；处理部203，其包括：打包模块2031，从存储部202中获取待代包的程序代码，根据预先设定的打包类型或者所述日志文件设定的打包类型，调用相应的打包工具将所述程序代码打包成安装包或其它应用程序类型包，对打包完成的应用程序包例如安装包进行存储。其中，打包模块2031在程序代码打包时还自动生成与该程序代码打包相关联的库文件，所述库文件包含用于测试打包是否成功的一个或多个识别信息；比较模块2032，其将与该程序代码包相关联的库文件与基准测试文件进行比较；判断模块2032，其基于比较结果判断库文件中的识别参数为正常信息、良性信息还是异常信息；通知部205，其基于判定部2032的判断结果输出打包成功或失败的通知信息。
45.所述测试装置2的具体工作流程图请参阅图5所示，具体包括步骤：
46.步骤s501：测试装置2通过获取部201从一个或多个客户端1获取最新程序代码和/或与所述程序代码相关联的日志文件；
47.在一种实现方式中，测试装置2的获取部201例如经由能够基于tcp(transmission control protocol：传输控制协议)/ip(internet protocol：互联网协议)进行通信或无线网络与多个客户终端11、12、13
…
双向通信，从多个客户终端接收或下载目标应用程序代码和/或与所述程序代码相关联的日志文件。
48.测试装置2接收到一个或多个客户端1发送的打包请求后，向客户端1返回可上传程序代码的应答信息，根据预先设定的程序代码存储目标信息或者所述日志文件中的程序代码存储目录信息将所接收到的程序代码存储。在一种优选的实现方式，存储部202还将所接收到的程序代码与对于的客户端1的标识符相关联的存储。
49.在一种实现方式中，所述测试装置2从大量的客户端1接收程序代码并将获取的应用程序代码与客户端id相关联地保存到存储部。
50.在一种实现方式中，所述测试装置2控制一个或多个客户端1中的程序代码的上传定时。上传定时表示从一个或多个客户端1发送程序代码的定时的时刻。
51.在一种实现方式中，所述测试装置2基于多个客户端1的发送请求检测当前待发送程序代码的客户端1的总数，当检测出客户端的总数之后，判断预定时间段内的待发送客户端1总数是否为预先设定的规定值th以上。在此，“规定值th”是认为待发送程序代码的客户端瞬时增多导致测试装置2的通信负荷变得过大的端数。当待发送程序代码的客户端总数变得过多时，测试装置2接收程序代码出现拥塞，成为通信负荷。上述“规定值th”是基于该实时性的确保与通信负荷的界限来设定的值。
52.在一种实现方式中，为待发送程序代码的客户端总数为规定值th以上之后，所述测试装置2对已发送程序代码上传请求的客户端各自的上传时刻实施校正。
53.在一种实现方式中，所述测试装置2对已发送程序代码上传请求的客户端进行“发送间隔延长校正”。“发送间隔延长校正”是指计算用于使各客户端上传程序代码的上传间隔变长的校正值，此外，在该“发送间隔延长校正”中，不需要延长全部客户端的上传间隔。
54.步骤s502：打包模块2031根据预先设定的打包类型或者客户端发送的日志文件预设的打包类型，调用相应的打包工具将程序代码打包成安装包；
55.下面示例性地给出一种把将java项目打包成可执行jar文件的方法。
56.java的jar是一个打包工具，用于将编译后的class文件打包起来，这里面主要是举一个例子用来说明这个工具的使用。
57.要打包成可运行的jar包，有两种方法，一是手动创建manifest.mf文件，并在其中指定主类；二是使用jar的-e参数指定可运行jar包的入口点(即main类的完全名称)。
58.以java源代码行数统计程序的打包为例，演示如何打包:
59.手动创建manifest.mf文件：
60.1)首先编辑manifest.mf文件，内容如下：mf代码收藏代码复制代码
61.manifest-version:1.0
62.created-by:rsljdkt
63.class-path:.
64.main-class:main
65.说明：
66.第一行指定清单的版本，若无，则jdk默认生成：manifest-version:1.0
67.第二行指明创建的作者，若无，则jdk默认生成created-by:1.6.0_22(sun microsystems inc.)
68.第三行指定主类所在类路径，
69.第四行指明程序运行的主类
70.2)使用jar命令进行打包：cmd代码复制代码收藏代码
71.jar cvfm counter.jar manifest.mf-c bin.
72.说明：
73.参数f：指定打包后的包名。
74.参数m：指定自定义的manifest.mf清单文件，否则，jdk会自动生成不包含main-class的默认清单。
75.参数c：指定是创建新的归档文件。
76.参数v：在标准输出中生成详细输出，该选项是可选的。
77.使用-e参数指定入口点：
78.执行如下命令即可：
79.cmd代码复制代码收藏代码
80.jar cvfe counter.jar main-c bin.
81.方法二：使用eclipse的export功能：
82.一、打包成一般的jar包：
83.步骤如下：
84.1)在要打包的项目上右击，选择export
85.2)在弹出的窗口中，选择java-》jar file，然后点击next按钮
86.3)在jar file specification窗口中，设置打包成的文件名和存放位置，点击两侧next
87.4)在jar manifest specification窗口中，设置manifest.mf清单文件的配置，
88.若仅仅打包成单纯的jar包的话，不用做任何修改，采取默认即可
89.若打包成可执行jar包的话，可以使用已存在的manifest文件或者直接选择main class
90.5)点击finish按钮，完成打包。
91.二、打包成可运行的jar包
92.步骤如下：
93.1)在要打包的项目上右击，选择export
94.2)在弹出的窗口中，选择java-》runnable jar file，然后点击next按钮
95.3)在runnable jar file specification窗口中，选择launch configuration和export destination
96.4)点击finish按钮，打包完成。
97.打包模块2031伴随程序代码打包还自动生成与该程序代码包相关联的库文件，所述库文件包含用于测试打包是否成功的一个或多个识别信息，所述识别信息包括特定的数
字、关键字、字段、标识符
…
，如“optmode＝opt”、“a.cpp|2
–”
、“make[1]:*
”…
。
[0098]
步骤s503：比较模块2032将与该程序代码包相关联的库文件与基准测试文件进行比较。基准测试文件可基于预先通过对一个或多个成功打包的程序代码包所生成的库文件中的识别信息统计产生。
[0099]
一种可实现方式中，用户预先设定或生成一个或多个基准测试文件，并将其存储在存储部202中，所述测试文件包含用于测试打包是否成功的一个或多个识别信息。
[0100]
在另一种可实现方式中，测试装置2通过有线或无线网络与云服务器通信来获取基准测试文件。
[0101]
在具体实施当中，比较模块2032搜索将本次程序代码打包所生成的库文件中的各识别信息，并将搜索出的各识别信息进行列表并与基准测试文件中的各识别信息逐项进行比较、标记。
[0102]
一种可实现方式中，在本次程序代码打包所生成的库文件中的识别信息与基准测试文件中的对应识别信息一致的情况下，将比较结果标记为核验通过的标记，例如“√”，该标记标识本次程序代码打包没有产生任何错误，打包成功；相反，在本次程序代码打包所生成的库文件中的识别信息与基准测试文件中的对应识别信息在不一致的情况下，将比较结果标记为待确定的标记，例如“？”。
[0103]
步骤s504：判定部2032在比较模块2032识别所示库文件的识别参数与基准测试文件中的识别参数一致的情况下，将所述库文件中的识别信息判定为正确信息，所述正确信息是用于表征程序代码打包成功的信息。
[0104]
步骤s505：判定部2032在比较模块2032识别所述库文件中的识别参数与基准测试文件中的识别信息不一致的情况下，进一步判断日志文件中的不一致的识别信息是良性信息还是错误信息。
[0105]
具体地，判定部2032在比较模块2032识别所示库文件的识别信息与基准测试文件中的识别信息不一致的情况下，进一步判定库文件中的不一致识别信息是良性信息还是会影响打包结果的错误信息。在示例中，将同时满足下面条件的信息识别为良性信息：(1)识别信息不存在disk space信息；(2)识别信息中不存在error信息；(3)识别信息数中存在error信息但是该条信息中的error是以error为名的文件。在本发明中，若库文件中与基准测试文件中的识别信息不一致的识别信息全部为所述良性信息，则仍认为本次程序代码打包成功，不会影响后续回归测试进程。因此，对于不会导致打包失败且不会影响回归测试的良性信息，过滤掉此良性信息且进行回归测试，
[0106]
判定部2032在比较部识别所示日志文件的识别信息与基准测试文件中的识别信息不一致的情况下，将不满足上述条件(1)-(3)中的任一项的日志文件中的识别信息判断为错误信息。
[0107]
程序代码打包错误包括但不限于：(1)获取代码失败，产生的原因有：
①
服务器内存不足，无法下载代码。
②
代码管理服务器不在线。(2)编译失败，产生的原因有：
①
代码本身有错误。
②
开发人员漏上传代码，导致代码库不完整。
[0108]
在本发明中，若日志文件中只要有一项识别信息判定为错误信息，则本次程序代码打包失败，不能进入后续回归测试进程。
[0109]
步骤s506：通知部205基于比较模块2032的上述比较、标记结果以及判定部2032的
判定结果生成如下表1所示的打包测试报告，并将其相应存储在存储部。所述打包测试报告包含比较模块对当前日志文件中的各识别信息与基准测试文件中的各识别信息逐项进行比较、标记的结果以及判定模块2032对日志文件中的各识别信息的判定结果。产生这个打包测试报告的目的是为了防止除了代码错误之外的原因导致的无法进行下一步的回归测试。
[0110]
表1
[0111][0112][0113]
优选地，通知部将上述测试报告通过显示部显示或进行文本输出、打印。
[0114]
优选地，通知部还基于判定部2032的判定结果通过文本、语音、图形、图像、视频等输出当前程序代码包打包成功或失败的通知信息。
[0115]
通过本发明所述的打包测试流程，本发明能够让软件自动化测试流程不会因为非报错导致的测试流程失败。
[0116]
在一种实现方式中，测试装置2还包括代码更新部206，用于供开发人员对待打包的程序代码的版本进行更新。代码更新部206通过获取部201从客户端获取程序代码的最新版本，并替换已存储的该程序代码的旧版本。
[0117]
在一种实现方式中，测试装置2中可以设置一指定地址的存储空间，该存储空间专门用于存放打包形成的安装包，则上述打包模块2031对程序代码进行打包后将成功打包的安装包保存在上述存储空间内。
[0118]
更进一步地，由于不同软件版本的迭代都是在前一个版本上添加、修改或者删除程序代码实现的，因此同一个应用软件可以采用统一的连续代码来表示，其中不同的软件版本通过不同部分的代码来表示。
[0119]
在一种实现方式中，测试装置2还包括代码更新记录部207，上述代码更新记录部207监控开发人员通过代码更新部206对各应用软件的程序代码进行的更新操作，每次记录更新操作时均记录该次更新操作所对应的软件版本的版本号、日期，以及该次更新操作对代码执行的添加/修改/删除的具体情况，例如增加了新的功能组件。更进一步地，上述更新记录单元3还记录每次版本迭代完毕后，当前的版本号所对应的部分代码。换言之，在代码
更新记录部207中，记录了每次更新操作中，实际操作的情况，操作之后的软件版本号，以及该版本号所对应的部分代码的范围。
[0120]
本发明不限于上述实施方式。本技术的发明人对打包测试深入研究进一步发现，除程序代码打包过程中产生的错误信息导致打包失败而影响整个软件自动化测试流程外，还存在其它影响整个软件自动化测试效率的因素。
[0121]
具体地，在软件自动化测试流程中，程序代码打包进程与软件测试进程通常具有严格的时序要求。例如，对于a程序代码，设其每次打包定时为20分00秒-20分60秒，回归测试的定时为21分00秒-22分30秒。通常按照上述设定的定时自动对a程序代码打包及回归测试。但是在实际程序代码打包中，存在影响打包阶段的多种时间因素，例如：链接客户端所在的服务器带宽不足(网络堵塞)；系统资源不足(有太多应用程序在后台同时运行)；下载的代码量；编译代码文件的数量。
[0122]
在一具体示例中，例如a程序代码的原代码量为1m，通过修改后，代码量相比上一次打包的代码量要多，a程序代码的代码量变为2m，这样a程序代码的打包定时由20分00秒-20分60秒延迟为20分00秒-21分30秒，即打包过程发生了滞后现象，打出包的时间比原先设定的进行回归测试的时间21分00秒要晚，这样回归测试测试的内容会无效。
[0123]
此外，若删除了a程序代码中的部分组件，导致修改后的a程序代码的代码量相比上一次打包的代码量要少，例如a程序代码的代码量变为500k，这样a程序代码的打包定时由20分00秒-20分60秒提前至20分00秒-20分40秒，即打包过程发生了超前现象，打出来的包会相比预定的回归测试的时间21分00秒早，这样测试装置占用效率会降低。
[0124]
为解决上述技术问题，本发明每次程序代码打包结束时自动记录该打包结束时间，将当前程序代码打包结束时间与预定的程序打包结束时间比较，若判定为打包结束时间发生了滞后现象，则基于通过上述比较获得的时间校正值自动延迟回归测试的开始时间。反正，若判定为打包结束时间发生了提前现象，则基于通过上述比较获得的时间校正值自动提前回归测试的开始时间。具体地，例如a程序代码的打包定时由20分00秒-20分60秒提前至20分00秒-20分40秒，提交前20秒，将该20秒作为校正值，将回归测试的时间校正提前到20分41秒。
[0125]
相应地，本发明所述的打包测试方法还进一步包括如下步骤：
[0126]
根据当前程序代码打包的结束时间相对于预定的打包结束时间获得的校正值动态调整回归测试的开始时间。
[0127]
上述实施方式中的测试装置2也可以具有以下单元，该单元自动记录每次程序代码打包的结束时刻tn，获取各程序代码打包的结束时刻tn相对于预定的打包结束时刻t0的时间差
±
δ，根据时间差
±
δ获得的时间校正值自动动态校正回归测试的开始时间。
[0128]
由此，本发明不会让自动化测试流程因为打包过程的超前或滞后导致测试回归测试服务器利用率低或回归测试失败，提高了软件自动化测试流程的容错率。
[0129]
本技术实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述一种打包测试方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
[0130]
其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(read-only memory，rom)、随机存取存
储器(random access memory，ram)、磁碟或者光盘等。
[0131]
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本技术实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
[0132]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本技术各个实施例所述的方法。
[0133]
上面结合附图对本技术的实施例进行了描述，但是本技术并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本技术的启示下，在不脱离本技术宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本技术的保护之内。