測(cè)試計(jì)劃安排與進(jìn)度監(jiān)控匯總

1、測(cè)試計(jì)劃安排與進(jìn)度監(jiān)控如果要測(cè)試一個(gè)大型系統(tǒng)， 將面對(duì)在一年甚至更長(zhǎng)的時(shí)間內(nèi)編寫、 執(zhí)行、 驗(yàn)證成千上萬(wàn)的測(cè) 試用例，處理上千的模塊，修訂成千上萬(wàn)的錯(cuò)誤，雇用上千的員工，顯然，這將在計(jì)劃、監(jiān) 視、控制測(cè)試過(guò)程中面對(duì)無(wú)窮的項(xiàng)目管理方面的挑戰(zhàn)。在計(jì)劃一個(gè)測(cè)試過(guò)程時(shí)， 主要的錯(cuò)誤是默許對(duì)不發(fā)現(xiàn)任何錯(cuò)誤的假設(shè)， 這種錯(cuò)誤明顯的 后果是大大低估了計(jì)劃資源（人、時(shí)間、計(jì)算機(jī)） ，這是計(jì)算機(jī)工業(yè)聲名狼籍的一個(gè)問(wèn)題。良好測(cè)試計(jì)劃的組成：1）目標(biāo)：必須定義每個(gè)測(cè)試階段的目標(biāo)。（2）完成準(zhǔn)則：設(shè)計(jì)準(zhǔn)則來(lái)指定判斷每個(gè)測(cè)試階段何時(shí)完成。（3）進(jìn)度：每個(gè)階段都需要日程安排，指出何時(shí)設(shè)計(jì)、編寫、執(zhí)行測(cè)試用例。（4）職責(zé)：

2、每個(gè)階段必須識(shí)別設(shè)計(jì)、編寫、執(zhí)行和驗(yàn)證測(cè)試用例的人員，修訂被發(fā)現(xiàn) 的錯(cuò)誤的人員。 在大型項(xiàng)目中， 會(huì)引起有些測(cè)試結(jié)果是否是錯(cuò)誤的爭(zhēng)論， 所以需要識(shí)別仲裁5）測(cè)試用例庫(kù)和標(biāo)準(zhǔn)：在一個(gè)大型項(xiàng)目中，必須要有系統(tǒng)的關(guān)于識(shí)別、編寫、存儲(chǔ)測(cè)試用例的方法。（6）工具：識(shí)別所需的測(cè)試工具，包括誰(shuí)將開發(fā)或去獲取工具，工具將如何被使用，何時(shí)是必需的。（7）計(jì)算機(jī)時(shí)間：這是關(guān)于每個(gè)測(cè)試階段所需的計(jì)算機(jī)時(shí)間的總量的計(jì)劃，包括編譯 應(yīng)用程序的服務(wù)器、安裝測(cè)試的桌面機(jī)、WEB應(yīng)用的 WEB服務(wù)器、網(wǎng)絡(luò)設(shè)備等。（8）硬件配置：如果需要特殊的硬件配置或設(shè)備，需要一個(gè)計(jì)劃來(lái)描述這種需求，它 們?nèi)绾螡M足、何時(shí)需要。（9）集成：測(cè)

3、試計(jì)劃的一部分是定義程序如何結(jié)合在一起（如增量從上到下的測(cè)試） 一個(gè)包含大量子系統(tǒng)或程序的系統(tǒng)可以增量地結(jié)合起來(lái)。使用從上到下或從下到上的方法， 但是構(gòu)造塊是程序或子系統(tǒng)，不是模塊。如果情況是這樣的，那么需要一個(gè)系統(tǒng)基礎(chǔ)計(jì)劃。 系統(tǒng)集成計(jì)劃定義了集成的次序， 系統(tǒng)每個(gè)版本的功能， 有責(zé)任去創(chuàng)建“腳手架”代碼來(lái)仿 真不存在的部件的功能。（ 10）跟蹤過(guò)程： 定義了機(jī)制來(lái)跟蹤測(cè)試過(guò)程的方方面面，包括傾向于錯(cuò)誤的模塊的定位、計(jì)劃、資源、完成準(zhǔn)則等各方面進(jìn)展的估計(jì)。（11）調(diào)試過(guò)程：定義了機(jī)制來(lái)報(bào)告檢測(cè)到的錯(cuò)誤，跟蹤糾正的進(jìn)展，將糾正好的添加 到系統(tǒng)中。計(jì)劃、職責(zé)、工具、計(jì)算機(jī)時(shí)間 / 資源都是調(diào)試計(jì)

4、劃的組成部分。（12）回歸測(cè)試：作了功能改進(jìn)或?qū)Τ绦蛐抻喓?，需要?zhí)行回歸測(cè)試。目的是確定改變 是否已經(jīng)回歸了程序的其他方面， 一般是通過(guò)重新允許程序的測(cè)試用例的子集來(lái)執(zhí)行。 回歸 測(cè)試的重要性在于變更和糾錯(cuò)傾向于產(chǎn)生更多的錯(cuò)誤， 所以一份回歸測(cè)試的計(jì)劃 （誰(shuí)、如何、 何時(shí)）是有必要的。如何制定軟件項(xiàng)目測(cè)試計(jì)劃摘要 隨著測(cè)試 走向規(guī)范化管理， 測(cè)試 計(jì)劃成為測(cè)試經(jīng)理必須完成的重要任務(wù)之 一，本文根據(jù)實(shí)踐經(jīng)驗(yàn)結(jié)合理論，探討如何制定軟件項(xiàng)目測(cè)試計(jì)劃。關(guān)鍵字 測(cè)試計(jì)劃 變更正文 軟件測(cè)試計(jì)劃作為軟件項(xiàng)目計(jì)劃的子計(jì)劃，在項(xiàng)目啟動(dòng)初期是必須規(guī)劃的。 在越來(lái)越多公司的軟件開發(fā)中， 軟件質(zhì)量日益受到重視， 測(cè)

