如何讓測試用例覆蓋性最強(轉)

對專業的 測試人員來講，編寫 測試用例並不陌生，可是如何編寫覆蓋性強的測試用例，就須要咱們再三思考後落筆哦~

　　首先咱們來想下測試用例的前世此生：

　　1.測試用例因何產生？

　　2.測試用例爲誰而寫？

　　這兩個問題咱們各用一句話來回答：測試用例是產品原型下的衍生物，爲想要了解這個系統（需求）的人而寫，且隨着產品原型的調整及時更新。

　　瞭解一個系統更多時候不是從已經使用的案例中抽取其中之一做爲了解對象，而是從需求原型中，梳理分析，整合成測試用例來幫助用戶去理解。而一個覆蓋性強的測試用例，能夠保障系統的強健性。

 

　　從大的方面講，測試用例分爲 功能測試、非功能測試兩個方面；

　　 增刪改查是基礎，也是重中之重。這一點不只咱們測試人員重視，研發也一樣瞭解，所以在提測以前，增刪改查的部分大多數狀況下已經由研發人員驗證過一次。若非如此，測試人員仍是有權力拒測或執行一鍵駁回的，直到醒目達到最基本的提測狀態。

　　 GUI頁面檢查以及元素驗證。這類驗證幾乎在咱們的平常工做中均有涉及，從設備來說PC項目，移動端（ Android，IOS）；從系統應用來講，辦公系統，娛樂網站，直播平臺，交易系統等等，均離不開用戶與系統之間的交互。能夠說，GUI部分的驗證佔據了測試人員大量的工做時長，因此咱們回顧羅列的測試用例，大範圍陳述了頁面元素的驗證：字符限長，非法驗證，非空校驗，提示語，二次彈窗，非空集合等等。這部分工做繁瑣冗長，每每是研發人員忽視的部分，稍有不慎就會引起問題，須要測試人員從不一樣角度屢次驗證。

　　 數據準確性。咱們在驗證數據準確性的時候，更多側重於已經產生的數據，在數據的生命週期中驗證其準確性，每每忽視了數據的初始化及消亡兩個極端。以往我測試過一個WEB系統，測試數據是由研發人員導入的線上數據，可是在測試過程當中，發現這批線上測試數據的生命週期並無異常，反而是我本身經過系統導入的初始數據，在接下來的頁面交互中出現很多問題。這就涉及到了前端如何處理初始數據的問題，假如本身一樣忽視數據的產生，上線後，就是引起測試事故的重要 漏洞。

　　 業務邏輯的正確性。這個問題每每是產品原型產生初期就被遺漏的問題，帶來的後果是用戶體驗度差。舉個例子，用戶經過手持端進入領取優惠頁面，一系列驗證用戶操做完畢後，提示領取成功。如今，做爲一個用戶，大多數狀況下應該會找使用優惠券的入口，或者去查看這個優惠券如何使用。然並卵，產品經理忽視了最終的體驗對象，只是將用戶領取優惠完成來當作這一動做的終結。因此說，測試不單單是去驗證產品原型，還要考慮業務邏輯是否正常。

　 　後端的特殊驗證。這類測試多出如今前端UI界面簡易，後端判斷複雜。例如，文檔的上傳下載，上傳一批 手機號到服務器，實現發送短信的目的。給出幾個錯誤驗證的例子，一，導入Excel文件中，同一個手機號連續輸入兩次，查看發送短信條數（此部分驗證的是短信攻擊性）；二，導入Excel文件中，同一個手機號不連續輸入屢次，查看發送短信條數（此部分驗證的是數據去重性）。

　　 業務關聯性。例如數據變動等信息同步問題時，有關聯的業務之間產生聯繫，會出現此類驗證。舉個例子，ES數據實現同步功能，在首批數據導入後，不一樣業務之間共享同一批數據，當某一條數據進入生命週期時，此時不只要觀察當前 數據庫中的數據變化，還要觀察使用ES技術同步後的數據是否一致。

　 　併發操做。此類問題的產生情景在較多用戶共享同一批數據，且同時對此數據進行同一功能操做下產生的問題。此類問題須要測試人員使用兩個 瀏覽器便可完成問題復現，左右各開一個顯示器，同時對一個數據進行編輯後的提交，查看界面反饋。

　　以上羅列的功能測試點和處理的例子尚有不完整之處，在此再也不多作贅述。功能測試過程當中，上述常見測試要點，酌情參考，每一個測試需求不一樣，不能統一照搬，在原有經驗的基礎上，更進測試方法，達到測試目的。

　　此外，除了功能測試還有非功能測試須要在梳理測試用例時覆蓋到。

　 　瀏覽器兼容。目前市場上普遍使用的瀏覽器較多，Firefox，Chrome，IE，UC，獵豹，Opera等等，在測試過程當中，摘選主要2-3個應用普遍的做爲重點測試對象，其次，酌情考慮項目參與人員的意見，如研發或產品人員，併入測試範圍。

　 　壓力。目前各個公司有本身的 壓力測試平臺，考慮當前項目的使用人數後酌情進行壓力測試。

　 　接口。更多時候是在界面上不能完成增刪改查操做時，使用手動 接口測試，查看返回值。

　 　安全和風險。這個也要看所測試的項目須要關注此類問題。

　　此外，測試用例評審，測試用例更新完善等環節也是對測試用例的查漏補缺。

　　覆蓋性強的測試用例是須要咱們針對項目具體制定的測試用例，以上所梳理的測試點，是在大多數工做中須要考慮的方面，總而言之，言而總之，測試用例不能照搬照抄，能夠參考不一樣測試用例的思考點，以這種思考的方式來當作當前項目的切入點，達到測試目的：發現程序的錯誤。