1、目录01刊首语 刊首语Sentence02编委名单P03 参与报告编委名单Editorial board member03基本情况P03年度报告调查基本情况Basic information06报告分析和数据展现P09报告分析和数据展现Key point and data analysis05年度报告主要观点 P06年度报告主要观点Key points of the annual report04专家智囊团 P05年度报告专家成员Annual report brain trust07案例分享P31通信-中国联通软件研究院银行-中国光大银行股份有限公司证券-国泰君安证券股份有限公司资管-百年保险

2、资产管理有限责任公司科技-上海安般信息科技有限公司Case study08评价认证介绍P47测试敏捷化成熟度评价认证介绍成熟度评价及见证机构Maturity evaluation专家名单0102刊首语Preface以质驭效，起质量的时候不掉速，起速度的时候不掉链“以质驭效”是在一次质量中台沙龙中起的名字。因为面向金融行业，所以“质量”在先，结合监管和稳定的诉求，用了“驾驭”来表现专有的行业特征以及对效率的平衡。当持续交付成为一种端到端价值实现的指导思想时，质量是内化于其中的潜意识。即使我们在推行效率时不太刻意谈及质量，但质量无处不在。真正理解“以质驭效”是在2022年。这一年的10月，光大银行

3、启动测试敏捷化成熟度评估项目。在三个月的评估辅导过程中，最大收获是认识到要实现整体质量稳定输出的不是某个项目或某个技术平台的能力，而是组织级测试能力建设。在这层组织级保证的基础上，我们才得以更好地推动测试敏捷项目创新和实践，以最大的质量稳定性保证测试的创新探索成效，实现测试的整体效率提升。“以质驭效”可以看做是组织进行质效管理的行动指导，落到实处需要更加明确的指引。基于光大银行的测试能力体系建设，我们引申出四大组织级的测试能力，即“组织级测试体系管理能力”“组织级测试技术建设能力”“组织级测试人员管理能力”“组织级测试环境和数据管理能力”等。2023年4月，国泰君安证券在测试敏捷化成熟度评审时

4、也用了“以质驭效”来高度概括组织测试能力建设的主导思想。不论是核心交易系统，还是手机APP都体现出对稳敏双态业务模式的兼容，对“以质驭效”行动指导的遵循。券商和银行虽然由于业务模式的差异，其测试体系和测试能力的建设各有特色，但在质量和效率的平衡上保持着相同的认知。测试敏捷化的目的是希望通过“以质驭效”来赋能组织的质效管理建设，不断地平衡测试效率与安全、质量与稳定的关系；促进组织文化对测试赋能的理解和吸纳；解决测试强流程管控与快速多变需求的冲突；构建适配业务敏捷所需要的持续测试能力，实现端到端高质量的价值交付。从这一两年对行业的观察来看，敏捷测试指标体系将会是未来2-3年，甚至是5年内测试重点关

5、注和建设的内容。因为可量化的指标是“以质驭效”中“质”的表征，“驭”的手段。所以，用量化指标定义“质量”，用量化指标把握“效率”，用量化指标观察“质效管理”的整体效果。如此这般，我们在推行测试敏捷化转型的时候，才能真正地做到：起质量的时候不掉速，起速度的时候不掉链！2022-2023年度行业测试敏捷化成熟度年度报告 虽然只是第二年发布，时间沉淀还不够，行业积累还不深，但中国计量科学研究院、中国质量认证中心和双态IT论坛依然本着为中国软件测试敏捷化转型赋能的淳朴愿望，坚持做基础性的数据统计和分析工作，展现软件测试行业在过去一年的所思所想和所作所为。数据虽有局限，但内容依然精彩！2022-2023

6、年度行业测试敏捷化成熟度年度报告 主编03年度报告基本情况Basic information报告调研过程和结果调研问卷是 2022-2023行业测试敏捷化成熟度年度报告 的核心组成部分，旨在全面了解测试敏捷化在行业的发展现状、建设难点、转型痛点以及对未来的规划和展望。本次调研内容涵盖测试的组织架构定位、人员构成、能力认证、敏捷转型、测试工具链、测试流程与管理、测试实践、测试持续优化、度量体系以及团队协作等多个领域。调研问卷的内容来自测试敏捷转型一线，体现了他们对转型的思考以及遇到的问题。希望通过这些调研数据，了解行业的探索实践，为测试敏捷化转型提供有益的参考和指导，积极促进行业的创新和发展。(

7、一)调查对象年度报告的对象主要包括：金融行业，如：银行、保险、证券、基金；能源电力行业；通信行业；科技公司；服务外包;制造业等在测试敏捷化有一定实践的单位。(二)问卷发放定向发放：以金融行业为主，同时涉及通信、科技公司等，对质量和测试的负责人进行定向发放。(三)问卷分析1.确定统计标签：结合测试敏捷化的发展特点及热点，经编写组讨论投票确定标签。2.识别统计标签：针对回答描述进行标签识别。3.统计排序：根据标签识别的数据统计各类问题TOP标签排序。分析解读：（1）统计呈现；（2）统计说明；（3）专家解读。(四)调查样本本次调研样本选择定向发放。调研样本根据一定比例的行业分布选取，其中有56家金融

8、企业包括基金、保险、证券、银行等、3家通信公司、4家科技公司、9家传统行业公司，共计回收调研问卷196份。筛选出有效问卷95份。相较于2021-2022年度的85份，同比增长11.8%。样本中金融占81%，科技通信类占8%，能源电力占4%，其它占比7%。调研问卷基于测试敏捷化转型的主题由行业测试专家提供，对同一组织的问卷结果进行去重分析和有效性筛选，确保信度和效度。(五)调查统计说明本次调研问卷以测试敏捷转型为重点，设计34个问题以了解行业在测试敏捷化转型的现状，包括：1.测试组织的基本信息、人员构成、组织定位以及战略规划。2.开发敏捷转型、测试敏捷转型以及组织能力认证情况。3.测试流程、测试

9、平台规划建设、测试环境管理、测试团队建设和管理以及测试工具体系。4.测试敏捷化实践的工作模式以及团队协作。5.测试左移、测试右移以及缺陷管理持续优化。6.质效度量体系的建设、运行以及评估机制。报告的局限和约束年度报告可能存在以下导致局限和约束的情况：1.受问卷填写人员所处的组织环境和组织架构差异，可能会对某些概念存在歧义进而影响调研结果。2.受问卷填写人员的级别和调研问题适用的范围影响，对某些问题的理解存在差异进而影响调研结果。3.行业不同带来的测试组织管理差异性对某些问题的理解和回答会影响调研结果。04报告编写指导委员会陈嘉陈凯戴鹏高翀洪佩雯胡小丽纪飞李进明沈庆飞史新丽孙小霞孙翊威汪健王叶楠

10、王月婷文俊吴锦武彤杨忠琪殷柱伟战玲玲张翀张宏英郑涓上海浦东发展银行卡中心中国质量认证中心上海金融期货信息技术有限公司华为云计算有限公司德邦证券股份有限公司光大银行股份有限公司海通证券股份有限公司国泰君安证券股份有限公司中国计量科学研究院中国光大银行股份有限公司中移（苏州）软件技术有限公司上海翰纬信息科技有限公司太保科技服务（武汉）有限公司中国质量认证中心光大证券股份有限公司易方达基金管理有限公司 华夏银行股份有限公司中国计量科学研究院东方证券股份有限公司腾讯科技（上海）有限公司中国银行股份有限公司建信金融科技有限责任公司中国东方航空集团有限公司中国质量认证中心0506年度报告专家智囊团Annu

11、al report brain trust蔡超曹栋陈霁曹忠华陈冠诚陈皓陈坤龙陈磊陈婷程琳琳邓雯邸望春丁博丁伟董鹏龚剑顾华来郭松郭伟辰贺章辉侯玉桥胡涛互联网测试开发社群VIPTEST上海浦东发展银行股份有限公司上海晦霁信息科技太平洋健康保险股份有限公司北京云测信息技术有限公司腾讯科技有限公司TCL实业集团有限公司某券商测试敏捷化专家北京国家金融科技认证中心中国邮储储蓄银行有限责任公司厦门银行股份有限公司中移（苏州）软件技术有限公司华宝证券股份有限公司国泰君安证券股份有限公司北京银行股份有限公司银河证券股份有限公司东吴证券股份有限公司科大讯飞股份有限公司合众新能源汽车股份有限公司上海农村商业银行华

12、夏银行股份有限公司杭州飞致云信息科技有限公司姬浩生金晶李斌李诚李淳李德宝李建斌李萍李娴李尧尧梁晶刘光宇刘韬芦越陆丰罗冰罗琼吕理伟倪佳乐彭杰任慧沈庆飞中银富登村镇银行股份有限公司江苏满运软件科技有限公司广发基金管理有限公司上海黄金交易所光大科技有限公司某消费金融测试专家中国联合网络通信有限公司软件研究院泰康养老保险股份有限公司广发证券股份有限公司招商证券股份有限公司北京字节跳动科技有限公司中信银行股份有限公司台州银行股份有限公司中国太平洋财产保险股份有限公司太保科技有限公司小米科技有限责任公司国泰君安证券股份有限公司微创（中国）有限公司上海浦东发展银行卡中心北京仁科互动网络技术有限公司 富国基金

13、管理有限公司中国计量科学研究院史敏宋云鹏王富王海燕王晓敏王洋王兆红王智臣吴德洲向力谢子怡杨爱珍杨柟 姚冬姚尧于航余于平张宏英张立华张莉张世同上海米哈游网络科技股份有限公司北京自如信息科技有限公司广州掌动智能科技有限公司台州银行股份有限公司农银金融科技有限责任公司航天一院软件评测中心上海翰纬信息科技有限公司宁波银行股份有限公司西南证券股份有限公司华夏银行股份有限公司四川省农村信用社联合社建信金融科技有限责任公司锦州银行华为云计算有限公司中国计量科学研究院北京宇信科技集团股份有限公司西部证券股份有限公司中国东方航空集团有限公司TesterHome社区大众酷翼（北京）科技有限公司广发证券股份有限公司

14、张亚光张晔张英英赵国玉赵寅宁赵政华郑炳祥钟思德周传欢朱宝平安科技股份有限公司腾讯科技有限公司上海翰纬信息科技有限公司北京自如信息科技有限公司华夏银行股份有限公司光大科技有限公司厦门国际银行股份有限公司上海恺英网络科技有限公司上海复深蓝软件股份有限公司上海元方科技股份有限公司KEY POINTSOF ANNUAL REPORT年度报告主要观点观点，基于抽样的结果而提炼观点，因为个人的经验而局限观点，融入读者的认知而多样相比上一年度，测试人员在50-300人范围内呈增长趋势。1测试管理职能在组织架构中独立设置和运行是发展主流。2开发与测试比与组织的资源投入，对质量的重视程度以及系统稳定、自动化程度

