软件测试(实习生)如何快速提升技能？整理1份大佬的学习路线送给迷茫的你！

Posted 2021-09-04 小码哥说测试

任何牛逼的人背后自有牛逼的知识体系，你要想自己牛逼，就得先了解什么是牛逼的知识体系。所以想做一个牛逼的测试人员，最快速的方法就是先要知道牛逼的底层的知识体系是什么。

一、什么是牛人应该具备的知识体系？

1.普通人的知识体系是怎样的

查理·芒格曾经用“逆向思维”确定了什么是普通人的知识体系：那就是缺乏纵深、单一化和松散无联系。

先说第一个，缺乏纵深。这点很好理解，你想，一个人知识面再广，至少也应该在某一点上是比较深入的吧。要是你什么都知道一点，但也什么都理解得不够深刻，那你就会发现，很难打通现象和底层规律之间的通道。这样的话，我们在社会上的竞争力就会很弱。

再说第二个，单一化。单一化的知识体系会造成狭隘的视野。举个例子，大家都听过一个品牌叫无印良品，这家公司在做员工管理的时候发现了一个问题，长期做销售的人会认为“产品卖得好，主要是销售的功劳”，而长期做产品研发的人呢，会认为“产品卖得好，主要是是产品质量好，销售不怎么重要”。显然这两种看法都很片面，这就是单一化。

还有第三个，松散无联系。就像任意堆积的衣服一样，不去整理它们。长此以往，不仅增大了你的认知负荷，也容易让你形成松散凌乱的知识体系。

而这3大特点，正是我们大多数人的知识体系，所以我们是普通的平凡人。

2.牛逼人的知识体系是什么样的？

其实一个好的知识体系符合这样一个特征，宏观上看像是字母 T，而在微观层面看又像字母 Y。

为什么说宏观上看像 T？

其实就是说，好的知识体系是在某一专业上纵深，比如在测试领域，纵深就包含功能测试，自动化测试，性能测试，测试开发….，一路上升级打怪。但同时具有多学科的广泛视野，这不就像字母 T 吗？大多数人都只使用自己学过的某一个思维模型。比如说经济学，那他就会试图用这一种方法来解决所有问题。就像谚语说的，“如果你的手里拿着铁锤，那你会觉得整个世界都像一颗钉子”。这其实是处理问题的一种笨方法，一般也很难取得理想的效果。

接下来我们再说说微观层面为什么又像字母 Y？

比如你在做设计，也许你只是使用了设计方面的知识。而 Y 型知识架构就是说，你不能只使用单一知识，还要将其他类型的知识合并进来一起使用。比如，设计加认知科学就是一种很棒的 Y 型知识架构。如果你想设计一张海报，提前考虑受众应该优先获取什么信息？会有什么样的情绪反应？是不是符合用户的预期？能不能引发他们的好奇？他们能不能无需思考就知道如何行动？想想看，一个设计师如果了解人的认知规律，哪怕只是一些基础原理，设计出的作品都会比不了解的好很多。

所以说，Y 型知识架构强调的就是在微观应用层面，你需要将两种学科以上的知识刻意合并使用。为什么说要“刻意”？因为对大部分人来说，做自己擅长的工作的话，他就会陷入常规套路当中，如果不是刻意，很难加入其它学科知识。

3、总结

好，我们来总结以上的内容：我们借用了查理·芒格的逆向思维方法，在分析了什么是“坏的”知识体系后，又基于查理·芒格的“多元思维模型”，又提出了什么是“好的”知识体系。并且指出，想构建的好的知识体系有三个步骤：一、到纵深的知识点；二、建立多元学科的知识体系；三、合并交叉地使用知识。

二、结合牛人的思维体系和个人经验，介绍测试人员如何才能牛逼

很多人觉得测试人员主要工作就是执行用例、提bug、跟踪bug、复现bug，比较少的涉及代码，技术能力不强，所以觉得测试人员不够牛逼，在项目组中不够有话语权。

如果想让自己在测试领域变的牛逼，结合牛人的思维体系和自身个人经验来说，可以从如下三个方面来努力：

一、要成为牛逼测试人员，就要争取在测试领域做非常有深度

常见的测试工作，包含如下环节：编写测试计划 — 编写测试方案 — 编写测试用例 — 测试执行 — 提交测试报告

（1） 编写测试计划的时候，除了分配人力和安排时间外，还要能提前识别出项目组中可能的人力、技术等风险，协调好项目中的时间及各种转测、测试通过的标准，既要与项目组其他部门达成一致又要充分保证测试组的权益。

（2） 编写测试方案的时候，能识别出项目中各个功能模块的重点和难点，制定对应的测试策略，并对比业内的测试工具，选择最适合的测试工具。

