最佳軟體測驗基礎入門教程4靜態測驗

靜態測驗

對作業產品（檔案和代碼）進行靜態測驗和分析，對提高產品質量有很大的幫助，本章介紹了靜態測驗的一般情況，以及所涉及的具體程序，包括其活動和必須填補的角色，我們描述了四種經過驗證的技術和它們的具體優勢，以及在應用它們時確保成功的因素，最后，我們比較了靜態和動態測驗技術，

• 被低估的技術

靜態測驗（或 "靜態分析"）可以在基于工具的環境中進行，也可以手動進行，是一種經常被忽視的測驗技術，動態測驗的測驗物件（見第5章）是使用測驗資料運行的可執行程式，而靜態測驗可以在任何一種與產品開發有關的作業產品上進行，靜態測驗可以采取由一個或多個人進行仔細檢查的形式（見第4.3節），也可以使用適當的分析工具進行（見第7.1.3節），

• 一切都是為了預防

靜態測驗的基本概念是預防，在進一步的開發程序中，錯誤和其他偏離計劃的情況被識別出來，以免產生負面影響，所有相關的作業產品在任何人做任何進一步的作業之前都是有質量保證的，這可以防止有問題的臨時作業產品進入開發流程，并在以后造成昂貴的故障，
靜態測驗可以在各種情況下進行（見下文），而且通常是開發程序中的一個組成部分（即在計劃階段就提供測驗資源），例如，在航空和醫藥等對安全要求很高的行業，靜態分析是確保所需產品質量的一個極其重要的因素，

參考資料

• 本文涉及的python測驗開發庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• 英文原版下載：Software Testing Foundations, 5th - 2021.pdf (訪問密碼: 訂閱號pythontesting 發送 密碼) https://url97.ctfile.com/f/18113597-853966551-6ed72c

4.1我們可以分析和測驗什么？

• 一種通用的技術

除了代碼本身，軟體開發也會產生很多其他的作業產品，大多數檔案在產品的進一步發展中起著某種作用，因此每個檔案的質量都是整個結果質量的重要因素，
可以用靜態分析（尤其是審查，見下文）來檢查的作業產品包括規范、業務需求、功能和非功能需求以及安全需求，規范的錯誤需要在轉化為代碼之前被發現，在敏捷專案中，史詩和用戶故事要進行靜態測驗，靜態分析揭示的缺陷種類包括不一致、含糊不清、矛盾、差距、不準確和冗余，

在軟體設計程序中，架構和設計規范（如類圖）被創建，可以像程式代碼一樣進行靜態測驗，構成網站的代碼也可以通過這種方式進行測驗（例如，自動驗證鏈接和其相應的目標網站），代碼可以被檢查是否與專案的編程指南一致，
一般來說，靜態測驗可以驗證在被分析的檔案中是否遵守了任何預定的標準，
此外，最好是檢查和驗證所有在測驗期間創建的檔案、定義和工具（如測驗計劃、測驗用例、測驗程式和腳本、驗收標準），其他可以通過靜態測驗驗證的檔案和作業產品包括合同、專案計劃、時間表、預算和用戶手冊，
此外，靜態測驗的結果也可以用來改進整個開發程序，如果某些種類的缺陷在特定的開發步驟中反復出現，這就表明這個步驟需要調查，如果有必要，可以進行優化，這種程序通常伴隨著額外的人員培訓，

4.2靜態測驗技術

• 人的精神和分析能力

人的精神和分析技能可以用來通過對有關檔案的密切調查來分析和評估復雜的情況，對這種分析的成功至關重要的是，有關人員要理解他們正在閱讀的檔案，并理解其中的陳述和定義，靜態測驗通常是檢查檔案和其他作業產品語意的唯一有效方法，

它們是各種靜態測驗技術，在其徹底性、所需資源（即人和時間）以及所追求的目標方面都有所不同，一些常見的靜態測驗技術詳見下文，使用的術語是基于ISTQB?大綱和ISO 20246，

• "審查"（Review）有多種含義

最常見和最重要的靜態測驗技術是審查，在這種情況下，"審查"一詞有多種含義，它被用來描述作業產品的靜態分析，但也被用來作為由人類執行的所有靜態分析技術的一般術語，術語 "檢查"（inspection）也被用來描述類似的程序，盡管它經常被用來指根據預定的規則正式執行靜態測驗（以及收集指標和資料），
不同的審查程序

審查可以非正式地或正式地進行，非正式的審查不遵守預先定義的程序，對預期結果或記錄的內容沒有明確的定義，相反，正式的評審程序（見第4.3.1節）是預先定義的，參與者（見第4.3.3節）記錄一組計劃的結果，
你選擇的審查程序的型別將取決于以下因素：
開發生命周期模型： 你在使用哪個模型？模型中的哪些地方和中期結果適合于進行評審？
開發程序的成熟度： 程序有多成熟，要檢查的檔案的質量有多高？
要檢驗的檔案的復雜性： 哪些產出顯示出高度的復雜性，因此適合進行（正式）審查？
法律或法規要求和/或可追溯的審計跟蹤的必要性： 哪些法規必須遵守，哪些質量保證的證明（也就是審查）是必須的？

• 不同的目標

評審的預期目標也決定了你選擇哪種型別的評審程序（見4.4節），你是關注缺陷檢測還是關注被測驗作業產品的一般可理解性？新的團隊成員是否必須通過評審來熟悉某個特定的檔案？評審是否有助于團隊達成一致決定？你所進行的評審的型別將取決于你對這些問題的回答，

