一种自动化测试方法和系统与流程

本申请涉及软件项目管理技术领域，特别涉及一种自动化测试方法和系统。

背景技术

在软件项目周期中，对于每个版本的迭代系统进行性能测试将是必须可少的是必不可少的。由于软件系统的复杂性，测试过程中会涉及大量性能指标，接口的性能指标是否能满足预期，是否比上版本有所上升/下降，将是评估系统模块产品质量一个重要指标和依据。

因此，进行有效的测试、对测试结果精确分析，是一个亟待解决的问题。

技术实现要素：

有鉴于此，本申请实施例提供了一种自动化测试方法和系统，以解决现有技术中存在的技术缺陷。

本申请实施例公开了一种自动化测试方法，包括：

收集多个触发任务，对收集得到的多个触发任务排序；

根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。

优选的，所述触发任务至少包含以下所列任务中的任一种或任意多种：

全量测试触发任务、部分接口测试触发任务、脚本测试触发任务，

该方法还包括：

为各种所述触发任务配置不同的优先级。

优选的，所述对收集得到的多个触发任务排序的步骤包括：

根据所述触发任务的优先级对收集得到的所述多个触发任务进行排序。

优选的，所述根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据的步骤包括：

选择排序最靠前的触发任务作为当前触发任务；

根据所述当前触发任务，确定需要执行测试的待测接口；

检查所述待测接口的脚本，在所述脚本正常时，执行所述脚本；

结合预置的测试策略，根据所述脚本动态生成至少一个测试指令；

执行所述测试指令，完成压力测试，得到每个所述待测接口的多个维度指标值，作为测试数据写入数据库。

优选的，所述根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据的步骤之后，还包括：

在接口的压力测试完成后，根据所述测试数据生成所有接口的对比测试报告。

本申请实施例公开了一种自动化测试系统，包括：

任务收集模块，用于收集多个触发任务，对收集得到的多个触发任务排序；

测试执行模块，用于根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。

优选的，所述测试执行模块包括：

任务选择单元，用于选择排序最靠前的触发任务作为当前触发任务；

接口确定单元，用于根据所述当前触发任务，确定需要执行测试的待测接口；

脚本执行单元，用于检查所述待测接口的脚本，在所述脚本正常时，执行所述脚本；

指令生成单元，用于结合预置的测试策略，根据所述脚本动态生成至少一个测试指令；

数据收集单元，用于执行所述测试指令，完成压力测试，得到每个所述待测接口的多个维度指标值，作为测试数据写入数据库。

优选的，该系统还包括：

报告生成模块，用于在接口的压力测试完成后，根据所述测试数据生成所有接口的对比测试报告。

本申请实施例还公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器在运行所述计算机指令时实现如上述自动化测试方法的步骤。

本申请实施例还公开了一种计算机可读存储介质，其存储有计算机指令，其特征在于，该指令被处理器执行时实现如上述自动化测试方法的步骤。

本申请提供的一种自动化测试方法和系统，收集多个触发任务，并对收集得到的多个触发任务排序，再根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。提供了成本低、易维护、对测试人员要求放宽的测试系统，实现了自动化性能测试，解决了需要进行有效的测试、对测试结果精确分析的问题。

附图说明

图1是本申请实施例提供的一种自动化测试方法的流程示意图；

图2是图1中步骤103的具体流程示意图；

图3是本申请实施例提供的又一种自动化测试方法的流程示意图；

图4是本申请实施例提供的又一种自动化测试方法的流程示意图；

图5是本申请实施例提供的一种自动化测试系统的架构示意图；

图6是图5中测试执行模块502的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

为配合软件项目开发，进行有效的测试、对测试结果精确分析，是一个亟待解决的问题。具体的，需要解决如何定位性能瓶颈、如何降低性能测试门槛、如何即可以减少人力投入、让数据分析更加准确、让数据分析和反馈更智能等问题。

