軟件測試流程規(guī)范最全

1、軟件測試流程規(guī)范整體的流程圖1.詳細的流程執(zhí)行 1.1 計劃與設計階段整體流程圖1.1.1 立項會議由高層主管立項會議，會議主要對項目的可行性進行分析，并且確定項目經理及項目測試組長。 過程要點 詳細說明 輸入條件立項會議工作內容l 項目（產品）可行性分析。l 項目經理的確定. l 根據項目信息，測試經理確定測試組長。退出標準測試組長確定責任人測試經理（確定測試組長）1.1.2 需求評審 過程要點 詳細說明 輸入條件需求定義完成工作內容測試團隊成員對需求中不清楚、不完整、太概括或存在疑義的地方提出問題，相關人員解答并確認。退出標準所有人員對需求無異議參與人員需求調研人員，開發(fā)組，測試部（需求提

2、出者，高層主管） 責任人需求調研人員（或高層主管） 注：1需求定義基本完成，此時應在評審會議召開之前發(fā)給測試團隊，預留時間給測試相關人員熟悉、理解。2測試部參與人員由測試部經理指定，主要由測試組長、測試設計等人員組成（還應包括配置管理人員、質量保證人員）。1.1.3 測試工作啟動 過程要點 詳細說明 輸入條件項目（產品）開發(fā)計劃完成 工作內容1項目/產品經理郵件通知測試組長正式測試交接時間，測試規(guī)模預估等，同時提交相關最新項目資料：l 項目需求及軟件規(guī)格定義文檔l 項目開發(fā)計劃l 開發(fā)設計過程中提供概要設計、詳細設計文檔。l 其他相關資料2組建測試小組，確定小組成員 3召開測試啟動會議，開發(fā)團

3、隊提供需求規(guī)格說明書和開發(fā)計劃，確認開發(fā)組與測試組對需要交接的測試內容、測試目標達成一致，統(tǒng)一項目組的目標和測試的工作重點。 退出標準測試小組成立，雙方對測試目標及內容達成一致。責任人產品（項目）經理，測試組長注：在正式測試任務下達前，開發(fā)團隊應在項目（產品）開發(fā)計劃完成后及時向測試團隊下達預通知，告之較為確切的測試日期，提供當前最新的相關資料。部門經理和測試組長組建測試小組，并視具體情況決定是否需要調整人力、時間安排、測試環(huán)境等其它資源。測試小組成員可預先熟悉必要的項目（產品）資料。1.1.4 測試設計階段1.1.4.1 設計測試計劃注：針對需求分析文檔和項目開發(fā)計劃文檔測試完成后，測試組需

4、要編寫測試計劃文檔、制定測試測略及預估測試過程中的風險，并設計出合理的規(guī)避風險的策略，為后續(xù)的測試工作提供直接的指導。過程要點 詳細說明 輸入條件項目需求文檔建立，項目開發(fā)計劃完成工作內容根據項目的需求文檔、設計文檔，按照測試計劃文檔模板編寫測試計劃。測試計劃中應該至少包括以下關鍵內容：l 依據項目背景及要求，確定測試環(huán)境。l 測試需求需要測試組測試的范圍，估算出測試所花費的人力資源和各個測試需求的測試優(yōu)先級l 測試策略確定項目的測試計劃內容，整體測試的測試方法和每個測試需求的測試方法，同時做好測試進度安排及人員調整。l 測試資源本次測試所需要用到的人力、硬件、軟件、技術的資源l 測試組角色明

5、確測試組內各個成員的角色和相關責任l 可交付工件在測試組的工作中必須向項目組提交的產物，包括測試計劃、測試報告等等l 風險管理列舉出測試工作所可能出現(xiàn)的風險測試計劃編寫完畢后，必須提交給項目組全體成員，并由項目組組中各個角色組聯(lián)合評審。退出標準l 測試計劃由項目組評審并通過. l 在項目開發(fā)過程中，要適時的對測試計劃進行跟蹤，以及評估此計劃的完整性、可行性，在項目結束時還要最后評估一下測試計劃的質量責任人測試設計工程師 1.1.4.2 設計測試用例注：在需求分析文檔確立基線以后，測試組需要針對項目的測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標準。 1.1.4.2.1設計測試用例

