軟件測試-理論概念整理（一）
文章目錄
1.軟件產品質量模型
軟件產品質量模型將一個軟件產品需要滿足的質量劃分爲六大屬性：功能性、可靠性、易用性、效率、可維護性和可移植性
翻閱查詢大多數資料指出質量模型分爲這六大類，少數資料將可移植性與易用性替換成安全性。
1.1功能性
能夠滿足明確和隱含要求的功能
1.2可靠性
是指在特定條件下使用時，軟件產品維持規定的性能級別能力，且能夠處理異常情況，很快從錯誤中恢復
1.3易用性
指用戶在指定條件下使用軟件，軟件對於用戶來說易懂，易學，易操作，一定程度上需要漂亮好看
1.4效率
簡單來說就是佔用少量的資源，提供適當的性能（大多數從時間、資源上測試體現出來）
在少數文獻資料裏，效率性與性能等同概念。
1.5可維護性
指軟件（產品）可被修改的能力：即對軟件的修改實現、改進功能等所表現的適應性
1.6可移植性
指軟件從一種環境移植到另一種環境的能力：環境可以是軟件間、硬件間、或所處的系統甚至包括使用組織等等
2.軟件測試
定義混雜 沒有統一標準 但主體中心意思差不多
經典定義：在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，並對其是否能滿足設計要求進行評估的過程
3.軟件測試分類-測試方法
根據不同的分類依據，有不同的分類類別。以下列舉比較常見（經典）且較有權威性的分類：
3.1 是否考慮覆蓋源代碼（內部結構）【重要！】
3.1.1 黑盒測試（在另一篇有專門詳細的說明）
點擊–>>黑盒測試專篇
不考慮內部結構的情況下，在 程序接口 進行測試
3.1.2 白盒測試
檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據的基礎上進行測試
3.1.3 灰盒測試
介於黑盒與白盒之間
3.2 是否執行程序
3.2.1 靜態測試
靜態方法是指 不運行被測程序 本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。
3.2.2 動態測試
動態測試方法是指通過 運行被測程序 ，檢查運行結果與預期結果的差異，並分析運行效率、正確性等性能。
3.3 按階段劃分【重要！】
3.3.1 單元測試
單元測試是對軟件組成單元進行測試。其目的是檢驗軟件基本組成單位的功能是否正確。測試的對象是軟件設計的最小單位：模塊。
3.3.2 集成測試
集成測試也稱聯合測試或者組裝測試，將程序模塊（單元測試）採用適當的集成策略組裝起來，對系統的接口及集成後的功能進行正確性檢測的測試工作
實踐表明，一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。一些局部反映不出來的問題，在全局上很可能暴露出來
3.3.3 系統測試
是對整個系統的測試，將硬件、軟件、操作人員看作一個整體，檢驗它是否有不符合系統說明書的地方
一般來說，在系統測試上測試時間佔比最大
冒煙測試、迴歸測試也屬於系統測試
3.3.4 驗收測試
也稱交付測試，是軟件部署前最後一個測試，一般以最終用戶角度確認軟件是否符合預期
3.4 按測試對象劃分【重要！】
在文獻與各種技術論壇裏答案不一，但相近，在這裏舉一些比較經典常見的
在這裏暫時只做概念梳理，後續會詳細分析每個測試的要點
3.4.1 性能測試
3.4.2 界面測試
3.4.3 業務測試
3.4.4 文檔測試
3.4.5 兼容性測試
3.4.6 安全測試
3.4.7 安裝測試
3.5 是否手工執行（自動化）
自動化測試不能完全替代手工測試，自動化測試的目的僅僅在於讓測試人員從繁瑣重複的測試流程中解脫出來，把更多的時間和精力放在更有價值的測試中
在某些領域和測試中，手動測試比自動化測試效率高，消耗資源少
3.5.1 手工測試
3.5.2 自動化測試【趨於重要】
3.6 其他分類（補充）
3.6.1 冒煙測試
對基本功能、主要功能的測試，避免不必要的測試資源的浪費
一般來說，冒煙測試優於其他測試，屬於第一個需要進行的測試（在開發完後）
冒煙測試屬於系統測試
3.6.2 迴歸測試
對bug或測試用例進行重新測試，確認修改後沒有引入新的bug且以往通過測試的功能沒有產生錯誤
在目前的快速開發和敏捷迭代開發中，新版本的連續發佈使得迴歸測試進行的更加頻繁
3.6.3 探索性測試
探索性測試可以說是一種測試思維技術。它沒有很多實際的測試方法、技術和工具
同時做測試設計和測試執行，探索複雜場景，容易被忽視的場景
4.軟件開發常見模型
4.1 瀑布模型
瀑布模型強調文檔的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟件開發模式
4.1.1 優缺點
優點：階段清晰，需求明確—適合大型項目
缺點：以來需求分析成果，對文檔要求較高
4.2 快速原型模型
4.2.1 優缺點
優點：支持客戶參與，適應靈活開發項目
缺點：文檔不完善，不滿足大型項目需求
4.3 增量模型
開發人員逐個構件地交付產品，這樣做的好處是軟件開發可以較好地適應變化，客戶可以不斷地看到所開發的軟件，從而降低開發風險。
5.軟件測試常見模型
5.1 V模型
V模型中開發階段和測試階段劃分明確，對應關係明確
V模型沒有體現儘早測試和不斷測試原則
V模型有一定的侷限性,它僅僅把測試過程放在需求分析、系統設計、編碼之後的一個階段，忽視了測試對於需求的分析和驗證。
5.2 W模型
優點：開發與測試並行，有利於儘早發現問題，有利於及時的瞭解項目的測試風險，來及早的執行相應的應對方案，加快項目的進度（是V模型的演變，彌補V模型的不足）
缺點：需求、設計、編碼仍然是串行進行的，測試和開發保持線性的關係，上一個階段完成之後才能進行下一個階段，不能夠很好的支持迭代的開發模型。
5.3 H模型
把軟件測試看成一個完全獨立的流程，與其他流程併發進行，比如設計流程，編碼流程，甚至是測試流程
H模型強調把測試分爲測試準備和測試執行兩個不同的階段，只要由於其他流程的進展引發了測試就緒點的到位，這時候，只要測試準備不能完成，測試執行活動就可以或者需要開展，在H模型當中，測試是一個完全獨立的模型，所以可以和其他的流程交叉地進行，也便於我們 儘早的執行測試 。
5.4 X模型
左邊描述的是針對單獨的程序片段相互分離的編碼和測試，此後進行頻繁的交接，再通過集成，最終合成可執行的程序，X模型還定位了 探索式測試 ，探索式測試是不進行事先計劃的特殊類型的測試，能夠幫助測試人員在測試計劃之外發現更多的錯誤
6.軟件缺陷（Bug）
6.1 定義
軟件缺陷（Defect），常常稱爲bug。即軟件或程序中存在的問題及錯誤（也包括隱藏的功能缺陷）
6.2 標準
無先後順序，只要滿足以下五條其中一條即可視爲軟件缺陷（bug）
違反需求：
1.未達到需求規格說明書標明的功能
2.出現了需求指明不會出現的錯誤
3.超出了需求範圍
違反標準：
1.未達到需求雖未指明但應該達到的目標
違反易用性：
1.軟件難以理解，不易使用，運行速度慢等
6.3 缺陷報告因素
6.3.1 缺陷ID
缺陷的唯一標識（便於記錄溝通）
6.3.2 缺陷狀態
指缺陷通過一個跟蹤修復過程的進展情況，即當前所處狀態
6.3.3 缺陷標題
缺陷的簡要概述
6.3.4 嚴重程度
缺陷的嚴重程度，指因缺陷引起的故障對軟件產品的影響程度
6.3.5 優先級
指缺陷必須被修復的緊急程度
6.3.6 詳細信息
缺陷的詳細描述
7.軟件測試的基本流程
總體上分爲五個階段
1.測試需求分析階段：閱讀需求，理解需求，主要就是對業務的學習，分析需求點，參與需求評審會議
2.測試計劃階段：在參考軟件需求規格說明書前提下，主要任務爲編寫測試計劃，確定整體測試策略
3.測試設計階段：主要是編寫測試用例，且要通過用例評審
4.測試執行階段：搭建環境，執行冒煙測試（預測試）-然後進入正式測試，bug管理直到測試結束
5.測試評估階段：出測試報告，測試結束
eg：
需求分析–》編寫測試計劃–》編寫測試用例–》評審用例–》搭建環境–》等待開發提交測試包–》測試包安排預測（冒煙測試）–》執行測試用例，進行正式測試–》bug跟蹤處理（提交及迴歸bug）–》N輪後符合需求–》-編寫出報告，測試結束