【軟件測試系列二】《軟件測試流程規(guī)范》

1. 目標

2. 背景

3. 測試工作總要求

4. 測試流程概述

4.1. 需求評審

4.2. 測試設計階段

4.2.1. 測試計劃編寫

4.2.2. 設計測試用例

4.3. 計劃/用例/方案評審

4.4. 測試實施階段

4.4.1. 提交測試

4.4.2. 冒煙測試

4.4.3. 實施測試

4.4.4. 交叉測試

4.4.5. 系統(tǒng)測試

4.4.6. 測試總結(jié)

4.4.7. 出口準則

4.4.8. 軟件測試暫停標準

5. 其他規(guī)范

5.1. 缺陷管理

5.1.1. 缺陷屬性

5.1.2. 缺陷嚴重程度

5.1.3. Bug填寫規(guī)范

5.2. 版本管理

5.3. 測試環(huán)境

5.4. 測試用例設計方法

5.5. 安全測試

5.6. 文檔管理

5.7. 線上問題跟蹤

5.8. 月度會議

1.目標

持續(xù)建設能夠保證事業(yè)部產(chǎn)品質(zhì)量的測試隊伍和體系。

2.背景

測試團隊剛成立，測試工作還沒有形成一個完善的體系，為此編寫此文檔，旨在規(guī)范測試流程，明確產(chǎn)品各個階段的測試工作，逐漸形成一個完善的測試體系，真正實現(xiàn)對產(chǎn)品質(zhì)量的保證。

3.測試工作總要求

建立支撐事業(yè)部的測試團隊；

新產(chǎn)品對外發(fā)布、發(fā)布后產(chǎn)品的缺陷修改發(fā)布（補丁），均需測試通過方可執(zhí)行。緊急情況需對外發(fā)布時，需注明未測試。

研發(fā)團隊依據(jù)測試過程中定義的職責進行測試過程中的工作；

測試團隊對測試過程執(zhí)行情況進行跟進并執(zhí)行過程改進；

測試團隊依據(jù)《測試流程規(guī)范》開展工作；

完善支撐事業(yè)部測試開展的《測試流程規(guī)范》；

建立支撐事業(yè)部測試團隊運行的軟硬件環(huán)境；

4.測試流程概述

根據(jù)軟件開發(fā)流程，各個階段中測試工作以及對應的輸出如下：

4.1需求評審

過程要點

詳細說明

輸入條件

需求定義完成

工作內(nèi)容

測試團隊成員對需求中不清楚、不完整、太概括或存在疑義的地方提出問題，相關人員解答并確認。

輸出條件

所有人員對需求無異議

參與人員

需求調(diào)研人員、產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)組、測試組

注：?需求定義基本完成，此時應在評審會議召開之前發(fā)給測試團隊，預留時間給測試相關人員熟悉、理解。

4.2測試設計階段

4.2.1測試計劃編寫

針對需求分析文檔和產(chǎn)品開發(fā)計劃文檔，測試組需要編寫測試計劃文檔、制定測試策略及預估測試過程中的風險，并設計出合理的規(guī)避風險的策略，為后續(xù)的測試工作提供直接的指導。

過程要點

詳細說明

輸入條件

產(chǎn)品需求文檔，產(chǎn)品開發(fā)計劃完成。

工作內(nèi)容

1.根據(jù)產(chǎn)品的需求文檔、設計文檔，按照測試計劃文檔模板編寫測試計劃。

測試計劃中應該至少包括以下關鍵內(nèi)容：

依據(jù)產(chǎn)品背景及要求，確定測試環(huán)境。

測試需求——需要測試組測試的范圍，估算出測試所花費的人力資源和各個測試需求的測試優(yōu)先級

測試策略——確定產(chǎn)品的測試計劃內(nèi)容，整體測試的測試方法和每個測試需求的測試方法，同時做好測試進度安排及人員調(diào)整。

測試資源——本次測試所需要用到的人力、硬件、軟件、技術的資源

輸出文件——包括測試計劃、測試報告等等

風險管理——列舉出測試工作所可能出現(xiàn)的風險，歸入到風險管理中

測試計劃編寫完畢后，必須提交給產(chǎn)品組全體成員，并由產(chǎn)品組組中各個角色組聯(lián)合評審。

2.產(chǎn)品中編寫測試方案要求：

