CN104281523A - 一种需求可测性分析方法及系统 - Google Patents

Abstract

本申请公开了一种需求可测性分析方法及系统，其中方法包括：需求可测性分析系统先获取系统应用设计说明书，从中提取与被测系统相关的测试需求信息；再将测试需求信息中的业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；所述需求可测性分析系统记录测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。本申请提供的技术方案，可以为测试人员提供全面的、专业的测试需求分析结果，并为测试人员提供依据规则设计案例和案例数目的指导信息。

Description

一种需求可测性分析方法及系统

技术领域

本申请涉及测试系统技术领域，特别是涉及一种需求可测性分析方法及系统。

背景技术

在软件测试的生命周期中，需求可测性分析结果是后续测试活动开展的重要依据，如果需求可测性分析结果不够准确，后续测试活动就会失去实际意义。

银行业务系统具有流程较多、业务逻辑复杂、测试需求要及时响应市场规则的特点，针对银行业务系统，目前还没有一个专业全面的需求可测性分析方法，在以往传统的需求可测性分析方案中，通常由测试人员根据自身经验查询相关资料，对资料进行分析和整理，产生一份测试需求分析文档，测试人员进行手工管理维护该文档。这种完全依赖个人经验的分析方式，其分析结果的准确性无法得到保障，且需要专业的测试人员基于一定的分析经验，大量的分析任务将会耗费一定的人力资源。

发明内容

为了解决现有技术存在的上述技术问题，本发明实施例提供了一种需求可测性分析方法及系统，能够基于银行测试系统的专有特点及时响应市场规则，自动为测试人员提供专业、全面的测试需求分析结果，一方面保证分析结果的可靠性、节约人力资源，另一方面为测试人员提供依据规则设计案例和案例数目的指导信息。

第一方面，本发明提供了一种需求可测性分析方法，包括：

需求可测性分析系统获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

所述需求可测性分析系统从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

所述需求可测性分析系统将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

所述需求可测性分析系统记录所述测试需求信息、所述最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

优选的，所述方法还包括：

所述需求可测性分析系统按照系统用例所需设计的最小正案例数量等于系统用例每个业务规则对应的最小正案例数量与每个界面校验规则对应的最小正案例数量的乘积，计算每个系统用例所需设计的最小正案例数量；

所述需求可测性分析系统按照系统用例所需设计的最小反案例数量等于系统用例每个业务规则对应的最小反案例数量与每个界面校验规则对应的最小反案例数量之和，计算每个系统用例所需设计的最小反案例数量。

优选的，所述方法还包括：

所述需求可测性分析系按照系统用例所需设计的最小案例数量等于系统用例所需设计的最小正案例数量和最小反案例数量的和值与系统用例的CPC系数最大值之间的乘积，计算每个系统用例所需设计的最小案例数量；

所述需求可测性分析系统计算所有系统用例所需设计的最小案例数量的和值，确定所述和值为该系统的案例规模。

优选的，所述方法还包括：

所述需求可测性分析系统根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则，以使测试人员按照设计规则设计案例。

优选的，所述根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则具体包括：

所述需求可测性分析系统根据系统用例的功能将系统用例分为联机交易类、报表查询类、批量作业类、渠道自有类、或者数据集成类；

所述需求可测性分析系统设置联机交易类对应的设计规则为基于业务规则、出错输出信息、页面校验规则分别设计正反案例；

所述需求可测性分析系统设置报表查询类对应的设计方法为基于业务规则、出错输出信息、页面校验规则、查询规则、报表样式、勾稽关系、数据正确性分别设计正反案例；

所述需求可测性分析系统设置批量作业类对应的设计方法为基于批量作业规则设计正反案例；

所述需求可测性分析系统设置渠道自有类对应的设计方法为基于渠道自有功能规则、渠道迁移界面规则、渠道展现变化影响的界面规则分别设计正反案例；

所述需求可测性分析系统设置数据集成类对应的设计方法为基于物理模型及数据接口设计正反案例。

优选的，所述方法还包括：

所述需求可测性分析系统接收需求变更信息，根据所述需求变更信息更新或者补充所述测试需求信息。

优选的，所述需求可测性分析系统分析多个被测系统之后，所述方法还包括：

所述需求可测性分析系统统计多个被测系统相同类型的系统用例的案例均值，利用该均值预估待测试系统的案例规模。

