CN110134585A

CN110134585A - 系统测试计划生成方法及终端设备

Info

Publication number: CN110134585A
Application number: CN201910294677.3A
Authority: CN
Inventors: 张瑞宁
Original assignee: Ping An Puhui Enterprise Management Co Ltd
Current assignee: Ping An Puhui Enterprise Management Co Ltd
Priority date: 2019-04-12
Filing date: 2019-04-12
Publication date: 2019-08-16

Abstract

本发明适用于计算机应用技术领域，提供了一种系统测试计划生成方法、终端设备及计算机可读存储介质，包括：通过获取待测试的目标系统的系统标识；根据所述系统标识确定所述目标系统中所包含的用户场景描述；根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。通过制定需求维度的测试计划，无需在子系统层面单独制定测试计划，便可以自动生成系统层面的测试计划，提高了需求测试计划和系统测试计划的生成效率，便于案例管理和执行。

Description

系统测试计划生成方法及终端设备

技术领域

本发明属于计算机应用技术领域，尤其涉及一种系统测试计划生成方法、终端设备及计算机可读存储介质。

背景技术

软件测试是保障软件质量的重要方法.由于全球广域网(World Wide Web， Web)即服务涉及因素众多，与其测试相关的方法和技术也很多，可以从功能、性能、安全性等多个方面进行考虑。测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。它是对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，它只是测试的一个框架，所以不一定要太过详细。

但是在现有的测试管理过程中，需求维度和子系统维度都需要产出测试进度报告，但若以需求维度制定测试计划，则系统维度的测试报告则无法产出，这将造成系统测试计划的生成效率较低的问题。

发明内容

有鉴于此，本发明实施例提供了一种系统测试计划生成方法、终端设备及计算机可读存储介质，以解决现有技术中系统测试计划的生成效率较低的问题。

本发明实施例的第一方面提供了一种系统测试计划生成方法，包括：

获取待测试的目标系统的系统标识；

根据所述系统标识确定所述目标系统中所包含的用户场景描述；

根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；

根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。

本发明实施例的第二方面提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

获取待测试的目标系统的系统标识；

本发明实施例的第三方面提供了一种终端设备，包括：

获取单元，用于获取待测试的目标系统的系统标识；

确定单元，用于根据所述系统标识确定所述目标系统中所包含的用户场景描述；

查找单元，用于根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；

生成单元，用于根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。

本发明实施例的第四方面提供了一种计算机可读存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行上述第一方面的方法。

本发明实施例与现有技术相比存在的有益效果是：

本发明实施例通过获取待测试的目标系统的系统标识；根据所述系统标识确定所述目标系统中所包含的用户场景描述；根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。通过制定需求维度的测试计划，无需在子系统层面单独制定测试计划，便可以自动生成系统层面的测试计划，提高了需求测试计划和系统测试计划的生成效率，便于案例管理和执行。

附图说明

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

图1是本发明实施例一提供的系统测试计划生成方法的流程图；

图2是本发明实施例二提供的系统测试计划生成方法的流程图；

图3是本发明实施例三提供的终端设备的示意图；

图4是本发明实施例四提供的终端设备的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

为了说明本发明所述的技术方案，下面通过具体实施例来进行说明。

参见图1，图1是本发明实施例一提供的系统测试计划生成方法的流程图。本实施例中系统测试计划生成方法的执行主体为终端。终端包括但不限于智能手机、平板电脑、可穿戴设备等移动终端，还可以是台式电脑等。如图所示的系统测试计划生成方法可以包括以下步骤：

S101：获取待测试的目标系统的系统标识。

作为计算机系统的重要组成部分，计算机软件在开发完成之后将会和系统中的其他部分集合成为一个整体，但是在此过程中需要对其进行系统的集成和确认测试。对于相关测试的详细说明已经完全超过软件工程的基本范畴，而相关测试工作也不可能仅仅由开发人员完成。系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。

系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。系统测试的目的是验证最终软件系统是否满足用户规定的需求，系统测试主要可以包括功能测试和健壮性测试，其中，功能测试即测试软件系统的功能是否正确，其依据是需求文档，如产品需求规格说明书。由于正确性是软件最重要的质量因素，所以功能测试必不可少；健壮性测试即测试软件系统在异常情况下能否正常运行的能力。系统测试的目标是：通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格说明不符合或与之矛盾的地方，从而验证软件系统的功能和性能等满足规格说明所制定的要求。

