本文来自《华为人》

做好测试，难吗？

入职第一课：敢问，会问

我的职业生涯是从学会如何向别人请教问题开始的。

首先发现我的问题的是我师父。有一天师父找我，开门见山地说：“你在工位一坐就一整天，也没见你问谁问题，是都学会了吗？”

我红着脸，憋了半天挤出一句：“师父，你们都太忙了，我不会的太多，老觉得会打扰到你们。”

师父若有所思地点了点头：“我刚毕业那会儿也跟你一样，不太敢主动问，一来，因为在学校大多是自己研究，养成了习惯；二来，担心自己的问题太 Low，不好意思问出口。”

我一边小鸡啄米般地点头，一边在心里给一语中的的师父点赞。

但师父话锋一转：“公司不是学校，工作跟学习不一样，不可能有人主动来问你会不会，一定要主动出击，敢于主动提问。提问会提升你的工作和学习效率，很多经验如果靠自己去摸索是很浪费时间的，别人的一句话可能就会帮你节省很多时间。当然，找准提问的时机也很重要，除了工作时间，还可以利用吃饭、遛弯，甚至打水的时候。要学会抓住一切碎片时间。“

我点头如捣蒜。明白了道理，我的执行力还是很强的。我马上见缝插针地开始向不同的人提问。比如 “用户在线但是流量一直不通呢”“增值业务都配置好了，但是就是没激活成功”……可当人家反问我 “查丢包原因了么，看激活失败原因了么”，我顿时傻眼了。这些动作我确实没有做过。在经历了几次被质疑后，我学会了在提问之前要先做 “功课”，一定要问一些有自己思考的问题，这样会更容易得到解答。

这里尤其要感谢我们组的阿哲同学，他不仅会帮我解答问题，还会把相关问题涉及的资料或帖子一并 “甩” 给我。一开始我以为他只是随手帮我找的，渐渐地，我发现这些问题都是他以前遇到过的，他会把这些积累起来，形成自己的知识库。于是我也向他学习，整理了一个百宝箱似的 word 文档，下次再碰到类似的问题，一贴一搜，很快就可以找到解决办法。

这个好习惯在后面的工作中真是让我受益匪浅。有了我这个 “前车之鉴”，现在我们组里有很多新同事，当他们也遇到一些基本的问题时，我会直接把这个文档里相关的解决方法发给他们，全面又高效。

从前辈阿哲身上学习到的经验和习惯在一点一滴的积累中，能够帮助到更多的新员工，我真的很开心。

不做工具人，要做 “思想者”

试用期转正后，我被分配接手 YANG 专项测试工作，主要是依赖 DFX（面向 X 的设计）工具来进行的专项测试，要求版本过点前专项的通过率在 95% 以上。项目开始投入了 4 个小伙伴，南京 3 人，北京因赶上版本过点，人力紧张，就我一人参与。当孤单的我得知测试范围是南京的 3 倍时，顿觉压力山大，心态有点崩了。有一段时间我觉得自己每天的工作和生活就是反复执行，发现产品问题就汇总给开发人员提问题单，发现工具问题就找工具的同事确认修改，然后继续执行来提高任务通过率。

我成了一个测试 “工具人”。虽然发现了很多专项的产品和工具问题，但看不到这些问题的价值，感觉换成别人也能分析明白，自己的能力没有提升。每天测得很痛苦，但我没和任何一个人说过，直到有一天，我在工位越想越委屈，还掉了 “金豆豆”，现在想想当时的自己可真是太不争气了。

师父第一时间发现了我情绪的波动，直截了当地对我说：“思锦，撑不住了不要硬撑，要学会排解情绪，学会向上级和周边的人求助。”

我有些担心：“师父，如果我说我压力很大，你们会不会觉得我抗压能力很差？”

师父一听反倒乐了：“这是你们新员工的通病啊，太在意别人的看法，而且瞎担心。其实，在工作中最重要的是先把任务完成好，然后自己有提升，这是组织希望看到的双赢的结果。来说说你现在怎么想的呢？”

我坦承自己很迷茫，觉得沦为了一个工具人，“用例不是我写的，测试方法不是我选的，测试点不是我梳理的，都是别人告诉我的，我只需要去做就可以了。“我对师父说，我陷入了思维的怪圈，如果发现问题，那是人家用例写得好；如果发现不了问题，那是功能比较稳定，“既感觉不到自己的成长，也感受不到自己的价值。”

师父摇了摇头：“这是你认为的。专项组 Owner 反馈说，北京只有一个人，但进度没有拖延，还给工具提了很多举一反三的合并问题，让开发去排查。这些都是你的成果啊。“

