2010年9月14日星期二

如何撰寫測試計畫?

reference: http://www.fisc.com.tw/fiscweb/fiscbimonthly/Article.aspx?Volume=49&TNo=213
鄧介銘 財金公司安控部品管測試組組長
陳星誌 財金公司安控部品管測試組高級工程師

現今之金融業在電子化服務導向下,倚賴資訊系統進行客戶服務已成為必然之發展。若欲進一步瞭解金融資 訊系統之運作穩定度及效能優異性,軟體測試扮演著關鍵性的角色。軟體測試作業的良窳與金融資訊系統服務品質息息相關,如何利用自動化測試工具來提高測試效 率及測試管理,進而提升金融資訊系統軟體測試品質,相信是金融業資訊人員極有興趣探討且持續關注之焦點議題。
人們常常誤以為,開發程式較具困難度,測試程式則較為容易,這其實是個誤解。軟體測試實為一門學問,它具有 作業方法、作業流程與理論基礎,因設計測試個案是一項細緻且需要高度技巧的工作,稍有不慎就會顧此失彼,導致不應有的疏漏發生。舉例來說,台灣正準備營運 的高速鐵路在自行系統整合測試完成後,在國外獨立驗證機構發表的整合測試報告中,仍被列出多項缺失,由此可見測試之複雜性。先進國家資深測試人員在進行專 案測試前,會先撰寫巨細靡遺且面面俱到的測試劇集(Test Scenario),保證所有作業處理程序及流程點均會被妥善測試,劇集裡的測試個案組合可能是彼此獨立卻可同時進行的測試,或是資料流程互為因果必須依 序進行的測試。自此不難看出,尋找好的系統開發設計人才並不困難,但要尋找一個經驗豐富的測試規劃人員,卻是可遇而不可求的道理。
軟體測試概念範疇極廣,金融資訊系統基礎架構可能大致相似,但不同應用系統及產品之軟體測試設計卻迥然不 同。本專欄將以介紹金融資訊系統軟體測試概念切入,首先談如何撰寫測試計畫;撰寫測試計畫之時機;測試計畫應包括那些項目等。接著,進一步介紹實務上經常 運用之測試類別、測試方法、測試個案設計種類及測試管理工作內容,並淺談測試分級概念,最後則分享本公司累積之測試心得。本篇內容若有不詳、不清楚或不正 確之處,尚祈各位先進海涵指正。
如何撰寫測試計畫
一、為何制訂測試計畫書
所有測試都會針對單一或數個測試目標,為了防止測試進度停滯不前,導致測試作業成效不彰的情形發生,每種測試皆須制定詳盡的計畫。撰寫測試計畫書有三個主 要用意:第一、藉由遵循測試計畫書內的標準作業程序,較利於軟體測試之進行;第二、透過測試計畫書制度化的呈現方式,可讓測試人員之間的溝通更加順利暢 通;第三、測試計畫書可使軟體測試以自動化系統的方式進行,易於測試作業之追蹤管理。
二、測試計畫書之撰寫及修訂時機
測試計畫書可撰寫於大型軟體開發專案尚未建立測試管理平台之前,或於軟體開發過程中,評估出可能影響現行系 統資源甚鉅之特殊測試需求時,始進行撰寫。若應用系統進行一般性之維護測試作業或現行系統新增子系統功能測試作業,可以不必撰寫測試計畫,但需檢視現行之 測試個案是否能滿足該異動內容之測試需求,如與需求不符,仍須增、修訂現行測試計畫及測試個案後始進行之。
三、測試計畫書種類
測試計畫書可分為三類,單一文件測試計畫書(STP:Single Test Plan)、主要方針測試計畫書(MTP:Master Test Plan)及詳細運作測試計畫書(DTP:Detail Test Plan)。
(一)STP:
所謂單一文件測試計畫書,即是彙整所有測試規劃議題後,將之撰寫在同一份文件上。這類做法的優點是可以集中所有軟體測試的工作項目及資源,便於管理掌控。 自管理人員的角度來看,集中管理當然有其方便性,但是,相對的這份測試計畫書的內容就會顯得複雜。
(二)MTP:
主要方針測試計畫書主要是將大型的軟體開發測試專案規劃成不同的階段進行,對每個階段均設計概略的測試方針。
(三)DTP:
詳細作業測試計畫書通常參照主要方針測試計畫書使用,亦即是將主要方針測試計畫書的內容詳細分解後,另於詳細測試計畫書中予以表現。因此,通常一個MTP會伴隨數個DTP以供參閱,這種方式相當適合大型的軟體開發專案。
四、測試計畫書內容
測試計畫書之內容架構概述如下,惟各種測試專案差異性頗大,測試人員可自行依測試環境、資源現狀及內部控管規範等增、刪減各個項目,換言之,測試計畫書是彈性非制式之工作說明書。
(一)導引:
說明系統架構、測試計畫要旨及軟體品質保證相關之目標任務。
(二)測試目標:
測試目標應該相對集中,必須是明確且可以量化的,而非模擬兩可的宏觀描述。一般較具規模之應用系統,往往很難同時全面進行整體測試,故需要以系統功能面、 業務需求面或系統介面規格等面向,劃分為較小之子系統後進行測試,但應保持子系統測試目標與主系統測試目標維持一致。
(三)測試範圍:
測試範圍主要描述各個測試階段需要或不需要測試的產品功能。需要測試的產品功能,包含:單元測試、整合測試、功能測試、介面測試、效能測試、配置測試、設 定測試(Configuration Testing)及使用者接受度測試等;並需描述不需要測試的產品功能,例如:測試資料與資料庫資料一致性測試、容量測試、壓力測試、安全性測試(使用者 作業權限、IP/PORT、FIRE WALL)等,皆是與產品功能非直接相關之排外測試。
(四)測試策略及測試時程:
此部分在說明各測試階段之測試對象及測試方法。由於軟體測試之測試時間有限,在測試人員隨時處於時間壓力下,其應如何安排測試時程之建議如下述:
  1. 首先決定必須列入測試所有項目;
  2. 接著決定各測試項目之優先順序;
  3. 最後決定各測試項目之時間配置。
