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

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

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

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

4、對程序修訂后，需要執(zhí)行回歸測試。目的是確定改變是否已經(jīng)回歸了程序的其他方面，一般是通過重新允許程序的測試用例的子集來執(zhí)行?；貧w測試的重要性在于變更和糾錯(cuò)傾向于產(chǎn)生更多的錯(cuò)誤，所以一份回歸測試的計(jì)劃（誰、如何、何時(shí)）是有必要的。如何制定軟件工程測試計(jì)劃摘要隨著測試走向規(guī)范化管理，測試計(jì)劃成為測試經(jīng)理必須完成的重要任務(wù)之一，本文根據(jù)實(shí)踐經(jīng)驗(yàn)結(jié)合理論，探討如何制定軟件工程測試計(jì)劃。關(guān)鍵字測試計(jì)劃變更正文軟件測試計(jì)劃作為軟件工程計(jì)劃的子計(jì)劃，在工程啟動初期是必須規(guī)劃的。在越來越多公司的軟件開發(fā)中，軟件質(zhì)量日益受到重視，測試過程也從一個(gè)相對獨(dú)立的步驟越來越緊密嵌套在軟件整個(gè)生命周期中，這樣，如何規(guī)劃整個(gè)

5、工程周期的測試工作；如何將測試工作上升到測試管理的高度都依賴于測試計(jì)劃的制定。測試計(jì)劃因此也成為測試工作的賴于展開的基礎(chǔ)。一個(gè)好的測試計(jì)劃可以起到如下作用1 .避免測試的“事件驅(qū)動”2 .使測試工作和整個(gè)開發(fā)工作融合起來3,資源和變更事先作為一個(gè)可控制的風(fēng)險(xiǎn)測試計(jì)劃的模板在各個(gè)公司中都大同小異，在個(gè)人實(shí)踐中發(fā)現(xiàn)，測試計(jì)劃制定中存在的問題具有相似性，下面重點(diǎn)就這些相似的問題談?wù)勅绾沃贫ㄜ浖こ虦y試計(jì)劃。問題一：測試階段劃分就通常軟件工程而言，基本上采用“瀑布型”開發(fā)方式，這種開發(fā)方式下，各個(gè)工程主要活動比較清晰，易于操作。整個(gè)工程生命周期為“需求-設(shè)計(jì)編碼測試發(fā)布實(shí)施維護(hù)”。然而，在制定測試計(jì)劃

6、時(shí)候，有些測試經(jīng)理對測試的階段劃分還不是十分明晰，經(jīng)常性遇到的問題是把測試單純理解成系統(tǒng)測試，或者把把各類型測試設(shè)計(jì)（測試用例的編寫和測試數(shù)據(jù)準(zhǔn)備）全部放入生命周期的“測試階段”，這樣造成的問題是浪費(fèi)了開發(fā)階段可以并行的工程日程，另一方面造成測試不足。合理的測試階段應(yīng)遵循下面劃分方法：7的段織碼單元集成系統(tǒng)設(shè)計(jì)系統(tǒng)測試設(shè)計(jì)集成測試£設(shè)計(jì)K4litlab單元測試計(jì)劃缺計(jì)|mm實(shí)驗(yàn)室照上圖所述，相應(yīng)階段可以同步進(jìn)行相應(yīng)的測試計(jì)劃編制，而測試設(shè)計(jì)也可以結(jié)合在開發(fā)過程中實(shí)現(xiàn)并行，測試的實(shí)施即執(zhí)行測試的活動即可連貫在開發(fā)之后。值得注意的是：單元測試和集成測試往往由開發(fā)人員承擔(dān)，因此這部分的階段

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

