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

　　1. “我不是QA”(I’m not QA)

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

　　2. “我沒時間”(I don’t have time)

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

　　3. “管理故障”(Management fault)

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

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

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

　　5. “熱衷測試覆蓋率”(Test coverage maniac)

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

　　6. “可信度測試”(Test to trust)

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

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

　　這些年我了解到，測試是開發(fā)過程中至關(guān)重要的一部分。每次代碼修改后，都應(yīng)該進(jìn)行測試。用于提高測試可信度的每一秒鐘，是你每次運行測試都會成功的時候。在軟件開發(fā)上，取得大效率的方式不是不寫測試，而是相信你的測試。

　　你是一位開發(fā)人員嗎?你為你的應(yīng)用程序?qū)憸y試嗎?你每次提交都在提高測試中的可信度嗎?每次提交都需要提高可信度，否則你是增加了一個有問題的代碼，后終將導(dǎo)致你重寫整個程序。