本发明涉及一种测试分析平台。
背景技术：
目前，市场上出现的纯手工编写案例的传统模式，这种模式受制于个人对业务理解的局限性所导致测试覆盖不足，测试品质不高的现象发生。该传统模式使得测试案例的覆盖质量严重依赖于个人对业务的理解，导致测试案例的覆盖品质参差不齐等缺点。
技术实现要素：
鉴于现有技术中存在的上述问题，本发明的主要目的在于解决现有技术的缺陷，本发明提供一种的测试分析平台，通过对业务分析过程的支撑，实现高效率、高品质的业务分析，为测试业务的覆盖质量提供有效保障和量化依据。
本发明提供一种测试分析平台，包括规则分析模块、业务分析模块以及系统分析模块，其中：
所述规则分析模块用于从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；
所述业务分析模块用于以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点，根据测试要点，结合技术偏好和业务偏好策略自动生成测试点以及测试点数据要求；
所述系统分析模块用于页面分析、交易流分析以及要素规则测试点分析，通过业务树与系统树的映射，将测试点关联到系统树中。
可选的，所述实体对象模型基于业务层面，使用面向对象分析方法的理论，通过实体、对象、属性以及态树等概念，根据规则分析，建立一个基础的业务模型。
可选的，所述技术偏好包括全组合算法、Pair-wise算法以及单态算法。
可选的，所述业务分析模块同时支持业务流分析，通过业务流分析来抽取主体对象组，然后结合情景分析结果，计算流程级测试点以及测试点数据要求。
可选的，所述情景指的是应用系统加以支持的最小业务意图，其在系统层面的表现是一个或一组用户界面。
本发明具有以下优点和有益效果：本发明提供一种测试分析平台，通过对业务分析过程的支撑，实现高效率、高品质的业务分析，为测试业务的覆盖质量提供有效保障和量化依据；同时该测试分析平台改变了纯手工编写案例的传统模式，这种模式受制于个人对业务理解的局限性所导致测试覆盖不足，测试品质不高的现象发生。测试分析平台使得测试案例的覆盖质量将不在依赖于个人对业务的理解，而是取决于对业务规则采集的是否完备，这将会大大改善测试案例的覆盖品质。
具体实施方式
下面将参照具体实施例对本发明作进一步的说明。
本发明实施例的一种测试分析平台，包括规则分析模块、业务分析模块以及系统分析模块，其中：所述规则分析模块用于从测试需求文档开始，按照分类管理测试需求文档，从文档中整理业务规则、系统规则以及要素规则，同时根据上述规则，建立实体对象模型；所述业务分析模块用于以业务情景为单位，分析出每个情景所涉及的规则以及相关的实体对象，通过区分态来表达情景的测试要点，根据测试要点，结合技术偏好和业务偏好策略自动生成测试点以及测试点数据要求；所述系统分析模块用于页面分析、交易流分析以及要素规则测试点分析，通过业务树与系统树的映射，将测试点关联到系统树中。
本发明实施例提供的测试分析平台的基础是业务分析理论，这一理论的思路是，通过对业务意图的拆分建立足以支持最小业务意图的情景，在情景中呈现不同来源的业务规则，然后通过业务要素的语义分析实现自然语言的形式化表达，由业务规则批量产生带有数据约束和检查点的测试意图(测试点)。从而形成一个具有测试点生产能力的分析结构。
业务分析模块的单元是情景。情景指的是应用系统加以支持的“最小业务意图”，其在系统层面的表现是一个(或一组)用户界面(UIflow)。业务规则是某个情景的规则组，这些规则构成了实现该业务意图的过程、限制或条件。业务分析的方法是把情景中的规则组形式化，具体方法就是把构成规则的诸要素的语义表达为一组(有限个)具体的“态”，由此形成一系列组合项。设规则组涉及的组合项为N，N个组合项形成了一个有限、离散的希尔伯特空间(Hilbert Space)。测试分析平台建立和描述了这样一个空间，并且实现了N维空间的二维表达(业务网格)。
测试分析平台的主要功能包括业务规则的录入、业务条件和区分点分析、要素映射、对象模型、网格分析、数据需求生成、测试点生成和覆盖优化等。在项目群测试的环境下，可以在多个测试项目中同时使用该平台，形成客户业务规则库和数据对象模型，集中整理和积累业务知识，并且把形式化的业务知识变成具有重复生产能力的知识容器。
测试分析平台改变了纯手工编写案例的传统模式，这种模式受制于个人对业务理解的局限性所导致测试覆盖不足，测试品质不高的现象发生。测试分析平台使得测试案例的覆盖质量将不在依赖于个人对业务的理解，而是取决于对业务规则采集的是否完备，这将会大大改善测试案例的覆盖品质。
测试分析平台是一个可以重复使用的分析架构，当需求变更时，测试分析平台将变更部分精确地表达为流程、规则和业务要素的变化，通过对于规则、要素及态的调整迅速适应变更。分析资源的产生和积累来自于业务分析的过程。业务分析是对传统测试分析方法的根本性的变革。传统的测试分析方法基于这样一个假定：需求(SR)是衡量软件的终极标准，在这一假定下，测试分析无外乎就是对需求文本的某种功能展开，满足于以测试用例对“功能点”一类似是而非的“覆盖”。深入理论研究否定了传统的假定，真正能够做为终极标准的是业务本身，软件需求无外乎是对业务的某种表达，这种表达既不完全也未必全然正确。业务有其内在的逻辑，这种逻辑可以通过“业务分析”的过程予以揭示，这种逻辑是独立于IT技术的。不管有没有相应的计算机应用，任何业务都可以表达为流程(业务流)、规则和要素。如果我们把一个业务的流程、规则和要素加以适当的形式化表达，我们就可以得到测试分析得以展开的可靠基点(分析资源)。作为业务的某种表达，需求文本只是我们开展业务分析的素材之一。
业务规则库是对业务分析中提取业务规则的集中存储，其核心是规则的分层和分类；规则是测试的基础或者说准绳。任何一个测试案例一定基于一条或多条规则，原因很简单，案例需要明确断言什么情况下是系统是对的，什么情况下是错的，而做出这样的断言的依据必须是得到公认的关于正确错误的法度——这正是规则；规则的来源可以理解为“法源”。不同的规则，按照其来源，有着不同的权威性和适用范围。对规则来源的第一个分类是强制性和非强制性，国家法律法规、国家标准、国家承认的国际公约及协议，均属于“强制规则”，即具有法律约束力的规则(法律法规)，行业惯例、国标之外行业规范、银行自身的规则，均属于“非强制规则”；规则的来源分为下列层次：强制性规则和非强制性规则，其中强制性规则包括国家法律法规、国家标准以及国家承认的国际公约及协议，非强制性规则包括行业惯例、国标之外行业规范以及银行自身的规则。规则的分层是以其来源(权威性)为依据的，规则的分类则是以其功效或者说内容为依据。规则分类的方法是分析，即从一个原初的整体中依次提取某种成分。在已知规则中提取了业务规则之后的剩余物即“非业务规则”。与业务规则不同，非业务规则是以软件系统(应用)的存在为基础的，它表现为对于应用系统的更加具体和详尽的约束，即应用以何种方式实现。提取非业务规则的依据是可测性，可测性是就被测系统而言的。就某一具体的系统，某些非业务规则是可测的，某些是不可测的。就测试的目的而言，我们只关心前者(即可测规则)。对某个具体的被测系统而言，可测的非业务规则称为“系统规则”。系统规则一定与被测系统相关，或者说，它是内在于系统的，以系统存在为基础的。与之相比，业务规则是超越于系统的，它可以实现于老系统，也可以实现于新系统，也可以暂不实现于某一个系统，或者永远不实现于任何系统。虽然没有被实现的业务规则不会产生测试案例，但从业务叙事的完整性考虑，业务分析仍然要关心这类规则——况且，它将来仍有可能实现于某系统。因此，对于系统规则的分析应该沿着具体应用系统的分类树(B-tree)展开，例如“核心系统-对私储蓄-整存整取-开户”。按照系统的具体实现方式，非业务规则(系统规则)又可以分为前端和后端规则。前端规则又可以分为要素规则、页面规则(含页面流)、操作规则，后端规则又可以分为(业务规则之外的)联机处理规则和非联机处理(如批处理)规则。规则的分类呈现为如下所示：规则包括业务规则以及不可测非业务规则，其中业务规则包括情景下的规则以及业务流规则，不可测非业务规则包括可测(系统规则)，该可测(系统规则)包括前端规则和后端规则，所述前端规则包括要素规则、页面规则(含页面流)和操作规则，所述后端规则包括联机处理规则和非联机处理规则；通过这样一种分层和分类结构，可以将核心账务系统的业务规则入库，做为对于业务的一种标准化描述，从而实现分析资源的资产化；业务分析是测试质量的基本保证，通过实现对业务规则的分析实现测试业务范围的有效覆盖，从而确保测试覆盖的准确性和测试范围的完整性。捷科公司发展一套完整的业务分析方法。其思想是通过一个分析的过程还原业务内在的逻辑，把业务内容表达为流程(业务流)、规则和要素。通过把一个业务的流程、规则和要素进行形式化表达，我们就可以得到测试分析得以展开的可靠基点(规则、区分点、业务条件)；按照业务分析的方法，分析开始于对业务流的界定，方法是针对不同的业务建立路线图(D型图)，通过路线图表达各业务内在的控制规则，从中得到覆盖业务流所需要的完备的节点序列，并由此确定用户与系统交互的情景；务流和情景构成了对功能测试的分析框架。由此形成的一个分类结构称为“A tree”；业务规则呈现在一个个具体的情景中，并由此得出表达并控制业务活动的一系列业务范畴(区分点)，区分点的一个有效组合形成一个业务格点，各组区分点的所有有效组合形成的业务网格(BD,business grid)构成基础业务空间，基础业务空间表达了业务覆盖的基本要求，在此基础上，结合不同规则表达的各种特殊条件则构成了业务规则允许的各种正例覆盖，即扩展的业务空间。测试意图(测试点)表现为对测试空间的一个具体的覆盖。覆盖是对业务空间的覆盖，在规则表达满足某种基本范式的前提下，对业务空间的覆盖也是对某一情景下一组业务规则的覆盖；对于公共组件的测试分析需要使用捷科分析体系中的结构分析，这是系统分析方法中最核心的内容。其宗旨是基于对于软件系统内部结构的知识系统、批量产生SIT测试点；结构分析首先着眼于系统架构，架构分为两个层次：业务架构和技术架构。前者在逻辑层面，它指出了实现整体业务意图的基础结构和逻辑关系。技术架构是业务架构的实现，它从逻辑层开始，最终将落实到物理层面，即网络、系统、数据库、中间件、平台、应用。从物理上看，架构的基础是网络环境下的具有处理能力的节点：计算节点、存储节点、通讯节点。节点之上部署了一系列基础构件：数据库、中间件、应用平台，应用系统，这些基础构件支撑着各种应用系统，应用系统部署在一个或多个计算节点中；结构分析开始于两个要素：一、设计意图；二、系统的行为。意图即目的，设计意图指的是意欲在软件系统中实现的目的，即以代码实现的目的。所谓功能即是某种被设计的意图。系统的行为指的是软件通过基础构件和节点完成的操作，例如文本读写、数据库读写、报文收发等，其后果在物理上是可观测的。
系统的行为是有主体的，这个主体大而言之是一，即作为整体的系统，但系统本身又被设计成许多部分，即多，例如多个模块，每个模块又有划分，例如子系统、交易等。这一划分的过程在设计中完成，在编码中实现，因此它形成了系统中的某种以代码形式出现的存在，即单元；单元是系统行为的主体。系统的行为可以分解为一系列单元的行为，系统对设计意图的实现表现为系统的行为，这些行为的内在的逻辑关系表现为某种时序。经过设计的带有时序的一系列单元的行为构成一个过程(proc)。一个具体的设计意图的实现，会表现为一个或多个过程。在行为图式中，意图通过过程而产生的行为，刚好是目的-手段关系；单元的入口是接口(interface)。从外部驱动单元产生某种行为的唯一合法的方式是通过接口。接口本质上是一种协议，通过公布某接口在某种条件(输入)下会产生某种行为，单元的设计者提供了一个明确的承诺。接口测试的目的就是验证这些承诺的有效性。对单元的引用就是以这些承诺为基础的；因此单元还应该进一步理解为通过公开发布的接口而产生系统行为的主体，它是系统的一个部分，通过设计产生、以代码实现、用接口驱动。对单元的划分应该止于公开发布的、承诺供外部调用的公共接口。在这以内的结构也会有接口(内部接口)，但对这些接口的测试有必要划入单元测试(UT)的范畴；单元的关系可以是递归的。对单元的分析从整体(即一)开始，一变为多，多中的每一个(作为单元)又可以划分为多，每一次这样的划分，形成一个结构分析的层级(level)。因此每一个单元都有自己的层级，而单元的层级是有限的；过程(proc)是就不同的层级而言的，在某个层级上的大的过程，由该层级各单元的带有时序的行为实现，而其中的每一个主体的行为(过程节点)在下一个层次看，完全有可能表现为自身的一个或多个过程。这样，单元的递归关系导致了过程的递归关系。结构分析因此也成了自上而下逐级递归的分析；从测试分析的观点看，对每一个层级过程的展开都构成了IT或SIT案例的来源，在这两个阶段，所谓功能验证指的是验证设计意图与系统行为的一致性(测试意图)。意图引起了过程，过程中每一个单元通过接口所承诺的行为都会要求某种条件并伴随着某种可验证的预期(检查点)。这意味着测试点，即在某种环境下，带有数据约束(条件)与检查点的测试意图；分析平台中支持结构分析的部分(结构分析模块)支持上述方法，它实现架构、单元、过程、接口、条件、行为的描述和可视化，并在此基础上批量生成IT和SIT环节中进行功能验证的测试点；业务分析的单元是情景。情景指的是应用系统加以支持的“最小业务意图”，其在系统层面的表现是一个(或一组)用户界面(UI flow)。业务规则是某个情景的规则组，这些规则构成了实现该业务意图的过程、限制或条件。业务分析的方法是把情景中的规则组形式化，具体方法就是把构成规则的诸要素的语义表达为一组(有限个)具体的“态”，由此形成一系列组合项。设规则组涉及的组合项为N，N个组合项形成了一个有限、离散的希尔伯特空间(Hilbert Space)；由于规则组构成了实现某业务意图的合法的方式，对于业务情景的覆盖应该理解为对规则组的覆盖。如果规则能够表达为if(要素及其逻辑)业务操作…else…的形式，从理论上可以证明，规则组覆盖的问题可以约化为白盒测试的路径覆盖。此时，全覆盖的问题是可解的。
在工程上，覆盖的问题一般会引起“组合爆炸”，因此，一般情况下，测试项目是不可能追求全覆盖的。这样就必然出现案例(此处表现为测试点)简约的问题，即，如何用数量有限的案例实现尽可能完整的覆盖；在案例简约领域，虽然有一些理想的算法(例如H算法、Z算法)，但它们都是集合论的某种抽象解，在工程上不具有可实现性。在业务分析的方法中，由于覆盖的问题被还原为对规则组的覆盖，覆盖的具体手段就可以表达为对于N维希尔伯特空间的覆盖(每一个测试点在这个空间中表现为一个N维矢量)，简约的问题就有更好的解法，即“网格简约法”；网格简约的第一步是把组合项划分为“区分点”和“条件”。所谓区分点，就是业务逻辑中能够引起业务操作分叉的那些要素，当这些要素取不同的态时，业务操作的逻辑会有所变化。而条件则是指单纯的限制(入口条件)，不满足这些限制业务操作无法进行；在这一基础上，网格简约首先保证各区分点之间的全组合(排除逻辑不可能的那些点)，并且把入口条件最常规的(业务上最可能发生的)态的组合设定为“正常条件”。“基础网格”就是正常条件下各区分点的逻辑上可能的全组合。在选取测试点是，基础网格要求全选，因为它代表了正常条件下的所有业务逻辑的路径。它代表了该情景下所有基本的或最高概率的业务路径；在正常条件之外，可以有各种业务上有意义的“异常条件”的组合，此时，至少有一个条件的态取了非最大概率的态。由此形成了一系列“扩展网格”，每一种异常条件支持一个扩展网格。业务分析的方法要求在扩展网格中按照业务上的关注程度选点，必须覆盖所有的扩展网格(即异常条件的组合)，但可以忽略其中不被关注的区分点组合(它们在正常条件下已经被覆盖了)；如果没有特殊的业务取向，在扩展网格中选点的另一个指导原则是pairwise算法；这一算法的基础是一个定理，这一定理指出，当N个要素的组合引起缺陷时，实际出现缺陷的概率随要素组合的阶数迅速下降，一阶(单个要素)组合引起缺陷的概率远大于二阶(两两组合)；二阶远大于三阶…如此类推。Pairwise定理证明：从概率的角度看，在组合爆炸的情况下，对于一阶、二阶的近似在概率上可以覆盖实际情况的90～95％，也就是说，只要我们有意识地保证所有组合项的两两组合(还可以排除掉业务上无意义的组合)，就可以在保证90～95％概率覆盖的前提下实现大规模的案例简约。
在业务分析的实践中，为了能够吸收业务经验的成分，一般是采用这两种方法的叠加，即在业务取向的基础上，辅之以pairwise，通过算法提供相关的审计。叠加的结果应该是对pairwise的改善，如果pairwise的概率覆盖为95％，则业务分析能够达到95％+。由于区分点代表着业务操作的分叉，仅仅对基础网格的覆盖就能够显著改善pairwise的覆盖，使之具体明确的业务内涵。
由于情景代表一个完整的业务意图，传统分析方法中的功能点一般来说是情景以下的某种特殊情况(情景的子节点)，在某些情况下是情景本身，在极为特殊的情况下表现为多个情景的流(业务流)。传统理论有两大命门：一是对功能点的划分没有一定之规，二是对于如何实现测试案例对功能点的覆盖没有任何站得住脚的理论。由此就不可避免地陷入了经验主义。业务分析的方法超越的传统的功能点覆盖，并且在工程上给出了案例简约的切实可行的方法。由于业务分析既考虑了业务流覆盖，也考虑了情景覆盖，功能点的覆盖被约化为对于情景和业务流的覆盖
最后应说明的是：以上所述的各实施例仅用于说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。