1、資料內(nèi)容僅供您學(xué)習參考，如有不當或者侵權(quán)，請聯(lián)系改正或者刪除。軟件測試標準規(guī)范目的為了確保軟件產(chǎn)品質(zhì)量, 使產(chǎn)品能夠順利交付和經(jīng)過驗收, 特編寫本文檔, 以作參考適用范圍本文檔適用于項目開發(fā)過程中的單元測試、 集成測試、 系統(tǒng)測試、 業(yè)務(wù)測試、 驗收測試以及一些專項測試。職責項目測試負責人組織編制測試計劃、 測試方案, 指導(dǎo)和督促測試人員完成各階段的測試工作。項目組測試人員按照測試計劃、 測試方案完成所承擔的測試任務(wù), 并按要求填寫問題報告及維護記錄。測試經(jīng)理依照確認規(guī)程和準則對工作產(chǎn)品進行確認, 提出對確認規(guī)程和準則的修改意見項目負責人組織測試環(huán)境的建立。項目經(jīng)理審核負責控制整個項目的時間和

2、質(zhì)量。研發(fā)人員確認修改測試人員提交的bug。工作流程測試依據(jù)詳細設(shè)計是模塊測試的依據(jù)。因此設(shè)計人員應(yīng)向測試人員提供系統(tǒng)需求規(guī)格書名書、 詳細設(shè)計、 概要設(shè)計等有關(guān)資料。測試人員必須認真閱讀, 真正弄懂系統(tǒng)需求和詳細設(shè)計。制訂測試方案在測試之前, 由項目負責人根據(jù)測試計劃的要求, 組織人員編制相應(yīng)的測試方案, 測試方案應(yīng)包括以下內(nèi)容: 測試目的; 所需人員及相應(yīng)培訓(xùn)要求; 測試環(huán)境、 工具和測試軟件; 測試用例、 測試數(shù)據(jù)和預(yù)期的結(jié)果。單元測試項目開發(fā)實現(xiàn)過程中, 每個程序單元( 程序單元的劃分視具體開發(fā)工具而定, 一般定為函數(shù)或子程序級) 編碼調(diào)試經(jīng)過后, 要及時進行單元測試。單元測試由單元開

3、發(fā)者自己進行, 使用白盒測試方法, 根據(jù)程序單元的控制流程, 爭取達到分支覆蓋。對于交互式運行的產(chǎn)品, 不便于進行自動測試的, 能夠采用功能測試的方法進行。單元測試針對程序模塊, 從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊能夠獨立進行單元測試。單元測試內(nèi)容包括模塊接口測試、 局部數(shù)據(jù)結(jié)構(gòu)測試、 路徑測試、 錯誤處理測試等; 單元測試組織原則一遍根據(jù)開發(fā)進度安排對已開發(fā)完成的單一模塊進行測試; 單元測試停止標準: 完成了所有規(guī)定單元的測試, 單元測試中發(fā)現(xiàn)的bug已經(jīng)得到修改。集成測試 編碼開發(fā)完成, 項目組內(nèi)部應(yīng)進行組裝測試。集成測試由項目負責人組織策劃( 編寫測試計劃、 測試用例) 并實施。

4、集成測試著重對各功能模塊之間的接口進行測試, 驗證各功能模塊是否能協(xié)調(diào)工作、 參數(shù)傳遞及功能調(diào)用是否正常。測試采用交叉方法, 即個人開發(fā)的軟件應(yīng)由其它的項目組成員進行測試。集成測試過程應(yīng)填寫問題報告及維護記錄, 測試結(jié)果應(yīng)形成測試報告。系統(tǒng)測試在項目開發(fā)完成之后, 應(yīng)對整個系統(tǒng)軟件和硬件進行系統(tǒng)測試。對性能、 可靠性、 健壯性、 壓力承受力等方面分別進行評價, 以驗證系統(tǒng)是否滿足規(guī)定的需要。系統(tǒng)測試由測試負責人組織策劃( 編寫測試計劃、 測試用例) 并實施, 系統(tǒng)測試過程應(yīng)形成問題報告及維護記錄。系統(tǒng)測試一般進行如下幾種情況的測試: 正常情況非正常情況破壞性測試邊界情況非法情況強度測試性能測試

