一种软件测试的管理方法、装置及设备与流程

本发明涉及软件测试领域，特别是涉及一种软件测试的管理方法、装置及设备。

背景技术：

随着信息化社会的迅速发展，软件开发的项目越来越多，架构越来越复杂，软件产品的升级与更新频率也越来越频繁，随之带来的问题就是现阶段越来越多的测试任务，为了保证软件产品质量，不得不投入越来越多的测试人员进行需求管理、测试用例设计与评审、测试进度管理、缺陷管理等工作中，造成越来越多的人力成本支出。

在软件测试过程中，首先需要解决的是测试人员问题，尤其是日渐繁重的测试任务、对软件产品越来越高质量的要求与测试人员不足之间的矛盾。众测是一种解决该矛盾的测试手段和方法，它能整合所有测试人员资源，让每一个专职或兼职测试人员都能直接参与软件产品的测试，利用自身专业测试知识完成测试任务。现有技术对众测中测试任务的分配需要依赖人工调度，这就需要更多的人工成本，且非常考验分配人员的调度能力，一旦分配不合理，会直接影响软件测试的质量和效率。

因此，如何合理分配众测中的测试任务，提高软件测试的质量和效率，是本领域技术人员需要解决的技术问题。

技术实现要素：

本发明的目的是提供一种软件测试的管理方法、装置及设备，用于合理分配众测中的测试任务，提高软件测试的质量和效率。

为解决上述技术问题，本发明提供一种软件测试的管理方法，包括：

接收软件测试申请，并按预设的转换方式将所述软件测试申请转换为测试任务列表；其中，所述测试任务列表包括测试任务，以及与所述测试任务对应的积分规则；

发布所述测试任务列表以供抢单，并根据时间顺序下发被抢单的测试任务；

接收各所述被抢单的测试任务的测试结果，按各所述被抢单的测试任务的积分规则分发对应的积分。

可选的，在将所述软件测试申请转换为测试任务列表之前，还包括：

审核所述软件测试申请，判断所述软件测试申请是否符合预设格式；

如果是，则进入所述将所述软件测试申请转换为所述测试任务列表的步骤。

可选的，在所述根据时间顺序下发被抢单的测试任务之后，还包括：

接收上传的测试计划；

依据所述测试计划完成与所述测试计划对应的测试任务。

可选的，在所述接收各所述被抢单的测试任务的测试结果之后，还包括：

检查各所述测试结果，判断是否合格；

如果否，则重新发布与所述测试结果对应的测试任务。

可选的，在所述接收各所述被抢单的测试任务的测试结果之后，还包括：

保存各所述测试任务的测试脚本和测试日志。

可选的，在所述接收各所述被抢单的测试任务的测试结果之后，还包括：

按预设的维度对所述测试结果进行统计分析。

为解决上述技术问题，本发明还提供一种软件测试的管理装置，包括：

转换单元，用于接收软件测试申请，并按预设的转换方式将所述软件测试申请转换为测试任务列表；其中，所述测试任务列表包括测试任务，以及与所述测试任务对应的积分规则；

发布单元，用于发布所述测试任务列表以供抢单，并根据时间顺序下发被抢单的测试任务；

评分单元，用于接收各所述被抢单的测试任务的测试结果，按各所述被抢单的测试任务的积分规则分发对应的积分。

可选的，还包括：

存储单元，用于保存各所述测试任务的测试脚本和测试日志。

可选的，还包括：

统计单元，用于按预设的维度对所述测试结果进行统计分析。

为解决上述技术问题，本发明还提供一种软件测试的管理设备，包括：

存储器，用于存储指令，所述指令包括上述任意一项所述软件测试的管理方法的步骤；

处理器，用于执行所述指令。

