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

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

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

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

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

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

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

7、等情況下。 Ø 邊界值分析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值處取輸入變量值，記為：min、min+、nom、max-、max考慮到健壯性測試，還可以加一個略大于最大值max+，以及一個略小于最小值min-的值。 舉例說明：例如要求0 < X<5,在編寫用例時需考慮到以下幾種情況： n x=0的情況 n x=5的情況 n x=-1的情況 n 輸入一個X大于5的值，例如輸入X=6 c 錯誤推斷法基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設(shè)計(jì)測試用例的方法。 思路：分析程序中最易出錯的場景和情況，在此基礎(chǔ)上有針對性的設(shè)計(jì)測試

8、用例，需要完成的前提條件如下：l 深度熟悉被測系統(tǒng)的業(yè)務(wù)、需求。l 對被測系統(tǒng)或類似系統(tǒng)之前的缺陷分布情況進(jìn)行過系統(tǒng)的分析。包括功能缺陷，數(shù)據(jù)缺陷，接口缺陷和界面缺陷等等。 舉例說明： 聊天窗口功能  輸入特殊字符（全角，半角）后，窗口是否能夠正常顯示 輸入空格，是否能夠過濾，是否會算入長度計(jì)算  輸入html字符  輸入腳本語言函數(shù)  在需要密碼驗(yàn)證，或者需要二次輸入確認(rèn)的地方，通過復(fù)制粘貼第一次的輸入內(nèi)容是否能夠通過接口測試的方法Ø 測試接口文檔。 Ø 根據(jù)接口文檔編寫測試用例（用例編寫方法完全可以按照黑盒測試的用例編寫規(guī)則來編寫

9、，如：邊界值、等價劃分等等設(shè)計(jì)方法）。 Ø 和數(shù)據(jù)庫中執(zhí)行測試，查看接口返回的接口數(shù)據(jù)是否正確，主要檢查返回的接口是否和接口文檔中定義的一樣，還有要檢查返回的數(shù)據(jù)是否的保持一致。 安全性測試的方法Ø 手工檢測：對于CSRF、越權(quán)訪問、文件上傳、修改密碼等漏洞，難以實(shí)現(xiàn)自動化檢測的效果，這是因?yàn)檫@些漏洞涉及系統(tǒng)邏輯或業(yè)務(wù)邏輯，有時候還需要人機(jī)交互參與頁面流程，因此這類漏洞的檢測更多的需要依靠手動測試完成。手工檢測網(wǎng)站URL、后臺登陸是否具有SQL注入u 舉例說明：關(guān)于上傳： Ø 上傳文件是否有格式限制,是否可以上傳exe文件； Ø 上傳文件是否有大小限制,

10、上傳太大的文件是否導(dǎo)致異常錯誤,上傳0K的文件是否會導(dǎo)致異常錯誤,上傳并不存在的文件是否會導(dǎo)致異常錯誤； Ø 通過修改擴(kuò)展名的方式是否可以繞過格式限制，是否可以通過壓包方式繞過格式限制； Ø 是否有上傳空間的限制,是否可以超過空間所限制的大小,如將超過空間的大文件拆分上傳是否會出現(xiàn)異常錯誤。 Ø 上傳文件大小大于本地剩余空間大小，是否會出現(xiàn)異常錯誤。 Ø 關(guān)于上傳是否成功的判斷。上傳過程中，中斷。程序是否判斷上傳是否成功。 Ø 對于文件名中帶有中文字符，特殊字符等的文件上傳。兼容性測試的方法Ø 操作系統(tǒng)/平臺兼容 Ø 不同瀏

11、覽器的兼容 Ø 不同分辨率間的兼容 界面測試的方法Ø 風(fēng)格統(tǒng)一 Ø 重要的和常用的元素優(yōu)先布局，且放置在醒目的位置 Ø 布局合理緊湊，疏密有致 Ø 明顯區(qū)分只讀區(qū)域與可編輯區(qū)域 Ø 使用紅色的符號*'來標(biāo)記必填項(xiàng) Ø 語句流暢，表述清晰，沒有錯別字 Ø 字段名稱通俗易懂、盡量使用專業(yè)術(shù)語 1.1.4.2.5 易用性測試的方法Ø 易理解 Ø 易學(xué) Ø 易操作 Ø 吸引性 1.1.4.2.6 APP兼容性測試Ø 分辨率：現(xiàn)在市場上分辨率是的各種各樣的什么的分辨率

