一种测试分析平台制造技术

本发明专利技术涉及一种测试分析平台,包括规则分析模块、业务分析模块以及系统分析模块，其中：规则分析模块从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；业务分析模块以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点；系统分析模块用于页面分析、交易流分析以及要素规则测试点分析。本发明专利技术的有益效果在于，提供一种的测试分析平台，通过对业务分析过程的支撑，实现高效率、高品质的业务分析，为测试业务的覆盖质量提供有效保障和量化依据。

【技术实现步骤摘要】

本专利技术涉及一种测试分析平台。
技术介绍
目前，市场上出现的纯手工编写案例的传统模式，这种模式受制于个人对业务理解的局限性所导致测试覆盖不足，测试品质不高的现象发生。该传统模式使得测试案例的覆盖质量严重依赖于个人对业务的理解，导致测试案例的覆盖品质参差不齐等缺点。
技术实现思路
鉴于现有技术中存在的上述问题，本专利技术的主要目的在于解决现有技术的缺陷，本专利技术提供一种的测试分析平台，通过对业务分析过程的支撑，实现高效率、高品质的业务分析，为测试业务的覆盖质量提供有效保障和量化依据。本专利技术提供一种测试分析平台，包括规则分析模块、业务分析模块以及系统分析模块，其中：所述规则分析模块用于从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；所述业务分析模块用于以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点，根据测试要点，结合技术偏好和业务偏好策略自动生成测试点以及测试点数据要求；所述系统分析模块用于页面分析、交易流分析以及要素规则测试点分析，通过业务树与系统树的映射，将测试点关联到系统树中。可选的，所述实体对象模型基于业务层面，使用面向对象分析方法的理论，通过实体、对象、属性以及态树等概念，根据规则分析，建立一个基础的业务模型。可选的，所述技术偏好包括全组合算法、Pair-wise算法以及单态算法。可选的，所述业务分析模块同时支持业务流分析，通过业务流分析来抽取主体对象组，然后结合情景分析结果，计算流程级测试点以及测试点数据要求。可选的，所述情景指的是应用系统加以支持的最小业务意图，其在系统层面的表现是一个或一组用户界面。本专利技术具有以下优点和有益效果：本专利技术提供一种测试分析平台，通过对业务分析过程的支撑，实现高效率、高品质的业务分析，为测试业务的覆盖质量提供有效保障和量化依据；同时该测试分析平台改变了纯手工编写案例的传统模式，这种模式受制于个人对业务理解的局限性所导致测试覆盖不足，测试品质不高的现象发生。测试分析平台使得测试案例的覆盖质量将不在依赖于个人对业务的理解，而是取决于对业务规则采集的是否完备，这将会大大改善测试案例的覆盖品质。具体实施方式下面将参照具体实施例对本专利技术作进一步的说明。本专利技术实施例的一种测试分析平台，包括规则分析模块、业务分析模块以及系统分析模块，其中：所述规则分析模块用于从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；所述业务分析模块用于以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点，根据测试要点，结合技术偏好和业务偏好策略自动生成测试点以及测试点数据要求；所述系统分析模块用于页面分析、交易流分析以及要素规则测试点分析，通过业务树与系统树的映射，将测试点关联到系统树中。本专利技术实施例提供的测试分析平台的基础是业务分析理论，这一理论的思路是，通过对业务意图的拆分建立足以支持最小业务意图的情景，在情景中呈现不同来源的业务规则，然后通过业务要素的语义分析实现自然语言的形式化表达，由业务规则批量产生带有数据约束和检查点的测试意图(测试点)。从而形成一个具有测试点生产能力的分析结构。业务分析模块的单元是情景。情景指的是应用系统加以支持的“最小业务意图”，其在系统层面的表现是一个(或一组)用户界面(UIflow)。业务规则是某个情景的规则组，这些规则构成了实现该业务意图的过程、限制或条件。业务分析的方法是把情景中的规则组形式化，具体方法就是把构成规则的诸要素的语义表达为一组(有限个)具体的“态”，由此形成一系列组合项。设规则组涉及的组合项为N，N个组合项形成了一个有限、离散的希尔伯特空间(Hilbert Space)。测试分析平台建立和描述了这样一个空间，并且实现了N维空间的二维表达(业务网格)。测试分析平台的主要功能包括业务规则的录入、业务条件和区分点分析、要素映射、对象模型、网格分析、数据需求生成、测试点生成和覆盖优化等。在项目群测试的环境下，可以在多个测试项目中同时使用该平台，形成客户业务规则库和数据对象模型，集中整理和积累业务知识，并且把形式化的业务知识变成具有重复生产能力的知识容器。测试分析平台改变了纯手工编写案例的传统模式，这种模式受制于个人对业务理解的局限性所导致测试覆盖不足，测试品质不高的现象发生。测试分析平台使得测试案例的覆盖质量将不在依赖于个人对业务的理解，而是取决于对业务规则采集的是否完备，这将会大大改善测试案例的覆盖品质。测试分析平台是一个可以重复使用的分析架构，当需求变更时，测试分析平台将变更部分精确地表达为流程、规则和业务要素的变化，通过对于规则、要素及态的调整迅速适应变更。分析资源的产生和积累来自于业务分析的过程。业务分析是对传统测试分析方法的根本性的变革。传统的测试分析方法基于这样一个假定：需求(SR)是衡量软件的终极标准，在这一假定下，测试分析无外乎就是对需求文本的某种功能展开，满足于以测试用例对“功能点”一类似是而非的“覆盖”。深入理论研究否定了传统的假定，真正能够做为终极标准的是业务本身，软件需求无外乎是对业务的某种表达，这种表达既不完全也未必全然正确。业务有其内在的逻辑，这种逻辑可以通过“业务分析”的过程予以揭示，这种逻辑是独立于IT技术的。不管有没有相应的计算机应用，任何业务都可以表达为流程(业务流)、规则和要素。如果我们把一个业务的流程、规则和要素加以适当的形式化表达，我们就可以得到测试分析得以展开的可靠基点(分析资源)。作为业务的某种表达，需求文本只是我们开展业务分析的素材之一。业务规则库是对业务分析中提取业务规则的集中存储，其核心是规则的分层和分类；规则是测试的基础或者说准绳。任何一个测试案例一定基于一条或多条规则，原因很简单，案例需要明确断言什么情况下是系统是对的，什么情况下是错的，而做出这样的断言的依据必须是得到公认的关于正确错误的法度——这正是规则；规则的来源可以理解为“法源”。不同的规则，按照其来源，有着不同的权威性和适用范围。对规则来源的第一个分类是强制性和非强制性，国家法律法规、国家标准、国家承认的国际公约及协议，均属于“强制规则”，即具有法律约束力的规则(法律法规)，行业惯例、国标之外行业规范、银行自身的规则，均属于“非强制规则”；规则的来源分为下列层次：强制性规则和非强制性规则，其中强制性规则包括国家法律法规、国家标准以及国家承认的国际公约及协议，非强制性规则包括行业惯例、国标之外行业规范以及银行自身的规则。规则的分层是以其来源(权威性)为依据的，规则的分类则是以其功效或者说内容为依据。规则分类的方法是分析，即从一个原初的整体中依次提取某种成分。在已知规则中提取了业务规则之后的剩余物即“非业务规则”。与业务规则不同，非业务规则是以软件系统(应用)的存在为基础的，它表现为对于应用系统的更加具体和详尽的约束，即应用以何种方式实现。提取非业务规则的依据是可测性，可测性是就被测系统而言的。就某一具体的系统，某些非业务规则是可测的，某些是不可测的。就测试的目的而言，我们只关心前者(即可测规则)。对某本文档来自技高网...

【技术保护点】
一种测试分析平台，其特征在于：包括规则分析模块、业务分析模块以及系统分析模块，其中：所述规则分析模块用于从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；所述业务分析模块用于以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点，根据测试要点，结合技术偏好和业务偏好策略自动生成测试点以及测试点数据要求；所述系统分析模块用于页面分析、交易流分析以及要素规则测试点分析，通过业务树与系统树的映射，将测试点关联到系统树中。

【技术特征摘要】
1.一种测试分析平台，其特征在于：包括规则分析模块、业务分析模块以及系统分析模块，其中：所述规则分析模块用于从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；所述业务分析模块用于以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点，根据测试要点，结合技术偏好和业务偏好策略自动生成测试点以及测试点数据要求；所述系统分析模块用于页面分析、交易流分析以及要素规则测试点分析，通过业务树与系统树的映射，将测试点关联到系统树中。2.根据权利要求1所述的测试分析平...

【专利技术属性】
技术研发人员：徐永波，赵勇，
申请(专利权)人：北京捷科智诚科技有限公司，
类型：发明
国别省市：北京;11