軟件測試標準規(guī)范

目的為了確保軟件產(chǎn)品質(zhì)量，使產(chǎn)品能夠順利交付和通過驗收，特編寫本文檔，以作參考

適用范圍

本文檔適用于項目開發(fā)過程中的單元測試、集成測試、系統(tǒng)測試、業(yè)務測試、驗收測試以及一些專項測試。

職責

?

項目測試負責人組織編制《測試計劃》、《測試方案》，指導和督促測試人員完成各階段的測試工作。

?

項目組測試人員按照《測試計劃》、《測試方案》完成所承擔的測試任務，并按要求填寫《問題報告及維護記錄》。

?

測試經(jīng)理依照確認規(guī)程和準則對工作產(chǎn)品進行確認，提出對確認規(guī)程和準則的修改意見

?

項目負責人組織測試環(huán)境的建立。

?

項目經(jīng)理審核負責控制整個項目的時間和質(zhì)量。

?

研發(fā)人員確認修改測試人員提交的bug。

工作流程

4.1

測試依據(jù)

詳細設計是模塊測試的依據(jù)。因此設計人員應向測試人員提供《系統(tǒng)需求規(guī)格書名書》、《詳細設計》、《概要設計》等有關資料。測試人員必須認真閱讀，真正弄懂系統(tǒng)需求和詳細設計。

4.2

制訂《測試方案》

在測試之前，由項目負責人根據(jù)《測試計劃》的要求，組織人員編制相應的《測試方案》，《測試方案》應包括以下內(nèi)容：

?

測試目的；

?

所需人員及相應培訓要求；

?

測試環(huán)境、工具和測試軟件；

?

測試用例、測試數(shù)據(jù)和預期的結(jié)果。

4.3

單元測試

項目開發(fā)實現(xiàn)過程中，每個程序單元（程序單元的劃分視具體開發(fā)工具而定，一般定為函數(shù)或子程序級）編碼調(diào)試通過后，要及時進行單元測試。

單元測試由單元開發(fā)者自己進行，使用白盒測試方法，根據(jù)程序單元的控制流程，爭取達到分支覆蓋。對于交互式運行的產(chǎn)品，不便于進行自動測試的，可以采用功能測試的方法進行。

單元測試針對程序模塊，從程序的內(nèi)部結(jié)構(gòu)出發(fā)設計測試用例。多個模塊可以獨立進行單元測試。

?

單元測試內(nèi)容包括模塊接口測試、局部數(shù)據(jù)結(jié)構(gòu)測試、路徑測試、錯誤處理測試等；

?

單元測試組織原則一遍根據(jù)開發(fā)進度安排對已開發(fā)完成的單一模塊進行測試；

?

單元測試停止標準：完成了所有規(guī)定單元的測試，單元測試中發(fā)現(xiàn)的bug已經(jīng)得到修改。

4.4

集成測試

編碼開發(fā)完成，項目組內(nèi)部應進行組裝測試。

集成測試由項目負責人組織策劃（編寫測試計劃、測試用例）并實施。集成測試著重對各功能模塊之間的接口進行測試，驗證各功能模塊是否能協(xié)調(diào)工作、參數(shù)傳遞及功能調(diào)用是否正常。測試采用交叉方法，即個人開發(fā)的軟件應由其他的項目組成員進行測試。

集成測試過程應填寫《問題報告及維護記錄》，測試結(jié)果應形成《測試報告》。

4.5

系統(tǒng)測試

在項目開發(fā)完成之后，應對整個系統(tǒng)軟件和硬件進行系統(tǒng)測試。對性能、可靠性、健壯性、壓力承受力等方面分別進行評價，以驗證系統(tǒng)是否滿足規(guī)定的需要。

系統(tǒng)測試由測試負責人組織策劃（編寫測試計劃、測試用例）并實施，系統(tǒng)測試過程應形成《問題報告及維護記錄》。

系統(tǒng)測試一般進行如下幾種情況的測試：

?

正常情況

?

非正常情況

?

破壞性測試

?

邊界情況

?

非法情況

?

強度測試

?

性能測試

?

兼容性測試

?

用戶友好性測試

界面設計規(guī)范測試：

?

光標的初始位置

?

字體是否統(tǒng)一

?

字號是否符合規(guī)定

?

標題顏色

?

按鈕的名稱是否規(guī)范

?

界面布局是否合理，整體效果如何

