如今随着用户对产品质量和体验的要求越来越高，很多公司都建立了自已的测试组织，但随着产品的迭代周期越来越短，客户对产品交付质量的要求越来越高，软件测试团队的管理成了各公司研发部门的难题，主要面临的问题如下：
- 开发交付的软件代码，质量差，测试跟着做集成，上线交付质量无底线，是开发的责任还是算测试的漏测？
- 很多项目经理都是来自开发团队，进度优先的文化比较突出，如果在进度和质量中取得平衡？
- 测试人员的职业通道较窄，工作三到五年之后会遇到职业瓶颈期，如何解决测试人员的职业通道问题？
- 测试人员的工作质量是由开发说了算？还是由客户说了算？谁来考核测试人员？
- 测试团队是研发部门离职率最高的群体，如何保证测试团队的稳定性？
- 测试的质量与测试人员的素质和态度密切相关，如果保证测试人员的积极性？如何激励？
- 开发人员通常对测试人员有抵触情绪，如何消除？
- 如何进行开发团队和测试团队的融合？
根据深圳市共创力研发咨询对国内4000多家产品研发型企业的咨询和培训，总结出目前在国内测试的组织形式主要有以下三种：
- 研发人员和测试人员不属于同一部门（开发和测试分开）
这种组织架构的优势在于：
1）测试人员和研发人员分开有利于测试人员的独立性，测试流程和规范可以很好的得到执行；
2）测试人员和研发人员分开向不同的领导汇报可以赋予测试人员更多的话语权，测试策略和测试计划可以顺利执行。
但这种组织架构也有两个缺点：
1）测试如果跟开发分开,测试人员对于产品业务知识的理解很难深入,测试和研发之间有距离感；
2）测试人员的归宿感的问题，如果测试人员不跟开发人员在一个团队，测试人员感觉被边缘化,没有地位，对公司文化的认可度会受到影响；
如何解决这两个问题呢？对于业务的问题建议多组织产品业务方面的培训，尤其是新产品,新业务的培训，另一方面对于测试团队的归宿感问题建议测试部门多组织一些与开发部门的互动，如拓展、聚餐或把座位按排到一起工作，增强与开发团队的粘性，避免开发人员孤立测试人员;测试部门经理也要多组织部门内部的分享和会议，增强部门的凝聚力。
建议在测试团队组建初期采用此模式，以严格测试开发部门的产品，把好质量关。
- 研发人员和测试人员属于同一部门（测试和开发团队融合）
这种组织形式是当测试团队的成熟度到达一定的程度后，开发和测试同属于一个团队，这种组织形式的优劣势恰恰与第一种方式相反：优势将是测试对业务掌握会较快，另外测试人员的归宿感也较强；劣势是测试人员有可能不能保持测试的独立性，另外测试人员的话语权有可能受到来自研发PM的压制，所以当开发和测试人员融合后这两个部门公共的领导对于质量和进度的权衡和把握尤为重要，将会影响测试人员在公司的地位和话语权。
以上这种形式针对测试能力比较成熟的企业，如华为和迈瑞等，测试起步阶段都是采用第一种组织形式，测试团队成熟后采用的是第二种组织形式。无论是采用第一种组织模式还是第二种组织模式，研发部门负责人对产品质量的意识和态度起决定性的作用，因为质量是一把手工程，如果研发部门负责人对质量的认识远远落后于进度，那么无论采用哪种模式测试团队的效果都不会太好。目前国内采用两种组织形式的企业都有，视企业的具体产品和组织架构而定，在如今敏捷开发大环境下，软件测试团队则比较偏向于二者融合。
- 测试人员属于第三方部门
这种组织形式一般适用于测试团队过渡期，企业如果现在没有专门的测试团队，可以把测试组织挂靠在运作管理部或项目管理部，但这种组织形式不太适合测试人员的工作开展。因为作为测试人员既是运动员，又是裁判员，很难与研发人员进行融合，所以在万不得已的情况下，不要采用此种组织架构。
以上是测试组织在公司整体组织架构中的常见三种组织形式，那么测试组织内部的人员如何进行分工呢？以下是一个公司典型的测试组织架构：（著名通信企业）
团队内部成员的分工：
• 产品测试组内部，建议如下：
– 测试经理：负责部门总体事务，人员培训培养与绩效考核、工作计划安排与监控等
– TSE或测试技术负责人：主要负责测试技术建设、积累、应用等相关工作，拉通项目间的共享；与上级部门的“测试技术组”直接对接
– DFX测试、自动化测试：相关测试技术工作规划、方法引入、执行监控、经验总结积累等，
– 产品测试方案评审，重点项目参与
– 测试资产积累：测试分析设计经验、测试工具应用经验、测试用例基线库建设等
– 例行网上问题分析
– 例行测试技术方法交流
– 解决方案测试小组（不一定有独立的测试小组，但活动应该不能少）
– 负责SIT测试，如多个项目的集成测试
– 面向客户的测试，如体验测试、验收测试等
自动化测试小组（视产品自动化需求而定）
• 成员组成
– 来自各项目测试小组中负责自动化测试的人员，组成虚拟小组
– 刚开始不建议全员掌握自动化测试能力，由少量人员先进行探索，针对关键特性的基本功能进行自动化测试，可以用于冒烟测试
– 不用专职于自动化测试，需要兼顾部分特性测试职责，以加强对系统的理解和熟悉
• 职责
– 自动化测试可测试性需求分析，分两部分
» 为了能进行自动化测试，产品中需要实现哪些相关可测试性需求
» 开源工具或商用工具无法完全满足需求时，可向上一级“测试工具组”提测试工具开发方面的需求
– 自动化测试工具引入及应用
– 自动化测试用例编写、调试、维护
– 自动化测试经验总结、例行交流（由TSE组织）等
DFX测试小组
• 成员组成
– 来自各项目测试小组中负责DFX测试的人员，组成虚拟小组
– 刚开始时DFX测试建议由专人负责，但不一定是专职，DFX测试小组成员同时可以做其他特性的测试
– DFX测试技术尚不成熟时，不建议要求所有测试人员都掌握；成熟后可以形成指导书、checklist等进行逐步推广
• 职责
– DFX测试基线准备，一般与产品DFX设计基线相对应，包括测试方法、测试用例等
– DFX测试执行
– DFX测试经验积累：每个项目结束后最好都有总结分享
– DFX测试经验例行交流：由TSE组织
测试技术组工作职责和范围
• 业界最新测试技术跟踪
• 公司内测试技术需求分析
– 与产品测试组内的TSE建立例行交流机制，收集产品测试技术、方法手段方面的需求，主要包括
» 测试分析设计方法
» 自动化测试可行性、适用性分析
» DFX测试设计、测试执行方法与工具需求等
• 测试技术方法研究、推广应用
– 结合业界及公司内产品测试需求，选择最合适的测试技术方法进行研究、试用，有一定效果后推广应用
• 与架构设计部对接，形成测试相关
– 架构设计部一般来说会有一些设计需求基线，如可靠性、安全性、可服务性等方面的统一要求，甚至直接以CBB方式在产品间共享，测试技术组可以在此基础上形成测试相关的基线，便于在不同产品测试组内分享
• 流程优化相关工作
– 当公司内产品开发流程优化时，以测试的专业视角参加进去，合理安排测试相关活动
• 任职资格相关工作
– 测试相关任职资格标准建设
– 测试相关任职资格执行：如技能鉴定、任职资格答辩等
测试工具组的职责范围：
• 公司内产品测试工具需求分析
– 与产品测试组内的TSE建立例行交流机制，收集产品在测试工具方面的需求等
• 测试工具引入或开发、试用、推广等
– 分析业界已有开源或商用工具，选择适合本公司的测试工具进行试用
– 如开源或商用工具无法满足产品测试需求，必须辅助工具测试的情况下，测试工具组可以开发或完善相关工具，以满足实际产品测试需求
– 某种测试工具应用成熟后，可以由测试工具组在不同产品间进行推广
• 对接“测试技术组”，提前规划测试工具相关工作
测试人员培训培养体系建设
• 建议分两个方面
– 流程、工作规范化方面
» 如测试流程（PTM）、测试Mini培训等，目的是让测试人员知道在什么阶段应该做什么事，有哪些标准化的工作模板、方法等可以使用
» 建议在公司或产品线级别的测试部组织相关培训
– 实际工作相关的技能方面
» 具体到某个产品、某个特性该怎么做测试设计、测试执行等方面的内容，目的是让测试人员工作效率更高、测试更加深入
» 建议在产品测试组级别组织相关培训，培训材料主要来自于日常工作中的经验总结（如测试案例、指导书、checklist等都可以，甚至一篇好的测试方案、一组好的测试用例也可以）
标签：高效,团队,DFX,组织,测试人员,测试,测试工具,打造 From： https://www.cnblogs.com/mikeyond/p/18431229