微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建課件_第1頁
微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建課件_第2頁
微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建課件_第3頁
微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建課件_第4頁
微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建課件_第5頁
已閱讀5頁,還剩87頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建DEV200微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建DEV200議題微軟研發(fā)簡介和研發(fā)系統(tǒng)觀開發(fā)人員配置開發(fā)流程中的重要階段和實踐開發(fā)工具的演化用VSTS/TFS構(gòu)建軟件開發(fā)平臺來加強管理、提高效率議題微軟研發(fā)簡介和研發(fā)系統(tǒng)觀微軟對創(chuàng)新的投入從未間斷微軟研發(fā)中心55個研究領(lǐng)域產(chǎn)品開發(fā)/技術(shù)孵化/基礎(chǔ)研究微軟成功的核心研究中心開發(fā)中心微軟對創(chuàng)新的投入從未間斷微軟研發(fā)中心研究中心開發(fā)中心?2009MicrosoftEcosystemDevelopmentResearchIncubationMadeINChina(Deployment)MadeFORChina(Production)MadeBYChina(Ownership)MadeWITHChina(Impact)微軟在美國以外投資最大、職能最完備、機構(gòu)設(shè)置最全的創(chuàng)新基地五大研發(fā)方向:移動通訊和嵌入式系統(tǒng)、互聯(lián)網(wǎng)技術(shù)產(chǎn)品和服務(wù)、數(shù)字娛樂、服務(wù)器與開發(fā)工具和新興市場微軟中國研發(fā)集團?2009MicrosoftEcosystemDevel微軟開發(fā)面對的挑戰(zhàn)了解客戶的需求多樣化的客戶群未來以及潛在需求的開發(fā)怎樣開發(fā)多種產(chǎn)品為客戶提供長期的價值

很多大團隊怎樣一起共同研發(fā)復雜的產(chǎn)品雇用優(yōu)秀的工程師并讓他們很快進入狀態(tài)與全世界不同地區(qū)的同事做分布式的協(xié)同開發(fā)微軟開發(fā)面對的挑戰(zhàn)了解客戶的需求微軟并沒有硬性的開發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期在線產(chǎn)品:每周或每日病毒預防,重要補丁等等:每月重要的產(chǎn)品:每年Office:兩到三年其它不同周期:操作系統(tǒng),數(shù)據(jù)庫…但是,都用同樣的理念!微軟并沒有硬性的開發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期研發(fā)系統(tǒng)觀人員流程工具研發(fā)系統(tǒng)觀人員流程工具功能團隊的核心項目管理項目經(jīng)理調(diào)查客戶需求、了解競爭對手并發(fā)展出相關(guān)軟件需求開發(fā)軟件開發(fā)人員編寫符合需求的程序測試軟件測試人員確保產(chǎn)品性能符合需求功能團隊的核心項目管理項目經(jīng)理調(diào)查客戶需求、了解競爭對手并發(fā)多重專業(yè)的有序分工開發(fā)測試項目管理IT運行產(chǎn)品計劃可用性設(shè)計創(chuàng)意內(nèi)容基礎(chǔ)研究工程管理專業(yè)開發(fā)測試項目管理