在本申请中，提供了一种自动化测试方法和系统，在下面的实施例中逐一进行详细说明。

本申请的一实施例提供了一种自动化测试方法，使用该方法完成自动化测试的流程如图1所示，包括步骤101至步骤104。

步骤101、为各种触发任务配置不同的优先级。

本申请的实施例中，通过配置不同优先级的触发任务对测试任务触发流程进行管理。

本申请的实施例中涉及的所述触发任务至少包含以下所列任务中的任一种或任意多种：

全量测试触发任务、部分接口测试触发任务、脚本测试触发任务。

以下为一种对上述触发任务优先级定义排序的举例：

脚本测试触发任务>部分接口测试触发任务>全量测试触发任务。

其中，全量测试触发任务为对模块下所有接口按策略进行性能测试，例如jenkins通过job任务后置触发ant指令，执行如jmter脚本的控制标识更新的脚本，增加对应模块更新标识，模块下所有接口按策略做全量性能测试。

部分接口测试触发任务为对部分需要进行性能测试的接口进行性能测试，例如在工具中置任务，关联需要性能测试的接口，逐个进行性能测试。

脚本测试触发任务为根据脚本执行性能测试，例如维护好脚本后，直接调用调试(主要为单接口)，根据脚本中的配置策略进行性能测试。

触发任务包括但不限于如下内容：

项目管理、版本管理、脚本管理、脚本健康检测、策略管理、任务管理、执行、数据分析等。

优选的，还可增加定时任务，既固定时间到达即触发执行的任务。该定时任务的优先级可配置为最高。

由于一个触发任务有可能涉及多个接口，在此种情况下，多个接口间亦可并行执行触发任务，完成测试。

需要说明的是，步骤101与步骤102-104并无严格时序关系，对触发任务的配置可根据实际应用需求随时调整，在配置生效之后按照最新配置完成测试。

步骤102、收集多个触发任务，对收集得到的多个触发任务排序。

本步骤中，收集并对多个触发任务进行排序，优选的，根据各个触发任务的优先级对触发任务进行排序。

例如，通过工具实现任务统一管理，使用数据库表(如task表)对多个触发任务统一进行管理，通过优先级区分触发任务级别，每次执行前进行触发任务自动筛选。如同一优先级上存在多个触发任务，则可进一步的根据多个触发任务到达的时间对同一优先级上的多个触发任务进行排序，将到达时间较早的触发任务排在较靠前的位置，保证先到的任务优先执行。

步骤103、根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。

本步骤中，根据排序结果，选择排序靠前的触发任务优先执行。同一触发任务可能会涉及多个接口，在需要测试的接口数量为多个时，还可以在多个接口并行测试。

本步骤具体如图2所示，包括步骤1031至步骤1035。

步骤1031、选择排序最靠前的触发任务作为当前触发任务。

步骤1032、根据所述当前触发任务，确定需要执行测试的待测接口。

步骤1033、检查所述待测接口的脚本，在所述脚本正常时，执行所述脚本。

步骤1034、结合预置的测试策略，根据所述脚本动态生成至少一个测试指令。

例如，使用c#通过对公共方法jmeter指令，动态读取压力测试策略(并发、时长、轮次等)设定，自动生成动态指令。系统中可配置一套默认测试策略，也可在执行触发任务时根据执行需要对任务配置测试策略。

步骤1035、执行所述测试指令，完成压力测试，得到每个所述待测接口的多个维度指标值，作为测试数据写入数据库。

本步骤中，在全部测试完成后，才收集得到的各个维度指标值，减少了测试运行过程中的系统压力。

例如，监控测试过程，每30秒获取一次测试数据，记录在缓存中，所有监控数据进行异步读取，压力测试完成后通过正则表达式对整体数据分析提炼。每个测试指令会涉及多个维度指标，如任务名、接口名、压力测试开始时间、结束时间、并发数、tps、平均响应时间、流量、报告路径等，根据测试结果生成包含多个维度指标值的测试数据。在收集得到测试数据时，即将测试数据存储至数据库，便于后续的数据分析利用。

