【直播回顾】深度分享 | 苏梦《基于TMMi，测试体系演变之路》
发表日期：2022-08-24被浏览： 1341次返回
编者按：
iSQE对话金融行业第四期直播活动圆满落幕，本期直播邀请到了泰康保险集团科技中心质量管理专家苏梦老师进行了《基于TMMi，测试体系演变之路》专题分享，聚焦泰康测试体系建设，围绕测试的规范化、测试的体系化以及测试的数字化等进行分享。
以下是苏梦老师演讲的文字版内容。
嘉宾按：
大家好，今天非常荣幸能有这样一个线上直播的机会来和大家分享基于TMMi的泰康测试体系演进之路。泰康保险集团有限公司成立于1996年，至今已经发展成为一家涵盖保险、资管、医养三大核心业务的大型保险金融服务集团。
面向长寿时代，泰康创新商业模式，整合保险支付与医养服务，打造长寿、健康、富足三大闭环。以泰康的业务战略为指引，科技团队也持续砥砺深耕，历久弥新，围绕三大闭环的战略打造科技护城河。同样在泰康科技战略的引领下，测试团队作为整个研发过程非常重要的一环，也经历了三个阶段的发展。
今天我为大家分享的测试体系演进之路，将从测试的规范化、测试的体系化以及测试的数字化来呈现整个泰康测试体系的专业性。
一、测试规范化
首先是测试的规范化，整个泰康的测试体系在这三个阶段其实有非常鲜明的特征，第一个阶段的关键词总结为规范化。在2002年，我们在当时还属于泰康人寿的需求团队中组建了测试团队，从而有了一个简单的上线流程。经过了10余年的发展，我们在2013年正式成立了独立的测试管理组织，也建立了初步的测试体系及流程，并且承接多个核心系统的测试工作，至此形成了规范的测试体系。
这一阶段的业务特点还是以传统金融为主，注重合规、稳定、质量，大家基本上还是按照瀑布的模式按部就班完成各项工作，按照各项里程碑保证自己的交互。相应的测试体系，在这一阶段的特点就是明确了各项的要求，也让测试活动实现规范化，包括测试组织、测试人员、测试过程等各方面都建立了可落地的、时间性强的规范要求，从而形成测试活动的规范化。
第二个阶段的关键词就是体系化，这一阶段最大的转变就是引入了国际标准的测试体系框架TMMi，让泰康的测试体系建设得到了质的飞跃。从2015年开始引入TMMi之后，逐步完善测试体系，并不断推广TMMi的实践，持续优化测试过程，建设各类测试工具和平台来提升整体的测试生产力。
随着整个的科技团队从集团化转型为提供科技底座的集团总部加与业务融合子公司的这种模式，出现了不同的研发形态，有这种部落制的，按照各个业务条线“产研测”高度融合，在子公司快速拓展市场，有丰富的业务节点，也需要提供持续的保障，也有维持之前的传统模式，以稳定交互为主，在这种多业务形态、多研发模式之下，对于测试体系建设面对的最大的困难是我们如何用一套体系适应丰富多样的实际情况，既要与业务深度融合，同时也要守住我们的质量底线；既要保证交付的质量，同时也要保证交付的时效。而测试人员在这个阶段就不仅仅是完成功能的验证，我们还要构建质量的思想，做到风险预警也十分的重要。
同时因为有了集团的科技团队和子公司的科技团队，我们在一套测试体系的引领下，如何能够“总子协同”，适应大家对指标、工具、人员等方面的统一要求，也为我们提出了非常多的问题。
第三阶段的关键词就是数字化，这也是当前我们正处于这一阶段的一个建设中，在之前经历了夯实的体系规范，以此为指导来实现制度流程化、流程工具化、工具自动化，以数字驱动持续改进。在以业务为导向的协作模式，以产品为导向的交互模式下，测试团队也顺应时代的发展来建立以用户为中心端到端的分层测试体系，所以我们在第二阶段测试体系，也是来对标了整个的TMMi的建设，同时进入测试数字，我们也是要聚焦整个测试体系数字化的转型。
首先测试的规范化，第一阶段规范化主要体现在几个方面，第一是有了独立的测试组织，有了规范的测试管理，同时也明确了测试职责。
泰康在经过了26年的耕耘，在整个大健康领域蓬勃发展的背后，科技是重要的推动力量，从而也催生了科技领域要精细化的管理，所以独立的测试组织也是顺势而生。因为有了独立的测试组织，通过专业化的测试管理和清晰的测试职责，也实现了测试游击队向测试集团军的转变，让测试资源专职专业，让测试过程有理有据，让测试交互保质保量。
在独立的测试组织方面，我们如何体现和建设？
首先就是从人员方面，我们分为两部分，自有人员和厂商人员，他们职责明确，分工明确。对于自有人员主要重点工作的重点还是抓管理、重设计，多方协调，严格审核；而对于厂商人员更多的是以执行为主，所以工作重点是抓任务、落执行。多人协作、要严谨的测试。结构化的资源管理是独立测试组织的基础。在人员类型上面我们进行了这样的分配，也有了各自不同的工作重点。同时从角色岗位上，又形成了以测试工程师到测试分管、测试主管、测试经理这样一个金字塔的结构。
一方面通过集中的测试资源，让研发过程分工明确，职责清晰，这体现出了我们的专职。同时也有了专业的测试团队，让研发交互有了上线前的保障。在整个金字塔结构的角色建设和人员建设中，我们也是有明确的区分，测试工程师以执行为主，所以我们也是以厂商人员为主，配有部分的自有人员来进行测试分析相关的工作。其他从测试分管、主管到测试经理，我们完全是以自有人员为主，这也对应了我们的不同工作重点，分别是抓管理和抓任务执行。
在规范的测试管理方面，有的集中的测试资源之后，我们就建立了一系列的规范制度，来指导不同测试岗位的伙伴有效测试，从而建立了以验证需求、发现缺陷、评估质量为测试目标；以全面测试、持续测试、适度测试为测试原则的各类测试准入和准出的门禁，把门禁作为一个标尺，来调动所有测试人员的积极性、主动性和创造性。通过多轮的测试建立统一的测试工作流。我们严守测试门禁，也是为了保证整个测试阶段，甚至整个研发过程的交互质量。
对于测试准入，我们至少要做到需求评审是通过的，需求的范围以及关联相关的职责都是明确，测试案例一定要经过相关方的共同评审来保证挖掘了隐藏的需求，在测试环境也是要独立准备完成，并且我们一定要有冒烟测试，通过了相应的准入。在测试准出阶段，我们也是建立了明确的要求，对测试的覆盖率，然后未覆盖的是一个什么样的类型，所有的测试用例和执行程度是有要求的，同时对于严重级别高的缺陷，它该如何解决？整体的缺陷关闭率是怎样？我们主要从这几方面来定义了测试的准出。
对于明确的测试职责，因为我们整个测试人员是以厂商和自有人员为主，又分为抓管理和抓任务执行，而整个的测试过程也是一个多方协同的过程。
为了大家能够有序协作，最大化的过程定型能力，就需要从测试管理、测试设计和测试执行这方面来建立明确的测试职责。
对于测试管理，我们要在项目启动的时候就制定相应的测试方案，在整个项目执行过程中要协调各方的测试资源来保证测试进度。同时要及时的分析测试相关数据来观测测试风险，并且要管理变更来保证最终实现在项目初期制定的测试目标。在项目结束之后还需要统筹各方及时复盘，从而为后续的交付来沉淀相应的测试资产。而测试设计和测试执行又分别从识别测试需求、设计测试用例、组织和参与设计评审，以及完成测试执行，记录跟踪缺陷和部署维护环境等方面来保证整个测试过程的完整性。
二、测试体系化
第一阶段的测试规范化，就如刚才我们所提，因为有了独立的测试组织，明确的测试职责和专业的测试工作，从而实现了测试团队从游击队到集团军的一个初步转型。第二阶段的测试体系化，我们又进行了一个怎样的演进？
随着泰康业务的快速发展，对科技的质量和效率都提出了更高的要求，仅有独立的测试组织和规范的测试过程，已无法应对更高质、更高效的业务交付要求。
我们在这一阶段引入的TMMi，分别从流程标准、工具赋能、数字驱动、人员能力等方面，让整个的测试过程体系化、系统化、平台化，这也成为测试团队责无旁贷的选择。同时科技贴近业务、服务业务，基于已有的测试资产，我们也形成了以TMMi为依据，建体系、建流程、建工具的组织级测试集团军，加上快速响应持续交付的业务及测试特种兵这样一个写作模式。所以我们在这一个阶段，用了6年的时间，夯实我们整个的测试体系。
随着整个集团化和科技战略的创新及转型，我们的测试团队也实现了由集团军向集团军与特种兵协作模式的一个转变。这一阶段最大的特点就是体系化，而我也将花更多的时间把这一部分作为重点和大家进行讲解。
首先是流程标准，因为泰康还是传统的保险领域，它面临的业务非常的多样化，同时随着子公司对业务快速上线的要求，我们整个的研发形态也出现了一个多样化。随着泰康科技的研发模式，逐步从传统的瀑布式开始转型到以DevOPs为核心的规模化敏捷，双模形态也是并存，所以测试流程也需要标准化的输出加机动化的变革来适应不同的研发模式。
作为双V的研发模式，是我们最常见的瀑布研发模式。这种研发模式通常是用于新建项目或是设计架构、整体业务流程等大规模调整的需求。这类项目或需求的特点就是建设周期长，质量和稳定性的要求非常高，所以测试流程也主要基于w测试模型来开展一系列的测试活动，从而保证从需求到交付的整个研发过程，都有与之对应的测试活动。
从最开始的需求分析，我们就要对应去探索需求里面每一个功能点的可测试性，进入到概要设计、详细设计，我们同样也要对测试需求进行提炼和分析，从而制定我们的测试策略，来确定我们的测试方案，所采用的测试设计的相关技术。
进入到开发实现阶段，对于我们测试就要开始准备相应的用例，可能是手工执行的用例，也有可能是自动化的用例，然后开发再进行完成单元测试之后提测，这个时候我们要经过各个阶段的测试来保证最终实现与用户期望的一致性。有功能测试、系统测试，最后还要回归测试，再进入整个的用户验收，在这一阶段开发也是要进行相应的缺陷修复、联调，大家来最终保证一个整个的交付。
从整个测试阶段，虽然与开发和需求活动不管如何对应，都是分为两大阶段。
第一是在前期的分析和设计阶段。
第二个阶段是进入到我们具体的执行阶段。
我们要保证每一个环节的完成度，这样才能符合最后的项目目标，从而也避免进入到最终的验证阶段之后，缺陷出现了爆发式的增长。所有问题的发现和解决都可以在有限周期内呈现合理的一个收敛趋势。这个是我们为了应对新建项目或者大规模改造的项目采用的传统瀑布式的测试流程。
对属于维护阶段的系统，通常日常需求比较多。这类需求最大的特点就是它会采用一种短、频、快的交互方式，需求量非常大，但是时效要求也很高。整体来说需求的规模是适中，不会像新鲜项目一样出现需要几个月半年甚至一年更长周期的一个交互过程。
这种方式下，现在团队通常会采用敏捷的研发模式，通过敏捷研发模式来获得干系人的快速反馈和持续参与。应对这种敏捷研发模式，我们的测试流程也做出相应的转变。虽然整体而言还是会分为两个阶段，从测试的需求分析设计到测试的执行，但是我们已经由需求驱动转变为了用户故事驱动，小批量快速验证并通过最终的迭代回归来保证迭代交互的可能性。
在整个迭代对应相应的用户故事，首先我们会建立针对迭代计划去建立整体的测试方案和测试策略。针对每一个用户故事去进行相应的测试设计与、展开相应的验证，但对于整个迭代后，在封板之后，我们也要进行一个明确的回归，回归结束之后进行一个迭代的整体验收，因为有了一个迭代明确的划分，让我们的需求排期也更加的清晰，对于我们每个迭代要做的事情可以更加有计划性，从而能够合理的安排资源，也方便我们去衡量整个过程的进度风险和质量的情况。
随着我们业务模式的一个融合度持续的提升，系统建设的复杂性也在不断增强，从而呈现出越来越多的系统关联、需求关联和测试关联。稳态和敏态的研发模式要交错。在这种情况下，我们既要保证各自功能独立运行的正确性，又要保证关联部分彼此交互的准确性，从而衍生出了双模并存的一个研发模式。
应对双模并存的研发模式，我们的流程也相应的做了一些改动，对于稳态开发的我们还是按部就班，从设计、功能测试、系统测试、用户验收，但对于敏态的我们还是面向用户故事，针对用户故事去进行相应的测试和验证，但同时要满足迭代的回归，保证迭代验收符合迭代计划的目标。
最后要进入一个整体的回归，无论系统建设是采用哪一种的研发模式，我们建立了版本的概念，通过以版本的方式，以集装箱的方式来进行一个整体的回归，整体的验证和整体的上线，从而实现了我们测试流程能够支持双模研发形态。
为了在双模研发生态下来全面的推进质量保障，测试也是实行了测试的左移和右移来推行整个测试的全程化。进入到这一阶段，我们由用户故事驱动的测试演进为业务驱动的测试。
在分析阶段，我们是要从用户、流程、影响等方面来积极的参与需求的理解和澄清，并且对需求的质量进行客观的评估，通过编写验收条件来确认需求的可测试性。所以我们在这一阶段也是采用了ATDD的思想，来明确产品验收的范围，风险、优先级。
进入了设计和开发阶段，我们要和开发伙伴共同梳理接口、数据模型、功能之间的对应关系，保证其符合业务逻辑。同时在这一阶段根据整个交付的特点来明确我们的测试计划。
进入到开发阶段之后，开发伙伴去进行相应的功能实现，而这一阶段我们依然会从用例和接口自动化等方面来开始我们的测试工作。同时我们也是深化技术应用来覆盖重点测试、关联测试，并且结合代码覆盖率的资金精准分析，让测试不再仅限于测试人员的活动，成为了每个阶段交付前都必须经过的保障活动。
在开发完成后，我们会与开发伙伴共同进入代码评审。在这一阶段我们会站在用户的角度去看代码的逻辑是否覆盖了相关的业务场景，同时我们也会对代码评审的问题进行一个跟踪闭环，事后通过问题的复盘来推进整个过程的改进。进入到测试阶段，除了之前的系统测试回归测试，最重要的是我们引入了探索性测试，通过交叉测试的方式来改变测试的固定思维，能够从用户角度出发发现更多的问题。同时我们在发布前和已发布，以测试右移的方式积极参与版本的评审，来避免代码的夹带积极参与线上的回验来保证线上的质量。
有了一个测试流程的演进之后，我们还需要做的一点就是要建立可复用的系统化的测试策略。这样的测试策略对测试团队的工作有重要的指导意义，它可以从测试资源、测试技术、方式方法、执行流程、风险评估等方面提供相应的指导原则，来告诉大家明确要测什么怎么测。而且这个系统化的测试策略，它是完全和系统特点、业务特点相符合，在我们敏捷快速迭代的方式下，可复用的方式能够大大缩短在整个测试计划阶段投入的资源。
通常我们建立测系统化的测试策略，也会从以下几方面进行考虑。我们采用的一些测试的方式，比如是会涉及到精准测试，还是做一些基于风险的优化，我们的人员安排是怎样？如何备份，如何交叉测试？采用的测试技术是否涉及到一些建模和一些挡板Mock，以及我们是否要实施自动化，实施自动化的策略是什么？它的主要发力点是在哪里？是针对接口还是针对测试数据？我们是关注静态还是动态，是会在回归引入自动化，还是在我们的日常迭代就引入自动化？
同时我们在整个测试设计方法上面也会考虑相应的组合，来以最少的资源覆盖最多的场景，以及在整个的测试层次流程，我们左移的一个程度，右移的程度，包括我们整个环境的准备。
在有了测试策略之后，其次就是要建立一个基于业务风险的测试分析。在测试执行之前很重要的一个阶段就是测试的分析和设计，基于测试分析和设计的结果来指导测试执行。如果我们不能在前期发现风险，要等到后期再进行返工，它的成本会非常的高。
我们如何来进行基于业务风险的测试分析，并把它落地到工具中？
首先我们在需求评审阶段就进行参与，要与相关方共同评估需求的业务风险。通常要求每一个需求要有明确的功能清单，针对功能清单里面的每一个点，要有单独的优先级和一个风险的评估。我们在进行设用例设计的时候，就是要对应到业务风险进行有效的覆盖，根据它的风险等级来建立需求和测试用例的一个映射关系。之后根据测试时间和业务风险来确定测试的范围和优先级，根据风险的覆盖来协助系统发布的一个决策。如何进行风险评估，就是针对每一个功能，从它的使用频率和失效影响上面来确定它的风险等级。一旦确定了风险等级之后，其实系统就会默认设置测试需求的优先级以及测试用例的优先级。
我们在进行测试的时候，有限的周期内、有限的资源下，肯定是会按照优先级去进行合理的分配，包括测试人员的能力不同，他所承担的测试优先级的测试用例也一定是不一样的。引入业务风险评估之后，系统也会根据每个功能点的风险权重来进行相关的关联和计算，从而对整个测试用例的执行进行一个有效的覆盖。
这个时候它所呈现的测试报告就不再是“我有100条案例完成了多少条，而是对于风险高的用例我完成了多少，发现的缺陷是怎样，对于严重程度高的缺陷，我的一个解决情况是怎样”对于发布的时候它就更加具有指导意义。大家会很清楚对于风险高的功能模块，现在的测试保障到了一个什么程度，它的完备度是不是已经具备了可上线的条件。对于风险程度低的可能我们没有测完，可能缺陷没有完全解决完，但只要大家认定这个风险非常低，上线之后不会带来很严重的业务影响，相关方决策之后也是可以进行一个上线的决定。
对于整个基于业务风险的测试分析，我们其实是有自己的一套模型，我们首先是基于刚刚提到的系统化的测试策略来决定我们风险策略。然后对风险的评估纳入到测试设计技术中，我们首先要形成基于头脑风暴的一个测试逻辑的分析题，也就是提炼我们的测试要点，通常是以思维导图的方式进行展现，之后再形成基于需求实力化的测试用例分析。在这一个阶段我们一般也会采用GWT的语言来说明它的前提条件是什么，由谁来执行，期望产生的结果是怎样。
为了保证整个测试流程裁剪的合理性，我们对整个测试过程也是采用了一个测试过程的审核以及测试结果审计相结合的方式，来对各项活动的产出物进行评估。同时它也采用了人工和自动工具相结合的方式，来保证我们整个测试阶段的一个产出。
在流程标准建立之后，下一步就是要工具赋能，我们的工具赋能主要是依托新的敏级四象限。其实对于测试四象限，相信大家都已经耳熟能详了，但是新的敏捷四象限它与传统有什么不同？我们可以看到它更强调测试驱动，更强调根因分析，更加强调我们在业务层是用来构建产品质量，而在技术层分别从业务层和技术层构建产品质量来评价产品质量。
通过业务层的ATDD测试驱动设计，探索性测试迭代评审等构建产品质量，以及在技术层的CR评审分析，BVT、契约驱动测试、线上的监控与分析等来评价产品质量。基于新的敏捷测试四象限也推导出了我们分层的自动化测试模型。我们在这个模型里面的重点发力点也是推行我们的接口测试和契约测试。
在整个自动化测试的策略之下，我们也是建立了统一的自动化测试服务框架。在整个框架中也可以看出我们将数据构造、日志分析、报告的可视化、环境的配置发布等都封装成了底层的服务，来共同支撑测试设计和测试执行这两个重要的核心工作流，从而对外提供web测试服务、APP兼容测试、精准测试等。
其中兼容测试我们主要是用于APP端，它一般会包括设备的兼容、操作系统、屏幕、网络，包括对于不同人群兼容。精准测试是建立在代码覆盖率的一个分析基础之上，包括关联性的分析以及代码与案例的映射，并且我们整个的自动化模型会对外提供一个统一的自动化服务窗口，让大家把相关的工具也整体只集合到我们的自动化平台上面，为大家整个测试体系的落地提供了非常好的工具支撑。
通过流程标准化和工具赋能，我们实现了测试体系从人治到法治的过程，接下来就要通过数字驱动推动改进来建立人员能力地图，实现从法治到自治的过程。
在这个过程里面，第一方面就是关于测试的度量体系。其实我们做度量也是有明确的原则，而且我们度量的维度也是考虑了整个的趋势，不同程度的下钻会提供相应的清单，帮助大家去做一些定制化的度量分析，同时也会通过指标反映出各个阶段的相关性，进行一个具体的分析。而我们度量的目标也是期望达到风险可观测，问题可跟踪，结果可量化。
我们的度量体系也是按照测试的三个部分，核心的工作阶段，从测试设计、执行和发布，这是一个横向的区分。在纵向我们其实是考虑了质量和效率以及交付能力这三个方面。
我们从过程方面包含了对设计执行和发布的衡量，从结果方面也提到了刚才的三个方面，在不同阶段的测试活动都是以符合其阶段特点的北极星指标为关键的导向，通过周度、月度等不同频率的观测分析来探测风险，跟踪过程评估结果。
同时我们会定期的将指标晾晒，会有统一的一个指标窗口看板。对于开发人员，我们目前非常关注人员效能的衡量，会采用开发当量等方式。对于测试也一样，我们不仅关注过程、关注交互，同时我们也会关注我们整个人员的利用率，所以对于测试人员我们也是定义了测试当量来考核我们的测试效能。
我们测试当量如何应用才能避免大家出现错误的导向？
首先测试当量会覆盖测试工作的方方面面，不会单纯的以缺陷为导向或者单纯的以数量为导向，倡导大家能够全方位的发展。
第二，我们的测试当量在应用的过程中更多的是用于末位淘汰。所以大家只需要按照正常的工作去做，无需把它作为一个相互攀比的考核分，这样也避免了大家过多的关注数字，而忽略了个人的成长。
第三，我们整个的测试当量在设计过程中并没有对它的分数测试设置上限，而这一目的也是为了能够驱动大家不断的上升，来告诉大家我们的人员能力有一个很大的上升空间，可以不断的突破自我，不断的自我创新。
在人员能力方面，我们从最初按照角色和岗位划分的金字塔结构，演进为横向贯穿选举质量意识，纵向叠加领域的专项知识。在我们测试这边也非常注重我们的一个持续学习，从测试理论的建设到行业化的分析指南学习，自动化的测试工具及方法论，同时我们还需要有一定的编程基础才能够深化技术应用以及我们的数据分析，才能够让我们的度量体系真正来推动过程的改进。
通过我们的新人培养，导师引领、体系化的学习工作坊以及差异化的case study等分层的培训模型，我们也建立了我们自己的业务专家、体系专家和工程专家，从而完善了人员画像，也构建了我们整个测试团队人员能力地图，不断的强化我们的领域专项，也在各个团队之间拉通了互联共享。
三、测试数字化
经过了长时间的测试体系建设之后，我们现在也在努力向整个数字化的转型发展。随着数字化时代的到来，让企业在实现高效和高质的同时，也可以满足个性化的体验需求。
泰康数字化测试体系的建设也是围绕质量效率和体验来深化技术创新，深入全流程的质量保障，建立以1234为核心的数字化测试体系底层逻辑分别代表什么？
一是一个中心即以业务为中心。
二是两个价值要体现我们的测试业务价值和技术价值。
三是三个阶段，就是从最初的发现缺陷进入到了质量保证，下一个阶段就是全面的质量推进。
四是有4个基本点，测试的左移、测试右移、全员参与和快速反馈，通过持续高效有价值的改进来实现精益测试转型。
同时借助我们现在研发全流程的质量优化项目，来实现全生命周期的打通，以管、帮、带的方式，我们在流程规范上面以用户为中心，来建立适应多模式的研发管理体系，同时来贴合公司发展的需要持续优化，及时发现流程中的等待浪费问题来推动改进。
在工具建设方面，我们一方面向业界头部企业学习，引入相关的优秀实践，同时也结合泰康的实际情况来落地，以流程规范为载体，寻求最高效的工具落地途径。同时我们还提供相应的专家服务来守底线、引实践、做工具，形成点面结合的一个推动机制，收集反馈改进建议，来促进工具和规范的持续完善。
相信通过我们泰康全体科技团队的努力，通过我们整个质量体系的不断完善，会为泰康的科技建立一个强大的质量护城河。我今天的分享到此结束，谢谢大家。
演讲嘉宾
苏梦，历经9年 IBM&Oracle研发及项目管理实战锤炼，PMP，CSM，TMMi Professional认证，2019年加入泰康科技这片沃土，从专业化、数字化的测试管理建设拓展到规范化、体系化的研发全流程质量管理建设，0-1初步建立了泰康IT质量管理体系和团队。
资料获取
演讲PPT分享：点击：链接 获取演讲PPT（百度网盘提取码：iSQE）
演讲视频回放：想了解更多精彩内容，欢迎点击：链接 查看查看直播回放