电控测试团队建设回顾

前言

初写本文时还是18年8月，那时候刚担任测试部门经理，而由于公司迁址，大部分测试同事未能继续留在团队。虽通过内推快速补充了2名，测试团队仍旧很小，并需要磨合，在自己摸索的过程中，从网上看到一篇不错的关于测试团队建设的文章，当时只是简单转了下，但可惜2年过去了貌似也没看到作者的下篇，而且原文仅涉及HiL测试团队并不全面，于是结合自身经验和思考重写一遍。

团队目标定义

首先要想明白的问题，即为什么要成立测试团队，为了达成什么样的效果，为什么不让开发人员自测或者在开发团队中安排测试角色甚至是直接外包出去。撇开行业、公司及成本等外在因素，大部分的原因无外乎是提高产品质量（少数原因是为了凑数给投资方看？），好了，这是大领导的需求。下面该是测试团队负责人要做的事情了，细化需求成为可落地的目标。以我自己当时经历为例，要打造一个“可以实现A-SPICE正向开发的测试流程，满足内需甚至具备外接项目能力的测试团队”。好，这也还是一个比较笼统的目标，还得因地制宜地具体分析：

1. A-SPICE类似汽车行业的CMMI，基于V流程开发，包含单元、集成、系统等几大阶段，强调需求、实现、验证之间的追溯性。而且各阶段的测试环境差异大（单元在PC，集成在负载箱+HiL，系统在HiL+发动机/整车），并且基本上都是并行在做的：比如做单元测试的同时要搭建HiL环境；做整车系统测试的时候，下一版本的软件可能已经开始单元测试了……同一个人是没法全做下来的，因此相应的需要划分虚拟子团队，不同子团队负责不同阶段的任务。
2. 要具备独立测试能力，那说明不能简单地把测试当任务完成，要有一定的深度，不仅能够发现问题，还要追溯上游减少下次开发的质量成本，人员需要一定基础要求，团队培训及测试资源也需要保障，整体能力呈阶梯分布不断层。
3. 人数上不强制要求具体数字，根据项目及开发团队规模做弹性调整，团队肯定是逐步扩大的，发展太快反而带来磨合困难及培训跟不上的问题。

团队构建规划

其实上一章节已经对团队构成做了初步的规划，这里举例细化。假设岗开始遇到的场景和我当初比较类似，团队新成立不到5人，需要覆盖的项目差不多3-4个：项目A开发完成度较高，接近OTS，可预见后续的维护工作量相当大；项目B正在稳定开发中，测试介入不久；项目C在前期准备阶段，策划中，测试参与了解项目目标及做相应准备；其他非产品类项目若干，投入相对小。对应的软硬件开发团队大概在20人左右，且在快速增长。进一步展开项目测试需求：

• 项目A虽然硬件设计已冻结，软件功能大多也已实现，但受限开发条件和进度，测试并不充分，只做过单元测试和负载箱上的开环功能测试，台架上通过了基础标定。需要重点使用HiL验证功能，并且由于公司战略需求需要小批量投放市场，所以整车测试也要提前开展起来。由于优先级最高，所以在这个项目需要投入最高的关注度。
• 项目B为项目A的升阶项目，应对下一代法规要求，开发难度大不少，但是项目紧急程度不高。虽然需要做完整流程的测试，但是可以充分借鉴项目A的经验，并且时间上也比较充裕，可以作为检验团队能力很好的实践。
• 项目C为道路车型产品，合作方比较有经验，以学习为主提升团队能力。
• 其他项目开发，需要测试这边提供基本的验证，以及验证环境搭建。不用上HiL，但要有单元和集成级别测试，最终客户环境测试。
• 其他非项目类，如测试实验室建设，也需要一定的人员分配精力去支撑。

综合来看，做了如下匹配的规划：

• 测试团队内部划分模型测试、负载箱集成测试、HiL测试、整车测试及仿真设备专项开发这5个虚拟组，各组之间的人员可以流动
• 根据实际需求，几个组初步的人员招聘需求为模型测试2名、负载箱集成测试2名、HiL测试3名、整车测试5名、仿真设备专项开发3名，共15名，实际后来团队也确实扩大到了这个规模
• 每个虚拟组都要至少有1个相关工作经验的人员支撑，除了整车测试（理论上整车测试非常接近于客户使用，所以有驾照，且具备较强学习能力，肯吃苦的都可以）

注意，这里的规划也是经过动态发展，完善后的版本，并不是说刚开始就能这么精确，也要随着招聘的难易程度来适应。

团队管理实施