8、1 .計(jì)算需求文檔的頁數(shù)，得出系統(tǒng)測試用例的頁數(shù)需求頁數(shù)：系統(tǒng)測試用例頁數(shù)=1:12 .由系統(tǒng)測試用例頁數(shù)計(jì)算編寫系統(tǒng)測試用例時(shí)間編寫系統(tǒng)測試用例時(shí)間=系統(tǒng)測試用例頁數(shù)X1小時(shí)3 .計(jì)算執(zhí)行系統(tǒng)測試用例時(shí)間編寫系統(tǒng)用例用時(shí)：執(zhí)行系統(tǒng)測試用時(shí)-1:24 .計(jì)算回歸測試包含的時(shí)間系統(tǒng)測試用時(shí)：回歸測試用時(shí)=2:1注：以上比值是個(gè)人工程經(jīng)驗(yàn)值，需要更正比值的測試經(jīng)理可以在具體實(shí)踐中收集數(shù)據(jù)?；谝陨戏椒▋?yōu)點(diǎn)是需求為已知的，可以利用已知來推算未知，適用于需求是已知且相對穩(wěn)定的情況下；缺點(diǎn)是處于研發(fā)狀態(tài)的工程，需求不清晰的時(shí)候比較難計(jì)算?，F(xiàn)套用一個(gè)例子加于說明：需求文檔頁數(shù)為500,系統(tǒng)測試用例頁數(shù)推算

9、為500,則編寫系統(tǒng)測試用例時(shí)間為500小時(shí)，執(zhí)行系統(tǒng)測試用例時(shí)間為1000小時(shí)，回歸測試需要500小時(shí)，加起來總共為2000小時(shí)，按一天8小時(shí)計(jì)算，共計(jì)250個(gè)工作日/人；假如一個(gè)月為22個(gè)工作日，則共計(jì)約11人/月，即投入4個(gè)人需要3個(gè)月左右時(shí)間工作量完成。當(dāng)然，這是系統(tǒng)測試需要的全部時(shí)間。根據(jù)測試階段劃分原則，設(shè)計(jì)用例時(shí)間可以和開發(fā)同步進(jìn)行，只需在測試階段中安排的時(shí)間為1500小時(shí)即4人2個(gè)月工作量。（測試經(jīng)理在編寫測試計(jì)劃時(shí)候，測試進(jìn)度中的計(jì)劃開始/結(jié)束時(shí)間往往用如2005010-20051201的具體時(shí)間劃分方式，這樣引起的問題是當(dāng)工程計(jì)劃進(jìn)行變更的時(shí)候，測試計(jì)劃時(shí)間不得不隨時(shí)調(diào)整，

10、這種變更可能是頻繁而瑣碎的，可以替代的辦法是取消這種方式，采用30工作日/2人或者2人月這種工作量記錄方式，這樣一來，只需在工程計(jì)劃中跟蹤階段的具體開始時(shí)間即可，不必反復(fù)修改測試計(jì)劃。）值得注意的是：國內(nèi)大多數(shù)公司的測試時(shí)間都是不足的，不可能按照這樣的理想比例進(jìn)行運(yùn)作，因?yàn)闇y試執(zhí)行的時(shí)間實(shí)際上不可能占據(jù)整個(gè)工程周期的1/2,甚至要短于其中任何一個(gè)工程階段時(shí)間。即使是微軟的測試結(jié)束原則也并不是完成所有必需的測試，而是測試在按計(jì)劃結(jié)束的那一天結(jié)束！在測試時(shí)間不足的情況下，可參考下面工程計(jì)劃變更時(shí)的做法，因?yàn)橛?jì)劃變更也涉及到測試時(shí)間不足的情況。問題三：變更的控制測試計(jì)劃改變了已往根據(jù)任務(wù)進(jìn)行測試的方

11、式，因此，為使測試計(jì)劃得到貫徹和落實(shí)，測試組人員必須及時(shí)跟蹤軟件開發(fā)的過程，對產(chǎn)品提交測試做準(zhǔn)備，測試計(jì)劃的目的，本身就是強(qiáng)調(diào)按規(guī)劃的測試戰(zhàn)略進(jìn)行測試，淘汰以往以任務(wù)為主的臨時(shí)性。在這種情況下，測試計(jì)劃中強(qiáng)調(diào)對變更的控制顯得尤為重要。變更來源于以下幾個(gè)方面1 .工程計(jì)劃的變更2 .需求的變更3 .測試產(chǎn)品版本的變更4 .測試資源的變更測試階段的風(fēng)險(xiǎn)主要是對上述變更所造成的不確定性，有效的應(yīng)對這些變更就能降低風(fēng)險(xiǎn)發(fā)生的幾率。要想計(jì)劃本身不成為空談和空白無用的紙質(zhì)文檔，對不確定因素的預(yù)見和事先防范必須做到心中有數(shù)。對于工程計(jì)劃的變更，除了測試人員及時(shí)跟進(jìn)工程以外，工程經(jīng)理必須認(rèn)識到測試組也是工程成

