越“测”越开心

做测试，是一种什么体验？

2013年4月，我来到RRU集成与验证部报道时，还在心里嘀咕：测试不就是个机械的“工具人”，能有技术含量吗？

可是一天时间，我的想法就有了180度大转变。

一个多小时的时间里，主管始终元气满满地介绍团队业务范围、技术能力模型、个人成长路径等。“开发人员要研究透彻自己负责的模块，测试人员则要懂每一个模块，并对整个系统有所了解，要持续学习产品知识，并有很高的技术追求。”他拍了怕我的肩头，“测试，大有可为。”

我不明觉厉地点点头，但还有些将信将疑。直到中午吃饭的时候，导师关心了一下我读研期间的研究课题后，竟然轻车熟路般地谈论起课题中的技术问题，还夹杂着我听不懂的术语，把我震惊了一把。

“技术难题信手拈来，这也太牛了吧！”测试人员在我心目中的形象立刻伟岸了起来。

我决定沉下心好好干，向着这样的技术大牛靠近，努力成为一名技术小牛。我当时给自己定的目标是，成为“四有少年”——有打了鸡血般的求知欲，有目空一切的怀疑劲头，有天马行空的想法，有细致入微的执行力。

测试首秀，没丢人

入职第二周，我接到了第一个测试任务——负责一个同时支持2G和4G的RRU产品的长时间射频指标可靠性测试。

身边热情的测试兄弟提醒我，对产品不熟悉的情况下，测试不叫黑盒测试，是瞎测。问题不是靠猜出来的，而是通过系统性分析后输出的。于是，他们帮我详细分析了这个产品与上一代产品的区别、可能存在的风险点、可以测试的维度等。

我按照测试用例，按部就班地执行完成。没有意外，测试结果pass。

就这样结束了吗？我有点失落。瞅了瞅身边的小伙伴，都在“唰唰唰”地提交问题单，和开发的兄弟们讨论得热火朝天，我也不想只是照搬测试用例，打算自己创建一些观测点，找到产品性能的极限点，确保测试到位。

我尝试做了一次反复重建载波的测试，这好比让手电筒重复“打开-关闭”这个操作，启动自动化测试14个小时后，我发现，有两次可靠性指标不达标，也就是有两次打开手电筒没有发光。

怎么回事？我带着疑惑，手动测试了一遍，结果都是达标。

是环境问题？手动测试通过，已排除这个嫌疑。是自动化工具问题？排查了自动化log，没有异常。会不会是一种概率性问题？导出日志，存在告警，看起来确实是产品问题。

我再次采用自动化测试，几十分钟后，问题顺利复现。喜出望外的我，急忙给开发人员老肖打电话：“快来看看，产品好像测出问题了。”

一开始他不以为然，但听完我的排查过程后，觉得“听起来挺靠谱的”，于是来到实验室定位问题。

第一次参与问题定位的过程枯燥而有趣。枯燥是因为我不清楚该如何配合定位，只能按照老肖的建议做一些简单执行。有趣是因为，此间接触到多个新的概念，如DPD、削波、AM-AM曲线等，我就像一块小海绵，快速吸收着这些闻所未闻的新知识。

老肖很快拿出第一套方案并执行。似乎很有效，无论怎么折腾，貌似都能满足达标。

会不会是测试的次数不够，时长不足？或者是否还有其他的激发点？看着几百次的测试结果，我再次陷入了沉思。

好在晚上的时间总会带来“惊喜”，放置一晚上之后，第二天到岗，我发现最大值保持下的频谱再次恶化。

老肖再次被我邀请到了实验室。对比两次场景，最直观的差异在于第二次手电筒没有再重复“打开-关闭”的操作，而是一直处于开启状态。

“有没有可能是高温下长时间测试，导致性能恶化？”看老肖苦思冥想的样子，我提出了自己的想法。

“有可能。”老肖眼里闪过了一丝赞许。他找了另一个领域的同事参与联合定位，最后确认，由于第一个方案缺少和温度相关的补偿和修正，因此没有完全解决问题，第二套方案做了补充。

为了验证新方案的可靠性，避免老问题的解决，再引入新的问题，TSE（测试系统工程师）带着我一起，开展了多场景的反复验证，最终成功攻克了问题。

虽然第一个测试任务难度不大，可能换谁都能测出来，但对初出茅庐的我来说，却是一次极大的肯定。我开始明白，作为一名测试工程师，必须持续学习产品知识，真正懂产品，懂协议标准，掌握测试的能力模型，动手过程中，要多怀疑，有折腾的意愿，不怕麻烦。

解决问题的机会只有一次

实力是在实战中打出来的。2014年，某运营商在做测试时，发现某款RRU产品在某种场景下，有一项辐射功率指标不符合要求。