15、高度相关。3建立专职的测试技术团队是构建组织级测试能力的重要保证。测试实践过程重视体系化管理，正逐步改变原来松散的管理模式。质量并非只是测试的责任，而是需要团队每个角色的共同努力。6单元测试对人员能力和成本都有较高要求，并非本身无意愿，现阶段推动单元测试仍有较高阻力。7测试质量效能度量尚在起步阶段，消费场景和体系建设仍在探索阶段。8在质量保证方面正逐步形成从需求分析到生产环境的全面覆盖，注重提升端到端的质量保障能力。9敏捷聚焦在项目级的质效提升。组织级测试敏捷化更加考验测试的整体规划能力和建设水平。10自有人数占总人数20%以下占44.7%；20%-40%占25.9%；40%-60%占13%。

16、主要发现1.整体来看，自有测试员工占比不高，对外包测试的依赖度仍然比较高。2.基于行业经验，自有测试人员与外包测试人员的分工正在呈现分层化趋势，自有测试人员偏重管理与测试设计，外包测试人员则更偏重测试执行，两者互补。3.自有人员比例有上涨趋势。由于对自主可控更加重视，IT组织不仅加大开发阶段的自主可控投入，同时也加大了测试阶段的自主投入。0910年度报告数据展现和主要发现Basic information第1题 您所在的测试组织的总人数（含自有、外包）范围在？统计说明测试总人数在20-50人的占23.2%；50-100人和100-300人的各占22.1%；20人以内占比18.9%；300-60

17、0人占6.3%；600人以上占7.3%。测试总人数在20-50人占比为25.9%；20人以内和100-300人的各占18.8%；50-100人占15.3%；300-600人占7.1%；600人以上占14.1%。主要发现1.相比上一年度，测试人员在50-300人范围内呈增长趋势。2.近2年数据显示测试组织规模主要集中在300人以内，其中50人以上规模增长明显。3.300人以上的测试组织人数有所下降。测试团队的规模大小可能与业务模式、测试组织架构、自动化程度等有关。图 1：2022-2023年度测试组织的总人数范围统计图 3：2021-2022年度和2022-2023年度测试组织的总人数范围占比统

18、计图 2：2021-2022年度测试组织的总人数范围统计51015202520人以内20-50人50-100人100-300人300-600人600人以上051015202520人以内20-50人50-100人100-300人300-600人600人以上第2题 您所在测试组织的自有人数占总人数（含自有、外包）占比？统计说明考虑到不同行业，不同组织的差异，调研结果仅供参考。10%-20%的测试自有人员占比最高，25.3%；20%-30%占15.8%；40%-60%和80%以上各占14.7%；10%以下占13.6%。图 4：2022-2023年度测试组织

19、的自有人数占总人数的区间统计图6：2021-2022年度和2022-2023年度测试组织的自有人数占总人数的区间占比统计382202530354020%以下20%-40%40%-60%60%-80%80%-100%4051015202510%以下10%-20%20%-30%30%-40%40%-60%60%-80%80%以上图 5：2021-2022年度测试组织的自有人数占总人数的区间统计18.8%25.9%15.3%18.8%7.1%14.1%18.9%23.2%22.1%22.1%6.3%7.4%0%5%10%15%20%25%30%20人以内2

20、0-50人50-100人100-300人300-600人600人以上2021-2022年度2022-2023年度44.7%25.9%12.9%7.1%9.4%38.9%25.3%14.7%6.3%14.7%0%5%10%15%20%25%30%35%40%45%50%20%以下20%-40%40%-60%60%-80%80%-100%2021-2022年度2022-2023年度数据展现和主要发现数据展现和主要发现1112第3题 您所在的测试职能团队，在IT组织架构中的定位是？统计说明 图 7：2022-2023年度测试团队在IT架构中的定位统计测试职能团队与开发和运维组织平级的占37.9%；属

21、于开发组织但管理独立的占23.2%；属于业务部门的独立测试团队的占22.1%。图 8：2021-2022年度测试团队在IT架构中的定位统计图 9：2021-2022年度和2022-2023年度测试团队在IT架构中的定位占比统计540附属于开发组织属于开发组织但管理独立与开发组织和运维组织平级属于运维组织但管理独立属于业务部门的独立测试团队测试职能团队与开发和运维组织平级的组织占41.2%；属于业务部门的独立测试团队的占比为16.5%；属于开发组织但管理独立的占比为20%。540附属于开发组织属于开发组织但管

22、理独立与开发组织和运维组织平级属于运维组织但管理独立属于业务部门的独立测试团队主要发现1.测试管理职能在组织架构中独立设置和运行是发展主流。2.基于行业经验来看，最近几年测试组织的变革出现过几轮与业务、开发之间分分合合。但总的来说，还是趋于独立。3.测试管理职能独立性的表现形式多样，这与行业特点、组织管理模式、测试重视程度等相关。4.“属于业务部门但管理独立”的统计数据有增长。一般来说业务和科技是两条线，这个数据的变化可能代表了业务与技术融合的一种趋势。第4题 您所在的组织中测试职能人员与开发职能人员配比是?统计说明测试开发比在1:4-1:6的占33.7%；测试开发比在1:8以上的占21.1%

23、；1:6-1:8的占17.9%；测试开发比1:2-1:4的占15.8%。图 10：2022-2023年度测试与开发配比数据统计图 12：2021-2022年度和2022-2023年度组织中测试与开发配比的占比统计0.00.20.40.60.81.00.00.20.40.60.81.0图 11：2021-2022年度测试与开发配比数据统计测试与开发比在1:4-1:6的占36.5%；测试开发比在1:2-1:4占27.1%；测试开发比1:6-1:8的占15.3%；测试开发比1:8以上的占13%。主要发现1.统计结果受系统/产品成熟度、系统数量、技术架构稳定性、并行迭代量等多方面因素的影响，测试组织可

24、以结合自身情况决定开发测试人员配比。2.1:4-1:6配比保持在1/3。测试整体表现出从高配比向低配比转变的趋势。3.开发测试比持续拉大，与敏捷开发，持续测试等工作开展有一定关联，测试左移渗透。人人测试，处处测试理念，推动更多的测试工作在开发阶段实施。4.开发与测试比与组织的资源投入，对质量的重视程度以及系统稳定、自动化程度高度相关。551:2以下1:2-1:41:4-1:61:6-1:81:8以上7233202530351:2以下1:2-1:41:4-1:61:6-1:81:8以上10.5%23.2%37.9%6.3%22.1

25、%14.1%20.0%41.2%8.2%16.5%0%5%10%15%20%25%30%35%40%45%附属于开发组织属于开发组织但管理独立与开发组织和运维组织平级属于运维组织但管理独立属于业务部门的独立测试团队2021-2022年度2022-2023年度8.2%27.1%36.5%15.3%12.9%11.6%15.8%33.7%17.9%21.1%0%5%10%15%20%25%30%35%40%1:2以下1:2-1:41:4-1:61:6-1:81:8以上2021-2022年度2022-2023年度1314第5题&第6题 您所在的组织2023年及以前通过以下哪些认证?统计说明2022年

26、之前38.9%的组织无相关认证；22.2%的组织有CMMI认证；16.7%的组织有TMMi认证；13.3%的组织有DevOps认证；1.1%的组织有测试敏捷化成熟度认证。图 13：2022年及以前认证组织的数据统计图 14：2023年计划认证组织的数据统计3570无其它TMMiCMMIDevOps测试敏捷化成熟度44520304050无其它TMMiCMMIDevOps测试敏捷化成熟度2023年46.3%的组织无认证计划；13.7%的组织有CMMI认证计划；12.6%的组织有DevOps认证计划；11.5%的组织有TMMi认证计划

27、；10.5%的组织有测试敏捷化成熟度认证计划。主要发现1.2022-2023年度计划认证的组织数量较2021-2022年度增加20%，反映组织对软件质量和流程改进的重视，其中20%的组织计划在2023年进行测试敏捷化认证。2.组织对软件质量和流程改进越来越重视。测试敏捷化成熟度得到市场关注。3.测试对自身能力建设和行业能力证明的意识正在提高，但是行业缺乏测试相关的体系认证。图 15：2022年及以前和2023年计划认证组织的数量对比第7题&第8题 您所在的开发组织/测试组织是否开始敏捷转型？统计说明开发敏捷转型中，73.7%的组织已开始转型；11.6%的组织未转型；14.8%的组织还在观望。图

28、 16：2022-2023年度开发组织敏捷转型的数据统计0.00.20.40.60.81.0图 17：2022-2023年度测试组织敏捷转型的数据统计704050607080是否还在观望56405060是否还在观望0.00.20.40.60.81.00.00.20.40.60.81.0测试敏捷转型中，58.9%的组织已开始转型；15.8%的组织未转型；25.3%的组织还在观望。图 18：测试组织敏捷转型和开发组织敏捷转型的数据对比主要发现1.测试敏捷转型是行业趋势，测试人员需要为此做好准备，持续测试，持续反馈成为必备的技能。2.基于行业经验，测试敏捷

29、转型一般会跟随开发敏捷转型。但也存在开发敏捷转型先行，再推广到测试的情况。60720070802022年及以前2023年7007080是否还在观望开发组织敏捷转型测试组织敏捷转型数据展现和主要发现数据展现和主要发现1516图 19：2022-2023年度组织是否有统一测试技术团队的数据统计0.00.20.40.60.81.00.00.20.40.60.81.00.00.20.40.60.81.0684050607080有无，各项目团队自己负责正在建设统一的测试技术团队还在考虑中第12题 您所在的组织在敏捷实

30、践中是否有遵循CMMI或TMMi体系的要求?统计说明73.7%的组织遵循CMMI或TMMi体系但针对实际情况做了调整；20%的组织不遵循；6.3%的组织认为CMMI或TMMi不适合敏捷实践。主要发现1.测试实践过程重视体系化管理，正逐步改变原来松散的管理模式。2.标准在落地时都会根据团队现状进行调整或裁剪。3.CMMI、TMMi和敏捷其实并不冲突。在敏捷实践中，组织仍然会遵循CMMI或TMMi体系的指导思想。第9题 您所在的组织是否有统一的测试技术团队，负责测试平台统一规划、统一建设和统一运维?统计说明71.6%的组织已建立统一的测试技术团队；16.8%的组织未形成统一测试技术团队；9.5%的

31、组织正在建设统一测试技术团队；2.1%的组织还在考虑中。主要发现1.建立统一的测试技术团队是构建组织级测试能力重要保证。2.统一测试技术资源，根据业务实际情况按需分配，提高人员复用率，进一步降本增效。3.测试团队正在向全栈技术能力进阶。图 22：2022-2023年度组织在敏捷实践中是否遵循CMMI或TMM体系的数据统计70650607080有遵循但做了裁剪CMMI 或TMMi 不适用敏捷实践不遵循图 21：2022-2023年度组织是否有统一测试外包资源的数据统计603050070有，组织有一个共用测试外包资源池，统一管理无，不同测试团队各自有外包

32、资源池正在建设统一的测试外包资源池第11题 您所在的组织是否建立统一的测试外包资源?统计说明有统一的测试外包资源池占63.2%；31.6%还在采用各自管理的方式；5.3%正在建设统一的测试外包资源池。主要发现1.基于成本和编制考虑，组织仍然采用人员外包来满足业务需求。2.组织建立统一的测试外包资源池，统一管理是主流选择。第10题 您所在的组织是否有专职的测试环境管理团队?统计说明专职专管测试环境的占比为45.3%；35.8%由测试人员兼职管理测试环境；15.8%的测试环境由运维统一管理。主要发现1.专职管理测试环境人员占比仍不到半数。2.测试人员参与到测试环境管理，开始自主运维测试环境。3.专