5、兼容性測試用戶友好性測試界面設(shè)計規(guī)范測試: 光標的初始位置字體是否統(tǒng)一字號是否符合規(guī)定標題顏色按鈕的名稱是否規(guī)范界面布局是否合理, 整體效果如何輸入值測試: 數(shù)據(jù)類型數(shù)據(jù)長度約束條件是否滿足, 是否完整TAB和Enter鍵是否起作用鍵盤操作能否全部代替鼠標操作輸入( 光標) 是否按照順序前進按鈕測試: 將按鈕放開和封閉是否嚴格、 準確, 不能使用的按鈕必須封閉檢查”退出”、 ”取消”等具有共性按鈕的功能異常情況測試: 在完成正常功能測試后, 安正常處理的相同操作順序, 執(zhí)行與正常處理不同的動作例如正常處理中要求輸入日期的字段, 這時輸入字符或數(shù)字正常處理中輸入字段有范圍要求, 這時輸入超過范圍

6、的值正常處理中用兩個值限定范圍, 這時用一個值或不限定正常處理中要求用”Tab”鍵, 這時安”Enter”鍵或其它鍵正常處理中單選框、 多選框、 下拉框等, 十一偶那個非指定鍵操作使用不同于指定的按鈕操作業(yè)務(wù)測試在組裝測試與系統(tǒng)測試結(jié)束后, 均可由最終用戶或測試人員對系統(tǒng)進行測試。業(yè)務(wù)測試著重測試業(yè)務(wù)流程, 功能、 用戶界面等方面。項目、 測試負責人負責組織相關(guān)人員制定測試方案和測試用例, 并進行測試。測試的結(jié)果應(yīng)形成問題報告及維護記錄。驗收測試驗收測試的條件按照項目計劃規(guī)定的驗收測試進度安排進行測試準備在驗收測試前, 各項內(nèi)部的測試活動都受到監(jiān)控并爭取執(zhí)行交付版本的要求按照集成測試用例完成了

7、整個系統(tǒng)的集成測試集成版本滿足設(shè)計定義的各項功能、 性能要求提交的數(shù)據(jù)庫腳本樣本需要完整, 沒有冗余數(shù)據(jù)在集成測試中發(fā)現(xiàn)的bug已經(jīng)得到解決, 各級缺陷修改率達到標準軟件需求分析說明書中定義的所有功能都已經(jīng)實現(xiàn), 性能指標全部達到性能需求指標提交階段性測試報告, 包括功能和性能測試報告所有文檔齊備完整版本發(fā)布的準則軟件產(chǎn)品經(jīng)過了單元測試、 集成測試、 業(yè)務(wù)測試、 系統(tǒng)測試、 性能測試測試部提交文檔: 測試計劃、 測試方案、 測試用例、 測試分析報告所有測試項必須符合以下標準致命錯誤: 無功能錯誤: 無功能缺陷: 項目經(jīng)理、 技術(shù)經(jīng)理、 測試負責人審核經(jīng)過界面缺陷: 項目經(jīng)理、 技術(shù)經(jīng)理、 測試

8、負責人審核經(jīng)過建議: 項目經(jīng)理、 技術(shù)經(jīng)理、 測試負責人審核經(jīng)過以上幾項其中之一不滿足要求, 視為不合格在產(chǎn)品交付和用戶驗收之前, 經(jīng)過驗收測試來確認在規(guī)定的使用環(huán)境下整個產(chǎn)品的運行情況是否滿足規(guī)定的要求。在產(chǎn)品交付之前, 由指定的驗收負責人組織制定測試方案和測試用例, 主持驗收。驗收測試過程應(yīng)形成問題報告及維護記錄。用戶現(xiàn)場測試將軟件部署到用戶實際生產(chǎn)環(huán)境后, 由于環(huán)境差異, 需要在用戶現(xiàn)場進行確認測試, 保證系統(tǒng)功能、 性能完備, 可正常運行。測試內(nèi)容: 根據(jù)軟件系統(tǒng)規(guī)模, 準備現(xiàn)場測試用例, 涵蓋所有重要功能點, 若規(guī)模小, 需要將全部功能點全部測試一遍對于后臺已定義好的工作流、 功能欄

