當拿到相關的資料后,從哪些方面分析需求?如何與開發人員交流需求?其實,只要把握需求分析的幾個關鍵的點就可以解決問題:輸入、處理過程、輸出、性能要求、運行環境,下面針對每一個項目逐一分析:
軟件輸入: 與該需求相關的一切可能輸入,可以從這幾方面考慮,輸入來源、輸入參數的數量、輸入參數的度量單位、輸入參數的時間要求、輸入參數的精度和輸入參數的有效輸入范圍。在測試用例設計中,這部分內容作為測試用例輸入的依據。
處理過程: 描述對輸入數據所執行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可,在測試過程中發現 BUG 時候,如果對處理過程了解的深入,對定位問題根源有很大的幫助。
軟件輸出: 描述每個需求的輸出結果,包括輸出的位置(如計算機顯示器、打印機,文件),輸出參數的數量、輸出參數的度量單位、輸出參數的時序、輸出參數精確度、輸出參數的有效輸出范圍、錯誤消息。在測試用例設計中,這部分內容作為測試用例的預期輸出。
性能要求: 與該需求相關的性能要求,比如 " 插入 ATM 取款卡后, 3 秒鐘內彈出提示用戶取款的圖形界面 " 。 3 秒鐘這一限制,就是對需求的基本性能要求。
運行環境: 軟件的運行所需的環境,包括硬件平臺的要求、操作系統的要求、數據庫的要求,以及其它相關支撐軟件的要求。
o 確認需求的優先級
確認需求的優先級是很必要的,如果在產品進度比較緊的情況下,測試人員可以考慮優先測試優先級高的需求項,如果進度允許,那么在測試優先級低的需求項,如果進度不允許,那么就放棄測試優先級低的需求項。如果軟件公司有規范的流程支撐,開發人員在提供軟件需求文檔的時候,應該在文檔中確定需求的優先級。但是,如果開發人員連基本的軟件需求文檔都沒有提供,又怎能指望他們確定軟件需求的優先級?如果是這樣,需求的優先級只能由測試人員完成了。
o 加入開發小組的郵件群組
測試人員需要通曉被測試產品,但是,產品在開發的過程中往往是不斷變化的。如果軟件開發團隊有一套變更控制流程,測試人員會對產品的變更了如指掌。如果沒有變更控制,那就要采用其他的土方法了。如果公司里面有自動化辦公系統,也許采用的是 Lotus Notes 系統,也許使用的是 E-mail 系統,測試人員應該加入到開發人員的郵件群組中。當開發人員通過郵件討論問題、通知召開技術會議的時候,測試人員可以及時知曉,如果必要,可以參加開發人員的技術會議。即便公司里面有了軟件變更控制流程,加入到開發郵件群組也是一個很好的習慣。
o 與開發人員為鄰
建議測試人員與開發人員為鄰。我所在的測試組曾經與開發組是在相鄰的寫字間里,開發人員與測試人員的關系非常融洽,拋去同事關系,大家還是不錯的朋友。不管開發人員有什么樣的活動,測試人員都能第一時間獲得信息。無論從事軟件測試工作,還是從事其它的工作,與工作中上下游環節的同事保持良好的個人關系對工作有很大便利。一般的公司內部都存在部門墻,良好的人際關系是打通部門墻的手段之一。向領導建議測試人員與開發人員為鄰,這很必要。
o 測試用例設計
測試需求收集完畢后,開始測試設計。測試用例是什么?測試用例就是一個文檔,描述輸入、動作、或者時間和一個期望的結果,其目的是確定應用程序的某個特性是否正常的工作。設計測試用例需要考慮以下問題:
o 測試用例的基本格式
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果,下面逐一介紹。
用例編號: 測試用例的編號有一定的規則,比如系統測試用例的編號這樣定義規則: PROJECT1-ST-001 ,命名規則是項目名稱+測試階段類型(系統測試階段)+編號。定義測試用例編號,便于查找測試用例,便于測試用例的跟蹤。
測試標題: 對測試用例的描述,測試用例標題應該清楚表達測試用例的用途。比如 " 測試用戶登錄時輸入錯誤密碼時,軟件的響應情況 " 。
重要級別: 定義測試用例的優先級別,可以籠統的分為 " 高 " 和 " 低 " 兩個級別。一般來說,如果軟件需求的優先級為 " 高 " ,那么針對該需求的測試用例優先級也為 " 高 " ;反之亦然,
測試輸入: 提供測試執行中的各種輸入條件。根據需求中的輸入條件,確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性,如果軟件需求中沒有很好的定義需求的輸入,那么測試用例設計中會遇到很大的障礙。
操作步驟: 提供測試執行過程的步驟。對于復雜的測試用例,測試用例的輸入需要分為幾個步驟完成,這部分內容在操作步驟中詳細列出。
預期結果: 提供測試執行的預期結果,預期結果應該根據軟件需求中的輸出得出。如果在實際測試過程中,得到的實際測試結果與預期結果不符,那么測試不通過;反之則測試通過。
軟件測試用例的設計主要從上述 6 個域考慮,結合相應的軟件需求文檔,在掌握一定測試用例設計方法的基礎上,可以設計出比較全面、合理的測試用例。具體的測試用例設計方法可以參見相關的測試書籍,白盒測試方法和黑盒測試方法在絕大多數的軟件測試書籍中都有詳細的介紹,這里不作贅述。
o 重用同類型項目的測試用例
如果我看得遠,那是因為我站在巨人的肩上 --牛頓。
一般來說,每個軟件公司的項目可以分為固定的幾大類??梢园礃I務類型劃分,比如 ERP 軟件、產品數據管理軟件、通信軟件、地理信息系統軟件等等;可以按軟件結構來劃分,比如 B/S 架構的軟件、 C/S 架構的軟件、嵌入式軟件等等。參考同類別軟件的測試用例,會有很大的借鑒意義。如果,公司中有同類別的軟件系統,千萬別忘記把相關的測試用例拿來參考。如果,系統非常接近,甚至經過對測試用例簡單修改就可以應用到當前被測試的軟件。 " 拿來主義 " 可以極大的開闊測試用例設計思路,也可以節省大量的測試用例設計時間。
o 利用已有的軟件 Checklist
在上面一個小節中,按照不同的規則劃分了不同的軟件類型。每種類型的軟件都有一定的測試規范,比如, WEB 軟件系統在系統測試過程中,會有一系列的范式,比如針對 Cookie 就會有很多測試點。在設計測試用例的時候,不妨到網上去搜索相關的 Checklist ,不過國內外的網站很少有這方面的資料,即便有,也不是特別系統??梢韵日乙环荽植诘?Checklist ,然后,在設計測試用例的時候不斷的去完善它,以作為下次測試用例設計的基礎。
原文轉自:http://www.anti-gravitydesign.com