华泰证券测试管理平台建设及应用情况分享

2018-08-08   出处:大商所行业测试中心  作/译者:大连飞创  

序言测试管理可以简单理解为测试活动的人、事、物的管理。人,指的是对测试人员的管理,建立一套可量化的评测体系来衡量测试人员的工作情况;事,主要指对测试流程方面的管理,将关键活动有序串联在一起,目的是量化流程管理;物,指的是对测试用例和测试结果的管理,目的是量化产品质量。随着证券行业信息技术的不断发展,大部分券商已开始或正在建立专业的测试队伍,测试活动也越来越多,测试管理的重要性也就显得愈发重要,本文旨在通过介绍华泰证券建设及应用测试管理平台的情况和相关经验,对同行在面临类似问题时,提供些许参考。

                                 

一、为什么要建设测试管理平台
如摘要所述,测试管理无非是人、事、物的管理,因为物是通过人和事的活动产生的,所以这三个核心因素中最重要的是人和事的管理。在华泰证券建设品质管理团队的过程中,组织规模在逐渐壮大,从最初的仅3个人目前已发展到了70人;所负责的产品也逐渐变多,从最初的仅负责集中交易系统的测试,到目前的与客户交易相关的几十个系统(包括多个版本)均已纳入测试范围。不断壮大的同时也带来了管理上的问题,即队伍大了不好带、事情多了不好管。实践证明,作坊式的测试管理手段已成为制约测试管理水平提升的主要障碍,进而影响了测试效率和测试质量。
怎么办?唯有建立有效的测试管理平台,使用技术手段优化测试管理手段方能解决上述问题。既然决定建设平台了,是选择自主研发还是外购产品呢?我们的选择是坚持走自主研发道路。不选择外购的原因是:
(一)合适的产品少:市面上的大多数产品要么关注于测试项目管理、要么关注于测试设计,能有机地将两者结合在一起的甚少(但据了解,大商所行业测试中心的测试管理平台就是一款不错的产品)。
(二)个性化需求多:市面上的产品大多是多行业通用类型,但证券行业与这些行业相比还是有自身的个性化特点,特别是华泰本身就是一个个性化极强,紧紧围绕优秀客户体验的注重自主研发的一家券商,本身的业务和开发流程与其他公司也未必相同,通用性的产品无法满足我们的个性化需求。
(三)需求响应不及时:厂商在决定开发一个功能时,势必会考虑这个功能其他客户是否有需要,投入产出比如何,应该怎样去满足通用性的口味要求,这就造成外购的产品往往开发速度极慢;相对的,自主研发的好处是需要什么功能就可以开发出什么功能出来,不必等、不必求,可形成完全匹配自身需求的测试管理体系。
但这里要澄清的是,自主研发不一定是最美好的,因为:
(一)成本要比外购的产品要高出数倍,且当使用人员一旦被开化了,各种新的需求会喷薄而出,每年都需要持续的保持一定比例的投入。
(二)大量的工作需要原创,从需求到分析到设计到研发到运维均需要有人牵头去消耗大量精力去操持,相应地,前述这些活动对测试队伍的人员素质要求会很高。
可是,尽管有这么多困难摆在我们面前,我们还是会坚定地坚持自主研发,因为自己的才是最好的,适合我们工作需要的才是最好的测试管理平台。

                               

二、如何建设测试管理平台
在做任何一件相对较大的事儿之前,第一要务是要做定位,本平台也不例外,我们将其定位为:主服务于测试团队内部成员,少部分兼顾外部团队需求,是一个强粘性的、便于测试人员提高工作效率和质量的“接地气”的测试管理平台。如图2.1所示,本平台围绕测试人员自身需求来建设,充分接地气,不考虑高大上的需求,以解决实际问题为第一要务。

                                                 图2.1 平台主要功能结构图