5、試過(guò)程也從一個(gè)相對(duì) 獨(dú)立的步驟越來(lái)越緊密嵌套在軟件整個(gè)生命周期中， 這樣，如何規(guī)劃整個(gè)項(xiàng)目周 期的測(cè)試工作；如何將測(cè)試工作上升到測(cè)試管理的高度都依賴于測(cè)試計(jì)劃的制 定。測(cè)試計(jì)劃因此也成為測(cè)試工作的賴于展開的基礎(chǔ)。一個(gè)好的測(cè)試計(jì)劃可以起到如下作用1 避免測(cè)試的“事件驅(qū)動(dòng)”2 使測(cè)試工作和整個(gè)開發(fā)工作融合起來(lái)3 資源和變更事先作為一個(gè)可控制的風(fēng)險(xiǎn)測(cè)試計(jì)劃的模板在各個(gè)公司中都大同小異， 在個(gè)人實(shí)踐中發(fā)現(xiàn)， 測(cè)試計(jì)劃制 定中存在的問(wèn)題具有相似性， 下面重點(diǎn)就這些相似的問(wèn)題談?wù)勅绾沃贫ㄜ浖?xiàng)目 測(cè)試計(jì)劃。問(wèn)題一：測(cè)試階段劃分 就通常軟件項(xiàng)目而言，基本上采用“瀑布型”開發(fā)方式，這種開發(fā)方式下， 各個(gè)項(xiàng)目主

6、要活動(dòng)比較清晰， 易于操作。 整個(gè)項(xiàng)目生命周期為“需求設(shè)計(jì)編 碼測(cè)試發(fā)布實(shí)施維護(hù)”。 然而，在制定測(cè)試計(jì)劃時(shí)候， 有些測(cè)試經(jīng)理對(duì) 測(cè)試的階段劃分還不是十分明晰， 經(jīng)常性遇到的問(wèn)題是把測(cè)試單純理解成系統(tǒng)測(cè) 試，或者把把各類型測(cè)試設(shè)計(jì) （測(cè)試用例的編寫和測(cè)試數(shù)據(jù)準(zhǔn)備） 全部放入生命 周期的“測(cè)試階段”，這樣造成的問(wèn)題是浪費(fèi)了開發(fā)階段可以并行的項(xiàng)目日程， 另一方面造成測(cè)試不足。合理的測(cè)試階段應(yīng)遵循下面劃分方法：照上圖所述， 相應(yīng)階段可以同步進(jìn)行相應(yīng)的測(cè)試計(jì)劃編制， 而測(cè)試設(shè)計(jì)也可 以結(jié)合在開發(fā)過(guò)程中實(shí)現(xiàn)并行， 測(cè)試的實(shí)施即執(zhí)行測(cè)試的活動(dòng)即可連貫在開發(fā)之 后。值得注意的是： 單元測(cè)試和集成測(cè)試往往由開

7、發(fā)人員承擔(dān)， 因此這部分的階 段劃分可能會(huì)安排在開發(fā)計(jì)劃而不是測(cè)試計(jì)劃中。問(wèn)題二：系統(tǒng)測(cè)試階段日程安排 劃分階段清楚了，隨之而來(lái)的問(wèn)題是測(cè)試執(zhí)行需要多長(zhǎng)的時(shí)間？標(biāo)準(zhǔn)的工程 方法或 CMM 方式是對(duì)工作量進(jìn)行估算，然后得出具體的估算值。但是這種方 法過(guò)于復(fù)雜， 可以另辟專題討論。 一個(gè)可操作的簡(jiǎn)單方法是： 根據(jù)測(cè)試執(zhí)行上一 階段的活動(dòng)時(shí)間進(jìn)行換算， 換算方法是與上一階段活動(dòng)時(shí)間 1 ：1 。11 。5左右。 舉個(gè)例子， 對(duì)測(cè)試經(jīng)理來(lái)說(shuō)， 因?yàn)殚_發(fā)計(jì)劃可能包含了單元測(cè)試和集成測(cè)試， 系 統(tǒng)測(cè)試的時(shí)間大概是編碼階段（包含單元測(cè)試和集成測(cè)試） 1 到1。5倍。這種方 法的優(yōu)點(diǎn)是簡(jiǎn)單，依賴于項(xiàng)目計(jì)劃的日

8、程安排，缺點(diǎn)是水分太多，難于量化。那 么，可以采用的另一個(gè)簡(jiǎn)單方法是經(jīng)驗(yàn)評(píng)估。評(píng)估方法如下：1 計(jì)算需求文檔的頁(yè)數(shù)，得出系統(tǒng)測(cè)試用例的頁(yè)數(shù) 需求頁(yè)數(shù)：系統(tǒng)測(cè)試用例頁(yè)數(shù) 1 ：1 2 由系統(tǒng)測(cè)試用例頁(yè)數(shù)計(jì)算編寫系統(tǒng)測(cè)試用例時(shí)間 編寫系統(tǒng)測(cè)試用例時(shí)間 系統(tǒng)測(cè)試用例頁(yè)數(shù)× 1小時(shí) 3 計(jì)算執(zhí)行系統(tǒng)測(cè)試用例時(shí)間編寫系統(tǒng)用例用時(shí)：執(zhí)行系統(tǒng)測(cè)試用時(shí) 1 ： 24 計(jì)算回歸測(cè)試包含的時(shí)間系統(tǒng)測(cè)試用時(shí)：回歸測(cè)試用時(shí) 2： 1注：以上比值是個(gè)人工程經(jīng)驗(yàn)值， 需要更正比值的測(cè)試經(jīng)理可以在具體實(shí)踐 中收集數(shù)據(jù)。基于以上方法優(yōu)點(diǎn)是需求為已知的， 可以利用已知來(lái)推算未知， 適用于需求 是已知且相對(duì)穩(wěn)定的情況下

9、； 缺點(diǎn)是處于研發(fā)狀態(tài)的項(xiàng)目， 需求不清晰的時(shí)候比 較難計(jì)算?，F(xiàn)套用一個(gè)例子加于說(shuō)明：需求文檔頁(yè)數(shù)為 500 ，系統(tǒng)測(cè)試用例頁(yè)數(shù) 推算為 500 ，則編寫系統(tǒng)測(cè)試用例時(shí)間為 500 小時(shí)，執(zhí)行系統(tǒng)測(cè)試用例時(shí)間為 1000小時(shí)，回歸測(cè)試需要 500小時(shí)，加起來(lái)總共為 2000 小時(shí)，按一天8小時(shí)計(jì)算， 共計(jì)250個(gè)工作日/人；假如一個(gè)月為 22個(gè)工作日，則共計(jì)約 11人/月，即投入 4 個(gè)人需要 3個(gè)月左右時(shí)間工作量完成。當(dāng)然，這是系統(tǒng)測(cè)試需要的全部時(shí)間。根 據(jù)測(cè)試階段劃分原則， 設(shè)計(jì)用例時(shí)間可以和開發(fā)同步進(jìn)行， 只需在測(cè)試階段中安 排的時(shí)間為 1500 小時(shí)即 4人2個(gè)月工作量。（測(cè)試經(jīng)理在編

