軟體測試工作流程總結
阿新 • • 發佈：2019-01-07
Q：什麼是軟體測試？
答：特定的環境、特定的條件下執行軟體，驗證其能正常執行，並發現其缺陷，對軟體的質量進行評估的過程。
Q：軟體測試的工作過程有哪幾步？
答：需求、計劃、方案、用例、執行、總結。
1、測試需求
測試需求分析：分析識別測試範圍，解決測什麼的問題，方便測試的跟蹤和管理。測試需求分析的流程：需求採集—>需求分析—>需求評審。
測試需求分析的評審：完整性、準確性、一致性、易理解性、無歧義性。
測試需求分析的時間：開發需求完成後。
參考依據：
（1）狹義依據：需求規格；
（2）廣義依據：參照上面的測試需求分析來源。
Q：在測試需求不明確的情況下，如何保證測試質量？
（1）多方收集需求；
（2）多與開發人員溝通；
（3）若有以前的系統，參照以前的系統；
（4）找類似的產品熟悉；
（5）到網上查詢與系統相關的業務知識、專業術語。
測試需求分析的來源：
（1）開發文件：需求規格、概設、詳設、資料庫結構設計文件、模組功能圖等；
（2）使用者需求：與使用者或需求分析人員溝通，需求調研的會議紀要，與使用者郵件往來；
（3）軟體雛形：可執行軟體，軟體的框架；
（4）相關的規劃及標準：各行各業的標準、國家標準、行業標準、企業標準、專案標準、國家法律法規；
（5）類似的產品：公司內部相同的舊版本產品，行業其他公司類似的產品；
（6）測試知識經驗庫：測試人員的業務背景、系統業務知識的積累、個人的測試經驗積累；
（7）其他隱性的需求：產品利益相關者的建議、會議紀要、備忘錄、溝通記錄、郵件往來等。
測試需求分析的內容：
（1）業務流程圖的分析；
（2）使用者和角色的分析；
（3）資料庫結構的分析；
（4）測試要點的分析。
測試需求分析的方法：
（1）測試功能點分析法；
（2）功能互動分析法；
（3）質量特性分析法；
（4）測試型別分析法。
2、測試計劃
測試計劃：管理層文件，對測試過程、測試活動起到指導的作用，解決做什麼的問題，5W。測試計劃編寫時間：測試需求完成之後。
評審人：專案經理、QA、開發、產品、設計人員。
輸出文件：總的測試計劃文件。測試計劃的內容：
（1）專案背景，縮略語（專業術語）；
（2）測試的參考文件、測試的交付文件；
（3）測試目標、測試範圍、測試環境、測試工具、測試策略、測試風險；
（4）人力資源的分配、工作量的估算；
（5）測試時間、進度安排、任務分配、培訓計劃等；
（6）出入口準則（准入準出標準）等。
測試風險：質量、時間進度、成本、變更、人員變動等；
QA與QC的區別：QA為質量保證、QC為質量控制。
冒煙測試：在測試之前，對軟體進行可測性檢查，保證基本功能，基本流程可通，提高工作效率。
迴歸測試：包括完全迴歸和部分迴歸（根據操作頻率和風險選擇）。
| 專案 | 專案時間週期 | 測試用例數量 |
| 小 | 3個月-10個月 | 500-1000個 |
| 中 | 10個月-1.5年 | 1000-2000個 |
| 大 | 1.5年以上 | 2000個以上 |
| 測試階段 | 佔用時間比例 |
| 測試需求階段 | 10%-20% |
| 測試計劃 | 小專案2-3天，大專案5天左右 |
| 測試方案 | 小專案1周，大專案2周 |
| 測試用例 | 測試總時間的30% |
| 測試執行 | 測試總時間的40% |
| 測試報告 | 小專案2-3天，大專案5天 |
整合策略： （1）非增量式整合：大爆炸式整合；（2）增量式整合：自頂向下、自底向上、三明治。測試准入條件：（1）測試用例編寫，測試評審完成；（2）開發人員完成編碼，並完成自測；（3）冒煙測試通過；（4）開發組提交了測試申請單；測試準出條件：（1）時間標準：專案時間用盡；（2）缺陷修復：致命/嚴重缺陷比率為0%，一般<5%，輕微<10%;（3）測試用例執行覆蓋率為100%；（4）測試用例對需求覆蓋率>95%;（5）缺陷修復率達到一定的標準；（6）收益比：存在bug，但是修復需要花費的時間大於受益，測試停止；（7）完成軟體測試驗收報告，並且報告結果達到認可。
3、測試方案
4、測試用例
參考依據：參考方案、需求分析的結果、需求規格。
評審人：測試工程師、QA、開發人員、測試經理。
輸出文件：測試用例文件。
Q：用例設計需考慮的方面有哪些（以最少的用例更全面的覆蓋需求，以此發現更多的缺陷）？（1）編寫所有必填項（一個用例）；（2）編寫所有項包括必填和非必填（一個用例）；（3）一個完整的流程一次性走完（一個用例）；（4）編寫預期結果：包括前臺、後臺、資料庫等方面；（5）新增和修改的連結為同一介面（程式碼一致為前提）：在修改中只需測試進入介面的預設情況，其餘欄位只需在新增上測試，修改所有欄位點選儲存、重置，修改後直接返回需要提示；（6）刪除：子資訊有呼叫情況（全刪、不能刪除），例：品牌和商品，刪除品牌時則提示，物理刪除：可到資料庫中回滾，資料庫不存在；標誌刪除：到回收站用來做歷史記錄，後臺可看，前臺不可；（7）登陸：賬號長度限制，正確登陸，不正確登陸；（8）業務流程圖：場景法、基本流和備選流，序列用乘，並行用加；例：銀行取款流程圖；（9）查詢：精確查詢和模糊查詢，like“%x%”；多條件搜尋可用正交法、再補充。測試用例過程：（1）輸入—動作—輸出；（2）輸入—測試環境—測試目的—執行條件—動作—輸出；（3）為了達到某種特定目標而設計的一組測試輸入、執行條件和預期結果，其目的是為了檢測某個程式或何時是否滿足某個特定的需求。測試用例的作用：便於軟體質量的度量，方便測試任務的跟蹤管理，方便缺陷的提交。如何衡量測試用例的好壞：清晰、準確、完整、簡潔、一致。黑盒測試用例設計方法：包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。
白盒測試用例設計方法：語句覆蓋率、條件覆蓋率、判定覆蓋率、條件判定覆蓋率、組合覆蓋率、路徑覆蓋率。
關於因果圖法：（1）因果圖關係：（輸入與輸出）恆等、非~、與^、或V；（2）輸入約束：異E最多隻能一個為1、或I最少有一個為1、唯一O有且只有一個唯一；要求R兩個取值一樣如C1為1C2也為1；（3）輸出約束：強制M兩個輸出互異。#對於搜尋框的測試用例設計#（1）單個條件；（2）所有條件；（3）任意幾個條件組合：應用正交實驗法再補充情況；（4）不符合條件查詢；（5）條件中有相互衝突的條件，需單獨測試；（6）輸入合理的查詢條件後，點選返回需有提示。5、測試執行
參考依據：測試用例（需求）。輸出：缺陷報告。
測試執行注意事項：（1）注意用例執行的先後順序：資料流向、優先順序、時間進度安排；（2）執行的前置條件、測試環境、備註裡的特殊說明；（3）發現問題/缺陷時，應立即保留證據，再重現缺陷；（4）缺陷至少重現3次，並初步定位到問題；（5）測試過程中，根據實際情況維護測試用例。
測試用例的執行結果：（1）未測試：Not test；（2）通過：pass；（3）失敗：failed；（4）阻塞：black；因為其它的問題導致用例無法執行；（5）觀察：investigates。Q：什麼時候需要維護測試用例？（1）需求、編碼、設計發生了變更；（2）執行過程中發現用例描述有錯誤；（3）發現的缺陷不能對應用例，需補充用例；（4）發現重複、冗餘的用例需刪除；Q：什麼是缺陷（遺漏、錯誤、額外實現）？（1）需求規格說明書中明確要求實現的未實現；（2）需求規格說明書中雖未明確規定，但實際需要實現的缺陷；（3）未正確實現（錯誤實現）；（4）實現了需求規格中明確不需要的功能（額外實現）或實際不需要的功能；（5）效能、易用性等方面，站在使用者的角度，會認為不夠完美的。
bug的內容：bug描述、重現步驟、實際結果、預期結果。
缺陷的生命週期：提交->確認->分配->修復->驗證->關閉缺陷的內容： 缺陷編號、模組、專案名、版本、缺陷標題、缺陷級別、優先順序、缺陷型別、測試環境、缺陷描述（bug描述、重現步驟、實際結果、預期結果、修改建議）、狀態、缺陷引入原因、缺陷引入條件、發現人、發現時間、修改人、修改時間、關閉人、關閉時間、附件、對應的用例編號。Q：對於偶然發現，並難以重現的缺陷如何處理？（1）先保留證據（抓包、截圖、視訊等）；（2）本機重現問題，無法重現則換電腦重現；（3）若重現，則根據缺陷的實際影響情況定義缺陷的嚴重級別；若無法重現，則找開發人員協助重現；在開發人員的協助下仍未能重現，則需要對此問題邊重現邊錄視訊（最多兩小時），若2小時內重現則從發現問題的前半小時開始分析，若2小時內未重現，則需直接提交缺陷，降低缺陷的級別，將缺陷改成延遲狀態，該缺陷至少歷經半年或者在使用者現場歷經多個版本後關閉。
6、測試報告
定義：對於測試過程、產品質量進行評估，並對測試結果進行總結、下結論。依據：測試用例的執行情況，缺陷資料的統計結果。評審人：整個專案人員。測試報告評估人：測試經理、測試人員。
測試報告的內容：專案背景、測試目標、測試範圍、測試環境、測試策略、測試工具、測試人力資源、測試時間、測試用例資料統計、缺陷資料統計、遺留問題、測試風險、測試過程開發、產品質量評估、測試結論、經驗教訓與建議、附錄。
Q：編寫測試報告的目的是什麼？（1）用於專案經理決策提供依據；（2）用於下一個專案維護提供方便；（3）對測試進行評估。