【直播回顾】深度分享 | 战玲玲《踵其事而增华，变其本而加厉—软件测试工艺转型实践》
发表日期：2022-07-06被浏览： 1122次返回

编者按

 

iSQE对话金融行业第二期直播活动于上周圆满落幕，本期直播邀请到了中国银行软件中心战玲玲老师进行了《踵其事而增华，变其本而加厉—软件测试工艺转型实践》专题分享，探讨新形势下金融软件测试工艺突破发展的途径，从建设测试工艺、改进测试工艺以及转型测试工艺等方面进行分享。以下是战玲玲老师演讲的文字版内容。

 

嘉宾按

 

首先感谢iSQE提供的平台，也感谢我们的各位同仁和同行，能够冒着酷暑然后来听我的分享，这也是对测试的真爱。

我今天分享的题目是踵其事而增华，变其本而加厉，主要想表达的意思是怎么能够在传统或前人的一个基础上，能够把我们的一个工艺建设得更好，并且根据时代和形势的变化，把它建设的更先进。

另外，在我做测试工艺的过程当中有一个感触，经典的事物经得住推敲，非常的有价值，在我们的工作过程当中，永远都是常读常新，不管什么时候去读，都会有新的感触。

我今天将主要分享软件测试工艺转型的一个路径和实践。在分享中国银行转型实践之前，我想先同步几个定义或者是几个概念。

• 第一个是全面质量管理

大家做质量工作和测试工作的应该都比较清楚，“全面质量管理是一种综合的、全面的经营管理方式和理念。以产品质量为核心，以全员参与为基础，其根本目的是通过顾客满意来实现组织的长期成功，增进组织全体成员及全社会的利益。全面质量管理内容和特点，概括起来是“三全”、“四一切”。

三全：“全面的质量管理”、“全部过程的管理”和“全部人员参加的管理”

全面质量管理：实际上我们在做质量工作和测试工作过程当中，我们都知道产品的质量很重要，但是实际上全面的质量管理，它强调产品质量是基础，即使产品质量好，如果交付的慢、生产的成本高，也不会带来好的价值和收益。所以全面的质量管理它强调的是产品的质量、低成本和快速交付都很好，才能够证明我们的质量是好的。

全部过程的管理：不管是生产软件还是生产硬件，有很多的过程和工序，在每一个工序过程当中，我们都要有质量的控制和管理。大家经常说质量是生产出来的，不是测试出来的，所有的产品到了最后靠测试这个阶段去保证质量，那根本不可行。应该在整个的工艺过程、流水线过程当中，都应该有质量的管理和控制活动，并且要有一定的标准。

全部人员参加的管理：其实就是全员都参与，整个的交付流水线有各种各样的角色，单指在生产线上的也很难实现好的质量，所以应该是企业里全部的人员都要参与过程当中，为质量负责。

四一切：“一切为用户着想”、“一切以预防为主”、“一切以数据说话”、“一切工作按PDCA循环进行”

一切为用户着想：我们一说到用户，通常会想到的是客户，因为用我们产品的那就是最终的客户，我个人认为这相对而言是比较狭义的定义。

实际上下一道工序就是前一道工序的用户，从广义上来讲，你在生产的流水线上，每一个工序生产出来的交付物未必是一个成品，但是它会作为下一个工序的输入，也要为下一个工序的用户去着想，所以这个用户广义来讲是包括流水线上的所有的角色。

一切以预防为主：刚才在全部过程管理提到过，我们所有的质量活动不能都到最后，大家也都在说测试的前移，只要在前边我们有很多的测试。从生产的工艺上来讲，我认为可以有两条线，一条是生产线，一条是检测线。目前的DevOps，我们是把这两个线可能拉齐在一个工序上，在每一个生产环节都配套有验证的环节，有的是评审、有的是走查，有的是动态测试，它验证的方式有所不同，但是都要有。

一切以数据说话：我们都要有度量的这种概念，一切都要以客观为出发点，用数据来证明质量的好和坏。

