輕鬆談軟工

家裡總有些小蟑螂，我們想盡了各種方法來除小蟑螂，例如買強力黏蟑紙，或是殺蟑螂的誘餌，一開始都有點功效，但過了一陣子蟑螂又跑出來了。 根本的解決之道在於，蟑螂為什麼會到我家？過去我們大概兩三天會倒一次垃圾，因為家裡的塑膠袋是大的，每天倒垃圾覺得浪費。於是我們換成小的垃圾袋，並開始每天倒垃圾，於是乎家裡的小蟑螂慢慢地就不見了。 治標真的不是辦法，必須要找出問題的根源並加以解決。 軟體的開發也是，如果你的公司不斷的產生 bug, 或是品質出現問題，別只是見 bug 除 bug，得好好想想： bug 為何會出現？

Continuous Integration 在討論版本控管時，我們曾經提到WiMAX計畫使用一個輔助工具「 JCIS 」進行持續整合(Continuous Integration)的工作。那麼，為什麼要做持續整合呢？維基百科中對於 持續整合 的理論有些初步的介紹，包含下列十個重要的Practices： 維護一個程式庫(Maintain a code repository) 將建置自動化 (Automate the build) 使建置能進行自我測試(Make the build self-testing) 每人每天送交程式碼(Everyone commits every day) 每次送交都應該被建置(Every commit should be built) 維持快速的建置時間(Keep the build fast) 在實際運行的環境下進行測試(Test in a clone of the production environment) 簡化取得最新可交付版本的方法(Make it easy to get the latest deliverables) 每個人都能看到最新版建置的測試結果(Everyone can see the results of the latest build) 將佈署自動化 (Automate deployment) 上述許多Practices都要求自動化，自動化又可以分為半自動和全自動，以半自動為例，可能是有人每天固定手動執行make指令，將所有要建置的檔案編譯與連結，接著有人將結果複製到實際運行的環境，再下指令讓電腦執行所有的測試，這個過程雖然必須由人來操作，但只要下少許指令就可以完成了。那麼全自動呢？就是在專案開始的時候進行若干設定，之後由電腦自動處理一切編譯、連結、測試等工作，這就需要一套輔助工具了。 要確實完成這麼多的Practices，其實門檻是很高的。即使是在企業界，也難免會有不遵守遊戲規則的軟體工程師，更何況我們的開發主力是學校裡沒什麼專案成敗壓力的學生。舉例說，要做到「每人每天送交程式碼」幾乎是不可能的，基本上學生開發程式是有一天沒一天的，最多只能要求到「有修改就必須送交程式碼」。另外像是「每次送交都應該被建置」，在我們第一年的WiMAX計畫中可以說是完全失敗。在開發環境未能統一的...

版本控管 在整合國科會CMMI文件與程式開發的過程中，總計劃與各子計畫的文件與程式都需要一個版本管理的機制，一方面萬一有電腦當機或是檔案損毀時，可以迅速還原最新的版本，解決資料備份的問題，另一方面還可以在歷史紀錄中往返，將刪去的文件或程式找回來。對於文件或程式整合而言，版本控管十足是一個Time Machine。 我們在第一年開發之前就已經預期到版本控管的重要性，因此在專案初期便架設可透過Web介面存取的版本控管伺服器(Apache + Subversion)，並且安排Subversion的教育訓練。但是，可能是一開始時教育訓練的內容安排不符合需求，也可能是開發團隊不夠用心，導致版本控管並不上軌道。最常發生的問題包括：團隊成員未確實解決衝突(Conflicts)、久久不送交(Commit)程式、送交無法編譯的程式、送交時不寫註解等。 這些問題的原因，有部分與先前討論過的缺乏一致的開發環境有關，部分團隊使用的IDE沒有支援版本控管，所以得在IDE編譯完後才知道有沒有問題，然後再使用其他版本控管軟體(TortoiseSVN等)送交程式；或在Windows上取出(Check out)程式然後複製到Linux的機器上修改與編譯，然後再複製回Windows上覆蓋舊版本後送交，然而在取出後到送交前的這段時間，如果沒有進行更新(Update)和合併(Merge)的動作，這些行為常常會導致衝突。 久而久之，有些團隊成員開始害怕使用版本控管系統，導致送交的週期越來越長，甚至有超過二個禮拜沒有送交程式碼，失去使用版本控管的優點。長時間的修改送交週期，也讓成員忘記曾經修改過什麼東西，自然不知道要寫什麼註解，這些都是讓版本控管失去威力的錯誤行為。經過一整年的觀察後，總計畫在第二年開始前，重新規劃Subversion的使用方式。 首先，我們將版本控管的支援加入一致的開發環境中。在Virtual Machine中，我們使用Eclipse搭配Subclipse套件，讓IDE與版本控管合而為一，之前也提到，單元測試的執行也加到程式中，這些都是確保程式無誤的前置作業。另外，針對文件撰寫的環境(通常是Windows平台)，撰寫TortoiseSVN的操作手冊，讓新加入的成員快速進入狀況。 接著，我們訂定幾個需要遵守的原則(Principle)，在文件部分，要進行編輯的文件一定要...

