中國網(wǎng)通趙軍(譯)
泰坦尼克的設計者有許多設計選擇并遵循一項戰(zhàn)略就是要集所有最新的和超前安全技術提供最高等級的安全性。然而,由于他們迫于商業(yè)壓力,泰坦尼克的設計者開始在安全裝置上做出妥協(xié)。這些壓力明顯地來自企圖為最終乘客(頭等艙)創(chuàng)造一流體驗的白星公司老板Bruceismay。例如:四個防水壁吃水線以上部分只有10英尺而并沒有到達頂甲板,目的是騰出一個200尺寬敞的舞廳。(參看第三部分)。
到了測試階段的計劃開始制訂時,泰坦尼克是不可征服的觀念一直存在于白星工作人員當中。事實上,這個觀念也作為泰坦尼克市場推廣的一部分被積極地使用。由于泰坦尼克即將完成,在交付白星公司之前,harland和wolff(造船專家)為泰坦尼克制訂了測試計劃。雙方都必須確定泰坦尼克滿足合同規(guī)定的條件和需求。測驗給造船專家一個機會,可以做出任何必要的調整和避免財政罰款的風險或遭受送回船廠的更壞命運。
同樣,IT解決方案也應該總是滿足合同義務,這些合同義務的滿足必須依賴于項目早期建立的服務等級目標。商業(yè)實際根據(jù)公司能夠容忍的底線為基礎確定解決方案的價格和服務水準要求(參看第二部分)。測試應該能夠評估IT解決方案是怎樣良好地滿足服務水平情況以及識別其中任何缺陷。
制訂計劃一般來說包含測試計劃的略述。例如,泰坦尼克毫無疑問進行了適航能力的操作測試,穩(wěn)定性的檢查、重量和負載細節(jié)等條目的仔細評定。其中有一項測試是用一個簡單的傾斜試驗,檢查船的重量和重心的傾斜測試。它還提供一項統(tǒng)計檢查。其他的測試包括迎水面碼頭邊試驗,主要目的是對主機和輔助機械裝置的初步測試。勻速試驗通常對滿足合同條款來說是必需的,即在斜度和總載重量的特定條件下,完成對某一速度的調整。
同樣,IT項目必須為IT解決方案制訂整體計劃測試,并且所做的測試必須對功能和無功能需求都應該有效。然而,重點將應放在具有難以置信地重要等級的無功能需求上,因為他們確定一個系統(tǒng)可使用的特征。測試必須是"動態(tài)"的并建立在較為早期的"靜態(tài)"測試或"走查"(walkthoughs)之上。
許多IT項目雖然在單位級別上功能測試的進行地很有效,但是卻沒能在宏觀上進行測試。這種情況的發(fā)生在一定程度上是由于模擬服務交付環(huán)境的感知成本是唯一的,導致只有局部測試不斷被完成,而整體測試卻沒有進行。這種做法降低了成功發(fā)布的置信度。許多公司事實上開始啟動IT解決方案的時候,報著要為用戶或客戶解決一切問題的初衷。這是一種極端危險的方法,有可能是商業(yè)陷入非常危險的嚴重狀態(tài)。
在泰坦尼克的故事中,當泰坦尼克計劃制訂和檢驗階段進行妥協(xié)時,同型船奧林匹克在泰坦尼克項目進行中扮演了一個及其重要的角色。泰坦尼克是1911年6月投入使用的奧林匹克號的一個翻版。白星公司認為奧林匹克的航行記錄足夠用于幾乎相同的同型船,泰坦尼克可以不經(jīng)過多方面的海上試航就可以直接開始服務。航行記錄把泰坦尼克已經(jīng)完全準備好了的觀念印入了船主們頭腦中。然而,兩艘船可以進行用了進行比較的只有機械構造,而沒有著眼于船員(人)或方法(過程)的準備。
過于依賴先前類似的實現(xiàn)方法、對事件風險和次要事件估計不足會使一個即將發(fā)生的技術風險啟動,種種情況的發(fā)生都會導致IT項目可能出現(xiàn)相似的錯誤。 根據(jù)對測試目標和整體戰(zhàn)略評估,確定所需的測試,測試目的。
以上述方法為基礎進行的大量測試應該包括受力狀態(tài),性能,逆行,可靠性和運行測試。這需要為每一個測試目標分別制訂測試案例:什么將被測試、它是如何被測試的、需要什么樣數(shù)據(jù)、期望結果和結果。最重要的是,這些都是在測試解決方案可用性。另外,制訂計劃應該確定測試是在什么環(huán)境下,由誰怎樣執(zhí)行的,才能確保其客觀性。例如:開發(fā)團體永遠不應該自己測試自己的成果;測試工作應該具有自己獨立的團體。
奧林匹克的航行記錄并不完美的,有發(fā)生了一些嚴重事件。第一件事就是,奧林匹克號被12個托船牽引到北河,調度到第59號碼頭下錨。牽引船Hallenbeck號位于遠洋班輪的船尾,那時奧林匹克的右舷螺旋槳突然倒轉將Hallenbeck號卷了進去,切斷它的船尾、舵和轉輪艙道口。
第二件事發(fā)生在奧林匹克號第六次出航開始階段即將駛出索倫特海峽時。當時奧林匹克號以15節(jié)的速度與皇家海軍HMSHawke號巡洋艦在一個狹小航道相隔200碼并行行駛,突然Hawke號強行朝著奧林匹克轉變方向,與奧林匹克號正面發(fā)生碰撞并穿透了奧林匹克號的外殼。破壞是相當大:一個三角形的破洞,大小為15尺高,10尺寬和10尺深。兩個最大的不透水艙飛快地被灌滿水,因此所有的防水門都關閉了。但是即使任何兩個隔水間朝大海打開,船也不會沉沒的。難以置信地是,沒有人受傷害。這是因為乘客在飯廳吃午餐,所以被切開的二等艙當時是空的。并且Hawke號配備了一個船頭沖角用來緩沖碰撞和減輕破壞。
IT項目必須謹慎地關注先前項目的"航行記錄",它們執(zhí)行過程的成功事例有助于確定需要學習的教訓,并且理解其中一些風險。對奧林匹克來說,明顯全體人員都被詢問過究竟是巨大的尺寸還是新的造船技術的船導致那些事件發(fā)生。
與Hawke號碰撞之后,奧林匹克卸下了1,300名乘客,在貝爾法斯特旱船塢停止服務了六周更換鋼板。在事故調查中,皇家海軍專家把責任歸結于比Hawke號重8倍的奧林匹克施加的強大吸力上,也就是通常所說的伯努利法則。這個事故值得注意,因為泰坦尼克在1912年離開南安普敦的時候,幾乎就要發(fā)生一次碰撞。更值得注意的是船長Smith,大副Murdoch和二副Lightoller都是這兩次航行中成員。事實上,白星晉升船長Smith來指揮艦隊的旗艦顯示了一種自信。Hawke事故一直在船長Smith心頭縈繞,然而,他不斷聲辯自己是清白的,是Hawke號撞了奧林匹克號,因此碰撞是Hawke號船長的錯。
IT項目應該按照使用規(guī)范和有關設置,嚴格地調查先前的解決方案是如何完成的(正常運轉)和它們的操作。任何一種故障或異常必須通過事后檢查嚴格地調查,并作為制訂計劃的輸入項。
結論
今天許多IT項目沒有為測試充分地制訂計劃,未能防止在解決方案中的嚴重妥協(xié)轉換成產(chǎn)品。這與泰坦尼克的失敗非常相似,由于輕信奧林匹克的經(jīng)驗,白星公司認為泰坦尼克的初次航行具有最低限度的風險。畢竟這兩艘船幾乎一模一樣,并且船的所有者和全體人員對泰坦尼克滿懷信心。然而,沒有兩艘船具有同樣的操縱特性。白星為無計劃的測試下了一個大賭注,而且橫渡大西洋的泰坦尼克號上船員的人數(shù)也不足定額。當泰坦尼克進入到下一次階段的時候,人們在觀念并沒有多少改變,仍然堅信船是永遠不會沉沒。
下一部分將講述IT項目的測試。
【?發(fā)表評論?0條?】