一切工作按照PDCA循环进行：PDCA，大家都知道这是过程改进循环的一些工作，包括计划、实施、检查和改进。

这是全面质量管理的三全和四一切。

• 质量波动

质量波动是指同一个人在同一台机器设备上，用同一种原材料、同样的工艺方法加工出来的成品质量未必完全相同，这个就是我们说的质量波动。

质量波动是客观存在的一种事物，在任何的加工过程当中都是存在的，不以人的意志为转移。

另外影响质量的因素有好多种，除了人员不同以外，采用的原材料不同、设备不同，它的波动加起来会更大，影响质量波动的因素非常多。

工序的质量决定质量波动的大小，工序的质量好，它波动就会小，工序的质量不好，波动就会大。

• 工艺

对于软件来讲，工艺实际上和硬件一样，只不过它是生产出来的产品是无形的、不可见的，所以相比硬件生产而言，软件生产理解起来难度相对会大一些。

影响质量波动的因素有6种，也是我们生产工艺的一个组成的部分，统称为“5M1E”指的是：人、机器、物料、方法、环境和测量。

人其实就是我们的角色，人从工艺上来讲，它的定义比较宽泛，不仅仅是指个体的一个角色，有文化的认知、人的技能，包括职责；

方法也是非常重要的一个组成部分。方法包括我们生产的工艺，就是我刚才说的工序，还有一些操作的规程、标准的规范，技术方法。

材料，如果在生产硬件的过程当中是比较显性的，可能有原材料。在我们软件过程当中，其实每一个过程的交付物，它的输入和输出，我们的一些需求，技术方案，设计说明书，还有我们测试过程当中的一些计划方案，包括案例，这一些的输出物实际上都是我们的物料和材料。

测量，测量就是度量，我们要有一些度量的方法，度量的标准和度量的这些指标的定义。

机器对于软件研发而言就是一些工具，包括管理的工具，自动化的工具，这些都属于机器这一块的范畴。

环境可以理解为我们的一些配套资源的建设，包括测试环境，或者是一些数据准备等。

这就是工艺的6个主要组成部分，实际上我们所有的过程和工艺，包括我们TMMi也是围绕着这些定义的我们的一些过程域。

• 为什么要引入工艺？

工艺是产品生产的主要的依据，尤其是在规模化或者是量化生产的情况下。目前每一个企业，尤其像金融行业规模在不断地变化，像我们银行系统都能够达到几百个，开发人员也好，测试人员也好，这个也都是几千人这样的一个规模。在这样的一个规模下，没有一套这样的工艺来保障的话，首先我们很难生产出这么些的系统出来，另外生产出来的质量也基本上很难去保证。

所以在这种情况下，要引入一套合理的工艺，能够对生产起到指导的作用，最终会实现我右边画的图的几个价值。首先是提升产品的质量，其次是要提升服务的质量，另外就是要缩短交货的周期，最后是降低投入的成本。

我们有一套好的工序，可能生产一个东西的时候，未必会投入那么多人。尤其在当前数字化或者是智能化的时代，再靠招聘员工去生产咱们的软件系统的话，基本上是很难实现的。

所以在基于规模大，系统多，当前这种客户体验客户的要求又高，对交付的周期要求又快。

另外还有我们人员规模这么大，人员的能力参差不齐等情况，引入这种工艺，对于测试来讲，引入测试工艺是非常必要的一件事情。

在引入工艺的时候，我们知道原来是说先有几个阶段，我们原来一直在讲是先僵化再固化，然后在基础上再优化。目前也都在讲数字化转型，所以根据这种情况，我就分享一下我们测试工艺建设的路径和实践。

一、谋势而动，建设测试工艺

我们从2004年开始，在测试中已经有一套相对比较简单的工艺，从2004年开始持续在这套工艺上去进行建设和优化。