12、都有了，所以需要在app在不同的分辨率設(shè)備上進(jìn)行測試，顯示UI的效果怎么樣。Ø 系統(tǒng)：Android系統(tǒng)在不斷升級，就會產(chǎn)生不同系統(tǒng)版本，對系統(tǒng)版本是不斷進(jìn)行兼容來對來符合的系統(tǒng)的版本。而在市場上開發(fā)了不同的定制的版本，也需要進(jìn)行兼容。Ø 機(jī)型：現(xiàn)在所涉及到廠商生產(chǎn)的出來的機(jī)器較多，所以需要使用不同廠商的不同分辨率來進(jìn)行適配app的運(yùn)行的情況Ø 語言：現(xiàn)在的很多的app已經(jīng)支持較多的語言的，所以需要對語言方面進(jìn)行測試，是app顯示的語言國際化顯示的效果 1.1.4.2.7 測試用例的維護(hù)存在以下幾種情況，需對測試用例進(jìn)行更新： 先前的測試用例設(shè)計(jì)不全面或不準(zhǔn)確 部

13、分嚴(yán)重的軟件錯誤未在測試用例中覆蓋 新的版本有新功能的需求或改動 編寫的測試用例不規(guī)范或者語句錯誤 舊的測試用例不再適用 過程要點(diǎn) 詳細(xì)說明 輸入條件測試需求明確，測試計(jì)劃明確工作內(nèi)容根據(jù)測試計(jì)劃設(shè)計(jì)測試用例，設(shè)計(jì)參考原則：l 等價類劃分l 邊界值分析l 錯誤推測等l 業(yè)務(wù)知識及相關(guān)流程退出標(biāo)準(zhǔn)l 測試用例需要覆蓋所有的測試需求l 測試用例集需進(jìn)行評審并通過l 項(xiàng)目進(jìn)行過程中，適時的根據(jù)需求變更來對測試用例進(jìn)行維護(hù)責(zé)任人測試組成員.3 設(shè)計(jì)內(nèi)容評審注：測試計(jì)劃及測試用例的設(shè)計(jì)工作完成后，需通知項(xiàng)目組相關(guān)成員召開評審會議。在這之前需要將待評審的內(nèi)容發(fā)給相關(guān)人員熟悉和理解。過程要點(diǎn) 詳細(xì)說明 輸入

14、條件測試計(jì)劃、測試用例集完成工作內(nèi)容評審測試計(jì)劃內(nèi)容的正確性及合理性：l 測試環(huán)境、測試資源；l 測試需求范圍，各個測試需求的優(yōu)先級；l 測試策略及風(fēng)險管理等；評審測試用例集：l 測試用例優(yōu)先級l 測試用例集基于需求的覆蓋程度退出標(biāo)準(zhǔn)測試計(jì)劃及測試用例集評審?fù)ㄟ^責(zé)任人同行測試組，項(xiàng)目經(jīng)理，1.2 實(shí)施測試階段整體流程圖 測試交接過程要點(diǎn) 詳細(xì)說明 輸入條件測試設(shè)計(jì)內(nèi)容評審?fù)戤?，開發(fā)團(tuán)隊(duì)編碼工作完成，并已完成內(nèi)部測試；工作內(nèi)容1. 開發(fā)組根據(jù)測試啟動會上所規(guī)定的內(nèi)容，填寫送測單，向測試組提交測試內(nèi)容。2. 測試小組檢查提交部件的完整性和可測性：l 檢查接收的測試內(nèi)容（按照測試啟動會上所規(guī)定的交接