10、寫測(cè)試計(jì)劃時(shí)候，測(cè)試進(jìn)度中的計(jì)劃開始 / 結(jié)束時(shí)間往往用 如 2005010-20051201 的具體時(shí)間劃分方式，這樣引起的問(wèn)題是當(dāng)項(xiàng)目計(jì)劃進(jìn) 行變更的時(shí)候，測(cè)試計(jì)劃時(shí)間不得不隨時(shí)調(diào)整，這種變更可能是頻繁而瑣碎的， 可以替代的辦法是取消這種方式， 采用30工作日 /2 人或者 2人月這種工作量記錄 方式，這樣一來(lái)， 只需在項(xiàng)目計(jì)劃中跟蹤階段的具體開始時(shí)間即可， 不必反復(fù)修 改測(cè)試計(jì)劃。）值得注意的是： 國(guó)內(nèi)大多數(shù)公司的測(cè)試時(shí)間都是不足的， 不可能按照這樣的 理想比例進(jìn)行運(yùn)作，因?yàn)闇y(cè)試執(zhí)行的時(shí)間實(shí)際上不可能占據(jù)整個(gè)項(xiàng)目周期的 1/2 ， 甚至要短于其中任何一個(gè)項(xiàng)目階段時(shí)間。 即使是微軟的測(cè)試結(jié)

11、束原則也并不是完 成所有必需的測(cè)試，而是測(cè)試在按計(jì)劃結(jié)束的那一天結(jié)束！在測(cè)試時(shí)間不足的情況下，可參考下面項(xiàng)目計(jì)劃變更時(shí)的做法，因?yàn)橛?jì)劃變 更也涉及到測(cè)試時(shí)間不足的情況。問(wèn)題三：變更的控制測(cè)試計(jì)劃改變了已往根據(jù)任務(wù)進(jìn)行測(cè)試的方式， 因此，為使測(cè)試計(jì)劃得到貫 徹和落實(shí)，測(cè)試組人員必須及時(shí)跟蹤軟件開發(fā)的過(guò)程，對(duì)產(chǎn)品提交測(cè)試做準(zhǔn)備， 測(cè)試計(jì)劃的目的， 本身就是強(qiáng)調(diào)按規(guī)劃的測(cè)試戰(zhàn)略進(jìn)行測(cè)試， 淘汰以往以任務(wù)為 主的臨時(shí)性。在這種情況下，測(cè)試計(jì)劃中強(qiáng)調(diào)對(duì)變更的控制顯得尤為重要。變更來(lái)源于以下幾個(gè)方面1 項(xiàng)目計(jì)劃的變更2 需求的變更3 測(cè)試產(chǎn)品版本的變更4 測(cè)試資源的變更測(cè)試階段的風(fēng)險(xiǎn)主要是對(duì)上述變更所造成

12、的不確定性， 有效的應(yīng)對(duì)這些變更 就能降低風(fēng)險(xiǎn)發(fā)生的幾率。 要想計(jì)劃本身不成為空談和空白無(wú)用的紙質(zhì)文檔， 對(duì) 不確定因素的預(yù)見和事先防范必須做到心中有數(shù)。對(duì)于項(xiàng)目計(jì)劃的變更， 除了測(cè)試人員及時(shí)跟進(jìn)項(xiàng)目以外， 項(xiàng)目經(jīng)理必須認(rèn)識(shí) 到測(cè)試組也是項(xiàng)目成員， 因此必須把這些變更信息及時(shí)通知到項(xiàng)目組， 使得整個(gè) 項(xiàng)目得到順延。 項(xiàng)目計(jì)劃變更一般涉及都是日程變更， 令人遺憾的是， 往往為了 進(jìn)度的原因，交付期限是既定的，項(xiàng)目經(jīng)理不得不減少測(cè)試的時(shí)間，這樣，執(zhí)行 測(cè)試的時(shí)間就被壓縮了。 在這種情況下， 測(cè)試經(jīng)理常常固執(zhí)的認(rèn)為進(jìn)度縮減的唯 一的方法就是向上級(jí)通報(bào)并主觀認(rèn)為產(chǎn)品質(zhì)量一定會(huì)下降， 這種做法和想法不一

13、 定是正確的。由于時(shí)間不足，不能“完美”的執(zhí)行所有測(cè)試，為了保證質(zhì)量，第 一種辦法是調(diào)整測(cè)試計(jì)劃中的測(cè)試策略和測(cè)試范圍， 實(shí)踐中測(cè)試經(jīng)理常常忽略測(cè) 試計(jì)劃的這個(gè)章節(jié)。 調(diào)整的目的是重新檢查不重要的測(cè)試部分， 調(diào)換測(cè)試的次序 和減少測(cè)試規(guī)模， 對(duì)測(cè)試類型重新組合擇優(yōu)， 力求在限定時(shí)間內(nèi)做最重要部分的 測(cè)試，可以把忽略部分留給確認(rèn)測(cè)試或現(xiàn)場(chǎng)測(cè)試。 其他應(yīng)對(duì)辦法包括減少進(jìn)入測(cè) 試的阻力，例如降低測(cè)試計(jì)劃中系統(tǒng)測(cè)試準(zhǔn)入準(zhǔn)則； 分步提交測(cè)試， 例如改成迭 代方式增量測(cè)試； 減少回歸測(cè)試的要求， 例如開發(fā)人員實(shí)時(shí)修改， 在測(cè)試計(jì)劃中 對(duì)缺陷修復(fù)響應(yīng)時(shí)間和過(guò)程進(jìn)行約定； 和公司 QA 商量進(jìn)行簡(jiǎn)化配置管理，

14、 跳過(guò) 正式發(fā)布環(huán)節(jié)；缺陷進(jìn)行局部回歸而不是重新全部測(cè)試等等。第二：項(xiàng)目進(jìn)行過(guò)程中最不可避免的就是需求的變更。 那么，測(cè)試計(jì)劃中就 不能進(jìn)行控制和約束的嗎？答案是未必。 當(dāng)制定計(jì)劃時(shí)， 如果項(xiàng)目需求處于動(dòng)態(tài) 變化時(shí)，在測(cè)試用例章節(jié)就要進(jìn)行說(shuō)明。許多測(cè)試經(jīng)理在編制測(cè)試用例時(shí)往往沒(méi)有把測(cè)試用例和測(cè)試數(shù)據(jù)進(jìn)行區(qū)分， 因此，造成的問(wèn)題是當(dāng)需求變化時(shí)辛辛苦苦設(shè)計(jì)的數(shù)據(jù)就作廢了。 在這時(shí)， 假使 面臨一個(gè)需求動(dòng)態(tài)的項(xiàng)目， 必須在計(jì)劃中對(duì)需求變更造成的測(cè)試 （設(shè)計(jì)） 方式變 化進(jìn)行說(shuō)明，例如采用用例和數(shù)據(jù)分離、 流程和界面分離、 字典項(xiàng)和數(shù)據(jù)元素分 離的設(shè)計(jì)方式， 然后等到最終需求確定后細(xì)化測(cè)試設(shè)計(jì)； 另一