IT運行產(chǎn)品計劃創(chuàng)意可用性基礎(chǔ)研究內(nèi)容工程管理多重專業(yè)的有序分工開發(fā)測試項目管理IT運行產(chǎn)品計劃可用性設(shè)組織結(jié)構(gòu)–用某開發(fā)團隊為例在微軟,產(chǎn)品是由產(chǎn)品組“ProductUnits”來開發(fā)的,由ProductUnitManager來負責GroupProgramManager,DevManager,TestManager各負責一類職責并向ProductUnitManager匯報項目管理(ProgramManagement)負責產(chǎn)品功能集和功能定義七位項目管理經(jīng)理最終向GroupProgramManager匯報開發(fā)(Development)負責產(chǎn)品的實現(xiàn)和架構(gòu)十五位軟件開發(fā)工程師最終向DevManager匯報測試(Testing)負責產(chǎn)品的質(zhì)量保證二十八位軟件開發(fā)測試工程師最終向TestManager匯報組織結(jié)構(gòu)–用某開發(fā)團隊為例在微軟,產(chǎn)品是由產(chǎn)品組“Prod開發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略總結(jié)價值分析價值分析價值分析多次發(fā)布策略服務(wù)開發(fā)定義項目服務(wù)上市測試版進度表工程系統(tǒng)版本目標功能計劃里程碑優(yōu)化選擇里程碑里程碑功能重復設(shè)計文件功能描述測試描述測試代碼產(chǎn)品代碼質(zhì)量檢驗功能團隊會用Agile方法開發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略價值分析價值分析價值時間計劃里程碑=產(chǎn)品周期進展的單元常見的里程碑計劃:M0,M1,M2,…,Beta1,Beta2,RTM有利于對當前進展和所剩工作的評估在里程碑計劃中功能分優(yōu)先級當質(zhì)量達到里程碑終結(jié)標準“exitcriteria”,里程碑才算完成?2009Microsoft時間計劃里程碑=產(chǎn)品周期進展的單元?2009Micr主要的功能里程碑事件里程碑事件定義SpecComplete規(guī)格完成日里程碑功能設(shè)計規(guī)格應寫好并審核完的日期FeatureCoding寫功能代碼功能里程碑通常

用8-9周長短來寫代碼CodeComplete(CC)代碼完成日所有里程碑計劃的功能都應完成的日期TestPlanComplete測試計劃完成日里程碑功能測試計劃應寫好并審核完的日期ZeroBugBounce(ZBB)零漏洞震蕩本里程碑大于48小時的漏洞數(shù)量=

0ZBBTestPass(ZBBTP)ZBB全測試所有功能測試都在當前構(gòu)建(build)上運行一遍ZeroResolvedBugs(ZRB)零解決漏洞里程碑內(nèi)解決的并等待驗證的漏洞數(shù)量=0TestSign-Off測試驗收對里程碑構(gòu)建(build)做最后的驗證和媒介驗收?2009Microsoft主要的功能里程碑事件里程碑事件定義SpecComplete設(shè)計規(guī)格沒有設(shè)計就不要寫產(chǎn)品代碼即使是一個人的項目也要遵守這個好規(guī)則對團隊項目來說則是必須的功能集是由微軟ProgramManagers來負責的負責寫每個功能的設(shè)計規(guī)格,開發(fā)和測試給反饋一個好設(shè)計規(guī)格有如下特點:清楚地說明功能的目標和非目標清楚地說明客戶和合作伙伴怎樣來用這個功能準確地說明功能的對象模式和架構(gòu)設(shè)計足夠清楚地讓分開的開發(fā)、測試、文檔、本地化團隊一起來完成設(shè)計規(guī)格沒有設(shè)計就不要寫產(chǎn)品代碼編寫代碼對源代碼樹的任何改動在提交前都要由別的開發(fā)工程師來做代碼審核開發(fā)者負責對實現(xiàn)的功能進行提交測試現(xiàn)趨向于開發(fā)者寫的單元測試達不到60%block-levelcode-coverage不能提交功能代碼代碼提交前所有的提交測試都要運行,通過率要100%(2-3小時的過程)工具:提交排隊系統(tǒng)來運行提交測試提交排隊系統(tǒng)在每次成功提交后會給團隊發(fā)“Check-inmail”電郵,信中總結(jié)修改了什么代碼、解決的漏洞、修改的文件

