1.4 高質(zhì)量軟件開發(fā)的基本方法

1.4.1 建立軟件過程規(guī)范

人們意識到，若想順利開發(fā)出高質(zhì)量的軟件產(chǎn)品，必須有條理地組織技術(shù)開發(fā)活動和項(xiàng)目管理活動。我們把這些活動的組織形式稱為過程模型。軟件企業(yè)應(yīng)當(dāng)根據(jù)產(chǎn)品的特征，建立一整套在企業(yè)范圍內(nèi)通用的軟件過程模型及規(guī)范，并形成制度，這樣開發(fā)人員與管理人員就可以依照過程規(guī)范有條不紊地開展工作。

我們曾與國內(nèi)很多研發(fā)人員和各級經(jīng)理交流過，大家都對軟件開發(fā)的混亂局面表示了不滿和無奈。盡管“游擊隊(duì)”的開發(fā)模式到處可見，但是沒有人真的喜歡混亂。“規(guī)范化”是區(qū)別“正規(guī)軍”和“游擊隊(duì)”的根本標(biāo)志，大家無不渴望以規(guī)范化的方式開發(fā)產(chǎn)品，這是現(xiàn)狀，是需求，也是希望。

對軟件開發(fā)模型的研究興起于20世紀(jì)60年代末70年代初，典型成果是1970年提出的瀑布模型。人們研制了很多的軟件開發(fā)模型，常見的還有“噴泉模型”、“增量模型”、“快速原型模型”、“螺旋模型”、“迭代模型”等。

這么多軟件開發(fā)模型，企業(yè)應(yīng)該如何選擇并應(yīng)用呢？

企業(yè)在選擇軟件開發(fā)模型時，不要太在乎學(xué)術(shù)上的“先進(jìn)”與“落后”，正如有才華的人并不一定要出自名牌大學(xué)或擁有高學(xué)歷那樣。關(guān)鍵是看該模型能否有效地幫助企業(yè)順利地開發(fā)出軟件產(chǎn)品，并且要考慮員工們使用起來是否方便。簡而言之，就是考察模型是否“實(shí)用、好用”。

最早出現(xiàn)的軟件開發(fā)模型是瀑布模型，它太理想化、太單純，看起來已經(jīng)落后于現(xiàn)代的軟件開發(fā)模式。如今瀑布模型幾乎被學(xué)術(shù)界拋棄，偶爾被人提起，都屬于被貶的對象，未留下一絲惋惜。說它如何如何地差，為的是說明新模型是怎樣怎樣地好。

然而企業(yè)界不同于學(xué)術(shù)界。我認(rèn)為瀑布模型對企業(yè)太有價值了，我要為它聲辯，恢復(fù)它應(yīng)有的名譽(yù)。瀑布模型的精髓是“線性順序”地開發(fā)軟件。我們應(yīng)該認(rèn)識到“線性化”是人們最容易掌握并能熟練應(yīng)用的思想方法。當(dāng)人們碰到一個復(fù)雜的“非線性”問題時，總是千方百計地將其分解或轉(zhuǎn)化為一系列簡單的線性問題，然后逐個解決。一個軟件系統(tǒng)的整體可能是復(fù)雜的，而細(xì)分后的子程序總是簡單的，可以用“線性化”的方式來實(shí)現(xiàn)，否則干活就太累了。

讓我們引用愛因斯坦的話作為信條——“任何事物都應(yīng)該盡可能地簡潔”。“線性”是一種簡潔，簡潔就是美。當(dāng)我們領(lǐng)會了“線性”的精神，就不要再呆板地套用“線性”的外表，而應(yīng)該用活它。例如，增量模型實(shí)質(zhì)上就是分段的線性模型，螺旋模型則是迭代的彎曲了的線性模型。在其他模型中大都能夠找到“線性”的影子。

