l

2010年5月31日 星期一

600 多個 bugs 要怎麼修?

5/31 22:36~23:56

昨天晚上 Teddy 接到以前公司同事(M小姐)打來的電話,問了幾個她在新公司所遇到的問題。M小姐是個很稱職的 PM,最近到了國內獲得 CMMI Level 3 認證的某大資服業(資訊服務業,就是去 接案子的公司啦)的某部門負責維護專案。她們部門負責某軟體(在本篇的代號為 F 軟體)的維護,她們公司有一個產品的 team 負責開發 F 軟體,完成之後就用這個 F 軟體去搶專案,搶到之後由於每個專案都需要做『客製化』,因此每接一個專案就產生一份 F' 軟體。專案結束之後,為這個專案所客製化的功能並不會回饋到原本的 F 軟體中 (錢都到手了,誰還管那麼多。)。M 小姐所在的維護部門,養了幾個 programmers,每一個人負責 10 來個專案的維護工作(就是修 bugs 啦),但是這些負責維護的 programmers 其實並不全然了解整個系統。F 1.0 版是在 10 年前用 微軟 ASP 技術開發出來的,目前有幾十個客戶,也就是說有幾十個不同的 F 1.0 版本。目前產品 team 即將完成 以 .NET 技術開發的 F 2.0 版。

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 要怎麼解?Teddy 怎麼可能會知道,只能依照常理來開藥方:

  1. 先把這 600 多個  bugs 分類,看看能否找出 bugs 的  patterns。例如,memory leak bugs,database transaction control bugs,UI validation bugs,business logic bugs,concurrent control bugs,exception handling 不良所產生的 bugs  等等。
  2. 從這幾十個 F 1.0 的專案中找出功能最多的,目前 bugs 最少,或是客戶最急的專案作為基礎,然後實施 code review。對照步驟 1 所整理出的  bugs 分類,看看能否從 code review 的過程中找出一些發生錯誤的蛛絲馬跡。
  3. 補寫  test cases。(3.1) 針對每一個準備修復的 bug,寫出一個自動化測試案例來重現這個 bug。(3.2) 或是對於不了解的功能,以寫 test cases 的方式來驗證與理解這些功能。(3.3) 針對準備 refactoring 的功能寫自動化測試。由於古早以 ASP 技術所開發的系統程式碼和 UI 大概都是混在一起,要寫自動化單元測試可能不是那麼容易。所以要依據程式結構實際狀況來研究一下這種自動化測試要怎麼寫。
  4. 導入持續整合。
  5. 如果一切順利,則看看有沒有可能用同樣的方法來修正其他專案的 bugs。
M小姐:可是要求 programmers 寫自動化測試不太可能。其他專案的 PM 會認為『寫程式的時間都沒有了哪有時間寫測試』。Programmers 也會有類似的想法。

Teddy:頑皮頑皮推一推...Teddy 內心獨白...
  • 這是什麼鳥公司...
  • Automatic test cases 不會寫,失敗。不願意寫,失敗中的失敗。
  • 一個號稱獲得 CMMI Level 3 的公司,要他們寫點自動化測試居然是那麼的困難,可見 CMMI 真的是很博大精深。CMMI,我真是猜不透你啊。
  • 本校資工系大一學生修程式設計的課都要寫自動化測試了,號稱專業的資服業者居然都是用人工測試。
  • 台灣的軟體開發團隊對於軟體工程的知識與實踐上的『貧富差距』真的很大。
  • 地鼠 (bugs) 是打不完滴,只有把地鼠給徹底剷除,剷完再除,牠們才不會一直不停地冒出來。
  • 也許應該考慮採用 Scrum 或是 Kanban 來改善軟體開發與維護流程。
  • 把公司的電話線和網路線剪掉,手機關機,這樣就不會接到客戶的抱怨。
  • 再次驗證了 Dave Thomas 所說的『All programming is maintenance programming』這句話。
Teddy 和 M小姐通了一個半小時的電話,講了一堆有的沒的,最後還是請她回去請示一下她的老闆,確認一下她老闆是屬於『袁世凱』還是『孫中山』。如果是前者,那就千萬不要想太多,做一天算一天,有空就更新一下 104 上面的履歷表,隨時準備開啟。如果是後者,則可以考慮找人幫忙導入 Scrum  或是一些軟體開發的 practices。

***

