軟件質(zhì)量保證過程.doc

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