33、职或兼职测试环境管理占比81.1%，测试团队管理测试环境已是主流趋势。图 20：2022-2023年度组织是否有专职测试环境管理团队的数据统计43342530354045有，在测试组织中专职团队负责无，在测试组织中安排兼职人员负责管理无，运维统一负责还在考虑中数据展现和主要发现数据展现和主要发现1718年度报告数据展现和主要发现Basic information0.00.20.40.60.81.00.00.20.40.60.81.00.00.20.40.60.81.0第13题 您所在组织选择敏捷试点项目的标准是?（多选）统计说明判断项目是否适合敏捷，依据业务特性占比为76

34、.8%；依据系统的需求量占比为52.6%；依据前中后台系统特点占比为35.8%；基于组织考核要求的占比为20%；凭经验选试点项目占比为15.8%。主要发现1.依据业务特性、系统的需求量和前中后台系统特点来判断项目是否采用敏捷方法是综合考虑的关键因素。2.组织选择是否敏捷，主要是根据业务特性本身来判断是否适用，这符合测试敏捷化向更高效、更敏捷交付模式转型的特性。3.组织会选择业务特性和需求量来确定敏捷试点范围，如渠道类系统变更多，投产频率高等特点更适合业务上敏捷的需要，需求量大的系统更能够体现敏捷的效果。图 23：2022-2023年度组织选择敏捷试点项目标准的分类统计0.00.20.40.60

35、.81.00.00.20.40.60.81.00.00.20.40.60.81.0第15题 您所在的测试团队在敏捷实践中承担的责任是?统计说明测试对产品有建议权占比40%；测试对产品有评审权占比34.7%；测试对产品有决定权占比12.6%；测试没有影响力占比12.6%。主要发现1.测试左移与测试右移，可以让测试活动更好的推进和落地。更多的权利意味着更多的责任，需要理清边界。2测试团队在敏捷实践中，通过对整个交付过程的建议和评审，为产品交付质量提供重要的保障和支持。3.综合14&15题来看，在敏捷实践中，测试参与度和话语权都比较高。同时说明质量并非只是测试的责任，而是需要团队每个角色的共同努力。

36、4.认为测试没有影响力或仅建议权的仍占50%以上。5073344050607080依据系统的需求量来选择依据业务特性来选择依据前中后台系统特点来选择基于公司考核要求来选择凭经验选试点项目0.00.20.40.60.81.00.00.20.40.60.81.0第14题 您所在产品或项目团队敏捷实践工作模式有哪些?统计说明测试团队与业务、开发团队共建敏捷团队占比为37.9%；测试与开发共建敏捷团队占比为26.3%；测试与开发共建敏捷团队派驻业务部门占比为21.1%；业务与开发共建敏捷团队，测试辅助参与占比为14.7%。主要发现1.整体来看，测试和需求、开发之间的沟通和协调是敏

37、捷实践中的一个关键因素，需要建立有效的合作机制。2.测试团队作为敏捷团队的一部分占37.9%，体现了测试敏捷化的重要性。2036255303540测试团队与开发团队共同组建敏捷团队派驻业务部门测试团队与业务部门、开发团队共同组建敏捷团队测试团队与开发团队共同组建敏捷团队业务部门与开发共同组建敏捷团队，测试部门辅助参与图 24：2022-2023年度团队敏捷实践工作模式的分类统计00测试只是旁路，没有影响力测试对于产品端到端交付过程有建议权测试对于产品端到端交付结果有评审权测试对于产品端到端交付质量有决定权图 25：2022-20

38、23年度测试团队在敏捷实践中承担的责任类型统计第16题 单元测试在项目团队中常存在难以推广的现象，您认为最重要原因是?（多选）统计说明人员能力不足占比62.1%；成本太高占比61.1%；组织不考核占比47.4%；系统不适用占比16.8%；其它因素占比3.4%。主要发现1.人员能力不足、成本太高和组织不考核是影响单元测试推广的主要原因。2.质量是不是所有团队的第一选择，当团队业务对质量有非常高的要求时，单元测试推进就会相对顺利。如果不是，高成本的质量是否对团队有利，值得讨论。3.单元测试对人员能力和成本都有较高要求，并非本身无意愿，现阶段推动单元测试仍有较高阻力。图 26：2022-2023年度

39、单元测试在项目中难以推广的原因分类统计3203040506070其它原因系统不适用成本太高人员能力不足组织不考核数据展现和主要发现数据展现和主要发现业务知识及需求分析能力与沟通与人际关系各占19.9%；环境及配置管理占14.1%；自动化脚本编写能力与专项测试能力各占13.3%。主要发现1.业务知识及需求分析能力、软技能和自动化能力被认为是测试人员最关键的能力。其中自动化测试能力要求有所提升。2.测试人员具备多元化技能，以满足不同项目和团队的需求。3.运维能力要求下降，这与运维侧加大云原生能力建设有关。4.测试人员角色正在逐步细分，越来越多的组织选择构筑统一的专项测试人员资

40、源池来满足整个组织的需要，对项目内测试人员的专项测试技能要求逐渐降低。数据展现和主要发现数据展现和主要发现1920Basic information第17题 您所在组织的敏捷测试工具链建设情况是怎样的?统计说明38.9%的测试部门有统一测试平台，但未能覆盖组织全部研发流程，这意味着组织在敏捷测试工具链建设上仍存在一定的局限性；有限的测试工具链占比23.2%；组织级研发效能一体的测试工具链占比22.1%；测试工具建设不成体系的占比15.8%。主要发现1.测试工具可以更好地提升测试效率，但并不一定是大而全的建设，应以解决实际问题为主，不重复建设。2.50%左右的组织都已在敏捷测试工具链上有投入，工

41、具对测试效能的提升正在被重视。3.统一构建组织级效能平台和测试平台占主要比例，这将有利于测试工具整体规划，避免重复造轮子。图 27：2022-2023年度组织的敏捷测试工具链建设情况统计0.00.20.40.60.81.00.00.20.40.60.81.0第19题 您认为敏捷实践对测试人员最必要的三个要求是?（多选）统计说明业务知识及需求分析能力占31.6%；自动化测试脚本编写能力占20.1%；沟通与人际关系占18.6%；专项测试能力（性能、兼容性）占11.9%。第18题 您所在组织的质量效能度量是如何开展?（多选）统计说明在质效度量方面，有17.9%的组织取得了较好的成果，能够为组织的发展

42、和决策提供有力的数据支持；占比31.6%的组织处于试点阶段，尚未形成质效度量；占比30.5%的组织已建立质效体系，但消费场景不足；占比54.7%的组织已有数据积累但未形成体系。主要发现1.测试质量效能度量尚在起步阶段，消费场景和体系建设仍在探索阶段。2.效能度量提出来很久，但在落地实践时存在较大问题，组织和成员对于度量的预期目标不一样，当数据通过透明的方式展现在所有人面前时，对于组织和个人都是比较大的挑战。一个不好的引导指标可能会破坏团队氛围。对于度量指标的选择，需要慎重。图 28：2022-2023年度组织开展质量效能度量情况统计图 29：2022-2023年度敏捷实践对测试人员必要要求的分

