一、軟件測試寫測試用例

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

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

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

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

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

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

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

延伸閱讀：

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

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