瀑布模型是如此地簡潔，所有的軟件開發(fā)人員一學(xué)就會（如果學(xué)不會，那他就別干軟件這一行了）。所以瀑布模型特別適合于企業(yè)，請大家別輕易地貶低它。

軟件開發(fā)模型只關(guān)注技術(shù)開發(fā)活動，并不考慮項(xiàng)目管理，這對開發(fā)產(chǎn)品而言是不夠的，所以開發(fā)模型只是軟件過程模型的一部分。奇怪的是，迄今為止我尚未找到論述軟件過程模型的軟件工程書籍，我就自己創(chuàng)作了一個基于CMMI 3級的軟件過程模型，稱為“精簡并行過程”（Simplified Parallel Process, SPP）。

SPP模型如圖1-2所示。“精簡并行過程”的含義是：

（1）對CMMI 3級以內(nèi)的過程域及關(guān)鍵實(shí)踐做了“精簡”處理。

（2）項(xiàng)目管理過程、技術(shù)開發(fā)過程和機(jī)構(gòu)支撐過程“并行”開展。

SPP模型把產(chǎn)品生命周期劃分為6個階段：

? 產(chǎn)品概念階段，記為PH0。

? 產(chǎn)品定義階段，記為PH1。

? 產(chǎn)品開發(fā)階段，記為PH2。

? 產(chǎn)品驗(yàn)證階段，記為PH3。

? 用戶驗(yàn)收階段，記為PH4。

? 產(chǎn)品維護(hù)階段，記為PH5。

在SPP模型中，一個項(xiàng)目從PH0到PH5共經(jīng)歷19個過程域（Process Area），它們被劃分為3大類過程，如表1-2所示。其中項(xiàng)目管理過程含6個過程域，技術(shù)開發(fā)過程含8個過程域，支撐過程含5個過程域。

SPP模型的主要優(yōu)點(diǎn)如下：

（1）模型直觀。SPP模型是三層結(jié)構(gòu)，上層是項(xiàng)目管理過程的集合，中層是技術(shù)開發(fā)過程的集合，下層是支撐過程的集合。這種模型很直觀，高級經(jīng)理、項(xiàng)目經(jīng)理、開發(fā)人員、質(zhì)量保證員等根據(jù)SPP模型就很容易知道自己“應(yīng)該在什么時候做什么事情，以及按照什么規(guī)范去做事情”。SPP模型有助于使各個過程的活動有條不紊地開展。

（2）便于用戶裁剪SPP模型。項(xiàng)目管理過程和支撐過程對絕大多數(shù)軟件產(chǎn)品開發(fā)而言都是適用的。需求開發(fā)、技術(shù)預(yù)研、系統(tǒng)設(shè)計、編程、測試、技術(shù)評審、維護(hù)都是技術(shù)開發(fā)過程中必不可少的環(huán)節(jié)，用戶可以根據(jù)產(chǎn)品的特征確定最合適的開發(fā)模型（如瀑布模型、快速原型模型、迭代模型等）。

（3）便于用戶擴(kuò)充SPP模型。如果產(chǎn)品同時涉及軟件、硬件開發(fā)的話，可將產(chǎn)品生命周期、軟件開發(fā)過程和硬件開發(fā)過程集成起來。

1.4.2 復(fù)用

復(fù)用就是指“利用現(xiàn)成的東西”。被復(fù)用的對象可以是有形的物體，也可以是無形的知識成果。復(fù)用不是人類懶惰的表現(xiàn)，而是智慧的表現(xiàn)。因?yàn)槿祟惪偸窃诶^承了前人的成果，不斷加以利用、改進(jìn)或創(chuàng)新后才會進(jìn)步。