4.3 評審程序

• 評審活動

審查作業產品的程序包括計劃、開始、參與者（專家、審查員、檢查員）的準備、溝通和分析結果、糾錯和報告（，
影像

4.3.1審查程序活動

• 規劃

定義你的目標并選擇審查的型別

在計劃階段，管理層--或者更準確的說，專案管理部門--必須決定哪些檔案（或檔案的一部分）需要接受哪種型別的評審（見4.4節），這個決定會影響到必須擔任的角色（見第4.3.3節）、必要的活動，如果需要，還會影響到檢查表的使用，你還需要決定評估哪些質量特性，也要計劃每次評審的估計作業量和時間范圍，專案經理選擇一個由適當技能的參與者組成的團隊，并給他們分配角色，專案經理還必須與評審物件的作者檢查他們是否處于可評審的狀態，即他們至少已經達到了部分結論，并且盡可能的完整，
正式的審查需要預定的進入和退出標準，如果計劃包括進入標準，你需要在進行審查之前檢查這些標準是否已經實作，

• 不同的觀點會增加有效性

從不同的角度檢查檔案，或讓個人檢查檔案的特定方面，可以提高審查程序的有效性，這些觀點和/或方面必須在計劃階段確定，
你不一定要審查整個檔案，選擇包含高風險缺陷的部分，或能夠使你對整個檔案的質量得出結論的樣本部分，往往是有意義的，
如果你想舉行預審會議，你需要決定何時何地舉行，

評審程序的開始（或 "啟動"）是向參與者提供所有必要的實物和電子材料的時刻，這可以是簡單的書面邀請，也可以是一個審查前的會議，會上討論審查的重要性、目的和目標，如果參與者還不熟悉評審物件的環境，也可以用啟動儀式來簡要說明評審物件如何適合其應用領域，

• 基準檔案

除了要審查的作業產品外，審查參與者還需要其他材料，這些材料包括任何有助于決定他們正在看的東西是一個偏差、一個錯誤/缺陷，還是一個正確的陳述的檔案，這些是檢查審查物件的基礎（例如，用例、設計檔案、指南和標準），這些檔案通常被稱為 "基線"，額外的測驗標準（也許是以檢查表的形式）有助于結構化程式，如果你使用表格來記錄你的發現，這些需要在程式開始時分發，
如果你正在進行正式的審查，你需要檢查進入標準是否已被滿足，如果不符合，應該取消審查，這樣可以節省時間，否則就會浪費在審查 "不成熟 "的作業產品上，

• 研究審查物件

只有當所有參與者都準備充分時，審查才會成功，所以審查小組的每個成員都要為審查做個別準備，
審查員（或 "檢查員"）以提供的檔案為基準，對審查物件進行嚴格審查，任何潛在的缺陷、建議、問題或評論都會被記錄下來，
個人準備可以采取多種形式，關于這些的更多細節，見4.3.2節，

• 整理你的發現

在個人準備之后，對發現進行整理和討論，這可以在審查會議上進行，也可以在公司內部的在線論壇上進行，對團隊成員發現的潛在偏差和缺陷進行討論和分析，你還必須定義誰負責糾正所發現的缺陷，如何監控糾正進度（見6.4.4節），并確定是否需要或有必要對固定的檔案進行后續評審，
在計劃期間，要確定所調查的質量特性，對每個特性進行評估，并將分析結果記錄下來，
然后，評審組要提供關于接受評審物件的建議：
接受，不作修改或稍作修改
由于廣泛的變化，有必要進行修訂
不接受
附注：對審查會議的建議

如果舉行審查會議，盡量遵守以下建議：
將會議時間限制在兩小時內，如果有必要進一步討論，最早在第二天舉行后續會議，
如果一個或多個審查員缺席，或雖出席但準備不足，主持人（見下文）有權取消或暫停會議，
討論的物件是作業成果，而不是其作者：
評審員需要注意他們的措辭，
不能要求作者為自己或其作品辯護，然而，對他的決定進行辯解可能是有用的，
主持人也不能成為評審員，
不能討論審查標準中沒有涉及的一般風格問題，
制定和討論潛在的解決方案不是評審組的作業（見下文對該規則的例外），
每個審查員都必須有足夠的機會陳述她的結論
評審員應努力達成并記錄共識
研究結果不應該被表述為對作者的糾錯指示，然而，對審查物件的糾正或改進的建議可以幫助提高產品質量，
個別結論應被歸類為：
關鍵（審查物件不適合其預期的目的，缺陷必須在發布前得到糾正），
主要缺陷（物件的可用性是有限的，在發布前必須糾正缺陷）
輕微缺陷（與計劃略有偏差--例如，印刷中的語法錯誤，不影響使用）
良好（沒有缺陷，在修訂程序中不改變），
糾正和報告

• 糾正缺陷

審查程序中的最后一項活動是報告你的發現并糾正審查中發現的任何缺陷或不一致之處，評審會議的記錄通常包含了所有需要的資訊，因此對于需要修改評審物件的缺陷，不需要單獨的報告，一般來說，作者會糾正審查所揭示的任何缺陷，
除了寫報告，你發現的任何缺陷也可以直接與負責人或團隊溝通，然而，這涉及到良好的人際關系技巧，因為沒有人真正喜歡談論自己的錯誤（見2.4節），

