前言

個(gè)人認(rèn)為，qa的終極目標(biāo)是保證自己負(fù)責(zé)的需求功能模塊上線后無bug。然而實(shí)際的生產(chǎn)環(huán)境中，總是或多或少的出現(xiàn)一些嚴(yán)重程度不一的線上bug，我們?nèi)绾伪苊饽?？同時(shí)，在測試環(huán)境下如何做到側(cè)無遺漏，對(duì)于自己的測試質(zhì)量充滿自信呢？

分析

簡單的總結(jié)分析出現(xiàn)線上bug的成因：

• 生產(chǎn)環(huán)境與開發(fā)、測試環(huán)境存在一些差異
  這里所提到的差異，指的是玩家身上數(shù)據(jù)的多樣性。每個(gè)玩家的游戲數(shù)據(jù)都不相同，QA在測試工作開展時(shí)無法模擬每一種玩家攜帶數(shù)據(jù)的情況。
  舉個(gè)bug例子：
  玩家A是游戲大佬，背包內(nèi)存放著稀有道具孽火結(jié)晶，其在結(jié)束一場活動(dòng)副本玩法后，玩家A發(fā)現(xiàn)背包內(nèi)的孽火結(jié)晶丟失了。
  QA在測試環(huán)境中使用的賬號(hào)并不會(huì)攜帶所有已投放的道具，這便造成了上述所說的差異之一。
  這時(shí)，就會(huì)有人說那我們每次測試前將背包內(nèi)塞滿已投放的道具不就行了。說的很有道理，不過換個(gè)角度想想：如果我們的游戲內(nèi)容非常龐大、不僅有道具、還有時(shí)裝、坐騎、家具等等，按照這個(gè)說法我們繼續(xù)發(fā)散思維，那豈不是像滾雪球一樣，需要添加的東西越來越多呢。
  我們再深入思考，這僅僅是物品上的差異，mmorpg游戲玩家角色數(shù)值的差異呢，卡牌游戲玩家卡牌的養(yǎng)成數(shù)據(jù)差異呢？
• QA對(duì)功能實(shí)現(xiàn)理解的不夠透徹，導(dǎo)致測試深度過淺
  QA在功能完成后，需要對(duì)程序的實(shí)現(xiàn)邏輯進(jìn)行了解。在不看代碼的基礎(chǔ)上，我們可以根據(jù)程序的邏輯上的一些關(guān)鍵點(diǎn)，進(jìn)行用例的設(shè)計(jì)補(bǔ)充或者修改，這樣才能提高測試的深度，而不是只簡單的設(shè)計(jì)客戶端上我們能夠看到的功能測試用例。
  舉個(gè)例子：
  現(xiàn)在有一個(gè)排行榜，新老玩家都能查看，需求評(píng)審會(huì)議定下的規(guī)則是：15分鐘上傳一次玩家數(shù)據(jù)，1小時(shí)刷新一次玩家排行榜。
  這時(shí)，不了解程序?qū)崿F(xiàn)邏輯的話，我們可能關(guān)注點(diǎn)會(huì)著重于刷新以及排行榜上的內(nèi)容顯示、以及新老玩家這幾個(gè)點(diǎn)。如果只是這樣設(shè)計(jì)用例的話，遠(yuǎn)遠(yuǎn)還不夠。
  了解程序邏輯之后，得知有一個(gè)實(shí)現(xiàn)流程為：新玩家進(jìn)入游戲時(shí)，程序代碼便開始走入上述的規(guī)則。此時(shí)我們便開始思考，如果玩家第一次進(jìn)入游戲處于新手流程階段且還未取名并在這期間停留了15分鐘以上未操作游戲，那么會(huì)怎么樣。于是我們將其納入在功能開發(fā)完成前就寫好的測試用例中。
  ps：該情況最后的結(jié)果便是，玩家接著操作游戲至取名結(jié)束，進(jìn)入游戲查看榜單時(shí)會(huì)發(fā)現(xiàn)自己的游戲名字變成了自己的游戲ID；又因?yàn)?小時(shí)刷新一次排行榜，所以如果玩家是取完名字一小時(shí)后才查看的榜單，根本不會(huì)發(fā)現(xiàn)這個(gè)bug。
  這一點(diǎn)，我們很容易的就看的出來。如果我們不提前了解程序邏輯，我們是不會(huì)知道上傳數(shù)據(jù)的流程點(diǎn)，進(jìn)而導(dǎo)致測試的深度不夠。
  當(dāng)然，了解程序邏輯的還有一個(gè)好處便是，方便我們對(duì)功能的接口進(jìn)行測試。這點(diǎn)暫時(shí)在這先不細(xì)說，后續(xù)開新隨筆再聊