43、类统计图 31：2021-2022年度和2022-2023年度敏捷实践对测试人员必要要求的分类占比统计00测试工具离散建设，不成体系有限的工具链测试部门的统一测试平台建成企业级研发效能一体化平台3052295060试点阶段未开展质量效能度量已有数据积累，还在探索未能形成体系成质量效能度量体系，但消费场景不足质量效能度量体系有足够的数据支持各类消费场景及管理决策855054230405060708090业务知识及需求分析能力沟通与人际处理低代码方式下自动化测试脚本编写环境及配置管理开发编程能力专项测试能力(性

44、能、兼容性）懂运维，如:数据库、操作系统、中间件、网络协议等5582582852825500708090（低代码方式下）自动化测试脚本编写沟通与人际处理环境及配置管理开发编程能力数据库、操作系统、中间件、网络协议业务知识及需求分析能力专项测试能力（性能、兼容性）图 30：2021-2022年度敏捷实践对测试人员必要要求的分类统计31.6%18.6%20.1%8.6%5.9%11.9%3.3%19.9%19.9%13.3%14.1%6.8%13.3%12.6%0%5%10%15%20%25%30%35%业务知识及需求分析能力沟通与人际处理低代码方式下自动化测试脚本编写环境及

45、配置管理开发编程能力专项测试能力(性能、兼容性）懂运维，如:数据库、操作系统、中间件、网络协议等2021-2022年度2022-2023年度2122第20题 您的团队在测试左移中进行了哪些实践?统计说明42%的组织向业务需求端左移；21.9%的组织构建质量能力平台赋能研发实现左移；15.4%的组织参与开发架构质量评估实现左移。7020304050607080向业务需求端左移（如:实例化需求）基于验收标准的BDD基于代码的TDD参与开发架构的质量评估构建质量能力平台赋能研发图 32：2022-2023年度测试左移数据统计图 34：2021-2022年度和2022-2023年

46、度团队实践测试左移的占比统计202030405060参与开发架构的质量评估构建质量能力平台赋能研发基于代码的TDD基于验收标准的BDD向业务需求端左移（如：实例化需求）图 33：2021-2022年度测试左移数据统计36.2%的组织向业务需求端左移；34%的组织构建质量能力平台赋能研发；25%的基于验收标准的BDD。主要发现1.在质量保证方面正逐步形成从需求分析到生产环境的全面覆盖，注重提升端到端的质量保障能力。2.42%的组织实现了测试左移到需求环节，让测试的焦点从发现缺陷转移到预防缺陷。3.TDD 和BDD 占比仍然不高，开发人员开展测试活动不足。0.00.20.40

47、.60.81.00.00.20.40.60.81.0第21题 您的团队在测试右移中进行了哪些实践?统计说明23.9%的组织通过赋能生产环境的测试能力实现右移；22.2%的组织为业务部门提供业务逻辑和系统关系的培训实现右移；赋能生产监控实现右移占17%；5%的组织没有进行测试右移。图 35：2022-2023年度测试右移数据统计图 36：2021-2022年度测试右移数据统计33.1%的组织通过业务部门提供业务逻辑和系统关系的培训实现右移；30.3%的组织赋能生产环境的测试能力；20%的组织赋能生产监控实现右移。图 37：2021-2022年度和2022-2023年度团队实践测试右移的占比统计主

48、要发现1.相比测试左移的实践，测试右移的实践呈现了倒退趋势。可能测试右移的实践不够成熟。2.2022-2023年度增加了用户众测和A/B测试，分别占15.9%和4.5%，用户参与和反馈也有助于提升产品竞争力和用户满意度。5828243039420554045无A/B测试用户众测混沌工程赋能生产监控为业务部门提供业务逻辑和系统关系培训赋能生产环境的测试能力4429244801020304050赋能生产环境的测试能力赋能生产监控混沌工程为业务部门提供业务逻辑和系统关系培训2.8%4.5%15.9%13.6%17.0%22.2%23.9%0.0%0.0%0.0%16.6%20.

49、0%33.1%30.3%0%5%10%15%20%25%30%35%无A/B测试用户众测混沌工程赋能生产监控为业务部门提供业务逻辑和系统关系的培训赋能生产环境的测试能力2021-2022年度2022-2023年度42.0%11.8%8.9%15.4%21.9%36.2%25.0%15.0%21.0%34.0%0%5%10%15%20%25%30%35%40%45%向业务需求端左移（如:实例化需求）基于验收标准的BDD基于代码的TDD参与开发架构的质量评估构建质量能力平台赋能研发2021-2022年度2022-2023年度年度报告数据展现和主要发现Basic information数据展现和主要

50、发现数据展现和主要发现数据展现和主要发现第24题 您团队的敏捷回顾会参与人员有哪些?统计说明全员参与敏捷回顾会占53.7%。18.9%在敏捷回顾会中会有开发和测试人员参与；16.8%有需求，产品和开发参与敏捷回顾会。主要发现1.全员参与敏捷回顾会占53.7%，符合敏捷理念中的跨团队合作，强调团队成员之间的紧密协作和持续改进。必要的话可以邀请外部人员参与。2324第22题 您团队的项目，其测试环境部署周期是?统计说明环境部署周期1-3天居多，占44.2%；部署周期3-7天占22.1%；部署周期1小时以内占18.9%；10分钟以内占8.4%。主要发现1.测试环境部署周期与需求变更频率、项目的复杂性

51、、测试团队的技能和经验等综合因素有关。2.现阶段测试环境的自动化部署能力还有很大提升空间，也要更多地考虑云化、微服务化等技术架构。同时，测试环境的部署能力和整个系统的架构具有重要的相关性。图 38：2022-2023年度测试环境部署周期的数据统计804510分钟以内1小时以内37 天13 天1周以上第23题 您团队的敏捷回顾会召开时间点是?统计说明31.6%定期组织召开敏捷回顾会；30.5%在每个迭代结束后召开回顾会；25.3%按需组织。主要发现1.不同组织根据自身需求和团队特点，选择不同的敏捷回顾会召开时间和形式。2.90%以上都会召开敏捷回顾会，

52、已得到认可并执行。5其它时间点不组织按需组织每一个迭代结束后定期组织（每周、每月等）图：-年度敏捷回顾会召开时间的数据统计0.00.20.40.60.81.00.00.20.40.60.81.0图 40：2022-2023年度团队敏捷回顾会参与人员的数据统计2830405060只有产品人员、开发人员其它组合只有需求人员、产品人员、开发人员只有开发人员和测试人员全员(需求、产品、开发、设计、测试、运维)第25题 您团队的敏捷回顾会是如何闭环的?统计说明在敏捷回顾会闭环过程中，明确责任并跟进改进措施的落地占27.4%；只有重点改进措

53、施指定专人负责落地占24.2%；改进措施指定某一角色负责落地实施占16.8%。主要发现1.所有和每项措施都跟进并落地需要综合考虑资源投入和管理成本。应考虑分类分级管理。2.有回顾必有改进项，有改进项必有跟进人，巩固改进成果。图 41：2022-2023年度团队敏捷回顾会闭环情况的数据统计56304050会后不做跟踪其它方式所有改进措施都指定某个角色负责跟进落地只有重点改进措施指定专人负责跟进落地每项改进措施都指定具体责任人负责跟进落地数据展现和主要发现Basic information2526第26题 您所在组织如果开展敏捷转型实践，您认为最制约的困扰或难点是什么?统计说

54、明改善过程中产出无法达到预期占28.4%；敏捷工具不熟悉，转型落地不明确占21.1%；管理层未考虑敏捷转型占16.8%。主要发现1.敏捷效能体现仍不明确，主要的问题是组织对敏捷转型的预期没有对齐。2.敏捷转型实践中，改进方法和技术工具是主要的突破口。图 42：2022-2023年度在敏捷转型实践中最制约难点的分类数据统计第27题 您所在组织对测试架构师或测试教练的岗位是如何设置的?统计说明占48.4%的组织没有专门的测试架构师或测试教练岗位；只有测试架构师岗位的组织占28.4%；只有测试教练岗位的组织占9.5%；同时有测试架构师和教练岗位的组织占13.7%。图 43：2022-2023年度组织

55、对测试架构师或测试教练岗位设置情况的数据统计4620304050都没有只有测试架构师岗位，有1人只有测试架构师岗位，有多人只有测试教练岗位，有1人只有测试教练岗位，有多人既有测试架构师也有测试教练，各1人既有测试架构师也有测试教练，各多人951015202530其它人员能力不够技术能力不成熟管理层未考虑敏捷转型改善过程中产出无法达到预期敏捷工具链不熟悉，转型落地不明确94202530354045不清楚没有测试架构师有兼职测试架构师有专职测试架构师图 44：2021-2022年度组织对测试架构师设置情况的数据统计第28题 您所在的

56、组织中质量体系建设是由：统计说明由独立于测试的团队负责占35.8%；由测试人员兼职承担管理的占28.4%；由测试内部质量小组负责的占27.4%；未建立质量体系团队的占8.4%。主要发现1.质量管理的独立性是共识。是否独立管理取决于组织的规模以及对质量的重视程度。2.随着质量内建的推广和落地，质量小组应该由各团队成员共同承担，而不是仅仅依赖质量团队解决。图 45：2022-2023年度组织中质量体系建设分类情况的数据统计占43.2%的组织没有测试架构师；有兼职测试架构师的组织占22.1%；有专职测试架构师的组织占14.7%。主要发现1.测试架构师或测试教练对整个行业来说都属于新兴人才。2.基于行

57、业经验来看测试经理一般充当测试架构师角色，负责测试团队的发展及整体的规划。3.测试架构师或测试教练并非一定需要专职，只有测试团队规模达到一定程度才有细分的必要。4.测试架构师的职责和能力要求，在组织中所起到的作用和效果，在业内尚不明确，还未有较为成功的范例，对组织人才梯队培养和个人发展意向均缺乏导向。826273405540无质量体系建设团队测试团队内部的质量小组负责由测试团队的人员兼任承担部分质量管理独立于测试部门的质量团队负责年度报告数据展现和主要发现Basic information数据展现和主要发现数据展现和主要发现2728第29题 您所在组织如何度量测试敏捷化的

58、质量？统计说明40%制定组织级测试敏捷化质效指标体系，并通过平台采集指标数据，各团队统一遵循；29.5%制定组织级测试敏捷化质效指标体系，但指标数据采集离散，各团队参照执行；30.5%无组织级测试敏捷化质效指标体系，各团队负责质量度量。主要发现1.敏捷聚焦在项目级的质效提升。组织级测试敏捷化更加考验测试的整体规划能力和建设水平。图 46：2022-2023年度组织度量测试敏捷化质量情况的数据统计第30题 您所在组织的测试质效如何满足监管要求？统计说明72.6%的组织在需求中体现监管要求；18.9%的组织在评审中检查监管要求；8.4%的组织不考虑监管要求。主要发现1.72.6%的组织对监管要求比

59、较重视，在需求阶段介入，开发测试协作避免事后触发监管直查。2.评审时检查监管要求，对评审团队的人员组成需要更全面的考虑才能保证监管要求得到保证，但此阶段发现问题后修正代价会比较大。图 47：2022-2023年度组织如何满足监管要求情况的数据统计28293805540制定组织级测试敏捷化质效指标体系，但指标数据采集离散，各团队参照执行无组织级测试敏捷化质效指标体系，由各个团队负责质量度量制定组织级测试敏捷化质效指标体系，并通过平台采集指标数据，各团队统一遵循84050607080不做要求，事件触发监管要求，引发监管直查只在评审时对监管要求进行检查需求

60、中体现监管要求，开发负责实现，测试统一管理第32题 您所在的组织是否有对需求人员、产品人员、设计人员、测试人员、运维人员的质量评估及考核机制？统计说明24.2%的组织进行评估且与考核挂钩；22.1%的组织有评估但未与考核挂钩；20%的组织只对部分人员评估且不考核挂钩；18.9%的组织无评估无考核。主要发现1.不同组织在质效评估与考核挂钩方面存在差异，可以根据自身情况和文化特点选择适合的考核机制，以激励员工关注质量并持续改进。图 49：2022-2023年度质量评估及考核机制在各类岗位中的应用情况统计第31题 您所在的组织是否会对生产问题（用户反馈的产品缺陷）从需求、产品、设计、开发、测试和运维

61、等方面进行分析和评估，并持续优化改进？统计说明55.8%的组织重视生产问题的解决和持续改进，但各自进行；38.9%的组织运维未参与生产法问题分析解决和持续改进；5.3%的组织未对生产问题进行分析评估和优化。主要发现1.生产问题需要从需求、产品、设计、开发、测试和运维等整个交付链进行分析和评估，但目前大多数组织都独立、局部进行，未形成全局视角。5375300否，都不做是，但只负责需求、产品、设计、开发、测试的分析和优化是，但各自进行图 48：2022-2023年度组织对生产问题从需求到运维分析评估情况的数据统计510152025无评估无考核都进行评估但

62、未与考核挂钩都进行评估且与考核挂钩部分人员进行评估但未与考核挂钩部分人员进行评估且与考核挂钩数据展现和主要发现数据展现和主要发现Basic information2930年度报告数据展现和主要发现Basic information第33题 您所在的组织是否有设置了以需求为导向的开发测试运维一体化管理（DevOps）的PMO和QA？统计说明47.4%的组织有统一的PMO和QA进行管理；29.5%的组织没有该职位；23.2%的组织没有统一的PMO和QA。主要发现1.实施DevOps是一个跨团队，跨工具的项目，因此更需要有专职PMO负责。2.QA是独立于DevOps之外的管理职能，可以从质量的角度关

63、注DevOps的实施效果。但对DevOps项目而言不是必须。图 50：2022-2023年度DevOps的PMO和QA管理在组织中的应用情况统计第34题 您所在组织常用的度量测试敏捷化指标有哪些？统计说明根据收集的指标按照管理、技术、质量和效率四个维度，设计四个象限进行分类统计，结果如下：主要发现1.测试敏捷化度量指标可以基于现有的指标，增加团队协作和沟通、风险管理等方面的考核内容。表格 1：2022-2023年度组织常用的度量测试敏捷化指标的分类统计22284501020304050组织没有统一的PMO 和QA，但针对DevOps 有专人管理没有设置类似管理岗位或人员是，组织有统一的PMO

64、和QA 进行管理分类管理技术效率 需求测试周期 需求吞吐量 需求交付周期 迭代速率 迭代周期 交付周期 发布部署频率 团队速率 需求与缺陷的响应时长 测试用例需求覆盖率 测试用例检查百分比 测试用例自动化率 测试覆盖率 自动化测试执行率占比 自动化测试覆盖率 单元测试覆盖率 接口测试覆盖率 UI自动化通过率 UT通过数 缺陷探测率质量 缺陷数量 缺陷分布 缺陷逃逸率 缺陷修复率 缺陷修复时间 缺陷平均修复周期 缺陷平均验证时长 缺陷循环事件 高危缺陷占比 需求受理满意度 客户需求满意度 需求采纳率 发布成功率 流水线失败率 静态扫描通过率 代码覆盖率 行覆盖年度报告数据展现和主要发现Basic

65、 information数据展现和主要发现数据展现和主要发现3132案例Case（一）系统运维复杂，稳定性保障遇挑战中国联通顺应移动互联网、电子商务、5G时代潮流，从系统建设向平台建设转变，着力打造统一、集约化、云化、微服务化的IT互联网生态系统，开启业务支撑系统的数字化转型工作。cBSS系统作为平台建设转变的重点，现已成为中国联通互联网化运营的核心承载平台，承担着联通全国31省B域业务，日均订单量千万笔以上。中国联通在cBSS架构演进过程中，综合稳定性、性能、扩展能力、自主能力提升、成本等诸多因素考虑，整体采用分布式技术解决方案，选用分布式体系架构及产品来支撑业务系统，实现降低成本、增强扩展

66、能力、提高性能、支撑创新。由于支撑移动业务、固定电话、IPTV、宽带、国际漫游等多个业务品类，平台架构复杂，服务链路长，故障定位难度大，解决时限难以保证，cBSS系统运维工作存在较大的管理难度和运行风险，平台稳定保障面临较大挑战。（二）质量右移，建立四重保障机制质量右移建四重保障实现端到端价值赋能在集团质量工作会议指示下，2014年起以接收测试为开端，逐步开启质量右移探索工作。以四重保障机制模型为核心，构建质量管理体系标准，建设稳定性测试平台，形成各项质量保障能力。第一重保障是从UAT测试理念出发，进行用户级接收测试。针对已知的管理和技术风险，结合生产运营，聚焦一线稳定，在传统研发测试过程完成

67、单元测试、集成测试、联调测试后，以运营为主导开展质量管控右移工程，将UAT测试理念落地，在上线前模拟用户开展接收测试与生产当日的验证。聚焦运营阶段的核心流程、要点工作、专题项目，纳管系统运行期间共性问题，形成整体验证列表。以总部+省分两级联动方式开展工作，通过总部下发任务，省分组织人员资源，对列表进行验证，对结果反馈进行打标，将异常项反馈至研发测试，确认是否已经发现，如未测试出问题，进一步协同研发人员、需求人员进行解决或开展异常服务回退，减少生产bug遗漏风险。通过此类测试右移真正做到了由用户开展测试，提高用户参与程度，也落实了全程软件测试思想。第二重保障是以自动化测试为基础，结合运营需要，开

68、展自动化主动探活业务服务。自动化巡检方面，以生产运营实际需要出发，综合自动化测试实践经验，对资料查询、融合受理等关键业务与核心服务进行聚类梳理，通过UI+接口两方面开展；UI巡检方面，以开源能力为基础，通过模拟人工操作方式，在WEB端进行业务办理，在营业开始前、业务受理高峰前扫雷。第三重保障是由外到内梳理各层级指标，以接口巡检贯穿全层级，提升架构问题发现准确度。UI巡检模拟人工页面操作最为真实，但是也存在业务流程长，时间粒度不够精细的问题。基于此情况，研发了接口级巡检，以链路角度出发，结合调用频率，完成cBSS系统关键服务能力API清单整理，基于接口测试技术，从运营环节拿到对应参数，形成定时巡

69、检服务用例，实现秒级服务状态检查，提升发现频率的同时，实现了更加精准的异常点判断。在自动化巡检的运行过程中，按照省域方式，进行区域化探测，期间如发现问题卡点堵点，自动评估当前问题影响范围，并将告警推送至运维侧开展排查，在处理中提供恢复验证。基于安全风险防控与大量并发支撑角度考虑，cBSS系统跨越了F5硬负载、lb软负载、动态安全防护等多个层级。由于曾发生部分层级的变更或配置调整造成业务端到端贯通，引发系统无法使用的情况。通过模拟业务受理链路，由外到内逐层进行服务扫描，经过专家评估研判，完成各层指标级服务梳理，结合生产运营实际数据，复用接口自动化巡检能力，由外到内逐层级开展主动调用，形成架构级全

70、层级巡检。在日常使用过程中，如各层级应答正常，但个别层级响应超过2s，则认定该层异常，排查问题时从本层与上下两层进行排查，实现问题快速定位。第四重保障是聚焦非功能性测试，评估系统承载能力，开展压力测试。作为中国联通的最核心平台，cBSS在向全国提供服务的同时，也向联通客服、联通APP、联通公众、联通政企等多个兄弟系统提供基础服务能力，承载性能与平台服务容量显得异常重要。为评估cBSS系统可承载容量与平台瓶颈，选取了系统新增服务、系统高频调用服务、历史故障或问题接口三类服务展开压测。对系统新增服务，在版本前进行压力测试，对照预期业务量进行评估，如未达到指定要求，开展相关优化直至符合标准。对高频告

71、警服务、历史故障接口服务，在版本后展开性能评估，通过调用链业务量分析，评估相关服务最大并发量，按照3、5、10倍冗余准备容器化压力机，构建预期压力资源池，按照单服务实例、多实例组合场景加压，评估服务性能。对性能测试发现的问题做到当日发现，当日复盘，由运维人员、研发人员、架构人员、DBA等共同进行问题评估，确认性能问题根因，及时制定整改方案，如数据库并发及缓存优化，服务内部逻辑处理优化，慢sql语句优化等多个维度。同时明确整改时间计划，待优化后立即开展复测，直至调整服务性能至最优状态。中国联通软件研究院-李建斌（二）自动化脚本设计测试脚本的编写设计主要采用了默认对象录制模式、OCR图像识别录制模

72、式。Web自动化采用了AI录制模式。脚本整体框架采用混合模式，灵活的支持模块化测试框架和数据驱动框架。通过把一个业务或者一个页面封装成为一个Page对象，在这个Page对象里存放有所有这个Page所属的页面对象、元素操作等。并组成一个个的测试类方法，供测试执行用例层调用。结合关键字驱动的方式封装公共的操作类，类似全局函数在整个自动化测试项目中使用。图3：自动化测试脚本样例（三）自动化测试系统部署采用三层部署结构，文件服务器进行脚本管理支持更新、发布，测试管理平台应用服务器进行执行机器的监控和调度。配置文件、测试数据等通过数据库服务器进行管理。图4：自动化测试系统部署架构商购技术平台，贴合自身现

73、状改造（一）平台选型与系统架构基于自身业务系统进行严格选型，引入自动化测试平台，并在其基础上进行改造和优化。图1为该平台测试标准流程：提测-计划-需求分析-测试设计-测试执行-测试报告-评审。支持内部裁剪和定制化修改，能做到较好的测试全链路管理和应用。图1：自动化测试平台基础的测试标准流程 该平台系统架构如图2所示，系统自下而上分为：运行环境、数据层、调度管理层、应用系统层、用户层，其中多层结构将调度层和应用层结合，以数据层为驱动的方式实现对用户层展现。图2：自动化测试平台分层架构行业大发展，测试遇瓶颈随着金融科技的快速发展，保险资管行业迎来了一个快速成长阶段，为支撑自身的发展，无论是投资端还

74、是产品端，都加大了软件系统建设的投入。与此同时在系统建设过程中也遇到了很多困扰。IT系统的交付时效和质量要求不断提升，软件测试工作已逐步成为了各类项目实施过程中所面临的瓶颈。定目标，明方向百年保险资管作为一家保险资管企业，根据自身实际情况，经过前期调研分析，并结合自身实际情况，确定引入自动化测试工具，主要实现如下三个目标：目标一是满足监管要求，为数字化转型打好基础。通过引入自动化测试工具改变没有测试管理工具的现状，对于项目中的测试工作做到全生命周期管理，满足监管对于测试质量管理的要求。对于监管数字化转型意见中敏捷转型的明确要求，自动化测试工具将为推进DevOps建设提供质量保障，为后续整体数字

75、化转型打好基础。目标二是缓解测试压力，提高项目交付效率。通过系统自动化测试替代手工验证，以及实现多进程并行运转，缓解测试人力瓶颈。在减轻测试消耗的前提下，缩短项目交付周期，满足业务对于项目时效的要求。目标三是提升测试质量，降低系统应用风险。通过增加测试覆盖面，在测试阶段尽可能全面地发现问题、解决问题，保障系统应用投产后的质量；通过实际应用中的不断打磨和知识积累，形成公司级测试案例库，逐步提升自动化测试质量。案例案例3334中国联通质量管理右移已带来初步成效，cBSS系统2022年全年无故障发生。后续将在“体系+平台”的思路下，通过贯彻全程软件测试理念，以测试端到端赋能业务价值链的视野，将测试的

76、质量管理使命与生产运营的安全稳定管理使命相结合，持续探索各项稳定性保障能力，让测试发挥出更大价值，提供稳定高效的服务，做好通信领域的国家队与排头兵，支撑集团数字化转型工作展开。以自动化增效测试赋能资管数字化转型角色视角权限序号百年保险资产管理有限责任公司-薛世杰、何浏、刘景瑞表一 投资交易系统表二 反洗钱系统表三 直销系统案例案例3536角色视角权限序号再次，对测试任务进行持续优化。自动化测试中最常见的问题是随着被测系统的版本变更，部分系统界面进行了调整，原有的测试脚本无法正确地进行识别，测试脚本也需要同步进行修改。此外，实际测试中个别特殊业务场景不在原本的设计中，需要进行相应的问题修复。如证

77、券卖出案例因为零股以及每个品种交易规则的不同，无法使用统一的逻辑，为此也要对程序进行修改，实现无需人工干预的情况下顺利下达委托。类似问题无法一劳永逸的避免，在实际工作中，测试团队形成了对此类问题的快速响应机制，通过程序架构的灵活性及自动化测试工具的可配置性，实现自动化测试程序的持续优化，从而将影响降到了可承受的范围内。最后，自动化测试不是“银弹”。虽然自动化测试案例已经做到了较高的覆盖率，但从成本与实际的效果来考量，目前的最优解还是人工与自动化程序相结合的方式。实际测试过程中的沟通协调很难被自动化测试所替代，依然少不了人工介入。面对不同的系统，现阶段依然会使用不同的测试方案，但将自动化测试逐步

78、渗透到测试实战中是最主要的方向。投产显价值，纳管见真功自动化测试平台初步建成以来，已完成四个系统的自动化用例建设工作，系统满足整体框架通用性强、可维护性强、可扩展性强三点设计原则。图5：自动化测试平台界面投产后自动化测试平台正逐步发挥出的它的价值下：首先，实现主要系统90%以上测试案例覆盖。目前自动化测试已基本覆盖各被测系统中的主要功能模块。此次项目涉及的四个主要业务系统（投资交易系统、TA、直销、反洗钱）已实现90%以上的自动化测试案例覆盖。对于特殊情况，以实际测试效率为主要考量，确实不适合使用自动化测试脚本的，暂时保留人工测试的方式。下表为各个系统已经实现自动化测试的主要案例清单。表四 T

79、A系统其次，在基础的测试功能上实现一部分复杂流程的自动化。在实际系统测试中存在很多与外部机构协同的测试工作，为了保证测试的自动化运行，除基础的操作模拟外，还通过一些复杂逻辑使得测试任务拥有一定的“柔性”，从而更好的实现对于外部系统的适应。下图为投资交易系统证券买入案例的基本流程图，为了避免测试环境由于券商数据不完整带来的影响，实际测试任务通过基础脚本外加入了一部分复杂的逻辑来实现，提高了整体测试的效率。业务分类 涉及主要模块 自动化测试内容 交易所联测 交易所指令 证券交易 港股通指令 港股通交易 模拟生成交易进行常规下单及对敲下单 覆盖主板、新三板、科创板、港股通股票、国债、企债、公司债、可

80、转债、开放式基金、质押式回购代码 覆盖买入、卖出、转股、回售、提交质押、转回质押、融资回购、融券回购 非交易所业务 开放式基金指令 开放式基金确认 银行间指令 银行间交易 资金管理 证券管理 使用固定代码及产品覆盖涉及业务 清算 日操作流程控制 使用 2 种模式覆盖清算业务 1、常规模式，只执行归档和初始化，强制及后续操作执已完成，满足平时初始化需求 2、仿真模式，使用清算文件进行模拟生成清算，满足升级测试需求 涉及主要模块 自动化测试内容 风险评级流程 审批驳回、复核受益人、初评/系统得分等字段校验。客户信息查询 股东信息、界面上各字段查询校验、系统枚举值字典校验。名单管理 页面响应时长校验

81、、出生日期等字段校验；线下客户管理 客户信息与线下客户管理页面表格内容对比校验（控股股东、受益所有人等）、客户导出数据内容校验（sheet 页名称、字段内容等）、产品、个人、机构字典字段校验、产品、个人、机构新增客户流程和页面内容校验。涉及主要模块 自动化建设内容 账户类 机构户开户、机构开户复核、机构开户复核放弃、机构开户驳回修改、机构开户驳回修改驳回放弃、机构客户资料修改复核、机构客户资料修改驳回修改、机构客户资料修改复核放弃、机构客户资料修改驳回修改驳回放弃、机构开户_界面字段校验、产品开户、产品开户复核、产品开户复核放弃、产品开户驳回修改、产品开户驳回修改驳回放弃、产品客户资料修改复核

82、、产品客户资料修改驳回修改、产品客户资料修改复核放弃、产品客户资料修改驳回修改驳回放弃、产品开户_界面字段校验、个人开户。交易类 基金申购复核通过、基金申购复核驳回提交修改、基金申购复核驳回放弃、基金申购驳回修改放弃、基金赎回复核通过、基金赎回复核驳回提交修改、基金赎回复核驳回放弃、基金赎回驳回修改放弃、基金认购复核通过、基金认购复核驳回放弃、基金认购复核驳回提交修改、基金认购驳回修改放弃、基金转换复核通过、基金转换驳回修改放弃、基金转换复核驳回放弃、基金转换复核驳回提交修改、资金存入复核。涉及主要模块 自动化测试内容 日操作流程 日初始化、申请数据导入、基金行情输入、复核登录、基金行情复核、

83、基金行情导出、处理前备份、账户预处理、交易预处理、批处理、批后统计、处理后备份、数据导出。案例案例3738 软件越复杂，质量越重要近年来，随着金融科技和业务的加速融合，人工智能、区块链、大数据、云计算等新兴技术承担着重要角色，系统代码普遍达到百万行，有些系统甚至可达千万行，金融软件的复杂度呈现越来越高的态势。与此同时，金融软件质量也面临着更严峻地挑战。证券公司投资者保护状况评价报告 统计数据显示：证券公司因交易系统稳定性问题被投诉次数从2019年的486次，上升到2020年1103次，2021年944次。根据威胁情报公司Flashpoint的数据，在全球范围内，金融服务行业组织2022年遭受的

84、已知软件漏洞攻击数量位居第二，仅次于政府组织。以某券商为例，由于金融交易领域的特殊性，对软件缺陷保持零容忍态度，软件故障除了会造成经济影响外，还会导致客户流失、品牌受损等长期负面影响。近年来，该券商信息系统建设任务明显增加，上线变更操作较为频繁，在敏捷开发模式下，测试是一个频繁地活动。如何在保障测试质量的前提下，提高测试效率，是技术团队面临的一个重要且迫切地挑战。全面建设，以质量门禁解决方案赋能质效提升 质量门禁解决方案采用一系列考核指标进行科学把控，将测试工具对接DevOps和集成开发环境等平台，实现在软件开发过程及交付验收中进行质量控制，打造了一套智能化、自动化、精准化的质量保障体系，可以

85、有效降低发布上线后的软件可靠性风险。以模糊对抗复杂以质量平衡效率序号上海安般信息科技有限公司-王宏才 李雯行，并可以结合待测系统的分级指标实现灵活地调整和部署。智能模糊测试：挖掘未知/深层缺陷，充分测试智能模糊测试系统可以在短时间内生成并执行成千上万个测试用例作为入口函数/接口的输入，全面覆盖系统中可执行的代码路径，以检测软件在各种意外情况下的表现是否正常。当软件崩溃时，系统能够快速找到程序内部各个代码分支中存在的漏洞，复现缺陷，精准定位至代码行，同时提供专业修复意见。1)支持非独占多并发，目标程序可同时被其他程序调用通过插桩和整体交互流程的优化，增加唯一可追踪ID，实现非独占多并发的测试，提

86、高测试资源利用率。2)支持多参数变异，多引擎融合，提升模糊测试能力至少三个引擎同时工作，可集合各引擎的探索能力，更高效、更全面地挖掘漏洞。3)支持智能收敛，自动判断充分性，提升资源利用率根据实时的指标阈值（运行时间、最大模糊测试次数、总周期数、最小种子集等），通过贝叶斯超参优化算法计算权重，判断测试是否充分，智能化终止测试，减少人工判断产生的偏差和计算资源的浪费。(一)建指标，立质量标尺测试框架的普遍特点是测试方法零散，质量门禁解决方案引入CMMI和TMMi等行业标准，结合内外部实践，制定覆盖动态、静态的考核指标，方便对软件质量进行量化评估。(二)分等级，配测试资源证券软件种类繁多且复杂，需对

