在职场中，有一种常见的误区，就是误把平台当成自己的能力。为什么会这样呢？因为公司的平台和个人的能力是相互关联的，平台为个人提供了发挥和发展能力的机会和资源，但并不代表自己能力本身。

举一个例子，某测试部门经理，年终技术职级晋升答辩时，把部门员工完成的业绩全都合并在自己身上，如开发了哪些测试工具，自动化了多少条测试用例，为部门节省了多少人力预算，等等。站在部门这个组织的角度是没问题的，但站在部门经理技术晋升这个角色看，并非其个人能力的结果，而是在公司平台的加持下，整个团队合力的结果。

个人的能力是指与平台无关的，是你个人拥有的能力，只是借助平台，你的能力可以得到更好的发挥和提升，个人能力才是自己事业长期发展的护城河。

下面就测试人员在职业生涯中的能力护城河如何更好地构建提供几点个人的建议。

第一：测试硬实力方面

在技术线方向上发展，是大部分测试人员的选择，你可以选择在某一个或两个技术方向精深，做到专家的水平。下面是能力构建过程中，很容易被我们忽视的重要方法。

更多内容可以学习《测试工程师 Python 工具开发实战》书籍、《大话性能测试 JMeter 实战》书籍

1、 写总结

工作中，很多人非常排斥写总结。有时，因公司里的测试主管或测试经理们有团队管理及人员培养的职责，会安排测试人员写总结。这种情况下，大部分人交上来的总结其实是流水帐形式的工作记录（因工作关系，我曾读过大量这类总结），实际上已失去写总结的意义。

但我们必须认识到，写总结本身是很有意义的，因为我们可以通过写总结倒逼自己去思考，去回顾过去的工作，梳理存在的问题，整理出可吸取的经验与教训，这才是我们写总结的本质。

有些人，通过写日记的方式做总结，而有些人通过写周记进行总结，也有人通过做完一件事后进行总结，方式多种多样，选择适合自己便是最好的。

日拱一卒，功不唐捐，我们在写总结中养成的主动思考的习惯，久而久之，你会发现自己自然会提出一些独立观点，会形成某些知识体系，进而可以拿出有创新性的问题解决方法，还可能会申请上一些技术专利发明等，这个过程其实你就是在构建自己的能力护城河。

2、 质量问题复盘

因软件测试职业特点，大部分测试人员的工作都在捉 bug，我们的使命就是把 bug 拦截在家里，但在现实中因时间，资源等原因，而软件的 bug 又不可能穷尽，所以不可避免地出现已发布的软件仍存在 bug（但这绝不是客户端出现 bug 是合理的借口）。

当客户端反馈问题后，特别是一些严重的 bug，首当其冲，测试人员是需要闭门反思的。尽管有些人可能不能接受，会觉得委曲，例如抱怨说项目需求变来变去，开发提交版本质量差，我没有必要的时间完成测试，等，但实际上老板们却从不会这样想。

收到客户端的问题反馈，并不可怕，怕的是我们不当回事，不做质量问题的复盘，错失了自我提升的机会。软件质量问题的复盘，需要团队中每个人的参加。如果暴露问题的模块正好是你负责的模块，那么正好你可以利用这个复盘机会，探究出过去自己在测试某特性时，是哪个环节存在问题。这里常出现一个悖论，不少测试人员会不自觉地引向是自己能力不足造成的，复盘会上除了自责，却提不出什么具体的解决方案。例如，就客户端反馈的某路径下才发生的 bug，复盘时该测试人员查完历史测试记录，发现的确是当初的测试分析中未考虑到此路径，然后便认定是自己个人能力的问题，最后陷入 “我没考虑到，我也没办法” 的境况，使得复盘讨论会陷入好像是在为他开的追责会，显然，这种复盘会是走偏了的。

在复盘过程中，当遇到是自己所负责的模块存在测试遗漏时，我们不妨多给自己设问，设问时可按测试的流程顺序结构化地向自己提问，

1、 此业务场景需求定义是怎样的？

2、 测试方案中已分析到此业务场景如何测试吗？

3、 此业务场景有对应的测试用例吗？

4、 客户端软件版本的测试记录是怎么样的？