輸入值測試：

?

數(shù)據(jù)類型

?

數(shù)據(jù)長度

?

約束條件是否滿足，是否完整

?

TAB和Enter鍵是否起作用

?

鍵盤操作能否全部代替鼠標操作

?

輸入（光標）是否按照順序前進

按鈕測試：

?

將按鈕放開和封閉是否嚴格、準確，不能使用的按鈕必須封閉

?

檢查“退出”、“取消”等具有共性按鈕的功能

異常情況測試：

在完成正常功能測試后，安正常處理的相同操作順序，執(zhí)行與正常處理不同的動作例如

?

正常處理中要求輸入日期的字段，這時輸入字符或數(shù)字

?

正常處理中輸入字段有范圍要求，這時輸入超過范圍的值

?

正常處理中用兩個值限定范圍，這時用一個值或不限定

?

正常處理中要求用“Tab”鍵，這時安“Enter”鍵或其他鍵

?

正常處理中單選框、多選框、下拉框等，十一偶那個非指定鍵操作

?

使用不同于指定的按鈕操作

4.6

業(yè)務測試

在組裝測試與系統(tǒng)測試結(jié)束后，均可由最終用戶或測試人員對系統(tǒng)進行測試。業(yè)務測試著重測試業(yè)務流程，功能、用戶界面等方面。

項目、測試負責人負責組織相關人員制定測試方案和測試用例，并進行測試。

測試的結(jié)果應形成《問題報告及維護記錄》。

4.7

驗收測試

4.7.1

驗收測試的條件

?

按照項目計劃規(guī)定的驗收測試進度安排進行測試準備

?

在驗收測試前，各項內(nèi)部的測試活動都受到監(jiān)控并爭取執(zhí)行

4.7.2

交付版本的要求

?

按照集成測試用例完成了整個系統(tǒng)的集成測試

?

集成版本滿足設計定義的各項功能、性能要求

?

提交的數(shù)據(jù)庫腳本樣本需要完整，沒有冗余數(shù)據(jù)

?

在集成測試中發(fā)現(xiàn)的bug已經(jīng)得到解決，各級缺陷修改率達到標準

?

軟件需求分析說明書中定義的所有功能都已經(jīng)實現(xiàn)，性能指標全部達到性能需求指標

?

提交階段性測試報告，包括功能和性能測試報告

?

所有文檔齊備完整

4.7.3

版本發(fā)布的準則

?

軟件產(chǎn)品通過了單元測試、集成測試、業(yè)務測試、系統(tǒng)測試、性能測試

?

測試部提交文檔：測試計劃、測試方案、測試用例、測試分析報告

?

所有測試項必須符合以下標準

n

致命錯誤：無

n

功能錯誤：無

n

功能缺陷：項目經(jīng)理、技術經(jīng)理、測試負責人審核通過

n

界面缺陷：項目經(jīng)理、技術經(jīng)理、測試負責人審核通過

n

建議：項目經(jīng)理、技術經(jīng)理、測試負責人審核通過

?

以上幾項其中之一不滿足要求，視為不合格

在產(chǎn)品交付和用戶驗收之前，通過驗收測試來確認在規(guī)定的使用環(huán)境下整個產(chǎn)品的運行情況是否滿足規(guī)定的要求。

在產(chǎn)品交付之前，由指定的驗收負責人組織制定測試方案和測試用例，主持驗收。

驗收測試過程應形成《問題報告及維護記錄》。

4.8

用戶現(xiàn)場測試

將軟件部署到用戶實際生產(chǎn)環(huán)境后，由于環(huán)境差異，需要在用戶現(xiàn)場進行確認測試，保證系統(tǒng)功能、性能完備，可正常運行。測試內(nèi)容：

?

根據(jù)軟件系統(tǒng)規(guī)模，準備現(xiàn)場測試用例，涵蓋所有重要功能點，若規(guī)模小，需要將全部功能點全部測試一遍

?

對于后臺已定義好的工作流、功能欄目路徑以及用戶信息等數(shù)據(jù)，不可進行修改和刪除操作，新增的測試數(shù)據(jù)也需要在測試完成后給予清楚

?

重點檢查上傳、下載的數(shù)據(jù)是否可以正常的打開或保存

?

確認界面美觀，基本信息和鏈接無錯誤

?

