作者：朱祁恒
随着互联网行业的快速发展，银行系统更新迭代愈发频繁，系统运行的可靠性与稳定性显得更为重要，也给系统测试人员带来多重挑战。 以我行企业金融服务平台为例，该系统平台具有业务产品更新快速(近三年平台按每月两次投产的节奏快速更新)、应用系统关联复杂(相关业务严格依赖于BoEing、贸易通、C3等14个后台系统，关联性复杂)、项目组人员流动性大(近三年项目组开发、业务、测试人员交替频繁)等特点。这些客观因素导致测试团队在有限的测试周期内难以做到充分测试，其中首当其冲的就是测试设计不充分。
在测试设计环节，如何将需求语言文字转化为测试人员可理解、系统功能全覆盖、系统缺陷高命中的测试设计文档，成为当前测试工作亟待解决的重要问题。通过进一步分析，测试设计不充分主要由两方面因素导致：一是测试设计粒度难以统一；二是交易缺乏全局质量视图。
为提升测试质量，有效解决测试不充分的问题，北研测试部企业互联网金融测试组基于《IEEE/IEC/ISO 29119软件测试规范准则》，在实践中逐步形成一套渐进式标准化的测试设计方法——“生命之树”测试设计方法。
IEEE/IEC/ISO 29119软件测试规范
《IEEE/IEC/ISO 29119软件测试规范准则》(以下简称《准则》)作为行业准则标杆，将测试设计工作规范化，分为测试设计规范(Test Design Specification)、测试案例规范(Test Case Specification)、测试程序规范(Test Procedures Specification)三部分，各部分之间紧密联系、前后承接。同时，该准则准确定义了特征集(Feature Sets)、测试条件(Test Conditions)、测试覆盖项(Test Coverage Items)、测试案例(Test Cases)、测试集(Test Sets)、测试程序(Test Procedures)等概念，从测试对象分析到最终测试用例与测试程序设计进行了详细阐述(参见下图)。
在软件测试设计层级中，特征集(Feature Sets)包含被测项的所有测试特征与条件；测试条件(Test Conditions)作为特征集的一个子项，指系统的某一个可测试方面；测试覆盖项(Test Coverage Items)作为测试条件的子集，通过具体测试技术(等价类分析、边界值分析等)分析得到，形成最小的测试设计单元；测试案例(Test Cases)则是将不同测试条件中的测试覆盖项进行串联组合形成。测试案例生成后，根据不同的测试需求划分测试集(Test Sets)，并进一步编写测试程序(Test Procedures)，为测试执行做好准备。
“生命之树”测试设计方法理论体系
基于《准则》，结合测试工作实践，企业组形成一套规范的、可持续完善的测试设计方法——“生命之树”测试设计方法。 该方法分为交易级、系统级、组织级三个层级：1.交易级：以交易输入/输出项为切入点，严格按照系统测试设计技术(如等价类、边界值和场景法等)，从有效／无效两方面，推导出交易输入输出项的测试覆盖项(即标准化的测试点)；2.系统级：基于交易级测试设计规范体系，按照应用系统服务目录，以测试覆盖项为最小维度构建形成“生命之树”测试覆盖项资产库；3.组织级：在组织框架内，以“生命之树”测试覆盖项资产库为基础，形成资产库构建与项目测试设计的交互机制。
01
交易级测试设计规范体系
“生命之树”交易级测试设计层级规范基于系统/交易、输入输出项、测试覆盖项以及测试用例四个层级规范测试设计，各层级之间层层推演，形成一套可追溯、等粒度、全覆盖的测试设计规范体系，具体如下： 1)系统/交易：被测目标实体，不同交易之间具有相对独立性，同一交易由若干输入项与输出项组成。 2)输入输出项：分为输入项(Input)与输出项(Output)，若干输入项(Ii)、输出项(Oi)及关联关系(Fk)构成一个交易，可以用数学的形式表达为：Φ(O1，O2，……，On)=Fk(I1,I2,……,Im)。 3)测试覆盖项：某一输入项或输出项的具体取值，一个输入输出项可以视为一系列关联测试覆盖项的集合，例如对于输入项Ii，包含u个测试覆盖项，可表示为Ii=Ω(Ii-1，Ii-2，……，Ii-u)。 4)测试用例：对于某一交易，将其所包含的全量输入输出项选取特定测试覆盖项后，按照关联关系进行串联，形成一条测试用例，例如Φ(O1-8，O2-3，……，On-4)=Fk(I1-6,I2-13,……,Im-9)。
具体来看，“系统/交易”层级覆盖某测试特征集的所有关联系统与交易，保证不遗漏测试关联系统及交易。“输入输出项”层级针对某一交易涉及到的所有输入项与输出项，包括界面要素(例如单笔转账交易中“交易金额”输入项)以及隐含要素(例如单笔转账交易中“复核流程”输入项)。“测试覆盖项”层级针对某一输入输出项涉及到的所有测试覆盖项，通过等价类、边界值等测试设计方法分析生成。“测试用例”层级通过对测试覆盖项串联组合设计产生测试用例，并且需关注避免遗漏测试点。
02
系统级测试覆盖项资产库构建
为保证测试工作的持续性与可传递性，依托测试设计层级规范方法，以交易为维度持续梳理输入输出项与测试覆盖项，形成系统级测试资产库。 从系统角度来看，资产库目录构建与系统目录保持一致并动态更新，每一个系统作为资产库的一个端点，进一步细分为输入输出项、测试覆盖项，形成树状结构(即“生命之树”测试覆盖项资产库架构)。 测试覆盖项作为资产库最小单元，具有规则相对明晰、与功能实现关联性强、易于规范管理等特点，便于复用与更新。因此，“生命之树”测试设计体系将测试覆盖项作为资产库的铺底资产，在此基础上组合形成测试案例。其中，测试案例的整体设计需要保证避免产生测试覆盖项的孤点遗漏，即实现测试覆盖项的全面覆盖。
03
组织级测试设计交互机制
为实现“生命之树”资产库的持续更新，以及项目测试设计工作的有效开展，测试团队逐步构建起测试资产库与测试设计的交互机制，形成二者互相促进的良性循环。 在已有“生命之树”测试覆盖项资产库的基础上，某一交易进行需求优化改造时，可以下载并复用已有“生命之树”测试资产库中的输入输出项及测试覆盖项，避免测试设计的重复性以及随意性。而在本次需求改造中新增或修改的输入输出项及测试覆盖项，将上传至“生命之树”测试资产库中，实现资产库动态更新。
“生命之树”测试设计实践成果
目前，企业互联网金融测试组对于“生命之树”测试设计方法已达成共识，在项目开展过程中按“系统/交易-输入输出项-测试覆盖项-测试用例”这四个层级开展测试设计工作。
从2019年2月份开始试运行以来，测试团队已在14个投产窗口近100个项目投产批次中运用“生命之树”测试设计思路开展测试设计工作，在项目中设计输入输出项5100余个，测试覆盖项15500余个。输入输出项与测试覆盖项的分析过程有效避免了测试设计的随意性，提升了测试用例的质量与充分性，保证测试人员在需求不明晰、系统逻辑复杂的情况下将测试遗漏降到最小。
从效果角度来看，“生命之树”测试设计文档在用例评审时对于业务人员与开发人员具有更强的可读性，帮助开发人员提前发现系统改造程序遗漏。例如在对公收费平台上收企业网银相关费用项目中，通过梳理付款方账户类型、转账方式等输入项的全部测试覆盖项，帮助开发人员发现单位结算卡、预约转账等场景的程序设计遗漏，使缺陷定位从测试执行阶段前移至测试设计阶段。
基于“生命之树”测试设计方法体系，企业互联网金融测试组梳理企业金融服务平台现有359支交易，综合交易量、复杂度、交易类型等因素，按照风险模型等级划分“高”、“中”、“低”三类。
企业金融服务平台测试覆盖项资产库一期建设总体思路为：风险等级为“高”的交易资产积累粒度达到测试覆盖项(TCI);风险等级为“中”的交易资产积累粒度达到输入输出项(I/O);风险等级为“低”的交易资产积累粒度达到交易列示。截至目前，已实现82支“高”、“中”风险等级交易资产梳理，以及70支“低”风险等级交易列示，资产库交易覆盖率达到42.34%。
随着“生命之树”测试点资产积累体量的增大，已实现测试资产积累的交易数(Tl)将逐渐向实际交易总数(T)收敛趋近。而对于单支交易，已积累测试覆盖项数(Nl)也将逐渐向实际测试覆盖项总数(N)收敛趋近。
同时，规范的测试覆盖项有效减小了测试人员流动对测试工作的冲击，减少了测试人员在新项目开展时进行需求分析的时间成本，也为项目测试设计覆盖已知测试点，为项目充分测试提供保障。2018年及2019年人员调整时，依托现有“生命之树”测试资产，“对公收费平台上收企业网银相关费用项目”以及“企业金融服务平台(升级)及‘单一窗口’项目”工作交接平稳过度。
“生命之树”测试设计方法旨在通过统一测试概念、规范测试设计，在需求变更、系统迭代、人员流动频繁的现状下，解决系统测试不完备等实际问题。
该方法具有一定的延展性，在完成测试覆盖项积累的基础上，可以进一步实现测试数据库以及测试用例自动化脚本库的构建，为后续建设企业金融服务平台应用系统的“质量中心”、实现数说“测试质量”打下坚实基础。
(来自：我们的开心)
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
