CN112148587A - 一种软件测试管理系统和方法 - Google Patents

Abstract

本发明公开软件测试管理系统和方法，既进行测试用例生命周期的管理，又对测试用例的执行进行驱动和结果收集，还可从上线发布包追溯到测试用例，为版本质量提供透明的质量反馈数据。其技术方案为：本发明包含现有测试系统的通用优点，能管理测试用例、测试任务、测试结果，为测试过程提供清晰管理。本发明使测试用例和测试需求进行关联性管理，方便测试需求分析，为设计测试用例查漏补缺。本发明集成不同自动化测试用例，构建自动化用例流水线，弥补现有系统无法管理自动化用例短板。本发明关联显示运行待测包，延伸测试数据时效性，保持与线上数据一致，方便线上问题追踪。本发明丰富了测试数据度量指标，能为开发、测试、运维和管理者提供数据支持。

Description

一种软件测试管理系统和方法

技术领域

本发明涉及一种软件测试用例管理技术，具体涉及一种测试用例和结果管理的系统和方法，能够为开发测试效率赋能。

背景技术

随着计算机系统发展越来越迅速，办公流程电子化程度越来越高，企业级软件开发集成度越来越高，软件复杂度越来越高，依赖的相关系统越来越多。那么，软件的边界测试，可能需要由不同的测试团队负责。因此，不同测试团队的沟通和交流变的越来越频繁；为了能使不同测试团队之间工作效率提升，减少重复劳动，一个好的测试管理系统是必不可少。

现存的一些企业级和开源的测试管理系统，都比较偏向于测试用例管理；而对于自动化用例执行管理和用例执行结果管理兼容性不是很好。比如开源的TestLink和禅道，它们对于测试用例管理能够根据不同的项目进行统一的归类，然后对于用例导入测试管理系统后，无法改变用例的公共属性，不能把一些用例设置为多个项目共享的，并且对于自动化测试的用例，无法通过平台上触发执行。

目前市面上比较流行的测试管理工具有QC、Mantis、BugZilla、TestLink、Redmine等，这些软件的各自侧重点不同：比如Mantis、BugZilla偏重缺陷管理，TestLink则偏重测试用例管理，QC则更加全面，Redmine项目管理的概念又更强一些。虽然他们可以很好的进行需求到用例的追溯，但是这些用例却不能够进行反向的逆回溯。比如，一个线上的上线包，测试了哪些测试用例；系统的某个组件，测试了哪些测试用例。这些数据的追溯，目前市场上的测试管理系统都无法做。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种软件测试管理系统和方法，既可以进行测试用例生命周期的管理，又可以对测试用例的执行进行驱动和结果的收集，还可从上线发布包追溯到测试用例，为版本质量提供透明的质量反馈数据。

本发明的技术方案为：本发明揭示了一种软件测试管理系统，系统包括：

用户交互界面层，用于提供用户与界面的交互，以及展示软件测试的度量数据；

测试用例管理模块，用于提供测试用例的新建、查询和导入；

测试任务管理模块，用于提供测试任务的新建，在测试任务中添加或删除测试用例，对测试任务的进度、测试任务的执行人、测试任务的通知进行管理；

测试结果管理模块，用于提供测试任务对应的测试结果的展示和管理；

测试需求和测试发布包管理模块，用于测试任务中测试用例集关联测试需求的管理以及测试任务中的测试用例通过与每次上线的测试发布包进行关联，以实现测试发布包维度的测试度量数据；

测试度量模块，用于展示测试数据度量指标；

测试调度模块，用于调度自动化测试用例的执行，管理自动化测试用例；

测试结果收集模块，用于收集自动化测试用例的执行结果，并与相关的测试任务进行关联；

数据库模块，用于存储测试用例。

根据本发明的软件测试管理系统的一实施例，测试任务管理模块中测试任务通知管理进一步包括：测试团队成员根据自己与测试任务的相关性，自行订阅测试任务变化的通知；或者由测试组长进行选择通知范围；测试任务通知内容包括：测试任务执行进度，测试任务是否发现编码错误，测试成员是否添加测试提醒项。

根据本发明的软件测试管理系统的一实施例，测试任务管理模块还配置为通知测试人员是否被分配了测试任务，由测试管理人员订阅测试任务的通知，并定时推送测试任务动态。

根据本发明软件测试管理系统的一实施例，测试结果管理模块还配置为提供测试用例与测试结果的关联关系管理，测试用例的历史测试结果查询，测试迭代的测试结果查询，以及测试任务的测试结果查询。

