軟件質量保證過程.doc

軟件質量保證過程海恒達遠科技有限公司2005年3月1日1、前言1.1 范圍本文對軟件質量保證活動中涉及到的人員提供指導，使得軟件開發(fā)中不同的角色清楚自己在什么時間做什么事情。1.2 目的本文的目的是描述軟件質量保證的所有活動。文檔中涉及到的角色均以粗體表示，以便各角色更明確自己的工作。本文檔可以幫助我們規(guī)范化公司的軟件質量保證過程。1.3 文檔概述第一部分：描述本文檔的范圍和目的，以及SQA過程涉及到的角色。第二部分：培訓。第三部分：詳細描述質量保證過程的活動。第四部分：附錄。1.4 有關的角色及職責角色職責描述項目設計師組織和進行Quality review開發(fā)人員單元測試，alpha 測試測試負責人制定測試計劃，確保測試過程正常進行測試人員Beta測試，性能測試2、培訓對相關人員進行軟件質量保證過程的培訓，培訓包括兩部分：1、 軟件質量保證過程。2、 過程用到的工具，包括Bugzilla, Junit, Jmeter，Webtest等3、軟件質量保證活動軟件質量保證是為保證產品和服務充分滿足消費者要求的質量而進行的有計劃、有組織的活動。軟件的質量保證活動和一般的質量保證活動一樣，是確保軟件產品從誕生到消亡為止的所有階段的質量的活動，即是為了確定、達到和維護需要的軟件質量而進行的所有有計劃、有系統(tǒng)的管理活動。質量保證是面向消費者的活動，是為了使產品實現用戶要求的功能，站在用戶立場上來掌握產品質量的。這種觀點也適用于軟件的質量保證。軟件質量保證的主要手段是檢驗，檢驗有兩種方式： Quality review，檢查階段產品是否與要求一致，防止軟件差錯到下個過程被放大。一般在各階段的中途或向下一階段移交時進行的檢查。因為這時候還沒有結果產品，所有的檢查都是通過評審的形式實現的。（Verification） 測試，檢驗開發(fā)出來的軟件的特性是否與需求相符，確保所有的軟件功能需求都能得到滿足，所有的軟件性能需求都能達到，所有的文檔都是正確的且便于使用。檢查方式是由測試人員對產品結果進行正式全面的測試。（Validation）另外，為了保證程序源代碼的可維護性，公司有嚴格而合適的編碼規(guī)范以約束程序員的編碼習慣。其中借助工具Checkstyle來檢查java程序的編碼規(guī)范。3.1 Quality review3.1.1 Quality review 概述目的：確保開發(fā)的過程結果的質量。時間：每個主要階段上至少要進行一次Quality Reviews?？梢愿鶕ぷ骱瓦M程的需要安排Quality Reviews。它可以持續(xù)幾天時間。形式：會議形式。由項目主管或設計師來發(fā)起和主持，一般要求項目主管或設計師提前將會議邀請發(fā)給需要參加會議的人。必要時需要將會議的內容大體介紹給大家，以便他們做好準備。參加人：團隊中與本技術有關的所有人員和邀請的項目組之外的其他人員。該類會議一般會邀請有關領域的專家?；顒樱?討論被審核對象的有關問題 深入地審核系統(tǒng)的體系架構和所使用的技術 確認技術過程（Build/Release，源碼控制，等）會議記錄：由設計師或指定他人在當天將會議的內容整理出來并置于配置管理之下。原則： 某階段未通過階段評審不得進入下一個軟件研制階段； 評審時對事不對人，評審的是產品，而不是評審生產者； 評審就要挑刺，找問題、缺陷和隱患； 評審組的人員面越廣越好； 評審組不作無休止的爭論和辯駁，將爭論點記錄下來，供以后甄別； 評審只是提出問題，沒有解決問題的任務； 作用： 技術把關，避免軟件人員的想當然； 概念溝通，吸收用戶和總體人員參加，審查軟件人員理解的正確性； 集思廣益，吸收有關的分系統(tǒng)人員參加，從不同側面確認軟件的協(xié)調性； 總結匯報，使實時控制系統(tǒng)總指揮。設計師了解軟件的進度、問題和要求，作出新的部署。 3.1.2 Checklist為了確保Quality review的質量，需要列出軟件開發(fā)不同階段上的Review內容。利用這個Checklist，設計師根據項目的具體內容安排合適的Quality review。公司給出了一個可參考的checklist，可以用來指導Quality review，也可以用來跟蹤Quality review的執(zhí)行。3.1.3 通過準則軟件質量保證工作是開發(fā)團隊整體的工作，只有每個人都將自己角色所涉及的工作質量把握好，才能保證項目整體的質量。這里將針對開發(fā)過程給出每個階段的退出標準。即，只有達到了某個要求才可進入下個階段。項目主管和設計師以此來推進項目的進度。發(fā)現定義設計概念實現Working/ShareIntegration Alpha testBeta testDeploy審核通過審核通過審核通過審核通過單元測試通過，Code review通過集成成功，記錄日志Alpha測試結果審核通過成功發(fā)布，記錄日志Beta測試結果審核通過2.1.4 Review notes為了更有效地開展Quality review工作，公司給出了一個可參考的review notes。利用這個表格，設計師可以更好地把握會議的重點。3.2 測試在分析、設計等各個開發(fā)階段結束之前，對軟件進行了嚴格的Quality review，但由于人們能力的局限性，審查不能發(fā)現所有的錯誤，而且在編碼階段還會引進大量的錯誤。軟件測試就是在軟件投入運行之前，對需求分析、設計規(guī)格說明書和編碼的最終復審，是軟件質量保證的關鍵步驟，是為了發(fā)現錯誤而執(zhí)行程序的過程。測試不僅僅是運行程序，然后將發(fā)現的問題記錄下來的過程。他的真正目的是想以最少的時間和人力找出軟件中潛在的各種錯誤和缺陷。軟件測試在軟件生存期中橫跨兩個階段：通常在編寫出一個模塊之后就對它做必要的測試（稱為單元測試），編碼和單元測試屬于軟件生存期中的同一個階段。在結束這個階段之后，對軟件系統(tǒng)還要進行各種綜合測試，這是軟件生存期中的另一個獨立的階段，即測試階段。它主要包括功能測試、性能測試、用戶接受性測試。從測試方法上來講，單元測試屬于白盒測試；測試階段的測試屬于黑盒測試。對功能測試，又分為alpha測試階段和beta測試階段。Alpha測試由開發(fā)人員來做，Beta測試由專門的測試人員來做。測試階段的測試，是在模擬的環(huán)境（可能就是開發(fā)環(huán)境）下，運用黑盒測試的方法，驗證所測軟件是否滿足需求規(guī)格說明書列出的需求。由測試負責人負責制定測試計劃，確保測試過程正常進行。3.2.1 單元測試定義單元測試集中檢驗軟件設計的最小單元-模塊。測試之前必須先通過編譯程序檢查并改正所有語法錯誤，然后用詳細設計描述做指南，對重要的執(zhí)行通路進行測試，以便發(fā)現模塊內部的錯誤。單元測試要求開發(fā)人員來編寫測試用例并執(zhí)行測試。測試內容針對一個模塊進行五方面的檢查：模塊模塊接口錯誤處理邊界路徑局部數據結構 模塊接口測試。這方面的錯誤如，調用所測模塊時的輸入參數與模塊的形式參數在個數、屬性、順序上是否匹配；輸出給標準函數的參數在個數、屬性、順序上是否正確；全局變量的定義在個模塊中是否一致，等。 局部數據結構測試。這方面的錯誤如，不正確或不一致的數據類型說明；使用尚未初始化的變量；錯誤的初始值或錯誤的缺省值；變量名拼寫錯或書寫錯，等。 路徑測試。這方面的錯誤如，不正確的邏輯運算符；關系表達式中不正確的變量和比較符；錯誤的或不可能的循環(huán)終止條件，等。 錯誤處理測試。這方面的錯誤如，出錯的描述難以理解；出錯的描述不足以對錯誤定位，不足以確定錯誤的原因；顯示的錯誤與實際的錯誤不符，等。 邊界測試。數據流、控制流中剛好等于、大于或小于確定的比較值時出現的錯誤。測試方法通常有兩種測試方法： 單元靜態(tài)檢查，不要求實際執(zhí)行所測程序，而是以一些人工的模擬技術和一些類似動態(tài)分析所使用的方法對程序進行分析和測試。 單元動態(tài)測試 ，通過執(zhí)行程序來測試有沒有問題。測試工具使用Junit工具來幫助實施單元測試，也包括Junit工具的擴展Cactus等。322 集成測試定義集成測試是為了確保測試用例能夠正常運行而由開發(fā)人員來執(zhí)行的測試測試內容測試軟件或系統(tǒng)的全部流程、用例是否可以正常運行。測試方法首先需要制定測試計劃，規(guī)定要做測試的范圍，要求，方法等。還需要制定一組測試步驟，描述具體的測試用例，用例應該可以遍歷到全部的流程。3.2.3功能測試定義為了保證軟件能滿足功能要求而做的測試。功能測試是由專門的測試人員對系統(tǒng)進行的有組織的詳細全面的測試。測試內容軟件的所有功能。針對公司Java開發(fā)Web測試的特點，需要額外注意以下幾方面的測試： 操作系統(tǒng)+ 瀏覽器兼容性測試：在不同操作系統(tǒng) (win,mac,unix)和不同版本的瀏覽器（IE4.0,IE5.0,IE5.5,NN6,NN4.5）組合情況下web應用能否正確執(zhí)行； 可用性測試：主要從使用的合理性和方便性等角度對軟件進行檢查，是專為“對用戶友好”的特性進行測試； 超鏈接檢查：檢查是否頁面上所有的連接都正確鏈接，是否存在broken links； 圖形顯示檢查：檢查是否所有的圖片都被正確裝載，在不同的瀏覽器、分辨率下圖片能否正確顯示（包括位置、大?。?； 分辨率檢查：在不同分辨率設置情況下，窗口的滾動條能夠正確滾動，屏幕刷新是否正確； 調整窗口檢查：在調整瀏覽器窗口大小時，屏幕刷新是否正確； 外部網絡訪問檢查：從外部網絡撥號訪問web應用以驗證連接、功能和性能；測試方法首先需要制定測試計劃，規(guī)定要做測試的范圍，要求，方法等。還需要制定一組測試步驟，描述具體的測試用例，旨在說明軟件與需求是否一致。測試方案測試方案包括預定要測試的功能，應該輸入的測試數據和預期的結果。設計測試方案的目標是，確定一組最可能發(fā)現某個錯誤或某類錯誤的測試數據。幾種主要的黑盒測試的設計技術有： 等價類劃分。將所有可能的輸入數據，即程序的輸入域劃分為若干部分，然后從每一部分中選取少數。不光考慮輸入等價類，有時還需要考慮輸出等價類。 邊界值分析。對等價類劃分的補充，不是從等價類中隨便選一個數據作為代表，而是選幾個特定值，如等于、剛剛大于、剛剛小于邊界值。 其他方法。回歸測試當軟件經過測試發(fā)現錯誤，程序員對一個錯誤的修改可能會引起另外的錯誤出現，所以，在修改之后還要進行測試，這種測試就叫回歸測試。在整個產品提交之前要進行正式的回歸測試，有必要給出回歸測試的要求： 每次測試需要將所有的功能都走一遍； 對不同狀態(tài)的bugs要求check一遍，重新定他們的狀態(tài)，特別關注狀態(tài)改變的bugs。 check Bugs時，注意走一下與此Bug 有關聯(lián)的功能，以及與此Bug相類似的功能。為了更快更有效地進行回歸測試，借助自動測試工具Webtest來完成部分的回歸測試工作。3.2.4性能測試定義為了保證軟件能滿足性能要求而做的測試。本部分測試由專門的測試人員來設計和執(zhí)行測試內容本著公司Web testing的特點，只提出下面三方面的測試： 安全測試：安全性測試是要檢驗在系統(tǒng)中已經存在的系統(tǒng)安全性、保密性措施是否發(fā)揮作用，有無漏洞。 負載測試：通過模擬大批量用戶的并發(fā)請求，給系統(tǒng)施加較大的負載，這時檢測整個系統(tǒng)處理交易的能力。 壓力測試：在反常數量或資源（使用的容量達到規(guī)定的極限）的情況下執(zhí)行應用程序，檢測中間件系統(tǒng)在長時間、高負載情況下的運行處理能力，從而檢驗系統(tǒng)的穩(wěn)定性。測試方法設計測試用例，模擬錯誤數據和軟件界面可能發(fā)生的錯誤，測試各項性能是否達到預期的指標。測試工具使用Jmeter等工具來幫助測試系統(tǒng)的負載。3.2.5 用戶接受性測試（UAT）定義驗收測試的目的是向未來的用戶表明系統(tǒng)能夠象預定要求那樣工作。要求必須有用戶積極參與，或者以用戶為主進行，測試人員來協(xié)助。測試內容主要對功能要求、性能要求、和文檔的完整性進行檢查。這里強調下面幾點：1、 主要使用生產中的實際數據進行測試2、 對用戶特別感興趣的功能，需要增加一些測試3、 需要按照用戶的使用步驟設計一些用例4、 可能會忽略一些純技術性的特性測試方法一般使用黑盒測試方法。3.2.6 Bug管理管理內容Bug管理解決下面幾個問題：1、 開發(fā)人員按照Bug的等級優(yōu)先修復嚴重的問題2、 開發(fā)人員和測試人員之間的協(xié)作溝通方便有效3、 測試人員的Bug錄入要方便有效4、 開發(fā)人員定位自己的Bug5、 Bug的跟蹤6、 Bug的查詢方便有效7、 方便準確地進行Bug統(tǒng)計Bug等級（Severity）This field describes the impact of a bug. Blocker - Blocks development and/or testing work. Critical - Crashes, loss of data, severe memory leak. Major - Major loss of function. Normal - This is the run of the mill bug. Minor - Minor loss of function, or other problem where an easy workaround is present. Trivial - Cosmetic problem like misspelled words or misaligned text. Enhancement - Request for enhancement.Bug管理工具借助Bugzilla來管理Bug。Bugzilla是一個Bug跟