一、軟件測試寫測試用例

1.在原本測試用例的基礎(chǔ)上，再次放大用例描述的模糊度，以利于用例可用于相似但細(xì)節(jié)不同的功能。以登陸界面的字符長度為12雙字節(jié)的用戶名提示框?yàn)槔?/p>

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

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

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

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

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

分析：每個用例覆蓋一個功能點(diǎn)，是優(yōu)異的理想狀態(tài)。但條件覆蓋有個缺點(diǎn)就是每次執(zhí)行會存在一個較長的周期，如果部分不可套用自動化，會導(dǎo)致測試和開發(fā)并行產(chǎn)生無法按時驗(yàn)證完每個版本的分支。

延伸閱讀：

二、 測試用例的細(xì)度如何把握

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