所屬產(chǎn)品中存在性能測試或安全測試，但在測試用例中無法描述，請編寫測試方案，例如：《##性能測試方案》。

如果產(chǎn)品中單獨執(zhí)行性能測試或安全測試，則需要編寫測試方案

輸出條件

產(chǎn)品的《測試計劃》/《測試方案》由產(chǎn)品組評審并通過.

在產(chǎn)品開發(fā)過程中，要適時的對測試計劃進行跟蹤，以及評估此計劃的完整性、可行性，在產(chǎn)品結(jié)束時還要最后評估一下測試計劃的質(zhì)量。

責任人

項目組測試負責人

4.2.2設計測試用例

在需求分析文檔評審確認后，測試組需要針對產(chǎn)品的測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標準，在出現(xiàn)線上問題后，測試用例會作為問題是否測試遺漏的依據(jù)。在用例的編寫過程中，具體的任務和責任人如下：

過程要點

詳細說明

輸入條件

需求明確，測試計劃明確

工作內(nèi)容

1.根據(jù)需求說明書或需求規(guī)格說明書分析形成測試需求，再根據(jù)測試需求分解成測試項，根據(jù)測試項編寫測試要點；

2.根據(jù)測試計劃、測試需求/測試要點設計測試用例，設計參考方法：

等價類劃分

邊界值分析

錯誤推測等

因果圖方法

判定表方法、場景法

業(yè)務知識及相關流程

輸出條件

《測試用例》需要覆蓋所有的測試需求

《測試用例》需要進行評審并通過

產(chǎn)品進行過程中，適時的根據(jù)需求變更來對測試用例進行維護。

責任人

測試組成員

備注：

測試過程中，根據(jù)實際執(zhí)行情況，進行用例的完善，包括新增、修改、刪除用例。

4.3計劃/用例/方案評審

測試計劃、測試用例、方案的設計工作完成后，需通知產(chǎn)品組相關成員召開評審會議。在這之前需要將待評審的內(nèi)容發(fā)給相關人員熟悉和理解。

過程要點

詳細說明

輸入條件

測試計劃、測試用例、方案完成

工作內(nèi)容

評審測試計劃、方案內(nèi)容的正確性及合理性：

測試環(huán)境、測試資源；

測試需求范圍，各個測試需求的優(yōu)先級；

測試策略及風險管理等；

評審測試用例：

測試用例優(yōu)先級

測試用例集基于需求的覆蓋程度

評審方式：

當測試小組為多人時，可以討論方式或者測試組負責人進行評審

當測試小組只有一個人的時候，建議將相關文檔提交產(chǎn)品經(jīng)理與產(chǎn)品組員進行評審。

測試計劃評審責任人：項目經(jīng)理、產(chǎn)品經(jīng)理、測試組

測試用例評審：項目經(jīng)理、產(chǎn)品經(jīng)理、測試組、開發(fā)干系人員

輸出條件

測試計劃、測試用例、方案評審通過。

責任人

測試組，項目經(jīng)理。

4.4測試實施階段

提交測試：當開發(fā)完成需求的實現(xiàn)并自測試通過后，按照提交測試的流程規(guī)范將軟件提交測試組進行測試；測試組接收測試軟件包后，檢查提交的文件是否正確、完整，不滿足條件打回，開發(fā)重新提交。

冒煙測試：在確認提交軟件可測后，執(zhí)行冒煙測試。冒煙測試即對系統(tǒng)的主功能、基本業(yè)務流程進行測試，驗證基本功能是否實現(xiàn)。冒煙測試通過，開始進行測試；冒煙測試不通過，打回版本包，開發(fā)修改再提交；

測試實施：根據(jù)測試用例、需求進行測試，將發(fā)現(xiàn)的問題提交到相應的管理工具，同時在測試用例中記錄測試結(jié)果；測試完成一輪后，開發(fā)修改問題后，再次將版本提交測試，測試人員對之前的問題進行驗證，同時對以前測試過的功能進行回歸測試；根據(jù)實際產(chǎn)品中問題解決的情況進行多輪測試，直至問題解決。

交叉測試：功能測試完成，問題都修改以后，測試人員A將功能交由測試人員B進行交叉測試，這樣可以避免單個人員測試存在漏測問題；

系統(tǒng)測試：每次版本發(fā)布前，需要對系統(tǒng)的主要功能（包含本次沒有修改的功能）進行回歸測試，保證主業(yè)務流程可以正常使用。