但紧接着，师父一针见血：“你之所以有工具人的感觉 ，问题在于你做事不扎实，只是想着完成任务，没有自己的沉淀和思考。虽然别人会说你完成得又快又好，但你不知道为什么要测这个功能，就会缺少一份成就感和使命感。”

师父建议我问自己一个问题：如果这个任务分给另一个人，你能不能自信自己一定完成得更好？

一语惊醒梦中人，我顿时明白了自己真正的问题在哪里。在后面的测试任务中，我沉下心来，沿着师父的思路，反复问自己，在发现问题的基础之上总结经验教训，不断提高专项测试的效率，不仅保证了专项的如期交付，还输出了 3 篇测试总结，帮助后续投入专项的同学能够快速上手。别说，做完这些，真的有了一些成就感！

“相爱相杀” 的测试与开发

随着技能不断增长，2020 年夏天，我开始参与到 PDU 关键重构项目的测试中。需要重构的功能在历史版本已经商用多年，但由于历史代码多个模块互相影响，牵一发而动全身，因此此次目标主要是对代码进行梳理精炼。虽然底层代码修改量大，但对外的功能差别不大，所以在功能点的黑盒测试上，没有太多表现。

这让我很紧张，因为它和我以往接手的项目不同。之前的项目都有明显的黑盒验证点，而这次主要是大量的底层代码的修改，单单依靠已有的自动化用例和现有的黑盒验证点只能保证基本功能没有影响，但不能确保覆盖到所有的代码修改点。我必须要再往前走一步，跟开发一起讨论策略。

而关于测试和开发这对欢喜冤家 “相爱相杀” 的故事，我早有耳闻，一想到自己要直面，心里不免有些打鼓。

因此，在测试前，我特意请教了负责重构的开发同学，包括代码修改的逻辑，还有调试分析以及业务的中间交互过程，开发同学开玩笑地说：“你又不用写代码，不用看得这么仔细，只要知道最后和历史版本功能一致就行”。我也笑笑说 “让我学习下你们怎么重构的嘛”。

有了前期的交流和熟悉，我和开发之间虽有 PK，但还算 “相亲相爱”。可随着项目验收的深入，我发现了几个问题，虽然没有影响功能，但是站在测试的角度来看，和历史功能相比确实有了变化。于是我去询问开发同学，开发同学表示重构后的代码实现就是如此，并不是问题。我也知道不是问题，可心里还是过不去自己这一关：如果客户使用这个功能时，我们也这样回复，客户能否心悦诚服？反之，如果我们确实有分析、裁决过这种差异不会影响业务功能，客户多少都会宽心一些吧。

我决定勇敢表达内心真实的想法。好在开发同学都非常通情达理，几小轮 PK 下来，我们终于心平气和地达成一致，并一起与测试 DE（设计工程师）、开发 DE 沟通决策：修改底层表项平滑不掉、成员口多次加入退出概率超时等多个问题，与历史功能保持一致，对于不建议修改的内容，就按照 “同版本差异变更” 记录在案。

有了这次成功的尝试，我开始向更隐蔽的功能发起探索和尝试。在对 Trunk 负载分担功能重购的测试中，我发现了 “特殊场景负载不均衡 “的问题，但这个场景很难构造，开发同学初步判断，“现网很难出现，不需要修改。” 但是我这个人有点强迫症，如果发现了问题，不找出问题根因，不解决掉，会寝食难安。

一番摸索后，我复现了问题，还意外地发现，相同的场景下，重构负载分担不均衡比重构前更为明显，如果现网出现此种场景，将会影响客户体验。开发同学也承认，之前对负载平衡处理条件判断不够准确。

就这样，在与开发人员一次又一次的 “交锋” 中，我不断学会用开发人员的思路思考问题，也更加重视黑盒和白盒数据的收集，不仅保证了项目本身测试点的精准全面，而且对其他项目的验收也产生了举一反三的价值。

老话常说 “知己知彼百战不殆”，当我们有了成熟的测试方法，又主动学习了开发的实现逻辑，还了解了客户的应用场景，我们自然而然就有了更清晰的测试思路。无论开发还是测试，我们共同的目的都是为了更好的产品质量，更多的是互相帮助，共同成长。

将工具变为自己最有力的武器

工具对于测试人员而言，就像乾坤圈、混天绫、风火轮对于哪吒的意义。看过电影《哪吒》的伙伴们应该都知道，乾坤圈是太乙真人胯下那头猪变的，所以对于不同的测试人来说，想要成功就需要有一个趁手的工具，但这个工具需要我们自己去挖掘。

