2011年5月21日 星期六

Programmer一般都是寫出認為是正確的code

作者: leicheong (睡魔) 看板: Soft_Job
標題: Re: [轉錄] 開發人員的測試悖論(The Developer Tes …
時間: Tue May 17 20:58:25 2011

由另一些角度來看看...

※ 引述《TonyQ (沉默是金。)》之銘言:
:         英文原文:http://blogs.mulesoft.org/the-developer-testing-paradox/
:         簡體翻譯:http://www.jobbole.com/entry.php/794
:         今天看到費大(fillano)轉噗的訊息,覺得不錯,與大家分享下。
:         (本文內文是由簡轉繁工具直接轉譯,有些是大陸用語,不另行註明。)
:         --簡中翻譯分隔線-----------------------------------
:   多年來,我在軟件開發過程中看到了許多不同的測試方式。每一種測試都有它的獨特
: 性,一些開發人員認定他們自己有不只一種方式。在本文中,我試著列舉所有不同種類的
: 測試,並說一說它們在項目上反映出的效果。
:   1. “我不是QA”(I’m not QA)
:   我提交代碼,其他人驗證其是否能正常運作。我的工作就是寫代碼,而不是測試。因
: 為是我寫的代碼,所以,我不能測試出代碼什麼地方出錯了。我需要讓其他人看應用程序
: ,並且學會如何使用,如何崩潰。通常,這種方式也說明缺乏說明文檔,同樣原因,這應
: 該是其他人的工作。通常這種測試方式意味著,質量是其他人該負責任的事。
我會認為Programmer一般都是寫出認為是正確的code, 想沒有任何因由
的事況下debug會因為看不到自己的盲點而看不到成效. 這和要求撰稿人
自行proofread的效果不會有很大分別.

因此如果自己寫test case然後以此為據寫code, 即使all pass也無法
代表沒有bug.

:   2. “我沒時間”(I don’t have time)
:   我必須在3周時間內完成項目,再沒有時間去寫測試了。我想測試可以保證應用程序
: 的質量,但是因為我必須三周內完成任務,所以我必須跳過開發中的這一部分, 直接做
: 工作上的事情。一旦事情完成,我會做些手工檢查,然後直接投產。這種方式通常和那些
: 只用1或2個月來開發,並且4年內不用維護的小項目相關,他們只需要短時間內得到一個
: 產品。這種案例沒有說明文檔,因為你沒有時間去做。(編注:關於這種類型,可參見伯
: 樂在線職場博客《每位開發人員都應銘記的10句編程諺語》一文中的“欲速則不達”。)
問題在於職場上90%的support case都是在處理別人寫的東西的bug.
你寫的東西的bug除了剛上線的時間外, 70%都是會交給別的人維護,
而不是原作者.

你細心的處理自己的bug, 延遲上線的時間責任卻在自己.

這樣「損己利人」的事, 會做的人真是佛心來的. :P

:   3. “管理故障”(Management fault)
:   許多大公司的雇員都遵循這種開發方式。他們有過失敗或項目推遲的經歷,因此,他
: 們排斥一切不能給高層管理帶來直接利益的事。通常情況下,在持續快速地開發一個功能
: 性強大的項目時, 在開始階段無需測試。隨著時間的推移,應用程序的增多,添加了越
: 來越多復雜的程序,並且開發進程越來越困難。每一個新的部署就意味著大量的新錯誤和
: 新任務。短短幾年,應用程序失去可信度,通常有人想在新技術下重新寫程序。不幸的是
: ,如果開發過程沒有改變,幾年後他們會在不同的技術中以同樣的方式結束。
因此一個可能寫了數年的時間才上線的程式, 可能用了數年又要請人重寫了.

這是一個可持續的business model......

:   4. “測試只是一個工具”(Testing is just a tool)
:   這種情形下,由開發人員編寫測試,但僅限於某些對他們編碼有幫助的地方。測試是
: 用來作為創造新功能的工具,而非在代碼中增加可信度的方式。如果任何新功能的添加破
: 壞了已存在的測試,開發員會假定測試錯誤,測試需要更改、取消或刪除。雖然是對應用
: 程序的測試,但是這些測試並不可信。如果這些測試不可信,應用程序也就毫無價值可言
: 了。
程式的核心部份理應已經經歷多次直接或間接的測試, 有bug的可能性
的確比其他部份以致剛寫成的test case少很多. 因此質疑test case
是很合理的舉動.

btw, 實際上我們的潛意識在排斥已經在廣泛應用的程序有bug的可能性.
因為如果這些部份真的有bug, 這意味著無盡的debug, debug後的交叉測試,
patch, 以及incident report. 可能以後數個月你就別想作其他的事了.

:   5. “熱衷測試覆蓋率”(Test coverage maniac)
:   所有的一切都是關於代碼的覆蓋率。使代碼的覆蓋率達到100%是最終目標。查看測試
: 的覆蓋率以及查看測試未能通過的地方,為那些路徑添加測試成了一項重復的工作。我的
: 意思是,增加毫無意義的測試只是增加覆蓋率。測試將變得復雜,新開發人員通常要花很
: 長時間才能明白這個代碼是做什麼的。在這種情況下,我們就比其他人處於更有利的位置
: ,測試不僅是和覆蓋率有關,還有可信度。
只有test driven programming approach下, 高測試覆蓋率才有意義.
(不是這樣的話就不是test driven了)

正確的佈置測試方法, 應該像corner stone一樣集中在需求的logic
上預計較大機會出錯的地方, 以及對外互動的各個接口 (包括UI和
programming interface)

:   6. “可信度測試”(Test to trust)
:   這是終極方式。軟件開發的測試有許多目的,但是最重要的是在代碼中建立可信度。
: 如果隊員對測試有信心,他們會很自如地改進或更改代碼。使其效率更高,質量更佳,周
: 轉更快。
:   測試中有可信度並不是和代碼覆蓋率有關,而是相信團隊成員,他們會為重要的事物
: 增加測試。如果你做了更改或者破壞(break)測試,你就需要認真考慮你的更改,而不
: 是僅僅移出錯誤測試。我們要做的是能提高代碼和測試可信度,而非僅僅解決一個新問題
: 。
:   這些年我了解到,測試是開發過程中至關重要的一部分。每次代碼修改後,都應該進
: 行測試。用於提高測試可信度的每一秒鐘,就是你每次運行測試都會成功的時候。在軟件
: 開發上,取得最大效率的唯一方式不是不寫測試,而是相信你的測試。
:   你是一位開發人員嗎?你為你的應用程序寫測試嗎?你每次提交都在提高測試中的可
: 信度嗎?每次提交都需要提高可信度,否則你就是增加了一個有問題的代碼,最後終將導
: 致你重寫整個程序。

--

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.238.58.149

沒有留言:

張貼留言

您好.本資料庫並非第一手資料.如果你有對文章作者的詢問,意見與需求,請自行找尋文章作者並提供意見,謝謝.