想当年（7年前），我开始学习软件测试时，跟大多数自学者一样，学习完很多理论和技术，转头就忘，还不知如何运用，体现在面试中，便是极容易被问得“岔气”。
后来，我咨询一位自学的前辈，他告诉我：把你学过的知识讲给身边不懂软件测试，甚至不懂IT技术的人，当他们能听懂你讲的内容，那就差不多了。
于是，我果断尝试：
讲第一次，我自己都不清楚该讲什么……
讲第二次，知道该讲什么，但话到嘴边，舌头捋不顺畅……
讲第三次，别人问我讲的什么鬼东西……
……
直到反复练习N次，我才把软件测试讲明白，通过主动的讲，我消化了死记硬背的知识点，把场景和知识完整的串联了起来——特别是当别人提一些常识问题，让我用软件测试的术语来解释时。
最后，讲解达标，我也顺利找到工作。
做软件测试的这些年，我一直把“讲出口，讲明白，讲得简单”作为消化一门知识或者一种技术的最终评判标准。
这个讲，可以是讲，也可以是写，再经由大家的评判。例如，学习完Python，我要试着把它讲出去（写博客），再把它讲明白（用通俗的语言写博客），讲得简单（不带废话的写博客）。
俗话说：先把书读厚，再把书读薄。以我之理解，把书读薄，就是讲出去的过程。
再到现在，我开始深入业务，进入到市场锤炼，才深切明白讲出去的真·道理。
身为测试人员，常常自诩为团队里最熟悉业务的人，但我之前在一篇文章说过，你以为的业务，其实只是产品经理口中的业务：
而在产品之前，该业务已经由客户、销售、市场、技术服务等岗位人员之口传递，每个人的角度和理解不一致，会导致最后敲定的业务产生偏差。
你熟悉的业务，不一定是客户想要的业务，兴许只是满足客户的折中方案；你理解的业务，也不一定经得起市场的考验，有时只是为满足拓宽市场的临时之举。
曾经，我也自诩对业务的理解足够深刻，但当我要讲解公司产品的全链路时，我毫无头脑，在应对客户和市场的提问时，也只能答上十之一二。我还经常遇到：明明系统可以支持，但就是无法关联场景，明明系统提供B方案解决，但总是想不到它。
就这样，经过一次次的讲解总结，我埋头研究小半年，也才理得80%，并且这80%，还只是公司一条产品线的80%。市场千变万化，客户万千画像，这80%远远不够，我估摸得再研究个两三年，才能完全吃透。
所以，结合我的经历，我有一些建议：
如果你还在自学，学习后，大胆的讲给身边的人，他们能听懂，你才算过关；
如果你找到工作，认真做笔记，并对外输出，哪怕一次只写几十个字，积累起来也能自成体系；
如果你跳槽到中大型公司，尝试脱离于测试本职以外，多做横向的尝试，别把自己的思维局限于需求文档的范围。捋清你做的业务，讲出你对业务的理解，多和产品掰扯，多和业务沟通，个人视野便是 在这一次次的“讲”中间拔高的。
这就好比谈一场恋爱，你有情愫，你为他（她）执迷，但爱在心口难开，除非他（她）对你看得上眼，才能两情相悦。
但这是职场，不主动，不争取，机会一瞬就没了...
联系客服