• 正式審查涉及更多的作業

在正式評審中，你需要記錄一個缺陷或其報告的當前狀態（見第6.4.4節），只有在負責的評審員同意的情況下，才可以改變缺陷的狀態，您還需要檢查指定的退出標準是否已經完成，

評估正式審查會議的結果將幫助你改進審查程序，并使相應的準則和檢查表保持更新，這需要收集和評估適當的指標，
評審的結果因評審的型別和涉及的正式程度而有很大的不同（見4.4節），下面幾節將詳細介紹審查程序的不同方法，并繼續討論正式審查中涉及的角色和責任，

4.3.2 不同的個人審查技術

• 整理你的發現

基本審查程序通常要求每個參與者為團隊審查做準備，有各種個人審查技術，有助于揭示缺陷，這些技術可以應用于所有型別的評審（見第4.4節），盡管它們的效果會根據你所進行的評審型別而有所不同，下面的章節描述了各種單獨的審查技術，

• 沒有規則

顧名思義，這種技術不涉及關于個人準備的預定義規則，評審員通常按順序閱讀作業產品，并記錄發現的任何問題、發現或缺陷，檔案的型別也是任意的，因為它們只需要很少（或沒有）的準備，所以臨時性的審查相當頻繁，而且因為沒有涉及規則，結果在很大程度上取決于個別審查員的技能，如果一個審查物件由一個以上的人審查，一些問題肯定會被標記多次，
基于檢查表的審查

• 使用檢查表

使用檢查表是一個很好的方法來組織你的閱讀，從而提高個人審查的有效性，你可以定義哪些檢查表是由哪些審查員使用的，檢查包含基于在早期專案程序中發現的潛在缺陷的問題清單，這些問題也可以基于需要遵守的正式準則或標準，如下面的例子所示，

案例研究： 使用檢查表

審查需求檔案的檢查表：
檔案的結構是標準化的嗎？
是否有關于如何使用該檔案的解釋（即解釋性介紹）？
需求檔案中是否包括專案摘要？
是否有詞匯表以幫助一致的理解？
...
我們的例子顯示了一個審查需求檔案的檢查表，但檢查表可以被制定來幫助審查任何型別的作業產品（例如，代碼審查），檢查表必須定期更新，以包括新認識到的問題，并洗掉與過期或已解決的問題有關的問題，檢查表一般應保持簡短，只包括關鍵問題，
基于檢查表的技術的主要好處是它系統地涵蓋了所有典型的缺陷型別，這種技術的潛在缺點是，它傾向于將審查 "集中 "在特定的問題上，從而降低了發現與所列問題無關的缺陷的可能性，在使用這種技術時，要始終保持開放的心態，
使用場景和試運行7

• Use case演練

基于場景的審查是基于預定義的、結構化的指導方針，規定了如何貫穿審查物件，特定用例的可用性簡化了這種型別的審查，因為你所要做的就是對所有的用例進行 "干運行"，例如，在我們的VSR-II案例研究中，我們可以檢查所有的 "配置車輛 "和 "選擇特別版 "案例是否被正確實作（也見5.1.6節），
在代碼審查的情況下，這種情況也可以基于缺陷的類別，例如，審查員可以專注于代碼中的錯誤處理，而另一個則專注于檢查邊界的遵守情況，情景幫助審查員發現特定型別的缺陷，通常比簡單地通過問題清單作業更有效，
然而，完全使用場景會使識別其他型別的缺陷（如缺失的屬性）更加困難，如果可能的話應該避免，

• 不同的角色和觀點

在基于角色的評審中，評審員的任務是從專家的角度來檢查評審物件，要做到這一點，評審員必須已經在專家角色中作業，或者至少對其有強烈的同情心，基于角色的審查的基本思想是利用每個角色提供的技能，當然，扮演某個角色的人必須有適當的技能，例如，讓測驗人員審查需求總是有用的，因為他們可以在開發程序的早期檢查需求是否有足夠精確的定義，以便有效地從需求中得出測驗條件和測驗案例，

• 利用專家技能

其他典型的審查角色是利益相關者，如終端用戶或客戶組織內的系統操作者，如果最終用戶或系統的操作者不能參加審查會議（通常是這種情況），這些角色必須由其他人來扮演，終端用戶 "的角色可以進一步細化，取決于這個人是 "有經驗 "還是 "無經驗"，如果該系統要在組織內使用，審查員可以扮演系統或用戶管理員的角色，

案例研究： 基于角色的審查

一份需求檔案要進行基于角色的審查，在審查程序中，Joe Smith被指派為設計師的角色，理想情況下，Joe知道軟體系統的設計，并將在現實世界的專案中履行這個角色，Joe分析了需求，看看為了使需求得到充分的實作，對系統的結構需要做哪些改變，Jane Brown是一名測驗員，在審查中采用這一角色，在審查程序中，她將檢查是否有可能毫不含糊地決定（在實施和測驗之后）每個需求已經得到滿足，簡將 "系統將實作快速操作 "的要求標記為沒有充分的量化，沒有可以測量的數字，也沒有先決條件或約束條件來確定在什么情況下時間可以被認為是充分的，其他的角色也需要被填補，以便進一步仔細檢查這些要求，

• 不同的觀點