測試總結(jié)：測試完成以后，編寫測試報告，對所測系統(tǒng)進行問題總結(jié)。

測試過程中的流程如下圖：

4.4.1提交測試

過程要點

詳細說明

輸入條件

測試設計內(nèi)容（測試用例、測試計劃/測試方案）評審完畢，開發(fā)團隊編碼工作完成，并已完成內(nèi)部測試；

工作內(nèi)容

開發(fā)組根據(jù)測試計劃上所規(guī)定的內(nèi)容，將測試材料提交到SVN。

產(chǎn)品測試組負責人從SVN中獲得提交的測試內(nèi)容。

產(chǎn)品測試組檢查提交部件的完整性和可測性；

檢查測試提交單是否按照規(guī)范填寫

能否正確安裝/卸載；

檢查提測的軟件是否完整，能否進行測試

輸出條件

提交部件經(jīng)產(chǎn)品測試組檢驗通過，包含以下內(nèi)容

（1）軟件測試申請表（包含需求文檔、設計文檔、程序包等信息，明確標明已完成功能、未完成功能）

（2）郵件通知相關人員

（3）提測功能涉及的安裝部署操作手冊（根據(jù)具體功能而定）

責任人

項目經(jīng)理，項目組測試負責人

4.4.2冒煙測試

提交測試軟件在冒煙測試時，若發(fā)現(xiàn)致命級別錯誤（大于等于2）、嚴重界面錯誤（大于等于6），則暫停測試返回開發(fā)；提交測試軟件功能點少于計劃范圍內(nèi)功能模塊數(shù)的需要暫停，并與產(chǎn)品經(jīng)理協(xié)商處理。

4.4.3實施測試

實施測試將花費測試組大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。

過程要點

詳細描述

輸入條件

測試用例、被測軟件的需求文件

工作內(nèi)容

測試人員根據(jù)測試計劃中分配給自己的測試任務和提供的測試用例，執(zhí)行相應的測試工作。此過程可能需要分為多個輪次進行；每輪測試除了驗證問題，還需要對所測功能進行回歸測試；

記錄測試用例的結(jié)果；

提交缺陷。

輸出條件

測試用例中的所有任務被執(zhí)行，結(jié)果被記錄。

責任人

測試組成員

4.4.4交叉測試

過程要點

詳細描述

輸入條件

測試用例；被測功能所有問題已修改

工作內(nèi)容

測試人員交換功能進行測試，對主要功能進行測試，同時根據(jù)個人測試習慣對主要功能進行測試。

記錄測試用例的結(jié)果。

提交缺陷。

輸出條件

交叉測試結(jié)果。

責任人

測試組成員

4.4.5系統(tǒng)測試

過程要點

詳細描述

輸入條件

所有功能模塊已經(jīng)測試通過，問題已修改

工作內(nèi)容

根據(jù)系統(tǒng)測試用例，對系統(tǒng)的基本功能進行測試，確保新增功能沒有影響原有功能的正常使用

輸出條件

系統(tǒng)測試用例執(zhí)行通過。

責任人

測試組成員

4.4.6測試總結(jié)

階段性測試報告

在約定的測試周期（暫定每輪測試）完成之后，測試負責人需要總結(jié)此次測試的結(jié)果，編寫階段性測試報告。

過程要點

詳細描述

輸入條件

測試組完成了預定周期的測試任務

工作內(nèi)容

測試負責人根據(jù)此輪測試的結(jié)果，編寫階段性測試報告，主要應包含以下內(nèi)容：

測試報告的版本

測試的人員和時間

測試新發(fā)現(xiàn)的缺陷數(shù)量

上一版本活動缺陷的數(shù)量

經(jīng)過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類

測試評估——寫明在這一版本中，哪些功能被實現(xiàn)了，哪些還沒有實現(xiàn)，這里只需寫明和上一版本不同之處即可。對測試發(fā)現(xiàn)的問題進行分析，指明導致問題的原因，提出改進意見

急待解決的問題——寫明當前產(chǎn)品組中面臨的最優(yōu)先的問題，可以重復提出

輸出條件

在每輪測試結(jié)束之后盡快將符合標準的測試報告發(fā)給產(chǎn)品組。

郵件發(fā)送產(chǎn)品組成員，并將報告上傳SVN

