對功能測試的一些思考

功能測試可以說是件簡單的事情，但是想要做好卻並不那麼容易。筆者所測的業務是商業化廣告相關的CRM系統，整條業務線有18個子系統，很多子系統的流程相當長且繁複，功能邏輯複雜，想要上線後沒有漏測著實不容易。不過從我接手以來，有幸還沒有發生大的漏測問題。今天筆者就來聊聊自己對於功能測試的一些個人經驗和思考。

　　接到需求後，我一般會將需要做的工作分為三部分，分別為：需求分析、測試用例、以及測試執行。當然，有一個很重要的大前提，那就是要足夠熟悉你所測的系統。下面就分別來聊聊這三部分。

　需求分析+設計分析

　　拿到一個需求，第一步應該做的就是需求分析。這個環節很多人不在乎，覺得這不是測試的工作，而是產品應該的工作，測試只是把需求文檔簡單的直接翻譯為了自己的測試用例，當測試過程中發現需求文檔不完善的時候說產品沒做好等等。但對我個人工作經驗來講，需求分析這一步至關重要，俗話說磨刀不誤砍柴工，只有做了詳細的需求分析，才能寫出有意義的、正確的測試用例，這就是我個人常說的「需求測試」。

　　需求測試的第一步，需要了解做這個需求是為了什麼？你可能會懷疑，產品說做就做唄，測試管那麼多幹嘛？其實了解需求本身的動機在於以下幾點：

　　1、有些需求是「一次性」的，對於一次性的需求是否有別的方式來實現，如果有我們則可以不去做無用功。所以需求評審的時候，我們可以提出質疑並給出合理的解決方案，減少「一次性」的工作量；

　　2、更好的理解需求本身，該需求是給什麼角色的業務人員使用的，測試可以「站在對方的角度」考慮問題。

　　3、解惑，對於一個需求文檔，很多時候測試做不到百分百的理解的，如果沒有完全理解需求的話，在寫測試用例的時候很有可能給出錯誤的測試用例，或者給出一個粗枝大葉的測試用例，這都不是我們想要的。

　　4、把握測試粒度，以便於正確評估測試工期。例如，一個是給業務人員做的excel上傳功能，一個是給系統管理員做的excel上傳功能，兩者測試粒度是不一樣的。業務人員的功能實現必須詳盡準確，並要覆蓋各種異常處理，而對於項目系統管理員所需的使用上傳功能，大部分時候只要保證正常功能OK，不要求易用性，也不要求各種異常情況處理；

　　5、繪畫需求宏圖，只有根據需求文檔和原型，可以在腦子裡畫出系統最終實現的各種功能時，才能夠說明真正的吃透了這個需求，這時測試用例自然而然就出來了。

　　需求分析的第二步，就是需求中業務功能的實現，一般分為兩部分：

　　一是頁面實現，頁面上每個模塊的實現，每個模塊中每個欄位的實現，這裡我會做一個工作量比較大的梳理，就是每個欄位的取值邏輯，具體到資料庫-數據表-數據欄位，這有的時候可能要在開發做完詳細設計後才能從開發那獲取；

　　二是功能實現，哪個頁面上要做什麼樣的一個功能，以及統計各種業務場景，以及該功能使用的資料庫-數據表-數據欄位以及數據的變化過程。

　　現在很多項目沒有設計評審，這也是目前筆者正在項目內推進落實的一個環節。如果說一個比較大的項目既沒有設計文檔，也沒有設計評審，到最後你會發現，真的好坑啊，專坑測試，有木有~，比如多個開發相互合作但是最後發現確實各自為政，到聯調時發現一堆問題，很容易出現延期提測或者提測質量不達標，還比如一期實現不考慮二期三期，到二期三期時發現一期實現有問題等等；像這種情況，測試有多苦筆者就不說了，自己體會吧~~

　　所以如果沒有設計評審，我也會坐在開發旁邊跟他核對實現方案，包括實現邏輯、配置文件以及使用的資料庫-數據表-數據欄位，以及數據整體的一個流轉過程，也方便書寫測試用例。根據經驗，這個時候其實就已經可以發現開發的一些邏輯bug或者需求理解不一致導致的問題，開發在提測前就能對這些問題做一個修復。這個時候問題解決成本很低，而且對測試而言是一個很大的提升機會，能夠讓測試更加熟悉了解該需求並掌握開發的實現邏輯，有助於測試過程中定位bug產生原因。

　測試用例

　　目前傳統的測試用例越來越少，大多數都是思維導圖方式寫下測試點，筆者寫測試用例主要包括四個方面：

　　1、UI：界面測試，需求要求的各個模塊各個元素，以及隱含的各個元素的通用測試用例；

　　2、業務功能點：對業務功能點的拆分，筆者一般會覆蓋所有的業務場景，包括正向和反向的測試用例，也就是盡量覆蓋到開發的所有代碼分支。

　　3、資料庫：涉及到的數據表-數據欄位；

　　4、配置文件：測試熟悉掌握配置文件，一方面是能夠方便自己排查問題，一方面是提醒開發無遺漏配置文件上線（個人經驗，作用不大但是很重要）。

　　其實這四個方面也是我需求分析、設計分析的四個方面，需求分析做完了，測試用例呼之欲出了。目前總結線上問題，通用測試用例遺漏比較多，例如項目之前沒有考慮過廣告主名稱雙引號問題，通用測試用例沒有考慮各種特殊符號測試，當真的有了帶雙引號的廣告主時，現有平台不支持。至於功能點的遺漏一般比較少，除非產品、開發、測試都不熟悉業務，造成功能點遺漏或者影響其他功能。

執行測試

　　這裡筆者主要講下個人的經驗，每個人的想法和做法不盡相同，僅供參考。筆者一般將測試分為四個階段測試：

　　第一階段：冒煙測試，主流程正向測試用例，不要上來就執行你的詳細測試用例，這樣你會常常受傷。

　　第二階段：就是一輪詳細測試，一輪詳細測試的時候，按照模塊，盡量一次執行完該模塊下的所有測試用例再更新代碼，不要測試過程中開發修改bug後立馬就更新代碼，這樣你回去驗證bug的時候可能打斷了你原有的測試思路；個人習慣是，每天早晨更新代碼，然後模塊測試結束後更新代碼。

　　第三階段：二輪測試，我一般稱之為bug回歸測試，對一輪發現的bug進行回歸測試，以及bug周邊相關功能的再次詳細測試；

　　第四階段：回歸測試，對第三階段發現的bug進行回歸測試（一般比較少，改一個bug帶三個bug的開發雖然有，不過也不常見），以及所有功能的再次詳細測試。

　　以上僅為筆者個人功能測試實施過程中的一些經驗和思考，也歡迎各位測試同仁留言探討。