本发明所提供的软件测试的管理方法，先将软件测试申请转换为测试任务列表，即拆分为多个测试任务，并预先设定好每个测试任务的积分规则，下发测试任务列表让测试人员对测试任务进行抢单，并根据与测试任务对应的积分规则进行评分。改现有技术中测试人员被动接受测试任务为测试人员主动抢单，使得测试人员可以根据自身条件选择测试任务，使测试任务得到更加合理的分配，从而提高了软件测试的质量和效率。而采用预设的积分规则对各测试任务进行评价，相比于现有技术中的人工审核，避免了人为主观误判的问题，提高了测试人员的工作积极性，也进一步提高了软件测试的质量和效率。本发明还提供一种软件测试的装置和设备，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚的说明本发明实施例或现有技术的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的第一种软件测试的管理方法的流程图；

图2为本发明实施例提供的第二种软件测试的管理方法的流程图；

图3为本发明实施例提供的第三种软件测试的管理方法的流程图；

图4为本发明实施例提供的第四种软件测试的管理方法的流程图；

图5为本发明实施例提供的一种软件测试的管理方法的结构示意图；

图6为本发明实施例提供的一种众测管理系统的技术架构图；

图7为本发明实施例提供的一种软件测试的管理设备的结构示意图。

具体实施方式

本发明的核心是提供一种软件测试的管理方法、装置及设备，用于合理分配众测中的测试任务，提高软件测试的质量和效率。

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

图1为本发明实施例提供的第一种软件测试的管理方法的流程图。如图1所示，软件测试的管理方法包括：

s10：接收软件测试申请，并按预设的转换方式将软件测试申请转换为测试任务列表。

其中，测试任务列表包括测试任务，以及与测试任务对应的积分规则。

测试发起人可发起普通测试、众测工作两种类型的测试申请。其中普通测试和众测工作又可以细分为发布类、建设类两类。接收到测试申请后，可以先对测试需求进行整理分类(普通测试类、众测工作类)普通测试类暂不做任务处理直接归档。

由于大部分软件测试任务具有重复性与共通性，可以预先设计各测试任务对应的积分规则，方便从软件测试申请到测试任务列表的自动转换。积分规则可以根据测试任务的紧急程度、难易程度、抢单响应速度等维度制定。一种积分规则如下所示：

假设软件测试申请的个数为n，测试需求基准分为s，任务紧急程度为j，任务难度系数为x，则基准积分r1＝(n×s)×(1+j％+x％)；

假设主任务期望完成时间为e1，主任务下达时间为s1，提交结果归档时间为e2，抢单时间为s2，则主任务工作效率l＝(e1-s1)/(e2-s2)。假设l≥150％，则工作效率奖励积分r2＝r1+5；

假设主任务进行测试监控环节时间为e3，主任务下达时间为s3，则主任务抢单响应时效t1＝e3-s3；假设t1≥150％，则抢单响应失效奖励积分r3＝r1+5；

假设子任务期望完成时间为e4，子任务下达时间为s4，提交结果归档时间为e5，抢单时间为s5，则子任务工作效率l1＝(e4-s4)/(e5-s5)；假设l1>＝150％，则子任务工作效率奖励积分r4＝r+5；

假设子任务进行测试监控环节时间为e6，子任务下达时间为s6，则子任务抢单响应时效t2＝e6-s6；假设t2>＝150％，则抢单响应失效奖励积分r4＝r1+5。

为方便软件测试申请转换为测试任务列表，可预先设定软件测试申请的格式。进一步地，在将软件测试申请转换为测试任务列表之前，还包括：

审核软件测试申请，判断软件测试申请是否符合预设格式；

如果是，则进入将所述软件测试申请转换为测试任务列表的步骤。

当软件测试申请不符合预设格式，即系统无法读取全部关键信息时，则驳回软件测试申请，待测试发起人重新提交软件测试申请。

接收测试发起人提交的软件测试申请，在软件测试申请符合预设格式时，按预设的转换方式提取关键信息，拆分出测试任务，为每个测试任务关联预设的积分规则，从而将软件测试申请转换为测试任务列表。