考慮用戶實際的軟件環(huán)境和網(wǎng)絡環(huán)境，以客戶端最為復雜的軟硬件環(huán)境作為測試機器，檢查有無異常情況出現(xiàn)

?

針對前期發(fā)現(xiàn)的bug進行回歸測試，以保證發(fā)布版本為最新版本

4.9

編寫測試文檔

4.9.1

測試點

將測試模塊分解成多個功能點，測試點應涵蓋功能點，也涵蓋了正常測試和異常測試。

4.9.2

輸入數(shù)據(jù)

輸入數(shù)據(jù)包括界面輸入數(shù)據(jù)、數(shù)據(jù)庫的初始數(shù)據(jù)及其他外部輸入數(shù)據(jù)。特別是數(shù)據(jù)庫的初始所需屬性一一列出，全面是指：數(shù)據(jù)能達到模塊所涉及的全部功能，典型是指這個數(shù)據(jù)能充分反映功能特點。

4.9.3

測試描述

描述測試步驟，包括：操作員所執(zhí)行的動作（包括鼠標、鍵盤、加載外部數(shù)據(jù)等操作）；系統(tǒng)的反應，包括：光標定位、光標聚焦、顯示字段值、按鈕的封閉和放開、功能鍵的封閉和放開、系統(tǒng)提示和系統(tǒng)消息等。

4.9.4

預期輸出數(shù)據(jù)

按準備的輸入數(shù)據(jù)和設計要求的處理過程，模塊應輸出的數(shù)據(jù)。

輸出數(shù)據(jù)包括：屏幕輸出數(shù)據(jù)、輸出到數(shù)據(jù)庫的數(shù)據(jù)、輸出到其他外部介質(zhì)上的數(shù)據(jù)，并指出斷點結(jié)果或最終結(jié)果。

4.9.5

實際輸出

填寫本測試點程序運行后的實際輸出。

4.9.6

正確與否

程序運行后，實際輸出結(jié)果和預期輸出結(jié)果一致時，為正常，否則為不正常。

4.9.7

測試結(jié)論

填寫本次測試的結(jié)論，是合格或不合格。若不合格時，應總結(jié)存在的問題，可以讓修改者一目了然。

缺陷管理

5.1

缺陷的定義及其基本屬性

缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題，這些問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質(zhì)量。缺陷應該具備以下屬性，也就是往缺陷管理庫或者缺陷列表中提交的缺陷應該具備以下屬性：

屬性名稱

描述

缺陷標識

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

缺陷類型

根據(jù)缺陷的自然屬性劃分的缺陷種類

缺陷驗證程度

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

缺陷所處的模塊或子系統(tǒng)

缺陷分步的模塊或子系統(tǒng)

缺陷出現(xiàn)幾率

指發(fā)現(xiàn)錯誤的幾率

缺陷的重現(xiàn)步驟

詳細的缺陷重現(xiàn)步驟

附件

與缺陷相關的附件（截圖、附件、用例等）

備注

對缺陷的其他描述

5.2

缺陷分類

根據(jù)缺陷的定義，將缺陷分為如下列：

?

文檔缺陷：是指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定，被評審的對象包括最終出產(chǎn)物和中間過程產(chǎn)出物，比如需求文檔、設計文檔、計劃、報告、用例等

?

代碼缺陷：是指對代碼進行同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷

?

測試缺陷：是指由測試活動發(fā)現(xiàn)的測試對象（被測對象一般是指可運行的代碼、系統(tǒng)，不包括靜態(tài)測試發(fā)現(xiàn)的問題）的缺陷，測試活動包括單元測試、集成測試、系統(tǒng)測試、性能測試等

?

過程缺陷：有稱為不符合項問題，是指通過過程審計、過程分析、管理評審、質(zhì)量評估、質(zhì)量審核等活動發(fā)現(xiàn)的關于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試人員、項目經(jīng)理等

5.3

文檔缺陷分類

缺陷分類

描述

描述不完整

文檔內(nèi)容缺失，或文檔應該包括的范圍沒有涵蓋

不一致

一致性問題有兩類：

一是與源頭說明書不一致，比如需求和客戶業(yè)務需求不一致、設計與需求不一致等

二是上下文或者與前提不一致

描述錯誤

文檔描述是錯誤的，不可實現(xiàn)或?qū)е洛e誤的輸出或結(jié)果

功能問題

該缺陷將會導致用戶功能的錯誤、不滿足、不可用