15、內(nèi)容）；l 檢查程序是否有病毒；l 能否正確安裝/卸載；l 檢查送測的軟件是否完整，能否進(jìn)行測試；退出標(biāo)準(zhǔn)提交部件經(jīng)測試組檢驗(yàn)通過責(zé)任人產(chǎn)品（項(xiàng)目）經(jīng)理，測試組長 實(shí)施測試 實(shí)施測試注:實(shí)施測試用例將花費(fèi)測試組大部分時間，這些工作都是建立在前期很多計(jì)劃工作的基礎(chǔ)上。過程要點(diǎn) 詳細(xì)描述 輸入條件測試組長于前一工作日定出當(dāng)日的測試計(jì)劃，確定可用的測試用例。工作內(nèi)容l 測試工程師根據(jù)測試計(jì)劃中分配給自己的測試任務(wù)和提供的測試用例，實(shí)施相應(yīng)的測試用例。l 記錄實(shí)施用例的結(jié)果，提交當(dāng)日測試紀(jì)錄。l 提交缺陷。退出標(biāo)準(zhǔn)測試用例中的所有任務(wù)被執(zhí)行，結(jié)果被記錄。責(zé)任人測試組成員提交階段性測試報告在約定的測試周

16、期完成之后，測試組長需要總結(jié)此次測試的結(jié)果，編寫階段性測試報告。過程要點(diǎn) 詳細(xì)描述 輸入條件測試組完成了預(yù)定周期的測試任務(wù)工作內(nèi)容測試組長根據(jù)此輪測試的結(jié)果，編寫階段性測試報告（參考測試階段性報告模板），主要應(yīng)包含以下內(nèi)容：l 測試報告的版本l 測試的人員和時間l 測試所覆蓋的缺陷測試組在這輪測試中所有處理的缺陷，報告測試組長處理的缺陷和實(shí)施工程師驗(yàn)證的缺陷。不僅要寫出覆蓋缺陷的總數(shù)，還要寫明這些缺陷的去向：l 測試新發(fā)現(xiàn)的缺陷數(shù)量l 上一版本活動缺陷的數(shù)量l 經(jīng)過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類l 測試評估寫明在這一版本中，那些功能被實(shí)現(xiàn)了，那些還沒有實(shí)現(xiàn)，這里只需寫明和上一版本不同

17、之處即可l 急待解決的問題寫明當(dāng)前項(xiàng)目組中面臨的最優(yōu)先的問題，可以重復(fù)提出退出標(biāo)準(zhǔn)在每輪測試結(jié)束之后應(yīng)盡快將符合標(biāo)準(zhǔn)的測試報告發(fā)給全項(xiàng)目組責(zé)任人測試組長回歸測試在每輪測試結(jié)束之后，由測試組重新針對修改后的最新版本，進(jìn)行回歸測試。過程要點(diǎn) 詳細(xì)描述 輸入條件在每輪測試中，按照現(xiàn)有的測試用例沒有新的缺陷被發(fā)現(xiàn)，測試報告中全部的活動缺陷都被解決。工作內(nèi)容l 測試組將按照測試計(jì)劃中對于回歸測試的策略對產(chǎn)品進(jìn)行回歸測試，回歸測試的用例屬于測試用例的一部分或者是全部測試用例，但不能超出原先預(yù)定的測試用例的范圍。l 記錄用例實(shí)施結(jié)果，提交回歸測試記錄。 退出標(biāo)準(zhǔn)l 回歸測試所運(yùn)行的用例全部通過l 缺陷經(jīng)過驗(yàn)

18、證l 所有缺陷都被指明處理方式責(zé)任人測試工程師 同行審查過程要點(diǎn) 詳細(xì)描述 輸入條件回歸測試結(jié)束，所有缺陷都被關(guān)閉。工作內(nèi)容1.進(jìn)行對測試組所測試項(xiàng)目或產(chǎn)品的測試審查工作.基本原則: l 不依據(jù)所設(shè)計(jì)測試用例,進(jìn)行自由測試. l 測試時間保持在3個正常工作日以內(nèi). l 如發(fā)現(xiàn)嚴(yán)重缺陷,則一輪測試結(jié)束后,更新版本,執(zhí)行回歸測試. 2.提交當(dāng)日測試紀(jì)錄. 3.編寫同行審查總結(jié)報告(報告以簡單為好). 退出標(biāo)準(zhǔn)同行審查沒有新的缺陷或沒有嚴(yán)重缺陷產(chǎn)生. 責(zé)任人同行測試組1.3 總結(jié)階段整體流程圖 測試報告總結(jié)在回歸測試結(jié)束之后，測試組長將要編寫測試總結(jié)報告，對測試進(jìn)行總結(jié)，并且提交給全體項(xiàng)目組，為產(chǎn)品