9、目路徑以及用戶信息等數(shù)據(jù), 不可進行修改和刪除操作, 新增的測試數(shù)據(jù)也需要在測試完成后給予清楚重點檢查上傳、 下載的數(shù)據(jù)是否能夠正常的打開或保存確認界面美觀, 基本信息和鏈接無錯誤考慮用戶實際的軟件環(huán)境和網(wǎng)絡(luò)環(huán)境, 以客戶端最為復(fù)雜的軟硬件環(huán)境作為測試機器, 檢查有無異常情況出現(xiàn)針對前期發(fā)現(xiàn)的bug進行回歸測試, 以保證發(fā)布版本為最新版本編寫測試文檔測試點將測試模塊分解成多個功能點, 測試點應(yīng)涵蓋功能點, 也涵蓋了正常測試和異常測試。輸入數(shù)據(jù) 輸入數(shù)據(jù)包括界面輸入數(shù)據(jù)、 數(shù)據(jù)庫的初始數(shù)據(jù)及其它外部輸入數(shù)據(jù)。特別是數(shù)據(jù)庫的初始所需屬性一一列出, 全面是指: 數(shù)據(jù)能達到模塊所涉及的全部功能, 典型

10、是指這個數(shù)據(jù)能充分反映功能特點。測試描述 描述測試步驟, 包括: 操作員所執(zhí)行的動作( 包括鼠標、 鍵盤、 加載外部數(shù)據(jù)等操作) ; 系統(tǒng)的反應(yīng), 包括: 光標定位、 光標聚焦、 顯示字段值、 按鈕的封閉和放開、 功能鍵的封閉和放開、 系統(tǒng)提示和系統(tǒng)消息等。預(yù)期輸出數(shù)據(jù) 按準備的輸入數(shù)據(jù)和設(shè)計要求的處理過程, 模塊應(yīng)輸出的數(shù)據(jù)。 輸出數(shù)據(jù)包括: 屏幕輸出數(shù)據(jù)、 輸出到數(shù)據(jù)庫的數(shù)據(jù)、 輸出到其它外部介質(zhì)上的數(shù)據(jù), 并指出斷點結(jié)果或最終結(jié)果。實際輸出 填寫本測試點程序運行后的實際輸出。正確與否 程序運行后, 實際輸出結(jié)果和預(yù)期輸出結(jié)果一致時, 為正常, 否則為不正常。測試結(jié)論 填寫本次測試的結(jié)論,

11、 是合格或不合格。若不合格時, 應(yīng)總結(jié)存在的問題, 能夠讓修改者一目了然。缺陷管理缺陷的定義及其基本屬性缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題, 這些問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質(zhì)量。缺陷應(yīng)該具備以下屬性, 也就是往缺陷管理庫或者缺陷列表中提交的缺陷應(yīng)該具備以下屬性: 屬性名稱描述缺陷標識標記某個缺陷的一組符號, 每個缺陷必須有一個唯一的標識缺陷類型根據(jù)缺陷的自然屬性劃分的缺陷種類缺陷驗證程度因缺陷引起的故障對軟件產(chǎn)品的影響程度缺陷所處的模塊或子系統(tǒng)缺陷分步的模塊或子系統(tǒng)缺陷出現(xiàn)幾率指發(fā)現(xiàn)錯誤的幾率缺陷的重現(xiàn)步驟詳細的缺陷重現(xiàn)步驟附件與缺陷相關(guān)的附件( 截圖、 附件、

12、用例等) 備注對缺陷的其它描述缺陷分類根據(jù)缺陷的定義, 將缺陷分為如下列: 文檔缺陷: 是指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、 產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定, 被評審的對象包括最終出產(chǎn)物和中間過程產(chǎn)出物, 比如需求文檔、 設(shè)計文檔、 計劃、 報告、 用例等代碼缺陷: 是指對代碼進行同行評審、 審計或代碼走查過程中發(fā)現(xiàn)的缺陷測試缺陷: 是指由測試活動發(fā)現(xiàn)的測試對象( 被測對象一般是指可運行的代碼、 系統(tǒng), 不包括靜態(tài)測試發(fā)現(xiàn)的問題) 的缺陷, 測試活動包括單元測試、 集成測試、 系統(tǒng)測試、 性能測試等過程缺陷: 有稱為不符合項問題, 是指經(jīng)過過程審計、