復(fù)用有利于提高質(zhì)量，提高生產(chǎn)率，并降低成本。由經(jīng)驗(yàn)可知，通常在一個新系統(tǒng)中，大部分的內(nèi)容是成熟的，只有小部分內(nèi)容是創(chuàng)新的。一般可以相信成熟的東西總是比較可靠的（即具有高質(zhì)量），而大量成熟的工作可以通過復(fù)用來快速實(shí)現(xiàn)（即具有高生產(chǎn)率）。勤勞并且聰明的人們應(yīng)該把大部分的時間用在小比例的創(chuàng)新工作上，而把小部分的時間用在大比例的成熟工作中，這樣才能把工作做得又快又好。

把復(fù)用的思想用于軟件開發(fā)，稱為軟件復(fù)用。技術(shù)開發(fā)活動與管理活動中的任何成果都可以被復(fù)用，如思想方法、經(jīng)驗(yàn)、程序、文檔，等等。據(jù)統(tǒng)計，世上已有一千多億行程序，無數(shù)功能被重寫了成千上萬次，真是浪費(fèi)啊！面向?qū)ο螅∣bject Oriented）學(xué)者的口頭禪就是“請不要再發(fā)明相同的車輪子了”。

具有一定集成度并可以重復(fù)使用的軟件組成單元稱為軟構(gòu)件（Software Component）。軟件復(fù)用可以表述為：構(gòu)造新的軟件系統(tǒng)可以不必每次從零做起，直接使用已有的軟構(gòu)件，即可在組裝或加以合理修改后成為新的系統(tǒng)。

復(fù)用方法合理化并簡化了軟件開發(fā)過程，減少了總的開發(fā)工作量與維護(hù)代價，既降低了軟件的成本，又提高了生產(chǎn)率。另一方面，由于軟構(gòu)件是經(jīng)過反復(fù)使用驗(yàn)證的，自身具有較高的質(zhì)量，因此由軟構(gòu)件組成的新系統(tǒng)也具有較高的質(zhì)量。

軟件復(fù)用不僅要使自己拿來方便，還要讓別人拿去方便，是“拿來拿去主義”。這想法挺好，但現(xiàn)實(shí)中執(zhí)行得并不如意。企業(yè)的業(yè)務(wù)各式各樣，誰也不能坐等著天上掉下可以大規(guī)模復(fù)用的東西，一般要靠“日積月累”方能建設(shè)可以復(fù)用的軟件庫。從理論上講，這項(xiàng)工作沒有不可逾越的技術(shù)障礙。真正的障礙是它“耗時費(fèi)錢”，前期投入較多，缺乏近期效益。大部分的公司都注重近期效益，不是它天生目光短淺，而是為了生存必須這么做。有些處境艱難的公司的下一頓飯還不知道著落，更別提軟件復(fù)用這樣的“長久之計”了。所以軟件復(fù)用對大多數(shù)公司來說不是“最高優(yōu)先級”。

我到公司工作的最初安排是從事電信領(lǐng)域“可復(fù)用軟件工廠”的開發(fā)。領(lǐng)導(dǎo)在招聘時跟我講，這個想法已經(jīng)有數(shù)年了，一直沒有落實(shí)，希望我能做好。待我正式上班時，馬上就改成做其他短期的研發(fā)項(xiàng)目了。要知道我所在的公司人力與財力相當(dāng)充足，非國內(nèi)普通中小型IT企業(yè)所能比。即便我們有如此好的條件，軟件復(fù)用也只是掛在嘴上，沒有實(shí)際行動。

所以我建議：隨時隨地盡可能地復(fù)用你所能復(fù)用的東西，不要等待公司下達(dá)復(fù)用的行政命令，因?yàn)槟愫茈y等到那一天，即使等到了也沒有多大的意義。

1.4.3 分而治之

分而治之是指把一個復(fù)雜的問題分解成若干個簡單的問題，然后逐個解決。這種樸素的思想來源于人們的生活和工作經(jīng)驗(yàn)，完全適合于技術(shù)領(lǐng)域。

分而治之說起來容易，做好卻難，最糟糕的現(xiàn)象是“分是分了”，卻“治不了”。