在此期间我们也经历了组织架构的变革，一开始是软件中心，有单元测试、组装测试和SIT测试。当时的单元测试和组装测试都是由开发人员自行去测，没有一定的规程或者是工序的要求。SIT是有了一些测试方案制定、案例编写、测试实施管理、测试报告。

2014年的时候我们就把UAT和SIT进行了一个整合，整合后的工艺就包括了单元、组装以及功能测试，这个功能测试就是有sit的成分，也有UAT的成分，所以我们是起的这个过程的名字叫功能测试。

另外是还有一些专项测试，比如：安全、客户体验。性能测试和选型测试以及同产演练的测试是由数据中心来负责，这是两大中心对整个测试环节的一个定义和分工。从需求的接收一直到投产的动态验证的环节大概就分为这些。

这张图是把整合前和整合后大概的变化做介绍，我们是软件中心，负责接收需求、任务下达，所以从需求的分析、设计、编码那都是在软件中心完成的。

测试环节就是刚才提到的有单元组装，原来有SIT、UAT，整合以后就把 SIT一分为二。组装测试承接一部分，功能测试承接系统组装集成后的SIT加UAT的测试，站在用户视角的测试。

大概在2012年，我们引入了敏捷的实践，在这个基础上也针对敏捷制定了敏捷迭代测试。

作为金融行业的测试人员都知道，在一个需求来了以后，它可能会涉及很多的系统，不是由一个系统来完成的。

敏捷和面向过程实际上是一个开发方式，一个需求设计很多的系统来进行改造也好、开发也好，这些系统有的是用瀑布的方式开发，有的又是用敏捷的方式开发。在这种情况下，我们也在工艺上对整体来讲，一个是站在整个的视角上，一个全需求的视角上，涉及的这些系统他们如何根据迭代或者是根据单元测试来把整个测试活动进行融合，所以在工艺上是兼顾了瀑布和迭代，这个方式也保证整个中心在整体的测试的工作上能够无缝的衔接，也能够在保证一定的交互质量。

这是整合和引入新的开发模式，对测试带来的一些挑战和应对方法。

 

每一个过程，不管是单元组装还是迭代，敏捷对于测试来讲，差异更面向过程，我个人是觉得差异不是非常大，因为敏捷强调的是小步快跑，我们原来一个需求就非常大，它的开发周期和测试周期都很长，大概要经历2~3个月，长的话需要半年或者一年，快速交付很难实现。

所以敏捷只是把需求进行了一些拆分，把大的需求拆分成一些小的需求，对于测试而言没有太大的差异。该保证的质量、该执行的测试都要有。针对敏捷迭代，我们也经历了三年的试点过程，如果面向过程，我们的要求非常高，每一个开发部、每一个测试部都要按照我们的这些过程去执行。

如果不执行，有各种各样的内审、外审和一些考核。敏捷当时是一块试验田，根据敏捷的方式，到底我们应该如何去做，对它过程交付的文档要求来讲，就相对会轻量级一些，给它一个充分的时间，去看跟传统有什么不同，应该自己有一套什么样的工艺和方法。

后来发现该做的验证还是要有，敏捷对工艺的成熟度要求更高，如果没有办法实现自动化，敏捷其实也快不起来。所以针对敏捷，自动化的方面研究和投入的就比较大，所以在单元也好，组装也好，基本上都是要求用自动化去实施。

另外，测试左移要求也很高，在敏捷迭代的时候，我们要求专职的测试团队人员要加入到敏捷的团队当中，来行使测试相关的职能。在银行当中，一个完全解耦的系统相对比较少。我根据自己的需求抿完以后迭代就上生产，这种也比较少，每一个需求可能有很多的产品，之间有很多的关联关系。实际上敏捷在我们银行业执行也挺难，所以根据这些年在自动化和工艺的定义上，确实也有很大的改进，所以比刚开始的时候会好很多，但是慢慢地我们也会把工艺标准化，跟面向过程目前的要求和差异不是非常大，因为面向过程我们也要求快，也要求自动化，这个是敏捷和面向过程。

