本文由玩蟹科技測試部總監張敬峰獨家投稿，授權遊戲葡萄發布。即使我們允許，也不能轉載。

滿眼bug難，一把辛酸淚。都雲測試苦，誰解其中味？

當大家都在對一款S級産品侃侃而談時，當大家激動着歡呼月流水破億時，當大家贊美遊戲的設計多麼牛x時，一群測試工程師還在默默的測試着即将上線的功能。在缤紛閃耀的舞台上很難看到他們的面孔，在寂靜的深夜卻總是留下他們疲倦的背影。

記得筆者曾經跟心存困惑的測試兄弟們說過，在成功的産品面前，有些人是台前英雄，有些人是幕後英雄，而我們測試人員則是幕後的幕後英雄。各種辛酸，如魚飲水，冷暖自知。

一款産品的研發與運營的成功，有很多因素促成，比如設計層面的、IP層面的、運營層面的等等，然而容易被大家忽視的也時常被大家忽視的一個層面則是來自于産品質量。毫無疑問的是，質量關乎産品的生死成敗。

那麼在一款S級産品成功研發與運營的背後，為了在緊迫的節奏下保障産品質量，測試人員又面臨着怎樣的挑戰與困境呢？筆者結合實際S級項目經驗，就以下幾個層面跟各位同仁一起談一談在研發與運營過程中測試人員面臨的各種挑戰和困境。

挑戰一

版本管理

“這個bug怎麼沒測出來啊？”

“啊，這個怎麼上線了，我x，怎麼不經過測試就直接把代碼提到線上了？”

這樣的對話，是不是大家都經曆過呢？有時候面對一個bug或嚴重事故時，開發人員會感到很委屈，沒人告訴我不能提交啊？或者已經被混亂的分支搞得頭昏眼花，一不留神就提上去了。測試人員也感到很委屈，根本不知道代碼已經提到線上了，而這個功能還沒測試或沒測試完畢。

雖然大家都感到很委屈，但是事故已經發生了，怎麼辦？

項目上線運營之後，可能同時存在N個開發分支，混亂的提交代碼導緻的bug可能會成為導緻線上事故的主要因素。而出了問題首要被問責的往往是測試人員，面對這個困局，隻能嚴格做好代碼分支管理和提交規範，以及最後的提交内容檢查。從邏輯上來講，既然我們不應該相信開發人員寫的代碼，那麼我們也沒理由相信他們的提交操作。

為此我們嘗試在某些項目做了一個excel格式的檢查列表，如下圖：

證據确鑿，簽字畫押，辦法是土了一些，貌似還挺管用～

挑戰二

Bug與事故管理

由于我們每個個體都存在着認知局限性，所以對同一件事物，有的人看到的是一個點，有的人看到的是一條線，有的人看到的是一張平面，有的人卻看到了三維立體圖形。這個理論對于bug與事故也是成立的，我們提出的一條條bug并非是冰冷的無生命的存在，如果大家用心挖掘的話，這些bug數據能為我們提供非常多的理論和決策支持。

很多人認為Bug提出了并被修複了就行了，為什麼還要花精力去對這些數據進行數據挖掘呢？有那時間也許我能多發現幾個bug了。如果大家還是這樣的思維，那麼可能你還停留在體力勞動層面，還沒有把測試工作上升到腦力勞動層面。這樣做的根本原因是為了解決下面的2個問題：

1.我們總是習慣在同一個地方犯錯，不斷的踩同樣的坑

2.精細化的項目管理需要真實數據支撐

舉2個小例子，來說明下bug和事故挖掘能為我們提供哪些數據支持。

例子一：bug數據有利于我們統計出遊戲中哪個模塊容易出現問題，見下圖

例子二：bug數據有利于我們統計出開發人員的技術穩定性，見下圖

可提取的數據非常多，這裡就不一一列舉，這些數據可以應用到項目下一階段的版本中，為我們測試工作提供參考，或者為其它項目提供一些數據參考。

挑戰三

人員數量與管理的困境

筆者曾經在不同的場合多次被問過，一個手遊項目中配備多少個測試人員比較合适？其實這個問題沒有标準答案的，跟每個項目的做事風格，遊戲的類型，團隊的協同效率等都有關系，很難說出一個完美的答案。