編寫代碼對源代碼樹的任何改動在提交前都要由別的開發(fā)工程師來做UnitTesting單元(unit)測試UnitTesting單元(unit)測試源代碼樹的結(jié)構(gòu)MainSourceBranchFeatureBranchTeam1BranchTeam2BranchFeatureBranchFeatureBranchFeatureBranchFeatureBranchFeatureBranch源代碼樹的結(jié)構(gòu)MainSourceBranchFeatu產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個產(chǎn)品的新構(gòu)建“build”中央buildlab為全division(~2800人)做dailybuildBuild流程:Build團隊同步源代碼樹(~半夜)開始端到端的build(~4:00am)Build完成(~1:00pm)做BVT(BuildVerificationTests)來驗證build是否正常(~4:00pm)從BFD那里拿到hot-fixes然后re-buildBVT失敗的地方重復hotfix/BVT周期直到build沒有問題?2009Microsoft產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個產(chǎn)品的新每天都有Build報告每天都有Build報告測試測試團隊是由開發(fā)人員組成的,他們負責設(shè)計測試計劃、寫自動測試、建立測試基礎(chǔ)設(shè)施著重于提高質(zhì)量、防止退化、能夠快速分析不同的builds和它的變異以及各語言版VS2005測試狀況:102,000功能測試用例TestCases505,000功能測試方案TestScenarios71壓力混和變異測試測試實驗室~1000服務(wù)器來自動運行這些測試測試管理系統(tǒng)儲存并管理測試計劃和自動測試運行允許用戶很容易地增加、刪除、分析測試計劃及用例允許用戶遠程用再映像方式(re-image)來配置實驗室里的機器允許用戶遠程在一系列實驗室機器上啟動test-run允許用戶遠程分析測試運行結(jié)果并公布結(jié)果測試測試團隊是由開發(fā)人員組成的,他們負責設(shè)計測試計劃、寫自動測試質(zhì)量保證(QA)的第一步是測試計劃自動測試用例的實現(xiàn)目標是在產(chǎn)品周期結(jié)束時所有測試代碼覆蓋率>85%總是在尋找“testholes”測試中找到的缺陷(bug)會在VSTS/TFS中記錄定期的自動測試運行會捕捉到退化regressions測試質(zhì)量保證(QA)的第一步是測試計劃TestCaseManagement測試用例管理手動和自動在一個系統(tǒng)里TestCaseManagement測試用例管理CodeCoverage代碼覆蓋率Unit,BVT,Suite,AllCodeCoverage代碼覆蓋率Bug漏洞跟蹤Bugs和work-items放在TeamFoundationServer上功能leads會“triage”Bugs并給出優(yōu)先級每天會有Status郵件發(fā)給全division來跟蹤bug狀況主要觀察尺度:新進來的bug數(shù)和修掉的數(shù)以及在每個dev上的bug數(shù)在最后一個功能里程碑完成后,產(chǎn)品團隊的任務(wù)主要是把bug數(shù)減少到零Bug漏洞跟蹤Bugs和work-items放在TBug查詢Bug查詢Bug詳細情況Bug詳細情況產(chǎn)品近尾聲時的滑翔路徑大項目會慢慢滑入“glidein”而不是突然結(jié)束產(chǎn)品盡早得到真正用戶的反饋很關(guān)鍵微軟團隊常常在RTM(ReleaseToManufacture)發(fā)放前要有兩個公開betas在進入“尾聲”前,“滑翔路徑”中的一些主要步驟1)鎖定功能集,停止增加或改變功能設(shè)計2)在鎖定設(shè)計基礎(chǔ)上做全方位的測試找出所有能找到的bug3)努力達到零漏洞震蕩zerobugbounce(ZBB)4)用幾周時間來吸收回彈的bug數(shù)5)從系統(tǒng)中把不必須修的bug推掉6)進入尾聲“end-game”,開始把代碼改動量減到最小?2009Microsoft產(chǎn)品近尾聲時的滑翔路徑大項目會慢慢滑入“glidein”工具的演化單一功能的工具–編輯器、調(diào)試器整合的開發(fā)環(huán)境(IDE)

VisualStudio

Professional應用開發(fā)周期管理(ALM)

VisualStudioTeamSystemwithTeamFoundationServer?2009Microsoft工具的演化單一功能的工具–編輯器、調(diào)試器?2009M微軟的ALM解決方案PMODevelopmentOperations?2009Microsoft微軟的ALM解決方案PMODevelopmentOperVisualStudioTeamSystem

