【正文】 問題。 解決辦法 需求決定測試方案，而不是程序員，但程序員要參與測試方案審查。 用測試文檔資料工具起草手工測試的文檔好讓其他的測試員和程序員能夠重復(fù)。 準(zhǔn)備穩(wěn)定的數(shù)據(jù)是測試的前提工作。 測試也按重要性分級別，資源有限制時(shí)，寧可犧牲不重要的測試 ,而只做關(guān)鍵路徑測試。 分散組合各種非功能需求，求廣不求細(xì)。 不斷提升 自動(dòng)測試 的覆蓋率。（無人測試） 每個(gè)階段都要回歸測試。（積累以前完成的所有階段） 代碼分支的下并到主視圖 后和到客戶端之前，仍要作一次主視圖 的集成回歸測試。 （積累以前所有測試） 測試 測試工具介紹 – 文檔資料工具 (Mercury TestDirector) – 模擬化的自動(dòng)測試的工具介紹 界面功能測試 QickTest Professional ， 性能測試 :loadrunner winrunner, Microsoft web application stress tool 表達(dá)層模擬測試 HttpUnit 自動(dòng)回歸測試?yán)?ANT/Maven2代碼指導(dǎo) – 自動(dòng)測試工具的特點(diǎn) 通過記錄和重放，用界面特征識別對證，操作簡單，不要太多培訓(xùn)。 易于制作，不應(yīng)變，難以更改。 提供一定程度的測試代碼的編程，復(fù)雜度取決與測試過程要求的抽象和應(yīng)變能力。 體會(huì) 測試的發(fā)展趨勢是越來越自動(dòng)化，又人力密集性到程序密集性過度。因此對測試員的要求更高，不僅會(huì)簡單的機(jī)器操作，還要會(huì)使用工具和編程來實(shí)現(xiàn)自動(dòng)測試。 但是保留一定程度的人工測試是不可避免的，因?yàn)槿吮葯C(jī)器可靈活，更敏感，更有創(chuàng)造力。 機(jī)器只是第一防線（廉價(jià)堡壘），人是最終防線（哨兵）。 測試階段的工作流程 部署 編譯和集成打包階段 面臨的問題 – 編譯打包的過程是復(fù)雜的混合過程。（不同程序語言子系統(tǒng)，復(fù)雜的文件操作和壓縮） – 部署和集成有不同的變體。（服務(wù)器，數(shù)據(jù)庫，優(yōu)化選擇和配置選擇，不同的視圖） – 讓不熟悉它的程序員去完成，需要大量的時(shí)間和特殊的工序。 部署 編譯和集成打包 解決方案 – 部署部門不僅對客戶端負(fù)責(zé)，也對內(nèi)部開發(fā)服務(wù)。由專門的部署部門對不同的視圖進(jìn)行定期自動(dòng)編譯和部署到硬件 。 – 程序員直接使用部署的硬件軟件，或向部署部門發(fā)一個(gè)工作單要求特殊編譯部署 。 – 使用與代碼維護(hù)系統(tǒng)可直接集成的自動(dòng)工具（ ANT） 。 部署 編譯和集成打包 工具介紹。（ Apache Ant） – 支持多 OS 。 (Java程序 ) – 靈活豐富的文件處理功能。 (強(qiáng)于 make 和shell mand) – 完備的邏輯控制。 – 可按任務(wù)倚賴性調(diào)整順序。 – 可參數(shù)化和可調(diào)用子過程。 – 標(biāo)準(zhǔn)的 XML規(guī)范。 – 與代碼維護(hù)系統(tǒng)集成，直接調(diào)用。 體會(huì) 復(fù)雜的部署過程會(huì)嚇跑客戶，也會(huì)讓開發(fā)員頭疼。 有時(shí)，公司應(yīng)該組織一些開發(fā)人員來對部署程序?qū)崿F(xiàn)自動(dòng)化和友好的交互界面，以提高整體的工作效率。 維護(hù) 維護(hù)大型軟件中的問題 – 滿足客戶新要求的同時(shí)，保證與老需求的一致性，如老需求遺失更糟。 – 已經(jīng)被用戶接受的產(chǎn)品特性難以收回，被迫向后兼容。（舉例，鍵盤的低效格式） – 軟件內(nèi)部結(jié)構(gòu)和設(shè)計(jì)變的愈來愈亂，不再優(yōu)化，重復(fù)矛盾代碼隨處可見，實(shí)現(xiàn)方法技術(shù)落后于當(dāng)前標(biāo)準(zhǔn)，使維護(hù)成本上升，利潤下降。 – 開發(fā)員投入太多時(shí)間去維護(hù)以前的項(xiàng)目，不能集中精力做任何事。 維護(hù) 公司的對策 – 逃避法－外資， “ 讓別人維護(hù)，我們只管開發(fā)。 ” 。如果不投入精力教育外資，效果不佳。 – 悲觀主義－做好最壞的打算－開發(fā)員寫完程序就跳槽，怎辦？開發(fā)結(jié)束前，開發(fā)員完成詳盡的需求和技術(shù)檔案和講演，讓維護(hù)員迅速掌握。有長遠(yuǎn)打算。 – 值班制 － 維護(hù)和開發(fā)人員經(jīng)常對調(diào)，讓開發(fā)員完成自己的項(xiàng)目后，馬上到維護(hù)部門一段時(shí)間去清除自己的 bug 。 簡單高效。 – 大掃除法 － 定期重構(gòu)各個(gè)子系統(tǒng)。要求各子系統(tǒng)設(shè)計(jì)時(shí)松偶合， 需求保存完備。 – 退休法 － 正式宣告老產(chǎn)品線將于若干年后退休，新產(chǎn)品要取而代之，用戶的數(shù)據(jù)和應(yīng)用程序可以通過轉(zhuǎn)化程序載入新產(chǎn)品線。徹底但投資大。 維護(hù) 開發(fā)員和維護(hù)員的努力 – 加強(qiáng)開發(fā)員和維護(hù)員的交流和學(xué)習(xí)。 – 維護(hù)員審查開發(fā)員的項(xiàng)目的設(shè)計(jì)思路。 – 開發(fā)員監(jiān)督維護(hù)員的解決方案，以保證不違背原始的需求和設(shè)計(jì)。 – 當(dāng)維護(hù)員面臨重大的設(shè)計(jì)修改，可遞交產(chǎn)品總關(guān)作為新的項(xiàng)目提名。 – 維護(hù)代碼的同時(shí)，也要維護(hù)需求文件，保持一致性。 體會(huì) 開發(fā)一些維護(hù)用的調(diào)試工具和有效的日志系統(tǒng)。 開發(fā)該用戶一個(gè)自助的問題診斷的專家系統(tǒng)和系統(tǒng)管理員監(jiān)控系統(tǒng)，以節(jié)省維護(hù)的開銷。 許多案件是用戶對產(chǎn)品的使用不當(dāng)。如果提供該用戶完備的使用手冊和產(chǎn)品教育會(huì)減少維護(hù)，同時(shí)也是公司的服務(wù)收入。 重組松耦合的子系統(tǒng)進(jìn)行交叉測試 ,孤立問題到某一個(gè)子系統(tǒng)和視圖。 建立故障排除數(shù)據(jù)庫 ,按癥狀檢索。 學(xué)會(huì)簡化和實(shí)質(zhì)化故障到一個(gè)最簡案例 (KISS原則 ) 維護(hù)階段的工作流程 產(chǎn)品補(bǔ)丁及升級 面臨的問題 –容易忽視新需求和老需求兼容性。 –容易忽視多項(xiàng)并行再開發(fā)的 盲點(diǎn) 。 –難于管理跨空間和時(shí)間的代碼資源。 –同步進(jìn)行的維護(hù)和開發(fā)互相干擾。 –部署補(bǔ)丁存在風(fēng)險(xiǎn)和重要性的矛盾。 開發(fā)盲點(diǎn)例子 多流覽器支持 開發(fā)日歷構(gòu)件 支持從右到左的 阿拉伯語言 再開發(fā)和產(chǎn)品布丁及升級 解決方案。 – 新需求和老需求要?dú)w并成一個(gè)統(tǒng)一的新需求。 – 多項(xiàng)并行需求交叉點(diǎn)的實(shí)現(xiàn)責(zé)任要落實(shí)到其中一個(gè)開發(fā)組或錯(cuò)開進(jìn)度。 – 代碼加鎖和授權(quán)。 – 了解代碼視圖 分支 和 歸并 。 分支的空間分布和重要性風(fēng)險(xiǎn)度區(qū)別。 分支的倆種形式的時(shí)機(jī)，優(yōu)缺點(diǎn)比較和適用范圍。 歸并的兩種形式的使用時(shí)機(jī)。 – 越靠近客戶的視圖分支要穩(wěn)定，所以只有風(fēng)險(xiǎn)低和重要性大的才授權(quán)。 – 重構(gòu) (refactoring)體系結(jié)構(gòu) 歸并的例子 主產(chǎn)品視圖 子項(xiàng)目開發(fā)視圖 分支 上歸并 上歸并 下歸并 階段 1 階段 2 階段 3 客戶方正在使用的視圖 上線 維護(hù)員的工作范圍 開發(fā)員的工作范圍 歸并重要的工作單 分支視圖的空間分布 定義 修改頻率 修改風(fēng)險(xiǎn) 權(quán)限控制 子視圖 開發(fā)視圖 頻繁 小 弱 主視圖 主產(chǎn)品視圖 經(jīng)常 中 嚴(yán) 客戶視圖 已部署的客戶正在使用的視圖 很少 大 很嚴(yán) 分支的倆種形式 靜態(tài)視圖 (static view or snapshot view) – 是對特定時(shí)間和空間的代碼的一個(gè)全部截取的備份。 – 適合密集型短期開發(fā)的項(xiàng)目或標(biāo)記部署到客戶端的視圖。 – 開發(fā)中間一般不作上歸并 , 只在結(jié)束后迅速下歸并。 動(dòng)態(tài)視圖 (dynamic view or floating view) – 是一個(gè)隨時(shí) ” 浮 ” 在主產(chǎn)品線上的子視圖。 – 子視圖未修改的文件不存在副本，而直接引用主視圖， 并隨主視圖變化。 – 子視圖修改的文件分支出新副本，以后要經(jīng)常上歸并以保證子主視圖同步更新。 – 適合非密集型長期開發(fā)的項(xiàng)目。 歸并的兩種形式 上歸并 –從主視圖到子視圖歸并，以保證子視圖與主視圖同步。 –只在項(xiàng)目開發(fā)的每個(gè)中間階段的末期進(jìn)行， 為了綜合測試。 下歸并 –從主視圖到子視圖歸并。 –只在項(xiàng)目開發(fā)的末期進(jìn)行，標(biāo)志項(xiàng)目開發(fā)的結(jié)束。 再開發(fā)階段的工作流程 再開發(fā)和最初的原始開發(fā)的相同點(diǎn)是： – 都要經(jīng)歷需求，計(jì)劃，設(shè)計(jì)，編程，測試，部署和維護(hù)。工作流程是基本一致的。 再開發(fā)和最初的原始開發(fā)的不同點(diǎn)是： – 原始開發(fā)是從零開始。 – 再開發(fā)是在原始開發(fā)的基礎(chǔ)上，積累和修改所有各個(gè)階段的成果。 產(chǎn)品補(bǔ)丁及升級 工具介紹。（ Borland StarTeam, Microsoft SourceSafe, Rational ClearCase） – 權(quán)限和共享控制。 – 智能自動(dòng)代碼歸并。 – 對修改歷史進(jìn)行標(biāo)記，查詢，比較和取消。 – 與開發(fā)軟件直接集成。 (自動(dòng)授權(quán)和更新 ) – 對分枝視圖的發(fā)展歷史和分支歸并的關(guān)系用時(shí)間樹形象表達(dá) 。 體會(huì) 充分利用代碼管理工具的各種功能會(huì)很大的提高開發(fā)效率。 這三中工具各有千秋： – StarTeam 自動(dòng)歸并算法不可靠。 – ClearCase 查詢分類界面不好，但樹圖很直觀。 – SourceSafe 查詢分類快。 軟件評估和優(yōu)化的 技術(shù)和工具 評估軟件的健康性和復(fù)雜度和測試指標(biāo) 評估性能和速度和內(nèi)存卸露 軟件的可維護(hù)性 評估軟件的健康性和復(fù)雜度和測試指標(biāo) 工具介紹 （ McCabe, Together） 一些指標(biāo)的定義和工程上的使用價(jià)值。 – 靜態(tài)指標(biāo) Integration Coverage Metrics Cyclomatic Complexity Essential Complexity Module Design Complexity Design Complexity Pathological Complexity – 動(dòng)態(tài)指標(biāo) Path Coverage Metrics Branch Coverage Metrics 評估性能和速度和內(nèi)存卸露 工具介紹 – Java – Jprobe, Borland Optimizeit – JavaScript – Tito Web Studio – C++ Rational Suite Purify and Unify 分析和優(yōu)化技巧 – 在開發(fā)不同階段采樣，比較 profile 和 snapshot – 按指標(biāo)排序，安優(yōu)先權(quán)優(yōu)化 (cost/effect) – 注意優(yōu)化是不同軟件指標(biāo)的轉(zhuǎn)化，一般存在負(fù)面代價(jià)，要衡量得失，只在最需要的地方作。（舉例：循環(huán)效率） 軟件的可維護(hù)性 編碼格式和規(guī)范 –團(tuán)對精神 —犧牲小我尋求統(tǒng)一。 –自動(dòng)代碼檢查。 工具介紹（ WASD ， JDeveloper 自動(dòng)審查功能，自動(dòng)格式化 ， javadoc） 其它 – ISO 9000是 企業(yè)的合格證書 – Wiki百科是將來共享知識庫 – 為何軟件開發(fā)外資到印度多與中國 – 版權(quán)收入到服務(wù)收入的轉(zhuǎn)變 – 擁有專利是保護(hù) 企業(yè)的手段 – 數(shù)據(jù)安全不可忽視 – 內(nèi)部訓(xùn)練技術(shù)水平顯示企業(yè)的成熟 – 何時(shí)軟件也要變成 ” Made in China”