【導讀】軟件開發(fā)由于是人為的設(shè)計和開發(fā)過程,發(fā)乍缺陷很難避免,傳統(tǒng)軟件工程做法足通過軟件測試,控制軟件存在的缺陷。在本文中我們討論通過實施有效的評審和檢查以及軟件測試活動,控制軟件交付后,存在較少缺陷。1 引言  每個產(chǎn)品都會有缺陷,在軟件開發(fā)過程中應爭取盡早發(fā)現(xiàn)缺陷,開發(fā)的時候提高軟件質(zhì)量要遠比開發(fā)完成 后再進行測試更為有效。一般對軟件開發(fā)主要控制缺陷手段是進行測試和檢查,在一定程度上可以確保不讓不 合格產(chǎn)品交付到用戶手里,然而能夠保證最初制造的產(chǎn)品就是一個合格產(chǎn)品嗎能將質(zhì)量測試融入產(chǎn)品中去 嗎實現(xiàn)起來比較困難,而且只能在開發(fā)的結(jié)束才能進行測試。其實這不僅是改進軟件流程所獨有的現(xiàn)象,也 是目前軟件開發(fā)共同面臨的問題。要想得到高質(zhì)量軟件, 重要的是將質(zhì)量設(shè)計到軟件中。這比如何設(shè)置質(zhì)量保證 部門、向誰報告、獨立測試、需要進行什么樣的評審等事情重要得多。要想在軟件開發(fā)的每個階段都注重質(zhì)量需要有一個流程進行管理,大多數(shù)軟件流程改進模型(像CMM和ISO9000)都認為有效和正確的流程必然會導致生產(chǎn)出高質(zhì)量軟件。我們有理由相信有效的流程肯定能制作出一開始就能正常工作的高質(zhì)量軟件。下面先介紹缺陷管理的基本原理,然后討論軟件在產(chǎn)品開發(fā)周期中的驗證和確認,特別是所采用的評審、檢查和測試技術(shù)。2 缺陷管理  軟件中一般會有問題和缺陷,其實這都是一些由開發(fā)人員造成的軟件錯誤,這些缺陷實際上在開發(fā)過程從 提出要求到進行維護的任一階段都可能造成。假如適當條件永遠不發(fā)生而沒有觸發(fā)執(zhí)行有問題代碼的話,缺陷 就將隱藏下去,否則它們會暴露出來而造成失效。失效的嚴重程度不盡相同,最壞情況下失效可使系統(tǒng)崩潰或 者系統(tǒng)功能不正常,而輕微時失效僅僅使用戶感到不方便或不滿意而已(如響應時間太慢或者接口使用困難等)?! ‘斎贿€是應該盡量避免缺陷,關(guān)于缺陷管理有兩個指導性原則。首先,在最初階段就要避免造成缺陷,可 以通過在產(chǎn)品開發(fā)周期每個步驟都使用正確技術(shù)做到這一點。第二個原則就是在流程中盡可能早地檢測出缺陷,一旦檢測到就要從源頭處把它消除掉。這就是說如果缺陷是在低層設(shè)計中造成的,就應在此時把它消 除,最好在編碼開始前。  時間拖得越久,消除和修復缺陷的費用就越高。研究指出,缺陷在產(chǎn)品開發(fā)周期晚期發(fā)現(xiàn)其消除的費用將 會急劇上升。為避免缺陷,需要針對軟件開發(fā)每一階段的特殊技術(shù)進行培訓。  通過評審檢查的驗證和確認活動,是缺陷形成后盡早檢測出來并從源頭處把它消滅掉,這樣做不僅去除缺 陷的費用更少,而且使我們相信質(zhì)量已被制造在產(chǎn)品中,而不是直到裝運前才將高質(zhì)量產(chǎn)品篩選出來。通過評審就是在每一階段對軟件進行評估,以保證它符合前一階 段所提出的要求,同時,通過在開發(fā)工作完成時對軟件及其技術(shù)指標規(guī)范進行測試,以保證軟件符合總體要求。3 評審和檢查  有人說技術(shù)工作需要進行評審就如同鉛筆需要橡皮擦一樣,因為人總是要犯錯誤的。在開發(fā)過程的各個階段進行評審,如果軟件開發(fā)時沒有定出精確要求,則根本不可能通過評審或其它方法驗證設(shè)計是否準確,因為此時設(shè)計不是根據(jù)要求做出而是孤立的,任何對缺陷的判定最終都是個人觀點。因此評審和檢查首先假設(shè)軟件開發(fā)過程已有嚴格的要求。評審每個開發(fā)階段的中間產(chǎn)品有兩個基本作用。首先,我們能在早期檢查出缺陷并在修改費用較低時將其消除掉;其次,這一點可能更重要,我們能夠在公司內(nèi)部改變流程,在軟件開發(fā)最初階段就提出大量的嚴格要求。如果管理層在評審上投機取巧,則到時候可以清楚地看到?jīng)]有好的要求(或者好的設(shè)計)評審就不會帶來什么價值?! ≡u審可作為質(zhì)量過濾的一種形式用于軟件開發(fā)各階段,其目的是盡早發(fā)現(xiàn)錯誤以使產(chǎn)品更加完善。評審 結(jié)果是:指出產(chǎn)品中需要改進之處;確認好的部分,使產(chǎn)品在編碼方式、文件樣式、設(shè)計方法等方面更加一致,以便技術(shù)工作能更好地進行管理;改進軟件開發(fā)過程。  進行評審,確保四方面的特性。完整性,下一階段 產(chǎn)品與其前期設(shè)計的產(chǎn)品是完備的整體,沒有待定項、 遺漏功能。一致性,符合產(chǎn)品的要求??尚行?,產(chǎn)品能 完成。易測性,產(chǎn)品做指定測試的能力,該測試必須是 具體的、明確的和可以量化的。  評審會議的組織,人員應限于3~7人,會議中,明確分工,經(jīng)過培訓。為使會議有效,事前做準備,時間一般不超過兩個小時;評審的是產(chǎn)品而不是它的設(shè)計者,要客觀地討論產(chǎn)品而不涉及與之相關(guān)的人要限制爭論和辯解。搞清問題所在但不要試圖去解決任何事情會議的焦點 是發(fā)現(xiàn)而不是解決,正式評審中小組的目的不是進行共同設(shè)計。會議應沿著發(fā)現(xiàn)問題的思路進行,指定記錄員?! ≡u審檢查是很經(jīng)濟的,通過檢查能在修復費用相對較低的早期階段發(fā)現(xiàn)缺陷。此外當要求作必要的修改 時,對多層次設(shè)計文件、產(chǎn)品代碼及產(chǎn)品文件進行改動會出現(xiàn)脈動效應,而檢查能防止這類效應,評審的另一 個關(guān)鍵是它設(shè)計為檢測缺陷而不是檢測失效。最后,因 為每一個中間產(chǎn)品必須要能追溯至前一級中間產(chǎn)品,所以評審必然會改善整個流程,而要求的準備和設(shè)計工作都做得很差的小組幾乎就拿不出合適的東西進行評審。4 軟件測試  雖然正式評審和檢查占用了我們大量的精力,測試 仍然是缺陷控制和檢查中很有用且很重要的一個部分。 測試時我們在受控狀態(tài)下運行軟件以檢測缺陷,如同我們在提要求、設(shè)計和編碼等各階段進行評審和檢查一樣,我們在軟件制作的任何適當?shù)牡胤竭M行測試。下面將簡單介紹單元測試、集成測試,系統(tǒng)測試和回歸測試。  4.1單元測試  單元測試的任務是在一個受控環(huán)境中執(zhí)行—個特定模塊。它—般包括某種形式的構(gòu)架,通常為短線程和驅(qū)動器。 —般用來驗證模塊的功能屬性,但也可以測試其它項目,如性能、可用性等等,可使用“黑盒”或“白盒”方法進行?! ?b>4.2集成測試  當各模塊已經(jīng)過單獨的單元測試后,我們就將它們組合到一起,看與其它模塊集成在一起時的整體功能。模塊可按多種途徑集成,包括從上向下和從下向上。實際上任何方法都可以使用,只要測試人員能了解特定模塊組合所 表示的行為,組合從最前面兩個模塊開始,到加入最后一個 模塊結(jié)束,形成一個完整的系統(tǒng)。理想狀況下,集成測試應 每加入一個模塊進行一次。集成測試—般也看作驗證的一 種形式,因為組合模塊的行為是一個功能規(guī)范的產(chǎn)品。4.3系統(tǒng)測試  系統(tǒng)測試是指對整個系統(tǒng)或產(chǎn)品進行測試,看它是否符合總體系統(tǒng)要求。系統(tǒng)測試人員相當于用戶代言 人,因為測試指導文件應該或者是用戶提出的需求,或者是直接基于這一要求的技術(shù)規(guī)范。系統(tǒng)測試能發(fā)現(xiàn) 任何質(zhì)量問題,包括功能、性能、可靠性和可用性,還有特定項目的其他方面要求?! ?b>4.4回歸測試  回歸測試就是漏洞修復完成后再對軟件進行測試, 以確保軟件沒有產(chǎn)生“回歸”或因修復而變得更糟,這 種測試一般要重新運行最初發(fā)現(xiàn)問題的原始測試程序?! y試是一個專業(yè),要用專門的一套技術(shù)來進行關(guān)鍵的工作。好的測試是從一開始就參加軟件開發(fā),可為產(chǎn)品開 發(fā)階段帶來一種質(zhì)量的觀念。盡量使產(chǎn)品暴露出問題才是公司和用戶的最大利益所在,應當注意的是測試的技能 與開發(fā)并不相同。常常和測試聯(lián)系在一起的用戶和開發(fā) 人員,但用這兩類人作測試都存在一些問題。開發(fā)人員的工作是構(gòu)建,他制造產(chǎn)品;而測試人員的任務則是找出缺 陷,每個工作都要求特定的個陛,在兩者之間隨意變動不是小事。更重要的是,讓開發(fā)人員去測試自已的代碼,當處理代碼的薄弱部位時,會不自覺地退縮,不是很好地了解問題而是繞開軟件中有問題的部分,他們沒有足夠的勇氣對自己動手術(shù)。由用戶來進行測試,雖然在可用性方面能提供大量反饋。用戶在測試時通常重復,不夠系統(tǒng),另外缺乏想象力。對新軟件缺乏信心,速度也比較慢。5 結(jié)束語  許多公司對獨立測試或功能驗證相當滿意。但這 些公司的測試一般是在流程結(jié)束時才會進行,以確定產(chǎn) 品達到必要的質(zhì)量水平。本文重點是評審和檢查,盡管這兩種技術(shù)提供了一個更可靠的機制,可以隨著開發(fā)階段的進行將質(zhì)量制造在產(chǎn)品中,但它們在軟件公司中使用得并不普遍。用很少人對產(chǎn)品進行直觀檢查在很多 方面會相當費力,但其潛在的好處是巨大的。每個產(chǎn)品 都有缺陷,這是無法改變的,但產(chǎn)品中的缺陷遲早都是 會發(fā)現(xiàn)的。最壞的情況是在應用現(xiàn)場發(fā)現(xiàn),最好則是盡 可能早地在軟件開發(fā)過程中發(fā)現(xiàn)缺陷。一個很充分的 理由就是應該制造缺陷更少的產(chǎn)品,并且這些剩下的缺 陷其嚴重程度應能被用戶所接受。