友藏內心獨白:那些導入 CMMI 的顧問到底都教了人家什麼東西啊?

14 則留言:

  1. 本部門也有通過CMMI Lv3啊,而且台灣SI公司本來就一直都是那種死樣子,很多老闆並不是持續處於"袁世凱"或"孫中山"的狀態,而是在"袁世凱"跟"孫中山"之間來回變化,景氣好的時候大家還可以行禮如儀地搞搞軟工,景氣不好接不到案子時就會開始逼每個人加班加到爆,也不管你是不是真的有那麼多工作要做

    至於更新104,那是一定要的,但個人現在覺得去考個公職也是不錯的出路

    回覆刪除
  2. To Lililala2:

    我看乾脆去當兵好了。我們實驗室還真的有一個學弟給它簽下去當職業軍人,雖然薪水不多,但是只要撐 20 年就可以領終身俸也是不錯滴。

    對了,你們有寫自動化測試嗎?

    回覆刪除
  3. 別組有導入自動化測試工具,至於實作情況如何 ..... 我得去問問才知道

    回覆刪除
  4. To Lililala2:

    你的意思是說,『你們這一組』沒有做自動化測試嘍?

    回覆刪除
  5. 做是有做,但就如同我說的,若你的老闆經常以趕時程為由要求"簡單測一下就好",那你是要宣稱有做還是沒做呢? (爆)

    回覆刪除
  6. 有時候問題不是那樣而已,很有可能不是不寫自動化測試的工具,是寫不出,尤其是你剛說了有段歷史的產品。
    真的在做最前端的開發的人,單純UI的問題是寫不出自動測試的,這也是為什麼要引入MVC架構的原因,最少有兩部份可以做自動測試。
    舉例來說,事實上,如果問題出在底層如JDK的focus有問題,怎麼測試也測不出來,我的經驗是focus很有可能是每天執行十萬次,一年可以出現一、兩次問題,但是那一、兩次問題一定要解。
    所以開發非UI的人是幸福的。

    回覆刪除
  7. 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 也沒有『一定要解』的意思啊,您真的太負責了。

    回覆刪除
  8. 你誤解了,我回這篇是因為我們的產品也有一樣類似的問題,現在幾乎所有的問題都是UI了,我們也沒有自動化,但是我們的人工測試可以達到一個bug最少500-1000次模擬(比起幾萬次才中一次其實太少)。
    因為有帳務問題,只發生一次可以說是測錯,但是只要發生兩次了,User就會強迫你一定解。不可能換JDK即使是update版都不行,因為那代表全部重測試,所以只能自己在外面透過某些機制改動,而不能也不行等sun來改。

    回覆刪除
  9. Hi M. Jwo:

    如果確定是 Java GUI 的問題,不是也有 GUI 自動測試的工具可以用嗎?Teddy 學校有一個老師就是在研究 GUI 自動化測試,幾年前參加 meeting 時也聽過好幾次學弟報告 GUI 自動測試的問題,略懂皮毛...不過這不是重點...Teddy 有一事不明,您說『所以只能自己在外面透過某些機制改動,而不能也不行等sun來改』所以您必須在程式中做特別的判斷,如果測到這個『bug』發生,在採取特別的手段來『修補』是嗎?

    回覆刪除
  10. 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等都有類似的問題,只是看客戶的重視程度。

    回覆刪除
  11. 完整的解法是把檢查都放server side,因為server沒有UI的問題,就算字不見了可以踢回。Java的強項畢竟是EE端,所以J2EE的市場遠大於J2SE。

    回覆刪除
  12. Hi M. Jwo:

    感謝您的分享,請問您的應用是 Web AP 還是 Swing AP,還是兩者都有?『一天大約一百萬次的頁面』感覺起來像是 Web AP,但是您又提到『所以我們公司對Java UI(Swing)的認識非常的深入』。Teddy 很好奇如果是 Swing AP 一天要有『一百萬次的頁面』不知是何種類型的應用ㄋㄟ...

    回覆刪除
  13. 作者已經移除這則留言。

    回覆刪除
  14. swing (move to browser now),短程式每次執行時間需要在一秒內完成,輸入時間大約一分鐘。客戶大小不同使用者大約600-6000人,依據角色每人每天平均200次執行,經過可能有問題欄位大約600個以上。
    都百萬誇張點,小點的客戶大約30萬次。

    回覆刪除