【正文】 選出一位程序員來(lái)?yè)?dān)任這個(gè)評(píng)分過(guò)程的管理，管理員又會(huì)挑選出大約6~20名參與者（為保持匿名性，6人是最少數(shù)量）。同行評(píng)分是一種依據(jù)程序整體質(zhì)量、可維護(hù)性、可擴(kuò)展性、易用性和清晰性對(duì)匿名程序進(jìn)行評(píng)價(jià)的技術(shù)。簡(jiǎn)而言之，桌面檢查勝過(guò)沒(méi)有檢查，但其效果遠(yuǎn)遠(yuǎn)遜色于代碼走查和代碼走查。小組會(huì)議培養(yǎng)了良性競(jìng)爭(zhēng)的氣氛，人們喜歡通過(guò)發(fā)現(xiàn)問(wèn)題來(lái)展示自己的能力。但是即使這樣，其效果仍然遜色于代碼走查或代碼檢查。另一個(gè)重要的原因是它違反了本書(shū)第2章提出的測(cè)試原則，即人們一般不能有效地測(cè)試自己編寫(xiě)的程序。 對(duì)于大多數(shù)人而言，桌面檢查的效率是向當(dāng)?shù)椎摹?桌面檢查 人工找錯(cuò)誤的第三中是古老的桌面檢查方法。 與代碼檢查過(guò)程描述的相似，代碼走查應(yīng)有一個(gè)后續(xù)過(guò)程。換句話說(shuō)，軟件中存在的錯(cuò)誤不應(yīng)該比視為編寫(xiě)程序人員自身的弱點(diǎn)。 與代碼檢查相同，代碼走查參與者所持的態(tài)度非常關(guān)鍵。因此，這些測(cè)試用例本是并不起到關(guān)鍵的作用；相反，它們的作用是提供了啟動(dòng)代碼走查和質(zhì)疑程序員邏輯思路及其設(shè)想的手段。程序的狀態(tài)（如變量的值）記錄在紙或白板上以供監(jiān)視。在會(huì)議期間，每個(gè)測(cè)試用例都在人們腦中進(jìn)行推演。不同于僅閱讀程序或使用錯(cuò)誤檢查列表，代碼走查的參與者“使用了計(jì)算機(jī)”。 開(kāi)始的過(guò)程與代碼檢查形同：參與者在走查會(huì)議之前的幾天得到材料，他們可以專心鉆研程序。當(dāng)然，程序應(yīng)該是其中之一。代碼走查小組又三至五人組成，其中一個(gè)人扮演類似代碼檢查過(guò)程中“協(xié)調(diào)人”的角色，一個(gè)人擔(dān)任秘書(shū)（負(fù)責(zé)記錄所有查處的錯(cuò)誤）的角色，還有一個(gè)人擔(dān)任測(cè)試人員。代碼走查的過(guò)程與代碼檢查大體相同，但是規(guī)程稍微有所不同，采用的錯(cuò)誤檢查技術(shù)也不一樣。？也就是說(shuō)，它是否對(duì)其輸入的合法性進(jìn)行了檢查？？這些檢查列表在表31和表32中進(jìn)行了總結(jié)?！熬妗毙畔⒅赋鼍幾g器對(duì)程序某些操作的正確性喲所懷疑；所有這些疑問(wèn)都應(yīng)進(jìn)行檢查。，那么對(duì)每個(gè)變量的屬性進(jìn)行檢查，確保沒(méi)有賦予過(guò)不希望的默認(rèn)屬性值。？，所有引用他們額模塊中，它們的定義和屬性是否形同？？在一些用FOTRAN語(yǔ)言編寫(xiě)的程序中，諸如CALL SUBX (J,3)的語(yǔ)句是很危險(xiǎn)的，因?yàn)槿绻映绦騍UBX對(duì)其第二個(gè)形參進(jìn)行賦值，常數(shù)3的值將會(huì)改變。 Y = X+Z。 W = X +1。} （例如dowhile或｛…｝），是否每一組語(yǔ)句都有一個(gè)明確的while語(yǔ)句，并且do語(yǔ)句也與其相應(yīng)的語(yǔ)句組對(duì)應(yīng)？或者，是否每一個(gè)左括號(hào)多對(duì)應(yīng)有一個(gè)右括號(hào)？目前的大多數(shù)編譯器都能識(shí)別保護(hù)這些不匹配的情況。Ii =9。i++){ ( i )。舉例來(lái)說(shuō)，如果想編寫(xiě)一段JAVA代碼執(zhí)行10次循環(huán)，下面的語(yǔ)句是錯(cuò)誤的，因?yàn)樗鼒?zhí)行了11次：For ( int i=0。i ++){…}While (NOTFOUND){…}當(dāng)NOTFOUND初始時(shí)就為假，或者x大于z時(shí)，情況會(huì)如何呢？（如一個(gè)搜索循環(huán)），如果循環(huán)越界（fallthrough）了，后果會(huì)如何？例如，偽指令循環(huán)以 DO I=1 TO TABLESIZE WHILE (NOTFOUND)開(kāi)頭，如果NOTFOUND永不為假，會(huì)發(fā)生什么結(jié)果呢？6．是否存在“僅差一個(gè)”的錯(cuò)誤，如迭代數(shù)量恰恰多一次或少一次？這在從0開(kāi)始的循環(huán)中是常見(jiàn)的錯(cuò)誤。、模塊或子程序是否最終終止了？，循環(huán)是否有可能從未執(zhí)行過(guò)？如果確實(shí)發(fā)生這種情況，這里是否是一處疏漏？例如，如果循環(huán)一下的語(yǔ)句作為開(kāi)頭：For (I = =x。( x/y)z）對(duì)于有的編譯來(lái)說(shuō)是可接受的，因?yàn)槠湔J(rèn)為一旦“與”運(yùn)算的一側(cè)為FALSE時(shí)，另一側(cè)就不用計(jì)算；但是對(duì)于其他編譯來(lái)說(shuō)，卻可能起一個(gè)被0除的錯(cuò)誤。(b = =2))||（c= = 3））的表達(dá)式，程序能否正確理解是“與”運(yùn)算在先還是“或”運(yùn)算在先？？例如，語(yǔ)句if（x = =0 amp。，賦值順序以及運(yùn)算的優(yōu)先級(jí)是否正確？也就是說(shuō)，如果碰到如同（if ( (a = =2)amp。(yz)。如果許啊喲驗(yàn)證數(shù)學(xué)關(guān)系xyz,正確的表達(dá)式應(yīng)該是（xy）amp。如果想判斷i是否大于x或y，表達(dá)式ix||y也是不正確的，正確的應(yīng)該是（ix）||(i)y。amp。？比較運(yùn)算符和布爾運(yùn)算符是否錯(cuò)誤地混在了一起？這是一類經(jīng)常會(huì)犯的錯(cuò)誤，這里我們描述幾個(gè)典型錯(cuò)誤的例子。？程序員經(jīng)常混淆“至多”、“至少”、“大于”、“不大于”、“小于”和“等于”等比較關(guān)系。9. 對(duì)于包含一個(gè)以上操作符的表達(dá)式，賦值順序和操作符的優(yōu)先順序是否正確？10. 整數(shù)的運(yùn)算是否有使用不當(dāng)?shù)那闆r，尤其是除法？舉例來(lái)說(shuō)，如果i是一個(gè)整形變量，表達(dá)式2*i/2= =i是否成立，取決于i是奇數(shù)還是偶數(shù)，或是先運(yùn)算乘法，還是先運(yùn)算除法。6. 除法運(yùn)算中的除數(shù)是否可能為0？7 如果計(jì)算機(jī)表達(dá)變量的基本方式是基于二進(jìn)制的，那么運(yùn)算結(jié)果是否不精確？也就是說(shuō)，在一個(gè)二進(jìn)制計(jì)算機(jī)上，10* 。Z = 0。(“z = “+ z)。int z = 0。卡看下面的JAVA程序片段，顯示了整數(shù)運(yùn)算中可能發(fā)生的取整誤差：int x = 1。 運(yùn)算錯(cuò)誤1. 是否存在不一致的數(shù)據(jù)類型（如非算術(shù)類型）的變量的運(yùn)算？2. 是否有混合模式的運(yùn)算？例如，將浮點(diǎn)變量與一個(gè)整形變量做加法運(yùn)算。4. 是否每個(gè)變量都被賦予了正確的長(zhǎng)度和數(shù)據(jù)類型？5. 變量的初始化是否與其存儲(chǔ)空間的類型一致？舉例來(lái)說(shuō)，如果FORTRAN語(yǔ)言子程序中的一個(gè)變量在每次調(diào)用子程序時(shí)都需要重新初始化一次，那么必須使用賦值語(yǔ)句對(duì)其初始化，而不應(yīng)該用DATA語(yǔ)句。另外，如果某個(gè)變量在一個(gè)內(nèi)部過(guò)程或程序壞中沒(méi)有明確聲明，是否可以理解為該變量在這個(gè)程序塊中被共用？2. 如果變量所有的屬性在聲明中沒(méi)有明確說(shuō)明，那么說(shuō)明默認(rèn)的屬性能否被正確理解？舉例來(lái)說(shuō)，在JAVA語(yǔ)言中，程序接收到的惡魔人屬性往往是導(dǎo)致意外發(fā)生的源頭。，那么每個(gè)過(guò)程或子程序?qū)υ搨€(gè)、結(jié)果的定義是否都相同？，當(dāng)對(duì)數(shù)組進(jìn)行索引操作或下標(biāo)引用，字符的邊界取值是否有“僅差一個(gè)”（off—by—one）的錯(cuò)誤？，是否所有的繼承需求都在實(shí)現(xiàn)類中得到了滿足？ 數(shù)據(jù)申明錯(cuò)誤1. 是否所有的變量都進(jìn)行了明確的聲明？沒(méi)有明確聲明雖然不一定是錯(cuò)誤，但通常卻是麻煩的源頭。將一個(gè)位串參數(shù)傳送給一個(gè)子程序時(shí)，也可能發(fā)生這種情況。，當(dāng)內(nèi)存分配的單元小于內(nèi)存可尋址的單元大小時(shí)，是否存在直接或間接的尋址錯(cuò)誤？例如，在某些條件下，定長(zhǎng)的位串不必以字節(jié)邊界為起點(diǎn)，但是地址又總是指向字節(jié)邊界的。如果程序先對(duì)A賦值，然后又引用變量B，由于機(jī)器可能會(huì)將內(nèi)存中用浮點(diǎn)位表示的實(shí)數(shù)當(dāng)作整數(shù)，在這種情況下錯(cuò)誤就可能發(fā)生。與前面檢查的方法類似，應(yīng)試圖非正式地“證明”，對(duì)于每個(gè)使用指針值的引用，引用的內(nèi)存單元都存在。當(dāng)指針的生命期大于所引用內(nèi)存單元的生命期時(shí)，錯(cuò)誤就會(huì)發(fā)生。2. 對(duì)于所有的數(shù)組引用，是否每一個(gè)下標(biāo)的值都在相應(yīng)維規(guī)定的界限內(nèi)？3. 對(duì)于所有的數(shù)組的引用，是否每個(gè)下標(biāo)的值都是整數(shù)？雖然在某些語(yǔ)言中這不是錯(cuò)誤，但這樣做是危險(xiǎn)的。 數(shù)據(jù)引用錯(cuò)誤1. 是否有引用的變量未賦值或未初始化？這可能是最常見(jiàn)的編程錯(cuò)誤，在各種環(huán)境中都可能發(fā)生。該錯(cuò)誤列表在很大程度上是獨(dú)立于編程的，也就是說(shuō)，大多數(shù)的錯(cuò)誤都可能出現(xiàn)在任意語(yǔ)言編寫(xiě)的程序中。遺憾的是，有些錯(cuò)誤列表更多地注重編程風(fēng)格而不是錯(cuò)誤（例如，“注釋是否準(zhǔn)確且有意義？”，“IF—ELSE代碼段和DO—WHILE代碼段是否縮進(jìn)對(duì)齊？”），錯(cuò)誤檢查太過(guò)模糊而實(shí)際上沒(méi)有用（例如，“代碼是否滿足設(shè)計(jì)的需求？”）。還有，代碼檢查還是早期發(fā)現(xiàn)程序中最容易出錯(cuò)部分的方法之一，有助于在基于計(jì)算機(jī)的測(cè)試過(guò)程中將更多的注意力集中在這些地方（本書(shū)地2章中的測(cè)試原則之一）。其一，程序員通常會(huì)得到編程風(fēng)格、算法選擇及編程技術(shù)等方面的反饋信息 。尤其是如果管理人員想利用代碼檢查結(jié)果，那么就與檢查過(guò)程的目的背道而馳了。正確的做法是，程序員必須懷著非自我本位的態(tài)度來(lái)對(duì)待檢查過(guò)程，對(duì)整個(gè)過(guò)程采取積極和建設(shè)性的態(tài)度：代碼檢查的目標(biāo)是發(fā)現(xiàn)程序中的錯(cuò)誤，從而改進(jìn)軟件的質(zhì)量。 請(qǐng)注意，要是檢查過(guò)程有效，必須樹(shù)立正確的態(tài)度。大多數(shù)的代碼檢查是都是按每小時(shí)大約閱讀150行代碼的數(shù)度進(jìn)行。代碼檢查會(huì)議的理想時(shí)間應(yīng)在90~120分鐘之間。幾分鐘之內(nèi)，整個(gè)設(shè)計(jì)就被徹底檢查完，任何問(wèn)題都會(huì)一目了然。在探討修補(bǔ)設(shè)計(jì)來(lái)解決這個(gè)小問(wèn)題的最佳方法時(shí)，有人可能會(huì)注意到另外的問(wèn)題。然而，有些小組可能會(huì)發(fā)現(xiàn)，當(dāng)檢查出某個(gè)小問(wèn)題之后，有兩三個(gè)人（包括負(fù)責(zé)該代碼的程序本人）會(huì)建議對(duì)設(shè)計(jì)進(jìn)行明顯的修補(bǔ)以解決這個(gè)特例。這份錯(cuò)誤清單也要進(jìn)行分析、歸納，用以提煉錯(cuò)誤列表，以便提高以后代碼檢查的效率。 會(huì)議結(jié)束之后，程序員會(huì)得到一份已發(fā)現(xiàn)錯(cuò)誤的清單。換句話說(shuō)，對(duì)著大家大聲朗讀程序，這種簡(jiǎn)單的做法看來(lái)是一個(gè)非常有效的錯(cuò)誤檢查方法。在講述的過(guò)程中，小組其他成員應(yīng)提問(wèn)題、判斷是否存在錯(cuò)誤。所有成員應(yīng)在檢查之前熟悉這些材料。小組中的其他成員通常是程序的設(shè)計(jì)人員（如果設(shè)計(jì)人員不同于編碼人員的話），以及一名測(cè)試專家。協(xié)調(diào)人就像是質(zhì)量控制工程師。u 紀(jì)錄發(fā)現(xiàn)的所有錯(cuò)誤。協(xié)調(diào)人應(yīng)該是個(gè)職稱的程序員，但不是該程序的編碼人員，不需要對(duì)程序的細(xì)節(jié)了解的很清楚，協(xié)調(diào)人的職責(zé)包括以下幾點(diǎn)：u 為代碼檢查分發(fā)材料、安排進(jìn)程。這里對(duì)整個(gè)規(guī)程進(jìn)行簡(jiǎn)短的概述，之后我們將重點(diǎn)討論實(shí)際的錯(cuò)誤檢查技術(shù)。 代碼檢查 所謂代碼檢查，是以組為單位閱讀代碼，它是一些列規(guī)程和錯(cuò)誤檢查技術(shù)的集合。根據(jù)我們的經(jīng)驗(yàn)，修改一個(gè)現(xiàn)存的程序比編寫(xiě)一個(gè)新程序更容易產(chǎn)生錯(cuò)誤（以每寫(xiě)一行代碼測(cè)錯(cuò)誤數(shù)量計(jì)）。缺少其中任何一種，錯(cuò)誤檢查的效率都會(huì)降低。然而，一些測(cè)試人員在使用了人工方法之后發(fā)現(xiàn)，對(duì)于某些特定的錯(cuò)誤，人工方法比基于計(jì)算機(jī)的方法更有效，而對(duì)于其他錯(cuò)誤類型，基于計(jì)算機(jī)的方法更有效。請(qǐng)記住，地2章告訴我們，程序中的錯(cuò)誤總數(shù)始終是未知的。但是，這些方法不能有效地查找出高層次的設(shè)計(jì)錯(cuò)誤，例如在軟件需要分析階段的錯(cuò)誤。而基于計(jì)算機(jī)的測(cè)試通常只能暴露出錯(cuò)誤的某個(gè)表征（程序不能停止，或打印出了一個(gè)無(wú)意義的結(jié)束），錯(cuò)誤通常是逐個(gè)地被發(fā)現(xiàn)并的得到糾正的。 菜嗎走查的另一個(gè)有點(diǎn)在于，一旦發(fā)現(xiàn)錯(cuò)誤，通常就能在代碼中對(duì)其進(jìn)行精確定位，這就是降低了調(diào)試（錯(cuò)誤修改）的成本。 代碼檢查與走查是對(duì)過(guò)去桌面檢查過(guò)程（在提交測(cè)試前由程序員閱讀自己程序的過(guò)程）的改進(jìn)。參加者當(dāng)中只有一個(gè)人是程序編寫(xiě)者。我們認(rèn)為，它們的成功與本書(shū)第2章所述的一些原則有關(guān)。換句話說(shuō)，是測(cè)試，而不是調(diào)試。準(zhǔn)備工作的高潮是在參加者會(huì)議上進(jìn)行的所謂“頭腦風(fēng)暴會(huì)”。 代碼檢查與走查都要求人們組成一個(gè)小組來(lái)閱讀或直觀檢查特定的程序。 代碼檢查與走查 代碼檢查與走查是兩個(gè)主要的人工測(cè)試方法。從內(nèi)部產(chǎn)生的壓力似乎會(huì)急劇增長(zhǎng)，并產(chǎn)生一個(gè)趨勢(shì)，要“盡可能快地修改這個(gè)缺陷”。 首先，人們普遍認(rèn)識(shí)到錯(cuò)誤發(fā)現(xiàn)的越早，改正的成本越底，正確改正的可能性也越大。 在開(kāi)始討論人工測(cè)試技術(shù)之前，有一條重要的注意事項(xiàng)；由于包含了人為因素在內(nèi)，導(dǎo)致很多方法的正規(guī)性要差于由計(jì)算機(jī)執(zhí)行的數(shù)學(xué)證明，人們可能會(huì)懷疑某些如此簡(jiǎn)單和不正規(guī)的東西是否有用。應(yīng)該在程序開(kāi)始編碼之后、基于計(jì)算機(jī)的測(cè)試開(kāi)始之前使用這些方法。 基于這些原因，在深入研究較為傳統(tǒng)的基于計(jì)算機(jī)的測(cè)試技術(shù)之前，我們首先討論非基于計(jì)算機(jī)測(cè)試的過(guò)程（即“人工測(cè)試”）。 今天，并不是所有的軟件測(cè)試人員都要閱讀代碼，但是研讀程序代碼作為測(cè)試工作的一部分，這個(gè)觀念已經(jīng)得到了廣泛的認(rèn)同。第3章代碼檢查、走查與評(píng)審 多年以來(lái)，軟件界的大多數(shù)人多持有一個(gè)想法，即編寫(xiě)程序僅是為了提供給機(jī)器執(zhí)行、并不是提供人們閱讀的，軟件測(cè)試的唯一方法就是在計(jì)算機(jī)上執(zhí)行它。u 一個(gè)好的測(cè)試用例具有較高的發(fā)現(xiàn)某個(gè)尚未發(fā)現(xiàn)的錯(cuò)誤的可能性。本書(shū) 章節(jié)討論的技術(shù)是我們能夠?yàn)槟硞€(gè)軟件設(shè)計(jì)出合理的測(cè)試用例集，然而這些技術(shù)需要大量的創(chuàng)造性。 測(cè)試一個(gè)大型軟件所需要的創(chuàng)造性很可能超過(guò)開(kāi)發(fā)軟件所需要的創(chuàng)造性。這種現(xiàn)象之所以有用，是因?yàn)樗o予了我們對(duì)軟件測(cè)試過(guò)程的洞察或反饋，如果一個(gè)程序的某個(gè)部分遠(yuǎn)比其他部分更容易產(chǎn)生錯(cuò)誤，那么這種現(xiàn)象告訴我們，為了是測(cè)試獲得更大的成效，最好對(duì)這些容易錯(cuò)在錯(cuò)誤的部分進(jìn)行額外的程序。如果模塊A經(jīng)過(guò)的程序并不是故意設(shè)計(jì)得更為嚴(yán)格，那么該原則告訴我們，模塊A與模塊B相比，錯(cuò)在更多錯(cuò)誤的可能性要大。咋看上去，這幅圖似乎沒(méi)有什么意思，但是很多程序都存在這種現(xiàn)象。我們?cè)僖淮沃厣?，所謂測(cè)試，就是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行的過(guò)程原則9：程序某部分存在更多的可能性，與該部分已發(fā)現(xiàn)錯(cuò)誤的數(shù)量成正比。原則8：計(jì)劃測(cè)試工作時(shí)不應(yīng)默許假定不會(huì)發(fā)現(xiàn)錯(cuò)誤。這就意味著，如果對(duì)程序的更改導(dǎo)致了程序某個(gè)先前可以執(zhí)行的部分發(fā)生了故障，這個(gè)故障往往是不會(huì)被發(fā)現(xiàn)的。情況往往是這樣的，由于重新設(shè)計(jì)測(cè)試用例需要投入大量的工作，人們總是避免這樣做。這樣的問(wèn)題在于，飽含我們寶貴投入的測(cè)試用例，還測(cè)試結(jié)束后就消失了。 這個(gè)問(wèn)題在采用交互式系統(tǒng)來(lái)測(cè)試軟件時(shí)最常見(jiàn)。比如，某個(gè)工資管理程序中即便可以生成正確的工資單，但是如果也為非雇員生成工資單或者覆蓋掉了人員文件的以一條記錄，這樣的程序仍然是不正確的程序。這條原則是上調(diào)原則的必然結(jié)果。因此，針對(duì)未預(yù)料到的無(wú)效輸入情況的測(cè)試用例，似乎比針對(duì)有效輸入情況的那些用例更能發(fā)現(xiàn)問(wèn)題。例如，很少有人會(huì)向程序輸入1，2，5以證明程序不會(huì)錯(cuò)誤地將其解釋為一個(gè)不規(guī)則三角形，而不是一個(gè)無(wú)效三角形。在測(cè)試軟件是，有一個(gè)自然的傾向，即將重點(diǎn)集中在有效和預(yù)期的輸入情況上，而忽略了無(wú)效和未預(yù)料到的情況。換言之，在后續(xù)測(cè)試中發(fā)現(xiàn)的錯(cuò)誤，往往是前面的測(cè)試遺漏掉的。這個(gè)原則可能是最顯而易見(jiàn)的原則，但也同樣常常被忽視。當(dāng)然，我們的言下之意是，更經(jīng)濟(jì)的方法是由客觀、獨(dú)立的第三方來(lái)進(jìn)行測(cè)試。即使是合理規(guī)劃和實(shí)施測(cè)試過(guò)程，也可能被認(rèn)為降低了完成進(jìn)度和成本目標(biāo)的可能性，因此， 編程組織難以客觀地測(cè)試自己的軟件。而且在大多數(shù)情況下，主要是根據(jù)其在給定時(shí)間、特定成本范圍內(nèi)開(kāi)發(fā)軟件的能力來(lái)衡量編程組織或項(xiàng)目經(jīng)理。 這里的論據(jù)與前面的論據(jù)相似?！罢{(diào)試”由程序的編寫(xiě)人員來(lái)完成有效得多。當(dāng)然，我們的言下之意是，讓其他人來(lái)測(cè)試程序會(huì)更加有效，也會(huì)更容易測(cè)試成功。如果情況是這樣