軟件的分而治之不可以“硬分硬治”。不像為了吃一個西瓜或是一只雞，揮刀斬成n塊，再把每塊塞進(jìn)嘴里粉碎攪拌，然后交由胃腸來消化吸收，象征復(fù)雜問題的西瓜或是雞也就此消失了。

軟件的“分而治之”應(yīng)該著重考慮：復(fù)雜問題分解后，每個問題能否用程序?qū)崿F(xiàn)？所有程序能否最終集成為一個軟件系統(tǒng)并有效解決原始的復(fù)雜問題？圖1-3表示了軟件的“分而治之”策略。軟件的模塊化設(shè)計就是分而治之的具體表現(xiàn)。

1.4.4 優(yōu)化與折中

軟件的優(yōu)化是指優(yōu)化軟件的各個質(zhì)量屬性，如提高運(yùn)行速度、提高對內(nèi)存資源的利用率、使用戶界面更加友好、使三維圖形的真實(shí)感更強(qiáng)，等等。想做好優(yōu)化工作，首先要讓開發(fā)人員都有正確的認(rèn)識：優(yōu)化工作不是可有可無的事情，而是必須要做的事情。

當(dāng)優(yōu)化工作成為一種責(zé)任時，開發(fā)人員才會不斷改進(jìn)軟件中的數(shù)據(jù)結(jié)構(gòu)、算法和程序，從而提高軟件質(zhì)量。

著名的3D游戲軟件Quake，能夠在PC上實(shí)時地繪制具有高度真實(shí)感的復(fù)雜場景。Quake的開發(fā)者能把很多成熟的圖形技術(shù)發(fā)揮到極致，例如，把Bresenham畫線、多邊形裁剪、樹遍歷等算法的速度提高近一個數(shù)量級。我的博士研究方向是計算機(jī)圖形學(xué)，我第一次看到Quake時不僅感到震動，而且深受打擊。這個PC游戲軟件的技術(shù)水平已經(jīng)遠(yuǎn)勝于我所見識到的國內(nèi)領(lǐng)先的圖形學(xué)相關(guān)科研成果。這對國內(nèi)日益盛行的“點(diǎn)到為止”的學(xué)術(shù)研究真是莫大的諷刺！

所以當(dāng)我們開發(fā)出來的軟件表現(xiàn)出很多不可救藥的病癥時，不要埋怨機(jī)器差。真的都是我們自己沒有把工作做好。正所謂，寫不好字不要嫌筆。

假設(shè)我們經(jīng)過思想教育后，精神抖擻，隨時準(zhǔn)備為優(yōu)化工作干上六天七夜時，要清醒地知道愿意做并不意味著就能把事情做好。優(yōu)化工作的復(fù)雜之處是很多目標(biāo)之間存在千絲萬 的關(guān)系，可謂“剪不斷理還亂”。當(dāng)不能夠使所有的目標(biāo)都得到優(yōu)化時，就需要“折中”。

軟件中的“折中”是指協(xié)調(diào)各個質(zhì)量屬性，實(shí)現(xiàn)整體質(zhì)量的最優(yōu)，正如“……為了使整個組織具有最好的戰(zhàn)斗力，我們要重用幾個人，照顧一些人，在萬不得已的情況下委屈一批人”。

軟件折中的重要原則是不能使某一方損失關(guān)鍵的功能，更不可以像“舍魚而取熊掌”那樣拋棄一方。例如，3D動畫軟件的瓶頸通常是速度，但如果為了提高速度而在程序中取消光照明計算，那么場景就會喪失真實(shí)感，3D動畫也就不再有意義了。

人都有惰性，如果允許濫用折中的話，那么一旦碰到困難，人們就會用“拆東墻補(bǔ)西墻”的方式去折中，不再下苦功去做有意義的優(yōu)化。所以我們有必要為折中制定嚴(yán)正的立場：在保證其他質(zhì)量屬性不差的前提下，使某些重要質(zhì)量屬性變得更好。