所有可用的角色都指向不同的缺陷、不一致的地方和差距，基于角色的評審員承擔了不同利益相關者的觀點，從而檢查了系統的不同方面，利益相關者本身的（通常是主觀的）觀點也需要被納入到評審中，下面的例子說明了在我們的案例研究專案中，對下一次迭代的日程安排審查存在不同的利益，

案例研究： 基于觀點的審查

銷售部門的觀點說，一個特定的需求在需求檔案中需要高優先級，因為這個功能是一個重要客戶要求的，需要盡快實施，從測驗人員的角度來看，這個功能與其他已經實施的功能非常相似，所以在實施和測驗中不應該有任何嚴重的問題，因此，她建議及時實施這個新功能，

然而，從測驗的角度來看，另一個新功能更為關鍵，因為它是這個專案中第一個實作人工智能（AI）的功能，到目前為止，團隊在這個領域還沒有經驗，因此，測驗人員假設這個功能需要大量的實施和測驗作業，所以需要為它分配更多的資源，
基于視角的審查的基本原則是，每個審查員從不同的視角看審查物件，并因此而運行不同的場景，然后，審查結果不僅可以用來評估有關檔案，還可以用來估計任何需要修改的緊迫性和范圍，要做到這一點，每個評審員都要通過不同的情景，并使用結果來評估所調查的檔案，利用不同的利益相關者的觀點可以增加每個人的審查深度，而且角色的分配可以減少缺陷和其他問題的重復命名，使用檢查表也是提高這種審查有效性的好方法，
經驗性研究認為基于觀點的審查是檢查需求和技術描述的最有效的方法，其成功的關鍵之一是在分析和評估風險時，包含了許多利益相關者的觀點，

4.3.3 審查程序中的角色和責任

在討論審查的一般原則時，已經大致描述了審查程序中涉及的角色和責任，下面的章節將更詳細地介紹典型的正式審查中的角色和責任，
并非每個角色都必須由一個人擔任，有些角色之間的重疊可以證明由一個人擔任多個角色是合理的（例如，主持人和審查負責人），然而，哪些角色可以合并取決于專案的性質和你需要實作的質量標準，與各個角色相關的個別活動也因你所進行的評審型別而不同（見4.4節），

• 管理

管理層選擇哪些作業產品和支持材料將被納入審查，以及哪種型別的審查將被進行，管理層還負責計劃審查和分配所需資源（人員、時間、資金），并需要關注成本效益，如果審查的結果不是結論性的，管理層就需要介入并做出控制性的決定，

管理團隊的成員如果也是審查物件的作者的老板，就不應該參加審查會議，因為這涉及到對作者而不是他的作業的隱性評價，會限制審查話語的自由，還有一種情況是，管理層沒有適當的IT技能來有效參與技術審查會議，當然，對于專案計劃會議和其他由管理層領導的任務來說，情況并非如此，在這些會議上，專案和一般管理技能是至關重要的，

• 評審組長

評審組長承擔著總體責任，因此需要確保計劃、準備、執行、修改和任何后續作業都有助于實作評審目標，審查負責人決定誰參與審查，以及審查的時間和地點，

• 主持人

主持人（通常也被稱為主持人）的作業是確保評審會議的順利進行，審查會議的成功往往取決于主持人的主持和外交技巧，他或她必須善于匯集反對的觀點，并在不傷害任何人的感情的情況下保持討論的簡短，此外，還需要有一定程度的自信和察覺談話中的暗語的能力，主持人不能有先入為主的想法，也不能對審查物件有個人看法，要負責收集任何結果的指標，并確保寫出會議報告，

• 作者

這里的作者是指評審物件的作者，如果有多個作者，其中一個在評審會議期間承擔唯一作者的角色，作者確保條目標準得到滿足，換句話說，審查物件處于 "可審查 "狀態，通常情況下，作者負責糾正審查期間發現的任何缺陷，因此也負責滿足退出標準，作者決不能把對作業的批評當作個人行為，審查程序只是為了提高審查物件的質量，

• 評審員

評審員（有時也被稱為 "檢查員"）是由最多五名專家組成的小組，他們在做了適當的準備后參加評審，評審員通常是其作業被評審的專案組的一部分，但也可以是對結果有興趣的其他利益相關者或具有專業和/或技術能力的人，
評審員的任務是識別和描述評審物件中存在問題的地方，擁有不同視角的評審員（測驗人員、開發人員、最終用戶、系統操作人員、商業分析師、可用性專家等等）有助于評審的有效性，盡管你要確保只有那些與評審物件相關的專家參與其中，
讓個別評審員專注于評審的特定方面，可以提高評審程序的效率，例如，一個審查員可以專注于對某一特定標準的遵守，而另一個則檢查程式的語法，這種角色的分配是在審查計劃階段進行的，
評審員必須明確區分評審物件中通過評審的部分和需要改進的部分，缺陷必須被清楚地記錄下來，以便于識別和解決，

• 記錄員

抄寫員（或稱 "記錄員"）記錄未解決的問題、未解決的問題，以及審查中產生的任何其他相關任務，該檔案必須簡短而精確，并且必須包括所有發生的討論的不失真的總結，
隨著專用工具變得越來越普遍，審查記錄員的作業正在慢慢變得過時，如果使用了這樣的工具，每個評審員都可以直接在工具界面上記錄缺陷、開放性問題和決定，而不需要單獨的檔案，

由于實際原因，作者往往也是抄寫員，作者通常清楚地知道什么是需要記錄的，以便執行評審員所要求的修改，