87、各类软件的质量保障等级进行划分，以更有效地分配测试资源。质量门禁解决方案根据证券行业系统特点，制定ABC三级参考评估标准。针对不同等级的系统，启用相应级别的指标集，选用动、静态测试手段完成测试，减少测试资源的浪费。(三)上手段，融前沿技术质量门禁解决方案集合了一系列测试手段，如智能模糊测试、静态代码安全检测、软件成分分析系统，全方位挖掘软件缺陷，有效支撑质量门禁指标的高质量执静态代码安全检测(SAST)：预测、评估、提升软件质量衡量软件的规范性、复杂性、可维护性的指标包括可执行代码注释率、圈复杂度、方法复杂度、程序容量等，这些也是软件安全体系化建设必要的指标。通过白盒静态分析方法，可以实现源代

88、码编码规则检测、运行时缺陷检测、安全漏洞检测、度量统计、克隆检测、逆向架构图自动生成等功能，从源头提升软件质量。软件成分分析（SCA）：解决开源治理中的安全和合规问题开源软件凭借源代码开放、产品方案丰富、初期引入成本低等特点，在金融机构中应用已经形成规模。虽然开源软件在推动科技创新和数字化转型方面发挥着积极作用，但也面临诸多风险。通过对软件源代码成分分析得到软件物料清单信息，同时，对其中引入的开源组件漏洞风险及合规风险进行扫描分析，提高软件供应链的透明度。案例案例3940 (四)松耦合，推主动服务质量门禁解决方案提供插件化、组件式的技术形态，通过将其集成于DevOps开发流程中的各个阶段，提升

