功能性測試用例
1. 測試的來(lái)源，即測試的需求
測試用例的主要來(lái)源有：
1) 需求說(shuō)明”及相關(guān)文檔
2)相關(guān)的設計說(shuō)明(概要設計，詳細設計等)
3)與開(kāi)發(fā)組交流對需求理解的 記錄(可以是開(kāi)發(fā)人員的一個(gè)解釋)
4)已經(jīng)基本成型的UI(可以有針對性地補充一些用例)
簡(jiǎn)而言之，所有你能得到的項目文檔，都盡量拿到。 從所得到的資料中，分解出若干小的“功能點(diǎn)”，理解“功能點(diǎn)”，編寫(xiě)相應的測試用例。
2. 用例的組織方式
不同的公司有不同的做法，原則上，只要方便管理和跟蹤，怎么組織都可以的。
用例可以按大的功能塊組織，如查詢(xún)功能模塊的用例，可以組織在一起，打印模塊的測試用例，可以另外組 織在一起。
在沒(méi)有專(zhuān)門(mén)的測試用例管理工具的情況下，用例執行后會(huì )產(chǎn)生2種狀態(tài)：“通過(guò)”、“失敗”——這樣加上“未 執行”的用例的狀態(tài)，共3種狀態(tài)。
即從“未執行”用例中執行一個(gè)用例后，該用例狀態(tài)應為“失敗”或“通 過(guò)”。將同一狀態(tài)的用例組織在一起。
至于用例文件格式，可以是.DOC或.XLS(如果有專(zhuān)門(mén)的測試用例管理工具另當別論)。
3. 用例與其他材料的關(guān)聯(lián)方式，即如何解決用例跟蹤的問(wèn)題 測試用例面臨的比較大的風(fēng)險有：
需求的變更、設計的修改、需求的錯誤和遺漏等等。
由于用例的主要來(lái)源是需求和設計的說(shuō)明，所以對用例的跟蹤其實(shí)就是對需求和設計的跟蹤，需求和設計的 變更勢必引起測試用例的變更。
如前所說(shuō)，將分解的功能點(diǎn)編號，與相應的用例聯(lián)系起來(lái)。例如，你可以列一個(gè)表格，列出各個(gè)(編號的)功 能點(diǎn)和測試用例間的關(guān)聯(lián)關(guān)系。
這樣，當需求和設計發(fā)生變化時(shí)，你只需要跟蹤“功能點(diǎn)”是否變化，是否增 加了新的功能點(diǎn)。
重要和困難的是，不手頭的資料和信息一定要是最新的。
4. 一個(gè)好的用例的表述要點(diǎn)，即用例中應當包含的信息
一個(gè)優(yōu)秀的測試用例，應該包含以下信息：
1) 軟件或項目的名稱(chēng)
2) 軟件或項目的版本(內部版本號)
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