第二方面，本发明提供了一种需求可测性分析系统，包括：

获取单元，用于获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

提取单元，用于从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

发送接收单元，用于将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

记录单元，用于记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

优选的，所述系统还包括：

第一计算单元，用于按照系统用例所需设计的最小正案例数量等于系统用例每个业务规则对应的最小正案例数量与每个界面校验规则对应的最小正案例数量的乘积，计算每个系统用例所需设计的最小正案例数量；

第二计算单元，用于按照系统用例所需设计的最小反案例数量等于系统用例每个业务规则对应的最小反案例数量与每个界面校验规则对应的最小反案例数量的之和，计算每个系统用例所需设计的最小反案例数量。

优选的，所述系统还包括：

第三计算单元，用于按照系统用例所需设计的最小案例数量等于系统用例所需设计的最小正案例数量和最小反案例数量的和值与系统用例的CPC系数最大值之间的乘积，计算每个系统用例所需设计的最小案例数量；第四计算单元，用于计算所有系统用例所需设计的最小案例数量的和值，确定所述和值为该系统的案例规模。

优选的，所述系统还包括：

分类设置单元，用于根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则，以使测试人员按照设计规则设计案例。

优选的，所述分类设置单元具体包括：

分类子单元，用于根据系统用例的功能将系统用例分为联机交易类、报表查询类、批量作业类、渠道自有类、或者数据集成类；

第一设置子单元，用于设置联机交易类对应的设计规则为基于业务规则、出错输出信息、页面校验规则分别设计正反案例；

第二设置子单元，用于设置报表查询类对应的设计方法为基于业务规则、出错输出信息、页面校验规则、查询规则、报表样式、勾稽关系、数据正确性分别设计正反案例；

第三设置子单元，用于设置批量作业类对应的设计方法为基于批量作业规则设计正反案例；

第四设置子单元，用于设置渠道自有类对应的设计方法为基于渠道自有功能规则、渠道迁移界面规则、渠道展现变化影响的界面规则分别设计正反案例；

第五设置子单元，用于设置数据集成类对应的设计方法为基于物理模型及数据接口设计正反案例。

优选的，所述系统还包括：

更改单元，用于接收需求变更信息，根据所述需求变更信息更新或者补充所述测试需求信息。

优选的，所述系统还包括：

统计预估单元，用于统计多个被测系统相同类型的系统用例的案例均值，利用该均值预估待测试系统的案例规模。

本发明实施例提供的技术方案，与现有技术相比具有以下有益效果：

本发明实施例提供的技术方案，第一方面需求可测性分析系统获取系统应用设计说明书，从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；需求可测性分析系统将测试需求信息分类以上述模板化形式管理，这样既能够为测试人员后续设计案例提供所需的关键信息，又能够便于管理；第二方面所述需求可测性分析系统将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；所述需求可测性分析系统记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

经过上述两方面的处理，本发明提供的需求可测性分析系统其不再需要完全依赖人力，就能够保证分析结果全面且可靠，最重要的是其为测试人员提供依据规则设计案例和案例数目的指导信息。

附图说明

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

图1是本申请实施例一种需求可测性分析方法实施例1的流程图；

图2是本申请实施例一种需求可测性分析方法实施例2的流程图；

图3是本申请实施例一种需求可测性分析方法实施例3的流程图；

图4是本申请实施例一种需求可测性分析系统实施例1的结构图；

图5是本申请实施例一种需求可测性分析系统实施例2的结构图；

图6是本申请实施例一种需求可测性分析系统实施例3的结构图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本发明是针对银行业务系统的软件需求可测性分析，而银行业务系统测试与一般管理系统有本质区别，第一，银行业务系统设计到大量的业务流程、复杂的逻辑规则，因此需要对被测系统每个用例进行深入的剖析，尤其是技术规范、业务规则、页面规则等，这些是测试人员设计案例的重要依据。第二，银行业务系统需要迅速响应市场规则，测试需求随时会有调整和变更，因此对测试需求的管理需要一定的灵活性，能够根据业务需求变更随时更新；第三，银行内外部系统较多，且有些系统间关联性很强，所有系统的测试需求分析也需要统一管理。