TeamFoundationServer團隊協(xié)作開發(fā)的一個整合的平臺團隊Portal–團隊協(xié)作SharePointsite變更管理–提供靈活的需求、變更請求、bugs、問題、工作項目的跟蹤系統(tǒng)項目管理–管理項目資源、時間線、質(zhì)量版本控制–強健的源代碼版本控制系統(tǒng),包括所有項目的代碼、分支、變更集(changeset)、擱置集(shelveset)報告–提供中央數(shù)據(jù)倉庫,實時項目指標和分析團隊Build–為團隊項目創(chuàng)建和管理build類型VisualStudioTeamSystem

Team由工具來制定的流程在建立新項目時選擇流程由工具來制定的流程在建立新項目時選擇流程工作項的解剖ValuePropositionExperienceFeatureTaskTaskFeatureTaskExperienceFeatureTaskBackoftheboxMarketingfeatureSpecFeatureCrewTask工作項的解剖ValuePropositionExperie每一次提交代碼都可以與工作項關(guān)聯(lián),使得需求、任務(wù)、Bug和代碼關(guān)聯(lián)版本控制-關(guān)聯(lián)工作項每一次提交代碼都可以與工作項關(guān)聯(lián),使得需求、任務(wù)、Bug和代構(gòu)建工作流-VSTS/TFS2010EditCodeSubmitgatedcheck-inAutomatedBuildCommitCheck-InY/NReadyforTest構(gòu)建工作流-VSTS/TFS2010EditCode商業(yè)需求記錄并管理商業(yè)需求,提供從頭到尾的可追蹤性商業(yè)需求記錄并管理商業(yè)需求,提供從頭到尾的可追蹤性哪里需要調(diào)整資源?大部分要做的工作在測試方面,表明資源分配不合適或質(zhì)量有問題哪里需要調(diào)整資源?大部分要做的工作在測試方面,表明資源分配不范圍蠕變“黑事”在迭代中浮現(xiàn)計劃的工作減少了范圍蠕變“黑事”在迭代中浮現(xiàn)計劃的工作減少了我們團隊的工作是否有效?測試率

(通過,沒結(jié)論,失敗)用顏色區(qū)分代碼覆蓋率,…代碼改動,…有效的

bugs我們團隊的工作是否有效?測試率

(通過,沒結(jié)論,失敗)測試不足代碼覆蓋率降低通過的測試減少沒結(jié)論的增多代碼改動量增加測試不足代碼覆蓋率降低通過的測試減少沒結(jié)論的增多代碼改動量增整個開發(fā)工程系統(tǒng)的性能R&D投入提供給客戶的價值現(xiàn)有的工程系統(tǒng)更新過的工程系統(tǒng)創(chuàng)新整個開發(fā)工程系統(tǒng)的性能R&D投入提供給客戶的價值現(xiàn)有的工參考資源BrianHarry博客:/bharry/VSTSMSDN主頁:/en-us/teamsystem/default.aspxTFSMSDN主頁:/en-us/teamsystem/dd408382.aspxVC++MSDN論壇:/Forums/en-US/category/vsts參考資源BrianHarry博客:http://blo專家問答區(qū)(F4)

本課程結(jié)束后,我將在接下來的70分鐘內(nèi)于4層專家問答區(qū)與您交流答疑專家問答區(qū)(F4)

