嚴(yán)格來說，不能算是讀書筆記，只能說是閱讀的快速翻譯，加一些個(gè)人理解。
我推崇通過通讀經(jīng)典的原著，可以幫我們找到最具有歷史痕跡的概念，厘清思路！而不是看那些被人消化反復(fù)咀嚼再吐出來的書籍！
這個(gè)文章里。個(gè)人理解的表達(dá)用下劃線表達(dá)?，翻譯有疑問的地方用斜體字表達(dá)
?------------------------------------------------------------------------------
第三章 ??程序評(píng)審、走查和復(fù)查
人工測(cè)試的方法在典型的程序中一般可以發(fā)現(xiàn)30%-70%的邏輯設(shè)計(jì)和代碼的錯(cuò)誤。但是這種方法不能檢測(cè)出高層設(shè)計(jì)錯(cuò)誤，例如出現(xiàn)在需求分析階段的錯(cuò)誤。我們注意到成功的比率是30%-70%，也就是說在找到的錯(cuò)誤中不超過70%?；仡櫟诙轮兴枋龅模覀儫o法知道程序中全部的錯(cuò)誤。因此，這說明這種方法可以有效的在測(cè)試過程發(fā)現(xiàn)超過已知缺陷的70%。
當(dāng)然，一個(gè)更嚴(yán)苛的統(tǒng)計(jì)是人工的過程只能發(fā)現(xiàn)“簡(jiǎn)單的”錯(cuò)誤（那些可以在基于計(jì)算機(jī)的測(cè)試中所發(fā)現(xiàn)的）和那些困難的、晦澀的或隱藏的錯(cuò)誤只可能通過計(jì)算機(jī)的執(zhí)行過程所發(fā)現(xiàn)。然而，一些測(cè)試者使用這些技術(shù)發(fā)現(xiàn)，人工過程趨向于比基于計(jì)算的過程在某些類型的錯(cuò)誤的發(fā)現(xiàn)上更有效，那些相反對(duì)于另一種類型的錯(cuò)誤來說是真實(shí)的。（例如：未初始化變量，對(duì)應(yīng)于被0除）。
human testing ?methods ?相當(dāng)于靜態(tài)測(cè)試，computer?-based testing 相當(dāng)于動(dòng)態(tài)測(cè)試
評(píng)審/走查和基于計(jì)算機(jī)的測(cè)試是互為補(bǔ)充的，其中一個(gè)未出現(xiàn)，則難以保證有效的錯(cuò)誤檢測(cè)。
最后，雖然這些過程對(duì)測(cè)試新程序是?非常有價(jià)值的，與程序修正是同等重要或者會(huì)更重要。我們的經(jīng)驗(yàn)是，修改現(xiàn)存的程序相比寫新的程序，可能導(dǎo)致更多錯(cuò)誤的過程（每多一個(gè)聲明就可能有一批的錯(cuò)誤）。因此，程序修正后，需要再經(jīng)歷被測(cè)試的過程，也就是回歸測(cè)試技術(shù)。
代碼審查?
?代碼審查是一套團(tuán)隊(duì)閱讀代碼的錯(cuò)誤檢測(cè)技術(shù)的規(guī)程。關(guān)于代碼審查焦點(diǎn)的大多數(shù)爭(zhēng)論是在程序上，填寫表格等等。這里，做一個(gè)通用過程的簡(jiǎn)短的闡述，我們將著重介紹事實(shí)上的錯(cuò)誤檢測(cè)技術(shù)。
評(píng)審團(tuán)隊(duì)
?一般一個(gè)評(píng)審團(tuán)隊(duì)由4個(gè)人組成。一個(gè)是主持人的角色，在這里相當(dāng)于質(zhì)量控制工程師。這個(gè)主持人希望是一名有能力的程序員，但是他或者她不是代碼編寫者，并且不熟悉程序的細(xì)節(jié)。主持人的職責(zé)包括：
1、?分發(fā)評(píng)審會(huì)議的材料、安排進(jìn)度；
2、主持會(huì)議；
3、記錄所有被發(fā)現(xiàn)的缺陷；
?4、確保所有的缺陷，在會(huì)后被更正。
?第二個(gè)成員是程序員本人。其他的會(huì)議成員一般是程序設(shè)計(jì)者（如果與程序員不同的話），還有一個(gè)測(cè)試專家。測(cè)試專家應(yīng)該精通軟件測(cè)試，并熟悉大多數(shù)一般的程序缺陷，也就是我們?cè)诤竺嬉懻摰降摹?/p>
評(píng)審議程?
開評(píng)審會(huì)議的之前幾天，主持人分發(fā)程序清單、設(shè)計(jì)規(guī)格說明文檔給其他參與者。參與者期望讓他們自己對(duì)會(huì)議的材料更熟悉。在會(huì)議期間，會(huì)有兩個(gè)活動(dòng)：
1、對(duì)于程序論述、聲明、程序邏輯結(jié)構(gòu)等，在討論期間，其他參與者應(yīng)提出那些用于追蹤是否有缺陷的問題。這有點(diǎn)像程序員而不是其他團(tuán)隊(duì)的成員，在敘述中將發(fā)現(xiàn)許多錯(cuò)誤的定義。換句話說，簡(jiǎn)單的對(duì)著觀眾大聲讀出程序的行為，就是顯然有效的錯(cuò)誤檢測(cè)技術(shù)。
2、程序分析遵循檢查表（Checklists），這張表是從歷史上通用的程序錯(cuò)誤中總結(jié)出來的。（這份檢查表將會(huì)在下一次的評(píng)審會(huì)議中討論）
主持人負(fù)責(zé)確認(rèn)討論進(jìn)程沿著產(chǎn)品的線索，參與者將他們的關(guān)注點(diǎn)放在發(fā)現(xiàn)缺陷上，而不是訂正它們。（程序員在評(píng)審會(huì)議結(jié)束后修正缺陷）
在評(píng)審過程中通常集中在發(fā)現(xiàn)缺陷而不是修改缺陷。有時(shí)候，一些2-3個(gè)人的團(tuán)隊(duì)當(dāng)發(fā)現(xiàn)小問題時(shí)，包括負(fù)責(zé)代碼的程序員，可能打算設(shè)計(jì)改變來處理這樣特殊的案例，對(duì)于小問題的討論，可能會(huì)變成全組將注意力特別地放在設(shè)計(jì)的領(lǐng)域。在討論期間最好的方法是區(qū)別開設(shè)計(jì)和處理這個(gè)小問題，因?yàn)橛行┤丝赡軙?huì)關(guān)注后者。關(guān)于設(shè)計(jì)方面，團(tuán)隊(duì)還有兩個(gè)問題，每幾個(gè)句子就可能評(píng)論頻頻。幾分鐘的時(shí)間，設(shè)計(jì)整個(gè)領(lǐng)域會(huì)被完全探索到，任何一個(gè)問題都會(huì)顯而易見。
評(píng)審會(huì)議的時(shí)間和地點(diǎn)應(yīng)該選擇避免被打擾。最佳的時(shí)間長(zhǎng)短是90-120分鐘，會(huì)議是智力耗費(fèi)的實(shí)踐，長(zhǎng)時(shí)間的會(huì)議反而效率降低。大多數(shù)評(píng)審會(huì)議的速度一般是每小時(shí)150個(gè)代碼行。基于此原因，大型程序?qū)?huì)跨越多個(gè)評(píng)審會(huì)議，每個(gè)會(huì)議處理一個(gè)或多個(gè)模塊或子程序。
人員議程
為讓評(píng)審會(huì)議更有效，測(cè)試團(tuán)隊(duì)必須采取恰當(dāng)?shù)膽B(tài)度。例如，如果一個(gè)程序員的認(rèn)為評(píng)審會(huì)議是對(duì)他或她的個(gè)人攻擊，而采取對(duì)抗的態(tài)度，那么會(huì)議將是不會(huì)效果的。正確的做法是，程序員必須把撇開自我本位的態(tài)度，而采取積極和建設(shè)性的態(tài)度，保持注意力在客觀的評(píng)審而發(fā)現(xiàn)程序的錯(cuò)誤，這樣才能提高工作質(zhì)量。正因?yàn)槿绱?，大多?shù)人建議對(duì)評(píng)審結(jié)果保密，而只與參與者共享。尤其是，如果管理者需要利用評(píng)審結(jié)果（例如，為明確或暗示程序員的低效率或低能力），那么就與檢查過程的目的背道而馳了。
評(píng)審過程的好處
除了評(píng)審的主要作用是發(fā)現(xiàn)缺陷外，評(píng)審還有其他的好處。第一，程序員通常接收關(guān)于編程風(fēng)格的，算法選擇和編程技術(shù)的有價(jià)值的反饋。第二，其他參與者通過查看程序，接觸到程序員的錯(cuò)誤和編程風(fēng)格，同樣受益。通常，這種類型的軟件測(cè)試幫助提高團(tuán)隊(duì)的凝聚力。減少對(duì)抗關(guān)系的潛在演變的可能，而更利于合作關(guān)系，以項(xiàng)目為核心可以引導(dǎo)更多有效而可靠的開發(fā)模式。
最后，評(píng)審過程是一種早期發(fā)現(xiàn)錯(cuò)誤傾向部分的方法，可以幫助確定在基于計(jì)算機(jī)測(cè)試階段的測(cè)試方向。（這就是我們說的第二章說的第9個(gè)測(cè)試準(zhǔn)則）