但是目前银行业界的功能测试，普遍面临如下问题：1、测试关注点散落在各种不同的系统设计文档中，测试人员查看分析十分困难；2、测试人员对系统的测试分析缺乏统一的方法体系，不同的测试人员会因为经验的不同、理解能力的不同而导致分析结果的不同，从而影响测试案例设计；3、对测试需求还是采取经手工分析和整理，产生一份可用的测试需求，人工进行表格管理的方式。

那么，如何能灵活有效的管理测试需求，如何能全面准确寻找测试依据，如何能保证测试的准确性和针对性？这些问题就是银行业务系统需求可测性分析的最重要的问题，上述问题如何解决直接关系到功能测试的开展是否可以保证银行系统的稳定运营。本发明意在解决以上技术性难题。

参阅图1，图1是本申请实施例一种需求可测性分析方法实施例1的流程图；从图1可知，该方法包括：

S101，需求可测性分析系统获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则。

在实现本实施例方案之前，由系统应用开发人员依据开发需求撰写系统应用设计说明书，在撰写说明书时，开发人员至少要将系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称、界面校验规则等信息写入说明书，当然，为了使得说明书内容更加丰富，更好的帮助测试人员后续的案例设计，开发人员还可以结合系统业务领域知识、用户使用手册、其他技术知识等与系统应用相关的知识撰写说明书。

在具体实现时，本步骤可以是由测试人员将系统应用设计说明书保存在预设的储存地址，则需求可测性分析系统从预设的储存地址获取系统应用设计说明书。

S102，所述需求可测性分析系统从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则。

在具体实现时，开发人员在撰写系统应用设计说明书时，可以以标准工艺模板化的形式在各个模块填写对应的内容，则对应的本步骤可以是按照系统应用设计说明书模块化格式，从相应的模块获取对应的信息。这样自动提取与被测系统相关的测试需求信息，无需测试人员再手动收集整理，节省了劳力，同时提高测试人员的工作效率。当然，开发人员在撰写系统应用设计说明书时，也可以是根据个人习惯不按照标准工艺模板化的形式去撰写，这样，所述需求可测性分析系统需要基于关键字提取算法，从中提取相关的测试需求信息。

在具体实现时，所述需求可测性分析系统可以将提取的这些测试需求信息以标准化、结构化的形式保存起来，以使后续测试人员在需要时直接查询对应的信息，或者补充或者修改对应的信息。

渠道信息：渠道是指业务操作的发起端，渠道信息包含系统涉及到的所有渠道，渠道分为：一级渠道、二级渠道、三级渠道、四级渠道。一级渠道分为电子渠道和非电子渠道；二级渠道分为物理渠道、行内电子渠道、第三方电子渠道、员工渠道；三级渠道又细分为普通网点、信用卡中心、手机银行、短信金融等等。在实际应用中，常会根据实际需求划分不同类型的渠道，具体如何划分，划分几个级别的渠道并不影响本实施例的实现。

系统工作流程：是指对用户工作流的系统实现过程，包括：实现的跨角色、跨时序、可中断的业务处理流程和在由人工介入实现的其它业务处理流程。

关联系统信息：是指给系统在接口方面提供支持的其他系统的信息。(其他系统为了配合待测试系统的实施，需要在接口方面进行改造或者支持，在实现待测试系统的案例设计时，需要参考其他系统的信息。)

系统用例属性：是指系统所包含的所有系统用例的相关属性，该属性至少包含：用例名称/ID、类型、(行内)机构名称/(行外)客户所属组织名称、(行内)最终用户岗位/(行外)角色名称、菜单名称和机构客户岗位角色对该系统用例操作权限等。

业务规则：是指引入业务模型定义的业务规则，描述在渠道上实现的业务规则或渠道控制规则，如权限、限额、授权、客户和产品在渠道上的控制规则等；

界面校验规则：是指对输入控件进行合法性检查时使用的检验规则，包含校验规则和要素显示规则。

S103，所述需求可测性分析系统将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量。

需求可测性分析的直接目的就是给测试人员提供充足且可靠的测试需求分析结果，以便测试人员依据这些分析结果决定如何设计案例以及设计多少个案例；在测试人员设计案例的过程中，最重要的技术点是设计多少个案例，既能够保证设计的案例充分覆盖需求，又能够满足案例设计的合理性。

