【正文】 的循環(huán)中是常見的錯(cuò)誤。我們會(huì)經(jīng)常忘記將“0”作為一次計(jì)數(shù)。舉例來(lái)說(shuō)，如果想編寫一段JAVA代碼執(zhí)行10次循環(huán)，下面的語(yǔ)句是錯(cuò)誤的，因?yàn)樗鼒?zhí)行了11次：For ( int i=0。i=10。i++){ ( i )。}正確的應(yīng)該是執(zhí)行10次循環(huán)：For ( int i = 0 。Ii =9。 i++){ ( i)。} （例如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ù)這些不匹配的情況。？舉例來(lái)說(shuō)，當(dāng)參數(shù)值不為1或2時(shí)，在邏輯上是否假設(shè)了參數(shù)必定為3？如果是這樣的話，這種假設(shè)是否有效？ 接口錯(cuò)誤（parameter）數(shù)量是否等于調(diào)用模塊發(fā)送的參數(shù)（argument）數(shù)量？另外，順序是否正確？（如數(shù)據(jù)類型和大?。┦欠衽c相應(yīng)形參的屬性相匹配？？舉例來(lái)說(shuō)，是否形參以度為單位而實(shí)參以弧度為單位？，是否等于彼此模塊期望的形參數(shù)量？，是否與彼此模塊相應(yīng)形參的屬性相匹配？，是否與彼此相應(yīng)形參的量綱相匹配？，實(shí)參的數(shù)量，屬性，順序是否正確？，是否引用了與當(dāng)前人口點(diǎn)無(wú)關(guān)的形參？下面PL/I程序的第二個(gè)賦值語(yǔ)句就存在這種錯(cuò)誤；A: PROCEDURE( W,X)。 W = X +1。 REJURNB: ENTRY ( Y,Z)。 Y = X+Z。 END。？，所有引用他們額模塊中，它們的定義和屬性是否形同？？在一些用FOTRAN語(yǔ)言編寫的程序中，諸如CALL SUBX (J,3)的語(yǔ)句是很危險(xiǎn)的，因?yàn)槿绻映绦騍UBX對(duì)其第二個(gè)形參進(jìn)行賦值，常數(shù)3的值將會(huì)改變。 輸入/輸出錯(cuò)誤，其屬性是否正確？？（就各項(xiàng)的數(shù)量和屬性而言）？，來(lái)保留程序?qū)⒆x取額文件?？？，并正確處理？？？ 其他檢查，那么對(duì)該列表進(jìn)行檢查，查看是否有變量從未引用過，或僅被引用過一次。，那么對(duì)每個(gè)變量的屬性進(jìn)行檢查，確保沒有賦予過不希望的默認(rèn)屬性值。，但計(jì)算機(jī)提供了一個(gè)或多個(gè)“警告”或“提示”信息，應(yīng)對(duì)此逐一進(jìn)行認(rèn)真檢查。“警告”信息指出編譯器對(duì)程序某些操作的正確性喲所懷疑；所有這些疑問都應(yīng)進(jìn)行檢查?！疤崾尽毙畔⒖赡軙?huì)羅列出沒有聲明的變量，或者是不利于代碼優(yōu)化的用法。？也就是說(shuō)，它是否對(duì)其輸入的合法性進(jìn)行了檢查？？這些檢查列表在表31和表32中進(jìn)行了總結(jié)。表31 代碼檢查錯(cuò)誤列表總結(jié)，第一部分?jǐn)?shù)據(jù)引用錯(cuò)誤運(yùn)算錯(cuò)誤？？？？？？？？？？？？？是否傳遞位串參數(shù)？？？？？10．索引或下標(biāo)操作是否有“僅差一個(gè)”的錯(cuò)誤？？？數(shù)據(jù)聲明錯(cuò)誤比較錯(cuò)誤？？？？？？、類型和存儲(chǔ)類？？？？？》？？表32 代碼檢查錯(cuò)誤列表總結(jié)，第二部分控制流程錯(cuò)誤輸入/輸出錯(cuò)誤？？？？？3．I/O語(yǔ)句是否符合格式規(guī)范？？？？？“僅差一個(gè)”的迭代錯(cuò)誤？？？？？？？接口錯(cuò)誤其他檢查？？？？？“警告”或“提示”信息？？？？？？、屬性、順序是否正確？？？？？ 代碼走查 代碼走查與代碼檢查很相似，都是以小組為單位進(jìn)行代碼閱讀，是一系列規(guī)程和錯(cuò)誤檢查技術(shù)的集合。代碼走查的過程與代碼檢查大體相同，但是規(guī)程稍微有所不同，采用的錯(cuò)誤檢查技術(shù)也不一樣。 就像代碼檢查一樣，代碼走查也是采用持續(xù)以至兩個(gè)小時(shí)的不間斷會(huì)議的形式。代碼走查小組又三至五人組成，其中一個(gè)人扮演類似代碼檢查過程中“協(xié)調(diào)人”的角色，一個(gè)人擔(dān)任秘書（負(fù)責(zé)記錄所有查處的錯(cuò)誤）的角色，還有一個(gè)人擔(dān)任測(cè)試人員。關(guān)于這三到五個(gè)人的組成結(jié)構(gòu)，有各種各樣的建議。當(dāng)然，程序應(yīng)該是其中之一。我們建議另外的參與者應(yīng)該包括：（1）一位極富經(jīng)驗(yàn)的測(cè)試員；（2）一位程序設(shè)計(jì)語(yǔ)言專家；（3）一位程序員新手（可以給出新穎、不帶偏見的觀點(diǎn)）；（4）最終將維護(hù)程序的人員；（5）一位來(lái)自其他不同醒目的人員；（6）一位來(lái)自該軟件編程小組的程序員。 開始的過程與代碼檢查形同：參與者在走查會(huì)議之前的幾天得到材料，他們可以專心鉆研程序。然而走查會(huì)議的規(guī)程則不相同。不同于僅閱讀程序或使用錯(cuò)誤檢查列表，代碼走查的參與者“使用了計(jì)算機(jī)”。被指定為測(cè)試人員的那個(gè)熱鬧會(huì)帶著一些書面的測(cè)試用例（程序或模塊具有代表的輸入集及預(yù)期的輸出集）來(lái)參加會(huì)議。在會(huì)議期間，每個(gè)測(cè)試用例都在人們腦中進(jìn)行推演。也就是說(shuō)，把測(cè)試數(shù)據(jù)沿程序的邏輯結(jié)構(gòu)走一遍。程序的狀態(tài)（如變量的值）記錄在紙或白板上以供監(jiān)視。 當(dāng)然，這些測(cè)試用例必須結(jié)構(gòu)簡(jiǎn)單、數(shù)量較少，因?yàn)槿四X執(zhí)行程序的數(shù)度比計(jì)算機(jī)執(zhí)行程序的數(shù)度慢上若干量級(jí)。因此，這些測(cè)試用例本是并不起到關(guān)鍵的作用；相反，它們的作用是提供了啟動(dòng)代碼走查和質(zhì)疑程序員邏輯思路及其設(shè)想的手段。在大多數(shù)的代碼走查中，很多問題是在向程序員提問的過程中發(fā)現(xiàn)的，而不是有測(cè)試用例本身直接發(fā)現(xiàn)的。 與代碼檢查相同，代碼走查參與者所持的態(tài)度非常關(guān)鍵。提出的建議應(yīng)針對(duì)程序本身，而不應(yīng)對(duì)程序員。換句話說(shuō)，軟件中存在的錯(cuò)誤不應(yīng)該比視為編寫程序人員自身的弱點(diǎn)。相反，這些錯(cuò)誤應(yīng)被看作是伴隨這軟件開發(fā)的艱難性所固定的。 與代碼檢查過程描述的相似，代碼走查應(yīng)有一個(gè)后續(xù)過程。同樣，代碼檢查所帶來(lái)的附帶作用（如可以發(fā)現(xiàn)易出錯(cuò)的程序區(qū)域，通過接觸軟件錯(cuò)誤、編程風(fēng)格和方法來(lái)獲得教育等）同樣也會(huì)發(fā)生在代碼走查過程中。 桌面檢查 人工找錯(cuò)誤的第三中是古老的桌面檢查方法。桌面檢查可視為由單人進(jìn)行的代碼檢查或代碼走查：由一個(gè)人閱讀程序，對(duì)照錯(cuò)誤列表檢查程序，對(duì)程序推演測(cè)試數(shù)據(jù)。 對(duì)于大多數(shù)人而言，桌面檢查的效率是向當(dāng)?shù)椎?。其中的一個(gè)原因是，它是一個(gè)完全沒有約束的過程。另一個(gè)重要的原因是它違反了本書第2章提出的測(cè)試原則，即人們一般不能有效地測(cè)試自己編寫的程序。因此桌面檢查最好由其他人而非該程序的編寫人員來(lái)完成（例如，兩個(gè)程序員可以相互好交換各自的程序，而不是桌面檢查自己的程序）。但是即使這樣，其效果仍然遜色于代碼走查或代碼檢查。原因在于代碼檢查和代碼走查小組中存在著互相促進(jìn)的效應(yīng)。小組會(huì)議培養(yǎng)了良性競(jìng)爭(zhēng)的氣氛，人們喜歡通過發(fā)現(xiàn)問題來(lái)展示自己的能力。而在桌面檢查中，由于沒有其他人可提供展示，也就缺乏這個(gè)顯而易見的良好的效應(yīng)。簡(jiǎn)而言之，桌面檢查勝過沒有檢查，但其效果遠(yuǎn)遠(yuǎn)遜色于代碼走查和代碼走查。 同行評(píng)分 最后一種人工評(píng)審方法與程序并無(wú)關(guān)系（其目的不是未來(lái)發(fā)現(xiàn)錯(cuò)誤），卻仍在這里談到，這是因?yàn)樗c代碼閱讀的思想有關(guān)。同行評(píng)分是一種依據(jù)程序整體質(zhì)量、可維護(hù)性、可擴(kuò)展性、易用性和清晰性對(duì)匿名程序進(jìn)行評(píng)價(jià)的技術(shù)。該項(xiàng)目技術(shù)的目的是為程序員提供自我評(píng)價(jià)的手段。選出一位程序員來(lái)?yè)?dān)任這個(gè)評(píng)分過程的管理，管理員又會(huì)挑選出大約6~20名參與者（為保持匿名性，6人是最少數(shù)量）。這些參與者都應(yīng)具備相似的背景（例如，不能把JAVA應(yīng)用程序員與匯編語(yǔ)言系統(tǒng)程序員編為一組）。要求每名參與者都挑選出連個(gè)由自己編寫的程序以供評(píng)審。其中的一個(gè)程序應(yīng)是參與者自認(rèn)為能代表其自身能力的最好作品，而另一個(gè)則是參與者自認(rèn)為質(zhì)量較差的作品。當(dāng)所有的程序都收集完畢后，就將這些程序隨機(jī)分發(fā)給參與者。每個(gè)參與者拿到4個(gè)程序進(jìn)行評(píng)審，其中兩耳是“最好”的程序，另外兩個(gè)是相對(duì)“較差”的程序，但評(píng)審人自己并不知道。每名參與者每評(píng)審一個(gè)程序得花費(fèi)30分鐘，評(píng)審?fù)旰筇顚懸粡堅(jiān)u價(jià)表。所有4個(gè)程序評(píng)審?fù)旰螅瑓⑴c者對(duì)4個(gè)程序的相對(duì)質(zhì)量進(jìn)行分級(jí)。評(píng)審表要求評(píng)審人從1~7的分值（1代表明確的“是”，7代表明確的“否”），對(duì)諸如下面的問題進(jìn)行回答：u 程序是否易于理解？u 高層次的設(shè)計(jì)是否可見且合理？u 底層次的設(shè)計(jì)是否可見且合理？u 修改此程序?qū)υu(píng)審者而言是否容易？u 評(píng)審者是否會(huì)以編寫出該程序而驕傲？u 還要求評(píng)審人給出總的評(píng)審和建議的改進(jìn)意見。評(píng)審結(jié)束之后，參與者會(huì)收到自己的那兩個(gè)程序的匿名評(píng)價(jià)表，此外還會(huì)收到一個(gè)帶統(tǒng)計(jì)的總結(jié)，說(shuō)明所有的程序中其程序的整體和具體得分，以及他對(duì)其他程序的評(píng)價(jià)與其他評(píng)審人對(duì)同一程序打分的比較分析情況。同行評(píng)分的目的，是讓程序員對(duì)自己的編程技術(shù)進(jìn)行自我評(píng)價(jià)。同樣，該過程適合用于企業(yè)開發(fā)和課堂教學(xué)環(huán)境。 本章節(jié)討論了軟件開發(fā)人員通常不會(huì)考慮到的一種測(cè)試形式—人工測(cè)試。大多數(shù)人都認(rèn)為，因?yàn)槌绦蚴菫榱颂峁C(jī)器執(zhí)行而編寫的，那么也應(yīng)該由機(jī)器來(lái)對(duì)程序進(jìn)行測(cè)試。這種想法是有問題的。人工測(cè)試方法在暴露錯(cuò)誤方面是很有成效額。實(shí)際上，大多數(shù)的軟件項(xiàng)目都應(yīng)該得到一下的人工測(cè)試方法：u 利用錯(cuò)誤列表進(jìn)行代碼檢查。u 小組代碼走查。u 桌面檢查。u 同行評(píng)審。附件二：外文原文The Art of Software TestingCHAPTER 1 A SelfAssessment Test Since this book was first published 25 years ago, software testing has bee both easier and more difficult than ever.Software testing is more difficult because of the vast array of programming languages, operating systems, and hardware platforms that have evolved. And, while relatively few people used puters in the 1970s, today virtually anyone in business or education could hardly plete a day’s work without using a puter. Furthermore, the machines themselves are hundreds of times more powerful than those early devices.Therefore, the software we write today potentially touches millions of people, enabling them to do their jobs effectively and efficiently— or causing them untold frustration and the cost of lost work or lost business. This is not to say that software is more important today than it was when the first edition of this book was published, but it is safe to say that puters—and the software that drives them—certainly affect more people and more businesses today.Software testing is easier, in some ways, because the array of software and operating systems is much more sophisticated than ever, providing intrinsic welltested routines that can be incorporated into applications without the need for a programmer to develop them from scratch. Graphical user interfaces (GUIs), for example, can be built from a development language’s libraries, and, since they are preprogrammed objects that have been debugged and tested previously, the need for testing them as part of a custom application is much reduced.Software testing is a process, or a series of processes, designed to make sure puter code does what it was designed to do and that it 1 does not do anything unintended. Software should be predictable and consistent, offering no surprises to users. In this book we will look at many approaches to achieving this goal.Now, before we start the book, we’d like you to take a short exam.We want you to write a set of test cases—specific sets of data—to properly test a relatively simple program. Create a set of test data for the program—data the program must handle correctly to be con