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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


↙↙↙阅读原文可查看相关链接,并与作者交流