在实际应用中，应用系统是运行在企业内的单纯的软件系统，而广义的应用系统则是由标准化的管理模式、知识化的业务模型以及集成化的软件系统三个层次构成。企业应用程序必须通过重构才能快速响应企业业务流程的变化，那么，重构的易操作性和灵活性就十分重要。并且，伴随着电子商务的普及。跨企业供应链协作需求也日益增加。因此，需要有一种技术能够将构建于不同时期、不同类型的异构系统以及跨企业边界的软件系统进行灵活的整合。应用系统架构的选择实际上是在系统实现的功能与系统实现的复杂性间寻求一种折衷。在这种背景下，基于各种架构或模型的企业应用系统和系统链应运而生了。

本实施例中的目标系统为待测试的用户系统，目标系统的系统标识可以是系统名称或者网络地址等，此处不做限定。除此之外，本实施例中的目标系统的数量可以是一个或者多个，因为在很多使用环境中，一个企业运行系统中往往包括很多分支系统相互之间连接运行，可以是一个系统来实现一个小功能，还可以是多个用户系统连接来实现一个比较复杂的功能，因此，在本实施例中，目标系统的数量可以是一个或者多个，此处根据具体的测试环境或者测试对象确定。

进一步的，在测试工作开始之前，应当为软件测试的信息输入形成必要的出错处理路径；对于测试案例的设计，在此过程中主要模拟数据和软件界面可能会出现的错误，并对相关错误结果进行准确记录，继而为系统测试提供经验和帮助；同时在测试系统规划和设计过程中，必须保证软件测试自身的合理性。在系统测试过程中必然会由多个不同测试组成，其目的在于成分运行系统，从而验证所有部件能够完成既定的运行目标。

S102：根据所述系统标识确定所述目标系统中所包含的用户场景描述。

本实施例中根据每个目标系统的系统功能预设有对应的用户场景描述，可以将不同系统的用户场景描述存储在预设的测试数据库中。用户场景描述是从用户的角度来描述用户渴望得到的功能。本实施例中的用户场景描述包括三个要素：角色、活动以及商业价值，其中角色用来表示要使用这个功能的角色，活动用来表示需要完成什么样的功能或目标；商业价值用来表示为什么需要这个功能，这个功能带来什么样的价值。

示例性地，本实施例中的用户场景描述可以按照如下格式来表达：As a <Role>,Iwant to<Activity>,so that<Business Value>，即：作为一个<角色>，我想要<活动>，以便于<商业价值>。示例性地，作为一个网站管理员，想要统计每天有多少人访问了我的网站，以便于赞助商了解网站会给他们带来什么收益。需要注意的是，用户场景描述不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

本实施例中的用户场景描述可以包括以下原则来创建：独立性、可协商性、有价值以及可测试性等。其中，独立性用于表示要尽可能的让一个用户场景描述独立于其他的用户场景描述。用户场景描述之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户场景描述和分解用户场景描述来减少依赖性。可协商性用于表示一个用户场景描述的内容要是可以协商的，用户场景描述不是合同。一个用户场景描述卡片上只是对用户场景描述的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户场景描述卡带有了太多的细节，实际上限制了和用户的沟通。有价值用于表示每个故事必须对客户具有价值。一个让用户场景描述有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户场景描述并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。可以估算性用于表示开发团队需要去估计一个用户场景描述以便确定优先级、工作量、安排计划。可测试性用于表示一个用户场景描述要是可以测试的，以便于确认它是可以完成的。如果一个用户场景描述不能够测试，那么你就无法知道它什么时候可以完成。

S103：根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例。

在本方案中，预设有案例库，其中存储有各种类型的测试案例，以及这些测试案例所对应的用户场景描述，用于通过目标系统的用户场景描述，在案例库中确定与目标系统对应的目标测试案例。

具体的，目标系统的用户场景描述用于形容一个系统的适用环境，测试案例的用户场景描述用户形容一个测试案例的测试场景，我们通过目标系统的用户场景描述，来确定与目标系统的用户场景描述对应的目标测试案例。