每一个过程有规划、分析、设计、准备、实施和总结，这个应该大家都一样，差异应该不是非常大。我们在每一个阶段都有明确的定义，就像我刚才说的我的输入是什么，输出是什么，它的一个交付标准是什么？然后在每一个环节我们都会有相应的评审，保证每一个工序实施的质量。

另外是针对每一个环节的角色，都有一个明确的定义，谁是主导方，谁是配合方，这些角色的职责和技能的要求，这些年也在逐步完善。

 

我们实现了统一的测试管理，包括测试任务的管理、实施、环境、数据以及测试调度的统一管理，环境版本的部署安装，批量运行，还有做一些特殊的测试，都是统一由测试调度来进行管理。

这些年根据我们自己的需要，自行研发了测试管理系统，实现了从任务到版本到案例过程问题单的流转以及报告的提交评审，这全都在测试管理系统里实现，实现了信息化。

中国银行目前的测试不光是总行产品，还包括国内海外的分行，测试也都使用我们的工具。因为总行和分行之间的产品也有很多的关联关系，所以统一的测试管理对测试的效率和测试过程的可视化起到了非常大的作用。

这个就是我们的第一阶段，体系从无到有这么一个过程。在此基础上根据我们的特点不断地完善和发展。

 

二、顺势而为、改进测试工艺

第二个阶段，持续地改进测试工艺。改进之路有几个关键的里程碑点。

2004年的时候，我们测试独立，建立了相应的测试过程，2009年通过了CMMI4级，我们是一个软件研发组织，所以通过了 CMMI的认证，建立了一套完整的质量管理体系，包括了我刚才说的需求的接收，包括任务的管理，还有其他一些配套资源的管理，测试的管理，整个中心的运转都囊括在测试管理体系里。

2009年到2012年，中国银行经历了国内蓝图的建设；2013年至2018年，中国银行经历了海外蓝图的建设。在这个过程中，我们不断地改进测试工艺以及测试管理系统。新系统和以往有很大的不同，若不及时调整会阻碍新系统建设的发展。所以在这个过程当中，我们的测试工艺突飞猛进。

2012年中国银行引入了敏捷的实践，这时候也是考虑了这种双态的支持。

在2014年进行了开发测试的融合，工艺也是做了一个比较大的调整，测试工艺整合完以后，交付周期也大幅缩短。

2021年中国银行通过 TMMi5级认证，相对来讲比较晚,之前通过的CMMI认证也做到了测试的改进，但是CMMI对测试的定义没有TMMi专业，所以中国银行在2021年希望通过一套国际上通用的测试标准，在行业的整体的情况下，我们到底是怎样的能力的成熟度，因为前期有很多的建设和优化的实践，所以在通过TMMi的时候相对比较快速地通过了认证。

在2021年，我们开始了企业级架构的建设，这个变化应该是数字化或者是云原生的一个过程，对于我们的测试工艺就带来了更新的挑战。

我们测试工艺的优化遵循的举措是：首先识别优化的一些目标、对过程能力的评估；制定一些优化的计划并且实施这些优化的行动，最后都要去试点和评价。在缺陷预防、合理的组织平台的提效、强化控制手段、新技术的融入等基础上不断地优化。

其实软件中心在工艺的固化执行的过程当中，中心的领导、管理层比较有力度，整个工艺制定完成后，并不是说方法上墙，方法和实施两张皮，所有的工艺和体系相应的标准规范，管理规定，制定完了以后全部都是应用到实践当中。每一个实施部门都要严格执行。当时也有一个说法，违背过程的事情是非常大的责任.如果是技能达不到，比你违背过程还是要轻很多。对于过程和这些体系的推进起到了很大的作用。

从部门设置来讲，我们是有技术管理部门和实施部门。技术管理部门专门负责工艺的制定、优化以及推进的实施；实施部门会对我们这些体系提出，在实施过程当中不能执行或者很难执行的问题。每年都会收集相应的问题和建议，当然平时也有一些收集的途径。我们作为技术管理部门比较害怕实施部门提意见。当然他们的意见也促进了我们在工艺上的不断改进，只要有问题，我们就要想办法解决。

