作為一名測試人員，到底其真正的核心競爭力是什麼？這個問題一直困惑著我，當我還未曾踏入這一行業的時候，聽到的聲音是這樣的：“測試是一種很有前途的工作，需求大於供給”、還有一種是這樣的“測試就要做接觸到程式碼的，點點滑鼠誰都……”懷著對於一個行業我也不知道好還是壞，到底是個什麼玩意的心理選擇並進入了這個行業。期間，我承認，的確有那麼一段時間，我認為作為一名測試如果能夠對於程式碼瞭如指掌，能夠寫出一個個的工具才有可能成為武林的盟主，壽與天齊。似乎，作為測試來說最核心的競爭力就是對於程式碼的掌握程度，除此以外，那些什麼功能測試的用例似乎就是個最低端，最沒有價值的產出而已。

但是就今天看來，就我現在自己遇到和看到的一些問題和現象，我開始對自己的一些想法有了挑戰。例如：現在很多組都在做和預研一些程式碼級別的測試工具，例如覆蓋率工具啦，程式碼掃描工具了（主要是遵循相關的語法規則做一些例如是否有空指標風險，是否有未定義的變數，是否if else的分支條件互斥等）、當然還有一些高階的通過業務流回溯的方式來對每一條分支進行檢查，只要有風險存在就發出郵件給對應的干係人。表面看起來非常的高階，大氣，上檔次，一切都在自動化，一切看起來都在掌握之中。翻手為雲，覆手即可為雨。但是實際情況呢？程式碼在進行了自動掃描也好，覆蓋率統計分析也好，最終產品外放後的質量還是體現在了功能測試的實際，實質結果上。這樣說，顯的好晦澀，舉個栗子吧～～～

XX專案，引入了hudson構建自動整合方案，並且前後臺都有接入，這樣，在開發提交程式碼轉測之後，功能測試不出意外會如期進行，程式碼後臺自動掃描，結果也會mail給對應的人。在一切具備，作為東風的版本到來之後，噼裡啪啦的就開始了，然後外放，，，然後，，，，然後就苦逼了，～～～為啥？版本外放之後，“遊戲道具神祕消失，客戶端莫名崩潰、寵物實際得到的數值與預期不一致，，，，”好吧，你niubility，，，走緊急更新、關外網功能閥門，出公告…….然後就進行了一段研發除錯，測試提單，研發分析，測試分析，DAI編寫，QA審計，leader審計的歷程～～～

其實，引起這些問題的根本原因在找到之後，我們事後來看，都會覺得，為蝦米？這樣的問題應該很容易想到啊？我只想說，事後人人都知道赤壁之戰的當晚要注意防風，不能報以黑天鵝的心態，何況在事前我們可能根本都不知道還有天鵝一說，就更加別說什麼黑與白了。什麼意思？別急，給我點時間打字，慢慢碼～～～

首先：第一個祝福神祕消失，最後找到引起的原因為“前臺客戶端在網路波動較大的時候，伺服器的回報沒有到達客戶端之前，客戶端的button和相關資料沒有重新整理，導致玩家可以進行第二次對於button的操作，發出2個請求到伺服器，伺服器在處理完第一個請求，check result為success之後，扣除了玩家的初級物品，生成一個高階物品返回給玩家，，，注意，此時第二個請求到達了伺服器，不湊巧，也是命中了成功的概率，此時伺服器的處理方式為只要概率命中為了避免給我司帶來損失，先扣除用於進化的低等級物品，然後再逐步扣除其餘的依賴物，最終返回給玩家高等級物品。這個時候就有問題了，第一個請求的物品成功了，是需要扣除進化道具的，扣除道具後，對於第二個請求來說，實際是不滿足需要的道具數的，但是後臺的處理邏輯是隻要命中概率，success則認為就會成功，這個時候為了避免損失，先扣物品，這個時候，到了第二步來扣除道具的時候，發現餘額不足，，，返回失敗，但是，，，親，人家第一次success成功的道具就特麼的，，，沒了～～～這個程式碼覆蓋率是OK的（有對應的檢查升級的用例），程式碼掃描也是ok的，因為判空做的很到位，，，但是這個問題 的root cause是 設計上的缺失，導致了邏輯處理上存在問題。這個我們通過自動化，僅僅通過閱讀程式碼掃描結果是發現不了的。只能通過用例設計的時候去發現，不湊巧，用例設計中沒有這一塊：弱網路的用例設計，，，從而，say goodbye，只能對玩家報以賣萌一笑，後臺log查證再補償玩家了～～～

其次：客戶端異常崩潰，這個問題的root cause又是什麼呢？先用事後的眼睛看，造成客戶端異常崩潰的原因為：客戶端前端的物品重新整理不是實時的（這個可以理解，因為誰會閒的蛋疼，實時去跟後臺做資料查詢的互動，又不是對資料實時性要求很高的功能，就一個查詢擺攤物品的功能，從CAP的角度來說，的確可以接受犧牲實時性。但是，就因為這個原因，當玩家選中的物品攤主在玩家點選購買前下線了，此時這個時候玩家點選購買，不好意思，空指標異常======）core。那麼這個bug為啥沒有通過程式碼前期的檢查工作得以暴露呢？原因是：工具本身的不足導致在做判空檢查時，遇到有break的業務流分支時，不支援業務流分支的檢查（後來聽說引入coverity可以解決，目前引入中，但是據說收費也不菲）。這個bug導致外網剛一更新就要走一個緊急更新，說實話，當這種情況出現多了的時候，哪怕作為測試組你前面加班個十天，半個月在專案組看來，在外人看來都覺得你們前面的付出是沒有意義的，因為此時的1決定了你前面的付出等於一萬個零。

好了，這樣的例子不舉了，總之，當我遇到的問題越來越多，對於根本原因查詢進行思考後，我現在開始會問自己，作為測試的從業者來說，程式碼的掌握程度是否真如傳說的那麼高階，重要，不可替代？還是說，我們的方向錯了，我們作為一名測試從業者來說，對於武器的選擇上太過於神話某種道具了，以為得此神器則天下可定？可實際結果，往往大相徑庭。

那麼說了這麼多，對於測試來說最主要的核心競爭力是什麼呢？我個人覺得是否可以理解為以下幾點：

1、  快速學習和思考的能力，此特技主要用於需求快速理解，提升問題發現深度和效率，廣度。

2、  問題發散能力。此特技主要用於對於影響面的歸納和總結，覆蓋

3、  溝通，協調能力。此特技主要用於推動問題的解決和資源間的合理協調，保障專案上人品配比的需求

4、  總結。此特技主要用於經驗的獲取，等級的提升，邁向高富帥

最後，只想說，在知道做正確的事情之後應該要思考怎樣正確的做事，只有這樣才能在對的方向上越走越遠，當然，我並不是就說我的理解就是對的，只是本著獨思而無友，必孤陋而寡聞的心態，在此借地跟大家做一個交流。夥伴們，我們是不是又到了該思考，如何構建一個用例設計體系（通用體系）集我測試眾人的精華構築的一個用例生產體系的時候了。這樣，結合我們的程式碼掃描和覆蓋率從而更好的保障外網質量，獲得更多更高的認可呢？

-----------------一個屌絲測試工作者