4.4審查的型別

題外話：管理評審

在查看審閱物件時，可以發現兩種審閱型別：

• 對開發程序中作為作業產品創建的檔案的評審
• 對專案或開發程序本身進行分析的評審

第二組的審查被稱為 "管理"、"專案 "或 "程序 "審查，它們的目的包括調查規章制度和計劃是否得到遵守，分析所需任務的執行情況，以及對程序所做改變的有效性，

• 審查物件是整個專案，主要的審查目標是確定其目前的技術和經濟狀況，以及檢查其是否按計劃進行，以及專案管理的情況如何

• 管理評審通常在專案達到某個特定的規劃里程碑、完成某個開發階段時進行，或者作為支持未來專案學習程序的 "死后 "分析，

• 在敏捷專案中，這種審查通常采取 "回顧性 "會議的形式，這些會議通常在每個沖刺階段之后舉行，使團隊能夠比較筆記并收集關于如何在下一個沖刺階段改進作業的想法，

• 主要目的是識別缺陷

下面將詳細介紹第一種型別的審查，其主要目的是通過調查檔案來識別缺陷，你執行的審查型別取決于專案的性質、可用的資源、審查物件的型別、潛在的風險、業務領域、公司文化和其他標準，
審查可以是非正式的審查，走訪，技術審查，或檢查，所有這些都可以作為 "同行審查 "進行--換句話說，在公司層次結構中，有相同或相似層次的同事參與，
審查物件可以使用一種以上的審查方式進行審查，例如，非正式審查可以用來驗證審查物件是否處于適合后續技術審查的狀態，以及所需的努力是否合理，

• 非正式審查-沒有嚴格的準則

非正式審查是一種 "軟 "審查，它仍然遵循標準審查程序（見第4.3節），但沒有嚴格的正式結構，非正式評審的主要目的是識別缺陷，并向評審物件的作者提供短期反饋，它也可以用來發展新的想法，并對現有問題提出解決方案，小問題也可以在非正式評審中得到解決，

• 作者/讀者反饋周期

非正式審查通常是由作者發起的，計劃階段包括選擇參與者和確定交付結果的日期，非正式評審的成功在很大程度上取決于評審員的技能和動機，可以使用核對表，但非正式評審通常不需要單獨的會議來討論結果，在這種情況下，非正式評審實際上只是一個簡單的作者/讀者反饋回圈，

因此，非正式審查是由一個或多個同事對審查物件進行簡單的雙重檢查--"伙伴檢查"，學習效果和團隊成員之間的互動是受歡迎的副作用，就結果而言，一份發現的問題清單或審查物件的更正/評論副本通常就足夠了，諸如 "結對編程"、"伙伴測驗 "和 "代碼交換 "等技術也可以被視為非正式評審的一種，由于非正式評審易于組織，且涉及的作業相對較少，因此被廣泛用于各種專案中，而不僅僅是在敏捷環境中，
演練

• 走讀

除了識別缺陷之外，走讀還可以用來檢查是否符合所需的標準和專案規范，這也是一個討論替代性實施方案的論壇，而且還可以就程式或風格的變化交換意見，從而促進參與者的學習，走讀的結果應該是一種共識，
走讀的重點是一個通常由作者領導的會議，結果需要被記錄下來，但并不真正需要準備一份正式的記錄或總結報告，檢查表的使用也是可選的，與技術審查或檢查相比，涉及的個人準備作業很少，演練可以在完全沒有準備的情況下進行，
在會議期間，典型的使用場景被命名，并以程序為導向的方式進行演練，程式部分的模擬或測驗運行（所謂的 "干運行"）也是可能的，個別測驗案例也可以模擬，評審員將參與者提出的意見和問題作為識別潛在缺陷的基礎，
作者負責做任何需要的修改，通常不涉及進一步的監督，

這種技術適用于五人以下的小團隊，幾乎不需要準備和跟進，它非常適合于檢查非關鍵物件，在實踐中，演練的范圍從極其非正式到相當正式，

因為作者通常會帶領大家走一遍，所以你必須注意審查物件還是要批判性地、公正地進行審查，否則，作者的潛在偏見可能導致對關鍵問題的討論不足，從而扭曲了結果，

• 技術審查：歡迎其他建議

除了識別缺陷外，技術審查的主要重點是形成共識，其他目標包括評估產品質量和建立對審查物件的信心，
在技術評審中，歡迎新的想法和替代實施的建議，技術問題可以由專家來解決，為了充分發揮這種討論的作用，作者在相同或密切相關的技術領域作業的同事應該作為評審員參與，此外，讓其他領域的專家參與進來，可以幫助防止團隊對自己的習慣視而不見，
個人的準備作業在技術評審中至關重要，也可以使用檢查表，如果可能的話，審查會議應該由受過訓練的審查主持人領導，但不是由作者領導，審稿人之間的討論不能失控，應該堅持就作者今后可以做什么來改進他的作業達成共識，會議不是必須的，討論可以在其他論壇上進行，例如在公司的內部網上，
審查的結果需要記錄，但不是由作者記錄，通常情況下，要準備一份潛在缺陷的描述清單和一份總結性的審查報告，
技術審查也可以采取多種形式，從完全非正式的到嚴格組織的，每個步驟都有預定的進入和退出標準，并強制使用報告模板，