責任人

項目組測試負責人

系統(tǒng)測試報告

測試工作結(jié)束或即將結(jié)束時，測試組就要開始著手準備系統(tǒng)測試報告，進行總結(jié)的工作。

過程要點

詳細描述

輸入條件

測試組完成了所有的測試實施工作

工作內(nèi)容

測試負責人根據(jù)測試的結(jié)果，編寫系統(tǒng)測試報告，系統(tǒng)測試報告必須包含以下重要內(nèi)容：

測試資源概述——多少人、多長時間。

測試結(jié)果摘要——分別描述各個測試需求的測試結(jié)果，產(chǎn)品實現(xiàn)了哪些功能點，哪些還沒有實現(xiàn)

缺陷分析——按照缺陷的屬性分類進行分析

測試需求覆蓋率——原先列舉的測試需求的測試覆蓋率，可能一部分測試需求因為資源和優(yōu)先級的因素沒有進行測試，那么在這里要進行說明

測試評估——從總體對產(chǎn)品質(zhì)量進行評估

測試組建議——從測試組的角度為產(chǎn)品組提出工作建議

輸出條件

測試負責人完成了符合標準的《系統(tǒng)測試報告》，發(fā)送給全項目組。

責任人

項目組測試負責人

4.4.7出口準則

測試用例設計已經(jīng)通過評審并執(zhí)行完畢；

按照系統(tǒng)測試計劃完成了測試；

達到了測試計劃中關于測試所規(guī)定的要求；

系統(tǒng)滿足需求規(guī)格說明書的要求；

測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復率達到標準：

致命、嚴重缺陷修復率應達到100%

一般、輕微缺陷修復率應達到95%以上

建議類缺陷（確認修改的）修復率應達到60%以上

4.4.8軟件測試暫停標準

提交測試軟件在進行冒煙測試時，發(fā)現(xiàn)致命級別錯誤或者嚴重級別錯誤，需暫停測試返回開發(fā)；

提交測試軟件功能點少于計劃范圍內(nèi)功能模塊數(shù)的需要暫停，并與產(chǎn)品經(jīng)理協(xié)商處理；

軟件產(chǎn)品需暫停以進行調(diào)整時，測試應隨之暫停，并備份暫停點數(shù)據(jù)；

軟件產(chǎn)品在其開發(fā)生命周期內(nèi)出現(xiàn)重大估算，進度偏差，需暫停或終止時，測試應隨之暫停或終止，并備份暫停或終止點數(shù)據(jù)。

5.其他規(guī)范

5.1缺陷管理

在測試過程中發(fā)現(xiàn)的任何與預期目標不符的現(xiàn)象和問題都必須詳細記錄下來，填寫測試記錄。為了能準確的找出問題產(chǎn)生的原因，及時的解決問題，保證測試工作的順利進行，一般來說所發(fā)現(xiàn)的問題必須是能夠重視的。

所有的缺陷需要記錄到jira中。

5.1.1缺陷屬性

屬性名稱

描述

缺陷標識

缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識。

缺陷嚴重程度

缺陷嚴重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。

缺陷優(yōu)先級

缺陷的優(yōu)先級指缺陷必須被修復的緊急程度。

缺陷狀態(tài)

缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況。

缺陷發(fā)現(xiàn)的階段(缺陷起源)

缺陷來起源指缺陷引起的故障或事件第一次被檢測到的階段。

缺陷引入的活動(缺陷來源)

缺陷來源指引起缺陷的起因。

5.1.2缺陷嚴重程度

序號

缺陷嚴重等級

描述

1.

致命缺陷

致命缺陷通常是一些致命的錯誤，造成系統(tǒng)或應用程序崩潰，死機，系統(tǒng)懸掛，或造成數(shù)據(jù)丟失，主要功能組完全喪失。

2

嚴重缺陷

通常是產(chǎn)品不穩(wěn)定、不安全、或產(chǎn)生缺陷結(jié)果，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題。

3

一般缺陷

程序的功能運行基本正常，但是存在一些需求、設計或?qū)崿F(xiàn)上的缺陷；次要功能運行不正常。

4

輕微缺陷

5

建議

具有建設性的問題。

注：對于缺陷嚴重等級的具體解釋

嚴重程度

說明

致命缺陷

（Fatal）

