一、軟件測試寫測試用例

1.在原本測試用例的基礎上，再次放大用例描述的模糊度，以利于用例可用于相似但細節不同的功能。以登陸界面的字符長度為12雙字節的用戶名提示框為例：

原始用例步驟：在登陸界面用戶名輸入框輸入11個中文字符。

修改后的用例步驟：在登陸界面輸入不超過字符長度限制的用戶名。

點評：原始用例步驟僅適合登陸界面用戶名字符長度限制為11以上的編輯框。修改后的用例可用于任何字符長度的用戶名編輯框。此方法還可用于對流程描述，如”進入編輯用戶名界面”可替換為”編輯用戶名”。

2.建立較為完善的基礎用例庫，項目用例作為基礎用例庫的子集存在。這樣的用例庫在針對單個功能時，存在多種不同的描述和設計。如1點的模糊程度不同可作為相同用例的不同兩支用例存在。而在以后的實際項目中，根據項目實際需求，從基礎用例庫篩選合適的用例組作為項目用例組。

如果用一條用例覆蓋一個功能點在實際操作中有很大的缺陷。首先不能確保測試人員進行集成測試時對功能用例執行到位，可能會出現遺漏。因此我們在測試用例輸出過程中，建議測試人員就測試因子使用工程方法進行流程功能覆蓋。但是這樣引入另外一個問題，客戶的需求是不斷變化的，需求在執行設計和測試用例輸出時，很大幾率產生變化，這種變化勢必對原輸出的測試用例造成沖擊。調整的工作量有時會很大，有可能對整個功能推倒重新輸出用例。面對這樣的情況該如何解決？

分析：每個用例覆蓋一個功能點，是優異的理想狀態。但條件覆蓋有個缺點就是每次執行會存在一個較長的周期，如果部分不可套用自動化，會導致測試和開發并行產生無法按時驗證完每個版本的分支。

延伸閱讀：

二、 測試用例的細度如何把握

用例粒度無論選擇什么方法，都存在利弊，所以在實際測試用例設計中，如何選取，需要結合整個測試團隊和產品未來發展來看，而非簡單的只分析測試用例原理就能得到結果。提供一個用例粒度供參考。單個quick check test單個測試人員在2小時完成，組成的用例組要求覆蓋產品所有功能，而每個用例都可從System cases中直接提取。以此為標準，可評估出每個用例的覆蓋粒度。