19、的后續(xù)工作提供重要的信息支持。過程要點(diǎn) 詳細(xì)描述 輸入條件測試組完成了所有的測試實(shí)施工作,同行審查結(jié)束. 工作內(nèi)容測試組長根據(jù)測試的結(jié)果，按照測試總結(jié)報告的文檔模板編寫測試報告，測試報告必須包含以下重要內(nèi)容：l 測試資源概述多少人、多長時間。l 測試結(jié)果摘要分別描述各個測試需求的測試結(jié)果，產(chǎn)品實(shí)現(xiàn)了哪些功能點(diǎn)，哪些還沒有實(shí)現(xiàn)l 缺陷分析按照缺陷的屬性分類進(jìn)行分析l 測試需求覆蓋率原先列舉的測試需求的測試覆蓋率，可能一部分測試需求因?yàn)橘Y源和優(yōu)先級的因素沒有進(jìn)行測試，那么在這里要進(jìn)行說明l 測試評估從總體對項(xiàng)目質(zhì)量進(jìn)行評估l 測試組建議從測試組的角度為項(xiàng)目組提出工作建議退出標(biāo)準(zhǔn)測試組長完成了符合標(biāo)

20、準(zhǔn)的測試報告，發(fā)送給全項(xiàng)目組。責(zé)任人測試組長 測試驗(yàn)收測試驗(yàn)收工作是在以上工作全部結(jié)束后，對測試的過程，效果進(jìn)行驗(yàn)收，宣布測試結(jié)束。過程要點(diǎn) 詳細(xì)描述 輸入條件測試組完成了所有的測試實(shí)施工作，測試組長完成符合標(biāo)準(zhǔn)的測試總結(jié)文檔工作內(nèi)容由測啟會上約定的驗(yàn)收組成員，對本次測試收進(jìn)行驗(yàn)收，驗(yàn)收內(nèi)容包括：l 測試效果驗(yàn)收測試是否達(dá)到預(yù)期目的l 測試文檔驗(yàn)收測試過程文檔是否齊全，可信，符合標(biāo)準(zhǔn)l 測試評估從總體對測試的質(zhì)量進(jìn)行評估l 測試建議對本次測試工作指出不足，需要在以后工作中改進(jìn)的地方l 宣布測試結(jié)束測試驗(yàn)收組成員簽字宣布本次測試結(jié)束退出標(biāo)準(zhǔn)測試驗(yàn)收通過，測試驗(yàn)收會議記錄整理完畢參與人員驗(yàn)收組人員

21、，測試經(jīng)理，測試組長，產(chǎn)品（項(xiàng)目）經(jīng)理 測試歸檔測試歸檔是在測試驗(yàn)收結(jié)束宣布測試有效，結(jié)束測試后，對測試過程中涉及到各種標(biāo)準(zhǔn)文檔進(jìn)行歸類，存檔。過程要點(diǎn) 詳細(xì)描述 輸入條件測試驗(yàn)收通過工作內(nèi)容歸類、存檔測試過程涉及到的文檔，主要包括以下文檔（必須）l 測試任務(wù)書l 測試計(jì)劃書l 測試用例書l 階段性測試報告l 測試總結(jié)報告l 測試驗(yàn)收會議記錄退出標(biāo)準(zhǔn)全部文檔歸類完畢，版本號封存責(zé)任人測試組長 測試工作總結(jié)過程要點(diǎn) 詳細(xì)描述 輸入條件項(xiàng)目驗(yàn)收工作完成。工作內(nèi)容由測試組長召開項(xiàng)目測試工作總結(jié)會議，會議內(nèi)容主要為：l 測試組長對項(xiàng)目期間的整個測試組的工作情況進(jìn)行總結(jié)，指出測試工作中存在的問題，同時也對工作中表現(xiàn)好的地方給與肯定。（具體包括整個測試情況、流程實(shí)施、人員安排、測試方法等）