聊一聊测试架构演进的曲折之路

        近期公司的测试团队需要重新组织安排，本着谦虚谨慎的态度，我从网上翻找了一下相关的资料，高质量的资料比较少，看到的大部分是比较宽泛的谈论。于是便想着梳理一下自己这几年的工作经历，把经验教训摘出来，然后再加一些同行的先进办法，搞一套完善一点的测试体系。这一梳理才发现，自己已经走过的了一条曲折的测试道路，现在把它分享出来，希望对读到的人有所裨益。

        一、“原始”阶段

        这个阶段可以追溯到最早的校内实验室阶段。自己当时还是本科生，最有代表性的项目是全国大学生电子设计竞赛。那时候脑子里还没有专业测试相关的概念，整个项目就是老师讲一个大体的方案，然后学生一个设计电路板、一个写代码，然后两个人一起调试功能，功能出来了基本上也就到时间该提交东西了，最后小组一起去演示考评。

        这个阶段的测试还仅限于功能体调试和演示，所以用现在的眼光，从专业测试的角度来看，这是单个的设计人员自己做测试，我把它比喻成测试架构演进过程中的最“原始”阶段。

        二、“小打小闹”阶段

       这个阶段还是在校内的实验室。比较典型的是一个大创项目，当时是要设计一套编程工具。这时候团队的稳定人员已经达到的6个以上了，大家就会交叉着做一些测试工作。比如我刚用开发出来的工具，实现了一个电子节气门的功能，这时候就会让另外一个人过来看一看试一试，收集一些评价。虽然说在单个设计物上面，做到了设计人员和测试人员的分立，但是这个“测试人员”毕竟还是设计人员中的一个，也没有明确的测试立场和独立的测试思维。这种测试模式我把它比喻成测试架构演进过程中的“小打小闹”阶段。

        三、“小米加步枪”阶段

        这个阶段是在一个企业的研发部门。自己当时研究生还没有毕业，作为一名测试工程师，参与了几个控制器的开发项目。这时候跟我一起的还有另外三、四个测试工程师，已经形成了一个专门的测试小组，核心的工作就是做测试。这时候的测试工作，从横向和纵向展开的矩阵如下所示：

	写测试方案	写测试程序	去外场做试验	整理测试数据和报告
缺陷验证试验	/	/	⚫	⚫
电气负荷试验	⚫	⚫	⚫	⚫
电磁兼容试验	⚫	⚫	⚫	⚫
气候负荷试验	⚫	⚫	⚫	⚫
机械负荷试验	⚫	⚫	⚫	⚫
耐久寿命试验	⚫	⚫	⚫	⚫

        这个阶段的测试人员，虽然形成了小组，有了专门的工作内容，但是毕竟还存在于设计部门内部，大部分工作都依设计规划而定，没有自己的工作流程。而且小组内部没有具体分工，也没有专门的设备设施做支撑，更没有测试角色的话语权，所以只是一种最初级的测试架构。这个阶段的测试模式，我把它比喻成“小米加步枪”式的测试架构。

        四、“摩托化部队”阶段

        这个阶段的测试部门是在企业的质量中心下面。当时自己作为测试团队的一员，亲历了测试架构从第三阶段向第四阶段演进的始末。这个时候原本位于几个设计部门的测试小组分别走出来，共同合并为了一个大约15人的测试部门，归入质量中心。这个阶段的测试工作矩阵如下：

	写测试方案	自己内部做试验	出报告
软件试验	⚫	⚫	⚫
电性能试验	⚫	⚫	⚫
机械液压试验	⚫	⚫	⚫

        这时候测试人员的工作内容有了更细致的划分，工作流程也规范了一些，有了专门的设施设备做支撑，也有了测试角度的话语权，算是一种比相对较高级的测试架构，所以可以比喻成一个“摩托化部队”。这个阶段还有一个重要的特征是，测试团队中出现了管理者的角色。这个角色从测试执行的试验任务中解放了出来，开始思考整个测试工作的发展问题，承担起了培养测试团队、写企业标准、画故障树、写FEMA、做性能仿真、挖掘设计薄弱、做回归分析、打测试补丁、研究电子可靠性、机械可靠性、做测试系统分析等工作。正是这个管理者角色的工作，把整个测试架构的形态推上了更高的一个台阶。但是由于质量工作的定位，与设计部门拉开了太大的距离，过度和衔接出现了一些问题，一部分原本来自设计部门的技术人员离开后，早期在测试上面的规划和设想便不了了之了。

        五、“骑兵连”阶段

        这个阶段的测试团队，是企业设计部门中的一个测试小组，是介于前面第三阶段和第四阶段之间的一种中间形态。工作特点和组织形式兼备了设计部门的技术性和质量部门的严谨性，团队规模也是15人左右。这个阶段的测试工作矩阵如下：

	设计分析	项目测试框架	测试成本预估	测试用例	测试程序和测试脚本	做测试	提交缺陷和出报告
功能调试	⚫	/	/	/	/	⚫	⚫
底层软件单元测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
底层网络接口测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
衔接件软件单元测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
衔接件网络接口测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
CAN性能测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
诊断测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
OTA升级测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
电磁兼容测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
电气负荷测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
气候负荷测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
机械负荷测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
耐久寿命测试	⚫	⚫	⚫	⚫	⚫	⚫	⚫
售后故障测试	⚫	/	/	/	⚫	⚫	⚫

        这时候的测试工作，在横向和纵向都拓宽和拉长了很多，测试工程师也开始细分。做软件测试的人就不去搞硬件测试，做测试开发的人就不去做测试执行。其中最重要的测试管理的人，也不去搞很发散的东西，而是专注于项目测试的框架、测试团队培养、测试设备建设、测试数据库维护、测试流程规范化、测试标准集编纂、新测试标准引入、新测试板块导入、新测试项开发、新测试技术培训、可靠性工程宣贯、等等这些非常内化的东西。这样的测试团队，因为工作更具象了，所以也更专注了，虽然不是很高大上，但是效率还是比较高的，所以可以比喻成一个“骑兵连”。

        六、“海军陆战队”阶段

       这个阶段是未来要长期规划的一个新形态，期望的目标是测试工作既不依附于设计部门，也不拘泥于质量部门，一种独立的第三方形态。测试团队内部的稳定规模至少要达到25人以上，每个产品类型的测试团队中需要具备一名测试架构工程师，每个模块的测试小组中需要具备一名测试开发工程师和若干名测试工程师，每个人都有自己明确的分工和要求。如果某个产品类型与已有的产品有重叠的测试模块，就可以与其他产品线共用测试小组，但是至少要有一名专门的测试架构工程师。大体的测试架构应该是如下这样的三维状态：

         这种形态的测试部门，要求有足够的设施设备资源做基础支撑，测试团队的每个人员对产品的原理和应用要有足够深入的理解，对相应的法规和标准要足够的熟悉，并持续维持高度的技术专业性。这种宽领域的知识和技能储备，我把他比喻成了“海军陆战队”。测试团队的管理者要有足够的话语权，能够争取到上级的足够重视和支持投入，能协调到足够的外部配合，能建立一套科学的人才考核制度来推动整个部门的发展车轮向前滚动。

        这样的测试架构才能够保持自己的正常节奏，真正发挥出测试的本质作用——早期充分挖掘问题，提高产品可靠性，最大程度降低后期风险。

        版权声明：原创文章，转载请注明出处与链接，违者必究！