从建立团队的一刻开始就伴随着团队管理，甚至只有/只剩下1个人（自我管理）的时候，刚开始容易简单地把团队管理认为是分配任务，跟踪团队成员进展，培训及考评团队成员这些，随着经验增加会发现这样是一种低效率的管理，理想中好的团队应该像是一个生命体，具备自我激励自我修复的特性，大家心往一处使，哪边少人了自动有人顶上去。我能想到的例子是战场上那种作战小团队，队长一个眼神或口令大家都知道要怎么做，很有默契，队长牺牲了，副队长顶上……直至到最后一个人还具有战斗力。当然这个例子夸张了些，工作中大家能聚到一块，一分靠理念，一分靠缘分，还有一分靠利益，当然这三者其实都互相有联系，但团队要成长，缘分不好说，管理者可以在理念和利益上下功夫。理念偏精神，利益偏物质，但总归合起来说明一件事：我愿意干。
从公司层面，理念和物质都考虑到了，对应的是公司文化愿景、薪资福利等等。在团队层面，一方面能够给个人带来影响的是职业发展、技能积累这些硬成长，另一方面是包括工作氛围，资源人脉这些软收益。能提供好这些，不失为一个优秀的有益于团队有益于成员的管理者。当然上面说的比较理论，实践还有距离，真带团队考虑的因素还有很多，回顾下自己当时做的几个点。

能力矩阵

能力矩阵是一个比较好的工具，我不记得自己当时有看过什么先例，但是当时可能看过类似的然后潜意识里就觉得要有这样一个MAP，对，就像一张MAP，把团队需要的和实际的能力成熟度用矩阵方式列出来。主要有两大区域：业务能力和专业能力。
业务能力就是我们要测试的对象特性、行业法规标准、专业工具使用，比如我们的主要项目是ECU，那么至少需要知道ECU的各项功能（转速同步、轨压控制、喷油控制、进气控制、扭矩计算、扭矩协调、故障诊断管理等）；还要知道一些基本法规标准，比如GB 17691/18352/20891、ISO26262、IATF16949、ISO14229/15765、J1939……；以及常用的如INCA、Matlab、CANoe、dSPACE这些工具。
专业能力指的是测试能力，包括需求分析、测试方法运用、搭建测试环境、缺陷敏感度、报告编制及表达等。
针对以上定义的能力，细分到阶段、项目上，和相关人员组成一个团队能力矩阵，附加上能力熟练度，类似下表

	能力1	能力2	能力3	……	能力x
成员1	掌握	熟练	欠缺	……	欠缺
成员2	欠缺	熟练	掌握	……	掌握
……	……	……	……	……	……
成员x	欠缺	掌握	欠缺	……	精通
这样做的好处是一方面可以知晓当前团队能力，对比和目标的差距，从而招募或者培养相应的人员；另一方面在有项目需要时，可以快速整理出一份最为合格的人员名单支持项目开展。当然这张矩阵表也是随着团队发展不断完善的，对引导能力建设时很有帮助，比如某项能力项目上急需具备，但当前没有完全合适的，那从能力矩阵表中容易看出哪名成员有相近能力，培养成本较低，如果loading较高，在协调其他人员帮助的同时做招聘计划。
除了以上两方面，在测试流程、规范、模板等通用准则的建立则是作为团队负责人要提升的能力。

测试实验室

俗话说，工欲善其事，必先利其器。要做好测试，除了有过硬的基本功、专业的意识和完善的流程外，还需要有较好的测试环境，这条可适用于所有行业。
所以建立测试实验室有两个目的：1. 保障测试活动能够有质量地开展；2. 从实践中精进团队测试能力。
没有测试实验室之前，测试活动主要在个人电脑上进行，比如做单元测试，以及在办公室空位处堆放一些测试设备，多项目多部门揉在一起使用，无法有效管理，并且受空间限制，设备完备度也低。所以有条件的话还是尽量争取要有独立的测试场地，当然要考虑实际使用能力，不是为了做形象工程。随着公司发展，办公地址变迁，团队扩大，测试实验室也经历了3次变更，当然是一次比一次更完善，常用设备工具包括：