13、 過程分析、 管理評審、 質(zhì)量評估、 質(zhì)量審核等活動發(fā)現(xiàn)的關(guān)于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試人員、 項目經(jīng)理等文檔缺陷分類 缺陷分類描述描述不完整文檔內(nèi)容缺失, 或文檔應(yīng)該包括的范圍沒有涵蓋不一致一致性問題有兩類: 一是與源頭說明書不一致, 比如需求和客戶業(yè)務(wù)需求不一致、 設(shè)計與需求不一致等二是上下文或者與前提不一致描述錯誤文檔描述是錯誤的, 不可實現(xiàn)或?qū)е洛e誤的輸出或結(jié)果功能問題該缺陷將會導(dǎo)致用戶功能的錯誤、 不滿足、 不可用不清楚或有歧義內(nèi)容的描述不清楚、 不能準確表示、 或表示的意思有歧義邏輯錯誤內(nèi)容組織邏輯不清楚、 邏輯錯誤接口問題與最終用戶接口問題、 與外部系統(tǒng)的接口問

14、題、 內(nèi)部子系統(tǒng)或模塊的接口問題輸入輸出問題輸入輸出不完整、 不正確、 不可測試或驗證不細化內(nèi)容還需要進一步細化性能問題文檔的設(shè)計或?qū)崿F(xiàn)方式存在性能問題安全性問題文檔的設(shè)計或?qū)崿F(xiàn)方式存在安全性問題代碼缺陷分類缺陷分類描述常量變量定義問題不滿足設(shè)計或需求編寫代碼不符合規(guī)范條件判斷處理循環(huán)處理錯誤異常處理算法邏輯問題注釋問題代碼冗余性能問題系統(tǒng)測試缺陷分類缺陷類型描述功能錯誤影響了重要的特性、 用戶界面、 產(chǎn)品接口或全局數(shù)據(jù)結(jié)構(gòu), 而且設(shè)計文檔需要爭取的變更。如邏輯、 循環(huán)、 遞歸、 功能等缺陷結(jié)構(gòu)錯誤Web應(yīng)用程序結(jié)構(gòu)化頁面無法顯示, 或者顯示錯誤腳本錯誤Web應(yīng)用程序當中出現(xiàn)腳本錯誤, 包括客

15、戶端對數(shù)據(jù)進行校驗和運算的各種情況下產(chǎn)生的錯誤頁面鏈接錯誤Web應(yīng)用程序頁面出現(xiàn)空鏈接、 錯誤鏈接、 死鏈接頁面文字錯誤Web應(yīng)用程序頁面出現(xiàn)的中外文拼寫、 使用、 以及不同語種頁面的編碼錯誤頁面圖形錯誤Web應(yīng)用程序頁面出現(xiàn)圖片內(nèi)容使用不當, 或者無法顯示ALT錯誤Web應(yīng)用程序頁面當中超文本標識語言、 文本標簽解釋錯誤排版錯誤Web應(yīng)用程序頁面排版不符合要求或者不符合使用習慣業(yè)務(wù)邏輯不合理應(yīng)用程序的實現(xiàn)流程和規(guī)定業(yè)務(wù)流程不一致, 或者實現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的部分并行、 爭用、 同步等操作, 引起的流程斷裂、 死鎖、 以及其它異常情況業(yè)務(wù)邏輯不方便應(yīng)用程序?qū)崿F(xiàn)流程在實際情況下雖然

