開始學習微軟的缺陷管理方法(6)

　　邏輯設計：把概念設計的表達(概念元素及其關系)，映射成程序世界能夠接受的邏輯表達;側重體系結構的創建。

　　描述設計組織的解決方案及其元素間通訊，給出解決方案的初步視圖;基于前一階段的成果-場景，設計對象與服務，用戶界面原型，以及邏輯數據庫。

　　物理設計：設計的實現，同樣不用編程語言表示;精確定義元素及其交互接口，進行數據庫物理設計，提供用戶界面規格說明;重點在于編寫各對象/模塊/構件的規范說明，接口和關鍵的算法描述。

　　一種基于服務的方法，將解決方案映射到分布的單元上，考慮實現的技術約束與性能問題。

　　2) 提交成果

　　功能規范：

　　產品及其特性集的詳細描述;為客戶與項目組間契約，也是制定主計劃和主進度表的基礎。

　　內容包括：前景概述，設計目標，產品需求(優先需求與沖突平衡)，用戶概述，特性，產品依賴性(高層依賴為外部系統，底層依賴為共享構件)，進度描述，風險，附錄(設計過程的輸出)。

　　項目主計劃：匯總各分計劃，說明產品如何構造;包括：開發計劃，測試計劃，培訓計劃，用戶支持計劃，市場宣傳計劃，部署計劃等。

　　項目主進度表：同項目主計劃一一對應

　　主風險評估文檔：提供項目風險整體視圖，導出高層決策和工作的優先級。

　　3 Developping Phrase

　　Code Review: 提高代碼質量，加快開發進度(節約了測試與維護時間)，提供培訓開發者的方法，增強代碼的可維護性。

　　Daily Build：隔離缺陷，減少集成風險;較早發現缺陷;保持對項目進度的監控。

　　4 Stablizing Phrase 產品測試，項目總結評審

　　property: 表示對象狀態的數據集;attribute：不是早期面向對象數據集統稱的屬性，而是說明對象性質與方法的metadata，特別是共享對象。

　　構件：一個應用邏輯單元，提供一組只能通過已發布的接口或契約，來訪問的服務集合;從程序角度，構件即共享的類對象。

　　接口：構件與外界的界面，方法的簡要規格說明，包括方法類型，方法名及參數表;是對構件中提供的服務的引用端口。

　　契約：一種特殊接口，對象間商定的相對固定的接口。如：構件P為了實現服務C，要求對象Q為它提供服務E，接口E即 PQ間的契約。接口類也是一種契約，規定該做什麼，而構件實現怎麼做。

　　RPC為底層的交互標準，可用來調用遠程動態鏈接庫;DCOM正是在RPC技術上構建的。 TCP/IP協議套接字組成了另一種供構件在網絡上交互的底層協議。

　　遠程數據對象RDO (Remote Data Object)，數據訪問對象DAO (Data Access Object)，及開放數據庫連接 ODBC (Open Data Base Connection)，為構件用來與數據庫交互的三種數據訪問技術。ODBC 性能最好，其次是 RDO和 DAO;而DAO 提供了豐富的編程接口，易于使用，其次才為RDO 與ODBC。

　　微軟測試階段

　　planning: test manager 寫test plan,關于資源，測試目標;

　　coding：制定詳盡的測試用例，放入database;CC要實現產品的最基本功能，推出一個可測試的版本!

　　fix bug: 從cc到release進行多次測試迭代;產品的specification在此階段，也不斷動態更新;

　　alpha，beta：進入beta測試階段，UI被freezed，不能修改; 寫幫助文檔的啟動工作;

　　release candidate: RC階段不允許提交代碼，遇到非改不可的bug則推出下一個RC;針對每一個，對應一次完成的測試過程;

　　release：此版本的尚存的bug應是可以容忍

　　bug court 由test manager ，developer manager，requirement manager 三人裁決;specification 由designer制定;　detail design由程序員完成，并提交詳細設計報告;一般而言，此報告比較簡單，關鍵還要看代碼;代碼的注釋通常清晰詳盡。

　　BVT, stress, full test pass, adhoc test, bug regress, risk areas, change role test

　　MS的BVT測試自動化進行，驗證底層的service or driver，覆蓋到每一個build;此類測試用在界面上GUI方面，結果不太可靠。

　　full test pass：比較消耗時間，一般在一個里程碑處才進行;full test pass, bug regress在項目后期，bug較少時進行才有意義。

　　change role: 當一個RC測試時間較長時，如兩周，為了保證對bug的敏感度，可考慮人員交換模塊測試;但一個release內仍以專人負責制定部分為主。

　　測試報告字段

　　Title，Severity，Priority，Reproduce Steps，Assigned To，Status(active, resolved,closed)，attachment，link to previous bug(Bugs in database are not allowed to be deleted)，Test enviroment，Build No.，Areas(modular)，Reasons(filled by developer)

　　不可復現的bug不能添入數據庫;因為不知造成問題的真正原因，無從查起!

　　測試經理提交每周發現的，解決的，及每個成員bug統計的周報;并繪制趨勢曲線圖，展示bug發現與解決的相對速率。

　　工作分配的再調整，依據團隊發現bug的統計規律;個人績效評估很大程度上依據發現的bug數量。

原文轉自：http://www.kjueaiud.com