15、個(gè)方面是最好制定 一個(gè)變更周期的約定尤其在執(zhí)行測(cè)試階段發(fā)現(xiàn)需求的變更定義變更的 最大頻度和重新測(cè)試的界限， 計(jì)劃從一定程度上能夠降低不可預(yù)期需求變化造成 的投入損失。值得注意的是： 需求發(fā)生變更時(shí)測(cè)試經(jīng)理額外的工作是記住要在需 求跟蹤矩陣上做記錄。對(duì)于測(cè)試產(chǎn)品版本的變更， 除了部分是由于需求變更造成之外， 很有可能是 由于修改缺陷引發(fā)的問(wèn)題或配置管理不嚴(yán)格造成。 眾所周知， 測(cè)試必須是基于一 個(gè)穩(wěn)定的“基線”進(jìn)行， 否則，因反復(fù)修改造成測(cè)試資源和開發(fā)資源的浪費(fèi)是可 觀的。合理的測(cè)試計(jì)劃在章節(jié)中應(yīng)增加一個(gè)測(cè)試更新管理的章節(jié)， 在此章節(jié)明確 更新周期和暫停測(cè)試的原則。 例如， 小版本的產(chǎn)品更新不能

16、大于每天三次， 一個(gè) 相對(duì)大的版本不能每周大于 1次，規(guī)定緊急發(fā)布產(chǎn)品僅限于何種類型的修改或變 更，由誰(shuí)負(fù)責(zé)統(tǒng)一維護(hù)和同步更新測(cè)試環(huán)境。 測(cè)試計(jì)劃通常制定了準(zhǔn)入和準(zhǔn)出準(zhǔn) 則，這是不夠的， 要考慮測(cè)試暫停的時(shí)候， 產(chǎn)品錯(cuò)誤發(fā)布或者 服務(wù)器數(shù)據(jù)更新就 是一個(gè)例子， 暫停的時(shí)候如果測(cè)試經(jīng)理不進(jìn)行跟蹤， 可能發(fā)生測(cè)試組等待測(cè)試而 沒(méi)人通知繼續(xù)測(cè)試的情況，所以，增加更新周期和暫停測(cè)試原則是很有必要的。最后，測(cè)試資源的變更是源自測(cè)試組內(nèi)部的風(fēng)險(xiǎn)而非開發(fā)組風(fēng)險(xiǎn)， 當(dāng)測(cè)試資 源不足或者沖突， 測(cè)試部門不可能安排如此多的人手和足夠時(shí)間參與測(cè)試時(shí)， 在 測(cè)試計(jì)劃中的控制方法與測(cè)試時(shí)間不足相類似。 沒(méi)有測(cè)試經(jīng)理愿意

17、承擔(dān)資源不足 的測(cè)試工作，只能說(shuō)公司本身是否具備以質(zhì)量為主的體系或者項(xiàng)目經(jīng)理對(duì)產(chǎn)品質(zhì) 量的重視程度如何決定了對(duì)測(cè)試資源投入的大小， 最終產(chǎn)品質(zhì)量取決因素不僅僅 在于測(cè)試經(jīng)理。 為了排除這種風(fēng)險(xiǎn)， 除了象時(shí)間不足、 測(cè)試計(jì)劃變更時(shí)那樣縮減 測(cè)試規(guī)模等等方法以外， 測(cè)試經(jīng)理必須在人力資源和測(cè)試環(huán)境一欄標(biāo)出明確需要 保證的資源，否則，必須將這個(gè)問(wèn)題作為風(fēng)險(xiǎn)記錄。規(guī)避風(fēng)險(xiǎn)的辦法可能有： 一，項(xiàng)目組的需求和實(shí)施人員參與系統(tǒng)測(cè)試； 二，抽調(diào)不同模塊開發(fā)者進(jìn)行交叉系統(tǒng)測(cè)試或借用其他項(xiàng)目開發(fā)人員； 三，組織客戶方進(jìn)行確認(rèn)測(cè)試或發(fā)布 版本。盡管上面盡可能的描述了測(cè)試計(jì)劃如何制定才能“完美”， 但是還存在的問(wèn) 題

18、是對(duì)測(cè)試計(jì)劃的管理和監(jiān)控。 一份計(jì)劃投入再多的時(shí)間去做也不能保證按照這 份計(jì)劃進(jìn)行實(shí)施。 好的測(cè)試計(jì)劃是成功的一半， 另一半是對(duì)測(cè)試計(jì)劃的執(zhí)行。 對(duì) 小項(xiàng)目而言，一份更易于操作的測(cè)試計(jì)劃更為實(shí)用，對(duì)中型乃至大型項(xiàng)目來(lái)看， 測(cè)試經(jīng)理的測(cè)試管理能力就顯得格外重要， 要確保計(jì)劃不折不扣的執(zhí)行下去， 測(cè) 試經(jīng)理的人際諧調(diào)能力， 項(xiàng)目測(cè)試的操作經(jīng)驗(yàn)、 公司的質(zhì)量現(xiàn)狀都能夠?qū)?xiàng)目測(cè) 試產(chǎn)生足夠的影響。 另外，計(jì)劃也是“動(dòng)態(tài)的”！ 不必要把所有的因素都可能囊 括進(jìn)去，也不必要針對(duì)這種變化額外制定“計(jì)劃的計(jì)劃”， 測(cè)試計(jì)劃制定不能在 項(xiàng)目開始后束之高閣， 而是緊追項(xiàng)目的變化， 實(shí)時(shí)進(jìn)行思考和貫徹， 根據(jù)現(xiàn)實(shí)修

19、 改，然后成功實(shí)施， 這才能實(shí)現(xiàn)測(cè)試計(jì)劃的最終目標(biāo)保證項(xiàng)目最終產(chǎn)品的質(zhì) 量！軟件開發(fā)是一項(xiàng)復(fù)雜的、 創(chuàng)造性的協(xié)作式游戲。作為游戲它自然存在著樂(lè)趣， 所以程序員們才會(huì)樂(lè)此不疲， 前仆后繼。 首先、這種快樂(lè)源于一種創(chuàng)造事物的快 樂(lè)。其次、 這種快樂(lè)來(lái)自于一種開發(fā)出對(duì)別人有用的東西時(shí)所帶來(lái)的滿足感。 第 三、快樂(lè)源自開發(fā)過(guò)程中， 親眼看到軟件按自己預(yù)先設(shè)想的那種效果運(yùn)行時(shí)所帶 來(lái)的迷人魅力。第四、快樂(lè)源自開發(fā)過(guò)程中持續(xù)學(xué)習(xí)的快樂(lè)。最后、快樂(lè)源自開 發(fā)過(guò)程中， 我們能象詩(shī)人一樣， 僅憑自己的想像， 來(lái)建造自己的城堡時(shí)帶來(lái)的快 樂(lè)。編程的快樂(lè)在于它不僅滿足了我們內(nèi)心深處進(jìn)行創(chuàng)建的渴望， 而且還喚醒了 每