本課程結(jié)束后,我將在接下來的70分鐘內(nèi)微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建疑問和解答疑問和解答微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建DEV200微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建DEV200議題微軟研發(fā)簡介和研發(fā)系統(tǒng)觀開發(fā)人員配置開發(fā)流程中的重要階段和實踐開發(fā)工具的演化用VSTS/TFS構(gòu)建軟件開發(fā)平臺來加強管理、提高效率議題微軟研發(fā)簡介和研發(fā)系統(tǒng)觀微軟對創(chuàng)新的投入從未間斷微軟研發(fā)中心55個研究領(lǐng)域產(chǎn)品開發(fā)/技術(shù)孵化/基礎(chǔ)研究微軟成功的核心研究中心開發(fā)中心微軟對創(chuàng)新的投入從未間斷微軟研發(fā)中心研究中心開發(fā)中心?2009MicrosoftEcosystemDevelopmentResearchIncubationMadeINChina(Deployment)MadeFORChina(Production)MadeBYChina(Ownership)MadeWITHChina(Impact)微軟在美國以外投資最大、職能最完備、機構(gòu)設(shè)置最全的創(chuàng)新基地五大研發(fā)方向:移動通訊和嵌入式系統(tǒng)、互聯(lián)網(wǎng)技術(shù)產(chǎn)品和服務(wù)、數(shù)字娛樂、服務(wù)器與開發(fā)工具和新興市場微軟中國研發(fā)集團?2009MicrosoftEcosystemDevel微軟開發(fā)面對的挑戰(zhàn)了解客戶的需求多樣化的客戶群未來以及潛在需求的開發(fā)怎樣開發(fā)多種產(chǎn)品為客戶提供長期的價值

很多大團隊怎樣一起共同研發(fā)復雜的產(chǎn)品雇用優(yōu)秀的工程師并讓他們很快進入狀態(tài)與全世界不同地區(qū)的同事做分布式的協(xié)同開發(fā)微軟開發(fā)面對的挑戰(zhàn)了解客戶的需求微軟并沒有硬性的開發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期在線產(chǎn)品:每周或每日病毒預防,重要補丁等等:每月重要的產(chǎn)品:每年Office:兩到三年其它不同周期:操作系統(tǒng),數(shù)據(jù)庫…但是,都用同樣的理念!微軟并沒有硬性的開發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期研發(fā)系統(tǒng)觀人員流程工具研發(fā)系統(tǒng)觀人員流程工具功能團隊的核心項目管理項目經(jīng)理調(diào)查客戶需求、了解競爭對手并發(fā)展出相關(guān)軟件需求開發(fā)軟件開發(fā)人員編寫符合需求的程序測試軟件測試人員確保產(chǎn)品性能符合需求功能團隊的核心項目管理項目經(jīng)理調(diào)查客戶需求、了解競爭對手并發(fā)多重專業(yè)的有序分工開發(fā)測試項目管理IT運行產(chǎn)品計劃可用性設(shè)計創(chuàng)意內(nèi)容基礎(chǔ)研究工程管理專業(yè)開發(fā)測試項目管理

IT運行產(chǎn)品計劃創(chuàng)意可用性基礎(chǔ)研究內(nèi)容工程管理多重專業(yè)的有序分工開發(fā)測試項目管理IT運行產(chǎn)品計劃可用性設(shè)組織結(jié)構(gòu)–用某開發(fā)團隊為例在微軟,產(chǎn)品是由產(chǎn)品組“ProductUnits”來開發(fā)的,由ProductUnitManager來負責GroupProgramManager,DevManager,TestManager各負責一類職責并向ProductUnitManager匯報項目管理(ProgramManagement)負責產(chǎn)品功能集和功能定義七位項目管理經(jīng)理最終向GroupProgramManager匯報開發(fā)(Development)負責產(chǎn)品的實現(xiàn)和架構(gòu)十五位軟件開發(fā)工程師最終向DevManager匯報測試(Testing)負責產(chǎn)品的質(zhì)量保證二十八位軟件開發(fā)測試工程師最終向TestManager匯報組織結(jié)構(gòu)–用某開發(fā)團隊為例在微軟,產(chǎn)品是由產(chǎn)品組“Prod開發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略總結(jié)價值分析價值分析價值分析多次發(fā)布策略服務(wù)開發(fā)定義項目服務(wù)上市測試版進度表工程系統(tǒng)版本目標功能計劃里程碑優(yōu)化選擇里程碑里程碑功能重復設(shè)計文件功能描述測試描述測試代碼產(chǎn)品代碼質(zhì)量檢驗功能團隊會用Agile方法開發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略價值分析價值分析價值時間計劃里程碑=產(chǎn)品周期進展的單元常見的里程碑計劃:M0,M1,M2,…,Beta1,Beta2,RTM有利于對當前進展和所剩工作的評估在里程碑計劃中功能分優(yōu)先級當質(zhì)量達到里程碑終結(jié)標準“exitcriteria”,里程碑才算完成?2009Microsoft時間計劃里程碑=產(chǎn)品周期進展的單元?2009Micr主要的功能里程碑事件里程碑事件定義SpecComplete規(guī)格完成日里程碑功能設(shè)計規(guī)格應寫好并審核完的日期FeatureCoding寫功能代碼功能里程碑通常