测试案例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。是将软件测试的行为活动做一个测试案例科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试案例也是将测试具体量化的方法之一，不同类别的软件，测试案例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试案例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据(以及产品需求)，只能通过评测产品和竞争销售数据来完成。

S104：根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。

在确定了目标系统对应的测试案例之后，我们根据目标测试案例和用户场景描述，生成目标系统的系统测试计划。具体的，本实施例中的系统测试计划可以包括每个用户场景描述或者每个测试阶段对应的开始时间、结束时间以及测试类型等信息。我们通过生成目标系统的系统测试计划，便可以通过系统测试计划对该目标系统的测试流程进行管理，以监督测试进度的执行情况。

上述方案，通过获取待测试的目标系统的系统标识；根据所述系统标识确定所述目标系统中所包含的用户场景描述；根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。通过制定需求维度的测试计划，无需在子系统层面单独制定测试计划，便可以自动生成系统层面的测试计划，提高了需求测试计划和系统测试计划的生成效率，便于案例管理和执行。

参见图2，图2是本发明实施例二提供的系统测试计划生成方法的流程图。本实施例中系统测试计划生成方法的执行主体为终端。终端包括但不限于智能手机、平板电脑、可穿戴设备等移动终端，还可以是台式电脑等。如图所示的系统测试计划生成方法可以包括以下步骤：

S201：获取至少一个待检测对象的测试需求；所述测试需求包括测试时间计划、测试类型以及与所述测试需求关联的至少一个用户场景描述。

本实施例中的测试需求是主要是整理测试焦点，包括一些界面、输入域、业务流程、数据等，为测试案例的设计提供测试所需的功能点信息。测试需求的分析也会体现用例设计方法，有的测试需求分析文档中也会指导性的明确焦点的测试案例设计方法。好的测试需求能发现需求中显性和隐性的测试焦点，从而能更好的指导测试案例的设计，能更好的提高被测模块整体功能的覆盖率。测试需求分析会根据不同阶段的测试类型会有不同的侧重点，主要注重系统或软件是否满足用户需求的情况。平时做测试需求时会比较明确系统的功能模块和测试点明细整理，也可以把测试案例设计方法同时加入到分析文档中。

本实施例的测试需求可以包括测试时间计划、测试类型以及与测试需求关联的至少一个用户场景描述。其中的测试时间计划用于表示该测试需求中的每个测试任务对应的时间安排，比如某个测试任务的开始时间和结束时间，或者测试时长等信息，通过测试时间计划可以确定给每个测试任务的执行时间安排，用于对测试任务进行统一管理和监控。

实际应用中的测试类型包括但不限于三种，分别是冒烟测试、系统集成测试和回归测试。其中，系统集成测试(System Integration Test Case，SIT)即内部测试，它是根据测试案例描述测试每一个场景，优化系统性能。系统集成测试和软件一般的模块集成测试差不多，但用户参与的机会很少，主要由公司内部进行。

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。如果通过测试，功能可以正常运行，不会影响测试进行，那么这个版本才会进行下一步的测试，例如功能测试、集成测试以及系统测试等；如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。则打回开发那边重新开发；冒烟测试是自由测试的一种。冒烟测试在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为冒烟测试。在很多情况下，做冒烟测试是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。冒烟测试优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。回归测试的使用条件可以包括：当修复一个bug后，把之前的测试案例再次应用到修复后的版本上进行测试，或者当一个新版本开发好且冒烟测试通过，此时可以先用上一个版本的测试案例对新版本进行测试，测试是否有bug。

S202：根据每个所述测试需求中的所述测试时间计划、所述测试类型以及所述用户场景描述，生成测试案例。

在确定了每个测试需求中的测试时间计划、测试类型以及用户场景描述之后，根据这些信息生成测试案例。具体的，本实施例中测试需求用于表示需要测什么对象以及测试过程中的要求，而测试案例包括测试该对象的测试流程。

测试案例是对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。不同类别的软件，测试案例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。

S203：根据不同的用户场景描述，将所述测试案例与其对应的用户场景描述关联存储至所述案例库中。

在根据每个测试需求中的测试时间计划、测试类型以及用户场景描述，生成测试案例之后，我们根据不同的用户场景描述，将测试案例与其对应的用户场景描述关联存储到案例库中。