如果評審員事先將他們各自的評審結果提交給會議主持人，這有助于將評審會議的重點放在最重要的地方，然后，主持人可以對這些意見進行優先排序，并利用會議討論最重要的要點和最明顯的分歧意見，
技術審查的結果是所有參與者的責任，如果你在會議期間不能達成共識，你可以舉行投票來解決討論，并將結果記錄在評審報告中，
技術審查的參與者沒有責任考慮他們提出的建議的后果，這是由管理層負責的，

• 檢查（Inspection）正式的預定流程

檢查是最正式的審查型別，遵循嚴格的預定流程，所有參與者都是專案專家或審查物件其他方面的專家，每個人都在審查中采取特定的角色，評審程序受規則的制約，這些規則為流程的每個方面定義了檢查標準，每個檢測步驟都有自己的進入和退出標準，
檢查的目標是識別缺陷和不一致，確定檢查物件的質量，以及建立對作業產品的信心，在這里，達成共識也是程序的一個重要部分，檢查的結果應該幫助作者在未來避免類似的錯誤，并且像技術審查一樣，幫助提高未來作業的質量，
另一個目標是改進軟體開發程序（見下文），檢查的目標在計劃階段就已經確定，審查員需要解決的問題數量從一開始就受到限制，
在檢查開始前，檢查物件會被正式檢查為 "可審查性"，并被驗證是否達到了準入標準，審查員的個人準備是根據預定的規則或標準使用檢查表進行的，

• 抽樣檢查會議

抽樣檢查會議可以按以下方式進行： 會議由訓練有素的主持人（不是作者）主持，他介紹參與者和他們的角色，并對要檢查的主題進行簡要總結，主持人詢問所有審查員是否有足夠的準備（例如，確保所有的檢查表問題都已回答），主持人也可以問審查員花了多少時間，他們發現了多少缺陷，
首先討論并記錄影響整個物件的一般不一致之處，
然后，審查員對檢查物件的內容進行簡明而有邏輯的介紹，如果有必要，可以宣讀部分材料（但不是由作者宣讀），這時其他審查員可以提出問題，并且可以詳細討論物件的選定方面，作者（不能是評審組長、主持人或抄寫員）回答任何直接問題，如果審查員和作者不能就如何處理某個問題達成一致，在會議結束時進行表決，

如果討論偏離主題，則由主持人進行干預，主持人還必須確保涵蓋檢查物件（和一般物件）的所有選定方面，并明確記錄所有缺陷和不一致之處，
在會議結束時，所有的缺陷都會被提出來，并由所有參與者檢查是否完整，對任何未解決的問題進行簡要討論，但不討論可能的解決方案建議，如果對未解決的問題是否代表缺陷沒有達成共識，這種差異將記錄在報告中，最后的報告總結了檢查的所有結果，并提供了所有潛在缺陷的描述清單，
最后，對檢查進行評估，并決定檢查物件是否需要更多的作業，在檢查程序中，所做的任何改變和后續作業都是正式的規范，

• 對開發和審查程序的額外評價

檢查程序中收集的一些資料也可以用來確定開發程序中的薄榷訓節的原因，從而提高其質量，這些資料也可用于改進檢查程序本身，兩個程序質量的任何改善都可以通過比較任何改變前后收集的資料來驗證，

這種型別的審查通常被稱為設計、代碼或軟體檢查，這個名字是基于被檢查的檔案的型別，然而，如果存在正式的審查標準，所有型別的檔案都可以被檢查，

• 選擇審查的型別

什么時候以及使用什么型別的檢查取決于你所追求的目標，所要求的質量，以及這將花費的精力，專案環境對這些決定也很關鍵，不可能做出具體的建議，你必須根據不同的專案來決定哪種審查方式最適合當前的情況，下面的問題將幫助你決定進行哪種型別的審查：
審查結果的形式可能是一個因素，你需要一個全面的報告，還是一個沒有記錄的執行結果就足夠了？
安排時間是容易還是困難？找到一個五位、六位或七位專家都有時間的日期可能是很難的作業，
審查是否需要來自多個學科的專家？
評審員需要對評審物件有多少具體的了解？
評審員有多大的動力花時間和精力集中在計劃的評審上？
計劃的努力與預期的結果是否相稱？
審查物件有多正式？基于工具的分析能否在審查前進行？
你有多大的管理支持？如果時間緊迫，審查是否可能被限制甚至被砍掉？

4.5關鍵因素、好處和限制

• 提高質量和降低成本

審查是保證被調查的作業產品的質量的有效工具，理想情況下，審查將在作業產品定稿后立即進行，這樣，任何不一致或缺陷都能及時發現，作者也能盡快得到反饋，解決任何問題都會使有關檔案的質量得到提高，從而對開發程序產生有利的影響，這樣就可以在減少缺陷的牽引下繼續進行開發，此外，靜態測驗經常會發現一些使用動態測驗很難（或不可能）發現的缺陷（見4.6節），
通過審查早期識別和糾正缺陷，通常比后來在應用程式已經達到可執行的開發階段時解決缺陷要便宜，當一個應用程式的早期版本已經交付或已經在使用時，這一點尤其正確，
靜態測驗通常比動態測驗便宜（見第5章），因為缺陷可以直接在檔案中得到糾正，不再需要進一步檢查，糾正動態測驗中出現的故障一般需要額外的確認或回歸測驗，評審往往可以節省大量的開發時間，
然而，說審查會減少成本并不總是準確的，例如，如果靜態測驗發現了記憶體泄漏，補救這個問題可能是非常耗時的，在這里，你需要區分進行審查的成本和糾正審查發現的缺陷的成本，糾正檔案中的文字的成本是可以忽略不計的，換句話說，修正的努力取決于需要注意的問題的性質，
如果代碼審查已經消除了測驗物件（即代碼）中的缺陷，并且由于審查而減少了發現進一步缺陷的風險，那么動態測驗可能會涉及更少的努力，
在經過審查和糾正的檔案中，減少缺陷和不一致的數量，也會減少審查期間的成本，