（3） 编写测试用例的时候，考虑用例怎么能覆盖得更全面，能发现别人发现不了的bug，能发现更多的bug。真正想写好测试用例，除了要熟悉界面功能，还要比开发更懂业务，要有全局观。

（4） 测试执行时，除了手工执行功能测试以外，自动化执行、性能测试执行、安全性测试等是否都能上手

（5） 做完前面的，测试人员编写测试报告，项目就可以发布上线了。这时虽然能上线，但是潜在的风险能不能识别出来；分析项目进度、bug数量、bug类型、bug分布，分析这次项目中有没有可以改进的地方，可以学习的地方，能否推动后续改进落地。

图1：（传统）的测试工作流程

其实能做到上述几点，基本上可以是一个中高级的测试工程师了。不过优秀(“牛逼”)的测试工程师可能不满足于此。

2、要成为牛逼测试人员，还需要向上下游来扩展测试的工作领域，打开职业宽度

上游的工作包括：

（1） 在项目立项时，进行需求确认的时候，测试人员能参与进去。站在测试人员的角度上，通过发散性的思维来发现需求中的遗漏，提高项目的质量

（2） 想办法提升开发人员转测试的版本质量。例如：参加开发的code review，熟悉功能模块的项目代码，知道开发的代码逻辑，哪些地方坑比较多；提供一些手工用例让开发自测；给一些自动化的接口和UI测试代码让开发自测；部署静态代码检查工具，并推动开发分析和修改发现的问题

下游的工作包括：

（1） 发布线上版本部署的自动化，减少出错的概率；缩短项目部署的时间

（2） 线上问题的统计和分析，找到问题的根源，推动项目组的负向改进

（3） 发布后统计运行数据，分析上线系统是否达到预期效果，分析改进方法

总而言之，优秀的测试人员不要把自己单纯当做测试人员，而要把自己放在质量保障人员的角色上，推动整个项目组一起保证质量。

3、要成为牛逼测试人员，最后还要能多元的交叉使用知识

这里以自动化测试为例，自动化的技能不要仅仅满足于编写测试脚本，执行测试用例，而是要站在质量保障的角度想办法提升上下游的测试效率，并最终保障软件版本的发布质量。具体的工作可以包括持续集成探索、工具平台的开发等。

持续集成的工作大概包括：

（1） 从开发每次提交代码开发，把所有的编译环节都自动化，自动打包提测

（2） 编辑完成后，可以自动进行静态代码的扫描，利用业内一些静态代码检查的工具（如sonar），检查代码中的静态问题

（3） 引入单元测试，单元测试的用例和脚本可以由开发和测试合作编写，保证代码内部函数逻辑的正确性。在一套完整的自动化测试方案中，单元测试的难度和工作量可能是最大的，但是覆盖率高的话效果往往是最好的

（4） 单元测试结束后，可能自动获取编译完成的代码包，进行环境测试的自动搭建，搭建完成后直接用于后续的接口和UI自动化测试。

（5） 接下来，接口自动化是现阶段公司中做的比较多的自动化测试，因为后端提供给前端的HTTP接口相对比较稳定，后期用例修改维护工作量比较少，所以接口测试的自动化占比一般比较高。

（6） 在接口测试的上层就是针对用户界面的UI测试了，UI自动化通过操作页面上的各种元素，模拟测试人员对系统界面进行直接操作。但是UI界面由于受用户需求影响较大，经常发生变化，因此UI自动化的比例一般不高。

（7） 在项目结束时，可以将测试通过的代码；自动部署到线上环境，减少手工部署的时间和可能出现的失误。

持续集成是目前相对比较成熟的技术方案，在掌握了这一套持续集成的技术之后，可以在此基础上进一步开发测试工具/平台，如测试环境管理、配置管理、项目（需求/缺陷）管理、线上问题监控、打点统计等工具平台。最后，通过工具打通CI和CD的所有环节，使用持续集成的框架串联起来，可以大大的提高工作效率和产品的质量。

图2：自动化持续集成平台示意图

这里仅以自动化测试技术为例，介绍测试技术的多元化使用，对于其他性能测试技术、安全测试技术、管理技巧等各个方面，均可以在各自的技术领域深入学习提升，并进行多元化的探索，达到行业内“牛逼”的程度。

至于大概要多久才能这么牛逼？有了目标，就看你每天，每周，每月往目标靠近的速度了。一万个小时定律（大概5年）。在走向牛逼的路上，请坚持。祝你成功。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

在这里还是要推荐下我的软件测试学习交流群175317069，群里技术大牛，如果你正在学习，小编欢迎你加入，大家都是测试开发党，不定期分享干货，包括我自己整理的一份2021最新的资料。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

 码字不易，如果此文章对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。