需求是能否成功达成定位要求的关键,本平台的需求来源于:
(一)管理者自身的管理需要及归纳总结后的通用性测试管理需求。
(二)测试人员通过平台的“意见箱”反馈的实际的使用需求。
放开广纳需求的口子之后往往导致新需求的数量会比较大,对于近期新开发功能的优化需求我们会第一时间处理,对于较大的需求,我们会把其排入至后续的开发计划中。一般每隔三个月,我们会停止平台级的大功能开发,集中一个月时间去处理搁置的需求,所以较难出现测试人员提的小需求积压严重的情况。此外,平台的开发力量使用自有的测试开发人员,平台的测试来自于自有的测试工程师,对于平台的功能设计也往往不会做过多的讨论,常规的做法是想通了就做,做好了再优化这样的套路。事实证明,前述做法在华泰证券还是比较有效的,开发效率较高,但这种做法未必值得在所有券商适用,因为对平台建设的相关人员要求还是很高的。

                                  

三、建设情况及相关经验介绍
经过1年的建设,测试管理平台已初见规模并全部模块均已在实际工作中得以应用。平台引入后,至少带来了以下两处明显收益:
·可管理更多的人员:圈里有一句话,一个正式员工只能带4名外包人员,但我们现在的正式员工可带8名以上;特别是对于新员工,稍加培训即可成为一名可开展工作的项目管理人员。
·可承接更多的产品、开展更多的测试活动:平台引入后,管理正规化了、流程显性化了、工作量化了、资源利用率提高了、管理的成本降低了,项目的周期和风险更可控了,这些改进均让我们的单位时间和资源的条件下,产出更多了。
本平台已建成的主要功能模块有:
·人员管理:证券公司自有测试人员少,外包员工多的特点驱使我们必须做精细化的人员管理,特别是将其工作业绩和个人绩效结合起来。
·自动QA:测试人员素质参差不齐,产出物质量得不到有效保障,之前需要投入大量的人力去逐个项目审查,不仅费时费力,且容易有漏网之鱼和法外之地,故建设了自动检查功能。
·测试工具集:例如接口调试、业务地图、小工具集、估值工具等这些都是为了满足测试过程中的实际需求,协助提升测试人员的工作效率和质量。
·管理工具集:例如提测管理、项目管理、需求管理、用例管理等,均是按测试生命周期,定制化的流程性工作所需的功能。
下文将概要性且挑选性地介绍各主要功能的建设情况及相关经验。
(一)人员管理
    我们的测试人员分为两类,一类是华泰员工,一类是外包厂商员工。华泰员工分为两个组,分别是业务测试组(负责功能测试,手段包括手工测试、UI自动化测试和接口自动化测试)和技术测试组(负责测试工具开发和非功能测试)。外包员工放置在外包人力资源池中,实时维护其忙闲情况及技能矩阵。当有项目提测时,根据项目的要求由华泰员工从外包资源池中挑选合适的人员组成临时项目组开展测试工作。

                                              图3.1 人员管理逻辑架构图
人员能力量化管理矩阵,是人员管理的核心功能。我们将测试人员所需掌握的技能全部分门别类标识出来并划定了多个级别,将之前无法量化的技能全部量化了,这样对于给员工定级、考核以及高效率使用人力资源都非常有帮助。此外,员工的技能级别考量是通过主观评分及客观考试数据来度量的,客观的考试数据来自于测试管理平台的知识库。
(二)产品管理及提测管理
产品管理包括被测系统的版本管理和测试仿真度度量。测试仿真度度量的目的是通过量化定义测试环境和测试覆盖率情况以便衡量某个产品的测试仿真度。提测管理主要是用来在每个月第一周获取并记录各个被测产品的提测计划,当提测计划发生变化或者在测试过程中版本发生变化时,变动历史会被忠实地记录在系统中,用以总结分析开发方面是否按期提测以及版本是否稳定。

                                                       图3.2产品管理和提测管理