不過根據筆者經曆過的多個項目經驗而言，每2個開發人員配備1個測試人員是相對合理的。在2:1的配比下，開發和測試能夠很好的協同工作，發揮出的效率相對較高，當然這個不是絕對的，比例稍微差異也不大影響，但是如果差别較大，無論是多配還是少配置，都會一定程度影響整個項目的工作效率。

另一個經常被問到的問題是，項目現在很掙錢，但是還是偶爾會出現一些線上事故，我們能不能多加幾個測試來降低事故率？相信這個狀況不僅僅是測試的同仁遇到過，可能項目裡各個職能團隊都會遇到過這個問題。一個項目就像一頭饕餮巨獸，總是想法設法的吞噬可争取到的盡可能多的資源，尤其是在掙錢的階段，這本身并沒有問題，問題是人多了，真的能解決問題麼？

對于這個問題，筆者覺得每個團隊的負責人都需要深刻的思考一下。有沒有可能加人會導緻反作用？人多了，問題沒解決，反而線上出現更多的事故。筆者認為是否應該加人應該考慮兩方面因素：導緻線上出事故的本質和測試組長的管理能力。

如果線上事故不是因為人少測不過來導緻的，而是其他一些因素比如項目流程導緻的，那麼我們随便加人可能導緻更加嚴重的後果，因為嘗試解決問題的方向錯了。

如果确實因為測試人員過少導緻線上事故頻發，我們優先考慮的問題可能并不是增加人手，而是目前的這個測試組長是否有能力帶領更大的團隊。古人雲：一将無能，累死三軍。如果組長能力夠的話，果斷加人就能讓問題立竿見影，如果組長能力不夠，可能首先要做的是尋覓一個能力更高的組長。

挑戰四

測試覆蓋度的挑戰

在上面挑戰一中我們談到的胡亂提交代碼導緻的線上事故，這種我們可以看作是與測試關聯不大的外部因素，這裡我們繼續談談可能導緻線上事故的内因，那就是測試不充分，出現盲點。

每當發布版本時，我們是不是都懷着忐忑的心情？我們很難預料這個版本是不是還有未發現的bug，曾經有些時刻，當鼠标點下去的那一刹那，我的心是顫抖的。為了讓自己對版本更有信心，更心安理得一些，我和我的同事們在某些測試關鍵節點做了一些改良，總結了一下，大概有下面幾個方面：

1.盡早的開始測試。甚至不必等一個功能完全開發完畢，隻要某些部分是大概完整的，我們就可以開始測了，這樣能盡早的暴露出缺陷和漏洞，為後續的工作争取更多的時間。

2.可選項：交叉測試。交叉測試其實是老生常談了，大家都知道交叉測試能避免很多測試的盲點。但在一個手遊項目，尤其是快速叠代的項目，功能從開發到上線可能隻有一兩天時間，如果固守交叉測試的思維，時間根本不允許。所以交叉測試變成了一個可選項，版本緊迫時就果斷放棄，時間充裕時則一定進行。

3.bug和事故分享。每周定期進行本周bug和事故會議，花一點時間，讓大家了解到工作中存在的不足，吸取以往的經驗并給大家一個警醒作用。

4.必選項：版本上線前作checklist檢查。迫于版本叠代速度，很多功能可能連完整跑一遍測試用例都變的不太可能，而遊戲各個功能之間藕合度又比較高，很難預料一個功能的修改是不是會導緻别的功能出bug。面對這種兩難的境況，我們怎麼辦才能保證測試覆蓋度？通過實際驗證，版本上線前集中精力做全功能的checklist不失為一個恰當的選擇。通過checklist我們幾乎可以覆蓋到遊戲的所有功能，雖然精細度不夠，但可以就每個功能的核心點都做一遍檢查，在保證版本進度的基礎上确保核心點不出問題。既然不能大而全，我們就小而精。

額外說一點亡羊補牢的題外話，版本發布後，并非萬事大吉，還需要我們繼續觀察一段時間，及時了解玩家反饋。如果發現問題，盡量第一時間解決。

挑戰五

與策劃程序不得不說的故事

策劃、程序員與測試在傳說中是基情四射的小夥伴，如同鐵三角般在一起快樂的生活，然而殘忍的現實總是讓他們之間充滿争吵，紛紛擾擾，剪不斷，理還亂。說好的策馬奔騰共享人世繁華呢？一聲長歎，其實我隻想靜靜。

