軟件測試之針對詳細設計（Detail Design）的同行評審

        軟件測試之針對詳細設計（Detail Design）的同行評審  軟件測試

        在軟件開發過程中，當某個模塊詳細設計文檔（Detail Design）完成后，軟件開發人員會按照詳設文檔的設計要求進行代碼開發，而軟件測試人員會按照詳設文檔的要求進行測試用例設計。因此，詳細設計的內容是否完善、有無重大缺陷；軟件開發、測試人員是否正確深入的了解了詳細設計的內容和設計思路，都直接關系到該模塊的開發進度和產品質量。
        那么怎樣才能夠完善模塊的詳細設計，并讓開發、測試人員正確的貫徹設計人員的設計思路呢？針對詳設級別的同行評審可以有效地解決這個問題。
        針對詳設的同行評審，其主要目的是檢查和確認詳細設計中的缺陷，以便在模塊開發周期中的早期階段清除設計方面的缺陷。就缺陷修復的成本而言，在代碼開發工作開始之前就清除設計方面的缺陷，其所付出的成本是較低的。而且這個檢查和確認的過程，對評審的參與人員而言，也有助于他們了解參評的模塊。
        那么，當我們確定對詳細設計進行同行評審時，其主要參與者都應該是哪些角色呢？
        試問，在一個軟件項目團隊中，除了詳計文檔的設計人員之外，還有誰對詳細設計質量擁有發言權呢？有人可能會說是詳細設計的Reviewer（檢閱人員）。誠然，詳細設計的Reviewer往往是團隊中比較有經驗的“牛人”級角色，也有可能是詳設人員的直屬Leader。從技術角度上講，他們對于模塊的詳細設計是有發言權的，能夠對詳細設計得框架進行把關，但是由于角色、職責、精力等方面的限定，他們往往不會對其審查的詳設文檔進行仔細的分析、走查。其審查往往只能做到走馬觀花式的宏觀把握，而對于細節問題往往予以忽略。
        在很多大型項目中，模塊的劃分數量很多，要進行評審的詳設文檔更如煙海。要同行評審中，如果能有Reviewer級別的人物參加，當然最好。但是基于時間和效率方面考慮，讓Reviewer參加每一次詳設評審，是很難做到的。他們往往只參加一些重要級別模塊詳設的同行評審。
        其實，對于一份詳細設計文檔質量優劣，感受最深的往往是工作在詳細設計層下游的軟件開發、測試人員。他們的工作，直接依照詳細設計進行，詳細設計文檔的質量直接影響到他們實際的工作效率和產品質量。他們在日常工作中，對于詳設文檔，往往是逐字逐句的斟酌揣摩，對于文檔中的一些細節問題尤為敏感。
        因此，各模塊的開發、測試人員應該參與自己所負責模塊的詳設評審，并根據自己的工作職責和需要，對詳細設計提出相應的修改意見。開發、測試人員的加入，不但可以使模塊的詳細設計更加貼進于實際的開發工作，同時也可以讓參與同行評審的開發、測試人員明確是設計者的意圖，確定自己要開發的或要測試的是什么樣的軟件。
        但是由于專業知識得限制，一些初級的開發和測試人員往往難以對能夠對詳細設計中的一些復雜的設計問題，提出實質性的改進意見。因此如果條件允許，還有必要邀請一兩位有經驗的專家，參與評審。
        除了保證詳細設計質量外，同行評審可以給設計、開發、測試人員提供一個跨部門的橫向交流機會；同時也可以從“設計”、“開發”、“測試”等不同的角度來對整個模塊設計的合理性提供意見；相關人員匯聚到一起進行同行評審，通過相互溝通，較好的了解模塊的相關背景知識，避免了日后繁瑣的交流，減少了“因為對項目設計思路的理解不一致，而產生錯誤”的可能性。
        在實際操作中，由開發和測試人員參與的詳細設計同行評審，可以以“走讀”為主；在技術實力較強的情況下，也可以進行“技術評審”。所謂“走讀”，其主要是對文檔進行檢查，通過走讀發現文檔中存在的缺陷（可能包括邏輯矛盾、描述模糊和文法錯誤等），同時參與人員也可以進行技術交流，初級人員也可以學習一些技術方面的知識，了解設計者的思路。而“技術評審”是一個相對正式的評審過程，其在規格、標準等方面進行評審，并在評審后給出相應得修改意見。
        理論上，一些模塊構架級別的東西，應該在概要設計階段就已經的得到了解決。我們在評審時，不需要在框架問題上多花功夫。但是在實際操作中，一些構架方面的東西往往到編碼的后期還在不停的修改。因此，在進行概要設計評審時，設計者應該做好改變甚至推翻模塊原有框架的心理準備。
        詳細設計的評審，應該提前制定相應得計劃，并做好充分的準備，制定評審的入口準則和相關規程，確定評審時間，安排相關組織者和與會人員，準備所需材料等。
        同行評審由專門的組織者主持，并有作者和相關同行出席。其規模不宜過大，大致可以控制在七人以下。在會議過程中，可以先由作者對其詳細設計進行講解，引導大家進行走讀。然后參與者們共同對詳細設計進行評審，確認問題，并對其進行分類。
        一般情況下，同行評審可以被控制在兩個小時之內。一些簡單的模塊，可以把同行評審壓縮到一個小時之內。在評審過程中，如果遇到問題需要延時，可以由作者決定是否召開“第三小時會議”。
        評審結束后，有必要對評審問題進行跟蹤，以便確認確陷的到了修改，并且沒有引入新的缺陷。

原文轉自：http://www.anti-gravitydesign.com