20、個(gè)人內(nèi)心的情感。不幸的是，同樣作為游戲它也有苦惱的一面：首先、苦惱來(lái) 自追求完美主義。 其次、苦惱來(lái)自總是由他人來(lái)設(shè)定目標(biāo)、 供給資源、提供信息。 第三、苦惱來(lái)自于尋找瑣碎的 BUG 卻是一項(xiàng)枯燥的、重復(fù)性的活動(dòng)。第四、人 們通常希望在項(xiàng)目接近結(jié)束時(shí)，能收斂得快一些，然而，情況卻是越接近完成， 收斂得越慢。 最后、苦惱來(lái)自當(dāng)投入大量的辛苦勞動(dòng)后， 產(chǎn)品發(fā)布時(shí)卻面臨著陳 舊過(guò)時(shí)的危險(xiǎn)。作為軟件開發(fā)者，我們別無(wú)選擇，只有適應(yīng)它們，就這樣痛并快 樂(lè)著地面對(duì)每一天。來(lái)自領(lǐng)導(dǎo)的信息只有 25%被下級(jí)知道并正確理解， 從下到上的反饋信息不超 過(guò)10% ，平等交流的信息則可達(dá)到 90% 以上。平等造就信任，

21、信任增進(jìn)交流。 有效地進(jìn)行適當(dāng)?shù)囊庖娊涣鳎?對(duì)一個(gè)組織的氣候和生產(chǎn)力會(huì)產(chǎn)生有益和積極的影 響。使顧客滿意并和他們面對(duì)面地交流，才是蠃得市場(chǎng)的關(guān)鍵。引自管 理智典管理是一種控制性游戲，在游戲面前，你只有二種選擇：或者，你確信自己 能蠃，于是投入足夠多的能量來(lái)蠃得一切；或者，你不進(jìn)行這個(gè)游戲，放棄它。 然而，作為軟件項(xiàng)目管理者，你也應(yīng)該知道，早投入、高風(fēng)險(xiǎn)才會(huì)有高回報(bào)。逃 避風(fēng)險(xiǎn)是致命的， 因?yàn)檫@也會(huì)讓你得不到與風(fēng)險(xiǎn)同在的利益， 久而久之， 你就會(huì) 面臨著被市場(chǎng)淘汰的危險(xiǎn)。風(fēng)險(xiǎn)是 "遭受損失的可能性 "，由條件、結(jié)果以及周圍 的環(huán)境構(gòu)成。 風(fēng)險(xiǎn)和問(wèn)題的區(qū)別在于： 風(fēng)險(xiǎn)是尚未發(fā)生

22、的問(wèn)題， 而問(wèn)題是業(yè)也成真的風(fēng)險(xiǎn)，昨天的風(fēng)險(xiǎn)可能會(huì)是今天的問(wèn)題。風(fēng)險(xiǎn)管理主要包括下面幾個(gè)方面： 第一、風(fēng)險(xiǎn)識(shí)別：從頭腦想像中抽取出各種風(fēng)險(xiǎn)并加以篩選， 再加上在整個(gè)開發(fā)過(guò)程中， 保持 持續(xù)不斷的風(fēng)險(xiǎn)發(fā)現(xiàn)機(jī)制，以發(fā)現(xiàn)新的風(fēng)險(xiǎn)。第二、風(fēng)險(xiǎn)分析： 對(duì)風(fēng)險(xiǎn)出現(xiàn)的可能性和潛在的危害性進(jìn)行量化分析。第三、應(yīng)急計(jì)劃： 如果識(shí)別出的風(fēng)險(xiǎn)真的出現(xiàn)，你將采取的應(yīng)急措施。第四、風(fēng)險(xiǎn)緩解： 為了使應(yīng)急計(jì)劃得以有效實(shí)施，必須在風(fēng)險(xiǎn)轉(zhuǎn)化為真之前所采取的措施。 第五、持續(xù)的監(jiān)控：跟蹤需要管理的風(fēng)險(xiǎn)，尋找風(fēng)險(xiǎn)出現(xiàn)的跡象。 項(xiàng)目面臨的某些風(fēng)險(xiǎn)可能是致命的，發(fā)生時(shí)會(huì)使項(xiàng)目嚴(yán)重滯后或直接廢棄。 這類風(fēng)險(xiǎn)是最需要管理的，但有效的管理

23、它們也許會(huì)使你與你的上級(jí)發(fā)生沖突 （如時(shí)間上最后期限等 ），對(duì)于這類風(fēng)險(xiǎn)往往超出了你的管理權(quán)限，可以先將它們 列為項(xiàng)目假定風(fēng)險(xiǎn)，然后把它們轉(zhuǎn)交給上級(jí)來(lái)管理。風(fēng)險(xiǎn)可能出自技術(shù)、政治、 經(jīng)濟(jì)、資源或其它各個(gè)方面，幾乎無(wú)所不在，并且會(huì)對(duì)項(xiàng)目開發(fā)、市場(chǎng)占有率或 是達(dá)到項(xiàng)目目標(biāo) （如進(jìn)度、預(yù)算、質(zhì)量等）造成災(zāi)難性后果。 但在所有軟件項(xiàng)目中， 通常會(huì)共存五大核心風(fēng)險(xiǎn)，分別如下：第一、缺乏合理的進(jìn)度安排這是導(dǎo)致項(xiàng)目滯后的最主要的原因。 首先、它源于開發(fā)人員們普遍存在的樂(lè) 觀主義精神， 我們總是期待在實(shí)現(xiàn)過(guò)程中不會(huì)碰到困難， 然而我們的構(gòu)思是有缺 陷的，因此總會(huì)發(fā)現(xiàn) BUG 。其次、它源于一種錯(cuò)誤的認(rèn)識(shí)，人員