根据本发明的软件测试管理系统的一实施例，测试度量模块中测试数据度量指标包括：测试人员新建测试用例统计图表、测试用例执行情况统计图表、不同测试系统测试用例对比图表、每周新增测试用例图表、每月新增测试用例图表；其中测试用例执行情况统计图表进一步包括：用户与测试用例关系展示图，测试用例与测试迭代展示图，测试用例与测试结果关系展示图。

根据本发明的软件测试管理系统一实施例，测试调度模块由调度服务器和执行机构成，其中调度服务器采用jenkins进行调度，在对应的执行机上执行对应的测试用例。

根据本发明的软件测试管理系统的一实施例，测试结果收集模块部署在各个单独执行机上，调度服务器、测试用例管理模块、测试任务管理模块、测试结果管理模块、测试需求和测试发布包管理模块、测试度量模块部署于服务器端，用户交互界面层部署于浏览器客户端上。

根据本发明的软件测试管理系统的一实施例，测试结果收集模块上传测试结果，还用于配置为解析自动化测试用例的执行结果。

本发明还揭示了一种软件测试管理方法，在如上所述的软件测试管理系统上运行，方法包括自动化测试中进行一次测试迭代的流程：

创建一个测试任务，关联对应开发任务迭代；

创建测试执行流水线；

手动触发流水线执行；

流水线执行结束后，人工找到执行失败的测试用例，关联对应的编码错误。

根据本发明的软件测试管理方法的一实施例，方法还包括手动进行一次测试迭代的流程：

用户通过用户交互界面层新增测试用例，在新增测试用例时选择测试用例所属的测试系统或者将测试用例设置为公共测试用例；或者用户通过将本地编写好的测试用例，按照系统下载的用例模板，上传本地测试用例到软件测试管理系统中；

创建一个测试任务，测试任务设置为归属某一开发任务迭代；

将测试用例加入到测试任务中；

在加入到测试任务的测试用例的测试用例集上，关联测试需求；

用户通过用户交互界面层设置测试用例执行结果；

导入自动化测试用例结果；

测试结果关联成功后，将测试用例执行结果关联此次执行的系统部署包；

关联测试过程中发现的编码错误。

本发明对比现有技术有如下的有益效果：一、包含现有测试系统的通用优点，能够有效管理好测试用例，测试任务，测试结果，为测试过程提供清晰管理。二、本发明能够使得测试用例和测试需求进行关联性的管理，方便测试需求分析，设计测试用例查漏补缺。三、本发明集成不同的自动化测试用例，构建自动化用例流水线，弥补了现有用例管理系统无法管理自动化用例的短板。四、本发明能够关联显示运行待测包，延伸了测试数据的时效性，与线上数据相一致，方便线上问题追踪。五、本发明丰富了测试数据的度量指标，能够为开发、测试、运维和管理者提供有力的数据支持。综上，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的软件测试管理系统的一实施例的模块结构示意图。

图2示出了本发明的软件测试管理系统的一实施例的部署结构示意图。

图3示出了本发明的软件测试管理系统中手动进行一次测试迭代的流程图。

图4示出了本发明的软件测试管理系统自动化进行一次测试迭代的流程图。

图5示出了本发明的测试度量指标。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

本实施例是对特定例子的部件和设置进行描述。本发明还可以根据实际的企业数据规模，采用不同的部署和实施方式，加以应用。本实施例中各个细节，不一定需要严格按照给出的实例进行比例绘制，规模可以自己调节。

图1示出了本发明的软件测试管理系统的一实施例的模块结构。如图1所示，本实施例的软件测试管理系统包括以下模块：用户交互界面(UI)层、测试用例管理模块、测试任务管理模块、测试结果管理模块、测试需求和测试发布包管理模块、测试度量模块、测试调度模块、测试结果收集模块、数据库模块。

数据库模块和用户交互界面层，均与其他的测试用例管理模块、测试任务管理模块、测试结果管理模块、测试需求和测试发布包管理模块、测试度量模块、测试调度模块建立数据连接。测试结果收集模块和测试用例管理模块建立数据连接。

用户交互界面层用于提供用户与界面的交互，以及展示软件测试的度量数据。

测试用例管理模块用于提供测试用例新建，测试用例查询，测试用例导入。

测试任务管理模块，用于提供测试任务新建，测试任务添加测试用例，测试任务删除测试用例，测试任务进度管理，测试任务执行人管理，测试任务通知管理等功能。