89、对软件质量控制能力。软件开发人员可以在DevOps工具中配置postbuild动作，调用系统模块，自动完成测试分析工作，测试分析完成后，发现的问题可登录web页面或者推送至管理工具（如：禅道、Jira）和指定的邮箱进行查看。(五)设门禁，查问题缺陷开发测试运维一体化如同持续的水流，在开发流程各环节设立质量门禁，有利于及时发现问题，阻止低质量软件进入下一个环节，同时可以合理利用不同阶段的项目资源，避免造成流程阻塞。(1)单元门禁单元测试是软件开发中质量把控的基石，如果在单元测试时不进行充分的安全可靠性测试，会导致发布时出现问题，集成之后这些问题的发现、定位、修复都将耗费大量精力和返工成本。质量门

90、禁解决方案通过智能模糊测试工具在持续开发中对代码进行充分的动态测试，确保代码新增/修改的部分不会引入新的缺陷。解决方案提供IDE插件，安装至IDEA后，开发人员可便捷发起测试，在同一界面获取测试报告。角色视角权限序号(2)增效：提升测试人效，帮助快速修复bug-实施期间，发现bug的复现率为100%，且可定位至代码行，开发人员从接到 bug 工单到完成修复，平均用时约1.5h-经统计，测试平均覆盖率从8%-20%，提升至3-4倍，达到高覆盖率要求，软件测试充分性大大提升(3)预防：发现深层/未知缺陷，提前应对重要威胁(4)验证：捕获即展示错误现场，验证问题影响程度“质量”与“效率”双赢，夯实竞

91、争基础实施质量门禁解决方案之后，该券商测试团队从需求阶段就开始介入，加强与开发、产品等角色的配合，使测试工作有条不紊地进行，从而尽可能多地发现存在的漏洞和不足，提高交付质量，保障最终交付的产品价值，使其风险可控，质量更高。此外，实施过程中所采用的技术，对分布式软件、云化软件、嵌入式软件等均具备测试能力，可灵活适用于多种工作场景。敏捷开发并不只是简单地比拼速度，而是一个强调敏捷与质量平衡的“质量游戏”，缺乏相应质量管理方法的情况下盲目强调敏捷，最终影响的是项目成效。事实证明，在敏捷开发的同时进行质量管理，达到“质量”与“效率”的双赢，是让软件保持竞争力的关键。(2)集成门禁集成测试阶段一般不提供

92、源代码，关注的重点是接口层级测试，交付物为Jar/War包、接口文档。质量门禁解决方案使用智能模糊测试工具，针对Java程序的API接口，在持续集成中对代码进行充分的动态测试，确保上线前不会引入新的缺陷。(3)验收门禁验收测试无疑是发布上线前的重要屏障，无论是自研软件、还是第三方交付软件，除基本的功能逻辑验证、性能验证之外，对质量的把控也至关重要。保质降本增效，多维提升成效显著 通过实施质量门禁解决方案，该券商构建了全生命周期的缺陷/漏洞管理体系。使用白盒、黑盒、灰盒等多种技术手段，实现漏洞通报、修复的闭环管理，确保上线前已知风险全面收敛，同时接入第三方组件和开源组件的安全检测，实现多场景、多