12、員，因此必須把這些變更信息及時(shí)通知到工程組，使得整個(gè)工程得到順延。工程計(jì)劃變更一般涉及都是日程變更，令人遺憾的是，往往為了進(jìn)度的原因，交付期限是既定的，工程經(jīng)理不得不減少測試的時(shí)間，這樣，執(zhí)行測試的時(shí)間就被壓縮了。在這種情況下，測試經(jīng)理常常固執(zhí)的認(rèn)為進(jìn)度縮減的唯一的方法就是向上級通報(bào)并主觀認(rèn)為產(chǎn)品質(zhì)量一定會下降，這種做法和想法不一定是正確的。由于時(shí)間不足，不能“完美”的執(zhí)行所有測試，為了保證質(zhì)量，第一種辦法是調(diào)整測試計(jì)劃中的測試策略和測試范圍，實(shí)踐中測試經(jīng)理常常忽略測試計(jì)劃的這個(gè)章節(jié)。調(diào)整的目的是重新檢查不重要的測試部分，調(diào)換測試的次序和減少測試規(guī)模，對測試類型重新組合擇優(yōu)，力求在限定時(shí)間內(nèi)做

13、最重要部分的測試，可以把忽略部分留給確認(rèn)測試或現(xiàn)場測試。其他應(yīng)對辦法包括減少進(jìn)入測試的阻力，例如降低測試計(jì)劃中系統(tǒng)測試準(zhǔn)入準(zhǔn)則；分步提交測試，例如改成迭代方式增量測試；減少回歸測試的要求，例如開發(fā)人員實(shí)時(shí)修改，在測試計(jì)劃中對缺陷修復(fù)響應(yīng)時(shí)間和過程進(jìn)行約定；和公司QA商量進(jìn)行簡化配置管理，跳過正式發(fā)布環(huán)節(jié)；缺陷進(jìn)行局部回歸而不是重新全部測試等等。第二：工程進(jìn)行過程中最不可避免的就是需求的變更。那么，測試計(jì)劃中就不能進(jìn)行控制和約束的嗎？答案是未必。當(dāng)制定計(jì)劃時(shí)，如果工程需求處于動態(tài)變化時(shí)，在測試用例章節(jié)就要進(jìn)行說明。許多測試經(jīng)理在編制測試用例時(shí)往往沒有把測試用例和測試數(shù)據(jù)進(jìn)行區(qū)分，因此，造成的問題

14、是當(dāng)需求變化時(shí)辛辛苦苦設(shè)計(jì)的數(shù)據(jù)就作廢了。在這時(shí)，假使面臨一個(gè)需求動態(tài)的工程，必須在計(jì)劃中對需求變更造成的測試（設(shè)計(jì)）方式變化進(jìn)行說明，例如采用用例和數(shù)據(jù)分離、流程和界面分離、字典項(xiàng)和數(shù)據(jù)元素分離的設(shè)計(jì)方式，然后等到最終需求確定后細(xì)化測試設(shè)計(jì)；另一個(gè)方面是最好制定一個(gè)變更周期的約定一一尤其在執(zhí)行測試階段發(fā)現(xiàn)需求的變更一一定義變更的最大頻度和重新測試的界限，計(jì)劃從一定程度上能夠降低不可預(yù)期需求變化造成的投入損失。值得注意的是：需求發(fā)生變更時(shí)測試經(jīng)理額外的工作是記住要在需求跟蹤矩陣上做記錄。對于測試產(chǎn)品版本的變更，除了部分是由于需求變更造成之外，很有可能是由于修改缺陷引發(fā)的問題或配置管理不嚴(yán)格造成