很多時候劍拔弩張并不是要分出個勝負，而是找個機會宣洩下長久積壓的壓力，讀書人的事，辯論一下能叫吵架麼？

其實大家真正關心的核心隻有一個，那就是時間。測試抱怨程序代碼寫的慢，留給測試的時間太少。程序員抱怨策劃的需求總是變來變去，立字據都沒用。策劃則委屈的說你們懂個x，我能不變麼，我又不是神，況且boss一個眼神已經把我秒了。。。

于是這個抱怨怪圈一直在時空中旋轉着，直到某個英雄駕着七彩祥雲降落凡間。他帶給我們一件管理利器：進度管理。良好的進度管理能很大程度上幫助我們控制住項目研發這匹脫缰野馬，讓各個環節的時間安排更加科學合理，減少各個環節的抱怨。

那麼我們實際是怎麼做的呢？有鑒于google sheet被牆，我們隻能用相對低端一些的excel svn來解決決這個問題。當然可能還存在其它好用的工具，我們并沒有花太多精力在工具本身上，因其非關鍵因素，關鍵的是整個項目要有進度管理的思維并認同這種思維。無圖無真相，小夥伴們請看下圖（項目實際進度管理表，雖非假語村言，真名還是隐去，請小夥伴們見諒）：

自從進度管理做好後，策劃、程序員與測試又可以一起快樂的玩耍了～

挑戰六

資源利用與協調

對于一名測試工程師，發現缺陷，保證負責的工作不出問題，在筆者看來也僅僅能夠打60分，勉勉強強及格。要想獲得優秀并非易事，意味着我們要付出很多額外的時間和精力去做好各種銜接工作。這樣的事情比較多而雜，比如幫客服同事确認用戶的反饋，與平台部門的人合作接入sdk，每天核對項目進度，配合運營同事驗證活動，為其它部門提供一些測試數據等等。

為了把這些看似額外的工作做好，單靠我們自身的力量顯然是不夠的，要善于利用和協調資源，借外力為己用。為了做好資源協調與利用，我們大概可以從3個方向進行：

1.工具方向：如何在雜亂的事情中理出頭緒并避免遺忘？一些在線雲筆記，貌似是不錯的選擇，做完劃勾，簡單輕松。為了避免廣告的嫌疑，這裡就不直接提供名字了。還有其他的為了方便工作的工具也可以多網上搜索一些，工欲善其事，必先利其器。

2.思路方向：在工作中，可能我們無法搞定所有的事情，我們要學會借力，任何領導和協作部門都可以看作是可利用的資源。要學會向他們争取支持，拓展可使用資源的來源，從而完成一些不可能的任務。

3.态度方向：保持微笑着與其他部門協調合作。無論事情能不能搞定，保持一個良好的态度，總會有更多的機會，也能為以後的合作打下良好的基礎，畢竟不是一錘子買賣。

挑戰七

責任與擔當

測試在整個項目中起着一個承上啟下的作用，上銜研發環節，下接運營環節。做好了錦上添花，做不好怨聲載道。

測試也是項目事故的首要被問責人，除了勇敢的承擔之外，更重要的是要總結分析每一次事故，沉澱經驗教訓，争取下一次不再犯同樣的錯誤。如果不做總結反思，還不如不承擔。如果一個人連承擔責任的勇氣都沒有的話，那麼也意味着這個人喪失了繼續前進的機會。我是測試，我為測試代言，我們都有一顆勇敢的心。

測試要簡單可以做的很簡單，點點遊戲就可以了。要做的複雜也可很複雜，可以幫程序員做單元測試，可以做服務端壓力測試，可以做客戶端性能測試，可以做sdk測試等等。就看我們能夠承擔多大的責任，能夠挑戰怎樣的困境，能否超越昨天的自我。

面對無盡的黑夜，回首昨日的榮耀，我們将繼續奮力前行，畢竟，我們的征途是星辰大海！

作者簡介

張敬峰，計算機專業科班出身，但代碼能力是個戰5渣。早年是光榮的鋼鐵工人，後來抱着對遊戲的無限熱愛，投身遊戲圈，入坑較深。長期在項目一線做測試和測試管理工作，參與過《刀劍英雄》、《大決戰》、《亞特蘭蒂斯之龍》、手遊版《英雄無敵》等衆多項目的質量保證過程。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部