嵌入式軟體的測試(三)

作者：
針對與時間因素有關處理的潛在錯誤而設計的測試案例，可能是嵌入式軟體測試的另一個精華表現。譬如，不少人都有如此的經驗：只要不規則地亂按一些按鍵，有時就可把手機或其他手持設備弄當掉，必須重新開機才行；但若要詳細說明如何才把那個機器弄當掉的，卻又說清不楚，也不一定有把握每次都可以把機器弄當掉。

我們都知道在硬體沒有問題的前提下，如果發生當機狀況就是因為軟體中有錯誤存在(反過來則不一定，即軟體中有錯誤卻不一定會造成當機)。但是，在看似相同的使用過程(或給予相同的輸入資料)中，有的時候可以正常運作，而有的時候卻發生當機，那是怎麼回事呢？一般來說，是因為受到時空因素不同的影響才可能產生這種現象。先舉一個類似的例子來說明：如果一個星期以前用"ABCD"為關鍵字在 Google 上搜尋所得到的結果，與一個星期之後同樣用"ABCD"為關鍵字在 Google 上搜尋所得到的結果，兩者不一定是相同的；因為網路上那麼多人在創造資訊，只要時空因素有改變，雖然其他同樣的處理程序及條件不變，輸出的結果就可能會不一樣。如果需要掌握輸出結果，就必須能掌握時空因素的描述，譬如當清楚指明使用 Google 搜尋的確切時間以及地區別時，也許 Google 就能再度輸出一份完全相同的結果(當然這要看 Google 提供的服務功能到底有多強才行，在此只是個協助說明的例子)。

一個成功的、以找出可能與時間因素有關錯誤為目的的嵌入式軟體測試案例，是可以清楚地描述如何用一組輸入資料(包含輸入順序、或時間間隔等等說明)來把機器弄當掉的。只要依照測試案例的內容來執行測試，如果實際輸出結果與預期的輸出不同(譬如當機了)，那這個版本的軟體就存在著某種(即測試案例的目的所描述的)時間因素有關錯誤。另外一個重點是，不會發生有時正常、有時卻不正常的狀況，因為成功的測試執行結果必須要能隨時再產生(reproduce)。

獲得這樣一個測試案例設計的費用，若相當於一個軟體工程師半個月的薪水，你覺得是便宜還是貴呢？(再提醒一次，相對而言，嵌入式軟體的測試是比較簡單的軟體工程技術應用。)

留言

  1. 劉立頌2008年11月7日 下午1:55

    一直很想回應，但一直在拖，雖然一點久，可是還是感謝劉教授提出這非常有趣的主題，畢竟嵌入式系統的應用廣泛，軟體開發的確是有一些值得注意的事項，包括如有無OS的系統，或是SoPC等平台上的軟體開發。

    如果案例設計的費用是一個軟體工程師半個月的薪水，當然是非常值得。可是多少時候，我們在許多project同時到期的壓力下，『沒有辦法』投資這重要的代價。

    這讓我聯想到另外一個問題，嵌入式軟體通常被視為platform-dependent。那麼我們有多少東西能reuse呢？如果測試案例每次都得重新設計，那麼感覺太浪費了。這會回來讓我們思考，如何作好知識的傳承。不只是軟體的開發，還包括測試的know-how。

    是否能提供一些經驗呢？

    回覆刪除
  2. 薛念林2008年11月7日 下午3:21

    這個星期一參加了一個嵌入式軟體的座談會，討論了一個類似的議題：需不需要成立一個『嵌入式軟體的測試中心』，提供公正的測試驗證結果。基本上產官學都十分希望有這樣的組織，討論也很熱烈。會中我提出了兩個問題，但因為時間的關係，並沒有討論到，或許可以從這裡得到一些答案。

    第一如何確認一個測試中心的正確性？因為沒有人可以保證軟體是沒有錯的。第二，台灣有IC測試（硬體）的公司，為什麼沒有軟體測試的公司？嵌入式可說是軟硬體通吃的產業，他在建立測試中心時應該注意什麼呢？

    回覆刪除
  3. LLLiu2008年11月7日 下午6:46

    真的有很多東西想寫，雖然沒整理，甚至還有點亂七八糟：
    一、立頌兄提的軟體開發與軟體測試，在我個人認知就是像在 security 相關研究裡的攻方與守方；乍看之下似乎是各有出發立場，但實際上最後是一樣的(攻的人想盡辦法攻，守的人想盡辦法守；最後才會共同瞭解問題的 lower bound 所在)。我是認為軟體測試最後就是與軟體開發(需求分析、設計)共同建置出好的軟體，其 competence 是一樣的。
    二、薛教授提的兩個問題，可能還先要有前題才好討論。譬如：測試(testing)與認證(certification)究竟有何不同？硬體與軟體的測試究竟有何不同？這些都是值得先吵一吵的，否則答案寫完了才發現題目沒看清楚，那考試分數不會好看的。一般的直覺想法都是要"通過測試取得認證"，但如同薛教授所說，軟體測試的目的是要證明軟體中有錯誤存在，並不是要證明軟體的正確性，那這裡不是很矛盾嗎？軟體測試應該是不會去管認證的，除非是專門發放"軟體有錯誤"的認證。其實有心人好好坐下來想一想，軟體測試中心的功能是可以浮現的，譬如專門設計各種有效的測試案例可能就是一大德政。
    三、再強調一次，嵌入式系統軟體的測試(非硬體)是屬於比較簡單的軟體測試，容易上手，也是很好的起點。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容