前方的炮火传来后，攻关团队迅速组建完成。由于原攻关组中的测试成员被抽调去支撑发货保障，我作为替补进入攻关组，拿着厚厚的操作指导书，怀着一颗惴惴不安的小心脏，参与其中。

攻关组长经验非常丰富，经过一个短暂的开工会后，大家各司其职，快速投入战斗中。我的任务是把动态环境搭建起来，复现现网的故障模式，然后配合开发的同事修改方案并验证方案的有效性。

第一次参加重大项目攻关，我很兴奋。周围是一群被“红牛灌溉”的小伙伴，每天都要奋战到凌晨，甚至有的领域需要两班倒，氛围就这么被带起来了。记得有个兄弟调侃自己每天“南半球作息”，因为白天是其他同事优化方案，晚上他要通宵写代码，出版本。

我是首次接触动态测试，刚开始有些“丢三落四”，一会儿链路异常，一会儿又发现话务呼不上，虽然大家并没有责备，但是我在心里默默想：绝不能成为攻关组的短板！

于是，我硬着头皮搭建完成定位环境A后，单独增加了环境B，当开发同事定位问题时，我就在环境B反复演练相关的配置操作，搞清楚各个环节的依赖关系。这就好比本来我只会开小汽车，但现在要随时有能力开大巴，我得抓住一切机会去练习。

方案一仅仅撑了1个小时就宣告失败，我很快加入到方案二的讨论中，开始提前思考可以从哪些观测点来做测试，是否会有新问题场景，以及修改点带来的新增风险。想清楚后，我向TSE讲述我的测试策略。

“这样就完备了么？从客户视角看，他们还会做哪些操作，做哪些测试，平时是怎么使用的？”TSE进一步引导我思考。

他解释说：“留给我们解决问题的机会只有一次，这要求我们不仅要关注修改点的影响分析，更要多从客户角度出发，对待质量要战战兢兢，如履薄冰。”

于是，我化身为“十万个为什么”，继续与攻关团队中的维护同事小吴讨论：现网场景是怎么样的？客户业务是怎么变化的？什么时候业务量最高？什么时候打电话人多？什么时候看看视频的人多？什么时候发短信的人多？……

根据小吴给出的多个用户角度的新建议，我进一步丰富了验证用例，明确了测试的策略。而与此同时，方案二也通过了前期自验证，顺利转测试。

经过攻关组的不懈努力，在保证无辐射功率控制在标准范围内的同时，我们从多个维度对产品做了充分验证，保证了产品的可靠性，圆满完成了问题攻关。我终于可以安安稳稳地睡个觉了。

没有“大腿”抱，我要自己变成“大腿”

2016年底，入职公司的第4个年头，我成为PL（项目主管）。团队有7个人，其余6人工作经验都少于3年，一转眼，28岁的我，就成了里面最老的那个了。

如何快速提升大家的能力，成了摆在我面前的第一道难题。我当时想的就是，既然没有“大腿”可以抱，那我自己就要变成“大腿”。恰逢主管交给我两个重要级产品的测试经理工作，我决定带着大家在项目中成长。

我对团队成员做了一次总体盘点，识别分析团队成员的特点、能力现状、个人情况。然后，结合项目类型和要求，梳理了团队能力建设的方案，包括业务需要我们具备什么技能，我们还在哪些方面有欠缺。

有了思路后，我和每个同事做了详细的沟通。对团队里面的新员工，加强导师的辅导，每周的小组例会设置新员工交流的议题，倾听诉求，讨论改进方案等；量身定做了年度知识管理的规划，基于业务需求和成长诉求，分别从产品知识能力提升、测试协议解读、专项能力提升等维度设计了学习计划和课程；结合项目需求，在每个所需的项目岗位指定明确的工作目标。帮助大家明确自己的工作任务，保障项目的成功交付……

小刁是B项目的主力成员，有一天，他突然找到我说：“实在忙不过来，希望加一个人。”

我这才注意到他这阵子胡子拉碴的，看起来情绪也有些低落。“是不是遇到什么事了？”我问。

他长叹了一口气，没有说话。后来我才了解到，他现在的很多一部分精力和时间花在和其他部门的协调上，但由于年轻、资历浅，经常说不上话，在技术澄清和交流时，经常处于被动位置，产生了一些挫败感。

我想，如果我直接把这部分工作揽过来，他永远不会有进步，没有办法成长，但是我可以成为他的拐杖，给他一些支撑。

所以接下来的一周时间，我陪着他一起参与重要的会议，在他做主讲人发言完毕后，给予一些必要的补充。慢慢的，我就发现他开始游刃有余地进行技术交流，整个人生龙活虎起来。

这一年中，看着团队的小伙伴每天都加足马力地向前冲刺，既高质量地交付了项目，同时个人技术能力也得到了极大提升，我觉得充满了成就感。

最酣畅淋漓的项目交付

2019年“5·16”后，我们与时间赛跑。其中，无线某平台的交付过程现在回想起来还是跌宕起伏。

