本文面向軟件測試新手，從測試前的準備工作、測試需求收集、測試用例設計、測試用例執行、測試結果分析幾個方面給出建議和方法。鑒于國內的軟件開發、測試不規范的現狀，本文為軟件測試新手提供了若干個軟件測試的關注點。

　　【關鍵詞】軟件測試、測試用例、測試需求、測試結果分析

　　引言

　　幾年前，從學校畢業后，第一份工作就是軟件測試。那時候，國內的軟件企業大多對軟件測試還沒有什么概念，書店里除了鄭人杰編寫的《計算機軟件測試技術》之外，幾乎沒有其它的軟件測試相關書籍，軟件測試僅僅在軟件工程的教材中作為一個章節列出來，因此，我對軟件測試一無所知。不過，在正式走上工作崗位之前，公司提供了為期兩周的系統的軟件測試技術專題培訓，對接下來的軟件測試工作有很大的指導意義?，F在，我繼續從事軟件測試的培訓與咨詢服務，在這個過程中，親眼目睹了很多軟件測試新手面對的困惑，他們初涉軟件測試行業，沒有接受系統的培訓，對軟件測試一無所知，既不知道該測試什么，也不知道如何開始測試。下面針對上述情況，給出若干解決辦法。

　　測試準備工作

　　向有經驗的測試人員學習

　　如果你進入的是一家運作規范的軟件公司，有獨立的軟件測試部門、規范的軟件測試流程、軟件測試技術有一定的積累，那么，恭喜你！你可以請求測試經理委派有經驗的測試人員作為你工作上的業務導師，由他列出軟件測試技術相關書籍目錄、軟件測試流程相關文檔目錄、產品業務相關的文檔目錄，在業務導師的指導下逐步熟悉軟件測試的相關工作。其實，在很多運作規范的軟件公司，已經把上述的師父帶徒弟的方式固化到流程中。

　　如果你進入的是一個軟件測試一片空白的軟件企業，那么，也恭喜你！你可以在這里開創一片自己的軟件測試事業，當然，前提是老板確實認識到軟件測試的重要性，實實在在需要提高產品的質量。這時候，可以到國內的軟件測試論壇和相關網站上尋找軟件測試資源，這種情況下，自學能力和對技術的悟性就至關重要了。

　　閱讀軟件測試的相關書籍

　　現在，中文版的軟件測試書籍越來越多，有的是國人自己寫的，有的是翻譯國外經典之作?？梢缘?www.chinapub.com 或者 www.cnforyou.com 等網絡購書的站點查找軟件測試相關的書籍。目前，從國外引入的軟件測試書籍有很多經典之作，但是，翻譯成中文后，翻譯質量對閱讀效果有很大的影響。

　　走讀缺陷跟蹤庫中的問題報告單

　　如果您所在的公司已經有軟件缺陷跟蹤庫了，無論采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，還是采用的 Bugzilla 、 Mantis 等開源工具，這都無關緊要，缺陷跟蹤庫中的缺陷報告單才是有價值的。缺陷跟蹤庫中的問題報告單是軟件測試工程師工作績效的集中體現，同時也是軟件產品問題的集中體現。一般來說，缺陷報告單中最關鍵的幾個部分包括：第一部分是發現缺陷的環境，包括軟件環境、硬件環境等；第二部分是缺陷的基本描述；第三部分是開發人員對缺陷的解決方法。通過對上述缺陷報告單的三個部分作仔細分析，不知不覺你已經吸收了其他軟件測試人員的工作經驗，并掌握了軟件產品常見的基本問題。這是迅速提高軟件測試經驗的好方法。

　　走讀相關產品的歷史測試用例

　　如果你所在的公司有測試用例管理系統，那么，走讀相關產品的軟件測試用例是迅速提高測試用例設計水平的一條捷徑。走讀測試用例也是有技巧的。測試用例寫作一般會包括測試用例項和根據測試用例項細化的測試用例，下面舉例說明。 “ 測試用戶登錄的功能 ” 是一個測試項，該測試項的目的是測試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠對非法用戶名和密碼做異常處理等等。因此，根據該用例項，可以設計出若干個測試用例，大多數情況下，測試用例項和測試用例是一對多的關系。

　　總之，走讀其他軟件測試人員設計的優秀軟件測試用例，是提高自身用例設計水平的好方法。

 

學習產品相關的業務知識

　　軟件測試人員不僅要掌握軟件測試技術相關知識，對產品相關的業務知識也要學習。這很好理解，如果從事財務軟件的測試工作，一定要學習財務知識；如果從事通訊產品測試工作，那么相關的通訊理論知識也是必須的；如果從事銀行軟件的測試，銀行的業務流程也是不可或缺的知識點。

　　因此，在學習軟件測試技術的同時，千萬不要忽略產品相關業務知識的學習。如果你是一個軟件測試技術專家，但是對產品業務知識一無所知，那么也只能測試出來純粹的軟件缺陷，而面對眼前出現的產品業務相關的缺陷，很可能是視而不見，如此這般，軟件測試的效果會大打折扣。

　　識別測試需求

　　主動獲取需求

