如何解决软体的测试包袱(繁体).docVIP

如何解決軟體的測試包袱？ 某個產品的專案，產品的歷史很悠久，使用的顧客人數也很多，但裡面有數量龐大、且歷史悠久的程式碼。每次只要加上幾個小功能，QA卻得花上三個月來做測試，甚至比開發的時間還要長！最後該讀者只好到處去調人來幫忙QA。 最後他問道：除了加人，還有什麼其他的辦法呢？解法是首先要導入SCM制度。 所謂的SCM（Software Configuration Management，中文翻譯成：軟體配置管理、或軟體組態管理）。簡單地說：就是對某個軟體內的每項功能的每項變更進行管控，並維護每項變更所影響的版本變更關聯，使軟體在開發過程中任一個時點的任何一項變更內容都可以被追溯。 但要作好SCM，至少得先作好RC（Revision Control，版本控制）再整合REQM（Requirement Management，需求管理），才能把這兩項資訊綜合在一起變成最後的SCM。 但光是要作好RC和REQM，對許些公司而言就是一項嚴苛的挑戰。以RC來說，和REQM相比，算是比較簡單的部份。安裝任何一套免費的RC軟體（如CVS、SVN、或SVK），再搭配一套Issues Track的軟體（如Bugzilla、Bugfree），就能架設好版本控管的「硬體」。 但困難的地方是安排「軟體」，也就是相對應的配合機制，如： 把Programmer 的 Local Space清空，改採Repository內的版本；．Checkin版本時要求加入Requirement、Issue(Bug) No及註解；加入協同開發的制度與習慣，讓多個成員能併行開發；依照程式的成熟度對Repository分層，以避免影響到已經驗證過的程式。 以REQM來說，在台灣的軟體業界，這個就更難了。 從提出需求的客戶開始，客戶通常對自己的需求不一定能完全瞭解，如果再加上未指派有相關經驗的人作為Contact Window、或是Contact Window有自己的業務無法兼顧專案，又加上客戶「通常」會大輻改變需求、不願依需求追加預算、甚至恣意縮減專案時程，種種的行徑都讓接案的業者吃不消。 從軟體業者的觀點來看，如果配上低價搶案，因為成本的考量又急著將專案結束以致未在初期花心血需求訪談、急就章的架構設計、缺少完整的需求管理的機制，再再都使需求在開發過程中漸漸發散到難以控管，最後的結果就是有很多專案都落得結不了案的下場。 老實說，要作好需求管理，從瞭解需求、取得需求承諾、管理需求變更、到維護需求的雙向追溯性，確實要花不少人力、成本；但不作需求管理的結果，只會讓軟體專案更難管理，越到後面越難收拾。 例如：產品XYZ的v1.2.3 專案中有：新功能K和Bug A、B。筆者們把上述功能、Bug所影響到的Test Case作為範圍時，可以用示意圖說明影響到的範圍（圓形的部份為XYZ全部範圍）。 假設筆者們修正的2個Bug中：Bug A需要修正2支舊程式A1、A2，而A1、A2除了Bug A的Test Case 外，還有各自其他的變動（Bug、功能修正）及其Test Case（A1、A2）；Bug B需要修正3支舊程式B1~B3，而B1~B3除了Bug B的Test Case 外，也各自有其他的變動及其Test Case（B1~B3）。 另外，新增功能K中：新增3支程式K1~K3僅包含此次變動的Test Case；修正舊程式3支K4~K6，而K4~K6除了功能K的Test Case 外，也各自有過去其他的變動及其Test Case（K4~K6）。 筆者們可以用示意圖說明上述內容中所有被影響到的部份。 第三步：釐清核心功能 另外，筆者們也需要重新對所有的Test Case分類，以區分出Test Case的重要性。 因為每個系統的功能不同、差異也很大，所以很難一概而論的說有什麼原則可供參考。但筆者通常會用「該功能的失效是否影響系統的主要功能」作為判斷依據。簡單地說，如果某個功能掛了，系統也就跟著失效或停擺，會使出貨系統不能出貨、薪資系統會計算錯誤、出勤系統無法正確記錄打卡時間，那這個就功就算是核心功能。 另外，如果以功能數的比例來看，核心功能的數量不應該超出所有功能的20%，因為依照「80/20法則」來看，「80%的結果將取決於20%的少數功能」。 如果筆者們再把這些核心功能C納入，並以示意圖表示時，就可以看到以下的圖。 第四步：重新調整Test Strategy 在Test Plan中，通常有一項很容易被忽略的Test Strategy。 一般人可能會想測試需要什麼Strategy？不是每個版本都要Full Testing就好了？但事實上，在某些情況Full Testing不僅作不到、沒有必要、有時甚至浪費時間。例如在經過幾輪的測試後，可以很明確地知道某個Build，只改了少數的地方；又或者是