當前位置:
首頁 > 最新 > 對功能測試的一些思考

對功能測試的一些思考

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

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

需求分析+設計分析

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

GIF

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

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

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

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

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

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

GIF

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

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

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

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

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

測試用例

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

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

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

3、資料庫:涉及到的數據表-數據欄位;

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

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

執行測試

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

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

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

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

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

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

Qtest是360旗下的專業測試團隊!

是WEB平台部測試技術平台化、效率化的先鋒力量!


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 Qtest之道 的精彩文章:

推薦引擎介紹
身為QA,你是否也了解SQL性能優化?

TAG:Qtest之道 |