不清楚或有歧義

內(nèi)容的描述不清楚、不能準確表達、或表達的意思有歧義

邏輯錯誤

內(nèi)容組織邏輯不清楚、邏輯錯誤

接口問題

與最終用戶接口問題、與外部系統(tǒng)的接口問題、內(nèi)部子系統(tǒng)或模塊的接口問題

輸入輸出問題

輸入輸出不完整、不正確、不可測試或驗證

不細化

內(nèi)容還需要進一步細化

性能問題

文檔的設計或?qū)崿F(xiàn)方式存在性能問題

安全性問題

文檔的設計或?qū)崿F(xiàn)方式存在安全性問題

5.4

代碼缺陷分類

缺陷分類

描述

常量變量定義問題

不滿足設計或需求

編寫代碼不符合規(guī)范

條件判斷處理

循環(huán)處理錯誤

異常處理

算法邏輯問題

注釋問題

代碼冗余

性能問題

5.5

系統(tǒng)測試缺陷分類

缺陷類型

描述

功能錯誤

影響了重要的特性、用戶界面、產(chǎn)品接口或全局數(shù)據(jù)結(jié)構(gòu)，并且設計文檔需要爭取的變更。如邏輯、循環(huán)、遞歸、功能等缺陷

結(jié)構(gòu)錯誤

Web應用程序結(jié)構(gòu)化頁面無法顯示，或者顯示錯誤

腳本錯誤

Web應用程序當中出現(xiàn)腳本錯誤，包括客戶端對數(shù)據(jù)進行校驗和運算的各種情況下產(chǎn)生的錯誤

頁面鏈接錯誤

Web應用程序頁面出現(xiàn)空鏈接、錯誤鏈接、死鏈接

頁面文字錯誤

Web應用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編碼錯誤

頁面圖形錯誤

Web應用程序頁面出現(xiàn)圖片內(nèi)容使用不當，或者無法顯示

ALT錯誤

Web應用程序頁面當中超文本標識語言、文本標簽解釋錯誤

排版錯誤

Web應用程序頁面排版不符合要求或者不符合使用習慣

業(yè)務邏輯不合理

應用程序的實現(xiàn)流程和規(guī)定業(yè)務流程不一致，或者實現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的部分并行、爭用、同步等操作，引起的流程斷裂、死鎖、以及其他異常情況

業(yè)務邏輯不方便

應用程序?qū)崿F(xiàn)流程在實際情況下雖然可以完成，但是存在不必要的反復、等待、冗余等影響使用效率的情況

其他錯誤

其他未分類錯誤

建議

系統(tǒng)改進建議

5.6

缺陷等級定義

缺陷的嚴重程度對以上所述的缺陷類型都是適合的，缺陷的嚴重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。

缺陷等級

缺陷性質(zhì)

系統(tǒng)中對應的錯誤分類

描述

一級

致命錯誤

系統(tǒng)崩潰

系統(tǒng)死鎖

導致對被描述的主要對象的理解錯誤、不可行、不可運轉(zhuǎn)、對業(yè)務和整個系統(tǒng)造成重大損失或損害；對使用、維護或保管人員有危險或不安全，以及對產(chǎn)品的基本功能有致命影響的缺陷

二級

嚴重缺陷

嚴重錯誤

對被描述的部分對象的理解或?qū)崿F(xiàn)錯誤，部分的模塊或系統(tǒng)不可行或不能運轉(zhuǎn)或部分模塊和系統(tǒng)缺失，對整個系統(tǒng)有重大影響或可能造成部分的損失或損害；嚴重影響使用安全

三級

一般缺陷

次要錯誤

布局不合理

文字錯誤

系統(tǒng)中部分單元模塊或單個功能描述和實現(xiàn)有錯誤、有偏差、不一致或有缺失，不影響模塊的正常運行，或有影響，但可以有替代的辦法或避免辦法

四級

微小缺陷

微不足道

基本不影響系統(tǒng)的運行和功能的實現(xiàn)。但是與標準、規(guī)范和定義不一致

五級

建議缺陷

新特性

不在定義、標準、范圍的定義和約束之內(nèi)，但是從提出者來看是需要完善的建議

5.7

缺陷優(yōu)先級定義

缺陷優(yōu)先級

描述

特急

需要立刻進行修改

加急

一天到兩天之內(nèi)必須修改

高

介于中和加急之間

中