以往學生在學軟體工程時，總覺得這門課就是在「寫文件」，對於為什麼要寫文件，以及文件的用途，不甚了解，甚至覺得寫文件是很枯燥乏味的一件事。的確，為了交作業而寫文件，我想沒有人會認為寫文件是有用的，特別是對於一個虛擬的軟體專案而言，即使必須開發對應的軟體，充其量也是一個小品，而且一個學期的時間又很有限，所以不是文件品質不好就是軟體沒寫好，更別提要維護了， 而學生無法對軟體跟專案產生情感，自然無法體會文件的意義。 過去三年，筆者因為主持國科會整合型計畫「WiMAX 無線通訊系統軟體與工具開發(I),(II),(III)」的關係，需要主導撰寫其Light-weight CMMI文件，剛開始的第一年，參與計畫的學生們也是哀鴻遍野，學生們即便已經參加過國科會舉辦的Light-weighted CMMI研討會，寫出來的文件，和實際的軟體設計仍有一段很大的落差，一直到第二年，需要開始維護第一年的軟體時，學生才慢慢體會到軟體工程要的不只是文件，而是文件所帶來的價值：溝通與管理。 有一個經常被提到的問題是「軟體流程」？我們的WiMAX整合行計畫到底有多大呢？是否真的需要軟體工程或是完善的軟體流程才能完成呢？這裡先簡單描述一下我們的案子，大家都知道WiMAX被視為M-Taiwan重點發展項目，WiMAX(802.16e)是一個相當複雜的通訊協定，而我們的目標是開發一套完整的「WiMAX網路模擬軟體」，由於WiMAX由上到下包含許多子層，而各子層又各須非常專業的知識，因此，這個案子需要軟體工程加入，才能有效地整合各種跨領域的知識，構成一個完整的系統。也因此我們(北科大軟體研發中心)才提出這個跨領域的整合型計畫，希望開發出WiMAX網路模擬軟體，以開放原始碼的方式貢獻給業界作為WiMAX參考模型，並分享我們的開發經驗。 在WiMAX的案子中分成三個主要項目：「應用」、「協定」與「輔助工具」，應用有「即時視訊傳輸應用」與「適地性資訊服務」；協定負責WiMAX通訊協定的所有子層包含媒體存取控制、安全加密、實體層編碼、實體層調變與通道模擬；輔助工具則提供通訊軟體模型建構工具與持續整合等輔助。由此可知，計畫規模頗大，最多曾經有12個子計畫。軟體流程不能保證專案如期完工，但能用來監控時程與進度，如果沒有流程，進度落後或是超前，都無法掌握，那軟體勢必是無法順利開發與整合的。 有了第一年的...