致命缺陷通常是一些致命的錯誤，不能完全滿足系統(tǒng)要求，基本功能未完全實現(xiàn)，死機，系統(tǒng)懸掛，系統(tǒng)崩潰或掛起等導致系統(tǒng)不能繼續(xù)運行，或造成數(shù)據(jù)丟失，主要功能組完全喪失。以下屬于致命缺陷：

1.由于程序所引起的死機,非法退出?2.死循環(huán)?3.數(shù)據(jù)庫發(fā)生死鎖?4.因錯誤操作導致的程序中斷?5.重大功能錯誤?6.與數(shù)據(jù)庫連接錯誤?7.數(shù)據(jù)通訊錯誤。

例如：

（1）架構(gòu)設計不合理，影響系統(tǒng)性能以及功能的合理實現(xiàn)；

（2）重要數(shù)據(jù)庫表設計不合理，數(shù)據(jù)流混亂；

（3）用戶需求理解重大歧義，嚴重不符合常規(guī)業(yè)務邏輯；需求中的重要功能未實現(xiàn)。

（4）程序?qū)崿F(xiàn)與設計間存在嚴重不一致；

（5）造成系統(tǒng)崩潰、死機,并且不能通過其它方法實現(xiàn)功能；

（6）（6）與數(shù)據(jù)庫連接錯誤或異常中斷。

（7）（7）常規(guī)操作中發(fā)生程序非法退出、死循環(huán)、導致程序無法運行、通訊中斷或異常，數(shù)據(jù)破壞丟失或數(shù)據(jù)庫異常且不能通過其它方法實現(xiàn)功能的；

（8）C/S、B/S模式下，利用客戶端某些操作可造成服務端不能繼續(xù)正常工作的。

（9）系統(tǒng)性能不能滿足客戶的需求，①并發(fā)用戶數(shù)不能滿足用戶需求，系統(tǒng)出現(xiàn)宕機或停止響應；②多用戶并發(fā)時，系統(tǒng)響應時間不滿足用戶需求；③多用戶并發(fā)時，程序數(shù)據(jù)處理出現(xiàn)錯誤，例如生成的序號跳號；④重要功能的響應時間不能滿足用戶需求；

嚴重缺陷

（high）

通常是影響系統(tǒng)要求或基本功能的實現(xiàn)，系統(tǒng)不穩(wěn)定、不安全、或產(chǎn)生缺陷結(jié)果，使系統(tǒng)不穩(wěn)定、或破壞數(shù)據(jù)、或產(chǎn)生錯誤結(jié)果，或部分功能無法執(zhí)行，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題。而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題。以下屬于嚴重缺陷:

1.程序接口錯誤?2.因錯誤操作迫使程序中斷3.?系統(tǒng)可被執(zhí)行，但操作功能無法執(zhí)行（含指令）?4.?單項操作功能可被執(zhí)行，但在此功能中某些功能（含指令參數(shù)的使用）無法被執(zhí)行（對系統(tǒng)非致命的）?5.?在功能項的某些產(chǎn)品（選項）使用無效（對系統(tǒng)非致命的）?6.業(yè)務流程不正確?7.功能實現(xiàn)不完整，如刪除時沒有考慮數(shù)據(jù)關聯(lián)?8.功能的實現(xiàn)不正確，如在系統(tǒng)實現(xiàn)的界面上，一些可接受輸入的控件點擊后無作用；對數(shù)據(jù)庫的操作不能正確實現(xiàn)?9.?報表格式以及打印內(nèi)容錯誤（行列不完整，數(shù)據(jù)顯示不在所對應的行列等導致數(shù)據(jù)顯示結(jié)果不正確的錯誤）9.在測試過程中執(zhí)行安全測試是發(fā)現(xiàn)的缺陷一律設置為嚴重級別.

例如：

（1）程序的功能運行基本正常，但是存在一些需求、設計或?qū)崿F(xiàn)上的缺陷；次要功能運行不正常，如：次要功能不能正常實現(xiàn)；

（2）重要功能不能按正常操作實現(xiàn)，但可通過其它方法可實現(xiàn)；

（3）程序接口錯誤；

（4）數(shù)據(jù)庫表中有過多的空字段；

（5）數(shù)據(jù)庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件；