24、數(shù)量和開發(fā)時(shí) 間是可以互換的， 既投入兩倍的人數(shù)會(huì)在一半時(shí)間內(nèi)完成開發(fā)工作。 然而， 這種 理論卻忽略了隨著人數(shù)的增加， 相應(yīng)的也會(huì)增加新人培訓(xùn)和人們相互交流所需的 負(fù)擔(dān) ,另外，還有任務(wù)重新分配所造成工作中斷帶來(lái)的負(fù)擔(dān)，正如 Alistair Cockburn 所說(shuō)：" 最有效的交流方式是面對(duì)面的交流 "當(dāng)3、5個(gè)人的時(shí)候很容易 做到這種交流方式， 隨著人數(shù)的增長(zhǎng)， 再也很難做到這種交流方式。 交流成本的 增加與培訓(xùn)新人所需時(shí)間成本的增加、以及任務(wù)重分配導(dǎo)致工作中斷成本的增 加，直接導(dǎo)致一種結(jié)果：向進(jìn)度落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后。第三、源于空泛的估算， 管理

25、人員特別是高層管理人員為了滿足顧客期望的 日期而造成的不合理進(jìn)度安排。 如果分配的時(shí)間一開始就不夠， 不管高層領(lǐng)導(dǎo)威 脅有多么嚇人， 工作也無(wú)法按時(shí)完成， 如果人們察覺到管理者可能濫用權(quán)力來(lái)懲 罰自己，他們就會(huì)感覺到威脅，沒(méi)有 安全感。 安全感的缺乏會(huì)讓人們反對(duì)變化， 而在所有成功項(xiàng)目中， 變化是唯一不變的要素之一， 除非感到安全， 否則人們就 不會(huì)去迎接變化， 只會(huì)按部就班， 這樣往往喪失了很多走捷徑的好機(jī)會(huì)， 而這些 機(jī)會(huì)原可以大大縮減時(shí)間進(jìn)度的。 第四、如果你沒(méi)有認(rèn)真估算產(chǎn)品規(guī)模， 那么你 預(yù)計(jì)的進(jìn)度就是空中樓閣， 唯一的依據(jù)只是你的希望。 在估計(jì)產(chǎn)品規(guī)模時(shí)， 除了 正常的時(shí)間計(jì)算以外，

26、 不但應(yīng)該將 " 可能需要做 " 的事情所需工作時(shí)間加上， 還要 將某些 "可能不需要做 "的事情所需工作時(shí)間加上。 項(xiàng)目的超期不應(yīng)歸咎于開發(fā)者 的低效率。最后、項(xiàng)目的滯后不是一下子造成的，而是在一天天的不知不覺中造成的， 有無(wú)數(shù)種方法可以浪費(fèi)一天的時(shí)間， 但是沒(méi)有任何方法可以拿回一天的時(shí)間。 高 層管理者的不良反應(yīng)肯定會(huì)對(duì)信息的完全公開造成壓制； 相反，仔細(xì)區(qū)分狀態(tài)報(bào) 告、毫無(wú)驚慌地接收?qǐng)?bào)告、決不壓制下級(jí)，將能鼓勵(lì)誠(chéng)實(shí)的進(jìn)度匯報(bào)，而這會(huì)使 你在第一時(shí)間掌握實(shí)際進(jìn)度， 把握先機(jī)， 及早做出正確的修訂， 從而避免了晚期 才獲得這些實(shí)際信息時(shí)， 那種無(wú)力挽天

27、時(shí)的無(wú)奈。 此外、也可以在項(xiàng)目管理中設(shè) 定一個(gè)合理的進(jìn)度安排和一個(gè)具有挑戰(zhàn)性的期望目標(biāo)完成時(shí)間。 期望目標(biāo)和合理 進(jìn)度不同，期望目標(biāo)完成時(shí)間，可以設(shè)為項(xiàng)目完成的成功率在 30% 左右時(shí)的日期， 這樣很具有挑戰(zhàn)性， 但不能強(qiáng)迫要求必須完成此期望目標(biāo)。 畢竟，合理進(jìn)度安排 才是更合理的時(shí)間安排。 另外、需要指出的是現(xiàn)代敏捷方法論對(duì)此進(jìn)行了有效改 進(jìn)，如 XP（極限編程 ）中，就利用用戶素材與 CRC 卡，進(jìn)行優(yōu)先級(jí)劃分并進(jìn)行快 速增量迭代開發(fā)，針對(duì)原來(lái)開發(fā)的產(chǎn)品或第一次迭代開發(fā)后的原型完成的功能 量，來(lái)計(jì)算功能點(diǎn)，從而估算每個(gè) CRC 卡的功能點(diǎn)，得到總功能點(diǎn)來(lái)推導(dǎo)出比 較準(zhǔn)確的進(jìn)度安排。第二、需

28、求的變化從項(xiàng)目的角度來(lái)說(shuō)， 需求總是向著膨脹的方向在變化。 就連去掉某些已經(jīng)做 好的東西，也是一種膨脹， 因?yàn)樗黾恿斯ぷ髁俊?開發(fā)人員交付的是用戶滿意程 度，而不僅僅是實(shí)際的產(chǎn)品，用戶的實(shí)際需要會(huì)隨著程序的構(gòu)建和使用而變化。 要知道，一個(gè)活著的軟件必須面對(duì)變化，只有死掉的軟件才不會(huì)有需求變化（沒(méi) 人用了 ），我們應(yīng)該盡早面對(duì)現(xiàn)實(shí)，而不是逃避，事先為它們做好思想準(zhǔn)備。變 化是好事不是什么壞事。 同樣，現(xiàn)代敏捷方法論強(qiáng)調(diào)對(duì)需求變化的快速響應(yīng)， 如 XP（極限編程 ）就采用快速增量迭代開發(fā)， 來(lái)在短時(shí)間內(nèi)開發(fā)出功能不斷增強(qiáng)的原 型軟件提交給用戶使用的方法，來(lái)快速響應(yīng)需求的變化。第三、人員的變更在我

29、們有些管理者中， 總是假設(shè)開發(fā)者都是可以隨便替換的， 新員工馬上可 以取代離去的老員工， 多么愚蠢的假設(shè)。解雇員工或高的員工替換率最大的影響， 是使軟件項(xiàng)目失去了連續(xù)性。 這是在抱著這種假設(shè)的團(tuán)隊(duì)文化中， 大量員工會(huì)在 項(xiàng)目進(jìn)行到一半時(shí)離開，新來(lái)員工往往需要 1到3 個(gè)月的上道時(shí)間，在這段時(shí)間 內(nèi)，他們做不了什么， 還經(jīng)常需要其它老員工的幫助， 從而浪費(fèi)了其它老員工很 多不必要時(shí)間，導(dǎo)致項(xiàng)目進(jìn)展更加緩慢，最終造成項(xiàng)目的很大損失。另外、還有一種現(xiàn)象在中國(guó)軟件事業(yè)中普遍存在，當(dāng)正在進(jìn)行一個(gè)項(xiàng)目時(shí)， 另一個(gè)項(xiàng)目由于進(jìn)度落后或最后期限等原因所致， 高層管理者就會(huì)從你的團(tuán)隊(duì)中 抽掉一些人去到另一個(gè)項(xiàng)目中