一夥程式設計師正在啟奏當今皇上。『今年有什麼偉大的成就嗎？』皇上問道。 程式設計師私下討論了一會兒，然後回話：『比起去年，我們今年多修正了50% 的Bug』 皇上滿臉困惑的看著他們。他們顯然並不知道『Bug』是什麼。他低聲與宰相商量一會兒，然後轉向這些程式設計師，面露慍色。『你們犯了品質管制不良之罪。明年起不得在有任何的Bug！』他當庭宣下這道聖旨。 當然啦，明年當這夥程式設計師再度向皇上奏報時，就完全不提 Bug 的事了。 以上是取自 G.M. Weinberg 的著作 Quality Software Management v1: System thinking 的中譯本： 軟體管理學-系統化思考 內的一個小故事。Prof. Wenberg 是我個人滿喜歡的一位軟體工程作家，他總是能用淺顯易懂的小故事道破許多軟體工程的問題。把這本好書推薦給大家，有空的話真的可以好好看看。

本來應該寫在 Code inspection 的代價 一文的意見中，但考慮到內容比較多，故還是以一文說明。 看了許多專家的看法，我也提出自己的看法。我的假設是這樣的 Programmer 的月薪為 35,000/月 資深的 inspector 月薪為 60,000/月 速紀員可能是系統助理，月薪較低，為 28,000/月 主席的月薪為 60,000/月 雖然一天工作八小時，但扣掉一些喝水、聊天的時間，一天工作有六小時應該不錯了，所以 這些角色分別的時薪應該分別為 182 (35000/((30-8)*6)), 312, 145, 312。真的是蠻低的吧。 在 overview 階段 review 的速度為 500/statement, 所以共需 2 小時，假設 overview 的階段 scriber 不需參加，則成本為：(1*182+2*312+312*1)*2 = $2,236 在 individual preparation 階段 review 的速度為 125/statement, 所以共需 8 小時，因為此階段 scriber 與 chair 不需參加，則成本為：(1*182+2*312)*8 = $6,448 在 inspection 階段每個人都要參加，因為 review 的速度為 90/statement, 所以共需 11 小時，則成本為：(1*182+2*312+145*1+312*1)*11 = $13,893 在 follow up 的階段進行除錯，假設錯誤率為 3%，亦即有 30 個錯誤，而程式員除錯的效率為每個錯誤需要五小時除錯，則需要 5*182*30=27,300。 加總以上的成本則共為 $49,877 。但這可不是這 1,000 行程式的成本， 這僅是 code inspection 的成本 ，不包含分析、設計、實作與後續動態測試的成本啊。光這樣看來，每行程式的價值就有將近 50 元， Szuwulin 所言『 五 行一塊錢』似乎是少了些。 問題是台灣很少執行 code inspection 的動作，而是以後續的動態測試才取代。我們知道， 動態測試是治標不治本的方法 ，它 能找到的錯誤是比較少的。假設有有一半的錯誤沒有在動態測試中被找出來而不小心流到使用者手上，那代價可能很難估算。第一：如果造成客戶的業務損失; 第二：維護階段除錯的效...

除了動態測試（執行程式來檢驗是否正確）以外，靜態的檢視也是非常重要的測試方法。檢視的對象可以是 code, 設計文件、需求文件等。當檢視的對象是 code, 我們稱之為 code inspection，一般而言有以下的角色： 撰寫者 (owner) ：程式的撰寫者 檢視員 (inspector) ：檢視程式的錯誤，通常都是較為資深或領域專家 速記員 (scriber) ：在檢視會議中幫忙記錄 主席 (chair/moderator) ：仲裁與協調會議的進行 在分工比較細的組織中，甚至還有報告者，但可以撰寫者來兼任。靜態檢視可以分為幾個步驟 簡介 (Overview) : 由撰寫程式者向所有的檢視者簡介系統內容 獨立準備 (Individual Preparation): 每個 inspector 獨立的閱讀與檢視程式碼，並將疑問處圈選出來，預備在會議上討論 檢視會議 (inspection): 檢視程式碼 追蹤 (follow up) : 修正會議上所找出來錯誤，並持續追蹤 依照 Sommerville 書上的資料顯示， 簡介、獨立準備、檢視會議  的速度分別是 500, 125, 90 statement/hour, 假設我們完成了一個 1,000 statement 的程式碼，檢視員有 2 位， 請問一次 code inspection 花公司多少錢？值得嗎？ （請假設每個員工的薪水）。有興趣的大家一起算算吧！