s11：发布测试任务列表以供抢单，并根据时间顺序下发被抢单的测试任务。

在现有技术中，根据测试需求分解的测试任务后，需要人工指派给对应的测试部门或者测试工程师。但是测试任务分配人员可能并不能客观了解每个测试工程师的能力和擅长领域，而测试工程师的任务都是被分配人员指派的，只能被动接受，而无法直接选择自己擅长的任务。

因此在本步骤中，将测试任务列表发布到对所有测试工程师公开的平台，测试工程师可以根据自己擅长的领域以及空闲时间，主动选取测试任务。

按抢单的时间先后顺序，系统自动将测试任务发放给最先抢到测试任务的测试工程师。进一步地，在系统中将被抢单的测试任务标记为执行中，具体实施如下：

对于已经被抢单的测试任务，后台web应用部分新建jenkinsjob项目，根据job时间表达式，自动构建jenkin任务；

变更执行记录表状态，变更测试任务列表中被抢单的测试任务的状态为执行中；

日志分析解析后台日志文件状态，并记录每次读取的行数；更新后台状态并同步后台日志；

对于已完成的测试任务，更新测试任务列表中对应的测试任务的状态为已完成，新增执行信息记录表记录，调用gitapi，将测试日志/报告上传到git代码仓库。

另外，对于开展方式为任务下达的测试任务，可直接发送给指定的测试联系人。测试联系人领取测试任务后提交给业务测试负责人。

s12：接收各被抢单的测试任务的测试结果，按各被抢单的测试任务的积分规则分发对应的积分。

测试工程师完成测试任务后，上传测试结果。接收测试工程师上传的测试结果，按照测试工程师抢单的速度，测试任务的难易程度、紧急程度，完成时间等对该次测试任务进行评分，并将积分加入该测试工程师名下，作为工作量统计的依据。

进一步地，为了方便后续查看、调用与分析，在接收各被抢单的测试任务的测试结果之后，还包括：保存各测试任务的测试脚本和测试日志。对测试任务的脚本数据进行统一管理，为自动化测试提供基础数据支撑，同时系统记录测试脚本变更的版本数据，提供用户对不同版本间的脚本内容进行比对的功能。

另外，还可以通过脚本录制器给测试工程师等用户提供自行录制自动化测试脚本的功能，脚本录制器支持脚本修改、调测、回放、导出等功能，并可实时查看脚本运行日志，跟踪脚本运行状况。同时录制得到的测试脚本可直接保存到测试脚本库，方便自动化测试数据调用。

本发明实施例提供的软件测试的管理方法，先将软件测试申请转换为测试任务列表，即拆分为多个测试任务，并预先设定好每个测试任务的积分规则，下发测试任务列表让测试人员对测试任务进行抢单，并根据与测试任务对应的积分规则进行评分。改现有技术中测试人员被动接受测试任务为测试人员主动抢单，使得测试人员可以根据自身条件选择测试任务，使测试任务得到更加合理的分配，从而提高了软件测试的质量和效率。而采用预设的积分规则对各测试任务进行评价，相比于现有技术中的人工审核，避免了人为主观误判的问题，提高了测试人员的工作积极性，也进一步提高了软件测试的质量和效率。

图2为本发明实施例提供的第二种软件测试的管理方法的流程图。如图2所示，在上述实施例的基础上，在另一实施例中，在步骤s11之后，还包括：

s20：接收上传的测试计划。

由于许多测试任务需要重复执行，而重复执行的过程可以由系统完成。为加快测试任务的实施，测试工程师可以上传测试计划，由测试任务发起者判断如何实施。接收测试工程师上传的测试计划，并将测试计划发送到测试任务发起者端，供测试任务发起者选择执行。

如果测试任务可以通过录制测试脚本，之后自动执行录制的脚本来完成，那么测试工程师可以上传录制好的脚本。

s21：依据测试计划完成与测试计划对应的测试任务。