用8-9周長短來寫代碼CodeComplete(CC)代碼完成日所有里程碑計劃的功能都應完成的日期TestPlanComplete測試計劃完成日里程碑功能測試計劃應寫好并審核完的日期ZeroBugBounce(ZBB)零漏洞震蕩本里程碑大于48小時的漏洞數(shù)量=

0ZBBTestPass(ZBBTP)ZBB全測試所有功能測試都在當前構(gòu)建(build)上運行一遍ZeroResolvedBugs(ZRB)零解決漏洞里程碑內(nèi)解決的并等待驗證的漏洞數(shù)量=0TestSign-Off測試驗收對里程碑構(gòu)建(build)做最后的驗證和媒介驗收?2009Microsoft主要的功能里程碑事件里程碑事件定義SpecComplete設(shè)計規(guī)格沒有設(shè)計就不要寫產(chǎn)品代碼即使是一個人的項目也要遵守這個好規(guī)則對團隊項目來說則是必須的功能集是由微軟ProgramManagers來負責的負責寫每個功能的設(shè)計規(guī)格,開發(fā)和測試給反饋一個好設(shè)計規(guī)格有如下特點:清楚地說明功能的目標和非目標清楚地說明客戶和合作伙伴怎樣來用這個功能準確地說明功能的對象模式和架構(gòu)設(shè)計足夠清楚地讓分開的開發(fā)、測試、文檔、本地化團隊一起來完成設(shè)計規(guī)格沒有設(shè)計就不要寫產(chǎn)品代碼編寫代碼對源代碼樹的任何改動在提交前都要由別的開發(fā)工程師來做代碼審核開發(fā)者負責對實現(xiàn)的功能進行提交測試現(xiàn)趨向于開發(fā)者寫的單元測試達不到60%block-levelcode-coverage不能提交功能代碼代碼提交前所有的提交測試都要運行,通過率要100%(2-3小時的過程)工具:提交排隊系統(tǒng)來運行提交測試提交排隊系統(tǒng)在每次成功提交后會給團隊發(fā)“Check-inmail”電郵,信中總結(jié)修改了什么代碼、解決的漏洞、修改的文件