在審查和糾正的檔案中，減少缺陷和不一致的數量也會在系統的生命周期中減少成本，例如，審查可以揭示出客戶需求中的不準確之處，這些問題可以在實施前得到解決，審查也會導致系統運行時發生的故障數量減少，此外，開發程序中的生產力也會提高，因為團隊將使用改進的設計和代碼，更容易維護（即，理解和改變），

• 改善團隊溝通

除了提高質量和降低成本，審查對開發團隊內部的合作也有積極影響：
因為審查總是在小組環境中進行，它們鼓勵參與者之間的知識交流，這導致了個人作業方法的改進，從而使他們的作業質量得到普遍提高，
在小組環境中，必須以所有參與者都能理解的方式展示材料，這種清晰的需求往往會產生作者本來不會有的洞察力，
整個團隊都覺得對審查物件的質量負責，結果是每個人都能理解的檔案，
為了提高審查質量，或者說首先要有一個成功的審查，需要考慮各種組織和人員方面的因素，下面的章節列出了其中最重要的因素，
組織的成功因素

• 組織因素

專案管理部門通過在整個開發程序中為評審提供足夠的資源來支持評審程序，
正式的評審是提前計劃好的，并以明確的、可核實的目標來組織，
參與者有足夠的時間為審查做準備，
原則上，所有型別的審查（例如，基于檢查表或基于角色）都適合于識別審查物件的缺陷，可以根據商定的目標、被調查物件的型別和水平以及參與者的技能來選擇最合適的型別，
檢查表涵蓋了最重要的風險，并且總是最新的，
大規模的檔案是分部分而不是整體來審查的，這樣可以盡快向作者提供缺陷反饋，

• 與人有關的因素

你需要選擇 "正確的 "參與者來達到你計劃的評審目標，選擇那些技能和觀點意味著他們需要理解評審物件以便繼續作業的人，是最有成效的，因為評審物件通常會被用作設計測驗用例的基礎，讓測驗人員參加評審是有意義的，這樣，測驗人員從開發程序的一開始就熟悉了專案檔案，可以馬上開始指定測驗用例，這種基于測驗的觀點也有助于質量保證的其他方面，如驗證一個物件的可測驗性，
評審的作用是保證被調查物件的質量，所以對缺陷、不準確和偏離計劃的識別是有意的，應該鼓勵，然而，審查人員必須以客觀、公正的方式傳達他們的發現，審查必須在信任、保密的氣氛中進行，參與者應避免使用表示厭煩、沮喪或敵視其他參與者的手勢，作者要確信審查的結果不會影響他在公司的地位，作者應該把審查看作是一個積極的經歷，所有參與者最后都應該覺得參加審查是花了很多時間的，
參與者花時間專注于細節，審查是為了讓參與者不至于失去注意力，不要試圖一次性審查大型檔案，并提前限制審查會議的長度，
如果有必要，在審查前為參與者提供額外的培訓，特別是對于像檢查這樣的正式審查，
盡量鼓勵學習氣氛，使每個人都能從每次審查中受益，這也能提高審查程序和個人審查技術的質量，

• 為什么審查有時會失敗

如果審查因準備不足而失敗，這通常是由于時間安排不當造成的
如果評審員不理解評審的意義或評審程序對質量改進的有效性，你可以用當前專案（或早期專案）的數字來強調評審程序的重要性
審查會因為檔案不充分或不完整而失敗，在審查物件的同時，你必須確保所有的支持性檔案都有必要的細節深度，只有在這種情況下，審查才應該進行，

靜態測驗和動態測驗的區別

• 識別不同型別的缺陷

靜態測驗和動態測驗可以用來實作相同的目標（見第2.1.2節），但通過識別不同型別的缺陷來相互補充，靜態測驗直接識別檔案和其他作業產品中的故障，而動態測驗通常識別源代碼中的故障，而不是其他型別的檔案（可執行模型除外），你發現的任何故障，如果要成功解決，就必須追溯到導致這些故障的故障，故障往往在很長一段時間內沒有被發現，例如，如果相應的代碼只是很少被執行，因此，它需要大量的努力來設計適當的測驗用例，源代碼中的這些型別的故障通常更容易用靜態測驗來識別，

-檢查 "內部 "質量

動態測驗驗證了測驗物件的可見的、外部的行為，而靜態測驗的重點是提高被調查物件的內部質量，
通過審查發現的典型缺陷

