給我測試案例，其他免談(二)

作者：
寫程式的人也要負責最基本的軟體測試工作，那就是單元測試的部份。也因為如此，這類測試常常會跟除錯一併進行，反正一個人要能負責把程式弄好(最起碼在自己能設想到的普通狀況下要能算出正確的答案)，用什麼方法都行。


除錯器(debugger)是最有效的軟體開發輔助工具了，設定中斷點，程式執行到那裡的時候可以逐次檢查各個暫存器的內容、變數的值等等，所有狀況清清楚楚，好不威風。如果沒有除錯器支援怎麼辦？沒關係，自己來。沒有把握的程式部份就在裡面多加一些指令或敘述，把當時的環境狀況、變數現值印(顯示)出來，然後追蹤看看到底自己腦子裡想的、手裡寫出來的，以及編譯器、函數庫、作業系統等系統軟體所轉換出來、認知的，究竟有什麼差異。通常弄明白以後，錯誤就能除掉了。


如果這個概念明確，那是不是可以考慮把測試案例就寫在原來的程式裡呢(怎麼寫先不管它，因為現代的程式語言都蠻複雜的，相關測試輔助系統也還不夠人性化)？當程式執行時「恰好」遇到與測試案例所規劃的狀況相同時，就表示在作單元測試了，預期正確結果可以與當時的計算結果比較，如果兩者相同就不作任何動作，否則就進入例外特殊處理的程式部份。如此，雖然有一點吹牛，但以後當我再說「給我測試案例，其他免談」的要求時，是否表示我這個寫程式的可能已經到了精益求精的水準，負責測試的同仁也不敢不給我了？


事實上，XP(eXtreme Programming) 派軟工朋友所提倡的 Test Driven Development 方法就是在這些方面表現其功力。他們定義的 unit test 就是一段 code，能達到相當於處理單元測試工作的功能，而不是傳統的一個程序(到 Wikipedia 網站上查一下就可以找到很多相關資訊)。

留言

  1. 黃為德2008年8月18日 晚上8:18

    XP或TDD依個人所了解都是code<->test之間做iterative and incremental(I&I)動作，但是從MDA的觀點來看，I&I的動作應該改用在PIM<->test，這中間涉及抽象層次的問題，暫時不談，不過對MDA來說，可以把PIM看成是一種可執行的程式，但先決條件是自動轉換，要除錯也是除PIM的錯，如何除模式的錯也許有機會再來「輕鬆談」，據了解，這類的談論不多。另外，agility並不只適用於軟體發展方法，發展團隊也可以agile一番，這一點對組織單位而言個人認為相當重要。

    回覆刪除
  2. LLLiu2008年8月18日 晚上10:11

    請參考「給我測試案例，其他免談(一)」的第4 個意見(那是一天以前寫的，比現在這個意見早一些，但觀念一致)。

    回覆刪除
  3. 黃為德2008年8月19日 上午10:56

    我想"wirte tests before coding"是敏捷方法如TDD的基本精神，「給我測試案例，其他免談」是否是這個意思？不過我認為與如何capture requirements的方式有關，看樣子use case或IEEE 830都不適合，大概user stories比較適合你說的案例，文中未談到用何種方法定義需求。我要在此地補充一點，要測試PIM仍然須要將其自動轉換為程式，只不過不是保養程式而是保養PIM(包括除錯、修改、應付變更等等)，這一點也許與「‧‧‧免談」文章無直接關係，我只是提出另類思考，這個思考與agility精神有關，也許改天再論。

    回覆刪除

張貼留言

這個網誌中的熱門文章

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比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容