在本实施例中，通过根据不同的用户场景描述，将测试案例存储，可以在对应用系统生成测试计划的时候，直接根据应用系统的用户场景描述，在案例库中查找到对应的测试案例，以根据查找到的测试案例确定与该应用系统相关的案例集。

S204：获取待测试的目标系统的系统标识。

在本实施例中S204与图1对应的实施例中S101的实现方式完全相同，具体可参考图1对应的实施例中的S101的相关描述，在此不再赘述。

S205：根据所述系统标识确定所述目标系统中所包含的用户场景描述。

在本实施例中S205与图1对应的实施例中S102的实现方式完全相同，具体可参考图1对应的实施例中的S102的相关描述，在此不再赘述。

S206：根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例。

在确定了目标系统中所包含的用户场景描述之后，我们根据用户场景描述，在预设的案例库中确定与目标系统对应的而目标测试案例。

进一步的，步骤S206可以具体包括步骤S2061～S2062：

S2061：若一个测试任务中包括至少两个目标系统，则根据每个所述目标系统的系统标识确定每个所述目标系统所包含的用户场景描述。

在实际应用中，各个系统可以单独运行，也可以多个系统关联执行一个任务。与其对应的，本实施例中的一个测试任务可以针对不同系统进行，一个测试任务可包括至少两个目标系统。若一个测试任务中包括至少两个目标系统，则根据每个目标系统的系统标识确定每个目标系统所包含的用户场景描述。

具体的，本实施例中根据每个目标系统的系统功能预设有对应的用户场景描述，可以将不同系统的用户场景描述存储在预设的测试数据库中，通过根据测试数据库确定每个目标系统对应的用户场景描述。

S2062：根据每个所述用户场景描述，在预设的案例库中确定与每个所述目标系统对应的目标测试案例。

在本实施例中中，预设有案例库，其中存储有各种类型的测试案例，以及这些测试案例所对应的用户场景描述，用于通过目标系统的用户场景描述，在案例库中确定与目标系统对应的目标测试案例。在确定每个目标系统对应的用户场景描述之后，在预设的案例库中确定与每个目标系统对应的目标测试案例。

S207：根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。

当确定了所有目标系统对应的目标测试案例之后，我们合并所有目标测试案例和用户场景描述，生成测试任务的系统测试总计划。

在进行合并的过程中，是根据测试案例中的测试类型、测试流程以及测试计划时间来进行合并，例如，在A时刻执行的测试案例A，在B时刻开始执行测试案例B，在将这些测试案例进行合并时，我们可以得到先在A时刻执行测试案例A，之后到了B时刻再开始执行测试案例B的总的测试方案。

进一步的，如果测试案例中的测试计划时间有冲突或者重叠，我们可以根据每个测试计划的具体任务修改执行时间或者执行方式，同时还可以将重叠执行时间的测试计划并行执行，以保证测试计划的正常运作。

进一步的，步骤S207可以具体包括步骤S2071～S2072：

S2071：将所述目标测试案例中系统测试中最早的开始时间识别为所述测试任务的目标开始时间；将所述目标测试案例中系统测试中最晚的结束时间识别为所述测试任务的目标结束时间。

在根据目标测试案例和用户场景描述生成目标系统的系统测试计划的过程中，我们可以将目标测试案例中系统测试中最早的开始时间识别为测试任务的目标开始时间；将目标测试案例中系统测试中最晚的结束时间识别为测试任务的目标结束时间。在将测试计划导入测试案例时，只需要导入需求的测试计划，则需求中的用户场景描述(User Story，US)都按照此测试计划(时间范围) 执行，系统层面测试计划(时间范围)自动生成。系统的任意一种测试类型中的案例都属于某一个测试计划，则系统的某一种测试类型计划开始时间以最早的计划起点为始，以结束时间最晚的计划为终。

示例性的，可以基于测试计划的执行时间，按照该测试计划的时间范围，将需求测试计划导入测试案例。示例性的，假设某研发版本需求A有四个US (AUS1、AUS2、AUS3、AUS4)涉及三个系统(甲、乙、丙)，SIT测试时段为：At₁～At₂，同一研发版本存在，需求B有三个US(BUS1、BUS2、BUS3) 涉及两个系统(甲、乙)，SIT测试时段为：Bt₁～Bt₂，则系统甲、乙的测试计划为Min(At₁，Bt₁)～Max(At₂，Bt₂)；若存在多需求依此类推。