目前测试人员在设计案例时，常常要依赖个人经验设计案例，由于不同测试人员的经验不同、理解能力不同导致其设计案例的数目和案例的形式都会有一些差异，案例的数目将会直接影响案例覆盖的充分性，因此本发明通过预先让测试人员估算出每个规则所需设计最小正案例数量和最小反案例数量，这样，测试人员在设计案例时就可以以这个数目为参考标准，系统提供的案例数目起到一定的指导限制作用，在一定程度上保证了案例设计的充分性和合理性。

测试人员要根据业务规则估算出每个业务规则对应的最小正案例数量和最小反案例数量，另外，一个系统用例可能包含一个或者多个业务功能，每个业务功能界面上也可能存在多个输入要素，例如密码输出框、文本框、下拉框等。提取界面校验规则的目的是为了测试人员后续能够更加准确且全面的设计界面规则校验的功能类测试案例。因此，测试人员还要根据界面校验规则估算出每个校验规则对应的最小正案例数量和最小反案例数量。所谓正案例是指针对正常业务处理流程、满足业务规则的情况，系统完成业务交易所设计的案例；反案例是针对异常流程与操作、不满足业务规则的情况，系统完成业务交易所设计的案例。

测试人员在估算过程中，需要按照系统提供的标准模板分析业务规则相关信息，该标准模板是基于银行业务系统通用业务规则分析得到的，该标准模板包括：密码与认证、数量与限制、权限控制、信息滥缺、业务逻辑、重复交易、时间与期限、风险控制。该标准模块的建立为测试人员有针对性、全面的提取业务规则给出了参考依据。

S104，所述需求可测性分析系统记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

需求可测性分析系统将测试需求信息、业务规则对应的最小正案例数量和最小反案例数量、界面校验规则对应的最小正案例数量和最小反案例数量记录下来，以使得测试人员在后续测试时，在该需求可测性分析系统中查看这些信息，然后针对业务规则分别设计至少大于对应的最小正案例数量的正案例和最小反案例数量的反案例，针对界面校验规则分别设计至少大于最小正案例数量的正案例和最小反案例数量的反案例。

由于现有技术中是由测试人员手工管理维护测试需求分析文档，这种方式可操作性差，为此，本发明的需求可测性分析系统将分析出的信息统一记录，这样，任何一个测试人员想要设计测试案例时，只需要在该系统中查询相关的信息，基于这些信息再分别设计一定数目的正案例和反案例。

利用本发明实施例的技术方案，能够基于银行业务的流程较多、业务逻辑复杂、业务需求响应市场规则速度快的特点，可以自动为测试人员提供全面的、专业的测试需求分析结果，同时，还可以为测试人员提供依据规则设计案例和案例数目的指导信息。

在测试人员完成案例设计之后，还需要进一步评估案例设计的充分性，但目前关于如何判断充分性还没有一个完整的方案，基本还是依赖个人经验作一个主观大概的判断，基于此，本发明还提供优选方案，该优选方案与上述实施例1的区别在于为判断充分性提供了基准数据，使得判断结果客观准确。

参阅图2，图2是本申请实施例一种需求可测性分析方法实施例2的流程图；从图2可知，该方法包括：

S201，需求可测性分析系统获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

S202，所述需求可测性分析系统从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

S203，所述需求可测性分析系统将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

S204，所述需求可测性分析系统记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

上述S201￣204与实施例1中S101￣S104相同，具体可参考实施例1中的描述，在此不再赘述。

需要说明的是S205和S206没有严格的执行顺序先后之分，且与S204之间也不存在严格的执行顺序先后之分，当需求可测性分析系统接收到测试人员反馈的最小正案例数量和最小反案例数量之后，需求可测性分析系统就可以执行S205和S206这两个步骤可以分开执行，也可以同时执行。

S205，所述需求可测性分析系统按照系统用例所需设计的最小正案例数量等于系统用例每个业务规则对应的最小正案例数量与每个界面校验规则对应的最小正案例数量的乘积，计算每个系统用例所需设计的最小正案例数量；

S206，所述需求可测性分析系统按照系统用例所需设计的最小反案例数量等于系统用例每个业务规则对应的最小反案例数量与每个界面校验规则对应的最小反案例数量的之和，计算每个系统用例所需设计的最小反案例数量。

被测系统包含多个系统用例，每个系统用例都会需要设计多个正案例和多个反案例，设计案例需要考虑其是否充分覆盖需求，而不能够盲目设计过多的案例，因此在实际设计中还需要一个标准用以判断至少设计多少个案例才能够满足充分覆盖需求。

