软件测试经验图谱硬技能之积累和应用

从硬技能的五大类（业务逻辑、测试技能、系统知识、自动化能力、通用知识）划分可以看出来，之所以硬，主要是因为这些都是实打实的知识，具体点也都是可以明确拿出来说的知识点。

比如业务逻辑，我们可以从整个业务角度进行详细的讲解，也可以从某一个模块、功能点的角度进行颗粒度更细的划分，但所有这些都是固化的，可以具体说出来和写出来，有明确的是否和对错区分的知识。

比如测试技能，我们可以有明确的等价类和边界值的测试用例设计方法，我们可以明确的学习到这些方法，并分享传授给其他人，所以对于这个知识点，要么会，要么不会，是很具体的硬干货。

比如系统知识，同样是很具体的，我们可以明确的指出 Windows 系统实现自启动的几种方式，典型的有注册表 Run 项启动、一次性 RunOnce 启动、文件夹 Startup 启动、单用户 HKCU 下的启动项，以及所有用户生效的 HKLM 下的启动项等等。

比如自动化能力，这里说「能力」是为了把工具的使用和自研区分开，但也都是很硬的要求，比如工具的使用，碰到 Windows 系统的操作监控，我们需要知道使用 Procmon，碰到系统信息的查看，我们会使用 ProcessHacker 等，那如果是工具的编写，就是更硬的代码知识了。

比如通用知识，我们是把数据库知识、部分专项知识进行汇总，同样的硬货有如数据库查询时只返回必须的字段、数据量太大时要使用分页查询，以及尽可能避免过多的表关联等等，这些都是可以明确拿出来作为标准的知识点。

上面我把硬技能每个分类，都进行了举例，无非就是强调，硬技能是硬通货，只要学就有的学，并且可以通过明确的方式来考核出学习的广度和深度。

也就是说，纯粹从积累的角度说，我们是知道自己积累了多少硬技能知识的。

但是，注意哈，但是来了，但是，工作和学习有个明显的区别，学习时会对特定知识点进行明确考察，相当于明确告诉你，嘿，我要考察你某某某知识点了哈，症状已经清晰，直接对症下药即可。

而工作却不一样，工作是一堆实际问题的集合，我们自己想办法先发现问题，再去分析问题，之后才是解决，至于要怎么解决，用什么方法，涉及哪些知识点，更是没有明确的说明和要求，谁能用最小的投入获得最大的产出，谁就牛，那么积累了多少知识，和能应用多少知识，完全不是对应的关系。

二、应用了多少知识

上面我强调了知识积累的重要性，同时也提到知识必须要进行应用，虽然不止强调一次了，但今天我还是要再次强调下。

比如业务逻辑，我们说一个系统复杂，大部分是指模块功能耦合性太强，导致关联关系复杂，那么能否在某个功能点修改后，完整准确的考虑到所有关联关系，就是具体的业务逻辑知识应用的体现了。

比如测试技能，同样我们知道等价类边界值的用例设计方法，但是有人能考虑到数字类型本身也是有边界的，有人就考虑不到，这就是知识是否转化为实践的区别。

比如系统知识，如果我们只知道新增了启动项而不去关注到底是哪个类型的启动项，就会漏掉切换用户去检查启动项是否正常生效的测试点，这种测试点凭空想象是很难覆盖到的，但是有知识点作为依据的话，考虑到的可能性就大大增加。

比如自动化技能，如果我们发现一个文件可能存在注册表操作的问题，但是不知道使用 procmon 进行确认时，猜测只能是猜测，以至于没法进行更详细深入的测试，但如果我们知道这个工具的使用，就可以详细的查看每个操作步骤的每个文件和注册表的操作，同样的，如果我们需要一些简单的性能测试，但是不知道用 Jmeter，那也是干着急。

比如通用知识，一个系统使用的 mysql 数据库，如果我们不知道数据库基本的性能优化方式，就没法设计出针对性的测试用例，哪怕只是通过和开发沟通来确认实现方式，咱们也问不出针对性的问题。

能把有限的知识充分的发挥出来，才是经验的最好体现，不然一切都是白扯，而现在测试经验的积累和应用都可以通过经验图谱进行关联。

突然想起来个有趣的故事。

故事里讲的是一个工厂流水线中总是出现空盒子，于是一群高智商海量知识储备的高级工程师研究了观察法、称重法、透视扫描法等各种高精尖的技术进行解决，结果也还是偶尔会有遗漏，最后是被一个流水线工人的电风扇给彻底解决了，因为电风扇直接把空盒子吹跑了。

我不清楚故事的真假，也没必要去考究，我就觉得这故事很有现实意义，具备了多少知识，和能解决多少问题并不完全等价，只有把自己积累的知识在合适的时间和地点，合适的应用上去，才是最重要的。

所谓学以致用，是这么个理。

以上，我在之前的基础上对测试经验图谱在经验的积累和应用上再次做了说明，不知道你是否认可我的看法，欢迎说说你的观点。