下面讓我們用優(yōu)化與折中的思想解決“魚與熊掌不可得兼”的難題。

1.4.5 技術(shù)評審

技術(shù)評審（Technical Review, TR）的目的是盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產(chǎn)品的質(zhì)量。

技術(shù)評審最初是由IBM公司為了提高軟件質(zhì)量和提高程序員生產(chǎn)率而倡導(dǎo)的。技術(shù)評審方法已經(jīng)被業(yè)界廣泛采用并收到了很好的效果，它被普遍認(rèn)為是軟件開發(fā)的最佳實(shí)踐之一。技術(shù)評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現(xiàn)并消除工作成果中的缺陷。技術(shù)評審的主要好處有：

? 通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量。

? 越早消除缺陷就越能降低開發(fā)成本。

? 開發(fā)人員能夠及時地得到同行專家的幫助和指導(dǎo)，無疑會加深對工作成果的理解，更好地預(yù)防缺陷，在一定程度上能提高開發(fā)效率。

技術(shù)評審有以下兩種基本類型。

? 正式技術(shù)評審（FTR）：FTR比較嚴(yán)格，需要舉行評審會議，參加評審會議的人員比較多。

? 非正式技術(shù)評審（ITR）：ITR的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。

從理論上講，為了確保產(chǎn)品的質(zhì)量，產(chǎn)品的所有工作成果都應(yīng)當(dāng)接受技術(shù)評審。現(xiàn)實(shí)中為了節(jié)約時間，允許人們有選擇地對工作成果進(jìn)行技術(shù)評審。技術(shù)評審方式也視工作成果的重要性和復(fù)雜性而定。例如，將重要性、復(fù)雜性各分“高、中、低”3個等級，重要性—復(fù)雜性的組合與技術(shù)評審方式的對應(yīng)關(guān)系如表1-3所示。

正式技術(shù)評審的一般流程如圖1-4所示。

技術(shù)評審的注意事項(xiàng)：

? 評審人員的職責(zé)是發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員找到消除缺陷的辦法，而不是替開發(fā)人員消除缺陷。

? 技術(shù)評審應(yīng)當(dāng)“就事論事”，不要打擊有失誤的開發(fā)人員的工作積極性，更不能搞人身攻擊（如挖苦、諷刺等）。

? 在會議評審期間要限制過多的爭論，以免浪費(fèi)他人的時間。

對技術(shù)評審的一些建議：

? 對于重要性和復(fù)雜性都很高的工作成果，建議先在項(xiàng)目內(nèi)部進(jìn)行“非正式技術(shù)評審”，然后再進(jìn)行“正式技術(shù)評審”。

? 技術(shù)評審應(yīng)當(dāng)與質(zhì)量保證有機(jī)地結(jié)合起來，最好請質(zhì)量保證人員參加并監(jiān)正式技術(shù)評審。

? 技術(shù)評審應(yīng)當(dāng)與配置管理有機(jī)地結(jié)合起來，如規(guī)定：工作成果在成為基準(zhǔn)（Baseline）之前必須先通過技術(shù)評審。

? 建議機(jī)構(gòu)采用統(tǒng)一的缺陷跟蹤工具，使得技術(shù)評審所發(fā)現(xiàn)的缺陷能夠及時地消除，不致遺漏。

1.4.6 測試

測試是通過運(yùn)行測試用例（Test Case）來找出軟件中的缺陷。測試與技術(shù)評審的主要區(qū)別是：前者要運(yùn)行軟件而后者不必運(yùn)行軟件（動態(tài)檢查和靜態(tài)檢查）。