刚来部门的时候，我独立承担了 radius 防雪崩项目的测试。大家都知道，现网发生雪崩很难自愈，而且在实验的环境里，我们想复现原场景是很难的，LM（部门经理）也在项目验收之前给我打了 “预防针”，说这种雪崩项目虽然测起来很难受，但是作为新员工不要有心理压力，遇到问题及时反馈，需要协助会优先安排，一定要在这种 “难项目” 验收后有自己的成长。

道理都懂，但我还是很头疼。因为当时部门服务器的性能还不到现网实际能力的十分之一，最大的瓶颈就是硬件资源的短缺。最开始我想用开源的小软件，但是发现它们的功能单一且存在安全隐患，所以早早放弃。我又想到一个法子：如果使用 10 台服务器负载分担并行处理报文的方式，那几乎就和现网能力无差异了。可是，难题又来了，部门只有 1 台空闲的 2288 服务器，按照以往经验，只能在它的上面拉起 1 台 Radius 服务器，这对项目来说简直是杯水车薪。

还有什么方法呢？我简直抓破头，有一天吃饭的时候猛然想起，读书的时候总在笔记本电脑上安装虚拟系统，那能不能在 1 台 2288 服务器上搭建多套我们自有的虚拟操作系统，这样一来，我的问题不就解决了么？

一想到曙光就在前方，我就浑身 “来劲” 了。连续几天，做梦都在想解决方案，当然，项目的测试进度也不敢耽误。为了给自己争取到更多的测试和服务器部署时间，我必须要先向开发证明当前的解决方案不是最佳的。

于是我赶紧去借服务器，虽然没办法在一两天内搞定 10 余台 radius 服务器来实现现网实际能力，但东借西凑还是找到了 3 台 radius 服务器，并证明了服务器的性能对项目的解决方案的阈值设置和调节幅度的确有影响。通过这个结果，我又推动开发同学修改了一版防雪崩方案。这对我来说，实在是 “一针强心剂”。

大家也都认可当前的防雪崩方案，认为是保底结果，如果继续测下去，可能结果也大抵如此。“要不就这样吧” 这句话一直在我耳边萦绕，我陷入苦苦挣扎中，真的就可以了么？我很不甘心，可是我又找不到更好的法子了。

山重水复疑无路，柳暗花明又一村。有一天，我在和同事了解 CU 部署的时候，突然了解到，华为有一个自研的虚拟化软件，叫 FusionCompute。我粗略看了一下部署方法，仿佛一束耀眼的光驱散了黑暗——用它来承载多个 radius 服务器的虚拟环境，貌似可行啊！但是我也知道，不能高兴得太早，离项目最后期限只有 5 天了，新年也快到了，再搞不定服务器性能瓶颈，怕是新年都过不好了！

我立即找项目经理老高商量，可不可以再匀出 3 天时间给我？如果打通了端到端的部署，我们就能基于现网的服务器性能进行测试了。当时，心情复杂的我可能说话声音都在颤抖，老高怕是觉得我要急哭了，立即应允：“明天继续测。” 我可太喜欢 “明天 “和 “继续” 这两个词了，它们总会让我充满希望和干劲，还有说不清的喜悦。

摸索了 3 天，我终于搞通了 10 台服务器端到端的部署，并且把方法分享在维基上。这套方案解决了硬件资源的短缺瓶颈，在没有花钱、没有延期的情况下达到了现网服务器的处理能力，能有效保证项目测试的结果可信。

开发同学根据我提供的最终测试结果做了方案调整，项目如期交付。新年如约而至，我悬了好久的心也终于稳稳地落地了。

其实我们可以看到，现有的工程工具已经非常完善，但这里的工具不单单指狭义的工具本身，它也可以是一种思路，一种方法。我们不仅要做工具的使用者，更要做工具提升的建设者。当你找到了这样的工具，学习如何去使用、如何去改进，那么它就会成为你独一无二的武器。

我的故事讲到这里，不如咱们再回头看看文章的题目——做好测试，难吗？

其实看似困难也简单。难是因为，作为新人的我们，有热情、有目标，也有一定的能力，但是还没有在项目高质量交付、测试效率提升和可信测试中有切实的自我成长。如果日后我们能不断学习，不断成长、善用武器，并且坚持交付出可信的测试结果，我相信，所有的困难都会迎刃而解。只要你相信自己可以做到，就一定可以做到，并且可以做得更好，那时我们的肩膀就能够承担起更大的责任。