通过自问自答这些问题，其实是在回顾当初的测试过程，在寻找问题的根因。通过不断的思考，我们总能找到一些解决问题的方案（有些解决方案不一定只能由软件测试单方面去解决，因为问题还可能涉及到需求及软件开发）。找到解决方案后，我们可以假设方案被执行了，但效果将会怎么样，可以分三步向自己提问。

1、 同一产品，同一问题已解决吗？

2、 同一产品，同类问题规避了吗？

3、 同系列产品，是否存在同样问题？是否需作改进？

其中，第 3 个问题可能自己不好回答，但可以提出来，依赖团队的力量一起在复盘中解决。

复盘，往往不单是个人在回顾，通常是在跟团队成员一起。很多公司有自己的复盘机制，甚至是复盘文化，例如华为公司，据在华为任职多年的朋友说，不仅项目完成要复盘，甚至重要的出差也要复盘。比如某地电信局的通信设备发生故障，华为工程师前往排查之后，一定要写详细的出差报告，总结其中发现的问题，以避免类似问题的再次发生，并且提出改进的意见或建议。写得好的报告会被打印出来，公开张贴，特别好的总结还会收到奖金激励。

通过复盘，可以增加个人对质量问题的认识，与团队一起不断改进测试的方法、技术，或者流程的过程中，个人的能力得到提升，能力的边界得到扩宽。

以上这些，都是在为自己积累经验，在给自己的能力护城河加深扩宽，变得更加牢固。

下面，跟大家一起探讨第三点，是需要在前面的基础上，才能作出突破的点。

3、 有意识构建能力亮点

自从你选择了软件测试作为自己的职业发展道路，在工作中完成一个个项目任务时，你会主动或被动地学习到很多知识，技能，慢慢累积成自己的经验。但进一步地形成有自己独立思想的原创性方法或技术，哪怕是微创新，是很多人遇到的难点。如果提出的方法论或技术通过在项目中的实践获得了突破性的成果，那就更是稀有，而这对于个人职业生涯的发展却又是至关重要。

我给大家分享一个案例。

【晋升评委为啥全部亮绿灯】

在 10 多年前，作为公司软件测试职级晋升答辩的评委之一，其中有一位答辩者给我留下了深刻的印象，她是当年全体评委（9 人）一致通过，并得高分的为数不多的答辩者之一。

她当时论述的主题是 “用例去冗余”，她采用的技术原理如下：通过代码覆盖率 Bullseye 工具收集用例的代码覆盖信息，通过人工及结合自动化测试工具，不断地尝试删除，调优已有用例，最后得到一套用例的优化规则，并开发出自动提示用例需调优的工具。最后的结果是她花了近 2 个月的时间，把 1000 多条用例，优化成 300 多条，项目整体覆盖率不降反升，质量得到保证同时，还明显提升了测试的效率，也为用例设计质量的评价探索出一种新的方法。

可以说，这就是她当时探索出来的一种精准测试的方法，属于测试方法的创新，所以评委听了后都是眼前一亮，毫无悬念，评委们都是一致高分通过。

怎么构建自己的测试能力护城河，我认为最核心的是意识的改变，思维的升级，需你主动往这方面去想。前面提到的正向总结，反向复盘，都是倒逼自己去思考可落地的方法，是能形成自己的亮点，获得创新能力的必经之路。

第二：测试软实力方面

软件测试是一项技术性工作，由于技术的发展日新月异，更新迭代非常快，所以自从进入了这一行后，不可避免地必须保持学习，才能跟上时代的步伐，才可能在所在业务领域应用自如，给工作上的挑战不断带来新的变化、突破。

软件测试与软件开发很不一样的地方在于，软件测试在技术上可能是杂家，而软件开发需要在某一技术领域深入钻研，越精通越有优势，例如才可能解决一些疑难杂症类的 bug。而软件测试更需要快速广泛学习的能力，才能与多个方向的开发人员同频交流，获得更有价值的信息，再结合测试人员常有的逆向思维带来的对质量的敏感性，才能在软件设计的前期提出可能的风险、可测试性等有价值的建议。

除了学习能力外，还有沟通能力，团队合作能力，自我管理能力等也很重要，对我们的职业发展起着不可忽视的影响。