[轉載]軟體測試從零開始

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

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

引言

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

　　測試準備工作

　　在測試工作伊始，軟體測試工程師應該搞清楚軟體測試工作的目的是什麼。如果你把這個問題提給專案經理，他往往會這樣回答： “ 發現我們產品裡面的所有 BUG ，這就是你的工作目的 ” 。作為一名軟體測試新手，如何才能發現所有的 BUG ？如何開始測試工作？即便面對的是一個很小的軟體專案，測試需要考慮的問題也是方方面面的，包括硬體環境、作業系統、產品的軟體配置環境、產品相關的業務流程、使用者的併發容量等等。該從何處下手呢？

　　向有經驗的測試人員學習

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

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

　　閱讀軟體測試的相關書籍

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

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

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

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

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

　　通過走讀測試用例專案，你可以掌握應該從哪些功能點著手未來的測試工作；通過走讀軟體測試用例，你可以瞭解如何根據被測試的功能點開展軟體測試用例的設計工作，包括如何確定測試用例的輸入、測試用例的操作步驟和測試用例的輸出結果等。

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

　　學習產品相關的業務知識

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

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

　　識別測試需求

　　識別測試需求是軟體測試的第一步。如果開發人員能夠提供完整的需求文件和介面文件，那固然好。可以根據需求文件中描述的每個功能專案的輸入、處理過程和輸出，來設計測試用例。如果開發人員沒有提供軟體需求文件，那該如何是好？下面給出幾個有效的方法：

　　主動獲取需求

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

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

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

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

　　軟體輸出： 描述每個需求的輸出結果，包括輸出的位置（如計算機顯示器、印表機，檔案），輸出引數的數量、輸出引數的度量單位、輸出引數的時序、輸出引數精確度、輸出引數的有效輸出範圍、錯誤訊息。在測試用例設計中，這部分內容作為測試用例的預期輸出。

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

　　執行環境： 軟體的執行所需的環境，包括硬體平臺的要求、作業系統的要求、資料庫的要求，以及其它相關支撐軟體的要求。

　　確認需求的優先順序

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

　　加入開發小組的郵件群組

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

　　與開發人員為鄰

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

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

　　測試用例的基本格式

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

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

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

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

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

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

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

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

　　重用同型別專案的測試用例

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

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

　　利用已有的軟體 Checklist

　　在上面一個小節中，按照不同的規則劃分了不同的軟體型別。每種型別的軟體都有一定的測試規範，比如， WEB 軟體系統在系統測試過程中，會有一系列的正規化，比如針對 Cookie 就會有很多測試點。在設計測試用例的時候，不妨到網上去搜尋相關的 Checklist ，不過國內外的網站很少有這方面的資料，即便有，也不是特別系統。可以先找一份粗糙的 Checklist ，然後，在設計測試用例的時候不斷的去完善它，以作為下次測試用例設計的基礎。

　　加強測試用例的評審

　　測試用例設計完畢後，最好能夠增加評審過程。同行評審是 CMM3 級的一個 KPA ，如果因為公司沒有通過 CMM3 級，就不開展同行評審是不恰當的。測試用例應該由產品相關的軟體測試人員和軟體開發人員評審，提交評審意見，然後根據評審意見更新測試用例。 如果認真操作這個環節，測試用例中的很多問題都會暴露出來，比如用例設計錯誤、用例設計遺漏、用例設計冗餘、用例設計不充分等等；如果同行評審不充分，那麼，在測試執行的過程中，上述本應在評審階段發現的測試用例相關問題，會給測試執行帶來大麻煩，甚至導致測試執行掛起。

　　定義測試用例的執行順序
　
　　在測試用例執行過程中，你會發現每個測試用例都對測試環境有特殊的要求，或者對測試環境有特殊的影響。因此，定義測試用例的執行順序，對測試的執行效率影響非常大。比如某些異常測試用例會導致伺服器頻繁重新啟動，伺服器的每次重新啟動都會消耗大量的時間，導致這部分測試用例執行也消耗很多的時間。那麼在編排測試用例執行順序的時候，應該考慮把這部分測試用例放在最後執行，如果在測試進度很緊張的情況下，如果優先執行這部分消耗時間的異常測試用例，那麼在測試執行時間過了大半的時候，測試用例執行的進度依然是緩慢的，這會影響到測試人員的心情，進而導致匆忙地測試後面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴重影響了軟體測試效果和進度。因而，合理地定義測試用例的執行順序是很有必要的。

