小白的白盒測試之路
需求瞭解篇
接到一個功能的測試，第一步就是了解整個需求，能否將整個需求瞭解透徹直接關係到後續測試工作開展和測試質量；如何在做好需求瞭解呢？下面我們就分析一下。
1. 一個版本開始了，產品找測試和開發講需求，聽聽都是什麼需求。
遇到問題：對於測試而言主要關注這個需求要做一件什麼事，要怎麼做，實現的效果是什麼樣的，解決了什麼樣的問題，做到這些我們已經對這個需求有了一個大概的瞭解，但往往我們會忽略這個需求的細節和關聯功能邏輯的處理，怎樣在需求講解過程中獲得更多的信息呢？
解決辦法：需求講解前做充足的準備，先自己理解一遍需求，對不明確的地方和可能影響的其他模塊功能記錄下來，在會上聽需求過程中解決這些疑問，這樣即有利於自己對需求的把握，也使得需求文檔更詳細，開發在做這個需求時也更明確；
2. 功能提測了，這個需求是什麼來着？
遇到問題：有些需求提出時間很早，但做出來提測的時間比較晚，在提測時測試這邊對需求的邏輯已經很模糊了，重新看需求文檔相當於又瞭解了一遍需求，時間消耗多，需要講解會上大家討論的問題有些沒有及時記錄，導致關注點被遺漏，這該怎麼辦？
解決辦法：按照正常的閱讀習慣，閱讀文字瞭解邏輯通常要比看圖瞭解邏輯慢很多，因此在聽完需求講解後，對每個需求繪製測試邏輯流程圖，在圖上重點標註會上大家討論的部分和分支邏輯，這樣在功能提測時就不會出現還要再瞭解一遍需求的尷尬局面，也不用努力回憶會上大家討論的事情；
3. 找開發問代碼實現，開發說的很詳細，但是好像都沒聽懂，還不好意思說都沒懂，自己回去看要花好長時間，項目delay，加班ing
遇到問題：剛開始做白盒測試的時候經常遇到這種問題，對整體代碼結構不瞭解，去找開發瞭解實現需求時，就直接說我是來了解實現需求的，你能給我講一下嗎，開發帶着你邊看代碼邊講實現邏輯，很是詳細，可是你卻聽得一頭霧水，想着開發還有很多事情要忙，又不好意思總說聽不懂，結果很顯然，只能自己回來慢慢看，測試時間被消耗在看代碼上，導致測試時間delay，每天工作時間很長卻看不到成果。
解決辦法：開始的時候想着現在對整體代碼還不瞭解，等着對全局代碼有了大概的瞭解時就不會這樣了，其實並不是這樣。主要原因是瞭解實現的方法不正確，主要問題有下面幾點：
1) 問問題的方法：你找到開發，問他你是怎麼實現的，你說開發怎麼給你講呢，從哪開始講呢，換位思考一下，一個外國人問你漢語怎麼說，你要怎麼解釋呢；結論是沒法解釋，或你解釋的東西不是他想要的；怎麼問問題呢？
Ø 有範圍的問題：如“這個函數中英文詞覆蓋組詞的邏輯是怎麼實現的呢？”有範圍的問題更容易讓講解者瞭解你想要了解的重點
Ø 帶着問題去問：根據繪製的測試流程圖列出自己想要關注的點，如對外的接口函數，邏輯分支的實現方法，與其他模塊有關聯的部分的處理辦法
Ø 適當打斷講解者：開發講的東西不一定都是你所需要的，而且你集中精力的時間是有限的，對於開發講的你不需要的東西要打斷他，繼續詢問自己關注的問題
2) 鑽牛角尖瞭解與功能無關的複雜邏輯：一個功能的完成很多時候是基於其他功能，我們聽不明白往往是因爲這個功能牽扯的其他邏輯太多，瞭解這些邏輯，時間消耗大，產出低，因此對於這些邏輯，我們只需要知道他們的功能是什麼，怎麼用就可以了，更多的時間放在主線邏輯上
3) 想知道的邏輯要問到底：對必須要瞭解的實現邏輯要問到底，因爲實現過程中越是複雜的邏輯就越是容易出錯，一定要和開發把這個問題弄明白，不能因爲不好意思問和其他個人因素就放棄，這很可能就是一個大問題
如需轉載該篇文章，請註明來自“搜狗測試”