例如，第X个系统用例，其有n个业务规则和n个界面校验规则；

按照顺序n个业务规则对应的最小正案例数量分别为Ax1、Ax2、Ax3……Axn；按照顺序n个业务规则对应的最小反案例数量分别为ax1、ax2、ax3……axn；

按照顺序n个界面校验规则对应的最小正案例数量分别为Bx1、Bx2、Bx3……Bxn；按照顺序n个业务规则对应的最小反案例数量分别为bx1、bx2、bx3……bxn；

则该第X个系统用例的最小正案例数量Yx＝(Ax1＊Ax2＊Ax3……＊Axn)＊(Bx1＊Bx2＊Bx3……＊Bxn)；则该第X个系统用例的最小反案例数量yx＝(ax1+ax2+ax3……+axn)+(bx1+bx2+bx3……+bxn)。

其他系统用例的最小正案例数量和最小反案例数量均可以按照上述公式计算得到，在此不再一一解释说明。

在计算得到这些数量之后，可以以这些数量为基准判断测试人员设计案例是否充分，测试人员至少设计这么多案例才能认为该系统用例的案例设计充分。

另外，在测试人员完成所有系统用例的案例设计之后，测试人员还需要在测试计划阶段识别项目的规模，根据规模大小后续进一步的实际操作打好基础。但目前还没有一种方法用于识别规模的。基于此本发明还提供了优选方法，具体是在本实施例的基础上还增加估算规模大小的操作。

优选的，在上述方法的基础上，该方法还包括：

S207，所述需求可测性分析系统按照系统用例所需设计的最小案例数量等于系统用例所需设计的最小正案例数量和最小反案例数量的和值与系统用例的CPC系数最大值之间的乘积，计算每个系统用例所需设计的最小案例数量；

S208，所述需求可测性分析系统计算所有系统用例所需设计的最小案例数量的和值，确定所述和值为该系统的案例规模。

上述CPC系数最大值是指在银行业务系统中去除部分级别业务流程模型差异化，抽象形成企业或者流程模型的各种变量因子，如产品、客户、渠道、机构、角色、商户、金融介质、物品等等。所谓CPC系数最大值是指系统各种变量因子的最大值。假设被测系统有n个系统用例，每个系统用例的最小案例数量为S，则n个系统用例的最小案例数量依次为S1、S2、……Sn；下面以第X个系统用例为例对S207作解释说明。

第X个案例所需设计的最小案例数量Sx＝CPCmax＊(Yx+yx)＝CPCmax＊{[(Ax1＊Ax2＊Ax3……＊Axn)＊(Bx1＊Bx2＊Bx3……＊Bxn)]+[(ax1+ax2+ax3……+axn)+(bx1+bx2+bx3……+bxn)]}，其中，CPCmax是一个具体数值。

其他系统用例均可以按照上述公式计算得到所需设计的最小案例数量，被测系统的案例规模TQs＝S1+S2+S3+……+Sn；从系统的角度判断该系统的案例设计是否充分，具体是判断为系统设计的总案例数目是否大于或者等于TQs如果是，则可以认为该系统案例设计满足充分覆盖需求。

利用本发明实施例的技术方案，能够基于银行业务的流程较多、业务逻辑复杂、业务需求响应市场规则速度快的特点，可以为测试人员提供全面的、专业的测试需求分析结果，同时，还可以为测试人员提供依据规则设计案例和案例数目的指导信息，一定程度上保证案例设计的充分性和合理性。更进一步的，可以给出判断案例设计充分性的参数，以该参数为基准能够有效地判断出案例设计是否充分。

另外，在实际测试分析之前，项目负责人需要对被测系统有一个整体把握，从而进行工作计划以及人员安排，针对该需求，本发明实施例还提供优选方案，具体是在上述方法基础上还包括：

所述需求可测性分析系统统计多个被测系统相同类型的系统用例的案例均值，利用该均值预估待测试系统的案例规模。

需求可测性分析系统对多个被测系统进行测试分析之后，统计多个被测系统相同类型的系统用例的案例均值，具体有联机交易类、报表查询类、批量作业类、渠道自有类、数据集成类五种类型，当然也可以有其他类型，在此不进行一一列举，针对每一种类型统计出一个案例均值，同时，求解上述多个被测系统的CPC系数的平均值作为CPC系数经验值，在下一个待测系统需求可测性分析之前，可以预估出其案例规模。