(三)需求管理
在每次提测时我们会将原始需求做分析汇总并作为测试需求分析任务分配给测试人员,测试人员在对需求做分析后会形成待评审的测试需求。原始需求一般情况下都不会作为我们的直接测试需求,因为证券行业的原始需求一般都不规范,大部分都是一两句话或者是交易所的一大篇文章,我们必须将其转化为能够有效指导测试活动的测试需求。之后,我们会组织运维、开发、测试三方共同评审,评审的形式有邮件评审和会议评审,评审后就会定下来测试范围。这个测试范围非常重要,因为随着目前敏捷的思路愈发深入人心,券商也开展了敏捷形式的开发,虽然要在有限的时间内做尽量多的测试活动,但也未必能达到100%的覆盖率,所以这个确定好的需求就是我们后期的测试团队需要承担责任的范围,该范围以外的如果出现缺陷逃逸,则不属于我们的责任范围了。建议其他友商也可以采用这样的思路去界定自己的范围,明确告知相关团队我们的责任范围,避免后期扯皮的事情发生。

                                      图3.3测试需求分析在测试周期中的重要性

                                                           图3.4测试需求统一管理
 如图3.4所示,以经纪业务平台为例从2016年开始到2018年4月份已累计发布新增或修改功能点3万余次,我们都将其格式化的记录在了测试管理平台中,方便需求分析活动的开展和后续需求回溯活动。
(四)项目管理
    我们将每次有目的集体性行为都定义为项目,我们将项目分为了三种类型,分别是升级验收测试类、测试体系建设类和测试工具研发类。

                                                           图3.5项目分类
·升级验收测试类:即提测过来的产品,在我们这做最后一道关口的质量把关;在这之前有研发方面的自测,含开发商的和自主研发的。
·测试体系建设类:测试用例的新建、补充完善,自动化框架的建设、自动化脚本的编写、业务的梳理分析等等。
·测试工具研发类:大的——平台级别的测试工具,如测试管理平台、性能测试平台、接口测试平台等;小的——各被测产品所需的个性化测试工具。
 那么测试管理平台在验收测试工作都会起到哪些作用呢?让我们来看图3.6。测试管理的基本要素为时间、成本、范围、质量、风险和资源,这些基础数据全部在平台中管理后,后期想做什么功能便可以开发什么功能。建议有外购测试管理平台的同行在POC阶段时重点考察这些要素是否全部齐备,是否可以在原有基础上做个性化的二次开发。我们现在只是将这些基础元素放在平台里面做了管理,但暂时还没做数据分析,目前仅是靠我们的经验来从基础数据中根据经验人工分析以辅助决策,这也是我们后续的改进方向之一。

                                                 图3.6测试管理的基本要素
(五)接口调试
    为什么在这里只讲接口调试,因为在证券行业中,接口测试比UI自动化测试有着更广泛的用途,在测试体系建设中建议更多的向接口自动化测试倾斜。单元测试自动化,我们一般不去关注也没精力去关注,因为这是研发方面需要做的,每次提测时要求开发方面提供单元测试报告即可,不建议费精力去搞这方面的测试体系建设。UI自动化测试在我们看来仅适用于做些冒烟测试即可,由于UI测试成本太高,又需要去识别各种各样的控件,又需要去费心费力的去维护脚本,花了好多精力,测试覆盖率得不到有效的提升,此外还需要花大量的钱去买Licence,建议可以有,但适度即可。

                                                             图3.7功能测试手段金字塔
 说正题,接口调试是什么?它是我们在做正式的接口自动化测试前的手工调试工具。那有了HSAdmin之类的工具后,我们为什么还要搞接口调试工具,答案是因为它不专业。一个完整的接口调试活动建议按图3.8的方式来开展。

                                                     图3.8接口调试活动关联关系图
