撰寫測試用例之經驗集成

2019-Nov-11

本日對一個中小型的CRM系統進行第一部份的測試，關於“客戶資料的管理”，而其中一個環節是針對其客戶的“創建日期”進行篩選，因為數據庫不歸我們測試部門，而是由第三方開方公司管理，而這家公司對我們測試部門愛理不理。這下懵了，原始數據也就2-3條，我們沒辦法一條一條的添加不同“創建日期”的數據，只能追供應商或者用腳本一天天的去添加數據，一共添加十天。想表達的是，測試數據的提前准備是相當重要的，不然面對一個對你愛理不理的供應商就會手停腳停了。

2019-Nov-23

 

至今應該寫了大概400條測試用例了吧，卻沒掌握到一種“通用的”或者“標準化”的固定模式去寫測試用例，一直處於摸索階段。在網上搜技巧，大致的方向都是說：「測試用例的目的—＞明確測試的功能點、保證測試的覆蓋率、保證每個新版本都能按照測試用例完整的測試。」當然，完整程度完全取決於您寫測試用例的詳細程度，而測試用例可弄成一個集合，不斷在這個集合上新增、更新、完善。其實要把測試做的好，真的不簡單，存在太多技巧，包括如何管理版本的迭代，把通用重覆的測試點抽離出來等等。

 

我也會反問自己：「你要如何做測試呢？」。其實呀，做什麼事情也好都是需要原因或者動機的，比如說「為什麼要對軟件進行測試呢？」。那當然是為了：「找出軟件潛在的缺陷，把他交給軟件提供者去進行修復。」。那麼問題來了，「“你”憑什麼說這知個軟件、這個功能是一個缺陷、或者不符合要求的呢？」。這個時侯我們必須要有一套規格、標准，當我們按照這套規範去測試，才知道軟件這個功能點是否符合，而這個東西就叫做“設計文檔”、“需求文檔”、“功能規格文檔”。

（大家試想一下：假如這裡有個充值功能，我們要測試輸入金額、點擊充值是否能充值成功。當我輸入100、0.001以及-100都能充值成功，那到底有沒有潛在缺陷呢？答案是顯然而見的，“-100”就是一個大家都知道的“必然缺陷”，而其他的就必須得按照文檔的標準來判定這個功能點是否存在缺陷，怎麼說？上例的0.001就是一個例子，大哥誰會充0.001，一來是不乎合常理人性，二是對服務器以及數據庫肯定不是健康的交易產生，假如文檔沒有一個需求提出充值金額的範圍，那測試的工作就尷尬了。）

 

要做到最優，有太多太多的點了，比例：如何根據一個系統去規劃測試方案；如何以最少的時間，人力成本，使測試效益最大化；如何抽取出可重用、高重覆性的測試用例，節省後期開發時間；測試的類型（功能測試、業務功能測試、性能測試）等等…太多的學問了。這裡持續更新。

 

關於測試用例之標題，避免一些模凌兩可的描述，大家可以看下下面的例子，哪一條使你一看就清楚要測試什麼：

1.「測試登錄是否能成功。」

2.「測試登錄可以成功。」

3.「輸入賬號密碼，點擊登錄，成功。」

4.「輸入已注冊之賬號及密碼，點擊登錄。」

好了，相信有寫過測試用例的同學，會不會比較傾向於第4種呢？原因是，第一、不要在測試標題上留下疑問，你說測試登錄是否能成功，那在“預期結果”欄，你是要寫期望成功，還是失敗呢？第二、可以的話簡而精說明是用什麼途徑去登錄，而不是測試登錄可以成功，你是用掃碼呢還是什麼途徑登錄呢？第三、你輸入的賬號密碼，是一個什麼樣狀態的賬號呢？當然你可以把“已注冊之賬號”、“未注冊之賬號”、“失效之賬號”寫在“前置條件”當中。最後第四、是否很清晰明了的表達我要測試什麼，沒有拖泥帶水，留下一個疑問給大家，需要把整條測試用例看完才知道要測些什麼呢？

 

2019-Dec-30

一轉眼就已經一個月過去了, 之前寫的所謂測試案例都把所有步驟拆分，當成是一個測試案例，當然寫的快累死.

這個覆蓋率, 在測試頁面功能上還可以, 之後再持續放多點案例出上分享.