15、。眾所周知，測試必須是基于一個(gè)穩(wěn)定的“基線”進(jìn)行，否則，因反復(fù)修改造成測試資源和開發(fā)資源的浪費(fèi)是可觀的。合理的測試計(jì)劃在章節(jié)中應(yīng)增加一個(gè)測試更新管理的章節(jié)，在此章節(jié)明確更新周期和暫停測試的原則。例如，小版本的產(chǎn)品更新不能大于每天三次，一個(gè)相對大的版本不能每周大于1次，規(guī)定緊急發(fā)布產(chǎn)品僅限于何種類型的修改或變更，由誰負(fù)責(zé)統(tǒng)一維護(hù)和同步更新測試環(huán)境。測試計(jì)劃通常制定了準(zhǔn)入和準(zhǔn)出準(zhǔn)則，這是不夠的，要考慮測試暫停的時(shí)候，產(chǎn)品錯(cuò)誤發(fā)布或者服務(wù)器數(shù)據(jù)更新就是一個(gè)例子，暫停的時(shí)候如果測試經(jīng)理不進(jìn)行跟蹤，可能發(fā)生測試組等待測試而沒人通知繼續(xù)測試的情況，所以，增加更新周期和暫停測試原則是很有必要的。最后，測試資

16、源的變更是源自測試組內(nèi)部的風(fēng)險(xiǎn)而非開發(fā)組風(fēng)險(xiǎn)，當(dāng)測試資源不足或者沖突，測試部門不可能安排如此多的人手和足夠時(shí)間參與測試時(shí)，在測試計(jì)劃中的控制方法與測試時(shí)間不足相類似。沒有測試經(jīng)理愿意承擔(dān)資源不足的測試工作，只能說公司本身是否具備以質(zhì)量為主的體系或者工程經(jīng)理對產(chǎn)品質(zhì)量的重視程度如何決定了對測試資源投入的大小，最終產(chǎn)品質(zhì)量取決因素不僅僅在于測試經(jīng)理。為了排除這種風(fēng)險(xiǎn)，除了象時(shí)間不足、測試計(jì)劃變更時(shí)那樣縮減測試規(guī)模等等方法以外，測試經(jīng)理必須在人力資源和測試環(huán)境一欄標(biāo)出明確需要保證的資源，否則，必須將這個(gè)問題作為風(fēng)險(xiǎn)記錄。規(guī)避風(fēng)險(xiǎn)的辦法可能有：一，工程組的需求和實(shí)施人員參與系統(tǒng)測試；二，抽調(diào)不同模塊開

17、發(fā)者進(jìn)行交叉系統(tǒng)測試或借用其他工程開發(fā)人員；三，組織客戶方進(jìn)行確認(rèn)測試或發(fā)布B版本。盡管上面盡可能的描述了測試計(jì)劃如何制定才能“完美”，但是還存在的問題是對測試計(jì)劃的管理和監(jiān)控。一份計(jì)劃投入再多的時(shí)間去做也不能保證按照這份計(jì)劃進(jìn)行實(shí)施。好的測試計(jì)劃是成功的一半，另一半是對測試計(jì)劃的執(zhí)行。對小工程而言，一份更易于操作的測試計(jì)劃更為實(shí)用，對中型乃至大型工程來看，測試經(jīng)理的測試管理能力就顯得格外重要，要確保計(jì)劃不折不扣的執(zhí)行下去，測試經(jīng)理的人際諧調(diào)能力，工程測試的操作經(jīng)驗(yàn)、公司的質(zhì)量現(xiàn)狀都能夠?qū)こ虦y試產(chǎn)生足夠的影響。另外，計(jì)劃也是“動態(tài)的”！不必要把所有的因素都可能囊括進(jìn)去，也不必要針對這種變化額

18、外制定“計(jì)劃的計(jì)劃”，測試計(jì)劃制定不能在工程開始后束之高閣，而是緊追工程的變化，實(shí)時(shí)進(jìn)行思考和貫徹，根據(jù)現(xiàn)實(shí)修改，然后成功實(shí)施，這才能實(shí)現(xiàn)測試計(jì)劃的最終目標(biāo)一一保證工程最終產(chǎn)品的質(zhì)量！軟件開發(fā)是一項(xiàng)復(fù)雜的、創(chuàng)造性的協(xié)作式游戲。作為游戲它自然存在著樂趣，所以程序員們才會樂此不疲，前仆后繼。首先、這種快樂源于一種創(chuàng)造事物的快樂。其次、這種快樂來自于一種開發(fā)出對別人有用的東西時(shí)所帶來的滿足感。第三、快樂源自開發(fā)過程中，親眼看到軟件按自己預(yù)先設(shè)想的那種效果運(yùn)行時(shí)所帶來的迷人魅力。第四、快樂源自開發(fā)過程中持續(xù)學(xué)習(xí)的快樂。最后、快樂源自開發(fā)過程中，我們能象詩人一樣，僅憑自己的想像，來建造自己的城堡時(shí)帶來的

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

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