6、的常用方法a 等價劃分法有效等價類:是指對于程序的規(guī)格說明來說是合理的有意義的輸入數(shù)據構成的集合利用有效等價類可檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能 無效等價類:與有效等價類的定義恰巧相反b 邊界值法： 邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。 通常情況下，軟件測試所包含的邊界檢驗有幾種類型：數(shù)字、字符、位置、重量、大小、速度、方位、尺寸、空間等。 相應地，以上類型的邊界值應該在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最長、 空/滿等情況下。 邊界值分

7、析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值處取輸入變量值，記為：min、min+、nom、max-、max考慮到健壯性測試，還可以加一個略大于最大值max+，以及一個略小于最小值min-的值。 舉例說明：例如要求0 X5,在編寫用例時需考慮到以下幾種情況： n x=0的情況 n x=5的情況 n x=-1的情況 n 輸入一個X大于5的值，例如輸入X=6 c 錯誤推斷法基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。 思路：分析程序中最易出錯的場景和情況，在此基礎上有針對性的設計測試用例，需要完成的前提條件如下：l 深度熟悉被測系統(tǒng)的

8、業(yè)務、需求。l 對被測系統(tǒng)或類似系統(tǒng)之前的缺陷分布情況進行過系統(tǒng)的分析。包括功能缺陷，數(shù)據缺陷，接口缺陷和界面缺陷等等。 舉例說明： 聊天窗口功能 輸入特殊字符（全角，半角）后，窗口是否能夠正常顯示 輸入空格，是否能夠過濾，是否會算入長度計算 輸入html字符 輸入腳本語言函數(shù) 在需要密碼驗證，或者需要二次輸入確認的地方，通過復制粘貼第一次的輸入內容是否能夠通過1.1.4.2.2接口測試的方法 測試接口文檔。 根據接口文檔編寫測試用例（用例編寫方法完全可以按照黑盒測試的用例編寫規(guī)則來編寫，如：邊界值、等價劃分等等設計方法）。 和數(shù)據庫中執(zhí)行測試，查看接口返回的接口數(shù)據是否正確，主要檢查返回的接

9、口是否和接口文檔中定義的一樣，還有要檢查返回的數(shù)據是否的保持一致。 1.1.4.2.3安全性測試的方法 手工檢測：對于CSRF、越權訪問、文件上傳、修改密碼等漏洞，難以實現(xiàn)自動化檢測的效果，這是因為這些漏洞涉及系統(tǒng)邏輯或業(yè)務邏輯，有時候還需要人機交互參與頁面流程，因此這類漏洞的檢測更多的需要依靠手動測試完成。手工檢測網站URL、后臺登陸是否具有SQL注入u 舉例說明：關于上傳： 上傳文件是否有格式限制,是否可以上傳exe文件； 上傳文件是否有大小限制,上傳太大的文件是否導致異常錯誤,上傳0K的文件是否會導致異常錯誤,上傳并不存在的文件是否會導致異常錯誤； 通過修改擴展名的方式是否可以繞過格式限

10、制，是否可以通過壓包方式繞過格式限制； 是否有上傳空間的限制,是否可以超過空間所限制的大小,如將超過空間的大文件拆分上傳是否會出現(xiàn)異常錯誤。 上傳文件大小大于本地剩余空間大小，是否會出現(xiàn)異常錯誤。 關于上傳是否成功的判斷。上傳過程中，中斷。程序是否判斷上傳是否成功。 對于文件名中帶有中文字符，特殊字符等的文件上傳。1.1.4.2.5兼容性測試的方法 操作系統(tǒng)/平臺兼容 不同瀏覽器的兼容 不同分辨率間的兼容 1.1.4.2.4界面測試的方法 風格統(tǒng)一 重要的和常用的元素優(yōu)先布局，且放置在醒目的位置 布局合理緊湊，疏密有致 明顯區(qū)分只讀區(qū)域與可編輯區(qū)域 使用紅色的符號*來標記必填項 語句流暢，表述