整个项目的交付周期只有2.5个月，留给测试的周期只有1个月，而且之后还面临海量的发货需求，质量承诺需快速兑现。如果遵循传统的思维，这些都是不可能完成的任务。但摆在面前的任务是务必要攻克的，最关键的是交付的质量要经得住考验，测试团队要能够守得住质量堤坝。

开工会是在作战室进行的，项目经理老胡铿锵有力地说：“我们已经没有退路了，只有破釜沉舟，全营一杆枪，打赢这一仗。”大家听了都很激动，没白天没黑夜地干。

让我惊讶的是，以往的部门墙不见了，低效的沟通不见了，所有人都以解决问题为目标。我一个电话说“兄弟，过来帮忙看看”，别人立马就过来了。这可能是我入职这些年做得最酣畅淋漓的一个项目。

作为整个平台的测试经理，我统一负责测试交付工作，测试内部40多人的工作安排都与我直接相关，真有一种指挥“百团大战”的感觉。为了提升效率，我将40多个测试人员分成三部分：测试经理群、TSE群、测试TFO（测试特性责任人）群，各群体间紧密配合，高度协作：

测试经理是测试项目管理的“车头”，面对20多款待交付的新硬件，三位骨干员工和我一起参加项目例会，参与关键计划制定。

TSE是测试策略的“发动机”。在正式产品Y板提供前，他们通过对比现有的X板，从方案设计、软硬件实现方面做了精细化分析，梳理了两者的共性与差异点。同时在X板提前验证了50%的活动，既保证了长期可靠性活动的充分验证，又提前暴露了100多个共性问题，帮助Y板争取到充足的解决时间。

测试TFO是测试的“最后一公里”。有些测试活动由于其特殊性，单兵作战的效率会较低，我就打破原有的方式，组建“三个臭皮匠”小分队。让每个人各有技术特长，互相补位，成功变身“三个诸葛亮”。

记得一天晚上11点多，第一阶段转测试物料到了。我们四五个人赶到实验室，很快把环境搭起来。由于前期充分的准备，只用了不到2小时，就成功启动了长期可靠性试验。这意味着这个跨时代的产品最大的一个风险点已经被清除。

凌晨2点，我在项目群里给大家通报了这个好消息。本以为大家都睡了，没想到群里群里此起彼伏的都是。当时我真的觉得很激动，很有成就感。

最终，我们提前多天发现了各类问题，其中涉及多个硬件方案的整改。在整个项目组的努力下，我们不仅如期完成项目交付，还有效地保证了产品质量，打下了一个来之不易的胜仗。

刚刚开始的故事

2020年2月，我开始负责中射频集成与验证团队的工作。

如果说PL要能够识别各自团队的独特价值,塑造自身的团队气质。那么，LM（资源线主管）对技术要了解、清楚、熟悉，能指导别人，能识别本领域技术方向。在团队内树立技术导向，倡导技术上深入，技术上发展。不仅仅只是交付，更要清楚如何自主经营。借用一位主管的比喻，“团队经营就像是责任田管理，只有把田守住，做好管理，才能长出更好的庄稼来”。

作为一个“新人”，我也才刚刚起步。但我觉得，一个团队要活起来，首先要在团队内部主动识别员工的成长意愿，让大家看到上升空间。在团队内可以有多个“岗位”的轮转，在立足于当前工作已经做成功的基础上，通过跨小组或者跨业务类型锻炼，提升团队成员综合能力。

比如，团队里的一个骨干员工小汪，工作6年一直没有参与跨领域的项目。我觉得这不利于他的成长。所以前阵子，我向他推荐了某项目群的大测试经理工作，让他一个人独立看护起硬件、软件的测试质量。小汪欣然接受，凭借自己的勤奋好学和实力，很快赢得了项目线的一致好评。后来，项目经理单独还发消息夸赞他：“小伙子很不错啊，之前怎么没发现还有这么一个人才！”

而对于新员工来说，培训、培养不能枯燥乏味。我们这些“老家伙”，和他们这些“小鲜肉”可能已经有了“代沟”，他们很多事情不愿意和我们说。我们要尊重这个差异。为此，我做了一个小尝试，成立了多个团建活动的“圈子”，让新员工自由选择，并公投选取每个圈子的“主席”。这样一来，每个新员工都可以在自己感兴趣的“圈子”里畅所欲言，获得帮助，团队的凝聚力自然也就上去了。

新的一年，随着更多项目交付，软硬件质量面临的挑战更大，质量保障的工作任重而道远。但我充满信心。时间没有磨平我的棱角，做不成“四有少年”，我还可以做“四有青年”、“四有中年”。那股不怕输、敢拼搏的劲头永远都不会变。

独行快，众行远。希望我和测试团队，都能越“测”越开心，都能为无线产品的质量和竞争力持续领先，贡献自己的一份力量。

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com

华为人期刊

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。