　　測試用例執行

　　測試用例設計完畢後，接下來的工作是測試執行，測試執行中應該注意以下幾個問題：

　　搭建軟體測試環境，執行測試用例

　　測試用例執行過程中，搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟體產品執行的軟硬體環境，比如要求作業系統系統是 Windows 2000 pack4 版本，資料庫是 Sql Server 2000 等等，此外，應該給出被測試軟體產品的詳細安裝指導書，包括安裝的操作步驟、相關配置檔案的配置方法等等。對於複雜的軟體產品，尤其是軟體專案，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。

　　如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。

　　測試執行過程應注意的問題

　　測試環境搭建之後，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：

　　全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要檢視軟體產品的操作日誌、系統執行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟體產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟體的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 佔用率地時候，發現 CPU 佔用率高達 90 ％，後來經過分析，軟體執行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，後來通過把定時器調整到 10ms ， CPU 的佔用率降為 7 ％。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。

　　加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟體產品提供了日誌功能，比如有軟體執行日誌、使用者操作日誌，一定在每個測試用例執行後記錄相關的日誌檔案，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。

　　及時確認發現的問題： 測試執行過程中，如果確認發現了軟體的缺陷，那麼可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟體缺陷，那麼一定要保留現場，然後知會相關開發人員到現場定位問題。如果開發人員在短時間內可以確認是否為軟體缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重新問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。

　　與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。首先，要定義軟體缺陷的標準原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那麼開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。

　　及時更新測試用例

　　測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。

　　總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。

　　提交一份優秀的問題報告單

　　軟體測試提交的問題報告單和測試日報一樣，都是軟體測試人員的工作輸出，是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。軟體測試報告單最關鍵的域就是 “ 問題描述 ” ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟體配置、硬體配置、測試用例輸入、操作步驟、輸出、當時輸出裝置的相關輸出資訊和相關的日誌等。

　　軟體配置： 包括作業系統型別版本和補丁版本、當前被測試軟體的版本和補丁版本、相關支撐軟體，比如資料庫軟體的版本和補丁版本等。

　　硬體配置： 計算機的配置情況，主要包括 CPU 、記憶體和硬碟的相關引數，其它硬體引數根據測試用例的實際情況新增。如果測試中使用網路，那麼網路的組網情況，網路的容量、流量等情況。硬體配置情況與被測試產品型別密切相關，需要根據當時的情況，準確翔實的記錄硬體配置情況。

　　測試用例輸入 操作步驟 輸出： 這部分內容可以根據測試用例的描述和測試用例的實際執行情況如實填寫。

　　輸出裝置的相關輸出資訊： 輸出裝置包括計算機顯示器、印表機、磁帶等等輸出裝置，如果是顯示器可以採用抓屏的方式獲取當時的截圖，其他的輸出裝置可以採用其它方法獲取相關的輸出，在問題報告單中提供描述。

　　日誌資訊： 規範的軟體產品都會提供軟體的執行日誌和使用者、管理員的操作日誌，測試人員應該把測試用例執行後的軟體產品執行日誌和操作日誌作為附件，提交到問題報告單中。

　　根據被測試軟體產品的不同，需要在 “ 問題描述 ” 中增加相應的描述內容，這需要具體問題具體分析。

　　測試結果分析

　　軟體測試執行結束後，測試活動還沒有結束。測試結果分析是必不可少的重要環節， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很大的借鑑意義。前面的 “ 測試準備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟體缺陷。測試結束後，也應該分析自己發現的軟體缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別；然後，再把一起完成測試執行工作的其他測試人員發現的問題也彙總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有侷限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試用避免盲區。

　　總結：

　　限於文章的篇幅，本文不可能給出一個類似於 checklist 的指導性的軟體測試新手入門。無論從事軟體測試還是從事其它的工作，技術上的和技巧上的問題都可以通過查詢相關的軟體測試技術書籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟體測試工作積累的經驗之談，如發現謬誤之處請不吝指出。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-142370/，如需轉載，請註明出處，否則將追究法律責任。