转载：https://www.cnblogs.com/imyalost/p/15116840.html
前言
从事软件测试相关工作七年，做过功能测试、自动化测试、测试开发、性能测试、专项测试，也干过一段时间技术管理。
近几年随着行业成熟度的发展，对软件测试也有了更高的要求，很多测试团队开始转变为质量保障团队。
如何从质量保障的维度去更好的为业务提供支持，是我一直在思考的事情。
整理了自己的很多笔记，结合我在工作中遇到的种种场景，我梳理出了下面这张质量保障体系思维导图，供大家参考。
思维导图
三大体系
组织
愿景
所谓的愿景，就是长期规划，我们要到哪里去的问题。一个组织或者团队，是一定要有愿景的。在软件质量保障领域，所谓的愿景概括来说就四个字：保质提效。
保质，就是在日常交付中保障软件质量，并且在长期发展过程中，不断提高软件的质量。如何评估质量是否是稳定且不断提升的，就需要引入评估体系，用事实、结果、背后的分析逻辑和数据来证明。
提效，很好理解，提高效率。怎么提高效率呢？引入ROI体系，从交付时间、耗用资源、团队成长方面着手。
目标
有了愿景，还要将其拆分为不同的目标。行业在变，组织架构在变，因此目标也要跟随整体的变化而调整。
不同的企业在不同阶段有不同的侧重点和诉求。你不能要求一个初创企业要啥啥都有，也不能要求BAT啥都凑合。这是一个平衡和抉择的过程，可以参考CMMI模型来思考这一点。
规则
这里的规则不是强制要求大家一定要做什么，而是为了避免某些方式对团队和企业带来不好的影响。常见的规则比如：周报、信息同步机制、反馈机制
文化
谈到文化这一块，一直是很务虚的东西，很多同学对之嗤之以鼻，2020年之前我也是这么想的。
20年读了一本书：《重新定义公司：Google是如何运营的》。里面对企业文化这一部分做了很经典的解释：企业文化就是指导员工面临艰难选择时，做正确的选择。
管理
团队管理方面，我将其分为了下面四个体系，每个体系都包含不同的内容。
相关内容，可参考我之前的文章：从技术专家到技术管理，我对管理的思考
业务体系
如果团队规模较小，业务也不复杂，可以暂时不用拆分。但是当人数超过10人&业务开始划分不同团队时候，就要考虑做业务拆分了。
这里的业务拆分指的是根据组织架构将测试同学分为不同的组，每个组有一个小组长或team leader，提高管理效率，做好信息同步和反馈机制。
避免自己成为团队的瓶颈，从繁杂的管理中抽身出来，去思考并解决更高维度的问题。
资源体系
在团队管理中，无论是人力、设备还是时间，都可以纳入资源管理体系中。我将其分为了如下三个部分：
1、人力模型
- 新人目标：新人入职如何落地？如何快速适应业务迭代节奏？如何设定合理的目标来达成预期结果？
- 转正述职：招聘、新人培养都需要成本投入，设定合理明确的转正评估机制，结合上述的新人目标，可以帮助新人更好的落地。
2、能力模型
- 成长模型：工作一方面为了金钱物质回报，另一方面也是希望能够借助平台获得自我成长。设定成长目标和模型，可以帮助员工在不同的阶段知道自己该向什么方向努力，达成不同阶段的不同目标，这是没一个管理者都需要考虑的事情。
- 胜任力模型：一个团队的组织结构，从初级的倒T型，经过金字塔模型，最终演变成纺锥型。在不同阶段，随着组织结构的演变，处在不同阶段和层级的员工，需要设定不同的级别和胜任评估体系，助力团队跟随公司不断发展，适应组织结构的变化。一般来说，可以从工作经验、技术、业务熟悉度、项目推动能力、沟通协同方面来设定评估指标。
3、资产管理
- 云端资产：现在大多数互联网公司，都采用了云服务。对于质量保障团队来说，测试环境及内部自建技术平台涉及的云端资产，都需要通过一定的手段管理起来。当然一般这种事在运维团队，有CMDB体系来进行管理，可进行参考。
- 硬件资产：这里的硬件资产包括移动端测试机&pad等设备，当然可能也包括用来做兼容测试而采购的相关服务等设施。还有一点，员工办公所使用的包含电脑显示器等设备，一般会有IT部门来专门登记管理。如果没有，建议做好统计，便于员工入离职交接等。
知识体系
这里的知识体系，主要指的是团队内部的能力建设和沉淀，主要包含如下几个方面：
1、技术博客
无论是工作职场中还是和同行交流中，我一向是比较鼓励大家写技术博客的。
这样无论是对个人知识的梳理总结，还是团队的技术能力沉淀都是有很大帮助的。长期以往坚持下来，还能形成品牌向外宣传，这也是吸引优秀候选人的一个方式。
2、业务串讲：前面提到随着企业的发展，业务规模越来越大也越来越复杂，业务串讲就显得很有必要。优点如下：
- 帮助不同team的同学了解不同的业务，便于日常工作理解；
- 遇到不同团队协同工作时，更明确交接的业务边界，提供沟通效率；
- 沉淀成业务知识库，可以让其他团队的同学&新入职的同学快速了解，离入职交接也更方便；
3、内部分享：这里的内部分享，指的是技术部门内部，上述的技术博客和业务串讲&知识库，都可以作为分享的素材来宣讲。
一方面可以让更多的同学了解到不同的知识，另一方面加深团队的影响力，这样有助于日常工作的开展。也能在一定程度上培养团队同学的沟通和表达能力。
4、外部培训：这个主要指下面几方面：
- 联合开源社区，合作举办技术沙龙、座谈会等类似的活动；
- 重量级的技术大会上做主题分享，主要目的是价值宣导和品牌影响力建设；
评估体系
如何理解这里的评估体系？围绕上文提到的保质提效相关的点，来分类进行评估。
1、问题管理
- 测试过程中遇到的BUG，分门别类，阶段性的总结梳理，输出质量保障参考手册/SOP；
2、版本管理
- 版本管理主要涵盖每个版本的服务发版次数、冒烟通过率、bug的reopen率、上线质量等因素。每个版本结束，除了向上做汇报，内部的复盘总结优化，也是很重要的。
3、项目管理
- 这里的项目管理，可以理解为PMO这个岗位做的一些事情，包括进度、风险、资源、deadline等因素。实际上无论是版本发布、和版本迭代同步进行的跨版本需求以及内部的一些独立项目，都可以采用这种方式来管理，总体上还是为了提高资源利用率以及风险前置。
4、效率管理
- 效率管理，我们之前的做法，一方面是通过调查问卷的方式，在部门内部开展调查，获取日常工作中影响工作效率的点，归纳汇总进行专项优化。另一方面，随着团队规模的不断扩大，整体的效率问题也会变成团队成长的一大问题，需要时刻重视。
专项
自动化体系
自动化体系的建设，目前来说在绝大多数稍有规模的互联网公司，都有不同的应用。
有UI自动化、APP自动化、接口自动化、单测自动化、埋点自动化以及自动化打包发布校验等方式。
最初的目标都是提高效率，降低手工的成本，让工作的个体突出发挥自己的思考能力，而不是手工的体力劳动。
在自动化体系建设中，主要需要考虑如下几点：
- 场景&用例&执行：这里需要注意的是场景的覆盖、用例的筛选以及执行效率；
- 框架&数据&CICD：人多了，需要注意避免团队内部造轮子，撸很多自动化框架。我个人对这点的理解是有成熟开源框架的，别自己造轮子。内部已有的，评估是否需要优化，而不是推到重构。自动化体系中，CICD是至关重要的一环，别忘记自动化的初衷。
- 提效&反馈&参与：自动化最终还是要解决的是效率问题，如上文提到的效率管理，需要持续不断的获得反馈，然后改进优化。说到参与，很多公司是自动化和功能测试工程师做了区分，实际上如果为了团队的整体成长，需要全员参与进来，有参与感，员工才能有收获和满足感。否则大部分人只靠工作本身的内容，是很难做到主动提升自己的。
防资损体系
什么叫资损？造成公司&客户资产损失的都算。比如公司发优惠券，多发且被用户使用了，造成公司成本支出。
比如用户的优惠券满足场景但无法在支付中使用，用户有了资损，实际上还是公司买单。还有部分舆情方面的东西，比如某个外部消息导致公司上了热搜，外部对公司的评价变差，对企业品牌造成不良影响。
我们之前的做法是线上监控及时告警，专人专群处理。还有线上涉及资损的场景进行针对性校验，尽可能降低资损的成本以及造成的影响。
质量大盘体系
这里的质量大盘，大家理解为一个可视化的监控即可。即把上面我们提到的各项规则和措施，通过数据量化的方式管控起来，便于做决策。
性能测试体系
性能测试体系，由于之前的文章已经详细介绍过，这里不过多赘述，大家可以参考之前的文章。
文章链接：性能测试体系建设演进之路
稳定性治理体系
稳定性是一个很大的范畴，在质量保障体系中，稳定性的建设，主要集中在如下几点：
- 测试过程监控（如自动化通过率&冒烟通过率&性能容量变化趋势等）
- 测试环境稳定性治理（特别是有多套环境多个项目版本交叉使用以及频繁发布）
- 线上服务可用性监控（质量保障不仅只关注测试环境，线上的稳定性也至关重要）
写在最后
总感觉自己写了很多，又好像有很多内容无法一一表达。关于本篇文章中提到的部分内容，如稳定性治理，会在后续的文章中进行详细介绍。
标签：体系,管理,保障体系,质量,测试,自动化,软件,团队 From： https://www.cnblogs.com/ceshi2016/p/17233992.html