（6）（功能錯誤，功能輸出非預期結(jié)果（例如：出現(xiàn)編譯錯誤或404錯誤）；功能冗余；功能雖實現(xiàn)但不夠完整；功能基本能實現(xiàn)，但系統(tǒng)不穩(wěn)定、一些邊界條件下操作會導致run-time error、文件操作異常、通訊異常、數(shù)據(jù)丟失或破壞等錯誤。

（7）非常規(guī)的操作，造成程序非法退出、死循環(huán)、導致程序無法運行、通訊中斷或異常，數(shù)據(jù)破壞丟失或數(shù)據(jù)庫異常且不能通過其它方法實現(xiàn)功能的；

（8）重要功能不能按正常操作實現(xiàn)，但可通過其它方法可實現(xiàn)；

（8） （9）重要資料，如密碼未加密存放（包括配置文件中的密碼），或其它存在安全性隱患的；

（9） （10）硬件或通訊介質(zhì)發(fā)生異常恢復后，系統(tǒng)不能自動正常繼續(xù)工作（需要過多的人工干預才行）；

（11）?缺陷的波及面廣，影響到其它重要功能正常實現(xiàn)。

（12）采用安全測試工具或手工執(zhí)行安全測試時，出現(xiàn)以下漏洞,如：

A.注入類缺陷；B．失效的身份認證和會話管理；C．跨站腳本；D．安全配置錯誤；E.敏感數(shù)據(jù)暴露；F．功能級別訪問控制缺失；G．跨站請求偽造；使用已知易受攻擊組件；H.?未驗證的重定向和轉(zhuǎn)發(fā)

一般缺陷

（Medium）

程序的功能運行基本正常，但是存在一些需求、設計或?qū)崿F(xiàn)上的缺陷；次要功能運行不正常，但存在合理的更正辦法（重新安裝或重新啟動該軟件不屬于更正辦法）。系統(tǒng)性能或響應時間變慢、產(chǎn)生錯誤的中間結(jié)果但不影響最終結(jié)果等影響有限的問題：

1.操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）?2.打印內(nèi)容、格式錯誤（只影響報表的格式或外觀，不影響數(shù)據(jù)顯示結(jié)果的錯誤）?3.簡單的輸入限制未放在前臺進行控制?4.刪除操作未給出提示?5.雖然正確性不受影響，但系統(tǒng)性能和響應時間受到影響?6.不能定位焦點或定位有誤，影響功能實現(xiàn)?7.?顯示不正確但輸出正確?8.?增刪改功能，在本界面不能實現(xiàn)，但在另一界面可以補充實現(xiàn)。

例如：

系統(tǒng)兼容性差，與其它支持系統(tǒng)一起工作時容易出錯，而沒有充分理由說明是由支持系統(tǒng)引起的；

或者由于使用了非常規(guī)技術或第三方組件造成不能使用自動化測試工具進行測試的。

（11）（3）密碼明文顯示；

（4）經(jīng)過一段時間運行后，系統(tǒng)性能或響應時間會變慢；

（5）操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義不一致）；打印內(nèi)容、格式錯誤；查詢錯誤，既定的查詢條件不能得到預期結(jié)果；

（6）執(zhí)行添加、編輯、刪除操作造成數(shù)據(jù)保存或刪除錯誤；

（7）（流程中）按非正常業(yè)務流程運行時程序非法或中斷退出；因錯誤操作迫使程序中斷；

（8）為空字段輸入控制不滿足要求，非空字段未輸入值可以保存成功；未識別、剔除導入的非法數(shù)據(jù)，對系統(tǒng)后續(xù)操作造成影響；

（9）一般數(shù)據(jù)項或標志位字段賦值錯誤，影響系統(tǒng)后續(xù)運行；

輕微缺陷

（low）

1.界面不規(guī)范?2.輔助說明描述不清楚?3.輸入輸出不規(guī)范4.長時間操作未給用戶提示?5.提示窗口文字未采用行業(yè)術語?6.?可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志?7.?必填項與非必填項應加以區(qū)別?8.?滾動條無效

9.?鍵盤支持不好，如在可輸入多行的字段中，不支持回車換行；或?qū)ο嗤?段，在不同界面支持不同的快捷方式?10.?界面不能及時刷新，影響功能實現(xiàn)

例如：

