也談測試核心競争力

作為一名測試人員，究竟其真正的核心競争力是什麼？這個問題一直困惑着我，當我還未曾踏入這一行業的時候，聽到的聲音是這種：“測試是一種非常有前途的工作，需求大于供給”、另一種是這種“測試就要做接觸到代碼的，點點滑鼠誰都……”懷着對于一個行業我也不知道好還是壞，究竟是個什麼玩意的心理選擇并進入了這個行業。

期間，我承認。的确有那麼一段時間，我覺得作為一名測試假設可以對于代碼了如指掌，可以寫出一個個的工具才有可能成為武林的盟主，壽與天齊。

似乎，作為測試來說最核心的競争力就是對于代碼的掌握程度，除此以外，那些什麼功能測試的用例似乎就是個最低端，最沒有價值的産出而已。

可是就今天看來。就我如今自己遇到和看到的一些問題和現象，我開始對自己的一些想法有了挑戰。

比如：如今非常多組都在做和預研一些代碼級别的測試工具，比如覆寫率工具啦，代碼掃描工具了（主要是遵循相關的文法規則做一些比如是否有空指針風險，是否有沒有定義的變量。是否if else的分支條件互相排斥等）、當然另一些高端的通過業務流回溯的方式來對每一條分支進行檢查，僅僅要有風險存在就發出郵件給相應的幹系人。

表面看起來非常的高端。大氣，上檔次，一切都在自己主動化，一切看起來都在掌握之中。

翻手為雲，覆手就可以為雨。

可是實際情況呢？代碼在進行了自己主動掃描也好，覆寫率統計分析也好。終于産品外放後的品質還是體如今了功能測試的實際。實質結果上。這樣說。顯的好晦澀，舉個栗子吧～～～

XX項目，引入了hudson建構自己主動內建方案，而且前背景都有接入，這樣，在開發送出代碼轉測之後，功能測試不出意外會如期進行，代碼背景自己主動掃描。結果也會mail給相應的人。

在一切具備，作為東風的版本号到來之後，噼裡啪啦的就開始了。然後外放。，。然後。，。，然後就苦逼了，～～～為啥？版本号外放之後，“遊戲道具神奇消失。client莫名崩潰、寵物實際得到的數值與預期不一緻，，，，”好吧，你niubility。，，走緊急更新、關外網功能閥門，出公告…….然後就進行了一段研發調試，測試提單，研發分析，測試分析。DAI編寫。QA審計，leader審計的曆程～～～

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

首先：第一個祝福神奇消失，最後找到引起的原由于“前台client在網絡波動較大的時候，server的回報沒有到達client之前。client的button和相關資料沒有重新整理，導緻玩家能夠進行第二次對于button的操作，發出2個請求到server，server在處理完第一個請求，check result為success之後，扣除了玩家的0基礎物品，生成一個進階物品傳回給玩家，，，注意，此時第二個請求到達了server，不湊巧，也是命中了成功的機率。此時server的處理方式為僅僅要機率命中為了避免給我司帶來損失，先扣除用于進化的低等級物品。然後再逐漸扣除其餘的依賴物。終于傳回給玩家高等級物品。這個時候就有問題了，第一個請求的物品成功了，是須要扣除進化道具的，扣除道具後。對于第二個請求來說，實際是不滿足須要的道具數的。可是背景的處理邏輯是僅僅要命中機率，success則覺得就會成功，這個時候為了避免損失。先扣物品，這個時候，到了第二步來扣除道具的時候，發現剩餘金額不足，，，傳回失敗，可是，，，親。人家第一次success成功的道具就特麼的，。，沒了～～～這個代碼覆寫率是OK的（有相應的檢查更新的用例）。代碼掃描也是ok的，由于判空做的非常到位，。，可是這個問題

的root cause是 設計上的缺失，導緻了邏輯處理上存在問題。

這個我們通過自己主動化，僅僅通過閱讀代碼掃描結果是發現不了的。僅僅能通過用例設計的時候去發現，不湊巧，用例設計中沒有這一塊：弱網絡的用例設計。。。進而，say goodbye，僅僅能對玩家報以賣萌一笑，背景log查證再補償玩家了～～～

其次：client異常崩潰。這個問題的root cause又是什麼呢？先用事後的眼睛看，造成client異常崩潰的原由于：client前端的物品重新整理不是實時的（這個能夠了解，由于誰會閑的蛋疼，實時去跟背景做資料查詢的互動，又不是對資料實時性要求非常高的功能，就一個查詢擺攤物品的功能，從CAP的角度來說。的确能夠接受犧牲實時性。

可是，就由于這個原因，當玩家選中的物品攤主在玩家點選購買前下線了，此時這個時候玩家點選購買，不好意思，空指針異常======）core。那麼這個bug為啥沒有通過代碼前期的檢查工作得以暴露呢？原因是：工具本身的不足導緻在做判空檢查時。遇到有break的業務流分支時，不支援業務流分支的檢查（後來聽說引入coverity能夠解決。眼下引入中，可是據說收費也不菲）。

這個bug導緻外網剛一更新就要走一個緊急更新。說實話。當這樣的情況出現多了的時候，哪怕作為測試組你前面加班個十天。半個月在項目組看來，在外人看來都認為你們前面的付出是沒有意義的。由于此時的1決定了你前面的付出等于一萬個零。

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

那麼說了這麼多，對于測試來說最基本的核心競争力是什麼呢？我個人認為能否夠了解為下面幾點：

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

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

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

4、  總結。

此特技主要用于經驗的擷取。等級的提升，邁向高富帥

最後，僅僅想說，在知道做正确的事情之後應該要思考如何正确的做事。僅僅有這樣才幹在對的方向上越走越遠，當然，我并非就說我的了解就是對的，僅僅是本着獨思而無友，必孤陋而寡聞的心态，在此借地跟大家做一個交流。

夥伴們。我們是不是又到了該思考，如何建構一個用例設計體系（通用體系）集我測試衆人的精華構築的一個用例生産體系的時候了。

這樣，結合我們的代碼掃描和覆寫率進而更好的保障外網品質，獲得很多其它更高的認可呢？

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