　　開發人員通常不會更好地考慮軟件測試，如果沒有開發流程的強制規定，他們通常是不愿意提供任何開發文檔，即便有強制規定，需求文檔也未必能夠真正指導軟件系統測試工作。因此，需要測試人員發揮主觀能動性，與相關的軟件開發項目經理和軟件開發人員保持溝通，了解軟件實現的主要功能是什么，并記錄得收集到的信息。一般來說，開發人員即便沒有提供相關需求文檔，也會保存一些簡單的過程文檔，主動向開發人員索要這些文檔，可以作為測試的參考。此外，可以與公司的技術支持人員交流，技術支持人員是最貼近用戶的人，因此，通過交流可以獲取第一手的用戶使用感受，在測試的過程中會更加貼近用戶。

　　當拿到相關的資料后，從哪些方面分析需求？如何與開發人員交流需求？其實，只要把握需求分析的幾個關鍵的點就可以解決問題：輸入、處理過程、輸出、性能要求、運行環境，下面針對每一個項目逐一分析：

　　軟件輸入： 與該需求相關的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入參數的數量、輸入參數的度量單位、輸入參數的時間要求、輸入參數的精度和輸入參數的有效輸入范圍。在測試用例設計中，這部分內容作為測試用例輸入的依據。

　　處理過程： 描述對輸入數據所執行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可，在測試過程中發現 BUG 時候，如果對處理過程了解的深入，對定位問題根源有很大的幫助。

　　性能要求： 與該需求相關的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒鐘內彈出提示用戶取款的圖形界面 ” 。 3 秒鐘這一限制，就是對需求的基本性能要求。

　　運行環境： 軟件的運行所需的環境，包括硬件平臺的要求、操作系統的要求、數據庫的要求，以及其它相關支撐軟件的要求。

　　確認需求的優先級

　　確認需求的優先級是很必要的，如果在產品進度比較緊的情況下，測試人員可以考慮優先測試優先級高的需求項，如果進度允許，那么在測試優先級低的需求項，如果進度不允許，那么就放棄測試優先級低的需求項。如果軟件公司有規范的流程支撐，開發人員在提供軟件需求文檔的時候，應該在文檔中確定需求的優先級。但是，如果開發人員連基本的軟件需求文檔都沒有提供，又怎能指望他們確定軟件需求的優先級？如果是這樣，需求的優先級只能由測試人員完成了。

　　加入開發小組的郵件群組

　　測試人員需要通曉被測試產品，但是，產品在開發的過程中往往是不斷變化的。如果軟件開發團隊有一套變更控制流程，測試人員會對產品的變更了如指掌。如果沒有變更控制，那就要采用其他的土方法了。如果公司里面有自動化辦公系統，也許采用的是 Lotus Notes 系統，也許使用的是 E-mail 系統，測試人員應該加入到開發人員的郵件群組中。當開發人員通過郵件討論問題、通知召開技術會議的時候，測試人員可以及時知曉，如果必要，可以參加開發人員的技術會議。即便公司里面有了軟件變更控制流程，加入到開發郵件群組也是一個很好的習慣。

　　與開發人員為鄰

　　建議測試人員與開發人員為鄰。我所在的測試組曾經與開發組是在相鄰的寫字間里，開發人員與測試人員的關系非常融洽，拋去同事關系，大家還是不錯的朋友。不管開發人員有什么樣的活動，測試人員都能第一時間獲得信息。無論從事軟件測試工作，還是從事其它的工作，與工作中上下游環節的同事保持良好的個人關系對工作有很大便利。一般的公司內部都存在部門墻，良好的人際關系是打通部門墻的手段之一。向領導建議測試人員與開發人員為鄰，這很必要。
　測試用例設計

　　測試需求收集完畢后，開始測試設計。測試用例是什么？測試用例就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。設計測試用例需要考慮以下問題：

　　測試用例的基本格式

　　軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果，下面逐一介紹。

　　用例編號： 測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則： PROJECT1-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。

　　測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應情況 ” 。

　　重要級別： 定義測試用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。一般來說，如果軟件需求的優先級為 “ 高 ” ，那么針對該需求的測試用例優先級也為 “ 高 ” ；反之亦然，

　　測試輸入： 提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。

 

操作步驟： 提供測試執行過程的步驟。對于復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。

　　預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那么測試不通過；反之則測試通過。

　　軟件測試用例的設計主要從上述 6 個域考慮，結合相應的軟件需求文檔，在掌握一定測試用例設計方法的基礎上，可以設計出比較全面、合理的測試用例。具體的測試用例設計方法可以參見相關的測試書籍，白盒測試方法和黑盒測試方法在絕大多數的軟件測試書籍中都有詳細的介紹，這里不作贅述。

　　重用同類型項目的測試用例

　　如果我看得遠，那是因為我站在巨人的肩上 －－牛頓。

　　一般來說，每個軟件公司的項目可以分為固定的幾大類?？梢园礃I務類型劃分，比如 ERP 軟件、產品數據管理軟件、通信軟件、地理信息系統軟件等等；可以按軟件結構來劃分，比如 B/S 架構的軟件、 C/S 架構的軟件、嵌入式軟件等等。參考同類別軟件的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟件系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以應用到當前被測試的軟件。 “ 拿來主義 ” 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。