• 需求文檔分析做的不夠好
  這種情形會(huì)出現(xiàn)兩個(gè)主要問題
  一、導(dǎo)致QA驗(yàn)證標(biāo)準(zhǔn)不明確，造成QA不知道這是bug。
  二、分析考慮不全面，導(dǎo)致后續(xù)用例設(shè)計(jì)不全面
  舉個(gè)最簡單的例子：
  需求文檔內(nèi)寫到，收到新郵件時(shí)，郵件上會(huì)有一個(gè)紅點(diǎn)提示。
  文檔分析沒做好，便會(huì)造成QA錯(cuò)誤的認(rèn)知現(xiàn)象：需求上寫著有一個(gè)紅點(diǎn)提示，嗯，沒問題，有紅點(diǎn)就可以了。但是真的就這樣嗎？如果QA真的覺得這個(gè)需求沒問題的話，那么在測試用例階段，也只會(huì)設(shè)計(jì)：收到新郵件時(shí)郵件上出現(xiàn)一個(gè)紅點(diǎn)。測試時(shí)，新郵件的右上角確實(shí)是有一個(gè)紅點(diǎn)，QA可能就認(rèn)為這個(gè)需求沒問題了。等到生成環(huán)境下玩家反饋后，才知道這個(gè)原來是bug。
  以上面的例子來說，文檔分析時(shí)，我們就需要和策劃明確紅點(diǎn)的顯示路徑是什么，同時(shí)還要結(jié)合郵件系統(tǒng)的其他需求進(jìn)行一個(gè)聯(lián)動(dòng)的考慮，以及提出一些缺失的設(shè)計(jì)內(nèi)容是否需要補(bǔ)充，例如郵件是否需要回收，玩家間是否需要可以發(fā)郵件等等設(shè)計(jì)層面的東西。
• 用例設(shè)計(jì)不夠全面
  這一點(diǎn)簡單了，QA測試肯定是都需要按照測試用例上寫明的測試點(diǎn)來測試。如果測試點(diǎn)都缺了，按測試過程肯定就會(huì)遺漏。一開始都沒想到的一堆點(diǎn)，難不成測試過程就能全部想到了嗎？
• 缺少用例review的過程
  用例review也是較為簡單，就是在用例設(shè)計(jì)完成后，組內(nèi)的QA開會(huì)聽設(shè)計(jì)者對(duì)玩法介紹，講解用例的測試點(diǎn)，同時(shí)大家進(jìn)行頭腦風(fēng)暴提出自己的觀點(diǎn)溝通交流，設(shè)計(jì)者可能因?yàn)榻?jīng)驗(yàn)不足亦或者對(duì)游戲不夠熟悉等問題造成的用例設(shè)計(jì)測試點(diǎn)遺漏
• 測試經(jīng)驗(yàn)的不足
  這個(gè)就不必多說了，顧名思義

總結(jié)
分析內(nèi)說了那么多，其實(shí)提到了測試流程內(nèi)的幾個(gè)環(huán)節(jié)。每個(gè)公司測試工作流程可能都不一樣，但是核心還是不變的，有需求分析、設(shè)計(jì)測試用例。有差別的地方就是整體環(huán)節(jié)的好壞以及合理程度。
前言說道：在測試環(huán)境下如何做到側(cè)無遺漏，對(duì)于自己的測試質(zhì)量充滿自信呢？這在分析中其實(shí)都有提到了。側(cè)無遺漏，最好的保障方法便是做好需求文檔分析、設(shè)計(jì)出好的測試用例，加入用例review環(huán)節(jié)。對(duì)測試質(zhì)量充滿自信的方法除了側(cè)無遺漏所提到的，最重要的就是深入了解功能玩法的實(shí)現(xiàn)邏輯，以及策劃設(shè)計(jì)的玩法規(guī)則，做好接口協(xié)議測試，必要且有能力時(shí)輔以白盒測試。