21、題，而問題是業(yè)也成真的風(fēng)險(xiǎn)，昨大的風(fēng)險(xiǎn)可能會是今天的問題。風(fēng)險(xiǎn)管理主要包括下面幾個(gè)方面：第一、風(fēng)險(xiǎn)識別：從頭腦想像中抽取出各種風(fēng)險(xiǎn)并加以篩選，再加上在整個(gè)開發(fā)過程中，保持持續(xù)不斷的風(fēng)險(xiǎn)發(fā)現(xiàn)機(jī)制，以發(fā)現(xiàn)新的風(fēng)險(xiǎn)。第二、風(fēng)險(xiǎn)分析：對風(fēng)險(xiǎn)出現(xiàn)的可能性和潛在的危害性進(jìn)行量化分析。第三、應(yīng)急計(jì)劃：如果識別出的風(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)的跡象。工程面臨的某些風(fēng)險(xiǎn)可能是致命的，發(fā)生時(shí)會使工程嚴(yán)重滯后或直接廢棄。這類風(fēng)險(xiǎn)是最需要管理的，但有效的管理它們也許會使你與你的上級發(fā)

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

23、內(nèi)完成開發(fā)工作。然而，這種理論卻忽略了隨著人數(shù)的增加，相應(yīng)的也會增加新人培訓(xùn)和人們相互交流所需的負(fù)擔(dān)，另外，還有任務(wù)重新分配所造成工作中斷帶來的負(fù)擔(dān)，正如AlistairCockburn所說："最有效的交流方式是面對面的交流"當(dāng)3、5個(gè)人的時(shí)候很容易做到這種交流方式，隨著人數(shù)的增長，再也很難做到這種交流方式。交流成本的增加與培訓(xùn)新人所需時(shí)間成本的增加、以及任務(wù)重分配導(dǎo)致工作中斷成本的增加，直接導(dǎo)致一種結(jié)果：向進(jìn)度落后的工程中增加人手，只會使進(jìn)度更加落后。第三、源于空泛的估算，管理人員特別是高層管理人員為了滿足顧客期望的日期而造成的不合理進(jìn)度安排。如果分配的時(shí)間一開始就不夠，

24、不管高層領(lǐng)導(dǎo)威脅有多么嚇人，工作也無法按時(shí)完成，如果人們察覺到管理者可能濫用權(quán)力來懲罰自己，他們就會感覺到威脅，沒有安全感。安全感的缺乏會讓人們反對變化，而在所有成功工程中，變化是唯一不變的要素之一，除非感到安全，否則人們就不會去迎接變化，只會按部就班，這樣往往喪失了很多走捷徑的好機(jī)會，而這些機(jī)會原可以大大縮減時(shí)間進(jìn)度的。第四、如果你沒有認(rèn)真估算產(chǎn)品規(guī)模，那么你預(yù)計(jì)的進(jìn)度就是空中樓閣，唯一的依據(jù)只是你的希望。在估計(jì)產(chǎn)品規(guī)模時(shí)，除了正常的時(shí)間計(jì)算以外，不但應(yīng)該將"可能需要做"的事情所需工作時(shí)間加上，還要將某些”可能不需要做”的事情所需工作時(shí)間加上。工程的超期不應(yīng)歸咎于開發(fā)者的

25、低效率。最后、工程的滯后不是一下子造成的，而是在一天天的不知不覺中造成的，有無數(shù)種方法可以浪費(fèi)一天的時(shí)間，但是沒有任何方法可以拿回一天的時(shí)問。高層管理者的不良反應(yīng)肯定會對信息的完全公開造成壓制；相反，仔細(xì)區(qū)分狀態(tài)報(bào)告、毫無驚慌地接收報(bào)告、決不壓制下級，將能鼓勵(lì)誠實(shí)的進(jìn)度匯報(bào)，而這會使你在第一時(shí)間掌握實(shí)際進(jìn)度，把握先機(jī)，及早做出正確的修訂，從而避免了晚期才獲得這些實(shí)際信息時(shí)，那種無力挽天時(shí)的無奈。止匕外、也可以在工程管理中設(shè)定一個(gè)合理的進(jìn)度安排和一個(gè)具有挑戰(zhàn)性的期望目標(biāo)完成時(shí)問。期望目標(biāo)和合理進(jìn)度不同，期望目標(biāo)完成時(shí)間，可以設(shè)為工程完成的成功率在30%左右時(shí)的日期，這樣很具有挑戰(zhàn)性，但不能強(qiáng)迫要