在具体实现时，需求可测性分析系统采用如下预估公式：

Ts＝CPCs＊(Us＊k1＊A1+Us＊k2＊A2……+Us＊k5＊A5)

其中，Ts为预估的待测系统案例规模，CPCs为CPC系数经验值，Us为待测系统的系统用例个数，k1、k2……k5分别是第1、2……5种类型占系统用例的比例，A1、A2……A5，分别是系统统计出的第1、2……5种类型的案例均值。

需求可测性分析系统通过上述公式预估出待测系统的案例规模，项目负责人就可以根据待测系统的案例规模进行工作规划以及人员安排。

目前测试人员完成需求分析之后，仅凭借测试经验以整体测试需求分析结果为依据设计测试案例，这样设计案例角度缺乏针对性，在一定程度上影响系统案例设计的有效性。基于此本发明还提供了优选方案，该优选方案与上述实施例1的区别在于为测试人员提供了依据系统用例的功能设计功能类案例的思路，并针对每种功能类案例提供的设计规则，这样，测试人员在后续设计案例时按照这些规则去设计，能够有针对性的设计案例，保证系统案例设计的有效性。

参阅图3，图3是本申请实施例一种需求可测性分析方法实施例2的流程图；从图3可知，该方法包括：

S301，需求可测性分析系统获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

S302，所述需求可测性分析系统从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

S303，所述需求可测性分析系统将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

S304，所述需求可测性分析系统记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

上述S301￣304与实施例1中S101￣S104相同，具体可参考实施例1中的描述，在此不再赘述。

S305，所述需求可测性分析系统根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则，以使测试人员按照设计规则设计案例。

在具体实现时，本步骤可以通过以下方式实现，包括：

所述需求可测性分析系统根据系统用例的功能将系统用例分为联机交易类、报表查询类、批量作业类、渠道自有类、或者数据集成类；

所述需求可测性分析系统设置联机交易类对应的设计规则为基于业务规则、出错输出信息、页面校验规则分别设计正反案例；

所述需求可测性分析系统设置报表查询类对应的设计方法为基于业务规则、出错输出信息、页面校验规则、查询规则、报表样式、勾稽关系、数据正确性分别设计正反案例；

所述需求可测性分析系统设置批量作业类对应的设计方法为基于批量作业规则设计正反案例；

所述需求可测性分析系统设置渠道自有类对应的设计方法为基于渠道自有功能规则、渠道迁移界面规则、渠道展现变化影响的界面规则分别设计正反案例；

所述需求可测性分析系统设置数据集成类对应的设计方法为基于物理模型及数据接口设计正反案例。

另外，开发人员没有实际测试经验，在撰写系统应用设计说明书时会存在遗漏或者错误，还考虑到银行业务系统需要迅速响应市场规则，测试需求变更速率快等需求，本发明还提供了优选方案，具体是在上述实施例的基础上，需求可测性分析系统还为测试人员提供变更信息的服务，这样，测试人员可以根据实际需求更改相关信息，需求可测性分析系统再根据需求变更信息更新或者补充测试需求信息。如，测试人员可以手动修改或者增加一些信息如被测系统业务领域知识、与用户或业务人员沟通信息、相关业务知识培训信息等。具体是通过以下技术特征实现上述功能：

所述需求可测性分析系统接需求变更信息，根据所述需求变更信息更新或者补充所述测试需求信息。

利用本发明实施例的技术方案，能够基于银行业务的流程较多、业务逻辑复杂、业务需求响应市场规则速度快的特点，自动为测试人员提供全面的、专业的测试需求分析结果，同时，还可以为测试人员提供依据规则设计案例和案例数目的指导信息，一定程度上保证案例设计的充分性和合理性。更进一步的，可以为测试人员提供案例设计的新思路，获取被测系统的功能，并分析各个功能对应的业务规则，以使测试人员在后续设计案例时，以该设计规则为基础进行设计。

参阅图4，图4是本申请实施例一种需求可测性分析系统实施例1的结构图，从图4可知，该系统包括：

获取单元401，用于获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

提取单元402，用于从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

发送接收单元403，用于将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

记录单元404，用于记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

如图5所示，优选的，所述系统还包括：

第一计算单元405，用于按照系统用例所需设计的最小正案例数量等于系统用例每个业务规则对应的最小正案例数量与每个界面校验规则对应的最小正案例数量的乘积，计算每个系统用例所需设计的最小正案例数量；

