在不同的企业里，质量团队的阵型也有着比较大的区别。比如有的团队归属于各个业务的研发总监，有的团队则归属于统一的测试总监；再比如有的团队有专门的自动化、性能、平台开发小组，有的团队则是由业务测试兼做专项类的工作。为什么团队阵型要这么设计？这些阵型又存在哪些优缺点？这篇文章就来做个汇总整理。
01. 集中模式
集中模式是指研发与测试在企业层面属于并立的两个大团队，由各自的唯一负责人统一领导。
集中模式有以下优点：
质量团队有较高的独立性，能够站在比较客观的位置上处理问题。
测试资源集中管理，当业务发生变化时可以快速进行调整，提升资源利用率。
便于聚集力量做平台研发或技术攻关，带动整体团队持续向上突破。
它也有以下缺点：
统一制定的政策，无法完美兼容不同业务的差异性，落地效果不如预期。
各个业务的测试诉求，难以被测试负责人全面考虑，资源分配不合理。
各个测试子团队之间容易产生竞争关系，导致大范围普遍内卷。
02.分散模式
分散模式是指测试分布在不同的业务线内，没有共同的最高负责人，分别向各自的业务研发负责人汇报。
分散模式有以下优点：
研发与测试的结合更为紧密，各个业务可以制定符合自身现状的质量策略。
允许业务自主决策测试资源的分配，双方的目标和预期更为一致。
测试角色的汇报链路较短，在业务上的实际产出和表现评估更为准确。
它也有以下缺点：
质量团队容易让步于研发目标，话语权相对较轻，影响最终质量结果。
测试资源难以跨团队协调，不能根据业务松紧度做出灵活调配。
各个测试子团队采用不同的技术方案，存在重复建设，造成资源浪费。
03.中台模式
集中模式和分散模式各有一些优缺点，很难说哪个就一定更好，所以我们经常可以看见一些企业的质量团队是分了又合，合了又分。
还有一种解法是质量中台模式，即定义一个中台部门，统一管理测试资源，并提供测试技术支持。测试主管则一般会采用双线汇报方式（一实一虚），以保证在业务领域和专业领域都有比较好的投入。
中台模式可以最大限度地保留测试的独立性，又能很好地与业务结合，因此被很多大企业采用。但是这种模式也不是没有缺点，之前我一直在强调，技术终究是要服务于业务的，但是中台恰恰在对二者进行剥离。
对于业务测试而言，由于缺少技术层面的锻炼，业务质量也难以深入；对于中台测试而言，同样缺少业务层面的接触，技术实现往往脱离业务。长此以往，双方的成长均会比较有限，人员流动性也比较大，因此近几年关于中台模式的质疑声也越来越多。
于是后来又出现了一种基于传统中台模式的演进模式，叫“轻中台”或“薄中台”，将测试开发的职能下放到业务线，移除了单一的业务测试角色（或转移到外包），中台部门只保留项目管理、测试架构等职能。
轻中台是当前比较流行的一种模式，相对也符合敏捷研发团队的调性，所以很多团队都在往这个方向去走。当然，小微型团队也不太需要这么复杂的模型，不管大家当前是什么模式，能够让团队跑得又好又快就行。
最后：下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
软件测试技术交流群社：786229024（里面还有工作内推机会，毕竟我们是关系社会。）软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
面试文档获取方式：