11、清晰，沒有錯別字 字段名稱通俗易懂、盡量使用專業(yè)術語 1.1.4.2.5 易用性測試的方法 易理解 易學 易操作 吸引性 1.1.4.2.6 APP兼容性測試 分辨率：現(xiàn)在市場上分辨率是的各種各樣的什么的分辨率都有了，所以需要在app在不同的分辨率設備上進行測試，顯示UI的效果怎么樣。 系統(tǒng)：Android系統(tǒng)在不斷升級，就會產生不同系統(tǒng)版本，對系統(tǒng)版本是不斷進行兼容來對來符合的系統(tǒng)的版本。而在市場上開發(fā)了不同的定制的版本，也需要進行兼容。 機型：現(xiàn)在所涉及到廠商生產的出來的機器較多，所以需要使用不同廠商的不同分辨率來進行適配app的運行的情況 語言：現(xiàn)在的很多的app已經支持較多的語言的，所

12、以需要對語言方面進行測試，是app顯示的語言國際化顯示的效果 1.1.4.2.7 測試用例的維護存在以下幾種情況，需對測試用例進行更新： 先前的測試用例設計不全面或不準確 部分嚴重的軟件錯誤未在測試用例中覆蓋 新的版本有新功能的需求或改動 編寫的測試用例不規(guī)范或者語句錯誤 舊的測試用例不再適用 過程要點 詳細說明 輸入條件測試需求明確，測試計劃明確工作內容根據測試計劃設計測試用例，設計參考原則：l 等價類劃分l 邊界值分析l 錯誤推測等l 業(yè)務知識及相關流程退出標準l 測試用例需要覆蓋所有的測試需求l 測試用例集需進行評審并通過l 項目進行過程中，適時的根據需求變更來對測試用例進行維護責任人測

13、試組成員1.1.4.3 設計內容評審注：測試計劃及測試用例的設計工作完成后，需通知項目組相關成員召開評審會議。在這之前需要將待評審的內容發(fā)給相關人員熟悉和理解。過程要點 詳細說明 輸入條件測試計劃、測試用例集完成工作內容評審測試計劃內容的正確性及合理性：l 測試環(huán)境、測試資源；l 測試需求范圍，各個測試需求的優(yōu)先級；l 測試策略及風險管理等；評審測試用例集：l 測試用例優(yōu)先級l 測試用例集基于需求的覆蓋程度退出標準測試計劃及測試用例集評審通過責任人同行測試組，項目經理，1.2 實施測試階段整體流程圖1.2.1 測試交接過程要點 詳細說明 輸入條件測試設計內容評審完畢，開發(fā)團隊編碼工作完成，并已

14、完成內部測試；工作內容1. 開發(fā)組根據測試啟動會上所規(guī)定的內容，填寫送測單，向測試組提交測試內容。2. 測試小組檢查提交部件的完整性和可測性：l 檢查接收的測試內容（按照測試啟動會上所規(guī)定的交接內容）；l 檢查程序是否有病毒；l 能否正確安裝/卸載；l 檢查送測的軟件是否完整，能否進行測試；退出標準提交部件經測試組檢驗通過責任人產品（項目）經理，測試組長1.2.2 實施測試1.2.2.1 實施測試注:實施測試用例將花費測試組大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。過程要點 詳細描述 輸入條件測試組長于前一工作日定出當日的測試計劃，確定可用的測試用例。工作內容l 測試工程師根據測

15、試計劃中分配給自己的測試任務和提供的測試用例，實施相應的測試用例。l 記錄實施用例的結果，提交當日測試紀錄。l 提交缺陷。退出標準測試用例中的所有任務被執(zhí)行，結果被記錄。責任人測試組成員1.2.2.2提交階段性測試報告在約定的測試周期完成之后，測試組長需要總結此次測試的結果，編寫階段性測試報告。過程要點 詳細描述 輸入條件測試組完成了預定周期的測試任務工作內容測試組長根據此輪測試的結果，編寫階段性測試報告（參考測試階段性報告模板），主要應包含以下內容：l 測試報告的版本l 測試的人員和時間l 測試所覆蓋的缺陷測試組在這輪測試中所有處理的缺陷，報告測試組長處理的缺陷和實施工程師驗證的缺陷。不僅要