26、求必須完成此期望目標(biāo)。畢竟，合理進(jìn)度安排才是更合理的時(shí)間安排。另外、需要指出的是現(xiàn)代敏捷方法論對此進(jìn)行了有效改進(jìn)，如XP（極限編程）中，就利用用戶素材與CRC卡，進(jìn)行優(yōu)先級劃分并進(jìn)行快速增量迭代開發(fā)，針對原來開發(fā)的產(chǎn)品或第一次迭代開發(fā)后的原型完成的功能量，來計(jì)算功能點(diǎn)，從而估算每個(gè)CRC卡的功能點(diǎn)，得到總功能點(diǎn)來推導(dǎo)出比較準(zhǔn)確的進(jìn)度安排。第二、需求的變化從工程的角度來說，需求總是向著膨脹的方向在變化。就連去掉某些已經(jīng)做好的東西，也是一種膨脹，因?yàn)樗黾恿斯ぷ髁?。開發(fā)人員交付的是用戶滿意程度，而不僅僅是實(shí)際的產(chǎn)品，用戶的實(shí)際需要會隨著程序的構(gòu)建和使用而變化。要知道，一個(gè)活著的軟件必須面對變化，只

27、有死掉的軟件才不會有需求變化（沒人用了），我們應(yīng)該盡早面對現(xiàn)實(shí)，而不是逃避，事先為它們做好思想準(zhǔn)備。變化是好事不是什么壞事。同樣，現(xiàn)代敏捷方法論強(qiáng)調(diào)對需求變化的快速響應(yīng)，如XP（極限編程）就采用快速增量迭代開發(fā)，來在短時(shí)間內(nèi)開發(fā)出功能不斷增強(qiáng)的原型軟件提交給用戶使用的方法，來快速響應(yīng)需求的變化。第三、人員的變更在我們有些管理者中，總是假設(shè)開發(fā)者都是可以隨便替換的，新員工馬上可以取代離去的老員工，多么愚蠢的假設(shè)。解雇員工或高的員工替換率最大的影響，是使軟件工程失去了連續(xù)性。這是在抱著這種假設(shè)的團(tuán)隊(duì)文化中，大量員工會在工程進(jìn)行到一半時(shí)離開，新來員工往往需要1至U3個(gè)月的上道時(shí)間，在這段時(shí)間內(nèi)，他們

28、做不了什么，還經(jīng)常需要其它老員工的幫助，從而浪費(fèi)了其它老員工很多不必要時(shí)間，導(dǎo)致工程進(jìn)展更加緩慢，最終造成工程的很大損失。另外、還有一種現(xiàn)象在中國軟件事業(yè)中普遍存在，當(dāng)正在進(jìn)行一個(gè)工程時(shí)，另一個(gè)工程由于進(jìn)度落后或最后期限等原因所致，高層管理者就會從你的團(tuán)隊(duì)中抽掉一些人去到另一個(gè)工程中補(bǔ)墻。這種拆東墻補(bǔ)西墻的作法，往往導(dǎo)致的結(jié)果是兩個(gè)工程都會落后，因?yàn)樗粌H十分錯(cuò)誤作了團(tuán)隊(duì)人員可以隨意替換的假設(shè)，而且還作了將開發(fā)人數(shù)與開發(fā)所需時(shí)間可以互換的錯(cuò)誤假設(shè)。盲目的認(rèn)為，投入大量人數(shù)后，新人馬上會投入新的工作，這樣工程開發(fā)所需時(shí)間就會成倍縮短。在這種組織文化中，是不會形成一支穩(wěn)定的團(tuán)隊(duì)的，成員整天只會忙碌

