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

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

發(fā)表于：2023-07-16來源：DiggerPlus：陳永達點擊數(shù)：標(biāo)簽：

作為一名測試人員，到底其真正的核心競爭力是什么?這個問題一直困惑著我，當(dāng)我還未曾踏入這一行業(yè)的時候，聽到的聲音是這樣的：“測試是一種很有前途的工作，需求大于供給”、還有一種是這樣的“測試就要做接觸到代碼的，點點鼠標(biāo)誰都……”懷著對于一個行業(yè)我也不知道好還是壞，到底是個什么玩意的心理選擇并進入了這個行業(yè)。期間，我承認，的確有那么一段時間，我認為作為一名測試如果能夠?qū)τ诖a了如指掌，能夠?qū)懗鲆粋€個的工具才

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

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

XX項目，引入了hudson構(gòu)建自動集成方案，并且前后臺都有接入，這樣，在（開發(fā)）提交代碼轉(zhuǎn)測之后，功能測試不出意外會如期進行，代碼后臺自動掃描，結(jié)果也會mail給對應(yīng)的人。在一切具備，作為東風(fēng)的版本到來之后，噼里啪啦的就開始了，然后外放，，，然后，，，，然后就苦逼了，～～～為啥?版本外放之后，"游戲道具神秘消失，客戶端莫名崩潰、寵物實際得到的數(shù)值與預(yù)期不一致，，，，'好吧，你niubility，，，走緊急更新、關(guān)外網(wǎng)功能閥門，出公告.然后就進行了一段研發(fā)調(diào)試，測試提單，研發(fā)分析，測試分析，DAI編寫，QA審計，leader審計的歷程～～～

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

首先：第一個祝福神秘消失，最后找到引起的原因為"前臺客戶端在網(wǎng)絡(luò)波動較大的時候，（服務(wù)器）的回報沒有到達客戶端之前，客戶端的button和相關(guān)數(shù)據(jù)沒有刷新，導(dǎo)致玩家可以進行第二次對于button的操作，發(fā)出2個請求到（服務(wù)器），服務(wù)器在處理完第一個請求，checkresult為success之后，扣除了玩家的初級物品，生成一個高級物品返回給玩家，，，注意，此時第二個請求到達了服務(wù)器，不湊巧，也是命中了成功的概率，此時服務(wù)器的處理方式為只要概率命中為了避免給我司帶來損失，先扣除用于進化的低等級物品，然后再逐步扣除其余的依賴物，最終返回給玩家高等級物品。這個時候就有問題了，第一個請求的物品成功了，是需要扣除進化道具的，扣除道具后，對于第二個請求來說，實際是不滿足需要的道具數(shù)的，但是后臺的處理邏輯是只要命中概率，success則認為就會成功，這個時候為了避免損失，先扣物品，這個時候，到了第二步來扣除道具的時候，發(fā)現(xiàn)余額不足，，，返回失敗，但是，，，親，人家第一次success成功的道具就特么的，，，沒了～～～這個代碼覆蓋率是OK的(有對應(yīng)的檢查升級的用例)，代碼掃描也是ok的，因為判空做的很到位，，，但是這個問題的rootcause是設(shè)計上的缺失，導(dǎo)致了邏輯處理上存在問題。這個我們通過自動化，僅僅通過閱讀代碼掃描結(jié)果是發(fā)現(xiàn)不了的。只能通過用例設(shè)計的時候去發(fā)現(xiàn)，不湊巧，用例設(shè)計中沒有這一塊：弱網(wǎng)絡(luò)的用例設(shè)計，，，從而，saygoodbye，只能對玩家報以賣萌一笑，后臺log查證再補償玩家了～～～

其次：客戶端異常崩潰，這個問題的rootcause又是什么呢?先用事后的眼睛看，造成客戶端異常崩潰的原因為：客戶端前端的物品刷新不是實時的(這個可以理解，因為誰會閑的蛋疼，實時去跟后臺做數(shù)據(jù)查詢的交互，又不是對數(shù)據(jù)實時性要求很高的功能，就一個查詢擺攤物品的功能，從CAP的角度來說，的確可以接受犧牲實時性。但是，就因為這個原因，當(dāng)玩家選中的物品攤主在玩家點擊購買前下線了，此時這個時候玩家點擊購買，不好意思，空指針異常======)core。那么這個（bug）為啥沒有通過代碼前期的檢查工作得以暴露呢?原因是：工具本身的不足導(dǎo)致在做判空檢查時，遇到有break的業(yè)務(wù)流分支時，不支持業(yè)務(wù)流分支的檢查(后來聽說引入coverity可以解決，目前引入中，但是據(jù)說收費也不菲