下面幾節詳細介紹了典型的缺陷和不準確之處，這些缺陷和不準確之處可以通過評審快速而廉價地識別出來，因此也可以快速解決：
需求缺陷
在需求檔案中發現的典型缺陷是：不一致、含糊不清、矛盾、差距、不準確或冗余，
軟體設計缺陷
在指定系統內部介面的架構檔案中發現的缺陷，當單個組件或模塊之間的依賴（或 "耦合"）程度很高時，就很難完全理解和測驗它們，這主要是因為創建相應的測驗環境所花費的精力與結果的重要性不相稱，組件/模塊之間的內聚力也可以被分析，強一致性的組件負責單一的、明確定義的任務，
執行松散的任務選擇的組件表示低內聚力，這和高程度的耦合一樣是不利的，設計效率低下的演算法和資料庫結構也可以被識別，
編碼缺陷
如果你有足夠的時間和適當的技術人員，所有的編程缺陷都可以通過代碼審查來識別，這使你能夠發現沒有價值的變數或從未被呼叫的多余的變數，你也可以用審查來檢測不可達的或重復的代碼，這些型別的缺陷也可以通過編譯器或使用自動靜態分析工具來檢測，這通常比基于人的技術更快、更便宜，
對標準的偏離
標準和準則有助于實作高質量的產品，而對編程準則的不充分遵守則會導致相反的結果，即：質量差，如果清楚地知道對某些準則的遵守將被檢查，那么從一開始就堅持這些準則的動力就大得多，
錯誤的介面規范
組件之間的介面名稱和它們的引數（數量、資料型別和順序）必須單獨檢查，因為不是所有的差異都會在集成程序中發現，
例如： 不正確的介面定義

NASA的火星探測器 "火星氣候軌道器 "是著名的、有據可查的、不正確的介面定義的例子[URL: Mars Climate Orbiter]，系統程式員使用了多種測量系統（公制和英制），這一疏忽導致了探測器的損失，正式的代碼審查可能會發現測量系統規范中的這種不一致，
安全漏洞
除了動態安全測驗外，靜態測驗也可以幫助發現這些型別的漏洞，例如，當緩沖區溢位發生時，因為約束條件沒有被明確檢查，或者輸入資料或SQL查詢被故意操縱時，
測驗基礎的可追溯性或覆寫率的差距或不準確之處
我們在2.3.8節討論了可追溯性和覆寫程度的重要性，可追溯性中的差距使可追溯性本身變得毫無用處，因為你不能再在需求和相應的測驗用例之間建立聯系，在退出標準和所需的覆寫程度方面的不準確也使這些方面無法使用，并可能導致不正確的估計或扭曲的結果，例如，審查報告可以指出已完成的退出標準的缺失測驗，

• 可維護性

軟體系統通常有驚人的長生命周期，使可維護性成為任何系統的重要方面，大多數可維護性的缺陷可以通過靜態測驗來識別，這些缺陷包括不正確的模塊化（見上面的耦合和內聚），單個組件的不良重用性，以及難以修改的復雜代碼，因此在修改時增加了產生新故障的風險，

4.7總結

• 每個作業產品（即每個檔案）都可以被審查，只要所有參與審查的人都知道如何閱讀和理解有關的檔案，
• 評審是靜態測驗，與動態測驗不同，不需要執行代碼，這意味著評審可以在任何時候適用于軟體開發程序中使用的或由軟體開發程序中創造的所有形式的作業產品，
• 多雙眼睛比單雙眼睛看到的東西更多，這一點同樣適用于軟體開發，用于監控和提高質量的審查就是基于這一原則，檔案由一個以上的人檢查，并在專門的會議上討論和記錄結果，
• 評審程序中涉及的活動有：計劃、啟動、個人準備（即個人評審）、討論結果（問題交流和分析，通常在專門的會議上）、修復和報告，
• 為了在個別審查階段更好地識別缺陷，你可以使用各種不同的審查技術：
  • 臨時性的
  • 無規則
  • 基于檢查表：預先制定的問題支持審查程序
  • 場景和模擬運行：場景的運行
  • 基于角色：參與者在審查中采用特定的角色
  • 基于觀點：對評審物件的不同看法
• 需要為審查分配的角色有經理、審查負責人、促進者（主持人）、作者、審查員（專家）和抄寫員，
• 評審的型別有很多，由于相關的標準沒有使用統一的術語，所以用來描述它們的名稱也會有所不同，在本章中，我們討論了以下四種審查型別：
  • 非正式審查不遵循任何正式的規則，所產生的檔案的形式也沒有規定，因為它涉及的作業相對較少，所以非正式審查程序已經成為一種廣泛接受和使用的技術，
  • 走讀是一種非正式的技術，即作者在會議上向評審員介紹檔案，在這里，準備作業也是最少的，走讀是小型開發團隊的理想選擇，他們需要討論替代方案并在團隊中分配知識，
  • 技術審查遵循更嚴格的流程，個別審查員的準備作業是必不可少的，評審員應該是作者的專業同事，這樣可以討論替代方案的實作，
  • 檢查是這些型別的審查中最正式的，準備作業以檢查表為基礎，每個審查步驟都有自己的進入和退出標準，審查會議由經過培訓的主持人主持，除了檢查作業產品的質量外，檢查的目的是改善開發和審查程序，
• 為了使其盡可能有效，審查一般是根據公司的具體要求進行的，最重要的因素之一是在軟體開發程序中的所有參與者之間建立一種合作氛圍，
• 如果你牢記適當的組織和與人相關的成功因素，只要你注意避免已知的陷阱，審查可以成為提高軟體開發專案質量的一個嚴肅有效的工具，
• 評審通常會發現與動態測驗不同的缺陷，

標籤：其他

上一篇：GPT大語言模型Alpaca-lora本地化部署實踐【大語言模型實踐一】

下一篇：返回列表