测试任务通知管理是指测试团队成员，可以根据自己与测试任务相关性，自行订阅测试任务变化通知；也可以由测试组长进行选择通知范围。通知的内容包括：测试任务执行进度，测试任务是否发现BUG(编码错误)，测试成员是否添加测试提醒项。

测试任务管理模块还可以通知对应测试人员，是否被分配了测试任务，测试管理人员可以订阅测试任务的通知，定时推送测试任务动态。

测试结果管理模块，用于提供测试任务对应的测试结果展示和管理，设置测试任务中用例结果，以及关联测试结果对应的BUG(编码错误)等。

提供测试用例与测试结果关联关系管理，测试用例历史测试结果查询，测试迭代的测试结果查询，测试任务的测试结果查询。

测试需求和测试发布包管理模块，用于测试任务中测试用例集关联测试需求对应的JIRA号(JIRA是Atlassian公司出品的项目与事务跟踪工具)，通过测试需求复盘整个测试迭代。复盘的内容包括：哪些测试需求已经完成测试，哪些测试需求没有完成测试，哪些测试需求测试比重比较大等。测试需求在JIRA上进行登记，本实施例的软件测试管理系统关连JIRA上对应的地址。也可以采用其他方式管理测试需求。

测试任务中的测试用例通过与每次上线的测试发布包进行关联，从而实现一个测试发布包维度的测试度量数据，进而分析每次上线测试发布包的质量情况。

测试度量模块用于展示测试数据度量指标，测试数据度量指标例如包括：测试人员测试用例新建、执行情况的统计图表；不同测试系统测试用例对比图表，每周新增测试用例、每月新增测试用例图表等。

测试用例执行情况的统计图表进一步包括：用户与测试用例关系展示图，测试用例与测试迭代展示图，测试用例与测试结果关系的展示图等度量指标。

测试调度模块用于调度自动化测试用例执行，管理自动化测试用例。测试调度模块由调度服务器(server)和执行机(agent)构成，调度服务器一般采用jenkins进行调度，执行何种类型测试用例，一般在对应的执行机上进行执行。其中，jenkins是一个开源CI&CD软件领导者，提供超过1000个插件来支持构建、部署、自动化，满足任何项目的需要，能够根据标签管理和调度不同的测试环境。

测试结果收集模块，用于收集自动化测试用例执行结果，并与相关的测试任务进行关联。包括解析基于JUnit(JUnit是一个Java语言的单元测试框架)单元测试用例执行结果，以及某一自定义的自动化测试用例执行结果。

如果需要能够支持上传企业自身开发的自动化测试工具执行结果，则需要在测试结果收集模块中开发对应插件，解析自动化测试用例的执行结果。

数据库模块用于存储测试用例，例如采用图示的mysql数据库。

图2示出了本发明的软件测试管理系统的一实施例的部署结构。如图2所示，软件测试管理系统可部署为包括服务器、浏览器客户端、执行机和数据库的平台，服务器与数据库连接，用于管理全部测试用例、测试任务、测试度量，以及调度测试任务。执行机器用于管理自动化测试用例执行，通过服务器的测试调度模块选择不同任务，执行不同执行机上的自动化测试用例。图1所示的各模块按照图2所示的部署结构的部署方式为：测试结果收集模块部署在执行机上，调度服务器、测试用例管理模块、测试任务管理模块、测试结果管理模块、测试需求和测试发布包管理模块、测试度量模块部署于服务器端，用户交互界面层部署于浏览器客户端上。

基于图2部署，由图1中各模块组成的测试管理系统上，运行一种测试管理方法，实现了测试过程中数据的可追溯。图3示出了此种测试管理方法中手动进行一次测试迭代的步骤，详述如下。

步骤S11：用户可以通过用户交互界面层进行测试用例新增，在新增测试用例时，可以选择测试用例所属的测试系统；或者将测试用例设置为公共测试用例，如果测试用例设置为公共测试用例，那么在不同团队之间便可以进行测试用例共享。

步骤S12：此步骤是与步骤S11平行，没有先后顺序。用户通过将本地编写好的测试用例，按照系统下载的用例模板，上传本地测试用例到软件测试管理系统中。

步骤S13：创建一个测试任务，测试任务可以设置为归属某个开发任务迭代。开发任务迭代可以上传为附件，作为测试任务附件；也可以关联第三方链接地址。新建测试任务时，可以指定测试人员和相关的知悉人员。

上述说开发任务迭代，是通过JIRA进行新建，或者可以通过Excel等其他方式进行管理。

步骤S14：将测试用例加入到测试任务中。

所加入的测试用例，可以选择公共测试用例，也可以选择用户可见的系统下测试用例。可以选择多个系统的测试用例添加到测试任务中。