針對與時間因素有關處理的潛在錯誤而設計的測試案例，可能是嵌入式軟體測試的另一個精華表現。譬如，不少人都有如此的經驗：只要不規則地亂按一些按鍵，有時就可把手機或其他手持設備弄當掉，必須重新開機才行；但若要詳細說明如何才把那個機器弄當掉的，卻又說清不楚，也不一定有把握每次都可以把機器弄當掉。 我們都知道在硬體沒有問題的前提下，如果發生當機狀況就是因為軟體中有錯誤存在(反過來則不一定，即軟體中有錯誤卻不一定會造成當機)。但是，在看似相同的使用過程(或給予相同的輸入資料)中，有的時候可以正常運作，而有的時候卻發生當機，那是怎麼回事呢？一般來說，是因為受到時空因素不同的影響才可能產生這種現象。先舉一個類似的例子來說明：如果一個星期以前用"ABCD"為關鍵字在 Google 上搜尋所得到的結果，與一個星期之後同樣用"ABCD"為關鍵字在 Google 上搜尋所得到的結果，兩者不一定是相同的；因為網路上那麼多人在創造資訊，只要時空因素有改變，雖然其他同樣的處理程序及條件不變，輸出的結果就可能會不一樣。如果需要掌握輸出結果，就必須能掌握時空因素的描述，譬如當清楚指明使用 Google 搜尋的確切時間以及地區別時，也許 Google 就能再度輸出一份完全相同的結果(當然這要看 Google 提供的服務功能到底有多強才行，在此只是個協助說明的例子)。 一個成功的、以找出可能與時間因素有關錯誤為目的的嵌入式軟體測試案例，是可以清楚地描述如何用一組輸入資料(包含輸入順序、或時間間隔等等說明)來把機器弄當掉的。只要依照測試案例的內容來執行測試，如果實際輸出結果與預期的輸出不同(譬如當機了)，那這個版本的軟體就存在著某種(即測試案例的目的所描述的)時間因素有關錯誤。另外一個重點是，不會發生有時正常、有時卻不正常的狀況，因為成功的測試執行結果必須要能隨時再產生(reproduce)。 獲得這樣一個測試案例設計的費用，若相當於一個軟體工程師半個月的薪水，你覺得是便宜還是貴呢？(再提醒一次，相對而言，嵌入式軟體的測試是比較簡單的軟體工程技術應用。)