30、補(bǔ)墻。 這種拆東墻補(bǔ)西墻的作法， 往往導(dǎo)致的結(jié)果 是兩個(gè)項(xiàng)目都會(huì)落后，因?yàn)樗粌H十分錯(cuò)誤作了團(tuán)隊(duì)人員可以隨意替換的假設(shè)， 而且還作了將開發(fā)人數(shù)與開發(fā)所需時(shí)間可以互換的錯(cuò)誤假設(shè)。 盲目的認(rèn)為， 投入 大量人數(shù)后，新人馬上會(huì)投入新的工作，這樣項(xiàng)目開發(fā)所需時(shí)間就會(huì)成倍縮短。 在這種組織文化中， 是不會(huì)形成一支穩(wěn)定的團(tuán)隊(duì)的， 成員整天只會(huì)忙碌著補(bǔ)自已 的墻或?yàn)閯e人補(bǔ)墻，充當(dāng)著類似消防員的角色，那兒有火那兒就有我們的身影。同樣，現(xiàn)代敏捷方法論非常注重人的能力，如 XP 中通過(guò)權(quán)力下放、教練角 色、將團(tuán)隊(duì)緊密圍在一起并結(jié)對(duì)編程、 小團(tuán)隊(duì)組成等方式， 來(lái)組成一個(gè)強(qiáng)有力的 團(tuán)隊(duì)，由于有凝聚力， 所以很少有大的

31、人員變動(dòng)， 他們往往可以完成兩倍于他們 人數(shù)所能完成的任務(wù)。 非常小的團(tuán)隊(duì)能夠產(chǎn)生非常大的物質(zhì)生產(chǎn)力， 有時(shí)候， 小 團(tuán)隊(duì)可以在很短時(shí)間內(nèi)創(chuàng)造奇跡， 而大型團(tuán)隊(duì)極少能做到。 但是， 小團(tuán)隊(duì)卻往往 得不到足夠的政策支持，從而導(dǎo)致任由團(tuán)隊(duì)超編，這是一種病態(tài)組織文化所致。 作為管理者必須明確知道， 擁有一支穩(wěn)定的、 有凝聚力的開發(fā)團(tuán)隊(duì)是組織最大的 財(cái)富，而不是障礙。第四、規(guī)約崩潰 這種情況只有兩種結(jié)果：要么發(fā)生，要么不發(fā)生，不會(huì)有不同程度的影響。 但它真的發(fā)生時(shí)， 它會(huì)直接毀滅你的整個(gè)項(xiàng)目。 在項(xiàng)目啟動(dòng)之初， 項(xiàng)目各方需要 通過(guò)一系列商談來(lái)確定需求的范圍， 規(guī)約崩潰就是指這個(gè)談判過(guò)程的崩潰。 在商

32、談期間， 很多時(shí)候當(dāng)遇到嚴(yán)重沖突時(shí)， 由于雙方都不愿意讓步， 但又不想放棄這 個(gè)項(xiàng)目，從而導(dǎo)致這些沖突被掩蓋起來(lái)。 最終項(xiàng)目便朝著一個(gè)帶著缺陷的、 含混 不清的目標(biāo)前進(jìn)了， 被掩蓋的問(wèn)題暫時(shí)不會(huì)打擾你， 但不是永遠(yuǎn)。 盡管你可以含 混說(shuō)明一個(gè)產(chǎn)品， 但不能含混構(gòu)造一個(gè)產(chǎn)品， 所以，最終在項(xiàng)目晚期這些問(wèn)題將 發(fā)生，在大半甚至所有預(yù)算時(shí)間和金錢都已付出的時(shí)候， 此時(shí)， 任何一方不再全 力支持，都將使項(xiàng)目被取消。 任何規(guī)格文檔中的含糊標(biāo)志著不同的系統(tǒng)參與者之 間存在著未解決的沖突。 只要在開發(fā)過(guò)程中有多個(gè)參與者， 就一定會(huì)有沖突存在。 談判困難而調(diào)解容易，如果兩個(gè)人的利益是完全或部分相斥的，預(yù)先做好

33、安排， 準(zhǔn)備好請(qǐng)雙方通過(guò)調(diào)解來(lái)解決沖突。 同樣，現(xiàn)代敏捷方法論通過(guò)客戶的積極參與 勝過(guò)合同談判的方試，來(lái)盡早發(fā)現(xiàn)和避免規(guī)約崩潰。第五、低效率 對(duì)于項(xiàng)目成功而言， 項(xiàng)目人員的素質(zhì)、 人員的組織和管理是比使用的工具或 采用的技術(shù)方法更重要的因素。 團(tuán)隊(duì)質(zhì)量是項(xiàng)目成功最大的決定因素， 對(duì)人的關(guān) 注、激勵(lì)和培養(yǎng)勝過(guò)一切。 項(xiàng)目管理人員的職責(zé)不是要人們?nèi)スぷ鳎?而是給人們 創(chuàng)造工作的可能。 創(chuàng)造力來(lái)自于個(gè)人， 而不是組織架構(gòu)和流程， 項(xiàng)目管理者面臨 的中心問(wèn)題就是如何設(shè)計(jì)架構(gòu)和流程，來(lái)提高而不是壓制人們的主動(dòng)性和創(chuàng)造 力。通過(guò)權(quán)力的向下委派， 從而產(chǎn)生了改進(jìn)的質(zhì)量、 提高的生產(chǎn)率、 高漲的士氣， 進(jìn)而使

34、中心的權(quán)威實(shí)際上得到了加強(qiáng)。 就整體而言，組織機(jī)構(gòu)會(huì)更加融洽和繁榮。 增加加班時(shí)間只會(huì)降低生產(chǎn)力， 壓力之下的人們無(wú)法更快地思考既也會(huì)降低生產(chǎn) 力。使用壓力和加班的真正原因是為了在項(xiàng)目失敗時(shí)讓人們看上去能好受一些。正式的過(guò)程改進(jìn)程序需要花錢、 花時(shí)間，特定的過(guò)程改進(jìn)工作還會(huì)延緩項(xiàng)目 進(jìn)度，盡管最終會(huì)體現(xiàn)生產(chǎn)力上的收獲， 它們也不可能抵消花在過(guò)程改進(jìn)上的時(shí) 間。多種技術(shù)的改進(jìn)程序 （如 CMM 提級(jí) ）很可能讓項(xiàng)目比不實(shí)施這些程序完成得 更晚，對(duì)于人員超編的項(xiàng)目， 標(biāo)準(zhǔn)過(guò)程會(huì)為多余的人們制造出足夠的工作， 讓所 有人都忙個(gè)不停， 盡管很多是無(wú)用的， 這也導(dǎo)致生產(chǎn)率低下。 人員超編的團(tuán)隊(duì)往 往生產(chǎn)

