軟件功能測試用例的書寫方式 軟件測試
功能性測試用例
1. 測試的來源,即測試的需求
測試用例的主要來源有:
1) 需求說明”及相關(guān)文檔
2)相關(guān)的設計說明(概要設計,詳細設計等)
3)與開發(fā)組交流對需求理解的 記錄(可以是開發(fā)人員的一個解釋)
4)已經(jīng)基本成型的UI(可以有針對性地補充一些用例)
簡而言之,所有你能得到的項目文檔,都盡量拿到。 從所得到的資料中,分解出若干小的“功能點”,理解“功能點”,編寫相應的測試用例。
2. 用例的組織方式
不同的公司有不同的做法,原則上,只要方便管理和跟蹤,怎么組織都可以的。
用例可以按大的功能塊組織,如查詢功能模塊的用例,可以組織在一起,打印模塊的測試用例,可以另外組 織在一起。
在沒有專門的測試用例管理工具的情況下,用例執(zhí)行后會產(chǎn)生2種狀態(tài):“通過”、“失敗”——這樣加上“未 執(zhí)行”的用例的狀態(tài),共3種狀態(tài)。
即從“未執(zhí)行”用例中執(zhí)行一個用例后,該用例狀態(tài)應為“失敗”或“通 過”。將同一狀態(tài)的用例組織在一起。
至于用例文件格式,可以是.DOC或.XLS(如果有專門的測試用例管理工具另當別論)。
3. 用例與其他材料的關(guān)聯(lián)方式,即如何解決用例跟蹤的問題 測試用例面臨的比較大的風險有:
需求的變更、設計的修改、需求的錯誤和遺漏等等。
由于用例的主要來源是需求和設計的說明,所以對用例的跟蹤其實就是對需求和設計的跟蹤,需求和設計的 變更勢必引起測試用例的變更。
如前所說,將分解的功能點編號,與相應的用例聯(lián)系起來。例如,你可以列一個表格,列出各個(編號的)功 能點和測試用例間的關(guān)聯(lián)關(guān)系。
這樣,當需求和設計發(fā)生變化時,你只需要跟蹤“功能點”是否變化,是否增 加了新的功能點。
重要和困難的是,不手頭的資料和信息一定要是最新的。
相關(guān)推薦:北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |