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

如何解決軟體的測試包袱？ 某個產品的專案，產品的歷史很悠久，使用的顧客人數也很多，但裡面有數量龐大、且歷史悠久的程式碼。每次只要加上幾個小功能，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納入，並以示意圖 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 示時，就可以看到以下的圖。 第四步：重新調整Test Strategy 在Test Plan中，通常有一項很容易被忽略的Test Strategy。 一般人可能會想測試需要什麼Strategy？不是每個版本都要Full Testing就好了？但事實上，在某些情況Full Testing不僅作不到、沒有必要、有時甚至浪費時間。例如在經過幾輪的測試後，可以很明確地知道某個Build，只改了少數的地方；又或者是某些只是改介面的Title的修正。 因為就現實面來看，除非是個重要到每年都有編列固定維護預算的專案，不然通常每個專案的維護預算都會逐年刪減、甚至是直接刪除。在資源排擠的情況下，要應付與日俱增的Test Case，即便採用了自動化回歸測試，也仍然會有資源的限制，和無法採用自動測試的項目。 所以建議方式就是對所有的Test Case標記測試的優先次序和必要項目，再設定可能會遇到的情況、以及該情況下需執行的優先次序和必要項目。 以發生錯誤的機率來看，筆者們可以把上述的項目，依重要性的高低由上而下排次序，重疊的部份則以重要性高的為準，變成以下的情況： 但採用這個方式排列測試的優先順序卻有個致命的缺點。若最重要的核心功能C沒通過測試，即使新功能K或Bug A、B通過測試了也沒有用，因為核心功能C的Bug使整個系統都不能正常運作了，所以核心功能C的測試順序和必要性應該高過新功能K或Bug A、B。 因此建議以「失效後的影響結果」作為擬定Test Strategy的考量，會是個比較務實的選擇： 另外，在每個版本變動的初期，測試的進度可能趕不上每個新Build出來的速度，這時候筆者建議，可以依照由上到下的優先順序橫跨數個Build以掃完所有的Test Case，之後可以再決定是要依照從上到下的優先順序分別測試每個Build。要想出前述的過程比較簡單，但真要作到這些活動，卻不容易。 除了因為這些活動需要花更多的資源管理，還因為這些活動後面需要有一套完整的開發資訊系統支援，以減少人力的需求、提昇這些活動的效率，但光是要建置這套系統就所費不貲，完全考驗開發組織的管理者對於軟體開發系統的決心。 以筆者的觀察，很少聽到或看到業界真有那間企業，真的能下定決心採購或自行開發、整合這類系統，以改善原本的開發流程。當然這後面自然有企業主在商業上的市場考量。 但即使真的導入了這類系統並改善了開發流程的活動還不夠，在實作時還需要System Designer和Programmer有相當的經驗，能貫徹Design for Test的精神，在設計系統架構的初期，就長遠地考量到後續的測試活動，才有機會在每一個版本，作到能釐清每個程式的變動後面所影響的範圍。 另外，決定Test Case的優先次序和必要項目本身也是個不容易的工作，需要有經驗的System Analyser和Test Manager花時間去釐清，倘若能在更早之前的決定需求階段就釐清這些資訊，會遠比在已開發完成後才回過頭去作來得容易。 所以真要作完整個「測試最小化」，需要不同部門在整個開發過程的不同階段，齊心合力的去作才有可能完成，更別說是要在事前就作大量溝通開發觀念以取得整個開發團隊的共識。