軟件測試一共有哪幾種類型

軟件測試是指使用人工或者自動的手段來運行或測定某個軟件產品系統的過程，其目的是在于檢驗是否滿足規定的需求或者弄清預期的結果與實際結果的區別，本文主要描述一下軟件測試一共有哪幾種類型。

單元測試（Unit test）：是針對模塊組件或方法的測試。在本人的操作中，一般是開發員工作范圍內的測試；在具備組件接口規范的情況下，一般需要做一個測試工具模擬調用環境，編寫測試實例，通過斷點情況監視模塊實際工作是否正常。

白箱測試：在理解內部流程的情況下針對邏輯流程設計測試實例，目的是找出極限邊緣以及內在的邏輯錯誤。單元測試中白箱測試的比例很高，（原因不難理解，還有誰比作者自已更理解模塊的構造流程的？）。

黑箱測試：這是QC部門的主要工作。黑箱測試主要在于編寫測試實例。不過在實際操作中，都是把最不懂技術的成員分配做測試，最高技術水平就是會用VSS，所以也就別指望編什么測試實例。

壓力測試：評價一個系統極限可以承受的壓力是多少，同時在超負荷后的的響應情況；同時，在極限狀況下，一些平時不太出現的bug也會浮現出來。

回歸測試；在修改其中一個模塊后看其他模塊有什么問題。作者認為這個測試是過程化程序的觀念產物，在模塊化軟件中相互耦合程度低，而且服從統一的調動協議，是不是修改真是自家里的事情，和他人（模塊）沒有半點相干。

整體測試：把不同的模塊連結后，看看聯合工作情況如何。這實際上是對接口協議的測試。作者認為是可以作為接口互動部分的設計一部分工作，沒有必要擺出來作為流程之一。同理還有系統測試，反正最后整個系統運行起來是什么情況。看似大，但如果前面已經做到好好的，這里如果出問題那才叫怪呢！

軟件測試一共有哪幾種類型？作為一名初學者來說，了解了軟件測試的類型還不夠，應用在不同類型中所需的工具也是很多的，那么做軟件測試要用到什么工具呢，請看下文

做軟件測試要用到什么工具

俗話說“工欲善其事、必先利其器”，作為一名合格的軟件測試工程師，測試用到的工具一定要準備齊全，當然學會如何使用它們也是你必須要做到的，那么做軟件測試要用到什么工具呢？南京達內軟件測試培訓師為您詳解。

測試管理工具：幫助測試人員完成計劃、追蹤等任務的工具，并且有助于根據需求、設計、編碼以及缺陷。

靜態分析工具：在不執行代碼的前提下進行分析，是非常重要的缺陷檢測工具，以各種指標來對代碼進行衡量，如McCabe測定復雜度，Logiscope度量代碼和規范的復合度等等。

動態分析工具：系統運行中進行分析、評估。例如運行過程中檢測內存使用情況、內存是否有越界、內存有無泄漏情況，常用工具有Purify、BoundChecker等。

覆蓋率工具：這類工具用于對軟件執行后，測試軟件被執行的程度，在單元測試中被廣泛應用，如TrueCoverage、PureCoverage、Logiscope等等。

測試執行工具：這類測試工具往往能夠自動執行，覆蓋單元測試、集成測試、系統測試等各種需求應用，分為功能測試自動化工具：Robot、Winrunner、SilkTest等；性能測試工具，如Loadrunner、SilKPerformer等。

做軟件測試要用到的工具就為大家介紹到這里，以上幾種為軟件測試工程師必備工具，具體根據黑盒、白盒測試也會有不同區分。

搭建軟件測試環境應注意的幾個問題

軟件測試環境的搭建在軟件測試項目中至關重要，其中應注意的問題也是不少，本文重點向讀者介紹在測試過程中應注意的幾個問題，希望能給讀者以啟迪。

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

軟件測試提交的問題報告單和測試日報一樣，都是軟件測試人員的工作輸出，是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。缺陷報告單中最關鍵的幾個部分：第一部分是發現缺陷的環境，包括軟件環境、硬件環境等；第二部分是缺陷的基本描述；第三部分是開發人員對缺陷的解決方法。通過對上述缺陷報告單的三個部分進行仔細分析，從中掌握了軟件產品最常見的基本問題，并吸收了其它軟件測試人員的工作經驗。最關鍵的域就是“ 問題描述” ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟件配置、硬件配置、測試用例輸入、操作步驟、輸出、當時輸出設備的相關輸出信息和相關的日志等。軟件配置：包括操作系統類型版本和補丁版本、當前被測試軟件的版本和補丁版本、相關支撐軟件，比如數據庫軟件的版本和補丁版本等。

硬件配置：計算機的配置情況，主要包括CPU 、內存和硬盤的相關參數，其它硬件參數根據測試用例的實際情況添加。如果測試中使用網絡，那么網絡的組網情況，網絡的容量、流量等情況。硬件配置情況與被測試產品類型密切相關，需要根據當時的情況，準確翔實的記錄硬件配置情況。測試用例輸入 操作步驟 輸出：這部分內容可以根據測試用例的描述和測試用例的實際執行情況如實填寫。輸出設備的相關輸出信息：輸出設備包括計算機顯示器、打印機、磁帶等等輸出設備，如果是顯示器可以采用抓屏的方式獲取當時的截圖也可以錄制視頻，其他的輸出設備可以采用其它方法獲取相關的輸出，在問題報告單中提供描述。

日志信息：規范的軟件產品都會提供軟件的運行日志和用戶、管理員的操作日志，測試人員應該把測試用例執行后的軟件產品運行日志和操作日志作為附件，提交到問題報告單中。

測試結果分析

軟件測試執行結束后，測試活動還沒有結束。測試結果分析是必不可少的重要環節，“ 編筐編簍，全在收口” ，測試結果的分析對下一輪測試工作的開展有很大的借鑒意義。前面的“ 測試準備工作” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟件缺陷。測試結束后，也應該分析自己發現的軟件缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別；然后，再把一起完成測試執行工作的其他測試人員發現的問題也匯總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試用避免盲區。搭建軟件測試環境時與開發的關系處理測試用例執行過程中，搭建測試環境是第一步。一般來說，軟件產品提交測試后，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟件產品運行的軟硬件環境，比如要求操作系統系統是Windows 2000 pack4 版本，數據庫是Sql Server 2000 等等。此外，應該給出被測試軟件產品的詳細安裝指導書，包括安裝的操作步驟、相關配置文件的配置方法等等。對于復雜的軟件產品，尤其是軟件項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。

問題二：全方位的觀察測試用例執行結果：

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

問題三：加強測試過程記錄：

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

問題四：及時確認發現的問題：

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

問題五：提交缺陷時與開發的關系處理：

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

問題六：及時更新測試用例

測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗余的測試用例完全可以由某一個測試用例替代，那么刪除冗余的測試用例。總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執

行結束后，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。