在軟件開發(fā)過程中，編程和測試是緊密相關(guān)的技術(shù)活動，缺一不可。理論上講兩者不分貴，同等重要。但在大多數(shù)軟件企業(yè)中，程序員的待遇普遍要高于專職的測試人員。即使不考慮待遇問題，大多數(shù)人認(rèn)為開發(fā)工作比測試工作更有趣、更有成就感、更有前途。所以計算機(jī)專業(yè)人員通常會把編程當(dāng)成一種看家本領(lǐng)，舍得下功夫?qū)W習(xí)和鉆研，但極少有人以這種態(tài)度對待軟件測試。這種意識導(dǎo)致軟件測試被過于輕視。不僅學(xué)生們在讀書時懶得學(xué)習(xí)測試（目前國內(nèi)高校似乎沒有“軟件測試”的課程），就連有數(shù)年工作經(jīng)驗(yàn)的軟件開發(fā)人員也未必懂得測試。

不少開發(fā)人員雖然不敵視測試工作，但有“臨時抱佛腳”的壞習(xí)慣，往往事到臨頭才到處找測試資料，向人請教。經(jīng)常有人向我要文檔模板，用來對付測試。

你以為有了文檔模板就懂得如何測試了么？

測試雖然并不深奧，但是學(xué)好并不容易。不懂得“有效”測試的項(xiàng)目小組往往面臨這樣的問題：計劃中的時間很快就用完了，即使有跡象表明軟件中還有不少缺陷，也只好草草收場，把麻煩留給將來。

測試的主要目的是為了發(fā)現(xiàn)盡可能多的缺陷。可是這個觀念不容易被人接受。

正確理解測試的目的十分重要。如果認(rèn)為測試的目的是為了說明軟件中沒有缺陷，那么測試人員就會向這個目標(biāo)靠攏，因而下意識地選用一些不易暴露錯誤的測試示例。這樣的測試是不真實(shí)的。如果是為了說明軟件有多么好，那么應(yīng)當(dāng)制作專門的演示。千萬不要將“測試”與“演示”混為一談。

看來測試并不單單是個技術(shù)問題，還是個職業(yè)道德問題。

根據(jù)測試的目的，可以得出一個推論：成功的測試在于發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷。所以測試人員的職責(zé)是設(shè)計出這樣的測試用例，它能有效地揭示潛伏在軟件里的缺陷。

如果測試工作很全面、很認(rèn)真，但是的確沒有發(fā)現(xiàn)新的缺陷，那么這樣的測試是否毫無價值？

不，那不是測試的過失，應(yīng)當(dāng)反過來理解：軟件的質(zhì)量實(shí)在是太好了，以至于這樣的測試發(fā)現(xiàn)不了缺陷。

所以，如果產(chǎn)品通過了嚴(yán)格的測試，大家不要不 氣，應(yīng)當(dāng)好好地宣傳一下，把測試的成本 回一些。

軟件測試的常規(guī)分類如表1-4所示，測試的一般流程如圖1-5所示。如果對表1-4和圖1-5的內(nèi)容做深入論述，大約還需要幾十頁的篇幅，這顯然超出了本章的范疇。這里就點(diǎn)到為止吧，請讀者參考軟件測試的有關(guān)文獻(xiàn)。

測試經(jīng)驗(yàn)談：

? 測試能提高軟件的質(zhì)量，但是提高質(zhì)量不能依賴測試。

? 測試只能證明缺陷存在，不能證明缺陷不存在。“徹底地測試”難以成為現(xiàn)實(shí)，要考慮時間、費(fèi)用等限制，不允許無休止地測試。我們只好祈禱：軟件的缺陷在產(chǎn)品被淘汰之前一直沒有機(jī)會發(fā)作！

? 測試的主要困難是不知道如何進(jìn)行有效的測試，也不知道什么時候可以放心地結(jié)束測試。

? 每個開發(fā)人員應(yīng)當(dāng)測試自己的程序（分內(nèi)之事），但是不能作為該程序已經(jīng)通過測試的依據(jù)（所以項(xiàng)目才需要獨(dú)立的測試人員）。

? 2-8原則：80的缺陷聚集在20的模塊中，經(jīng)常出錯的模塊改錯后還會經(jīng)常出錯。