根据测试任务发起者的指令触发测试计划，按测试计划完成测试任务。可以提供用户触发和系统自动触发两种方式。

测试任务发起者可以根据实际需要，人工主动触发一次测试计划执行操作，系统会实时生成一条自动测试任务数据，该任务立即自动执行，通过调用集成的第三方测试工具接口，按照计划的测试场景顺序，实时运行计划中的脚本信息，实现测试计划的自动执行，并对执行过程及执行结果数据进行保存。

系统根据制定的测试计划内容，生成一条或多条自动测试任务数据(计划周期为非单次的计划，都将生成多条自动测试任务)，每条测试任务的自动运行时间由计划周期决定。当测试任务的自动运行时间达到后，系统通过调用集成的第三方测试工具接口，自动执行该次测试任务，并对执行过程数据及执行结果进行保存。

本发明实施例提供的软件测试的管理方法，对于一些可以重复执行、不需要全程依赖手动完成的测试任务，可以根据测试工程师上传的测试计划完成，从而提高了软件测试的效率，节约了人力。

图3为本发明实施例提供的第三种软件测试的管理方法的流程图。如图3所示，在上述实施例的基础上，在另一实施例中，步骤s12具体包括：

s30：接收各被抢单的测试任务的测试结果。

s31：检查各测试结果，判断是否合格；如果是，则对该测试任务返回步骤s11；如果否，则进入步骤s32。

s32：按各被抢单的测试任务的积分规则分发对应的积分。

在具体实施中，在接收到各被抢单的测试任务的测试结果后，可以对各测试结果进行全面检查或抽查，当发现不合格的结果时，记当前的测试任务未完成，不予积分，并将该测试任务重新发布到抢单平台等待抢单。

如果测试任务需要录制脚本，可以对测试脚本进行审核，当审核不通过时，返回给测试工程师重新录制，当审核通过时，再由相关测试负责人开展测试任务。

本发明实施例提供的软件测试的管理方法，通过对测试结果进行审核，将审核不通过的测试任务重新发布，进一步提高了软件测试任务的完成质量。

图4为本发明实施例提供的第四种软件测试的管理方法的流程图。如图4所示，在上述实施例的基础上，在另一实施例中，在步骤s12之后，还包括：

s40：按预设的维度对测试结果进行统计分析。

为了更好地呈现软件测试的结果，还可以按预设的维度对测试结果进行统计分析，提供按照测试时间、测试系统、测试分类等维度，对测试质量指标进行统计分析及呈现的功能。

统计分析的维度可以包括测试时间、测试系统、测试分类等，不同测试分类的统计分析指标不同。

代码检查的统计指标可以包括代码总行数、bug数、漏洞数、代码重复率、代码覆盖率、代码注释率等。

功能测试的统计指标可以包括测试用例覆盖率、测试用例通过率(按模块来统计覆盖率)等。

性能测试的统计指标可以包括并发用户数、持续时间、平均响应时长、tps、事务成功率、服务器资源占用情况(cpu使用率、内存页交换率、网络传输率)等。

安全测试的统计指标可以包括安全问题数(高风险/中风险/低风险)等。

统计分析提供逐级穿透查看功能，先呈现按照测试时间、测试系统、测试分类来统计的该段时间内该系统的该类测试中产生的指标总数，点击可穿透到各个模块的统计指标数，再穿透可看到该指标值所关联的测试任务集合数据。

上文详述了软件测试的管理方法对应的各个实施例，在此基础上，本发明还公开了与上述方法对应的软件测试的管理装置。

图5为本发明实施例提供的一种软件测试的管理方法的结构示意图。图6为本发明实施例提供的一种众测管理系统的技术架构图。

如图5所示，软件测试的管理装置包括：

转换单元501，用于接收软件测试申请，并按预设的转换方式将软件测试申请转换为测试任务列表；其中，测试任务列表包括测试任务，以及与测试任务对应的积分规则；