S2072：根据所述目标开始时间、所述目标结束时间以及所述目标测试案例，生成所述测试任务的系统测试总计划。

在确定了目标开始时间和目标结束时间之后，根据目标开始时间和目标结束时间以及目标测试案例。在将测试计划导入测试案例时，只需要导入需求的测试计划，则需求中的用户场景描述(User Story，US)都按照此测试计划(时间范围)执行，系统层面测试计划(时间范围)自动生成。系统的任意一种测试类型中的案例都属于某一个测试计划，则系统的某一种测试类型计划开始时间以最早的计划起点为始，以结束时间最晚的计划为终，进而生成测试任务的系统测试总计划。

进一步的，在生成目标系统的系统测试计划之后，可以根据系统测试计划确定其中的每个测试任务的执行时间段，或者确定每个时间段的测试任务，以通过系统测试计划中的执行时间段或者测试任务对当前的测试任务进度进行调整和管理。我们通过获取当前时刻的测试进度和测试结果，其中测试进度用于表示当前系统测试的进程，例如测到了哪个系统或者哪个功能，测试结果用于表示测试完毕之后的测试报告、测试成功的系统或者功能、以及测试失败的测试案例等，根据测试任务和测试结果，对测试进度进行调整。示例性地，当获取到的当前的测试进度和测试任务都包括了系统测试计划中该时间段的测试任务时，则说明当前已经完成了该时间段的测试任务，可以维持当前的测试进度。若当前时间段的测试任务在当前时刻的测试结果中没有体现，则说明该时间段的测试任务在进行中或者还没有进行，可以适当的加快测试进度，以保证测试计划的顺利进行。

上述方案，获取至少一个待检测对象的测试需求；所述测试需求包括测试时间计划、测试类型以及与所述测试需求关联的至少一个用户场景描述；根据每个所述测试需求中的所述测试时间计划、所述测试类型以及所述用户场景描述，生成测试案例；根据不同的用户场景描述，将所述测试案例与其对应的用户场景描述关联存储至所述案例库中。获取待测试的目标系统的系统标识；根据所述系统标识确定所述目标系统中所包含的用户场景描述；根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。通过制定需求维度的测试计划，无需在子系统层面单独制定测试计划，便可以自动生成系统层面的测试计划，提高了需求测试计划和系统测试技术的生成效率，便于系统测试进度的管理。

参见图3，图3是本发明实施例三提供的一种终端设备的示意图。终端设备包括的各单元用于执行图1～图2对应的实施例中的各步骤。具体请参阅图1～图2各自对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。本实施例的终端设备300包括：

获取单元301，用于获取待测试的目标系统的系统标识；

确定单元302，用于根据所述系统标识确定所述目标系统中所包含的用户场景描述；

查找单元303，用于根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例；

生成单元304，用于根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划。

进一步的，所述终端设备还可以包括：

第一获取单元，用于获取至少一个待检测对象的测试需求；所述测试需求包括测试时间计划、测试类型以及与所述测试需求关联的至少一个用户场景描述；

第一生成单元，用于根据每个所述测试需求中的所述测试时间计划、所述测试类型以及所述用户场景描述，生成测试案例；

存储单元，用于根据不同的用户场景描述，将所述测试案例与其对应的用户场景描述关联存储至所述案例库中。

进一步的，所述查找单元303可以包括：

第一确定单元，用于若一个测试任务中包括至少两个目标系统，则根据每个所述目标系统的系统标识确定每个所述目标系统所包含的用户场景描述；

第二确定单元，用于根据每个所述用户场景描述，在预设的案例库中确定与每个所述目标系统对应的目标测试案例；

进一步的，所述生成单元304可以包括：

合并单元，用于合并所有所述目标测试案例和所述用户场景描述，生成所述测试任务的系统测试总计划。

进一步的，所述测试案例中包括每个测试案例对应的系统测试的开始时间和结束时间；

进一步的，所述合并单元可以包括：