第二计算单元406，用于按照系统用例所需设计的最小反案例数量等于系统用例每个业务规则对应的最小反案例数量与每个界面校验规则对应的最小反案例数量之和，计算每个系统用例所需设计的最小反案例数量。

优选的，所述系统还包括：

第三计算单元407，用于按照系统用例所需设计的最小案例数量等于系统用例所需设计的最小正案例数量和最小反案例数量的和值与系统用例的CPC系数最大值之间的乘积，计算每个系统用例所需设计的最小案例数量；第四计算单元408，用于计算所有系统用例所需设计的最小案例数量的和值，确定所述和值为该系统的案例规模。

优选的，如图6所示，所述系统还包括：

分类设置单元409，用于根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则，以使测试人员按照设计规则设计案例。

优选的，所述设置单元包括：

分类子单元，用于根据系统用例的功能将系统用例分为联机交易类、报表查询类、批量作业类、渠道自有类、或者数据集成类；

第一设置子单元，用于设置联机交易类对应的设计规则为基于业务规则、出错输出信息、页面校验规则分别设计正反案例；

第二设置子单元，用于设置报表查询类对应的设计方法为基于业务规则、出错输出信息、页面校验规则、查询规则、报表样式、勾稽关系、数据正确性分别设计正反案例；

第三设置子单元，用于设置批量作业类对应的设计方法为基于批量作业规则设计正反案例；

第四设置子单元，用于设置渠道自有类对应的设计方法为基于渠道自有功能规则、渠道迁移界面规则、渠道展现变化影响的界面规则分别设计正反案例；

第五设置子单元，用于设置数据集成类对应的设计方法为基于物理模型及数据接口设计正反案例。

优选的，所述系统还可以包括：

更改单元，用于接收需求变更信息，根据所述需求变更信息更新或者补充所述测试需求信息。

利用本发明实施例的技术方案，能够基于银行业务的流程较多、业务逻辑复杂、业务需求响应市场规则速度快的特点，可以全面的、专业的为测试人员提供测试需求分析结果，同时，还可以为测试人员提供依据规则设计案例和案例数目的指导信息，一定程度上保证案例设计的充分性和合理性。进一步的，可以给出判断案例设计充分性的参数，以该参数为基准能够有效地判断出案例设计是否充分。进一步的，可以为测试人员提供案例设计的新思路，从银行业务范围划分各个功能，并设计各个功能对应的业务规则，以使测试人员基于这些业务规则设计案例。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序单元。一般地，程序单元包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的测试设备来执行测试用例。在分布式计算环境中，程序单元可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

还需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (14)

1.一种需求可测性分析方法，其特征在于，包括：

需求可测性分析系统获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

所述需求可测性分析系统从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

所述需求可测性分析系统将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

所述需求可测性分析系统记录所述测试需求信息、所述最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述需求可测性分析系统按照系统用例所需设计的最小正案例数量等于系统用例每个业务规则对应的最小正案例数量与每个界面校验规则对应的最小正案例数量的乘积，计算每个系统用例所需设计的最小正案例数量；

所述需求可测性分析系统按照系统用例所需设计的最小反案例数量等于系统用例每个业务规则对应的最小反案例数量与每个界面校验规则对应的最小反案例数量之和，计算每个系统用例所需设计的最小反案例数量。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述需求可测性分析系按照系统用例所需设计的最小案例数量等于系统用例所需设计的最小正案例数量和最小反案例数量的和值与系统用例的CPC系数最大值之间的乘积，计算每个系统用例所需设计的最小案例数量；

所述需求可测性分析系统计算所有系统用例所需设计的最小案例数量的和值，确定所述和值为该系统的案例规模。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述需求可测性分析系统根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则，以使测试人员按照设计规则设计案例。

5.根据权利要求4所述的方法，其特征在于，所述根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则具体包括：

所述需求可测性分析系统根据系统用例的功能将系统用例分为联机交易类、报表查询类、批量作业类、渠道自有类、或者数据集成类；

所述需求可测性分析系统设置联机交易类对应的设计规则为基于业务规则、出错输出信息、页面校验规则分别设计正反案例；

所述需求可测性分析系统设置报表查询类对应的设计方法为基于业务规则、出错输出信息、页面校验规则、查询规则、报表样式、勾稽关系、数据正确性分别设计正反案例；

