開發人員的測試悖論(The Developer Testing Paradox)

作者: TonyQ (沉默是金。) 看板: Soft_Job
標題: [轉錄] 開發人員的測試悖論(The Developer Testing Paradox)
時間: Mon May 16 18:04:56 2011


        英文原文：http://blogs.mulesoft.org/the-developer-testing-paradox/
        簡體翻譯：http://www.jobbole.com/entry.php/794


        今天看到費大(fillano)轉噗的訊息，覺得不錯，與大家分享下。

        （本文內文是由簡轉繁工具直接轉譯，有些是大陸用語，不另行註明。）


        --簡中翻譯分隔線-----------------------------------

多年來，我在軟件開發過程中看到了許多不同的測試方式。每一種測試都有它的獨特
性，一些開發人員認定他們自己有不只一種方式。在本文中，我試著列舉所有不同種類的
測試，並說一說它們在項目上反映出的效果。

1. “我不是QA”（I’m not QA）

我提交代碼，其他人驗證其是否能正常運作。我的工作就是寫代碼，而不是測試。因
為是我寫的代碼，所以，我不能測試出代碼什麼地方出錯了。我需要讓其他人看應用程序
，並且學會如何使用，如何崩潰。通常，這種方式也說明缺乏說明文檔，同樣原因，這應
該是其他人的工作。通常這種測試方式意味著，質量是其他人該負責任的事。


2. “我沒時間”（I don’t have time）

我必須在3周時間內完成項目，再沒有時間去寫測試了。我想測試可以保證應用程序
的質量，但是因為我必須三周內完成任務，所以我必須跳過開發中的這一部分， 直接做
工作上的事情。一旦事情完成，我會做些手工檢查，然後直接投產。這種方式通常和那些
只用1或2個月來開發，並且4年內不用維護的小項目相關，他們只需要短時間內得到一個
產品。這種案例沒有說明文檔，因為你沒有時間去做。（編注：關於這種類型，可參見伯
樂在線職場博客《每位開發人員都應銘記的10句編程諺語》一文中的“欲速則不達”。）


3. “管理故障”（Management fault）

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


4. “測試只是一個工具”（Testing is just a tool）

這種情形下，由開發人員編寫測試，但僅限於某些對他們編碼有幫助的地方。測試是
用來作為創造新功能的工具，而非在代碼中增加可信度的方式。如果任何新功能的添加破
壞了已存在的測試，開發員會假定測試錯誤，測試需要更改、取消或刪除。雖然是對應用
程序的測試，但是這些測試並不可信。如果這些測試不可信，應用程序也就毫無價值可言
了。


5. “熱衷測試覆蓋率”（Test coverage maniac）

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


6. “可信度測試”（Test to trust）

這是終極方式。軟件開發的測試有許多目的，但是最重要的是在代碼中建立可信度。
如果隊員對測試有信心，他們會很自如地改進或更改代碼。使其效率更高，質量更佳，周
轉更快。

測試中有可信度並不是和代碼覆蓋率有關，而是相信團隊成員，他們會為重要的事物
增加測試。如果你做了更改或者破壞（break）測試，你就需要認真考慮你的更改，而不
是僅僅移出錯誤測試。我們要做的是能提高代碼和測試可信度，而非僅僅解決一個新問題
。

這些年我了解到，測試是開發過程中至關重要的一部分。每次代碼修改後，都應該進
行測試。用於提高測試可信度的每一秒鐘，就是你每次運行測試都會成功的時候。在軟件
開發上，取得最大效率的唯一方式不是不寫測試，而是相信你的測試。

你是一位開發人員嗎？你為你的應用程序寫測試嗎？你每次提交都在提高測試中的可
信度嗎？每次提交都需要提高可信度，否則你就是增加了一個有問題的代碼，最後終將導
致你重寫整個程序。



--
TonyQ 註：邁向複雜系統的時代，總有一天我們都終將倚賴測試來鍛鍊程序員的信心。

--

[1;36;44m      網頁上拉近距離的幫手              實現 GMail豐富應用的功臣  

[1;36m        數也數不清的友善使用者體驗      這就是ｊａｖａｓｃｒｉｐｔ

[1;30m                                                歡迎同好到 AJAX 板一同討論。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.83.16.246
※ 編輯: TonyQ           來自: 111.83.16.246        (05/16 18:05)
→ xlk:about #5:  80% and no less! http://bit.ly/9yVux6            05/17 01:57