缺陷需要正常排隊等待修復或列入軟件發(fā)布清單

低

留到組后解決，如果項目的進度跟緊張可以在產(chǎn)品發(fā)布以前不解決

5.8

缺陷狀態(tài)定義

缺陷狀態(tài)

描述

初始狀態(tài)（New）

測試或開發(fā)人員提交一個新的缺陷，等待開發(fā)人員或項目經(jīng)理分配修改負責人

打回（FeedBack）

要求缺陷的報告者再次對缺陷進行說明

已分配（Assigned）

是指已經(jīng)分配給屬主，等待修改。

已解決（Resolved）

缺陷被屬主修改，等待測試人員驗證

關閉（Closed）

測試人員驗證缺陷已經(jīng)修復

重新打開（Reopen）

測試人員驗證，缺陷沒有修改正確

遺留（Later）

經(jīng)項目經(jīng)理和技術經(jīng)理驗證此缺陷在本版本中不用修改

5.9

缺陷完成度

缺陷完成度

描述

打開（Open）

缺陷沒有被解決

已解決（Fixed）

缺陷已經(jīng)修改

遺留（Suspended）

此缺陷步驟本階段解決

重新打開（Reopen）

重新打開某個缺陷

不做修改（Won’t

fix）

不對這個缺陷進行修改

重復（Duplicate）

與某個缺陷重復

需求如此

經(jīng)理和開發(fā)人員經(jīng)過需求和設計的核實后決定不需要修改

不可重現(xiàn)

被指派的開發(fā)人員想要再現(xiàn)缺陷進行修改個時候，發(fā)現(xiàn)缺陷始終不能再現(xiàn)

5.10

缺陷管理流程

處理機制

6.1

退回機制

若在測試過程中發(fā)生如下情況，將系統(tǒng)退回到申請部門：

?

經(jīng)過測試后，發(fā)現(xiàn)與需求說明規(guī)格說明書中定義的功能項存在較大的差異

?

單一模塊，測試過程中發(fā)現(xiàn)缺陷輸了較多或者無法繼續(xù)進行系統(tǒng)其它功能模塊的測試，繼續(xù)測試無意義

?

測試過程中，頻繁死機或系統(tǒng)崩潰

?

主業(yè)務流程出現(xiàn)斷點

6.2

異常情況處理機制

非正常情況下，需要進行特別處理的情形，此情況需要主管領導簽字確認：

?

上線時間緊急的情況下，未經(jīng)測試部充分測試就需要部署到用戶現(xiàn)場

?

作為總包時，子商進度明顯延遲，尚未進行驗收測試就需要上線

6.3

報告機制

若出現(xiàn)以下情況，需要及時向部門領導和項目經(jīng)理匯報的情況：

?

測試后期出現(xiàn)重大邏輯錯誤，修改測試影響上線時間

?

測試過程中用戶需求出現(xiàn)重大變更

?

測試負責人定期匯報測試情況

測試完成的標準

7.1

被測試出的、在軟件錯誤級別分類中定義的：

?

一級缺陷，致命錯誤，100%得到修改并且復測通過

?

二級缺陷，嚴重錯誤，100%得到修改并且復測通過

?

三級缺陷，一般錯誤，95%得到修改并且復測通過

?

四級缺陷，輕微錯誤，95%得到修改并且復測通過

7.2

用戶可以接受未修改的軟件錯誤

7.3

測試超過了預定時間表，由項目經(jīng)理決定是否停止測試

7.4

測試結(jié)論及評價標準

測試結(jié)論

評價標準

拒絕發(fā)布

遺留了一級、二級缺陷

測試通過版本

不能遺留以一、二類缺陷

三類

一般缺陷95%得到修改并且通過復測

四類輕微缺陷85%得到修改并且通過復測

推薦使用版本

不能遺留以一、二類缺陷

三類

一般缺陷95%得到修改并且通過復測

四類輕微缺陷90%得到修改并且通過復測

可以證實發(fā)布版本

不能遺留以一、二類缺陷

三類

一般缺陷97%得到修改并且通過復測

四類輕微缺陷90%得到修改并且通過復測

7.5

輸出

《階段性測試報告》

《性能測試報告》

《測試總結(jié)報告》

《測試問題列表》

其他約束

記錄

序

號

名

稱

編

號

測試計劃

測試方案

問題報告及維護記錄

測試總結(jié)報告

僅供參考