93、环节、多维度的质量保障。(1)降本：提升软件可靠性，减少故障带来的损失 -该券商软件缺陷的修复成本降低20%-30%-经评估，预计减少80%以上的软件缺陷导致的问题，高危风险发生概率降低 95%以上案例案例4142 随着互联网金融的快速发展，云计算、大数据等新技术的广泛应用，银行科技迎来了前所未有的机遇和挑战，也给测试组织在质量管理、风险控制、效率提升等方面提出了更高的要求。光大银行科技测试一直都在探索通过管控测试实施中最关键的“人力资源”，强化测试部门对质量、外包、成本等风险的控制能力。同时借鉴“云计算”“机器学习”等先进的理论和技术，实现对资源进行统筹共享、精准投放与灵活调度，提升测试部门

94、整体效能，解决资源限制与多维风险之间的矛盾，实现测试模式向管理科学化、运行智能化、经验知识化方向转型，增强银行科技整体竞争力。一、迎难而上，敢于直面问题与挑战 1.“有限资源”与“多维风险”的冲突带来严峻挑战 快速响应业务发展，亦要兼顾质量风险控制在金融产品创新多、变化快常态化市场环境下，测试部门既要在保证投产效率的同时，兼顾应对质量风险，以增强银行业务产品的市场竞争力和软件产品的生命力。不稳定的外包引发质量的波动商业银行软件测试工作多以人力外包为主，可外包资源稳定性差，年流动率超过40%，人员资质和技能能力参差不齐，投产质量很难保障，风险不断提高。资源需求爆炸性增长，既带来机遇也带来风险银行

95、业务规模的快速增长，信息系统体量和复杂度不断增加，对测试资源需求的规模大幅增长，给测试部门提供了高速发展的契机，也带来了管理和成本的风险。人力资源配置的被动性往往造成隐性成本增加系统和人力资源绑定在一起，组织为了应对系统需求可能的峰值，往往会过度以测试技能共享池消解有限资源与多维风险的冲突权限号中国光大银行股份有限公司-胡小丽而无需多少管理工作或服务供应商的干预。“机器学习”是一门多领域交叉学科，涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善自身的性能。它是人工智能的核心，是主要

96、使用归纳、综合而不是演绎。“稳定匹配理论”是戴维盖尔(David Gale)和劳埃德沙普利(Lloyd Shapley)在1962年提出的稳定匹配理论。他们最先提出和介绍了双边匹配模型，并且提供了一个合适的解决方案，该概念被称为“稳定”(stability)。他们还通过一个简单的迭代算法递延接受算法，证明了稳定匹配的存在。文章中提到的经典双边匹配模型涉及两个不相交集的个体，每个个体可以和另一边的至多一个个体匹配，因此该模型也被称为“严格偏好的一对一匹配”。2.运用“专业方法”形成方案光大银行的测试“资源池”的研究运用关键问题筛选、结构化分析等专业方法，明确了要解决的“资源限制与多维风险矛盾”和

97、“管理局限性”两大关键问题，并将问题和研究方法进行匹配，形成最终的解决方案，即基于“多维风险”考量的“测试技能共享池”。配置资源，带来测试人员工作饱和度的不均衡甚至较大的闲置率。因为测试资源有限，我们不可能为了应对上述的质量、外包、成本风险而无限制的增加，所以，如何通过科学的管理手段，解决资源限制与资源需求之间的矛盾，最大化满足银行对风险管控、投产效率、质量、成本的要求，是测试部门面临的严峻挑战。2.主动转型，力求破解管理局限性问题面对国际金融危机和国内经济转型的挑战，银行测试管理的主动转型升级也迫在眉睫。光大银行信息科技测试能力建设，经历了由成长到成熟，确立了测试工作在信息科技建设周期的立足

98、点和担当的角色。随着我行新一期科技战略规划的落地，测试管理也加快转型优化期的创新步伐，积极探索和布局“智慧测试”战略，把全面提升测试部门的统筹管理能力、风险缓释能力与组织效能作为测试管理的目标方向，力求破解传统测试管理模式中，测试组织对大型规模资源管控难度大、资源与系统紧耦合导致工作周期性的不饱和、对外包依赖大、人员技能能力单一、可调度性差等衍生性问题。二、汲取经验，建立解决问题的新思路1.借鉴“专业理论”支撑研究自2015年起，光大银行既着眼测试管理的共性资源问题，开展测试“资源池”管理的研究与实践，并以“人力资源池”“云计算”“机器学习”“稳定匹配算法”等作为理论和实践的支撑。“人力资源池

99、”是一个“蓄水池”，将具有类似技能的人聚合在一起，建立起跨越若干组织的人力资源调度中心，根据不同的项目需要，统一管理资源入池出池，组织人才招聘、培养、绩效管理、工时管理和员工关系维护等，同时根据战略发展目标和资源池的规划，制定资源个人发展计划，推动人才的培养，从而可以提升资源池的整体能力乃至公司的能力。“云计算”是一种可以对共享可配置计算资源进行方便、按需网络访问的模型。这些计算资源包括网络、服务器、存储器、应用程序和服务，可以被快速配置和释放，1）关键问题一：资源限制与多维风险间的矛盾“外包风险”难控制，使用“人力资源池理论”中的“选育用管评”框架控制外包风险；“质量风险”难度量，基于历史数

100、据，使用“机器学习”算法，精准度量质量风险;“成本风险”难平衡，研究“稳定匹配”算法，通过合理的调度平衡成本与需求的关系。2）关键问题二：管理的局限性问题“云计算”对资源池化管理的先进性和可行性已被业界广泛认可，其提升资源使用率与共享度的目标与光大银行的管理目标是一致。光大银行借用“云计算”虚拟化管理思想，将实体的测试“人力资源”虚拟化成“技能资源”进行管理，每个技能可以并行承载不同任务，通过消除资源的物理边界和限制，提升资源的利用率和可调度性，只要资源整体数量满足需求，就能通过技能布局调整，打破各系统间的波峰和波谷，为系统提供有效的供给。这样既细化了管理颗粒度，又在一定程度上规避了人的主观因

101、素影响。3.使用“专业方式”完善模型为了保证“资源池”模型可以达到预期效果，光大银行在模型设计过程中采用了思维导图、头脑风暴、目标分解的等方式，将各项策略方法从三个角度进行集成，最终形成了“基于多维风险考量的测试技能共享池”模型的三个子模型：资源布控管理体系、基于风险的精准测试模型、资源调度模型，促进资源池模型方案的完善和可实施性。图2：模型完善-结合目标导向进行方案推演案例案例4344三、多措并举，测试资源池管理模型基于“多维风险”考量的“测试技能共享池”模型，简称“资源池”模型或“RTSS”模型。其中，基于“多维风险”指的是从外包风险控制、质量风险控制、成本风险控制的角度，考量和建立测试运

102、转机制；“测试技能共享池”指的是使用云计算的管理思想，把实体（人力）资源虚拟成技能资源，建立一人多能的池化共享管理模式。该模型有三个核心子模型，分别是在资源的供给层的“资源布控管理体系”，在需求层的“精准测试模型”，在调度层的“资源调度模型”。图3：测试“资源池”模型总览 子模型1：资源布控管理体系，缓释外包风险资源布控管理体系，是资源池的核心基础，使用虚拟化的方式将一个“实体资源”虚拟成多个“技能资源”，消除资源的物理限制，只要资源整体人数符合需求，就能通过技能布局调整，打破各系统之间的波峰和波谷，为系统提供有效的供给。图4：资源布控管理体系角色视角权限号图5：精准测试模型该模型位于资源的需

103、求层，从质量风险控制角度，使用科学的计量手段平衡质量风险与测试成本、测试覆盖之间的关系，把传统成本控制的立足点从过程管控深化到风险核算，围绕投产风险出现的概率、预期影响程度、风险依赖因子、期望的质量结果等9大风险因子，在大量历史数据的基础上，结合风险因子众多且难以精准量化的特点，引入机器学习算法预测需求的测试风险成本，控制资源的投放，并将预测结果应用到测试风险矩阵，获得需求最终的测试策略，包括最佳测试环节、测试方法与测试覆盖范围。通过对各个系统和需求进行风险分析与建模，既能够降低因测试人员能力参差不齐影响测试质量的风险，又能够将有限的测试资源投入到高风险的测试对象上。子模型3：资源调度模型，控

104、制成本风险资源调度模型，是资源池的大脑，是在满足需求对技能和时间要求的前提下，最大限度的平衡资源的工作饱和度、成本等要求，实现资源与需求的最佳匹配。该模型位于资源供给层，从外包风险控制角度，充分调研了“人力资源”理论的“选、育、用、管、评”框架，将其应用在“资源池”管理领域，保障资源技能的可用性和承载技能池子的稳定，并结合资源池特点，探索基于资源技能的:“结构化面试法”。挖潜能力强、具有多技能的测试资源；“自循环培训体系”。不借助外力，通过激励机制引导高级技能资源主动培养新人，新入场资源主动资源技能提升，化外驱为内驱，推动资源池化能力的螺旋式上升，建立起一人多能的交叉互备机制；“全周期的量化考

105、评体系”。基于技能的演变，积淀测试资源的动态、关键性能和流程操作数据，为管理决策提供更为精确的描述和科学的控制手段。同时通过量化考核指标，客观、真实地描述测试人员的服务档案，更好激发资源的竞争意识，促进工作的责任感和紧迫感；“技能池管理和监控”。实施监控资源技能布局、运转、供给和应急能力，分析过程中可能存在的独占行为或不合理使用情况，提醒资源使用人员改正，提高了资源的健壮度，保证“资源池”的长效运行；“资源规模规划及调整”。从资源池、系统两个层面规划和预测资源需求，结合供给能力的智能化分析，建立起事前资源数量先调整、资源技能先储备，事中技能布局快速调配的响应机制。只要资源整体人数符合整体需求，

106、就能通过技能布局调整，打破各系统之间的波峰和波谷，弥补资源限制问题，为系统提供有效资源的供给。子模型2：精准测试模型，度量质量风险精准测试模型，是资源池的亮点，使用风险核算的方式控制测试成本投放，精准测试的范围。简单来说，就是在成本有限的情况下把好钢要放在刀刃上。图6：资源调度模型该模型位于资源调度层，从成本风险控制角度，通过有效地调度，最大程度规避资源使用不饱和的问题。基于“稳定匹配理论”建立智能化资源调度中心，把调度问题分解成需求特性和资源特性的匹配问题。在决策匹配时，将测试需求对资源技能要求和工作量要求作为强制约束条件，把资源的饱和度、技能能力等作为排序、参考条件进行匹配，在保证满足需求

107、资源技能前提下，平衡资源的工作量和能力。该模型在调度思路上突出了资源特征和需求特征的双边匹配，可以依据任务类型的特点自定义排序条件规则，调整资源的任务并行度、缓冲设置和调度的颗粒度等，为选择留有一定自由度，以人性化的方式实现需求和资源的最佳匹配，保证测试资源被均衡使用。该模型以人性化的实现需求和资源的最佳匹配，具有五大特点：（1）需求与资源双边匹配，既满足需求所需，亦考虑资源工作量的平衡和成本 等因素；（2）可依据任务类型定义排序规则；（3）任务并行度可调整；（4）可为测试经理缓冲设置；（5）调度颗粒度可精细到天。案例案例4546“资源池”模型采用三位一体的资源共享管理模式，在规划层面解决了光