1.4.7 質(zhì)量保證

質(zhì)量保證（Quality Assurance, QA）的目的是提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實(shí)現(xiàn)持續(xù)地改進(jìn)質(zhì)量。質(zhì)量保證是一種有計劃的、貫穿于整個產(chǎn)品生命周期的質(zhì)量管理方法。

過程質(zhì)量與產(chǎn)品質(zhì)量存在某種因果關(guān)系，通常“好的過程”產(chǎn)生“好的產(chǎn)品”，而“差的過程”將產(chǎn)生“差的產(chǎn)品”。人們銷售的是產(chǎn)品而不是過程，用戶關(guān)心的是最終產(chǎn)品的質(zhì)量，而軟件開發(fā)團(tuán)隊(duì)既要關(guān)心過程質(zhì)量又要關(guān)心產(chǎn)品質(zhì)量。

質(zhì)量保證的基本方法是通過有計劃地檢查“工作過程及工作成果”是否符合既定的規(guī)范，來監(jiān)控和改進(jìn)“過程質(zhì)量”與“產(chǎn)品質(zhì)量”。如果“工作過程及工作成果”不符合既定的規(guī)范，那么產(chǎn)品的質(zhì)量肯定有問題。基于這樣的推理，質(zhì)量保證人員即使不是技術(shù)專家，他也能夠客觀地檢查和監(jiān)控產(chǎn)品的質(zhì)量，這是質(zhì)量保證方法富有成效的一面。但是“工作過程及工作成果”符合既定的規(guī)范并不意味著產(chǎn)品的質(zhì)量一定合格，因?yàn)閮H靠規(guī)范無法識別出產(chǎn)品中可能存在的大量缺陷，這是質(zhì)量保證方法的不足之處。所以單獨(dú)的“質(zhì)量保證”其實(shí)并不能保證質(zhì)量。

技術(shù)評審與測試關(guān)注的是產(chǎn)品質(zhì)量而不是過程質(zhì)量，兩者的技術(shù)強(qiáng)度比質(zhì)量保證要高得多。技術(shù)評審和測試能彌補(bǔ)質(zhì)量保證的不足，三者是相輔相成的質(zhì)量管理方法。我們在實(shí)踐中不能將質(zhì)量保證、技術(shù)評審和測試混為一談，也不能把三者孤立起來執(zhí)行。建議讓質(zhì)量保證人員參加并監(jiān)督重要的技術(shù)評審和測試工作，把三者有機(jī)地結(jié)合起來，才能提高工作效率和降低成本。

質(zhì)量保證小組（Quality Assurance Group, QAG）有如下特點(diǎn)：

? 質(zhì)量保證小組在行政上獨(dú)立于任何項(xiàng)目。這種獨(dú)立性有助于質(zhì)量保證小組客觀地檢查和監(jiān)控產(chǎn)品的質(zhì)量。

? 質(zhì)量保證小組有一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。這種權(quán)利使得質(zhì)量保證小組的工作不會被輕視，并有助于加強(qiáng)全員的質(zhì)量意識。需要強(qiáng)調(diào)的是，提高產(chǎn)品質(zhì)量是全員的職責(zé)，并非只是質(zhì)量保證小組的職責(zé)。

質(zhì)量保證過程域的主要活動如圖1-6所示。

1.4.8 改錯

改錯是個大悲大喜的過程，一天之內(nèi)可以讓人在悲傷的低 和喜悅的巔峰之間蕩起伏。

我從大三開始真正接受改錯的磨煉，已記不清楚多少次汗流浹背、濕透板凳。改不了錯誤時，恨不得撞墻。改了錯誤時，比女孩子朝我笑笑還開心。

在做本科畢業(yè)設(shè)計時，一天夜里，一哥們兒來我的實(shí)驗(yàn)室，合不攏嘴地對我嚷嚷：“你知道什么叫茅塞頓開嗎？”