所述需求可测性分析系统设置批量作业类对应的设计方法为基于批量作业规则设计正反案例；

所述需求可测性分析系统设置渠道自有类对应的设计方法为基于渠道自有功能规则、渠道迁移界面规则、渠道展现变化影响的界面规则分别设计正反案例；

所述需求可测性分析系统设置数据集成类对应的设计方法为基于物理模型及数据接口设计正反案例。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述需求可测性分析系统接收需求变更信息，根据所述需求变更信息更新或者补充所述测试需求信息。

7.根据权利要求1所述的方法，其特征在于，所述需求可测性分析系统分析多个被测系统之后，所述方法还包括：

所述需求可测性分析系统统计多个被测系统相同类型的系统用例的案例均值，利用该均值预估待测试系统的案例规模。

8.一种需求可测性分析系统，其特征在于，包括：

获取单元，用于获取系统应用设计说明书，所述系统应用设计说明书至少包括：系统用例名称/ID、最终用户、权限规则、部署渠道名称、业务规则描述、出错输出信息、界面名称、界面要素名称和界面校验规则；

提取单元，用于从所述系统应用设计说明书中提取与被测系统相关的测试需求信息，所述测试需求信息至少包括：渠道信息、系统工作流程、关联系统信息、系统用例属性、业务规则以及界面校验规则；

发送接收单元，用于将所述业务规则和界面校验规则发送给测试人员，以接收测试人员反馈的业务规则和界面校验规则各自对应的最小正案例数量和最小反案例数量；

记录单元，用于记录所述测试需求信息、最小正案例数量和最小反案例数量，以使测试人员针对业务规则、界面校验规则分别设计至少大于对应的最小正案例数量和最小反案例数量的案例。

9.根据权利要求8所述的系统，其特征在于，所述系统还包括：

第一计算单元，用于按照系统用例所需设计的最小正案例数量等于系统用例每个业务规则对应的最小正案例数量与每个界面校验规则对应的最小正案例数量的乘积，计算每个系统用例所需设计的最小正案例数量；

第二计算单元，用于按照系统用例所需设计的最小反案例数量等于系统用例每个业务规则对应的最小反案例数量与每个界面校验规则对应的最小反案例数量的之和，计算每个系统用例所需设计的最小反案例数量。

10.根据权利要求9所述的系统，其特征在于，所述系统还包括：

第三计算单元，用于按照系统用例所需设计的最小案例数量等于系统用例所需设计的最小正案例数量和最小反案例数量的和值与系统用例的CPC系数最大值之间的乘积，计算每个系统用例所需设计的最小案例数量；第四计算单元，用于计算所有系统用例所需设计的最小案例数量的和值，确定所述和值为该系统的案例规模。

11.根据权利要求8所述的系统，其特征在于，所述系统还包括：

分类设置单元，用于根据系统用例的功能将系统用例分类，并设置每个类型对应的设计规则，以使测试人员按照设计规则设计案例。

12.根据权利要求11所述的系统，其特征在于，所述分类设置单元具体包括：

分类子单元，用于根据系统用例的功能将系统用例分为联机交易类、报表查询类、批量作业类、渠道自有类、或者数据集成类；

第一设置子单元，用于设置联机交易类对应的设计规则为基于业务规则、出错输出信息、页面校验规则分别设计正反案例；

第二设置子单元，用于设置报表查询类对应的设计方法为基于业务规则、出错输出信息、页面校验规则、查询规则、报表样式、勾稽关系、数据正确性分别设计正反案例；

第三设置子单元，用于设置批量作业类对应的设计方法为基于批量作业规则设计正反案例；

第四设置子单元，用于设置渠道自有类对应的设计方法为基于渠道自有功能规则、渠道迁移界面规则、渠道展现变化影响的界面规则分别设计正反案例；

第五设置子单元，用于设置数据集成类对应的设计方法为基于物理模型及数据接口设计正反案例。

13.根据权利要求8所述的系统，其特征在于，所述系统还包括：

更改单元，用于接收需求变更信息，根据所述需求变更信息更新或者补充所述测试需求信息。

14.根据权利要求8所述的系统，其特征在于，所述系统还包括：

统计预估单元，用于统计多个被测系统相同类型的系统用例的案例均值，利用该均值预估待测试系统的案例规模。