16、寫出覆蓋缺陷的總數(shù)，還要寫明這些缺陷的去向：l 測試新發(fā)現(xiàn)的缺陷數(shù)量l 上一版本活動缺陷的數(shù)量l 經過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類l 測試評估寫明在這一版本中，那些功能被實現(xiàn)了，那些還沒有實現(xiàn)，這里只需寫明和上一版本不同之處即可l 急待解決的問題寫明當前項目組中面臨的最優(yōu)先的問題，可以重復提出退出標準在每輪測試結束之后應盡快將符合標準的測試報告發(fā)給全項目組責任人測試組長1.2.3回歸測試在每輪測試結束之后，由測試組重新針對修改后的最新版本，進行回歸測試。過程要點 詳細描述 輸入條件在每輪測試中，按照現(xiàn)有的測試用例沒有新的缺陷被發(fā)現(xiàn)，測試報告中全部的活動缺陷都被解決。工作內容l 測試

17、組將按照測試計劃中對于回歸測試的策略對產品進行回歸測試，回歸測試的用例屬于測試用例的一部分或者是全部測試用例，但不能超出原先預定的測試用例的范圍。l 記錄用例實施結果，提交回歸測試記錄。 退出標準l 回歸測試所運行的用例全部通過l 缺陷經過驗證l 所有缺陷都被指明處理方式責任人測試工程師 1.2.4同行審查過程要點 詳細描述 輸入條件回歸測試結束，所有缺陷都被關閉。工作內容1.進行對測試組所測試項目或產品的測試審查工作.基本原則: l 不依據所設計測試用例,進行自由測試. l 測試時間保持在3個正常工作日以內. l 如發(fā)現(xiàn)嚴重缺陷,則一輪測試結束后,更新版本,執(zhí)行回歸測試. 2.提交當日測試紀

18、錄. 3.編寫同行審查總結報告(報告以簡單為好). 退出標準同行審查沒有新的缺陷或沒有嚴重缺陷產生. 責任人同行測試組1.3 總結階段整體流程圖1.3.1 測試報告總結在回歸測試結束之后，測試組長將要編寫測試總結報告，對測試進行總結，并且提交給全體項目組，為產品的后續(xù)工作提供重要的信息支持。過程要點 詳細描述 輸入條件測試組完成了所有的測試實施工作,同行審查結束. 工作內容測試組長根據測試的結果，按照測試總結報告的文檔模板編寫測試報告，測試報告必須包含以下重要內容：l 測試資源概述多少人、多長時間。l 測試結果摘要分別描述各個測試需求的測試結果，產品實現(xiàn)了哪些功能點，哪些還沒有實現(xiàn)l 缺陷分析

19、按照缺陷的屬性分類進行分析l 測試需求覆蓋率原先列舉的測試需求的測試覆蓋率，可能一部分測試需求因為資源和優(yōu)先級的因素沒有進行測試，那么在這里要進行說明l 測試評估從總體對項目質量進行評估l 測試組建議從測試組的角度為項目組提出工作建議退出標準測試組長完成了符合標準的測試報告，發(fā)送給全項目組。責任人測試組長1.3.2 測試驗收測試驗收工作是在以上工作全部結束后，對測試的過程，效果進行驗收，宣布測試結束。過程要點 詳細描述 輸入條件測試組完成了所有的測試實施工作，測試組長完成符合標準的測試總結文檔工作內容由測啟會上約定的驗收組成員，對本次測試收進行驗收，驗收內容包括：l 測試效果驗收測試是否達到預

20、期目的l 測試文檔驗收測試過程文檔是否齊全，可信，符合標準l 測試評估從總體對測試的質量進行評估l 測試建議對本次測試工作指出不足，需要在以后工作中改進的地方l 宣布測試結束測試驗收組成員簽字宣布本次測試結束退出標準測試驗收通過，測試驗收會議記錄整理完畢參與人員驗收組人員，測試經理，測試組長，產品（項目）經理1.3.3 測試歸檔測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸類，存檔。過程要點 詳細描述 輸入條件測試驗收通過工作內容歸類、存檔測試過程涉及到的文檔，主要包括以下文檔（必須）l 測試任務書l 測試計劃書l 測試用例書l 階段性測試報告l 測試總結報告l 測試驗收會議記錄退出標準全部文檔歸類完畢，版本號封存責任人測試組長1.3.4 測試工作總結過程要點 詳細描述 輸入條件項目驗收工作完成。工作內容由測試組長召開項目測試工作總結會議，會議內容主要為：l 測試組長對項目期間的整個測試組的工作情況進行總結，指出測試工作中存在的問題，同時也對工作中表現(xiàn)好的地方給與肯定。（具體包括整個測試情況、流程實施、人員安排、測試方法等）l 參與本次項目測試工作