步骤102收集触发任务及步骤103为收集得到的触发任务排序的操作是持续运行，贯穿整个测试过程的。在系统闲时能够收集触发任务并执行，在系统中存在正在执行的触发任务时，仍可同时持续收集新下发的触发任务，并根据同样的排序规则，将新收集得到的触发任务添加到已有的未执行触发任务的队列相应位置中。在当前的触发任务执行完毕后，即可选择排序最靠前的触发任务继续执行。这样，测试系统就可持续接受新的触发任务并自动连续执行触发任务，进行测试，最大化的利用系统资源，提高测试效率。

步骤104、在接口的测试完成后，根据所述测试数据生成所有接口的对比测试报告。

为不影响压力测试过程中压力测试机整体性能，所有测试数据在压力测试结束后才进行数据提炼、分析、计算等处理，并存储在数据库，便于后续分析。

根据测试数据，可生成单个接口对应的测试报告，也可依据整个触发任务执行的结果数据甚至不同版本下多个触发任务执行的结果数据，生成对多个维度数据分析的对比测试报告，确保接口上线满足要求，该对比测试报告中至少包含如下内容：

不同版本接口性能对比曲线、接口最大tps，接口最大tps瓶颈指标数据、脚本健康情况等。

对服务器cpu、io、内存、网络等资源进行监控，通过不同命名本地生成文件，根据不同测试数据生成报告存储，关联数据库资源报告路径。便于后续分析瓶颈指标。

本申请实施例提供的自动化测试方法，收集多个触发任务，并对收集得到的多个触发任务排序，再根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。提供了成本低、易维护、对测试人员要求放宽的测试系统，实现了自动化性能测试，解决了需要进行有效的测试、对测试结果精确分析的问题。

通过本申请提供的技术方案，可实现24小时无人自动化性能测试。将自动化测试结果的测试数据沉淀数据库，便于通过多维度进行数据对比分析。可实时监测测试脚本的可用性，及时发现存在的问题，便于修复。将性能测试脚本进行集成维护，增强脚本的复用性。有效降低性能测试人员入门门槛，根据不同监控数据自动分析瓶颈，有效进行知识沉淀。

本申请的一实施例还提供了一种自动化测试方法，该方法在前述测试过程中对脚本进行定期的健康检查，具体流程如图3所示，包括步骤301至步骤308。

步骤301、定时执行任务扫描。

jenkins、ant编译器、jmeter、c/s工具关联实现持续集成，实时/定时对脚本进行健康检查。

步骤302、检查是否存在在途任务，在检查结果为存在在途任务时等待在途任务完成后再进入步骤303，在检查结果为无时直接进入步骤303。

步骤303、更新数据库健康检查字段标识。

数据库建表check-taskaction表，设置健康检查字段标识checkready和checkaction。服务更新后checkready＝1；开始执行后设置checkaction＝1，checkready＝0。通过意向锁，减少无效执行和资源消耗。

步骤304、获取对应模块接口。

步骤305、在所有接口管理目录下查询是否存在脚本，将检查结果更新入数据库。如果存在，进入步骤306；如果不存在，则继续遍历下一个脚本，在又遍历到存在的脚本时进入步骤306。

步骤306、更新数据库，遍历检查完成。

本步骤，更新数据库中触发任务对应的测试性能脚本，可更新如下内容：

nid(序列)，nprojectid(项目名)，sservername(模块名)，sport(接口名)，nscriptid(脚本id)，nexist(接口是否存在)，nhealth(接口是否健康)，ndate(检查日期)。

步骤307、检查脚本可用性，检查结果存储数据库。

步骤308、对于存在问题的接口脚本，发送预警邮件。

本申请实施例提供一种自动化测试方法，对测试性能所使用的脚本进行检查，以确定脚本可用性，保障系统正常运行，将性能测试脚本进行集成维护，增强脚本的复用性。

