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

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


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


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


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

留言

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

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

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

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