輕鬆談軟工

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

這次辛樂克怪颱侵台，重創台灣，其中后豐大橋斷橋，造成1死5失蹤的大不幸事件，照理颱風來前就必須封閉該危橋，但事後我們的官員說依照「程序」處理，這種說法讓我想起陳振炎教授文章所談的敏捷方法，我曾在其「意見」箱內談到，使用任何敏捷方法時不要忘記敏捷宣言的精神，我認為宣言的精神不但使用敏捷方法時必須時時在意，處理日常事務亦須念茲在茲，宣言第四項"Responding to change over following a plan"，"plan"可解釋為一種「程序」，程序故然重要，但反應變動應高於程序(不含法律)，這位官員在這個時候的這種說法有待商榷，也許他的字典裡沒有「敏捷」這種東西吧! 敏捷(agility)最重要的定義是：快速與彈性反應改變(rapid and flexible response to change)，或說"embrace change"，change就是一種變動，能快速並彈性處理各種變動(如封橋)才符合敏捷精神，因此如能活用敏捷之義，其功能大矣! 總之，如果不懂embrace change，可能會誤用各種發展「流程」的真義，我們可以看看CMMI ML5：具調整與修正流程的能力‧‧‧，(本部落格中鄭有進教授文章：CMMI是什麼？)，將發展流程客戶化就是調整與修正流程，可想見使發展流程適合自己專案之需的重要性，但這要靠人，所以說"People over Process"。

這是我還在讀研究所時所發生的事。有一個在職的同學突然間常常出現在實驗室，一副很輕鬆的樣子。他的公司在美國算是很大的公司（應該說是非常大的公司），軟體部門也非常大，而且他一向忙得不可開交，很難想像他怎麼有可能這麼輕鬆。原來他們所做的project 竟然提早一個月結束，team leader告訴他們不要讓經理知道他們已經做完，暫時享受一下悠閒的時間，所以他就有時間來學校晃一晃。 這種事當然不可能常發生，可是到底發生什麼？是招標端（客戶端）的評估能力差？cost estimation 的問題？project planning的問題？太高估了？假如兩方老闆發現了，會怎麼樣想？假如你是team leader你會作什麼？more testing? more refactoring?

台灣軟體業積弱不振, 可能因思維較舊所致: 工廠思維: 軟體工程在 1968 NATO 大會出現時, 仿效其他工程領域, 把軟體視為工廠生產, 講求精細分工 嚴格控管 注意產量成本等. 但新趨勢是, 軟體講求創意及合作, 像 工藝家聯合工作室, 而不像工廠. 電機思維: 軟體本由電機電子而來, 從The Institute of Electrical and Electronic Engineers, Inc, IEEE 這代表性機構的名稱, 即可看出此沿革, 但演進至今, 軟體已與電機無關. 軟體業界深知軟體開發(含物件導向開發)需製作大量文件( 含程式)，構成龐大負擔，常導致很多溝通不準或思考不週之處 (即 Bugs)。有些公司製作不少文件卻乏人閱讀，全無溝通之效；甚 或冀望多年後維修程式時，將會閱讀文件， 殊不知程式是不斷變動的，文件更新常趕不上變動的。 敏捷方法視開發為合作活動(如攀岩)，力求以面對面直接溝通， 來取代目前文件製作及閱讀的間接溝通，使開發變得快而準(即 agile)。 又，敏捷方法以測試來帶動開發 (Test-driven development)，軟體品質極佳。 最後，除國外重視的溝通訓練外，吾人亦加強國人不足的思考訓練， 溝通及思考乃深層基本功；–練功後人人紮實、軟體優質， 再用逆向工程工具動態產生class diagram, sequence diagram等，有可能敏捷達 成CMMI 一些process areas 的 goals。 此敏捷方法係陳振炎教授擴充極限開發法 (extreme programming)而得， 方法細節請見下面網站的上課教材：敏捷方法苗圃 ( www.agilemethod.csie.ncu.edu. tw ) 陳振炎教授 國立中央大學資訊工程系

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

最近因為接了行政職，生活開始忙碌了起來。為了能夠讓訊息暢通與方便行程的安排，忍痛買了 BlackBerry 黑莓手機。黑莓手機手機在國外賣的嚇嚇叫，他的 QWERT 功能讓習慣電腦操作的人愛不釋手，實際使用後，發現它的好處不只這些。 國外的系統在介面的使用上的確著墨很多，BB 的介面讓你很快的建立一個會議 --- 一隻手就可以辦到。查詢聯絡人的資料也是，即便你有上千筆的聯絡人，也可以在很短的時間內找你要的人，然後寫 email, 送 MMS 或打電話給他。資工系的學生通常會以『沒有美感』來作為介面設計不好的藉口，這個觀念應該要改。 回到主題來談談錯誤的管理。BB 雖然功能強大，但還是會有錯誤。寫過程式的我們都知道程式的錯誤難免，也可以忍受 --- 只要他們有專業的報修制度。我打過幾次電話，前兩次電話響了近三分鐘都沒有回應，直到第三次才有人來接，但回應是『晚上沒有技術人員，請我白天再打』。我猜想他們的流程大概是這樣子的吧： customer reports the bug through phone help desk records the bug, ask the engineer resolve the problem on line if they are available. If the engineer are not available, ask the customer call later.  現在的手機功能太強，就像是一個小秘書，沒有小秘書兩三天還得了？所有的工作都停擺了。顧客可沒有辦法配合他們的維修流程啊（白天大家忙得要命，哪有時間打電話)。於是我上了 google, 打上錯誤訊息，一下子跑出好多的解決方案。看了第一個方法，我就解決了我的問題。 BB 他們做了什麼？什麼都沒有做 ，只是許多閒暇 人事透過 web 2.0 將他們的錯誤解決方法寫在部落格上，透過許多人不斷的回應，於是最佳解決方案就出來了。或許報修的流程要改一下： customer reports the bug through phone ask the customer to "google their problem", if not resolved, go step 3. help desk records the bug, ask the engine

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