108、大测试管理局限性问题，还规划了未来测试管理基于多维风险考量的发展模式，在运行层面展示了多模式需求实施过程和多种任务类型的调度方法，在支撑层面覆盖测试资源和资产管理的全部内容，形成完整的管理闭环。图7：测试“资源池”模型总结 四、扎实落地，提质增效实现精细化管理“资源池”模型在光大银行的实施落地是从体系制度建设、模型落地、平台建设、文化建设四个方面展开。“资源池”模型已渗透和贯穿到整个测试项目实施过程。在测试需求阶段，使用精准测试模型确认测试成本和范围；在资源任务分配阶段，使用资源调度模型匹配资源，并通资源配置与释放过程，动态衔接资源的规划与管理过程，配合有针对性的招聘、培训和考评来保障技能的可

109、用性，实现资源与需求的供需平衡。图8：测试“资源池”运转概览角色视角权限号据统计，自2016年开始实施“资源池”起，光大银行测试部门年人均产能提升超过40%，年节约测试成本超过3900万，为科技创造价值；需求所需测试时间下降超过24.5%，且投产质量持续提升，高效地支撑了业务的快速发展；组织弹性增强3.5倍，响应速度持续提升。不仅如此，“资源池”还进一步提升了银行的风险缓释能力，降低对资源个人能力的依赖，增强了应对突发事件的能力，促进测试部门的管理能力全面提升，实现管理的标准化、流程的电子化、工作的可视化，提升了组织协调能力、量化管理水平和对资源的可控性。五、对标先进，探索更加精准的测试管理模

110、式光大银行测试“资源池”的建立，探索出一套完整的银行测试资源全生命周期的管理模型，形成了支撑具体落地的组织架构、实施流程和管理平台，使得测试风险得到有效控制，测试部门的效能大幅度提升，降低资源需求波峰波谷带来的被动影响。但由于现阶段资源特征数据积累的局限性，资源共享技能的布局和调整过程，尚不能完全忽略个人主观因素，暂未采用全面的系统化操作。未来将通过数据积累和大数据技术精准描述资源画像，推进资源管理的全面自动化和智能化。同时，光大银行还会进一步优化资源合作伙伴的布局，通过时间差、地域差，将测试任务排期进一步延展，从而最大限度地提高任务的承载量和成本控制，满足更快的测试交付和质量控制的需求，对标

111、国际测试标准，参考建立银行业测试的实践标准，抓住机遇、顺势而为，推动整个银行业测试的全面进步。所有部署都离不开“工作平台化”的全面规划和支撑，通过“光大银行统一测试管理平台”的建设实现对需求、任务、资源、环境、版本、数据等精细化管理，该平台主要功能包括：图9：统一测试管理平台（UTMS）整体架构概览 从整体层面统一测试的入口、操作和管理过程，让不同角色的人可以更好地了解项目状态，提高沟通效率；在接口层面打破测试信息孤岛，打通与所有行内管理系统的信息交互，降低跨系统协助测试难度，加快测试排期；在测试实施层面落地“资源池”三个核心子模型，实现对需求分级分类分流程管控，控制测试成本投放精准测试的范围

112、，解绑资源与系统的紧耦合关系，智能创建任务和匹配合理资源，保证测试资源的技能共享和工作排期；在资源管理层面实现对测试人员进行全生命周期（面试、入场、培训、能力调整、级别调整和离场等）的管理，通过人员服务档案的建立进行实时监控和量化考评管理；在度量层面使用自动化、智能化的分析功能，让数据的价值真正得到体现；在预估风险、组织决策、组织性能基线建立、外包商服务能力评估等多方面进行应用，利用多方的数据反馈不断健全和完善量化考评体系。4748测试敏捷化成熟度评价的背景为了更好地阐述测试敏捷化及其内涵，中国电子工业标准化技术协会信息技术服务分会（以下简称“ITSS分会”）所属数据中心运营管理工作组（以下简

113、称“DCMG”）联合双态IT联盟（BOA）共同研制，旨在为IT组织测试敏捷化提供方法指导、理清概念，推动测试敏捷化在IT组织中更好地实践，指导测试敏捷化探索前行。测试敏捷化成熟度评价的发布测试敏捷化成熟度于2021年9月1日，由中国质量认证中心发布为CQC9260-2021 测试敏捷化成熟度评价技术规范 和CQC92-831154-2021 测试敏捷化成熟度评价实施规则。测试敏捷化成熟度评价的意义测试敏捷化成熟度标准的发布打破了国外类似标准的垄断，是国内第一个帮助测试组织从传统测试向测试敏捷化转型的标准，是国家级的权威认证。通过认证将证明组织或项目在测试敏捷化方面取得的成就，成为行业对标对象，

114、同时会进一步激励组织持续提升自身测试敏捷化能力。测试敏捷化成熟度评价的内容评价标准覆盖测试10大领域，划分32个评估子域，分解为83个评估要素，216个评估要点，全面评估测试敏捷化能力，并分层指导，差距分析，从而提升组织和项目的测试敏捷化能力。Maturity Evaluation测试敏捷化成熟度评价测试敏捷化能力按测试全生命周期的特性划分为10个评估域，32个评估子域，评估子域共分解为83个评估要素，基于评估要素将测试敏捷化分解为216个评估要点。框架阐述能力建设战略定位创新管理预算管理绩效管理测试流程设计测试流程应用测试流程持续改进质量门禁测试需求分析需求评审测试目标与范围测试工作量评估测

115、试资源配置风险评估与应对测试方案测试用例设计测试用例变更测试用例评审测试环境构建测试用例执行测试结果分析问题反馈与跟踪测试报告复盘分析技术支撑工具支撑测试环境管理测试数据管理测试敏捷化成熟度模型测试管理和服务测试人员管理测试流程和规则测试需求测试计划 测试设计 测试执行 测试交付 测试技术和工具 测试环境和数据测试敏捷化服务能力要素组织流程技术支撑质效目标战略目标业务价值技术创新组织质效测试能力域测试管理服务测试人员能力测试流程和规则测试需求测试计划测试设计测试执行测试交付测试技术和工具测试环境和数据协作管理风险评估与控制度量管理4950测试敏捷化成熟度评价的申请方式具备测试敏捷化成熟度咨询能

116、力的公司对申请评估的组织进行培训和咨询，指导完成评级成熟度的优化改进；在具备一定级别的成熟度能力之后，由申请组织向认证机构提交申请材料，认证机构组织安排审核任务，中国计量科学院负责见证，国内行业测试专家进行评估。通过第三方权威认证来证明IT组织或项目在测试敏捷化能力方面达到的水平，审核通过后由认证机构颁发评价证书。目前已开放测试敏捷化成熟度的首批评价申请，首批评价通过的组织将成为行业标杆，激励和带动同行业的整体测试水平发展，促成行业趋势，也进一步提高IT行业的软件质量，形成良性循环。中国质量认证中心中国质量认证中心（简称“CQC”）是由中国政府批准设立，多国政府和多个国际权威组织认可的第三方专

117、业认证机构，隶属中国检验认证集团。中国质量认证中心由总部、业务部门、分中心、检验检测实验室及其他业务授权委托机构等组成，设有12个国内分中心、36个管体系认证分支机构、300多家签约检测机构、33个海外业务推广平台，参与了22个国际多边组织，与26个国家和地区的50家认证机构建立了良好的合作关系。测试敏捷化成熟度评价是中国质量认证中心推出的对测试组织或部门针对测试敏捷化成熟度的分级评价。从软件测试行业客户实际情况出发，以实践落地为原则，指导国内测试敏捷化的发展，进而提升整体测试敏捷化水平。中国质量认证中心始终致力于通过认证、检验检测、标准制定等高技术及专业服务帮助客户提高产品和服务质量，促成各

118、界的交流与合作，促进市场诚信体系与和谐社会建设。经过三十多年的发展，已经成为业务门类全、服务网络广、技术力量强的一流质量服务机构，以较高的信誉度和美誉度跻身世界知名认证品牌行列。中国计量科学研究院中国计量科学研究院是国家最高的计量科学研究中心和国家级法定计量技术机构，隶属于国家市场监督管理总局，属社会公益型科研单位。建院以来，中国计量院瞄准国际计量科学前沿，在国家经济建设、社会发展和科技进步中发挥了重要的支撑作用。为加强计量、标准化、合格评定等国家质量基础建设，深入实施质量提升，为产品服务质量提供技术符合性依据。中国计量科学研究院与中国质量认证中心合作开发软件成熟度评价体系，用于评估IT组织测

119、试敏捷化水平，同时帮助IT组织了解其在软件全生命周期中的测试状况，为如何改进提供方法，实现测试敏捷化，解决影响持续交付中测试端瓶颈，提升软件行业测试团队的敏捷能力，从而最终提高软件的质量，提升国家软件质量基础建设。Certification and witness成熟度评价及见证机构CQC中国计量院评审组申请方受理申请安排审核与见证任务资料审核评定报告发证现场审核出具审核报告提交申请配合审核与见证文件审核组建专家组现场见证出具见证报告评估申请现场审核评价结果评定批准获证后监督获证后监督评价结果评定批准现场审核/现场见证评估申请正式申请书；测试敏捷化制度、流程、文件、表单等相关资料。评价委托人、

120、数据中心法人的注册证明如营业执照、组织机构代码测试敏捷化成熟度评价依据 CQC9260-2021测试敏捷化成熟度评价技术规范由中国计量科学研究院安排的审核组执行，并完成现场审核报告从完成现场审核之日起计算，一般为 15 个工作日出具报告CQC9260-2021要求的项目经现场审核及现场见证在 10 个工作日内颁发评价结果证书因现场审核和（或）被评审现场不符合、企业资料无法提供等问题，造成评价无法推进，自申请受理之日起满 12 个月，或企业提出取消申请，评价终获证后 12 个月内应进行监督检查，每次监督检查的间隔不超过 12 个月。认证机构应在监督日期前 1 个月内向获证企业发出监督通知，并安排

121、监督任务。获证方产生的重大安全与质量事故或用户提出严重投诉并经查实为持证人责任的，可增加监督次数同初始审核项目全要素检查监督检查存在不符合项时，在 20 个工作日内完成整改5152北京国家金融科技认证中心北京国家金融科技认证中心作为人民银行、国家市场监管总局联合批复的权威检测认证机构，以支撑金融科技守正创新发展为己任，秉持“科技向善、金融为民”理念，坚持“国内领先、国际一流”目标定位,发挥“传递信任、服务发展”职责使命，助力搭建畅通监管、产业、机构、消费者四方主体“立交桥”。围绕金融科技、普惠金融、绿色金融、数字基础设施、个人信息保护等重点领域和薄弱环节，研发推出人工智能金融应用双认证、金融APP无障碍认证、碳中和认证、绿色数据中心和数字基础设施能力等级认证、商用密码评估等产品服务，形成涵盖认证、检测、安全、FinTech+的4大类68项主营业务，累计颁发证书1.6万余张，服务机构1809家，覆盖全国各省直辖市并延伸海外。