16、能夠完成, 可是存在不必要的重復(fù)、 等待、 冗余等影響使用效率的情況其它錯誤其它未分類錯誤建議系統(tǒng)改進建議缺陷等級定義缺陷的嚴重程度對以上所述的缺陷類型都是適合的, 缺陷的嚴重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。缺陷等級缺陷性質(zhì)系統(tǒng)中對應(yīng)的錯誤分類描述一級致命錯誤系統(tǒng)崩潰系統(tǒng)死鎖導(dǎo)致對被描述的主要對象的理解錯誤、 不可行、 不可運轉(zhuǎn)、 對業(yè)務(wù)和整個系統(tǒng)造成重大損失或損害; 對使用、 維護或保管人員有危險或不安全, 以及對產(chǎn)品的基本功能有致命影響的缺陷二級嚴重缺陷嚴重錯誤對被描述的部分對象的理解或?qū)崿F(xiàn)錯誤, 部分的模塊或系統(tǒng)不可行或不能運轉(zhuǎn)或部分模塊和系統(tǒng)缺失, 對整個系統(tǒng)

17、有重大影響或可能造成部分的損失或損害; 嚴重影響使用安全三級一般缺陷次要錯誤布局不合理文字錯誤系統(tǒng)中部分單元模塊或單個功能描述和實現(xiàn)有錯誤、 有偏差、 不一致或有缺失, 不影響模塊的正常運行, 或有影響, 但能夠有替代的辦法或避免辦法四級微小缺陷微不足道基本不影響系統(tǒng)的運行和功能的實現(xiàn)。可是與標準、 規(guī)范和定義不一致五級建議缺陷新特性不在定義、 標準、 范圍的定義和約束之內(nèi), 可是從提出者來看是需要完善的建議缺陷優(yōu)先級定義缺陷優(yōu)先級描述特急需要馬上進行修改加急一天到兩天之內(nèi)必須修改高介于中和加急之間中缺陷需要正常排隊等待修復(fù)或列入軟件發(fā)布清單低留到組后解決, 如果項目的進度跟緊張能夠在產(chǎn)品發(fā)布

18、以前不解決缺陷狀態(tài)定義缺陷狀態(tài)描述初始狀態(tài)( New) 測試或開發(fā)人員提交一個新的缺陷, 等待開發(fā)人員或項目經(jīng)理分配修改負責人打回( FeedBack) 要求缺陷的報告者再次對缺陷進行說明已分配( Assigned) 是指已經(jīng)分配給屬主, 等待修改。已解決( Resolved) 缺陷被屬主修改, 等待測試人員驗證關(guān)閉( Closed) 測試人員驗證缺陷已經(jīng)修復(fù)重新打開( Reopen) 測試人員驗證, 缺陷沒有修改正確遺留( Later) 經(jīng)項目經(jīng)理和技術(shù)經(jīng)理驗證此缺陷在本版本中不用修改缺陷完成度缺陷完成度描述打開( Open) 缺陷沒有被解決已解決( Fixed) 缺陷已經(jīng)修改遺留( Sus

19、pended) 此缺陷步驟本階段解決重新打開( Reopen) 重新打開某個缺陷不做修改( Wont fix) 不對這個缺陷進行修改重復(fù)( Duplicate) 與某個缺陷重復(fù)需求如此經(jīng)理和開發(fā)人員經(jīng)過需求和設(shè)計的核實后決定不需要修改不可重現(xiàn)被指派的開發(fā)人員想要再現(xiàn)缺陷進行修改個時候, 發(fā)現(xiàn)缺陷始終不能再現(xiàn)缺陷管理流程處理機制退回機制若在測試過程中發(fā)生如下情況, 將系統(tǒng)退回到申請部門: 經(jīng)過測試后, 發(fā)現(xiàn)與需求說明規(guī)格說明書中定義的功能項存在較大的差異單一模塊, 測試過程中發(fā)現(xiàn)缺陷輸了較多或者無法繼續(xù)進行系統(tǒng)其它功能模塊的測試, 繼續(xù)測試無意義測試過程中, 頻繁死機或系統(tǒng)崩潰主業(yè)務(wù)流程出現(xiàn)斷點異常情況