昨天晚上 Teddy 接到以前公司同事（M小姐）打來的電話，問了幾個她在新公司所遇到的問題。M小姐是個很稱職的 PM，最近到了國內獲得 CMMI Level 3 認證的某大資服業（資訊服務業，就是去
10 年前開發的 F 1.0 版與其衍生的幾十個版本（據說新的 F2.0 版也是）都沒有任何的『自動化測試』。目前以 F 1.0 版為基礎的客戶所回報的 bugs 一共有 『 600 多個尚未解決的 bugs』。客戶對於 bugs 修復的進度緩慢感到非常不滿意，甚至直接打電話跟公司高層抱怨。
公司高層：M小姐，妳評估一下需要多少的人，在多少的時間內，可以把全部的 bugs 解決？
M小姐：??? （我又不是算命的... 這句是 Teddy 幫她回答的）
***
M小姐問 Teddy 幾個問題：
- 這 600 多個 bugs 要怎麼解決？（Teddy 內心獨白：我也不是算命的啊）
- F 1.0 版所衍生的幾十個專案，日後要如何維護？
- F 2.0 版即將完成，如果依照公司之前的模式，日後一定又會產生 N 個 F 2.0 版的衍生物，又會遇到維護的問題。
- 先把這 600 多個 bugs 分類，看看能否找出 bugs 的 patterns。例如，memory leak bugs，database transaction control bugs，UI validation bugs，business logic bugs，concurrent control bugs，exception handling 不良所產生的 bugs 等等。
- 從這幾十個 F 1.0 的專案中找出功能最多的，目前 bugs 最少，或是客戶最急的專案作為基礎，然後實施 code review。對照步驟 1 所整理出的 bugs 分類，看看能否從 code review 的過程中找出一些發生錯誤的蛛絲馬跡。
- 補寫 test cases。(3.1) 針對每一個準備修復的 bug，寫出一個自動化測試案例來重現這個 bug。(3.2) 或是對於不了解的功能，以寫 test cases 的方式來驗證與理解這些功能。(3.3) 針對準備 refactoring 的功能寫自動化測試。由於古早以 ASP 技術所開發的系統程式碼和 UI 大概都是混在一起，要寫自動化單元測試可能不是那麼容易。所以要依據程式結構實際狀況來研究一下這種自動化測試要怎麼寫。
- 導入持續整合。
- 如果一切順利，則看看有沒有可能用同樣的方法來修正其他專案的 bugs。
Teddy：頑皮頑皮推一推...Teddy 內心獨白...
- 這是什麼鳥公司...
- Automatic test cases 不會寫，失敗。不願意寫，失敗中的失敗。
- 一個號稱獲得 CMMI Level 3 的公司，要他們寫點自動化測試居然是那麼的困難，可見 CMMI 真的是很博大精深。CMMI，我真是猜不透你啊。
- 本校資工系大一學生修程式設計的課都要寫自動化測試了，號稱專業的資服業者居然都是用人工測試。
- 台灣的軟體開發團隊對於軟體工程的知識與實踐上的『貧富差距』真的很大。
- 地鼠 (bugs) 是打不完滴，只有把地鼠給徹底剷除，剷完再除，牠們才不會一直不停地冒出來。
- 也許應該考慮採用 Scrum 或是 Kanban 來改善軟體開發與維護流程。
- 把公司的電話線和網路線剪掉，手機關機，這樣就不會接到客戶的抱怨。
- 再次驗證了 Dave Thomas 所說的『All programming is maintenance programming』這句話。
***
友藏內心獨白：那些導入 CMMI 的顧問到底都教了人家什麼東西啊？
本部門也有通過CMMI Lv3啊,而且台灣SI公司本來就一直都是那種死樣子,很多老闆並不是持續處於"袁世凱"或"孫中山"的狀態,而是在"袁世凱"跟"孫中山"之間來回變化,景氣好的時候大家還可以行禮如儀地搞搞軟工,景氣不好接不到案子時就會開始逼每個人加班加到爆,也不管你是不是真的有那麼多工作要做
回覆刪除至於更新104,那是一定要的,但個人現在覺得去考個公職也是不錯的出路
To Lililala2:
回覆刪除我看乾脆去當兵好了。我們實驗室還真的有一個學弟給它簽下去當職業軍人，雖然薪水不多，但是只要撐 20 年就可以領終身俸也是不錯滴。
對了，你們有寫自動化測試嗎？
別組有導入自動化測試工具,至於實作情況如何 ..... 我得去問問才知道
回覆刪除To Lililala2:
回覆刪除你的意思是說，『你們這一組』沒有做自動化測試嘍？
做是有做,但就如同我說的,若你的老闆經常以趕時程為由要求"簡單測一下就好",那你是要宣稱有做還是沒做呢? (爆)
回覆刪除有時候問題不是那樣而已，很有可能不是不寫自動化測試的工具，是寫不出，尤其是你剛說了有段歷史的產品。
回覆刪除真的在做最前端的開發的人，單純UI的問題是寫不出自動測試的，這也是為什麼要引入MVC架構的原因，最少有兩部份可以做自動測試。
舉例來說，事實上，如果問題出在底層如JDK的focus有問題，怎麼測試也測不出來，我的經驗是focus很有可能是每天執行十萬次，一年可以出現一、兩次問題，但是那一、兩次問題一定要解。
所以開發非UI的人是幸福的。
To M. Jwo:
回覆刪除我完全贊同您的說法，GUI 自動化測試是不容易的。在文中 Teddy 提到，如果有可能的話要先對這 600 多個 bugs 分類，以區分哪些是，例如，UI的問題，哪些是 model 的問題。就算無法分類，如果可以先確保 model 這一層的邏輯是正確的，這樣就算 GUI 是採用人工測試，也可以找出相當比例的錯誤。但是，如果無法先確保 model 是正確的，這樣就比就不容意分別出問題出在哪裡。
另外一個重點是，M 小姐公司的高層認為『專案是不需要自動化測試的』，只有『開發產品』才需要。這是 Teddy 無法認同的想法（和是否為 GUI 自動化測試無關）。
最後，你提到『如果問題出在底層如JDK的focus有問題，怎麼測試也測不出來』，Teddy 以前也遇到好幾個 JDK 的 bugs 導致 AP 執行出了嚴重的問題。也許這個問題一開始無法被自動化測試找出來（因為根本不知道要寫這樣的測試案例），但是 (1) 一旦發現這樣的問題，就『有可能』可以嘗試撰寫自動化測試來暴露出這問題，(2) 就算是這樣的自動化測試寫不出來，至少這算是一個 known bug，也需該回報給 Sun (現在要回報給 Oracle ) 讓他們改 JDK (JRE)，或是，如您所說得『一年可以出現一、兩次問題，但是那一、兩次問題一定要解』。至於這個解法就要看實際應用環境，也有可能採用非軟體的解法。
PS：Teddy 用 Microsoft 的軟體，一年下來出的問題可能不下幾十次，Microsoft 也沒有『一定要解』的意思啊，您真的太負責了。
你誤解了，我回這篇是因為我們的產品也有一樣類似的問題，現在幾乎所有的問題都是UI了，我們也沒有自動化，但是我們的人工測試可以達到一個bug最少500-1000次模擬(比起幾萬次才中一次其實太少)。
回覆刪除因為有帳務問題，只發生一次可以說是測錯，但是只要發生兩次了，User就會強迫你一定解。不可能換JDK即使是update版都不行，因為那代表全部重測試，所以只能自己在外面透過某些機制改動，而不能也不行等sun來改。
Hi M. Jwo:
回覆刪除如果確定是 Java GUI 的問題，不是也有 GUI 自動測試的工具可以用嗎？Teddy 學校有一個老師就是在研究 GUI 自動化測試，幾年前參加 meeting 時也聽過好幾次學弟報告 GUI 自動測試的問題，略懂皮毛...不過這不是重點...Teddy 有一事不明，您說『所以只能自己在外面透過某些機制改動，而不能也不行等sun來改』所以您必須在程式中做特別的判斷，如果測到這個『bug』發生，在採取特別的手段來『修補』是嗎？
GUI test tools 只能測試標準問題。我們有用IBM Rational Robot（當然是客戶買的，貴）。
回覆刪除真實狀況舉例，比如說某個狀況下，欄位的值會被清空，所以就會收到空值的資料，簡單的解決方法可以在server做檢查，但是我的架構主要是前端檢查過後端就不檢查，所以欄位清空是不可被接受的。
以一天大約一百萬次的頁面來說，根據不同的客戶，一年會發生一到五次。
更麻煩的重點是，Sun/Oracle也知道問題了，所以會在新版做修正，不可能上新版因為測試test effort過大，別以為auto unit test就夠了，我們最近一個專案unit test完整沒問題，但是SIT的bug一天開出30個，完全符合unit test。上次某客戶的估算，估計要上一個新版的JRE，需要大約20個User測試三個月，這還只是UAT的功夫。
所以我們必須自己上JRE patch，而且是每個版本的JRE都要patch，已經有1.1.8,1.2.2,1.3.1,1.4.x(多版）,1.5.x(多版),1.6.x(多版），所以我們公司對Java UI(Swing)的認識非常的深入。還是不敢說都沒問題就是了，問題還是會發生，只是機率更低，就我所知道.Net, SWT等都有類似的問題，只是看客戶的重視程度。
完整的解法是把檢查都放server side，因為server沒有UI的問題，就算字不見了可以踢回。Java的強項畢竟是EE端，所以J2EE的市場遠大於J2SE。
回覆刪除Hi M. Jwo:
回覆刪除感謝您的分享，請問您的應用是 Web AP 還是 Swing AP，還是兩者都有?『一天大約一百萬次的頁面』感覺起來像是 Web AP，但是您又提到『所以我們公司對Java UI(Swing)的認識非常的深入』。Teddy 很好奇如果是 Swing AP 一天要有『一百萬次的頁面』不知是何種類型的應用ㄋㄟ...
作者已經移除這則留言。
回覆刪除swing (move to browser now)，短程式每次執行時間需要在一秒內完成，輸入時間大約一分鐘。客戶大小不同使用者大約600-6000人，依據角色每人每天平均200次執行，經過可能有問題欄位大約600個以上。
回覆刪除都百萬誇張點，小點的客戶大約30萬次。