假設有一個非常簡單的嵌入式軟體，它的開機模組功能包括要檢查所有主機內 10 個硬體組件是否能正常運作；其中具輸出功能的燈號、螢幕、喇叭，具輸入功能的按鈕、麥克風，具儲存功能的記憶體等都必須完整檢查(否則就算開了機，使用者可能不知道，或是使用者知道已開機但操作按鈕卻無法動作)，其他的如插孔或卡槽介面就等要用時再檢查。 要怎樣設計測試案例來測試這個開機模組呢？負責嵌入式軟體的朋友最怕是硬體出毛病，自己不知道卻還一直在那裡找問題，所以就瞄準這一方面先下手無妨。測試目的就定為「找出螢幕壞了卻還繼續處理開機程序的錯誤」，測試步驟是找一台主機、把螢幕拆掉(或把相關連線拔掉、真的把螢幕弄壞等等)、然後按開關鈕。預期的正確結果應該是開機模組要用其他的燈號或喇叭來輸出訊息提醒使用者螢幕壞了，同時停止繼續開機的程序。真正測試的時候如果出現的不是這樣的預期結果就證明開機程式還有這個錯誤存在。 負責測試的朋友幫負責寫軟體的朋友找出這個錯誤以後，程式的邏輯處理內容就改成如果檢查到螢幕有問題就要用閃爍燈號或喇叭發聲來提醒使用者，看是要送修或怎樣，然後停止執行。這時候的潛在衍生錯誤就可能會發生了，譬如原來設計的開機檢查順序是先檢查螢幕再檢查燈號及喇叭，所以如果螢幕不正常時可以馬上就用燈號及喇叭嗎？它們還沒有被檢查呢。還有，如果螢幕有問題要先閃爍燈號，要閃爍多久後才停止繼續處理呢？需要再測試嗎？ 據一些有經驗的專家表示，現在採用以開放原始碼(open source)為軟體基礎的嵌入式個人隨身設備，例如 PDA 手機，其程式規模(包括系統軟體及應用軟體)大約在 500 萬行左右。可以想像的是，這裡面絕對是夠複雜的，不管它們是怎麼樣組合而成。如果再回頭去看那一段最基本的開機模組部份，最原始的版本可能只需要 200 行就足夠了；但是為了要陸續通過那些測試案例而再加進去的部份，會有多少行？說不定是 2000 行。另外的議題則是，加進這些行數以後的新版本，是否提高了產品的品質？如果是，那當初看來似乎沒有什麼了不起的測試案例就是有意義的。 相關文章： 嵌入式軟體的測試(一)

嵌入式軟體、客戶訂製軟體、套裝軟體三者，那一個最難設計製作？那一個又最簡單？這些問題也許因為立場或看法的不同而會有不同的答案；不過我是認為嵌入式軟體應該是最簡單的。主要的依據是一般嵌入式軟體都只需要跟硬體打交道，只要都打點好就行；但是如客戶訂製軟體就不一樣，必須跟人打交道，而偏偏每個人的想法或看法卻不一定相同，很難搞定。套裝軟體就更複雜了，在設計的時候可能還不知道將來是那些人會買來用的。 順著這個邏輯，嵌入式軟體的測試相對而言也會是比較單純的。(補充一下，如果沒有領域知識，那任何軟體的設計製作都會是很難的。所以如果是因為對於嵌入式軟體是怎麼一回事還不太清楚而認為嵌入式軟體最難的朋友，也許在開始接觸過一陣子之後就會改變想法了。) 嵌入式軟體的測試，主要是組態測試(configuration test)與控制測試(control test)。組態測試是要找出軟體模組之間可能的不協調(synchronization)，而控制測試是要找出因為時間掌握(timing)沒有考慮週到所發生的不協調。以嵌入式系統開機功能為例，負責開機功能的軟體先要分別檢查所有的硬體(如記憶體及其他晶片組等等)是否能正常運作。最簡單的方式是循序一樣一樣來，但是如此開機時間就長，使用者無法接受；因此投機的方式就是只檢查最主要的幾樣，其它等將來要用的時候再檢查，節省時間。設計這種測試案例，是最典型的嵌入式軟體的組態測試技術。 如果對這個有興趣，可能還需要去參考一下軟體工程書上給予「組態」的定義：一組為達成某一共同目的、由組態項目所形成的集合。組態測試就是要設法證明某個嵌入式軟體的組態事實上不完善，不符合組態的定義。(PS. 希望這一段寫得不要太玄。) 相關文章： 嵌入式軟體的測試(二)

對於軟體開發人員而言，好的測試案例應該是很有價值的東西，因為如果一個軟體在依據一個測試案例進行測試執行時無法得到正確的預期結果，就知道有某個特定的錯誤存在；而如果這個軟體能在依據所有的測試案例進行測試執行時都得到預期的正確結果，那就不會有人可以說什麼話了，乖乖地付錢給寫程式的人吧。(當然，這必須是針對所謂「好的測試案例」才有意義，否則隨便寫兩、三個測試案例，寫程式的人也可以隨便寫幾行程式就應付自如，只是程式還是無法使用，自欺欺人而已。) 從這個角度來看，會設計「好的測試案例」的人應該在軟體開發團隊裡是有其一定地位的，這種人與一般寫程式的人在心態上就不一樣，大多是以「防禦性」或「預防性」的方式來處理程式邏輯；譬如從來不假設所有可使用的資源(如記憶體)是永遠不會有問題的，因此只要需要任何資源都會先確定這個資源的取得沒有問題才開始動作，否則就進入特殊狀況處理程序。這種人設計的測試案例非常細緻，專門找平常不容易出現的錯誤。(正常狀況都無法得到正確結果的實在不夠資格稱為軟體，真的。) 經驗豐富的軟體從業朋友在工作時是很有樂趣的，旁人只見到高來高去的溝通，而且非常有效率，一點都不八股，同時生產力與品質都有一定的水準(agility?)。在這種環境之下，似乎需求說明文件或需求規格都可以抽象化，文件規模大量減少，幾頁的文圖就可以描述一個應用系統，尤其是不太需要人機介面的核心模組。這些文件原有內容跑到那裡去了？答案是測試案例，那些細緻的、正常狀況下都不會發生的可能預防作為描述，都在測試案例說明裡面。 專家們相信，測試案例與需求規格兩者很可能是相同的東西，就像是拓樸學裡介紹的梅比烏斯帶子(Mobius Strip)，沒有裡面或外面之分；而測試案例比需求規格略佔優勢的地方是，測試案例的描述一般比較明確，需求規格的描述則會弱一些。對軟體開發階段與轉換程序而言，越是明確的描述，越能讓轉換所得的軟體堅實(solid)。這個觀點目前應該是還沒有方法來證明，所以只在提出與討論的階段；雖然有可能是亂想一通(研究的過程之一)，但感覺上似乎不離譜。 你的看法如何呢？難道只是又把需求分析的工作藏到測試案例設計去了？

寫程式的人也要負責最基本的軟體測試工作，那就是單元測試的部份。也因為如此，這類測試常常會跟除錯一併進行，反正一個人要能負責把程式弄好(最起碼在自己能設想到的普通狀況下要能算出正確的答案)，用什麼方法都行。 除錯器(debugger)是最有效的軟體開發輔助工具了，設定中斷點，程式執行到那裡的時候可以逐次檢查各個暫存器的內容、變數的值等等，所有狀況清清楚楚，好不威風。如果沒有除錯器支援怎麼辦？沒關係，自己來。沒有把握的程式部份就在裡面多加一些指令或敘述，把當時的環境狀況、變數現值印(顯示)出來，然後追蹤看看到底自己腦子裡想的、手裡寫出來的，以及編譯器、函數庫、作業系統等系統軟體所轉換出來、認知的，究竟有什麼差異。通常弄明白以後，錯誤就能除掉了。 如果這個概念明確，那是不是可以考慮把測試案例就寫在原來的程式裡呢(怎麼寫先不管它，因為現代的程式語言都蠻複雜的，相關測試輔助系統也還不夠人性化)？當程式執行時「恰好」遇到與測試案例所規劃的狀況相同時，就表示在作單元測試了，預期正確結果可以與當時的計算結果比較，如果兩者相同就不作任何動作，否則就進入例外特殊處理的程式部份。如此，雖然有一點吹牛，但以後當我再說「給我測試案例，其他免談」的要求時，是否表示我這個寫程式的可能已經到了精益求精的水準，負責測試的同仁也不敢不給我了？ 事實上，XP(eXtreme Programming) 派軟工朋友所提倡的 Test Driven Development 方法就是在這些方面表現其功力。他們定義的 unit test 就是一段 code，能達到相當於處理單元測試工作的功能，而不是傳統的一個程序(到 Wikipedia 網站上查一下就可以找到很多相關資訊)。

以寫程式為生(領薪水)的朋友一般都不會擔心程式太大寫不完，但都討厭要配合所謂客戶要求的「需求變更」而常常要把已經寫好的程式不斷改來改去，作很多虛功。依據我的觀察，對這些程式設計高手而言，原來已經寫好的程式要再修改，大概超過 3 次就是耐心的極限了；因為此時的程式已經幾乎是變得體無完膚，不但客戶不會滿意，連寫程式的人自己看了也會想吐血。 對程式設計高手而言，寫程式從來不會有什麼問題，而要寫出「什麼程式才是真正你要的東西」才是大問題。偏偏，「需求變更」就是一個他人常用的藉口(因為不一定是客戶要求的，只要之前有人在需求分析階段有錯誤或偷懶沒有詳細分析，最後都可歸咎於需求變更)，反正是你先去寫，然後他再去看，刺激他的神經之後，再提出他的修改看法叫你改，如此永不疲憊。另一種狀況是，需求分析說明文件的內容只是應付軟體工程開發階段的記錄，非常抽象，譬如是「能令使用者感到愉快的一個小型輸入畫面」。 如果我是負責程式設計的，在看完那種「不可能的任務」(Mission Impossible)需求分析說明文件之後，我因為要繼續領薪水、又要能融入傳統的軟體開發工作團隊之中，我就可能會轉而要求負責軟體測試的團隊成員趕快先把測試案例設計出來，不要等到我把程式寫好了再用這些案例去測我的程式，請他們先把完整的測試案例給我。因為既然以後是要用這些測試案例來測我的程式，那我就依據這些案例的內容來設計我的程式，只要在測試執行時這些案例都能順利通過，我的程式就找不到與這些測試案例目的相關的錯誤了。 給我測試案例，其他免談。

也許歐美的軟體都已經被別人測試得差不多了(雖然我們知道事實上軟體是測不完的，但總是會有人擔心說重要的軟體測試早已就被作掉)，所以我們不妨用中文資料處理應用中最基本的「排序」這個領域來看一下軟體測試的市場空間有多大(究竟我們的中文應用水準要比歐美人仕要強得多吧)。 假設有一個軟體模組 utility.sort 等著我們作黑箱測試。我們瞭解排序的基本計算方法對於程式設計師而言是很簡單的，而程式設計人員自己也已先作過單元測試，所以好像感覺上黑箱測試也玩不出什麼新花樣來。但是幾乎所有的軟工書上都說要先作等值分割，而稍微花一點功夫坐下來想一想，就可能會發現真的有許多不同的資料群組可以形成叢聚；譬如在數值方面，除了常見的整數之外，實數部份的有理數與無理數等等，都是等值分割的參考基礎。一般程式設計師是比較容易犯錯的原因不外是對這些數系定義域的忽略(因為唸書時都學過的)而已；試想，若把 0.33、1/3、1/3.0、3**0.3 等數值一起輸入此模組，執行出來的排序結果與預期的正確結果不同的機會可能是蠻高的。再進一步看，若把 123(數字)、一百二十三、壹佰貳拾叁、１２３(全形字)等數字及中文資料輸入此模組時，執行出來的排序結果是否會與預期的正確結果相同呢？我想機會是非常低的。因此，只在數值資料(不同資料格式)的定義域上作等值分割，就已經真的可以開始進行測試案例的規劃了(書上老掉牙的技術還是不錯的)。 接下來在非數值方面，那空間更是廣大了。中文資料的排序習慣上不外乎是依據筆劃或部首、注音等等，但不管怎麼樣，都不應該用內碼值的大小來處理，因為那是不具意義性的。若把王小明、李美麗、林國棟等姓名資料輸入此模組，執行出來的排序結果與預期的正確結果比較如何呢？此時突然發現所謂的預期正確結果本身就值得懷疑，為什麼是王小明、林國棟、李美麗？難道林國棟、李美麗、王小明就不正確嗎？顯然越想下去問題就越多。 是不是一個最基本的排序軟體模組就需要很多的測試人力呢？