29、著補(bǔ)自已的墻或?yàn)閯e人補(bǔ)墻，充當(dāng)著類似消防員的角色，那兒有火那兒就有我們的身影。同樣，現(xiàn)代敏捷方法論非常注重人的能力，如XP中通過權(quán)力下放、教練角色、將團(tuán)隊(duì)緊密圍在一起并結(jié)對編程、小團(tuán)隊(duì)組成等方式，來組成一個(gè)強(qiáng)有力的團(tuán)隊(duì)，由于有凝聚力，所以很少有大的人員變動，他們往往可以完成兩倍于他們?nèi)藬?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ī)約崩潰這種

30、情況只有兩種結(jié)果：要么發(fā)生，要么不發(fā)生，不會有不同程度的影響。但它真的發(fā)生時(shí)，它會直接毀滅你的整個(gè)工程。在工程啟動之初，工程各方需要通過一系列商談來確定需求的范圍，規(guī)約崩潰就是指這個(gè)談判過程的崩潰。在商談期間，很多時(shí)候當(dāng)遇到嚴(yán)重沖突時(shí)，由于雙方都不愿意讓步，但又不想放棄這個(gè)工程，從而導(dǎo)致這些沖突被掩蓋起來。最終工程便朝著一個(gè)帶著缺陷的、含混不清的目標(biāo)前進(jìn)了，被掩蓋的問題暫時(shí)不會打擾你，但不是永遠(yuǎn)。盡管你可以含混說明一個(gè)產(chǎn)品，但不能含混構(gòu)造一個(gè)產(chǎn)品，所以，最終在工程晚期這些問題將發(fā)生，在大半甚至所有預(yù)算時(shí)間和金錢都已付出的時(shí)候，此時(shí)，任何一方不再全力支持，都將使工程被取消。任何規(guī)格文檔中的含糊標(biāo)

31、志著不同的系統(tǒng)參與者之間存在著未解決的沖突。只要在開發(fā)過程中有多個(gè)參與者，就一定會有沖突存在。談判困難而調(diào)解容易，如果兩個(gè)人的利益是完全或部分相斥的，預(yù)先做好安排，準(zhǔn)備好請雙方通過調(diào)解來解決沖突。同樣，現(xiàn)代敏捷方法論通過客戶的積極參與勝過合同談判的方試，來盡早發(fā)現(xiàn)和避免規(guī)約崩潰。第五、低效率對于工程成功而言，工程人員的素質(zhì)、人員的組織和管理是比使用的工具或采用的技術(shù)方法更重要的因素。團(tuán)隊(duì)質(zhì)量是工程成功最大的決定因素，對人的關(guān)注、激勵(lì)和培養(yǎng)勝過一切。工程管理人員的職責(zé)不是要人們?nèi)スぷ?，而是給人們創(chuàng)造工作的可能。創(chuàng)造力來自于個(gè)人，而不是組織架構(gòu)和流程，工程管理者面臨的中心問題就是如何設(shè)計(jì)架構(gòu)和流程

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

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

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

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

36、遞時(shí)進(jìn)行驗(yàn)證。例如，XML測試在逐個(gè)事務(wù)地驗(yàn)證XML數(shù)據(jù)內(nèi)容，并在需要時(shí)驗(yàn)證正式XML結(jié)構(gòu)(元數(shù)據(jù)結(jié)構(gòu))。對組件測試來說，諸如舊MRationalRobot這樣的自動可擴(kuò)展的測試工具可以大大的減少用在GUI測試和非GUI組件的功能測試上的時(shí)間和精力。RationalRobot的腳本語言支持對外部COMDDLs的調(diào)用，是非GUI對象測試的理想工具。此外，RationalSuiteTestStudio和RationalTeamTest所附帶的新的Web和Java測試功能，提供了測試J2EE架構(gòu)和使用java語言來編寫測試腳本的附加功能。組件級可伸縮性測試和性能測試與這些功能測試并行的是組件級可伸縮性測試，在環(huán)境中檢驗(yàn)每個(gè)組件來確定其事務(wù)(或者說容量)的限度。一旦有足夠的應(yīng)用功能來創(chuàng)建業(yè)務(wù)相關(guān)的事務(wù)，事務(wù)特征測試(transcationcharacterization