发布单元502，用于发布测试任务列表以供抢单，并根据时间顺序下发被抢单的测试任务；

评分单元503，用于接收各被抢单的测试任务的测试结果，按各被抢单的测试任务的积分规则分发对应的积分。

一种众测管理系统的框架如图6所示，测试脚本通过脚本录制器由用户实际操作取得，默认标准格式为json。之后，将脚本提交到git服务器保存。定期从git服务器中更新脚本，翻译成java代码，提交回git服务器。通过jenkins自动化集成工具，配置好定时maven项目。定时从git服务器中更新项目java代码，运行测试脚本。

众测管理平台存储层采用关系型数据库加git代码仓库模式。mysql存储相关配置数据，和测试用例日志信息。git代码仓库用于存放测试脚本，和通过脚本翻译成的java代码。sonatypenexus为maven私服，用于存放编译运行java测试用例代码所需依赖包。

操作系统按服务器和测试节点，可分为两种类型，服务器的操作系统采用centos7，测试节点由于需要测试ie浏览器，所以统一采用win系列操作系统，根据ie版本需要选用win7或win10版本。

由于git代码仓库具有分布式的特点，其代码同样存储在其他测试节点上。因此，git代码仓库不需要考虑灾备问题，其数据可以从其他节点得到恢复。各测试节点，由于需要测试不同版本的ie浏览器，因此需要对应的windows操作系统。由于ie浏览器不能多版本同时安装，因此，一个节点只能测试一种版本的浏览器。

应用层采用jdk1.8编译和运行所有java程序，编译构建采用maven构建规范。由jenkins做统一管理调度。测试用例通过selenium-server中的webdriver驱动模块，控制ie或chrome浏览器的行为，达到自动测试的目的。

jenkins在整个机构体系中处于中心协调作用。它负责将配置好的测试项目分发到对应测试节点进行测试。并提供了相应的javaapi供web应用调用，除可以控制对应测试项目的运行和停止外，还可查询对应测试项目的基本信息，测试结果信息等相关信息供页面显示。

可选的，转换单元501还可以包括：

第一审核子单元，用于审核软件测试申请，判断软件测试申请是否符合预设格式；如果是，则进入将软件测试申请转换为所述测试任务列表的步骤。

评分单元503还可以包括：

第二审核子单元，用于检查各所述测试结果，判断是否合格；如果否，则通知发布单元502重新发布与测试结果对应的测试任务。

软件测试的管理装置还可以包括：

接收单元，用于接收上传的测试计划；依据测试计划完成与测试计划对应的测试任务。

软件测试的管理装置还可以包括：

存储单元，用于保存各测试任务的测试脚本和测试日志。

软件测试的管理装置还可以包括：

统计单元，用于按预设的维度对测试结果进行统计分析。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

图7为本发明实施例提供的一种软件测试的管理设备的结构示意图。如图7所示，该软件测试的管理设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)710(例如，一个或一个以上处理器)和存储器720，一个或一个以上存储应用程序733或数据732的存储介质730(例如一个或一个以上海量存储设备)。其中，存储器720和存储介质730可以是短暂存储或持久存储。存储在存储介质730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算装置中的一系列指令操作。更进一步地，处理器710可以设置为与存储介质730通信，在软件测试的管理设备700上执行存储介质730中的一系列指令操作。

软件测试的管理设备700还可以包括一个或一个以上电源740，一个或一个以上有线或无线网络接口750，一个或一个以上输入输出接口770，和/或，一个或一个以上操作系统731，例如windowsserver^tm，macosx^tm，unix^tm,linux^tm，freebsd^tm等等。

上述图1至图4所描述的软件测试的管理方法中的步骤由软件测试的管理设备基于该图7所示的结构实现。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的软件测试的管理设备及计算机可读存储介质的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法、装置设备及计算机可读存储介质，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

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

集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，功能调用装置，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本发明所提供的一种软件测试的管理方法、装置及设备进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。