我们的体系也好，工艺也好，有过程标准都非常多，也相应比较细，对整个过程的每一步做什么，然后如何去做的评判的标准，都有比较精准的定义。

 

持续改进重点：工艺的重点是过程、方法和角色，围绕这三点，我们不断去做一些改进和提升。

过程管理方面：我们强化测试风险的识别能力，加强测试的准入，质量的把关，控制测试周期。基于失效原因分析的改进，这也投入了很大的精力，进行了相应的失效原因分析的改进和分享等这些活动。

人员培养方面：每年都会进行质量文化活动和质量意识的宣传。另外还有技能的认证，中国银行比较早引入了ISTQB认证，现在中心有几百人通过了ISTQB基础级认证，100多人通过了ISTQB高级认证，在人员能力培养上也做了很多的改进。

工艺改进：从工艺上不断地提升规范化、自动化和智能化的水平以及对测试全景图的一些建设。

对于基于风险的研究和落地，基于风险的测试的落地并没有那么简单，我们在应用上还有很大的欠缺，现银行的这种系统基本上来讲，什么样的系统在什么样的情况下，我们要多去投入，在什么样情况下少去投入，这些优先级和基于风险的分析，还是有很大的提升和改进的地方。

 

强化统筹管理：软件中心由北京和几个分中心，另外还有分行涉及的测试方非常多，开发的系统也很多，开发方也是非常多的，还有一些是有除了自主开发，还有一些是外包开发，这些的质量也都是参差不齐。

我觉得一个工艺从整体的顶层设计上，要有一个系统化的思维，进行系统化的管理，才能够保证这么大的组织能够按照一定的质量标准去开展相应的工作。

这个地方其实是对我们一个测试任务的管理做一个实例，目的是想表达这个测试任务的一个复杂情况。每一个测试任务有可能是仅包含面向瀑布开发的产品，也有可能包含瀑布和敏捷的产品，也有可能是总行涉分行的或者分行涉总行的，还有涉安全的，涉性能的，涉非功能的，另外还有涉外部的，涉监管的，各种各样。它任务的复杂度是非常高的，统筹管理也就非常重要。针对不同的任务的情形，我们都要有配套的工艺去保证任务的落地和实施。

通过TMMi5级认证的时候，也给了我们质量管理体系和或者说我们的测试工艺相对较高的一个评价。比如：识别了我们企业的一些优势，管理体系基础比较扎实。经过十多年运转和不断的持续优化，确实是有一套比较符合我们中国银行软件中心的质量管理体系，相对来讲也能够保证实施部门的落地实施。

流程规范制度相对完善。这里举出一些例子，我们的流程有：过程文件、标准规范、管理的方法、管理制度，光测试就有几十个上百个，对每一项的要求相对来讲都比较细致，基本上实现了精益化的管理。

标准基线化、质量可预测。针对每一个任务，它的准出的标准也引入了相应预测和度量的方法。保证我们顺利通过了TMMi5级认证。这里主要分享了一下我们测试质量管理体系持续优化的过程。

 

三、乘势而上，转型测试工艺

目前数字化转型也是如火如荼，中国银行也在做相应的企业级架构建设，在这个过程中测试的工艺也需要与时俱进，进行转型。

随着企架的建设，我们又建设了新的、企业级的测试工艺。目前经过整改，性能测试等所有的测试都到了软件中心。整体来讲，根据新的形式，单元测试又引入了新的组件测试和组件集成测试。这个图对我们整个的测试的过程和测试的类型进行了定义。包括内部测试，就是开发侧的一个测试；和用户侧的测试，我们叫功能测试（没有叫验收测试）。另外还有一些专项的测试，包括选型、基地行的体验测试，以及一些客户的拓展和联调测试。所以在企架的新形势下，对测试工艺做出了一个新的定义，也是为了满足现在的形式。