軟體測試相關的詞彙很多，最常聽到的可能是單元測試、整合測試、系統測試、alpha測試、beta測試等與一般軟體測試工作階段有關的區分說法，或是如黑箱測試、白箱測試等與軟體測試方法有關的區分說法，或是如驗收測試、回歸測試等與軟體測試基本觀念有關的說法。另外在非功能需求方面如：人機介面測試、資料庫介面測試、網路介面測試、例外狀況處理測試、多國語言支援能力測試、資訊安全防範能力測試等等，也都是目前很普遍的說法。雖然這些詞彙原則上都是直接由英文翻譯過來，但軟體從業人員或軟工學生應該多少都能知道它們的含意及大致內容。 不管怎樣，有這麼多種的詞彙就可能表示有這麼多種不同的軟體測試工作需要處理，或許是要人力來擔當，或許是要用軟體工具來協助。從另一個角度來看，這就是商機，因為需要人力就代表著業務機會(企業)或是工作機會(個人)，而需要軟體工具就是軟體產品的市場機會。 我們來看一下軟體測試的市場有多大吧。一般軟體工程專業人士認為軟體測試相關工作的比重大約是整個軟體開發工作的 40% 以上，而程式寫碼相關工作的比重則約是整體軟體開發工作的 15% 以下，其他工作包括需求分析、設計，以及品質管理、組態管理等。如果以微軟視窗系列產品(如 NT、XP、Vista)開發的人力資源記錄來看，大概每一項產品都約在數千人年(NT: 900人x3年=2700人年、Vista: 1500人x5年=7500人年)，因此其中任一項的 40% 就表示至少 1000 人年的軟體測試人力資源需求。 在台灣，假設一般中小型軟體公司每人年的營業能力為新台幣 100 萬元，則 1000 人年的軟體測試的潛在市場即為新台幣 10 億元，或是相當於目前 10~20 個具 50~100 人力規模軟體公司的共同年營業額。

每次我在課堂上開始介紹軟體測試的目的是要「證明程式中有某一種錯誤」，而不是要表示程式是對(註*)的時候，總是有不少學生會瞪大了眼睛，或是以為我不小心說錯了，或是認為這是一個不可思議的說法，因為這跟自己以往的直覺認知完全不同。 (註*：以目前使用的軟體開發方法而言，一個典型的軟體幾乎不可能沒有錯誤存在。) 其實，軟體測試作法(也就是證明程式中有某一種錯誤)的原理很簡單：假設我們認為一個程式裡存在著一種錯誤 e。我們特意去設計一組輸入資料 I，如果把這組資料輸入到這個程式來執行時應該得到的輸出結果是 O。然後我們真的把這組資料拿給這程式來執行，得到 O' 的輸出結果。如果 O 與 O' 不同，那就證明這個程式果然有 e 這個錯誤。 軟體測試的原理說來簡單，但要想出可能存在的錯誤種類以及設計一組可以找出這種錯誤的輸入資料，就必須有幾把刷子了。通常這就是「測試案例設計」的專業工作，先要能規劃出到底一共要設計多少個測試案例(也就是想好要找出那幾種程式設計師可能會犯的錯誤)，然後再在每一個案例中設計出一組或多組輸入資料與執行後應該得到的正確輸出結果。 依據別人設計的測試案例把資料輸入、記錄輸出結果看看與應該得到的正確結果是否相同的工作報酬，事實上與在麥當勞打工的數字是差不多的，因為不需要太多專業技能(當然還是要有基本的知識，並不是每個人都能勝任在麥當勞打工的工作的)。但是如果能夠設計好(註**)的測試案例，那就會有很顯著的報酬差異了，說不定可以多一個零。 (註**：譬如找出錯誤的機率比較高，或找出的錯誤可以大幅增進軟體品質等等。) 以往台灣的製造業多以代工為主業，產品的組態都是由下單的買主自己規範；現在台灣的製造業對自有品牌的意識越來越強，產品的組態，尤其是其中軟體部份(譬如智慧型手機的嵌入式軟體)的品質，更已成為競爭的要素。如果大多數的軟體從業人員都在寫程式的紅海裡辛苦打拼，是不是，相對地，軟體測試的藍海是另一個不錯的取捨呢？