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

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