也談軟件測試工程師的核心競爭力是什么

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

　　但是就今天看來，就我現在自己遇到和看到的一些問題和現象，我開始對自己的一些想法有了挑戰。例如：現在很多組都在做和預研一些代碼級別的測試工具，例如覆蓋率工具啦，代碼掃描工具了(主要是遵循相關的語法規則做一些例如是否有空指針風險，是否有未定義的變量，是否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決定了你前面的付出等于一萬個零。

原文轉自：blog.csdn.net/yzongyu/article/details/25075385#1536434-tsina-1-62095-66a1f5d8f89e9ad52626f6f40fdeadaa