一

我们组的校招生，在三个月总结面谈时，我总会问他们一个问题「在学校学习的东西，工作中都能用上不？」，不出意外，一般得到的回答有三种：
1、用不上；
2、有一些用的上；
3、绝大部分都没有用上，但是觉得还是有用的，在考虑某些问题的时候会潜移默化的有一些影响；

这个问题并没有标准答案，不管是否真的用上，都不是关键，我这么问，主要是想让大家去思考这个问题本身的意义。

当然，相对来说，第三个回答更能体现出这位同学有在思考，不然答不上这么理论的总结出来，这正是我期望看到的，那后面我们就会关注让他不要丢掉思考这个好习惯。

对于给出前两个回答的同学，需要进一步引导他去明白这个问题的真正意义，真正的去思考这个问题要问的内容，比如可以继续追问「为什么用不上？」，「没有用的话，上学的目的是什么呢？」等等。

反正就是要「引发思考」，引发理论知识和社会实践的关联关系的思考。

二

如果做个类比，可以认为测试经验图谱是理论知识，具体的测试项目属于社会实践。

我们项目实施过程中，要不断刻意的去思考经验图谱和项目本身的对应关系，从而达到理论和实践相结合的效果，下面我提供了具体实施的例子。

第一步，通过社会实践提炼和积累理论知识。

比如我们项目的一个提测修改是「修复 CreateProcess 函数第一个参数没加引号的问题」，经过 MSDN 查询发现，如果这个 API 的第一个参数没有加引号，可能会出现被劫持的问题。

再扩展一下想想，这个 API 的功能是创建进程，那么其他创建进程的 API 是否有同样的问题呢，一查果然发现，其他的 CreateProcessAsUser、CreateProcessWithLogon、CreateProcessWithToken 都有类似的问题。

于是可以把关注这几个 API 特点这个知识点归类到系统知识->进程相关的经验图谱里面了。

第二步，在后续的社会实践中，把提取的理论知识进行再应用。

比如有个新的项目提测了，其中一个修改点是「使用 CreateProcess 创建第三方进程」，如果没有之前的知识储备的话，测试点一般是构造下业务场景，发现目标进程确实创建成功就行了。

如果是对文件路径格式比较了解的测试，会考虑第三方进程路径的不同格式，这里不同路径格式就是用到了系统知识->文件相关的知识点了，比如其中一个储备的路径信息就是带空格的路径，结果一测，果然有问题，最后问开发才知道是因为路径没有加引号导致的。

如果这个测试，有前面提到那个项目的经验，一看到 CreateProcess API 的第一反应应该就是去验证/确认第一个参数是否加了引号，也许立刻就发现问题了，如果是开发刚提测你就告诉他这个缺陷的风险，说不定他会对你刮目相看噢。

看到没？上面这两步，完整的呈现了测试理论和测试实践相互转换的过程，其实我们的项目实践过程中，无时无刻不是这样的循环，关键是我们是否有去刻意关注，并进行刻意练习。

单纯的社会实践，或者单纯的理论积累，都会让这个循环无法对接，达不到互补的效果，只有时刻进行测试理论和测试实践关联关系的思考，才能让良性循环的飞轮转动起来，并最终形成飞轮效应。

三

今天讨论这个事，主要是前两天有朋友问我「怎么把具体的东西梳理成体系，形成有指导的理论」。

我觉得上面的解释，应该可以解答这个问题。

还需要补充一点，实践和理论的转化，是一个偏软技能的意识流问题，不是一个具体的知识点，不可能一蹴而就，她需要经过长时间的锻炼，最后形成潜移默化的潜意识，最终水到渠成。

关于潜意识，我们还需要进行刻意练习，这样才能尽快的养成习惯，如何刻意练习呢？我觉得可以从一个个具体的问题出发，碰到每一个问题，都去思考这个问题的本质，问题背后的原理，背后的真实原因等等，反正就是不要被表面的现象所迷惑，久而久之，观察力就锻炼出来了，潜意识也就形成了，理论和实践的转换就是顺理成章的事情了。

以上，本次讨论了一些意识流层面的东西，肯定不好理解，那就一字不差地多读几遍吧，如果看明白了请点个「好看」让我知道你的态度，或者转发给更多人看到，当然，有任何问题欢迎留言和我讨论。