首先通过被测系统的生产日志中分析出生产上的各接口的调用频度,以便确定开展接口自动化测试建设的优先级;再从日志中分析出接口调用的实例,以便测试人员参考(由于接口文档一般写的都很粗糙,这种做法也是不得已而为之)。另外要对源代码有足够的解析能力,遍历源代码将接口全部列表、参数枚举值和接口调用模板全部获取到。将前述信息灌入至接口调试工具,测试人员只需动动参数值即可对实现对已支持的被测系统开展接口测试了,接口调试成功后即可将手工用例无缝转接至接口测试平台变为正式的自动化测试用例。
(六)用例管理
用例由两方面要素组成,一是测试脚本(手工用例的步骤也是脚本,只不过未自动化而已)、二是测试数据。测试数据建议额外开发测试数据构造工具,将平日的测试构造脚本整合起来,将生成的数据有机的管理起来。用例管理中需所有的自动化用例和手工用例统一管理起来,在测试需求分析完毕后,将其作为任务分配给测试人员。为了避免有漏测的情况,每条用例的执行必须有完整的测试执行留痕,整体的用例执行进度应有监控便于管理人员识别项目风险。最后测试执行完毕后,测试管理平台将缺陷、测试需求和用例执行情况整合在一起再通过测试管理平台的自动报告生成模块自动生成测试报告。按如此流程下来,测试过程将十分规范且很高效。

                                                         图3.9用例管理逻辑架构图
(七)缺陷管理
缺陷管理中最重要的是定义缺陷的属性和缺陷的处理流程。我们将缺陷的属性分为三类:状态、解决结果、是否对生产有影响。
状态为:待确认、测试专家确认、缺陷打回、已提交至开发商、缺陷关闭。
解决结果为:未解决、被否决、不解决、已解决。
是否对生产有影响:未评估、有影响、无影响。
上述几个状态的规则为:

                                                     图3.10缺陷状态规则
流转状态如图3.11所示。这里需要强调的是只有对生产有影响的缺陷才是有效缺陷,只有未解决、已提交至开发商、有影响的才为遗留缺陷。另外,开发商泛指研发团队和外部开发商,在我们看来他们都是开发商。


                                                        图3.11缺陷流转状态
(八)自动QA
自动QA的定义是:对测试管理平台中所管理的项目、流程、成果物等进行合规性自动检查,以发现不按照测试规范的工作活动,发现一起记录一起,并纳入到每个月的量化绩效考核中扣分,以此强制要求所有活动均按照规范来有序开展。为什么要开发这个功能呢?
·因为团队人员年轻,外包人员众多,素质、能力参差不齐
·责任心不强,不少人秉持着能混则混,能省则省的心态
·不想被表面光鲜的状态所蒙蔽,希望能看到潜在的风险
·方便对人员考核、方便对项目考核
从我们历史上发生过的缺陷逃逸的血的教训学习到:流程必须严格执行,不严格执行流程必然引致项目不可控,造成低级错误发生。
几乎每周都会检出不合规的项目出来,有些事情光靠宣贯是达不到目的的,必须有严格的检查手段,才能将问题暴露在阳光之下。                                                                                                                 

四、下一步的建设方向
虽然在测试管理上已取得了零到一的进展,但做的越多后会发现需要做的更多,测试管理平台仍需不断前进,下一步的建设方向除了完善平台本身的功能外,更重要的是要将这个平台变成一个智能化平台,关键步骤之一为智能生成测试用例。虽然测试设计在某种程度上属于测试活动中智力占比最高的内容,但这一活动长期受等价类、边界值等传统的测试设计思路限制,测试用例设计的质量和规模难以得到本质上的提升,且消耗了大量的人力、物力和时间,这一环节不实现突破何谈现代化的测试管理。故我们已开始在这方面做了一定的探索研究,且已取得了一点点成果,希望在未来能彻底将这一愿景落地,能够自动生成比人工方式还有效的测试用例,且能做到质量感知和缺陷预防。


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
222°|2229 人阅读|0 条评论

登录 后发表评论
最新文章