35、率低下， 因?yàn)樗鼈儓F(tuán)隊(duì)內(nèi)部耦合度提高， 會(huì)議時(shí)間、 重復(fù)勞動(dòng)和無(wú)效工作 都會(huì)增加。理想的人員安排是在項(xiàng)目的大部分時(shí)間里由小型核心團(tuán)隊(duì)來(lái)做設(shè)計(jì)工 作，在開發(fā)的最后階段再逐漸加入大量人手。 如果不大幅度減少調(diào)試的時(shí)間， 就 沒(méi)辦法讓項(xiàng)目大幅度提前完成， 而要成比例減少調(diào)試時(shí)間， 就需要成比例增加設(shè) 計(jì)所需時(shí)間， 因?yàn)榻^大多數(shù)的錯(cuò)誤源于接口缺陷， 編碼前進(jìn)行的正規(guī)而完善的設(shè) 計(jì)，可以大幅度減少錯(cuò)誤。同樣，現(xiàn)代敏捷方法論通過(guò)注重人、快速迭代開發(fā)、 自組織的團(tuán)隊(duì)和提倡可持續(xù)的開發(fā)速度， 來(lái)避免跑的過(guò)快導(dǎo)致團(tuán)隊(duì)精力耗盡、 出 現(xiàn)短期行為而導(dǎo)致崩潰的問(wèn)題，從而保持了穩(wěn)定的生產(chǎn)率。精兵簡(jiǎn)政是失敗公司使用的辦法

36、， 它讓員工負(fù)擔(dān)失敗的責(zé)任。 成功公司的目 標(biāo)應(yīng)該正好相反：興旺、發(fā)達(dá)、而人性化。引自 最后期限企業(yè)的最大風(fēng)險(xiǎn)則與價(jià)值相關(guān)： 在低價(jià)值的項(xiàng)目上浪費(fèi)資源， 付出高價(jià)值的 機(jī)會(huì)成本，就這是企業(yè)最大風(fēng)險(xiǎn)。勇于承擔(dān)風(fēng)險(xiǎn)是好事，但必須由收益來(lái)導(dǎo)航， 愿意承擔(dān)多少風(fēng)險(xiǎn)， 必須取決于能獲得多少收益。 真正的項(xiàng)目評(píng)估不是傾向于不 斷削減成本， 來(lái)提高價(jià)值， 而是在風(fēng)險(xiǎn)與價(jià)值之間取得平衡點(diǎn)。 通過(guò)不確定的價(jià) 值和不確定風(fēng)險(xiǎn)組合效果的凈收益圖， 來(lái)指導(dǎo)你把資本投入到最適當(dāng)?shù)牡胤健?我 們每個(gè)軟件從業(yè)人員都必須明白： 顧客真正需要的， 是我們能夠給他的、 某種他 想得到的利益。組件級(jí)測(cè)試很顯然，首先必須開發(fā)單個(gè)組件

37、，然后才能將它們 "裝配 "成功能系統(tǒng)。因?yàn)?組件可以進(jìn)行早期測(cè)試，所以在 TAP 中端到端測(cè)試是從組件測(cè)試開始的。在組 件測(cè)試中，隨著環(huán)境的建立，適當(dāng)?shù)臏y(cè)試也分別實(shí)施于各個(gè)不同的單個(gè)組件上。 功能測(cè)試和性能測(cè)試在組件測(cè)試階段都相當(dāng)有價(jià)值， 它們幫助診斷了在整個(gè)環(huán)境 構(gòu)建前和構(gòu)建中的各種缺陷。組件測(cè)試中的功能測(cè)試組件級(jí)功能測(cè)試驗(yàn)證了每個(gè)組件所執(zhí)行的事務(wù)。 這包括了組件或系統(tǒng)所要求 的任何數(shù)據(jù)轉(zhuǎn)換和組件所處理的事務(wù)的業(yè)務(wù)邏輯的驗(yàn)證。 在應(yīng)用程序功能的開發(fā) 中，基礎(chǔ)設(shè)施測(cè)試 (infrastructure testing )驗(yàn)證并量化整個(gè)環(huán)境中的數(shù)據(jù)流量， 并以這種方式來(lái)同時(shí)進(jìn)

38、行功能和性能測(cè)試。 數(shù)據(jù)完整性必須當(dāng)數(shù)據(jù)在組件間傳遞 時(shí)進(jìn)行驗(yàn)證。例如， XML 測(cè)試在逐個(gè)事務(wù)地驗(yàn)證 XML 數(shù)據(jù)內(nèi)容，并在需要時(shí) 驗(yàn)證正式 XML 結(jié)構(gòu)(元數(shù)據(jù)結(jié)構(gòu)) 。對(duì)組件測(cè)試來(lái)說(shuō)，諸如 IBM Rational Robot 這樣的自動(dòng)可擴(kuò)展的測(cè)試工具可以大大的減少用在 GUI 測(cè)試和非 GUI 組件的功能測(cè)試上的時(shí)間和精力。 Rational Robot 的腳本語(yǔ)言支持對(duì)外部 COM DDLs 的調(diào)用，是非 GUI 對(duì)象測(cè)試的理想工具。此外， Rational SuiteTestStudio 和 Rational Team Test 所附帶的新的 Web 和 Java 測(cè)試功能， 提供了測(cè)試 J2EE 架構(gòu)和使用 java 語(yǔ)言來(lái)編寫測(cè)試腳本的附加功能。組件級(jí)可伸縮性測(cè)試和性能測(cè)試 與這些功能測(cè)試并行的是組件級(jí)可伸縮性測(cè)試， 在環(huán)境中檢驗(yàn)每個(gè)組件來(lái)確 定其事務(wù)(或者說(shuō)容量) 的限度。一旦有足夠的應(yīng)用功能來(lái)創(chuàng)建業(yè)務(wù)相關(guān)的事務(wù)， 事務(wù)特征測(cè)試( transcation characterization testing )就被用來(lái)確定業(yè)務(wù)事務(wù) 中的各個(gè)定量描述， 包