編寫代碼對源代碼樹的任何改動在提交前都要由別的開發(fā)工程師來做UnitTesting單元(unit)測試UnitTesting單元(unit)測試源代碼樹的結(jié)構(gòu)MainSourceBranchFeatureBranchTeam1BranchTeam2BranchFeatureBranchFeatureBranchFeatureBranchFeatureBranchFeatureBranch源代碼樹的結(jié)構(gòu)MainSourceBranchFeatu產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個產(chǎn)品的新構(gòu)建“build”中央buildlab為全division(~2800人)做dailybuildBuild流程:Build團隊同步源代碼樹(~半夜)開始端到端的build(~4:00am)Build完成(~1:00pm)做BVT(BuildVerificationTests)來驗證build是否正常(~4:00pm)從BFD那里拿到hot-fixes然后re-buildBVT失敗的地方重復hotfix/BVT周期直到build沒有問題?2009Microsoft產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個產(chǎn)品的新每天都有Build報告每天都有Build報告測試測試團隊是由開發(fā)人員組成的,他們負責設(shè)計測試計劃、寫自動測試、建立測試基礎(chǔ)設(shè)施著重于提高質(zhì)量、防止退化、能夠快速分析不同的builds和它的變異以及各語言版VS2005測試狀況:102,000功能測試用例TestCases505,000功能測試方案TestScenarios71壓力混和變異測試測試實驗室~1000服務(wù)器來自動運行這些測試測試管理系統(tǒng)儲存并管理測試計劃和自動測試運行允許用戶很容易地增加、刪除、分析測試計劃及用例允許用戶遠程用再映像方式(re-image)來配置實驗室里的機器允許用戶遠程在一系列實驗室機器上啟動test-run允許用戶遠程分析測試運行結(jié)果并公布結(jié)果測試測試團隊是由開發(fā)人員組成的,他們負責設(shè)計測試計劃、寫自動測試質(zhì)量保證(QA)的第一步是測試計劃自動測試用例的實現(xiàn)目標是在產(chǎn)品周期結(jié)束時所有測試代碼覆蓋率>85%總是在尋找“testholes”測試中找到的缺陷(bug)會在VSTS/TFS中記錄定期的自動測試運行會捕捉到退化regressions測試質(zhì)量保證(QA)的第一步是測試計劃TestCaseManagement測試用例管理手動和自動在一個系統(tǒng)里TestCaseManagement測試用例管理CodeCoverage代碼覆蓋率Unit,BVT,Suite,AllCodeCoverage代碼覆蓋率Bug漏洞跟蹤Bugs和work-items放在TeamFoundationServer上功能leads會“triage”Bugs并給出優(yōu)先級每天會有Status郵件發(fā)給全division來跟蹤bug狀況主要觀察尺度:新進來的bug數(shù)和修掉的數(shù)以及在每個dev上的bug數(shù)在最后一個功能里程碑完成后,產(chǎn)品團隊的任務(wù)主要是把bug數(shù)減少到零Bug漏洞跟蹤Bugs和work-items放在TBug查詢Bug查詢Bug詳細情況Bug詳細情況產(chǎn)品近尾聲時的滑翔路徑大項目會慢慢滑入“glidein”而不是突然結(jié)束產(chǎn)品盡早得到真正用戶的反饋很關(guān)鍵微軟團隊常常在RTM(ReleaseToManufacture)發(fā)放前要有兩個公開betas在進入“尾聲”前,“滑翔路徑”中的一些主要步驟1)鎖定功能集,停止增加或改變功能設(shè)計2)在鎖定設(shè)計基礎(chǔ)上做全方位的測試找出所有能找到的bug3)努力達到零漏洞震蕩zerobugbounce(ZBB)4)用幾周時間來吸收回彈的bug數(shù)5)從系統(tǒng)中把不必須修的bug推掉6)進入尾聲“end-game”,開始把代碼改動量減到最小?2009Microsoft產(chǎn)品近尾聲時的滑翔路徑大項目會慢慢滑入“glidein”工具的演化單一功能的工具–編輯器、調(diào)試器整合的開發(fā)環(huán)境(IDE)

VisualStudio

Professional應用開發(fā)周期管理(ALM)

VisualStudioTeamSystemwithTeamFoundationServer?2009Microsoft工具的演化單一功能的工具–編輯器、調(diào)試器?2009M微軟的ALM解決方案PMODevelopmentOperations?2009Microsoft微軟的ALM解決方案PMODevelopmentOperVisualStudioTeamSystem

TeamFoundationServer團隊協(xié)作開發(fā)的一個整合的平臺團隊Portal–團隊協(xié)作SharePointsite變更管理–提供靈活的需求、變更請求、bugs、問題、工作項目的跟蹤系統(tǒng)項目管理–管理項目資源、時間線、質(zhì)量版本控制–強健的源代碼版本控制系統(tǒng),包括所有項目的代碼、分支、變更集(changeset)、擱置集(shelveset)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論