(五)測試開始與中斷條件:
此項目旨在說明測試開始的條件,舉例來說,測試前應具備交付完成的文件清單(如:系統功能說明書、系統規格說明書及已執行過的測試資料等文件),但是,卻 常發生很多文件尚未提供或提供不完整等情形,導致測試人員常因此無法得知異動內容,進而被文件中不全、錯誤之描述誤導,有時,甚至僅被通知測試某些功能而 已。若測試人員只是重複執行在開發階段已測試完成之部分,不同之處僅是測試環境及程式過版版本之正確性兩者,由此可以預見這類測試的結果是無法發現問題所 在,如此一來,系統於上線營運時將承擔極高之營運風險。另外,此部分仍需說明何種條件下可中斷測試,以避免測試人力空轉,大部分測試計畫書時常忽略此項目 之說明,但是,開始條件與中斷條件均為測試中極重要的一環,必須相關單位協力配合此項規定,才能順利完成測試作業。
(六)測試項目通過/失敗標準:
訂定測試項目(測試個案、各測試階段)通過/失敗的標準,是測試計畫書較少提及,卻與測試品質及測試分級密切相關的重點之一。
(七)測試完成繳交項目:
應明確列出測試作業完成後應留存之測試相關文件(如:測試資料、測試記錄及測試報告等),其留存年限則依單位內部規範辦理。
(八)排定測試工作時程:
描述測試環境設定、測試需求分析、測試個案設計撰寫、測試執行程序(測試流程)、測試人員名單及工作分配、測試人員的技術能力要求與針對新專案新技術所需要的教育訓練等各項時程規劃。
(九)測試軟、硬體資源需求:
列舉測試環境所需具備之軟、硬體規格、週邊系統網路、輸出入設備清單及數量等。
(十)潛在問題與風險評估:
測試亦存在風險,且多少隱藏一些死角。然而,安全性是一個複雜的領域,進行測試作業前,須先評量此次測試的風險可能集中何處,務必讓風險降到最低。一旦識 別出風險,則應依照嚴重性劃分風險等級,風險的嚴重程度將會影響系統的需求和目標。測試人員應視軟體行為功能、市場狀況和公司資源等制訂須留意的風險標 準,一般而言可以留意以下幾個因素:
  1. 落實風險評估;
  2. 確定較常出現的問題點皆有對應之解決策略;
  3. 列出風險清單,並逐項檢查漏掉重大的問題之可能性;
  4. 評估出現Bug時,公司付出的代價為何;
  5. 測試發現的問題是否徹底解決,抑或是暫時排除而已,仍無法確定問題發生原因;
  6. 喪失公司原有市場之可能性;
  7. 從事過多非必要的測試或重複測試,導致測試過度集中而忽略其他部分。
五、測試問題追蹤管理與分析
進行每項測試作業難免會發現問題,因此,為確保問題已被有效地排除,改善及校正,問題管理的生命週期就顯得 相當重要。制定測試計畫書可確保問題被妥善管理與分析,非但不會帶來阻礙,反倒能以極正面之姿態呈現系統規劃設計或程式開發過程未盡完美的部分。若公司內 尚未使用問題管理系統,或實已具備卻使用效果不佳時,制定測試計畫書即可建立修正問題的機會。
在軟體開發過程中,每一階段均有相對應之測試計畫,其對應關係如下表,透過此項連結,才能保證每一個階段具有達成品質控管目標之能力。
(表一)軟體開發階段與測試計畫對應表
需求分析階段
確認測試計畫目標及測試範圍 ( 理論上,需求分析完成後即應完成測試計畫,但實務上幾乎無法達成 )
系統規劃設計階段
確認測試策略及測試個案設計完成
系統開發程式
撰寫階段

測試計畫撰寫完成

沒有留言:

張貼留言