步骤S15：测试用例集关联需求，根据步骤S14中加入的测试用例，在这些所属的测试用例的测试用例集上，关联测试需求。

步骤S16：用户通过用户交互界面层设置测试用例执行结果，如果测试用例执行人与应执行人不一致，那么会进行邮件提醒应执行人，用例结果已设置。设置用例结果时，只有属于开发任务小组成员，才可设置测试结果，否则无权设置。

步骤S17：导入自动化测试用例结果，如果用例执行是自动化用例，那么可以采用测试结果收集模块。上传时，需要带上测试任务名作为参数，系统会将自动化测试用例与测试任务中用例进行匹配，如果匹配上，那么将对应的测试任务中的用例结果设置为自动化用例的执行结果。

步骤S18：测试结果关联成功后，可以将测试用例执行结果关联此次执行的系统部署包。

用例关联部署包可以进行批量设置，也可以进行单一设置。

步骤S19：关联测试过程中发现的BUG，用户可以在测试结果属性上，填写对应的BUG信息，也可以链接第三方BUG管理工具上对应的BUG链接。

如图4所示，测试管理方法中的自动化进行一次测试迭代的流程包括以下步骤。

步骤S21：创建一个测试任务，关联对应开发任务迭代。

步骤S22：创建测试执行流水线。

用户可以在此步骤下编制测试过程中需要执行的步骤顺序。用户可以从执行机列表下选择需要执行的自动化测试用例，按照顺序进行排列。上传执行结束后的测试执行结果，用户可以编写运行测试结果收集模块上传命令。邮件通知，用户可以在流水线中加入一个步骤，执行结束后是否进行邮件通知。关联待测系统包，用户可以在流水线中，配置需要待测的系统包。用户通过构造这样的一整条流水线，实现测试流程的全过程自动化。

执行机列表，每个列表下包含该执行机器的IP地址，机器上运行的测试用例集，并行线程数等属性。

如测试流水线的步骤为：执行自动化测试用例A，上传自动化测试用例结果A，执行自动化测试用例B，上传自动化测试结果B，发送执行结束通知，关联用例执行的待测包，发送执行结果分析图表邮件。每个流水步骤的命令都进行了标准化的封装。比如执行测试用例：run[测试用例集名称]；上传测试结果命令：upload[测试集名称]；发送执行结束通知：notify[流水线名称]；关联待测包：relation[软件系统包名][测试用例集名称]；发送测试分析结果：sendEmalAnysis[流水线名称]。

步骤S23：手动触发流水线执行。

流水线执行过程中，首先解析自动化用例，将待执行的自动化测试用例添加到测试计划中；然后根据流水线的配置，连接对应执行机器，通过执行机器上内置的jenkinsagent执行其上的自动化测试用例；待所有测试用例执行完成后。将回到服务器端机器，服务器端机器根据流水线的配置，执行下一个步骤，如将自动化测试用例结果自动上传，此时服务器端会去调度下一个执行机，执行用例上传操作。以此类推，直到流水线的步骤全部执行结束，整个测试任务就执行结束了。

步骤S24：流水线执行结束后，需要人工找到执行失败的测试用例，关联对应的测试BUG，至此整个测试任务结束了。

测试执行结束后，本实施例的软件测试管理系统的一个重要功能就是管理数据，那么接下来，就是本发明的系统与现有软件测试管理工具最大不同点，提供了多维度的数据分析功能，真正的能够利用好这些数据，为整个软件的研发周期提供数据支持。

如图5所示，本实施例的测试管理方法的一些度量指标和含义：

度量指标Q501，查询一段时间内用户执行用例数，既可以查询手工用例数，又可以查询自动化用例数。此数据可以用来评估测试人员工作量。

度量指标Q502，查询一段时间内系统执行用例数，同理可以查看手工用例和自动化用例，以及显示其比例。此数据可以评估系统的自动化程度，以及系统的开发任务繁忙度，依次确定投入人员。

度量指标Q503，查询一段时间内系统发现BUG数，此数据可以判断系统的风险性，是否需要加大测试力度。

度量指标Q504,查询一段时间内，哪些用例测试了BUG，此数据用于复盘用例，作为参考用例。

度量指标Q505，查询一段时间内测试人员新增测试用例数。

度量指标Q506，查询一段时间内系统新增用例数，同理可以查看手工用例和自动化用例，以及显示其比例。此数据可以评估系统的自动化程度，以及系统的开发任务繁忙度，依据此确定投入人员。