我像文盲似地?fù)u搖頭。

他說：“今天我花了十幾小時沒能干掉一個錯誤，剛才我去了廁所五分鐘，一切都解決了。”

軟件中的錯誤通常只有開發(fā)者自己才能找出并改掉，如果因 懼而拖延，會讓你終日心神不定，食無味，睡不香。所以長痛不如短痛，要集中精力對付錯誤。

改錯過程很像 破案件，有些壞事發(fā)生了，而僅有的信息就是它的確發(fā)生了。我們必須從結(jié)果出發(fā)，逆向思考。改錯的第一步是找出錯誤的根源，如同醫(yī)生治病，必須先找出病因才能“對癥下藥”。

根據(jù)軟件錯誤的癥狀推斷出根源并不是件容易的事兒，因?yàn)椋?/p>

（1）癥狀和根源可能相隔很遠(yuǎn)。也就是說，癥狀可能在某一個程序單元中出現(xiàn)，而根源實(shí)際上在很遠(yuǎn)的另一個地方。高度耦合的程序結(jié)構(gòu)加劇了這種情況。

（2）癥狀可能在另一個錯誤被糾正后暫時消失。

（3）癥狀可能并不是由某個程序錯誤直接引發(fā)的，如誤差累積。

（4）癥狀可能是由不太容易跟蹤的人工錯誤引起的。

（5）癥狀可能時隱時現(xiàn)，如內(nèi)存泄漏。

（6）很難重新產(chǎn)生完全一樣的輸入條件，難以重現(xiàn)“錯誤現(xiàn)場”。

（7）癥狀可能分布在許多不同的任務(wù)中，難以跟蹤。

改錯的最大忌 是“急躁 干”。人們常說“急中生智”，我不信，我認(rèn)為大多數(shù)人著了急就會 干，早把“智”丟到腦后去了。不僅人如此，動物也如此。

我們把尋找錯誤根源的過程稱為調(diào)試（Debugging）。調(diào)試的基本方法是“粗分細(xì)找”。對于隱藏得很深的Bug，我們應(yīng)該運(yùn)用歸納、推理、“二分”等方法先“快速、粗略”地確定錯誤根源的范圍，然后再用調(diào)試工具仔細(xì)地跟蹤此范圍的源代碼。如果沒有調(diào)試工具，那么只好用“土辦法”：在程序中插入打印語句，如printf(…)，觀看屏幕的輸出。

有些時候，世界上最好的調(diào)試工具恐怕是那些有經(jīng)驗(yàn)的人。我們經(jīng)常會長時間地追蹤某個Bug，苦惱萬分。恰好有高手路過，被他一語“道破天機(jī)”，頓時沮喪的云就被驅(qū)散，你不得不說“I服了You”。

修改代碼錯誤時的注意事項(xiàng)

? 找到錯誤時，不要急于修改，先思考一下：修改此代碼會不會引發(fā)其他問題？如果沒有問題，則可以放心修改；如果有問題，那么可能要改動程序結(jié)構(gòu)，而不止一行代碼。

? 有些時候，軟件中可能潛伏同一類型的許多錯誤（如由不良的編程習(xí)慣引起的），好不容易逮住一個，應(yīng)當(dāng)乘勝追擊，全部殲滅。

? 在改錯之后一定要馬上進(jìn)行回歸測試，以免引入新的錯誤。有人在馬路上撿到錢包后得意忘形，不料自己卻被汽車 倒。改了一個程序錯誤固然是喜事，但要防止樂極生悲。更加嚴(yán)格的要求是：不論原有程序是否絕對正確，只要對此程序做過改動（哪怕是微不足道的），都要進(jìn)行回歸測試。

? 上述事情做完后，應(yīng)當(dāng)好好反思：我為什么會犯這樣的錯誤？怎么能夠防止下次不犯相似的錯誤？最好能寫一下心得體會，與他人共享經(jīng)驗(yàn)教訓(xùn)。