因为目前企架建设在逐步推进，既有新的系统的建设，也有现存系统的运转。所以从开发的方式来讲，仍然还是存在瀑布开发和敏捷开发两种方式。

所以在这个情况下，我们还是兼顾了瀑布和敏捷两种工艺的制定。但是目前来看单元和组件，不管是敏捷还是瀑布开发，实际上差异不大，采用的方法和交付的标准差异也不大。对于敏捷开发来讲，我们要求更高。经过敏捷的开发和测试以后，质量标准要求更高，是新的工艺。

另外我想讲一下V模型,在定新的工艺过程当中，对V模型又有了一个新的认识。我们目前起架新工艺，首先是V模型的左半边，就是我刚才说的应该是一个生产的工艺，包括需求的分析、架构的设计、系统的设计以及开发。

在新的工艺中对每一个工艺又进行了更细化的细分。如图所示，上边都是一些大的阶段，比如：分析阶段和设计阶段。分析阶段也做了一些细化，包括定义、识别，原来我们就是需求分析、总体设计、详细设计，现在对需求分析过程也做了非常细的工艺的定义，应用分析里有功能差异分析、产品的模型匹配，整体方案包括上下文关系、应用架构、数据架构，又做了一个比较细化的定义。

实际上原来我们大家也都是在讲单元测试、组装测试、 SIT测试、UAT测试，到底测的方法有什么不同、目标有啥不同，定义的边界一直不是那么清晰，也很难去界定。

所以为了保证质量，实际上我们在后续的环节是不断的在加大投入，UAT本来是应该站在用户的视角去做的一些测试，但是为了保证质量，又把SIT甚至还有白盒的一些测试也都纳到了UAT测试，所以后续的环节投入不断的增加，也是开发的工艺不够细化带来的影响。

我们针对新的工艺，开发工艺已经进行了细化，所以再回到V模型。原来需求分析阶段分为项目分析、设计阶段、细化设计阶段，现在这些阶段里又细分了很多小的工序，每一个工序的输入和输出物也都比较明确，当然可能文档还是一个。原来我们测试最头疼的就是开发的文档，开发的文档大家都觉得写得非常不好，对我们测试的影响也非常大。

在后续的这种工艺过程当中，我觉得开发的工艺会做得越来越好，它每一个工序的定义以及它的一些交付物也都会做得非常好。所以对测试来讲就具备了一个条件，测试能够明确的定义输出输入。开发的这些输出物，哪一些是作为输入，根据这些输入，我们要测试的内容和范围也相对比较清晰。我们采用的测试方法，还有测试需要的一些条件，包括环境资源、数据，这些也都会相应地明确。

V模型现在就挂这几个单元组件、组建集成、功能或者是需求阶段、分析阶段，如果细化，里边会有很多的工序，也在试着去把这些新的工序都在这儿体现出来，每一个工序的输出也就比较清晰。在这种情况下实际上也会起到一个测试驱动开发的作用。我们根据这个要求看开发的交付物，哪个达标，哪个不达标，也就容易做到了。

中间我画的这条线是指我们的被测对象，在这些的输入输出以外，我们测试的被测对象，每一类测试也是不同的。比如：单元测试，我们现在是程序的交付、有构建，当然原来也有函数、模块，但是现在有构建的话那就更清晰，组建的话以后都是微服务，分布式的架构，每一个微服务可能就是我们测试的对象。组建集成测试就是服务之间的调用，功能测试或者是验收测试就是对于用户需求的验证，这些都相对比较清晰。

另外还有一个比较大的变化，就是需求。现在需求在数字化转型的背景下也要有建模，会用数字化的方式、结构化的方式来管理需求，所以对所有的前序环节都实现了数字化。对于V模型的右半边-测试，在实现数字化转型的路上相对打好了基础，具备了数字化转型的基础条件。