度量指标Q507，查询一段时间内测试任务执行实际分布，此数据可以查看哪些测试任务耗时比较长，可以最为自动化用例开发的优先级标准。

度量指标Q508，查询测试执行报告，可以查看历史的迭代报告。

度量指标Q509，查询测试系统版本包BUG列表,可以回顾开发质量。

度量指标Q510，查询测试系统版本包测试的用例数。

度量指标Q511，查询TOP用例的复用率。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (10)

1.一种软件测试管理系统，其特征在于，系统包括：

用户交互界面层，用于提供用户与界面的交互，以及展示软件测试的度量数据；

测试用例管理模块，用于提供测试用例的新建、查询和导入；

测试任务管理模块，用于提供测试任务的新建，在测试任务中添加或删除测试用例，对测试任务的进度、测试任务的执行人、测试任务的通知进行管理；

测试结果管理模块，用于提供测试任务对应的测试结果的展示和管理；

测试需求和测试发布包管理模块，用于测试任务中测试用例集关联测试需求的管理以及测试任务中的测试用例通过与每次上线的测试发布包进行关联，以实现测试发布包维度的测试度量数据；

测试度量模块，用于展示测试数据度量指标；

测试调度模块，用于调度自动化测试用例的执行，管理自动化测试用例；

测试结果收集模块，用于收集自动化测试用例的执行结果，并与相关的测试任务进行关联；

数据库模块，用于存储测试用例。

2.根据权利要求1所述的软件测试管理系统，其特征在于，测试任务管理模块中测试任务的通知管理进一步包括：测试团队成员根据自己与测试任务的相关性，自行订阅测试任务变化的通知；或者由测试组长进行选择通知范围；测试任务通知的内容包括：测试任务执行进度，测试任务是否发现编码错误，测试成员是否添加测试提醒项。

3.根据权利要求2所述的软件测试管理系统，其特征在于，测试任务管理模块还配置为通知测试人员是否被分配了测试任务，由测试管理人员订阅测试任务的通知，并定时推送测试任务动态。

4.根据权利要求1所述的软件测试管理系统，其特征在于，测试结果管理模块还配置为提供测试用例与测试结果的关联关系管理，测试用例的历史测试结果查询，测试迭代的测试结果查询，以及测试任务的测试结果查询。

5.根据权利要求1所述的软件测试管理系统，其特征在于，测试度量模块中的测试数据度量指标包括：测试人员新建测试用例统计图表、测试用例执行情况统计图表、不同测试系统测试用例对比图表、每周新增测试用例图表、每月新增测试用例图表；其中测试用例执行情况统计图表进一步包括：用户与测试用例关系展示图，测试用例与测试迭代展示图，测试用例与测试结果关系展示图。

6.根据权利要求1所述的软件测试管理系统，其特征在于，测试调度模块由调度服务器和执行机构成，其中调度服务器采用jenkins进行调度，在对应的执行机上执行对应的测试用例。

7.根据权利要求6所述的软件测试管理系统，其特征在于，测试结果收集模块部署在执行机上，调度服务器、测试用例管理模块、测试任务管理模块、测试结果管理模块、测试需求和测试发布包管理模块、测试度量模块部署于服务器端，用户交互界面层部署于浏览器客户端上。

8.根据权利要求1所述的软件测试管理系统，其特征在于，测试结果收集模块上传测试结果，还用于配置解析自动化测试用例的执行结果。

9.一种软件测试管理方法，其特征在于，在如权利要求1至7中任一项所述的软件测试管理系统上运行；方法包括自动化测试中进行一次测试迭代的流程：

创建一个测试任务，关联对应开发任务迭代；

创建测试执行流水线；

手动触发流水线执行；

流水线执行结束后，人工找到执行失败的测试用例，关联对应的编码错误。

10.根据权利要求9所述的软件测试管理方法，其特征在于，方法还包括手动进行一次测试迭代的流程：

用户通过用户交互界面层新增测试用例，在新增测试用例时选择测试用例所属测试系统或者将测试用例设置为公共测试用例；或者用户通过将本地编写好的测试用例，按照系统下载的用例模板，上传本地测试用例到软件测试管理系统中；

创建一个测试任务，测试任务设置为归属某一开发任务迭代；

将测试用例加入到测试任务中；

在加入到测试任务的测试用例的测试用例集上，关联测试需求；

用户通过用户交互界面层设置测试用例执行结果；

导入自动化测试用例结果；

测试结果关联成功后，将测试用例执行结果关联此次执行的系统部署包；

关联测试过程中发现的编码错误。

Images