【正文】 ?產(chǎn)品規(guī)格復(fù)閱 ?制訂測試計劃 產(chǎn)品周期：測試人員 產(chǎn)品規(guī)劃階段 ?產(chǎn)品規(guī)格復(fù)閱 ?制訂測試計劃 產(chǎn)品周期：測試人員 產(chǎn)品開發(fā)階段 ?測試軟件的開發(fā) ?測試過程的自動化 ?個人 /朋友版的測試 ?綜合 /驗錯測試 產(chǎn)品規(guī)劃階段 ?產(chǎn)品規(guī)格復(fù)閱 ?制訂測試計劃 產(chǎn)品周期：測試人員 產(chǎn)品開發(fā)階段 ?測試軟件的開發(fā) ?測試過程的自動化 ?個人 /朋友版的測試 ?綜合 /驗錯測試 產(chǎn)品測試階段 ?多次全面運行開發(fā)的測試軟件 （ full test pass) ?壓力測試（ stress test) ?發(fā)布標(biāo)準(zhǔn)測試 ?糾錯結(jié)果驗證測試 產(chǎn)品規(guī)劃階段 ?產(chǎn)品規(guī)格復(fù)閱 ?制訂測試計劃 產(chǎn)品周期：測試人員 產(chǎn)品開發(fā)階段 ?測試軟件的開發(fā) ?測試過程的自動化 ?個人 /朋友版的測試 ?綜合 /驗錯測試 產(chǎn)品測試階段 ?多次全面運行開發(fā)的測試軟件 （ full test pass) ?壓力測試（ stress test) ?發(fā)布標(biāo)準(zhǔn)測試 ?糾錯結(jié)果驗證測試 產(chǎn)品發(fā)布 ?最后產(chǎn)品金碟版測試 測試人員 挑戰(zhàn) ? 與開發(fā)人員保持最佳溝通 ? 國際范圍的測試 ? 測試軟件的互用性 ? 各組成部分的共享 ? 人員的流動 測試人員 測試方面的其他議題 ? 測試案例（ test case) ? 測試腳本（ test script) ? 版本驗證測試（ BTV） ? Bug status ? Regression bug ? 驗證錯誤已被改正，并在 bug數(shù)據(jù)庫中關(guān)閉此bug ? Raid數(shù)據(jù)庫 測試人員 要避免 ? 記錄過多不可再現(xiàn)的錯誤 ? 在早期籌備階段不進行有效的測試，直到產(chǎn)品開發(fā)后期才發(fā)現(xiàn)大量的嚴重錯誤 ? 不做完全地驗證就關(guān)閉 bugs ? Resolve bugs as fixed in Raid database 測試人員 — 回答你的問題？ 微軟軟件開發(fā)寫真 微軟怎么開發(fā)出世界一流的軟件的 … ? 100%以 bug數(shù)據(jù)庫為基礎(chǔ) ? 產(chǎn)品技術(shù)支持部門的反饋 ? 產(chǎn)品規(guī)格的完成（規(guī)格修改委員會） ? 完成視覺效果的設(shè)計 ? 源程序樹的鎖定（ lockdown source tree) ? 源程序樹的分叉（ fork source tree) ? 產(chǎn)品編碼完成 ? 先嘗其果（ eat your own dog food) 微軟軟件開發(fā)寫真 微軟怎么開發(fā)出世界一流的軟件的 … ? 可用性測試研究 ? 對于大型產(chǎn)品，按產(chǎn)品單元組景象源程序代碼更新和穩(wěn)定是有效且必要的方法 ? 戰(zhàn)斗組 (War team) ? 戰(zhàn)斗會議 (War meeting) ? Component team bug triage 微軟軟件開發(fā)寫真 微軟怎么開發(fā)出世界一流的軟件的 … ? 零錯出現(xiàn) ? 金主碟 ? Signoff ? Shipping parties ? Lake Bill dump ? Launch parties/events and news watching ? “ shipit” reward and shipping gifts ? It is so much fun working for Microsoft!Hope you too have a lot of fun 作軟件這行真好玩！ 回答你的問題？ 微軟產(chǎn)品開發(fā)方法 日程 ? 微軟產(chǎn)品周期模型中的開發(fā)者 規(guī)劃及撰寫產(chǎn)品說明書階段 里程碑 0 功能實現(xiàn)階段 里程碑 1到 N 測試和穩(wěn)定階段 代碼完成（ CC）和發(fā)布產(chǎn)品 ? 微軟開發(fā)協(xié)作模式 源代碼控制 工具 Bug跟蹤和解決 ? 開發(fā)人員應(yīng)有的態(tài)度 里程碑 0 規(guī)劃及撰寫產(chǎn)品說明書 微軟產(chǎn)品周期模型中的 開發(fā)者 微軟產(chǎn)品周期模型 編程開始 遠景目標(biāo)確定 QFE DCR 主金碟 市場 Beta版 技術(shù) Beta版 零 Bug反彈 點 (ZBB) 里程碑目標(biāo)達到 M1MN MO 計劃 代碼完成 Beta RC RTM SPs 開發(fā)人員在 M0階段的工作 ? 支持前一個版本 ? 幫助程序經(jīng)理撰寫產(chǎn)品說明書 支持前一個版本 ? QFE（ Quick Fix Engineering) ? DCR(Design Change Request) ? SP1,SP2.. ? 修正被推遲的 Bug 幫助程序經(jīng)理撰寫產(chǎn)品說明書 ? 為 PM寫產(chǎn)品 說明書提供支持 ? 審閱 Spec ? 估計功能實現(xiàn)時間，確定進度 制訂計劃 ? 預(yù)測什么時候可以完成什么功能 ? 協(xié)調(diào)各開發(fā)組，功能和里程碑 ? 決定做哪些功能，不做哪些功能 ? 激勵 沒有截止日期，什么事兒都做不了 ? 計劃是一種估計，更是一種承諾 ? 開發(fā)者做主來制訂計劃 什么是好計劃 ? 把大的計劃分成小塊 每塊半天到 5天（如 WBS方法） ? 什么事情都有時間限制 開發(fā)，測試，調(diào)試，代碼審校 … ? 如果計劃好的東西完成了，整個功能就應(yīng)該完成了（沒有不在計劃中的內(nèi)容） 制訂更合理的計劃 ? 不斷對比 比較最初的估計和實際時間有助于制訂現(xiàn)實的計劃 ? 多個開發(fā)人員獨立估算，把結(jié)果合并 進度控制 — 容易忽略的因素 ? 新人的上手時間 ? 準(zhǔn)備做演示的資源 ? 開會和講座的時間 ? 維護運行編譯的腳本 ? 編譯中斷的修正時間 ? 外部組件的集成 ? 處理測試的問題 ? 病假 /休假 考慮具體技術(shù)實現(xiàn) ? 計劃角色，工具和流程 ? 設(shè)計新功能的實現(xiàn)方法 建立原形 ? 考察新技術(shù) 考慮的第一個問題 — 代碼重用 ? 絕大多數(shù)代碼在別處已經(jīng)寫過了 ? 利用已有的代碼可以節(jié)省時間，提高質(zhì)量 ? 在微軟，各產(chǎn)品組互為客戶和提供商關(guān)系 ? 對于任何一段代碼，首先問自己： 這段代碼 /功能有可能在什么地方已經(jīng)有人寫過了 可能在已有的項目里 可能操作系統(tǒng)已經(jīng)實現(xiàn)了（ ) 可能在某個函數(shù)庫里（ ,DLL,.NET Framework) ? 代碼重用有不同的級別 代碼重用的不同級別 ? 調(diào)用系統(tǒng)已有功能，或其他項目組已完成的功能（ Messenger) ? 與其他項目合用可執(zhí)行代碼 ? 與其他項目復(fù)用源代碼 ? 從其他項目中拷貝源代碼（ Code base) ? 利用其他項目的界面設(shè)計和算法（ ,Wizard) ? IE創(chuàng)造了代碼重用的神話 (Help,URL Moniker) 選擇實現(xiàn)方式時一定要慎重 ? 決定自己開發(fā)時一定要慎重 比如：已經(jīng)有了很多數(shù)據(jù)庫引擎，我們真的有必要重新寫我們自己的嗎？ ? 采用別的項目的技術(shù)是一定要慎重 可能不是完完全全你要的東西 可能沒法放到你的體系中來 可能質(zhì)量達不到你的要求 可能有很多后續(xù)問題（版本問題，安裝 … ） ? 使用全新的技術(shù) 不一定是最好的 發(fā)布日期的限制 … 如何了解已有的代碼 ? 審閱所代碼（打印出來） ? 用代碼瀏覽器瀏覽所有代碼（如 Source Insight) ? 分步執(zhí)行程序 ? 閱讀設(shè)計文檔 ? 小心的重新格式化它 注釋，調(diào)試代碼，編程風(fēng)格，等等 MO易犯的錯誤 ? 功能說明書（ Spec)出來的太晚 ? 開發(fā)團隊對產(chǎn)品沒有共識（ Vision) ? 在設(shè)計上花的是時間太少，形成的功能設(shè)計書不踏實 ? 計劃過于樂觀 M1， M2到 Mn 開發(fā)和編程 里程碑的設(shè)計技巧 ? 時間分配 實際編程時間 集成，穩(wěn)定時間（后面的里程碑時間加長） *保證各個模塊可以在一起工作 *必須寫一段，穩(wěn)定一段，再繼續(xù)前進 緩沖的時間 ? 每個產(chǎn)品組都有不同的安排 ? 1/3時間來集成 Code Complete代碼完成 ? 計劃的工作完成 ? 功能可以運行 ? 不需要任何編程工作了 ? 它意味著 從編程模式轉(zhuǎn)變到發(fā)現(xiàn)并修正 Bug模式 不會再有新的功能了 代碼完成后的工作 ? 凍結(jié)界面修改 ? Beta測試 ? ZBB(Zero Bug Bounce) ? 發(fā)布候選版本 ? RTM/RTW 微軟協(xié)作工作模式 建立開發(fā)團隊的基礎(chǔ)設(shè)施 ? 源代碼服務(wù)器 ? Build machine ? Bug數(shù)據(jù)庫 ? 發(fā)布服務(wù)器 ? 信息發(fā)布站點 ? Exchange郵件列表和公共文件夾 建立開發(fā)團隊的基礎(chǔ)設(shè)施 ? 源代碼服務(wù)器 ? 編譯服務(wù)器 ? 發(fā)布服務(wù)器 ? Bug數(shù)據(jù)庫 ? 信息發(fā)布站點 ? Exchange郵件列表和公共文件夾 常用名詞 ? Checkin提交修改代碼 ? Code review代碼審核 ? Buddy build伙伴編譯 ? Pickup修改反映到 Build machine ? Synchronize同步其他人的修改 ? Build生成正式二進制文件 ? Release正式二進制文件發(fā)布 ? BVT啟動測試 開發(fā)中的版本控制 ? 為什么要進行版本控制？ ? 版本控制工具可以 恢復(fù)到以前的版本 知道誰曾經(jīng)改動過某段代碼 理解某個代碼改動的原因 ? 微軟內(nèi)部使用很多工具 Source Depot,VSS,SLM… 源代碼服務(wù)器 ?是正式的、唯一的代碼來源 ?源代碼服務(wù)器里有什么 *源代碼 *有關(guān)工具的代碼 *規(guī)格書 *其他經(jīng)常改動的文檔 ?源代碼服務(wù)器沒有什么 *二進制文件 *目標(biāo)文件 *編譯產(chǎn)生的頭文件 提交修改代碼過程 ? 統(tǒng)一的流程可以保證 *保證版本總可以工作 *避免出現(xiàn) Build Break ? Build Break是非常嚴重的錯誤 *開發(fā)過程被迫中斷 *測試人員沒法測試別人的餓代碼 *對此負責(zé)的程序員會被半夜叫到公司 源代碼管理 ? 集中 *必須使用工具：如 SourceSafe ? 質(zhì)量 *編程的標(biāo)準(zhǔn)規(guī)范 通用的編程方式 /注釋 *代碼凈化和代碼審核 ? 安全性 *經(jīng)常做服務(wù)器備份 *存儲在不同的地方 Checkin管理 ? 程序員開發(fā)出一段代碼 ? 個人測試 *在調(diào)試器里執(zhí)行每一行代碼 *所有的測試用例都要運行 ? 加入個人代碼后軟件的整體測試 ? 代碼的遞交和伙伴審核及編譯 ? 嚴格的 Checkin管理 Checkin管理 測試人員 發(fā)布服務(wù)器 Builder 開發(fā)人員 Bug數(shù)據(jù)庫 源代碼 服務(wù)器 郵件系統(tǒng) 作戰(zhàn)會議 拿到新的版本 記錄 bug 1驗證 bug解決 解決 bug 得到新的 bug 改正 bug Check in請求 Check in 編譯 批準(zhǔn) 拿到最新源代碼 代碼集成要點 ? 每一個 Checkin必須有記錄 *必須發(fā) pickup郵件 *要有新 feature規(guī)格、 Bug號或說明 *代碼審核和伙伴編譯 ? 進入控制模式后 *Checkin之前需要申請 *必須是解決 Show Stopper bug或由經(jīng)理或作戰(zhàn)會議批準(zhǔn) Build Machine(編譯機） ? 獨立的專用機器（通常再專用實驗室里） ? 專人負責(zé) ? 生成二進制