• HiL设备（有条件的话选用dSPACE的，更适合汽车行业，其他如NI、ETAS、恒润等也有对应产品），这个当然有能力自研也是可以的，能到这个级别的团队，妥妥地可以对外服务了。HiL设备毋庸置疑是汽车电子产品测试的必备，花个百来万，相对于收益还是值得的。能力进阶顺序：接口测试->基础功能测试->故障注入测试->自动化测试->标定验证。建议根据项目复杂度、数量做好采购规划，比如我们一共4-5个开发项目，测试时间大多都有重叠，所以采购了两台HiL设备，一大一小高低搭配，高配的用于道路产品，并向下兼容，低配的覆盖非道路产品，通过自制转接器和BOB解决不同ECU接口兼容问题，可以在不同项目间快速切换。
• 负载箱或者叫Loadbox，可以看作是不带被控模型的极简版HiL，作用也很多：基础软件开发调试、硬件测试、软硬件集成测试（开环）、故障件分析检测等，有效分担了HiL设备的测试压力，而且对于产品前期开发的帮助很大，因为不需要调被控模型，所有信号量都是可调电气信号，只要有ECU硬件，上电就能测试。而且不仅在测试试验室会用到，整车标定、DV/PV试验等也会用到。开发难度相对低了很多，我们自己就研发了3代不同功能规格的负载箱投入使用（不仅限于测试部门）。
• 其他的诸如示波器、万用表、稳压电源、电流钳、压线/退针器之类的常用配置就不多说了，提一点的是发现周立功的示波器功能还挺强大（有些版本支持SENT信号解析），属于物美价廉的，预算不够的可以考虑。还有专用于整车测试的行车记录仪（带远程通信），由于产品小批投放市场后，特别是装机爬坡期，会暴露不少未预想过的问题，而且即使人过去了也不一定能立马复现，有时需要进行大量的客户环境测试后才能获取充分的信息，而如果故障车辆装配行车记录仪后就可以在实验室远程接收记录信息，当客户反映问题复现后就能从预定记录的历史数据中定位问题了。
• 当然实验室除了硬件设备，也包括软件，做过一些调研/试用工作，比如自动化测试软件ECU-TEST，CAN协议开发工具CANoe，单元测试工具Tessy，运行时间分析工具aiT/TimingProfiler。当然能配置多少看预算，曾咨询1个在我第一家公司接触过的供应商，人家直言不讳地说这个软件一般只有科研院所买单（贵，满足特殊要求），民企不推荐……
  测试实验室管理方面，环境上不说严格要达到车间管理的6S/7S/8S……至少保持清洁，规范，工作区域划分为“手工台架测试区”（负载箱）、“HiL测试区”、“虚拟台架标定区”三块，购置工具收纳柜，绝缘桌垫，防静电手套等。此外由于我们办公区在写字楼里，还有用电功率和楼层承重方面的评估，需要物业审批通过，所以如果有自己的厂区最好实验室还是放在一楼并且提前按工业用电标准规划。在状态管理方面，通过磁吸标签，可以方便地指示当前设备使用状态（在用，停用，维修），另外还有发布设备使用计划表，项目需要使用测试设备时要先登记项目信息、需求周期等信息，这些措施对多个团队共享使用设备时是有利的。

团队凝聚力

虽然我现在转项目管理了，但不得不说，提供人员归属感还是要靠职能部门，因为项目总有结项的一天，结完项人员回到职能部门继续分配或者就做技术专项工作，并且大多数情况下员工的工位还是按部门分而不是项目分的。至少我经历过的，大多数情况还是部门成员业余在一起玩的更多些，感情更好些。
作为一名具备团队管理职责的人，我想换位思考是首要的，即你的所言所行是否能够说服你自己？以自己曾经作为一名测试工程师来想，我想要组织提供哪些？我觉得主流的想法应该是技能提升、发展空间和工作氛围，因为自己变强有更好的职场竞争力，组织变强带来更多的收益及影响力增值，而好的氛围又是前两条的基础。所以可以想到如果在允许的条件下做到以下几点，遵照人心所向，自然有凝聚力：

• 根据成员个人特点及意愿提供明确的发展路径
• 组织技能培训，包括团队内部、公司内部、供应商免费培训、外部论坛会议、外部收费培训等
• 保持积极乐观心态，对待困难身体力行，参与具体工作，而不是高高在上发布命令，以个人魅力而不是职权上的控制力去吸引下属
• 多方沟通，发现异常时及时关心，解决困惑或冲突，即使是批评对方也要给出建设性意见
• 适当组织吃喝玩乐，偶尔可以自掏腰包或申请活动经费，但最好AA（自己可以多出点），前提是自愿参与
• 定期更新团队规划并征求上级意见，便于下阶段团队建设工作开展
  但老实说自己实践得一般，有部分客观原因，其实还可以做的更好，比较遗憾。

结语

以上主要回顾了自己建立起测试团队的一些收获，而带好团队需要做的还远远不够（俗话说打江山容易，守江山难），目前自己经验还很有限，或许若干年后翻回来看看会有更多体会，届时再作更新。