本申请的一实施例还提供了一种自动化测试方法，使用该方法遍历任务接口完成压力测试的流程如图4所示，包括步骤401至步骤414。

步骤401、定时监测jenkins、任务、手工等触发任务执行创建的执行任务。

步骤402、根据触发任务的优先级进行排序。

步骤403、执行触发任务前需检查是否有在途任务，即判定是否有触发任务正在运行中，有则进入404，无则进入405。

步骤404、存在在途任务时，等待该在途任务执行完毕。

步骤405、不存在在途任务时，执行排序较靠前的触发任务，进入406。

步骤406、在数据库更新执行标识。

步骤407、检查需要测试的接口，检查接口脚本，在检查结果异常时终止触发任务，否则进入408开始执行。

步骤408、读取测试策略，此处的测试策略可为预置于系统中的默认策略，也可以是与触发任务一并配置的专用的测试策略。

步骤409、运行脚本，调用测试策略，根据测试策略逐一生成并发送测试指令。

步骤410、调用测试工具，如调用jmeter等测试工具。

步骤411、执行过程每30秒收集测试数据。

步骤412、每次策略压力测试结束后解析收集的测试数据，为不影响压力测试机性能，不在压力测试过程中收集，而在测试结束后再进行收集。

步骤413、将压力测试得到的各维度指标作为测试数据，存储至数据库。

步骤414、本触发任务涉及的所有接口压力测试完成后发送包含所有接口测试数据的对比测试报告，本地存储每个接口各策略下详细报告。

本申请实施例提供的自动化测试方法，提供了直观的操作界面，可进行性能测试策略的维护、性能测试脚本管理、任务管理，根据不同项目、不同版本、不同接口设定的自定义策略，定时对脚本进行健康性检查。可通过配置任务定时触发、jenkins自动触发、手工触发等来执行性能脚本，将测试得到的性能数据，如tps、响应时间、事务数、并发数等沉淀到数据库，不同接口并发生成各自对应的html测试报告，提供版本接口多维度数据比对，发现异常问题根据预警策略进行及时预警。减少了性能测试脚本的开发成本，降低测试人员技能要求，降低维护成本，使测试系统可满足持续集成的需求。

本申请的一实施例还提供了一种自动化测试系统，该系统的架构如图5所示，包括：

任务收集模块501，用于收集多个触发任务，对收集得到的多个触发任务排序；

测试执行模块502，用于根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。

优选的，所述测试执行模块502的结构如图6所示，包括：

任务选择单元5021，用于选择排序最靠前的触发任务作为当前触发任务；

接口确定单元5022，用于根据所述当前触发任务，确定需要执行测试的待测接口；

脚本执行单元5023，用于检查所述待测接口的脚本，在所述脚本正常时，执行所述脚本；

指令生成单元5024，用于结合预置的测试策略，根据所述脚本动态生成至少一个测试指令；

数据收集单元5025，用于执行所述测试指令，完成压力测试，得到每个所述待测接口的多个维度指标值，作为测试数据写入数据库。

优选的，该系统还包括：

报告生成模块503，用于在接口的测试完成后，根据所述测试数据生成所有接口的对比测试报告。

本申请一实施例还提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器在运行所述计算机指令时实现如前述自动化测试方法的步骤。

本申请一实施例还提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前述自动化测试方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的自动化测试方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述自动化测试方法的技术方案的描述。

本申请实施例提供了一种自动化测试系统、计算设备和可读存储介质，能够与本申请的实施例提供的一种自动化测试方法相结合，收集多个触发任务，并对收集得到的多个触发任务排序，再根据对所述多个触发任务的排序结果，依序执行所述触发任务，获取测试数据。提供了成本低、易维护、对测试人员要求放宽的测试系统，实现了自动化性能测试，解决了需要进行有效的测试、对测试结果精确分析的问题。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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

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

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。