目标识别单元，用于将所述目标测试案例中系统测试中最早的开始时间识别为所述测试任务的目标开始时间；将所述目标测试案例中系统测试中最晚的结束时间识别为所述测试任务的目标结束时间；

目标生成单元，用于根据所述目标开始时间、所述目标结束时间以及所述目标测试案例，生成所述测试任务的系统测试总计划。

进一步的，所述终端设备还可以包括：

第三确定单元，用于确定所述系统测试计划中每个时间段的测试任务；

结果获取单元，用于获取当前时刻的测试进度和测试结果；

进度调整单元，用于根据所述测试任务和测试结果，对所述测试进度进行调整。

图4是本发明实施例四提供的终端设备的示意图。如图4所示，该实施例的终端设备4包括：处理器40、存储器41以及存储在所述存储器41中并可在所述处理器40上运行的计算机程序42。所述处理器40执行所述计算机程序42 时实现上述各个系统测试计划生成方法实施例中的步骤，例如图1所示的步骤 101至104。或者，所述处理器40执行所述计算机程序42时实现上述各装置实施例中各模块/单元的功能，例如图3所示单元301至304的功能。

示例性的，所述计算机程序42可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器41中，并由所述处理器40执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序42在所述终端设备4中的执行过程。

所述终端设备4可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器40、存储器41。本领域技术人员可以理解，图4仅仅是终端设备4的示例，并不构成对终端设备4的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器40可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器41可以是所述终端设备4的内部存储单元，例如终端设备4 的硬盘或内存。所述存储器41也可以是所述终端设备4的外部存储设备，例如所述终端设备4上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card，FC)等。进一步地，所述存储器41还可以既包括所述终端设备4的内部存储单元也包括外部存储设备。所述存储器41用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器41还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims

1.一种系统测试计划生成方法，其特征在于，包括：

获取待测试的目标系统的系统标识；

2.如权利要求1所述的系统测试计划生成方法，其特征在于，所述根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例之前，还包括：

获取至少一个待检测对象的测试需求；所述测试需求包括测试时间计划、测试类型以及与所述测试需求关联的至少一个用户场景描述；

根据每个所述测试需求中的所述测试时间计划、所述测试类型以及所述用户场景描述，生成测试案例；

根据不同的用户场景描述，将所述测试案例与其对应的用户场景描述关联存储至所述案例库中。

3.如权利要求2所述的系统测试计划生成方法，其特征在于，

所述根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例，包括：

若一个测试任务中包括至少两个目标系统，则根据每个所述目标系统的系统标识确定每个所述目标系统所包含的用户场景描述；

根据每个所述用户场景描述，在预设的案例库中确定与每个所述目标系统对应的目标测试案例；

所述根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划，包括：

合并所有所述目标测试案例和所述用户场景描述，生成所述测试任务的系统测试总计划。

4.如权利要求3所述的系统测试计划生成方法，其特征在于，所述测试案例中包括每个测试案例对应的系统测试的开始时间和结束时间；

所述合并所有所述目标测试案例和所述用户场景描述，生成所述测试任务的系统测试总计划，包括：

将所述目标测试案例中系统测试中最早的开始时间识别为所述测试任务的目标开始时间；将所述目标测试案例中系统测试中最晚的结束时间识别为所述测试任务的目标结束时间；

根据所述目标开始时间、所述目标结束时间以及所述目标测试案例，生成所述测试任务的系统测试总计划。

5.如权利要求1所述的系统测试计划生成方法，其特征在于，所述根据所述目标测试案例和所述用户场景描述，生成所述目标系统的系统测试计划之后，还包括：

确定所述系统测试计划中每个时间段的测试任务；

获取当前时刻的测试进度和测试结果；

根据所述测试任务和测试结果，对所述测试进度进行调整。

6.一种终端设备，其特征在于，包括存储器以及处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时，实现如下步骤：

获取待测试的目标系统的系统标识；

7.如权利要求6所述的终端设备，其特征在于，所述根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例之前，还包括：

8.如权利要求7所述的终端设备，其特征在于，所述所述根据所述用户场景描述，在预设的案例库中查找与所述目标系统对应的目标测试案例，包括：

9.一种终端设备，其特征在于，包括：

获取单元，用于获取待测试的目标系统的系统标识；

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述方法的步骤。