給我測試案例，其他免談(一)
以寫程式為生(領薪水)的朋友一般都不會擔心程式太大寫不完，但都討厭要配合所謂客戶要求的「需求變更」而常常要把已經寫好的程式不斷改來改去，作很多虛功。依據我的觀察，對這些程式設計高手而言，原來已經寫好的程式要再修改，大概超過 3 次就是耐心的極限了；因為此時的程式已經幾乎是變得體無完膚，不但客戶不會滿意，連寫程式的人自己看了也會想吐血。
對程式設計高手而言，寫程式從來不會有什麼問題，而要寫出「什麼程式才是真正你要的東西」才是大問題。偏偏，「需求變更」就是一個他人常用的藉口(因為不一定是客戶要求的，只要之前有人在需求分析階段有錯誤或偷懶沒有詳細分析，最後都可歸咎於需求變更)，反正是你先去寫，然後他再去看，刺激他的神經之後，再提出他的修改看法叫你改，如此永不疲憊。另一種狀況是，需求分析說明文件的內容只是應付軟體工程開發階段的記錄，非常抽象，譬如是「能令使用者感到愉快的一個小型輸入畫面」。
如果我是負責程式設計的，在看完那種「不可能的任務」(Mission Impossible)需求分析說明文件之後，我因為要繼續領薪水、又要能融入傳統的軟體開發工作團隊之中，我就可能會轉而要求負責軟體測試的團隊成員趕快先把測試案例設計出來，不要等到我把程式寫好了再用這些案例去測我的程式，請他們先把完整的測試案例給我。因為既然以後是要用這些測試案例來測我的程式，那我就依據這些案例的內容來設計我的程式，只要在測試執行時這些案例都能順利通過，我的程式就找不到與這些測試案例目的相關的錯誤了。
給我測試案例，其他免談。
對程式設計高手而言，寫程式從來不會有什麼問題，而要寫出「什麼程式才是真正你要的東西」才是大問題。偏偏，「需求變更」就是一個他人常用的藉口(因為不一定是客戶要求的，只要之前有人在需求分析階段有錯誤或偷懶沒有詳細分析，最後都可歸咎於需求變更)，反正是你先去寫，然後他再去看，刺激他的神經之後，再提出他的修改看法叫你改，如此永不疲憊。另一種狀況是，需求分析說明文件的內容只是應付軟體工程開發階段的記錄，非常抽象，譬如是「能令使用者感到愉快的一個小型輸入畫面」。
如果我是負責程式設計的，在看完那種「不可能的任務」(Mission Impossible)需求分析說明文件之後，我因為要繼續領薪水、又要能融入傳統的軟體開發工作團隊之中，我就可能會轉而要求負責軟體測試的團隊成員趕快先把測試案例設計出來，不要等到我把程式寫好了再用這些案例去測我的程式，請他們先把完整的測試案例給我。因為既然以後是要用這些測試案例來測我的程式，那我就依據這些案例的內容來設計我的程式，只要在測試執行時這些案例都能順利通過，我的程式就找不到與這些測試案例目的相關的錯誤了。
給我測試案例，其他免談。
劉教授所言的確不失為解決過度需求變更，或是使用者無法定義明確的好方法。是否這也是另一種 TDD (test driven development) 的說法？
回覆刪除我覺得此法甚好，不知道目前是否有業界真正在實施。
nlh, FCU
教授您好，有個小疑問，測試案例是依照需求來寫的對吧，程式又根據測試案例來撰寫，那如果需求改變後，測試案例不是也要做修改嗎?如此一來程式不是也要跟著改?
回覆刪除謝謝您。
軟體發展的進展過程是不斷提升抽象層次(level of abstraction)，由(1與0)->(組合語言)->(第3代語言)->(MDA模式)，只不過到目前為止，模式與業務之間尚存有一些間隙，縱看這種進展軌跡，寫程式似乎有點「落伍」，雖然近期吵得火熱的敏捷方法，如XP，TDD等等，仍然以寫程式<->測試為主，只不過採取iteration的方式試圖解決需求變更的問題，依個人淺見，「寫程式」不如改「寫模式」，程式則可由模式自動轉換產生，保養時則保養模式，也就是所謂PIM，依照熱中MDA的人的說法，PIM相當於可run的程式，如果你相信這種說法，我(也不只是我)可大膽預測，有一天就不必煩惱寫程式，只不過目前PIM>Code尚未100%而已(大約85%左右)。如有仁人君子願「挑戰」上面說法，本人願舉更多範例與理論。
回覆刪除說的沒錯, UML virtual machine研究就是這方向
刪除我的看法：
回覆刪除1. TDD 在業界用得並不多，也許如 Junit 這類的東西有一些朋友在嘗試使用。
2. 這部份我會再寫一段與梅比烏斯帶子( Mobius Strip)似有同構的東西來一起討論，請稍候。(或請先參考今年年初出版的 IEEE Software 雜誌，其中有一篇文章講這個，主要是說測試案例一般會比需求說明清楚得多。)
3. 黃教授所言正確，但 V&V (包括各種測試)可能也會是 MDA/MDD 的議題，因為總會是要 validate 看 PIM 是否恰當的。如果真能限制人類彼此之間交談時只能用有限固定的句子(詞彙、文法、語意都完整定義)，那就不會有言語上的誤會，但實際上是無法規範的。程式語言(不管多麼高階)也有同樣的現象，早期的 Functional Programming Language (黃教授是專家)、Prolog 等都是屬於 Specification Language，只要用它寫出規格，其它就 OK。但是這些東西都比不過微軟的 VB。也許還需要時間 MDA 才會逐漸普遍，而 code <-> testing 的環境還是大部份業者朋友要面對的現實。
您好!我原是硬體QA，轉戰軟體後看到此篇文章
回覆刪除在QA的角度，此方案不免會發生『球員兼裁判』的情形
我已經知道答案了再從答案來去測試，是否喪失了測試的目的???