我刚才提到V模型的开发对象，在V服务分布式的架构下，它的测试对象比较清晰，有这么多种的构建，它就是单元测试的主体，要保证这些构建的质量，经过单元测试以后，这些构建的质量是要达标的。经过组件测试是保证服务，它的质量是达标的。组建集成是指这些服务集成到一起以后，应该实现一个什么样的质量标准，交付一个什么样的代码出来。对于功能测试、验收测试来讲要整体的都组装到一起以后，站在用户的视角去做的测试，所以对测试对象也再做一个清晰的定义。

针对刚才提到，我们要做数字化转型，实际上是离不开前期这些体系以及工艺的建设，并且是长期的持续改进。只有在这个基础上，我们再去做它的数字化、智能化和自动化才是可行的。目前我们正在做精准测试中台的建设，目前更多的想实现测试分析、测试设计的精准化、中台化和智能化的目的。

基于前边我说的V模型左半边的输入、输出比较清晰，我们根据它的输出，实现相应的数字化、结构化的管理。在此基础上，再结合我刚才提到的基于风险，我会对所有测试的对象，测试的交付物、输入物，还有开发方、测试方都会进行风险的标识。基于这些风险制定算法和规则，实现测试分析设计的精准化和智能化，这是降低对人员的能力的要求。这是测试中台的建设，也是我们整体在工序上的基础。

 

最后我再分享一下测试能力地图的建设。

人员能力和测试能力的建设也是工艺的一部分。在我们软件中心，根据不同的测试的类型，内部测试、功能测试和专项测试，都有一系列的角色，对这些角色的职责的定义，以及要做什么、如何做，都有相应配套的管理办法，或者是指南规范的支撑。其实也不止左边列出来的这些角色，因为我们现在还有性能测试、安全测试，都是由专门的测试工程师来完成的，还有功能测试以及开发测试、还有环境部署工程师或者是运维工程师。

另外开发的支持工程师，包括项目经理、团队经理、测试经理，还有我们的基地行、国内海外分行很多这样的角色，这些角色到底应该具备哪些技能？这些技能如何去落地和实现？目前我们也在做能力地图的建设，规划相应的角色的职责。另外他的技能的需求要去细化，不像原来希望一个人恨不得啥都能会，既要会开发又要会测试，还要懂这个还要懂那个。实际上在这些过程当中，无论是招聘还是在其他的方面都很难去落地。因为招不来那样的人，也很难让每一个人都能够变成全能的选手。所以会针对不同的测试的要求，它到底需要什么样的技能会去细化，细化到可落地、可实施，根据要求引入一些培训和认证，目前这一块也是我们在持续建设的事情。

以上就是我进行的分享，前边讲了三个势，其实还有非常重要的是聚势而强。目前来讲一个企业，首先我们的工艺也好，我们的质量体系也好，也是分几个范围，如果可以是团队级的，可以是部门级的，也可以是企业级的。最终我们应该还有行业级的，或者是现在大家也都在谈的一个生态圈，有生态的建设，有一套相应的标准和规范，目前不管是团标、国标、行标都有在建设，有这样一套的整体的行业标准还是很有必要的，这样可以拉起整个行业测试能力的提升建设。所以我也希望能够和融行业的各位同仁合作起来，共同为测试工艺的建设和提升做出我们的力量，今天的分享就这些，谢谢大家。

 

 

演讲嘉宾

战玲玲，中国银行软件中心，测试架构师，拥有多年的软件开发和金融行业软件测试工作实践经验，先后担任过项目的测试经理、测试管理团队经理和测试技术团队经理，负责组织中国银行软件测试过程改进、过程文件、标准规范的制定和测试技术方法的研究推广，擅长根据测试过程中的问题进行测试工艺改进和优化。同时兼职中心的内训讲师，负责进行测试相关的培训工作。

 

资料获取

• 演讲PPT分享：点击：链接 获取演讲PPT（百度网盘提取码：iSQE）

• 演讲视频回放：想了解更多精彩内容，点击：链接，查看直播回放