我們組的校招生，在三個月總結面談時，我總會問他們一個問題「在學校學習的東西，工作中都能用上不？」，不出意外，一般得到的回答有三種：
1、用不上；
2、有一些用的上；
3、絕大部分都沒有用上，但是覺得還是有用的，在考慮某些問題的時候會潛移默化的有一些影響；

這個問題並沒有標準答案，不管是否真的用上，都不是關鍵，我這麽問，主要是想讓大家去思考這個問題本身的意義。

當然，相對來說，第三個回答更能體現出這位同學有在思考，不然答不上這麽理論的總結出來，這正是我期望看到的，那後面我們就會關註讓他不要丟掉思考這個好習慣。

對於給出前兩個回答的同學，需要進一步引導他去明白這個問題的真正意義，真正的去思考這個問題要問的內容，比如可以繼續追問「為什麽用不上？」，「沒有用的話，上學的目的是什麽呢？」等等。

反正就是要「引發思考」，引發理論知識和社會實踐的關聯關系的思考。

二

如果做個類比，可以認為測試經驗圖譜是理論知識，具體的測試項目屬於社會實踐。

我們項目實施過程中，要不斷刻意的去思考經驗圖譜和項目本身的對應關系，從而達到理論和實踐相結合的效果，下面我提供了具體實施的例子。

第一步，通過社會實踐提煉和積累理論知識。

比如我們項目的一個提測修改是「修復 CreateProcess 函數第一個參數沒加引號的問題」，經過 MSDN 查詢發現，如果這個 API 的第一個參數沒有加引號，可能會出現被劫持的問題。

再擴展一下想想，這個 API 的功能是創建進程，那麽其他創建進程的 API 是否有同樣的問題呢，一查果然發現，其他的 CreateProcessAsUser、CreateProcessWithLogon、CreateProcessWithToken 都有類似的問題。

於是可以把關註這幾個 API 特點這個知識點歸類到系統知識->進程相關的經驗圖譜裏面了。

第二步，在後續的社會實踐中，把提取的理論知識進行再應用。

比如有個新的項目提測了，其中一個修改點是「使用 CreateProcess 創建第三方進程」，如果沒有之前的知識儲備的話，測試點一般是構造下業務場景，發現目標進程確實創建成功就行了。

如果是對文件路徑格式比較了解的測試，會考慮第三方進程路徑的不同格式，這裏不同路徑格式就是用到了系統知識->文件相關的知識點了，比如其中一個儲備的路徑信息就是帶空格的路徑，結果一測，果然有問題，最後問開發才知道是因為路徑沒有加引號導致的。

如果這個測試，有前面提到那個項目的經驗，一看到 CreateProcess API 的第一反應應該就是去驗證/確認第一個參數是否加了引號，也許立刻就發現問題了，如果是開發剛提測你就告訴他這個缺陷的風險，說不定他會對你刮目相看噢。

看到沒？上面這兩步，完整的呈現了測試理論和測試實踐相互轉換的過程，其實我們的項目實踐過程中，無時無刻不是這樣的循環，關鍵是我們是否有去刻意關註，並進行刻意練習。

單純的社會實踐，或者單純的理論積累，都會讓這個循環無法對接，達不到互補的效果，只有時刻進行測試理論和測試實踐關聯關系的思考，才能讓良性循環的飛輪轉動起來，並最終形成飛輪效應。

三

今天討論這個事，主要是前兩天有朋友問我「怎麽把具體的東西梳理成體系，形成有指導的理論」。

我覺得上面的解釋，應該可以解答這個問題。

還需要補充一點，實踐和理論的轉化，是一個偏軟技能的意識流問題，不是一個具體的知識點，不可能一蹴而就，她需要經過長時間的鍛煉，最後形成潛移默化的潛意識，最終水到渠成。

關於潛意識，我們還需要進行刻意練習，這樣才能盡快的養成習慣，如何刻意練習呢？我覺得可以從一個個具體的問題出發，碰到每一個問題，都去思考這個問題的本質，問題背後的原理，背後的真實原因等等，反正就是不要被表面的現象所迷惑，久而久之，觀察力就鍛煉出來了，潛意識也就形成了，理論和實踐的轉換就是順理成章的事情了。

以上，本次討論了一些意識流層面的東西，肯定不好理解，那就一字不差地多讀幾遍吧，如果看明白了請點個「好看」讓我知道你的態度，或者轉發給更多人看到，當然，有任何問題歡迎留言和我討論。

關於測試理論和測試實踐的相互轉換