【軟件測試-02】軟件測試生命週期，Bug週期，測試計劃，測試用例，測試類型，測試階段任務
目錄程序員
bug的生命週期瀏覽器
測試團隊的職責安全
整體測試計劃要素數據結構
測試用例要素併發
測試報告app
測試方法框架
軟件測試&軟件開發生命週期六個階段
- 需求階段 –測試人員瞭解需求、對需求進行分解，得出測試需求
- 計劃階段 —根據需求編寫測試計劃/測試方案
- 設計階段 –測試人員適當的瞭解設計，對於設計測試用例是頗有幫助的，測試人員搭建測試用例框架，根據需求和設計 編寫一部分測試用例
- 編碼階段 –測試人員通常是不須要編碼的，但已經編碼的模塊，專業的白盒測試人員能夠計劃執行單元測試，完善、細 化測試用例以及調整測試計劃和方案。
- 測試階段–測試階段是軟件測試人員最爲重要的工做階段，根據測試用例和計劃執行測試，在執行的過程當中記錄、管理 缺陷，測試完成後編寫測試報告。
- 運行維護 –測試人員須要參與項目的實施工做。測試人員對項目產品的業務和操做很是瞭解，加上測試人員的溝通表達 能力通常都比較強，因此測試人員能夠參與用戶使用軟件的培訓，在試運行項目時收集問題並及時反饋給相 關負責人
合格的bug描述七個要素：
bug的生命週期
- New新建 :新發現的Bug，未經評審決定是否指派給開發人員進行修改。
- Open指派 ：確認是Bug，而且認爲須要進行修改，指派給相應的開發人員。
- Fixed修改 :開發人員進行修改後標識成修改狀態，有待測試人員的迴歸測試驗證。
- Rejected拒絕修改 ：若是認爲不是Bug，則拒絕修改。
- Delay延期修改 :若是認爲暫時不須要修改或暫時不能修改，則延後修改。
- Closed關閉 ：修改狀態的Bug經測試人員的迴歸測斌驗證經過，則關閉Bug。
- Reopen 重建 ：若是經驗證Bug仍然存在，則須要從新打開Bug，開發人員從新修改。
- 無效的bug：open->closed open-rejected-closed
測試團隊的職責
- 需求評審
- 測試計劃
- 測試用例
- 測試用例評審
- 測試執行
- 缺陷報告
- 缺陷跟蹤
- 測試報告
測試團隊須要交付的文檔
- 測試計劃
- 測試用例
- 缺陷報告
- 測試報告
整體測試計劃要素
- 測試目標
- 測試範圍
- 測試依據
- 測試類型
- 資源計劃
- 測試要求
- 測試方法
- 測試工做流程
- 測試經過標準
測試用例要素
- 用例摘要
- 優先級
- 前置條件
- 輸入數據
- 步驟
- 預期結果
- 實際結果
測試報告
- 項目概述
- 測試工做說明
- 測試結果
- 缺陷分析
- 過程改進總結
- 附錄
測試方法
- 三大方法：白盒、黑盒、灰盒
- 測試階段：α/β測試、系統測試、冒煙測試、迴歸測試、驗收測試
- 軟件測試類型：功能測試、接口測試、性能測試(基準測試， 負載測試，峯谷測試，參入測試)自動化測試、安全性測試
設計測試用例的方法
- 黑盒測試： 等價類劃分法， 邊界值分析法， 錯誤推測法 ，因果圖法
- 白盒測試： 邏輯覆蓋法 ，基本路徑測試法
軟件測試的14種類型
- 數據和數據庫完整性測試：
數據與數據庫完整測試是指測試關係型數據庫完整性原則以及數據合理性測試。
數據庫完整性原即：
主碼完整性：主碼不能爲空；
外碼完整性：外碼必須等於對應的主碼或者爲空。
數據合理性指數據在數據庫中的類型，長度，索引等是否建的比較合理。 - 白盒測試：白盒測試是基於代碼的測試，測試人員經過閱讀程序代碼或者經過使用開發工具中的單步調試來判斷軟件的質量，通常黑盒測試由項目經理在程序員開發中來實現。白盒測試分爲動態白盒測試和靜態白盒測試
- 功能測試：功能測試指測試軟件各個功能模塊是否正確，邏輯是否正確。此類測試基於黑盒技術，該技術經過圖形用戶界面 (GUI) 與應用程序進行交互，並對交互的輸出或結果進行分析，以此來覈實應用程序及其內部進程。功能測試的主要參考爲相似於功能說明書之類的文檔。
- UI測試：
UI測試指測試用戶界面的風格是否知足客戶要求，文字是否正確，頁面美工是否好看，文字，圖片組合是否完美，背景是否美觀，操做是否友好等等
用戶界面 (UI) 測試用於覈實用戶與軟件之間的交互。UI 測試的目標是確保用戶界面會經過測試對象的功能來爲用戶提供相應的訪問或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預期的方式運行，並符合公司或行業的標準。包括用戶友好性，人性化，易操做性測試。 - 性能測試：性能測試主要測試軟件測試的性能，包括負載測試，強度測試，數據庫容量測試，基準測試以及基準測試
5.1負載測試
負載測試是一種性能測試指數據在超負荷環境中運行，程序是否可以承擔。
在這種測試中，將使測試對象承擔不一樣的工做量，以評測和評估測試對象在不一樣工做量條件下的性能行爲，以及持續正常運行的能力。負載測試的目標是肯定並確保系統在超出最大預期工做量的狀況下仍能正常運行。此外，負載測試還要評估性能特徵，例如，響應時間、事務處理速率和其餘與時間相關的方面。
好比，在B/S結構中用戶併發量測試就是屬於負載測試的用戶，可使用webload工具，模擬上百人客戶同時訪問網站，看系統響應時間，處理速度如何？
5.2強度測試
強度測試是一種性能測試，他在系統資源特別低的狀況下軟件系統運行狀況。這類測試每每能夠書寫系統要求的軟硬件水平要求。
實施和執行此類測試的目的是找出因資源不足或資源爭用而致使的錯誤。若是內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下並不明顯的缺陷。而其餘缺陷則可能因爲爭用共享資源（如數據庫鎖或網絡帶寬）而形成的。強度測試還可用於肯定測試對象可以處理的最大工做量。
好比：一個系統在內存366M下能夠正常運行，可是下降到258M下不能夠運行，告訴內存不足，這個系統對內存的要求就是366M。
5.3數據庫容量測試
數據庫容量測試指經過存儲過程往數據庫表中插入必定數量的數據，看看相關頁面是否可以及時顯示數據。
數據庫容量測試使測試對象處理大量的數據，以肯定是否達到了將使軟件發生故障的極限。容量測試還將肯定測試對象在給定時間內可以持續處理的最大負載或工做量。例如，若是測試對象正在爲生成一份報表而處理一組數據庫記錄，那麼容量測試就會使用一個大型的測試數據庫，檢驗該軟件是否正常運行並生成了正確的報表。作這種測試一般經過書寫存儲過程向數據庫某個表中插入必定數量的記錄，計算相關頁面的調用時間。
好比，在電子商務系統中，經過insert customer 往user表中插入10 000數據，看其是否能夠正常顯示顧客信息列表頁面，若是要求達到最多能夠處理100 000個客戶，可是顧客信息列表頁面不可以在規定的時間內顯示出來，就須要調整程序中的SQL查詢語句；若是在規定的時間內顯示出來，能夠將用戶數分別提升到20 000 , 50 000, 100 000進行測試。
5.4基準測試
基準測試與已知現有的系統進行比較，主要檢驗是否與相似的產品具備競爭性的一種測試。
若是你要開發一套財務系統軟件而且你已經得到用友財務系統的性能等數據，你能夠測試你這套系統，看看哪些地方比用友財務系統好，哪些地方差？以便改進本身的系統，也可爲產品廣告提供數據。
5.5競爭測試
軟件競爭使用各類資源（數據紀錄，內存等），看他與其餘相關係統對資源的爭奪能力。好比：一臺機器上即安裝您的財務系統，又安裝用友財務系統。當CPU佔有率降低後，看看是否可以強過用友財務系統，而是本身的系統可以正常運行？
- 安全性和訪問控制測試：
安全性和訪問控制測試側重於安全性的兩個關鍵方面：
應用程序級別的安全性，包括對數據或業務功能的訪問
系統級別的安全性，包括對系統的登陸或遠程訪問。 - 故障轉移和恢復測試：故障轉移和恢復測試指當主機軟硬件發生災難時候，備份機器是否可以正常啓動，
- 配置測試：又叫兼容性測試。配置測試覈實測試對象在不一樣的軟件和硬件配置中的運行狀況。
8.1瀏覽器兼容性
測試軟件在不一樣產商的瀏覽器下是否可以正確顯示與運行；
好比測試IE，Natscape瀏覽器下是否能夠運行這套軟件？
8.2操做系統兼容性
測試軟件在不一樣操做系統下是否可以正確顯示與運行；
好比測試WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否能夠運行這套軟件？
8.3硬件兼容性
測試與硬件密切相關的軟件產品與其餘硬件產品的兼容性，好比該軟件是少在並口設備中的，測試同時使用其餘並口設備，系統是否能夠正確使用.
好比在INTER,舒龍CPU芯片下系統是否可以正常運行？
這樣的測試必須創建測試實驗室，在各類環境下進行測試。
- 安裝測試：安裝測試有兩個目的。第一個目的是確保該軟件在正常狀況和異常狀況的不一樣條件下: 例如，進行首次安裝、升級、完整的或自定義的安裝_都能進行安裝。異常狀況包括磁盤空間不足、缺乏目錄建立權限等。第二個目的是覈實軟件在安裝後可當即正常運行。這一般是指運行大量爲功能測試製定的測試。
- 多語種測試：又稱本地化測試，是指爲各個地方開發產品的測試，如英文版，中文版等等，包括程序是否可以正常運行，界面是否符合當地習俗，快捷鍵是否正常起做用等等，特別測試在A語言環境下運行B語言軟件（好比在英文win98下試圖運行中文版的程序），出現現象是否正常。
- 文字測試：文字測試測試軟件中是否拼寫正確，是否易懂，不存在二義性，沒有語法錯誤；文字與內容是否有出入等等，包括圖片文字。
- 分辨率測試：測試在不一樣分辨率下，界面的美觀程度,分爲800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字體下測試。一個好的軟件要有一個極佳的分辨率，而在其餘分辨率下也都能能夠運行。
- 發佈測試：主要在產品發佈前對一些附帶產品，好比說明書，廣告稿等進行測試
13.1說明書測試
主要爲語言檢查，功能檢查，圖片檢查
語言檢查：檢查說明書語言是否正確，用詞是否易於理解；
功能檢查：功能是否描述徹底，或者描述了並無的功能等；
圖片檢查:：檢查圖片是否正確
13.2宣傳材料測試
主要測試產品中的附帶的宣傳材料中的語言，描述功能，圖片
13.3幫助文件測試
幫助文件是否正確，易懂，是否人性化。最好可以提供檢索功能。
13.4廣告用語
產品出公司前的廣告材料文字，功能，圖片，人性化的檢查 - 發佈測試：
文檔審覈測試目前愈來愈引發人們的重視，軟件質量不是檢查出來的，而是融進軟件開發中來。前置軟件測試發愈來愈受到重視。請看一個資料：
文檔審覈測試主要包括需求文檔測試，設計文檔測試，爲前置軟件測試測試中的一部分。
14.1需求文檔測試
主要測試需求中是否存在邏輯矛盾以及需求在技術上是否能夠實現；
14.2設計文檔測試
測試設計是否符合所有需求以及設計是否合理。
Web測試方法
- 連接測試 、
- 表單測試、
- 數據效驗 、
- Cookies測試、
- 數據庫測試、
- 應用程序特定的功能需求 、
- 導航測試 、
- 圖形測試 、
- 內容測試 、
- 表格測試 、
- 總體界面測試 、
- 兼容性測試
測試階段劃分 （按測試執行順序）：
- 單元測試（Unit Testing）
定義：針對軟件基本組成單元（軟件設計的最小單位）來進行正確性檢驗的工做；
測試目的：檢測軟件模塊對《詳細設計說明書》的符合程度。
- 集成測試（Integration Testing）
定義：在單元測試的基礎上，將全部模塊按照概要設計要求組裝成爲子系統或系統，驗證組裝後功能以及模塊間接口是否正確的測試工做；
測試目的：檢測軟件模塊對《概要設計說明書》的符合程度。
- 系統測試（System Testing）
定義：將已經集成好的的軟件系統，做爲整個基於計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其餘元素組合在一塊兒，在實際運行（使用）環境下，對計算機系統進行的一系列的測試工做。
測試目的：與《需求規格說明書》作比較，發現軟件與系統需求定義不符合或與之矛盾的地方。
- 迴歸測試（Regression Testing）
定義：軟件在測試或其餘活動中發現的缺陷通過修改後，進行的測試；
測試目的：驗證缺陷獲得了正確的修復，同時對系統的變動沒有影響之前的功能；
特色：迴歸測試能夠發生在任何一個階段，包括單元測試、集成測試和系統測試；
策略：
①、徹底重複測試：從新執行前期創建的全部測試用例，並確認確認缺陷解決和修改的擴散影響性；
②、選擇性重複測試：
——覆蓋修改法：選擇直接影響的用例；
——周邊影響法：選擇間接影響的用例；
——指標達成方法：達到指標的覆蓋率等。
流程：
1）制定迴歸測試策略
2）肯定測試的版本
3）按照迴歸測試策略執行迴歸測試
4）迴歸測試經過，關閉缺陷跟蹤單（問題單）
5）迴歸測試不經過，缺陷跟蹤單返回開發人員，經開發人員修改後再次進行迴歸測試
迴歸測試自動化：（需考慮的問題以下）
1）迴歸測試是一個重複的之前測試的測試，因此自動化是迴歸測試的追求；
2）自動化法包括：程序的自動運行、自動配置，用例的管理、自動輸入，測試自動執行，測試結果自動採集、比較及結論的自動輸出；
3）對比較穩定的可採用QTP、Robot、SilkTest等工具的「捕捉回放」工具；
4）爲了能實現自動化須要用到腳本語言，如：TCL、Python、Perl等；
5）對比較複雜的過程，沒法藉助工具的須要本身開發專用工具；
6）儘早考慮迴歸測試的自動化，造成工具化、可繼承和推廣的。
- 其餘測試階段
○ α測試：用戶在開發環境下進行的測試，評價軟件FLURPS
○ β測試：多用戶在實際使用環境下進行的測試
○ 驗收測試：用戶根據合同、《需求規格說明書》或《驗收測試計劃》對產品進行的驗收測試
注：FLURPS即：功能、局域化、可用性、可靠性、性能、技術支持
單元測試、集成測試、系統測試的比較：
● 測試方法:
單元測試屬於白盒測試範疇；
集成測試屬於灰盒測試範疇；
系統測試屬於黑盒測試範疇；
● 考察範圍：
單元測試主要測試內部數據結構、邏輯控制、異常處理等；
集成測試主要測試模塊間的接口與接口數據傳遞關係，以及模塊組合後的總體功能；
系統測試主要測試整個系統相對於需求的符合度；
● 評估基準：
單元測試主要經過邏輯覆蓋率來評估；
集成測試主要經過接口覆蓋率來評估；
系統測試主要經過測試用例對需求規格的覆蓋率來評估；
主要的測試文檔：
● 測試計劃：測試範圍、方法、資源，以及相應測試活動的時間進度安排表的文檔；
● 測試方案：爲完成軟件集成特性的測試而進行的設計測試方法的細節文檔；
● 測試用例：爲完成一個測試項的測試輸入、預期結果、測試執行條件等因素的文檔；
● 測試規程：執行測試時測試活動序列的文檔；
● 測試報告：執行測試結果的文檔；
● 測試日報：天天測試執行狀況的記錄和總結。
單元測試過程
一樣這個過程將研究單元測試過程各個階段的輸入及輸出。
單元測試計劃階段：
輸入：詳細設計說明書、軟件測試計劃
輸出：單元測試計劃
單元測試設計階段：
輸入：詳細設計說明書、單元測試計劃
輸出：單元測試方案
單元測試實現階段：
輸入：詳細設計說明書、單元測試計劃、單元測試方案
輸出：單元測試用例、單元測試規程
單元測試執行階段：
輸入：單元測試計劃、單元測試方案、單元測試用例、單元測試規程
輸出：單元測試報告、缺陷報告
系統測試過程
在這裏主要研究軟件系統測試過程當中的輸入和輸出，瞭解咱們應該根據什麼來作、要作什麼以及咱們作的前後順序是怎麼安排的過程。
系統測試計劃階段：
輸入：軟件開發計劃、軟件測試計劃、需求規格說明書
輸出：系統測試計劃
系統測試設計階段：
輸入：需求規格說明書、系統測試計劃
輸出：系統測試方案
系統測試實現階段：
輸入：需求規格說明書、系統測試計劃、系統測試方案
輸出：系統測試用例、系統測試規程、系統測試預測試項
系統測試執行階段：
輸入：系統測試計劃、系統測試方案、系統測試用例、系統測試預測試項、系統測試規程
輸出：系統預測試報告、系統測試報告、缺陷報告
集成測試過程
一樣這個過程將研究集成測試過程各個階段的輸入及輸出。
集成測試計劃階段：
輸入：軟件測試計劃、概要設計說明書
輸出：集成測試計劃
集成測試設計階段：
輸入：概要設計說明書、集成測試計劃
輸出：集成測試方案
集成測試實現階段：
輸入：概要設計說明書、集成測試計劃、集成測試方案
輸出：集成測試用例、集成測試規程
集成測試執行階段：
輸入：集成測試計劃、集成測試方案、集成測試用例、集成測試規程
輸出：集成測試報告、缺陷報告
需求分析階段
每一個階段有每一個階段的任務，這裏將瞭解需求分析階段的任務，及其軟件項目各工做人員的任務所在。
需求分析階段任務：
● 需求分析，完成SRS
● 軟件需求規格說明書的評審：檢查遺漏和存在問題
● 進行需求跟蹤
● 系統測試計劃
● 系統測試計劃的評審
概要設計階段
概要設計階段任務：
● 軟件系統各層設計，完成HLD
● HLD的評審
● 更新需求跟蹤
● 系統測試方案、用例的設計
● 系統測試方案、用例的評審
● 集成測試計劃
● 集成測試計劃的評審
詳細設計階段
詳細設計階段任務：
● 軟件詳細模塊的設計，完成LLD
● 詳細設計的評審
● 更新需求跟蹤
● 集成測試方案、用例的設計
● 集成測試方案、用例的評審
● 單元測試計劃
● 單元測試計劃的評審
編碼階段
編碼階段任務：
● 軟件編碼
● 對代碼進行靜態質量檢查
● 代碼評審
● 單元測試方案、用例的設計
● 單元測試方案、用例的評審
測試階段
測試階段的任務：
● 系統預測試項執行
● 系統預測試報告工做
● 執行各階段測試用例
● 各階段的缺陷記錄、修復
● 各階段日誌報告
● 各階段缺陷的迴歸測試
● 各階段測試報告
● 測試報告的評審
繁華事散逐香塵，流水無情草自春