（1）（1）界面在一些顯示上不美觀，不符合用戶習慣，或者是一些文字的錯誤，如：界面不規(guī)范、輔助說明描述不清楚、輸入輸出不規(guī)范（包括輸入長度，輸入字符限制，特殊輸入要求（例如:特殊字符處理錯誤，包括：“‘；<>等特殊字符）判斷，圖片上傳限制錯誤和文件上傳限制錯誤等）、界面存在文字錯誤；

（2）（2）模塊間按鈕名稱、用途不一致；

（3）（3）系統(tǒng)整體界面風格不一致；

（4）（4）提示信息不一致，易造成操作歧義；（執(zhí)行刪除操作未給出提示，或只有提示單一確認項）；

（5）提示窗口文字未采用行業(yè)術語；

（6）可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志；

（7）簡單的輸入限制未放在前臺進行控制；

（8）長時間操作未給用戶提示（或長時間操作結(jié)束后提示沒有消失）；

（9）（9）在功能實現(xiàn)方式上如果需求中沒有明確定義，而沒有按常規(guī)實現(xiàn)，并且不比常規(guī)方式實現(xiàn)優(yōu)越的；( 如用戶名第一位用數(shù)字或特殊字符)；

（10）選擇記錄數(shù)據(jù)時，無法按照類型排序，選擇不方便。

建議類缺陷

（suggestion）

建議性的改進要求（包括功能操作，校驗說明，相關文檔等）。

5.1.3Bug填寫規(guī)范

關鍵字段

填寫要求

標題

描述清楚問題所在模塊哪個界面入口，簡單描述問題

重現(xiàn)步驟

前置條件：如果問題有提前條件需要描述清楚

步驟：對于復雜問題需要清晰的描寫重現(xiàn)步驟；要做到開發(fā)根據(jù)操作步驟可以重現(xiàn)問題

結(jié)果：描述實際操作結(jié)果

期望結(jié)果：描述正確的結(jié)果

截圖：可以截圖的問題盡量截圖，將截圖貼到重現(xiàn)步驟中，方便開發(fā)查看

Bug類型

根據(jù)Bug進行判斷，是屬于哪一類問題

嚴重程度

依據(jù)缺陷嚴重程度標準進行bug嚴重程度選擇

問題優(yōu)先級

根據(jù)問題的緊急情況，設置優(yōu)先級

5.2版本管理

版本號定義標準

測試版本號：

版本號構(gòu)成：主版本.子版本.修正版本號

初始版本時V1.0或者V1.0.0

修改bug或者局部修改，修正版本號+1

增加部分功能，子版本號+1，修正版本號歸0

重大修改或者局部修正積累較多，系統(tǒng)全局有所改變，主版本號+1

發(fā)布版本號：

發(fā)布時在原版本號后加_Release

在更新SQL中增加版本信息，參考下列信息

/*========== 2018-02-26版本結(jié)束標識 開始================================*/

INSERT INTO Sys_ManualUpdateHistory(Muh_Flag,Muh_Version,Muh_Updatelog)

VALUES('BOS','V1.3.0_release','變價生效時間問題修改');

/*=========== 2018-02-26版本結(jié)束標識 ?結(jié)束==============================*/

5.3測試環(huán)境

a) 測試環(huán)境由測試人員進行維護，不允許開發(fā)人員對測試環(huán)境進行修改

b) 測試環(huán)境與開發(fā)環(huán)境分離，包括數(shù)據(jù)庫以及程序包，不允許出現(xiàn)類似開發(fā)測試共用一個數(shù)據(jù)庫的情況。

c) 每次部署新包前，備份測試環(huán)境數(shù)據(jù)庫。

5.4測試用例設計方法

詳見《測試用例編寫規(guī)范與設計方法.docx》

5.5安全測試

根據(jù)產(chǎn)品情況決定是否需要進行安全掃描。

5.6文檔管理

測試完成后，所有測試文檔需要上傳到云盤空間指定的目錄下。

5.7線上問題跟蹤

由實施人員或者客戶提出的問題，測試人員在測試環(huán)境上進行驗證確認問題，確認為問題后需要錄入jira中，問題要特殊標識為線上問題。

5.8月度會議

由測試人員統(tǒng)計本月bug分布解決情況，分析當前測試功能存在的問題；產(chǎn)品組人員一起參與會議，對問題進行分析，提出解決方案

責任人：項目組所有人員

單元測試 壓力測試 移動應用測試 MobileAPPTest 自動化測試

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。