一些公司把持續(xù)開發(fā)看作是“眾包”(crowdsource)他們測試的機會 – 讓他們的客戶來為他們測試。這實際上很有競爭力。然而也很難用這種方法寫出可靠安全的軟件 – 可能也是不可能的。針對持續(xù)發(fā)布給用戶的系統(tǒng)的質(zhì)量問題，James Bach有一篇批評的文章，是關(guān)于他們花了20分鐘時間去測試一個持續(xù)部署的程序，就發(fā)現(xiàn)在很短的時間內(nèi)就發(fā)現(xiàn)了問題。

有一些持續(xù)部署的公司更小心些，他們按照Etsy/Flickr的做法，在晚上上線：持續(xù)的發(fā)布更新，但是在用戶量很大之前就進行了測試，他們還會密切關(guān)注結(jié)果。

然而，很重要的一點是用戶只能測試某些功能，事實上，也只有用戶可以測試它們：一個功能是不是有用，一個功能是不是可用的，他們需要什么信息才能正確的完成一個任務，工作流程應該如何優(yōu)化。這才是對比測試所應該達到的效果 – 通過實驗不同的想法，功能和工作流程，收集數(shù)據(jù)，然后找到用戶最喜歡什么，以及他們不喜歡什么。去嘗試不同的方法，并獲得反饋。

但是你不會問你的客戶他們是否測試完畢了，代碼是否有效，系統(tǒng)是否穩(wěn)定安全，負載大的情況下是否正常工作。

　　你需要從測試團隊中獲得什么?

就算是最好的，最負責的，最有經(jīng)驗的程序員都會犯錯。在我們公司，每個人經(jīng)驗都很豐富，其中有些人工作了10-15年以上了。他們很仔細的測試代碼，每次check-in之后都會更新自動測試用例。在持續(xù)集成過程中這些測試都會運行 – 我們非常依賴于這些測試(現(xiàn)在已經(jīng)有成千上萬的測試用例了，并有較高的覆蓋率)，靜態(tài)分析的缺陷核查，以及安全核查工具來對付基本的代碼錯誤。所有的更改都會讓另外一個高級的程序員來核查，從來沒有過例外。

但就算有好的方法和工具，優(yōu)秀的程序員還是會犯錯：一些細微的問題(不一致，界面問題，數(shù)據(jù)轉(zhuǎn)換和建立問題，沒有編輯等問題)以及一些基礎(chǔ)的問題 (負載下的運行失敗，同步問題，缺少需求，規(guī)則錯誤，異常處理中的錯誤)。我想確保在用戶發(fā)現(xiàn)錯誤之前發(fā)現(xiàn)大部分(盡管不是全部)的錯誤。程序員也是。

這也就是測試團隊起作用的地方了。我們擁有一個小的，但是經(jīng)驗豐富的，有特別專長的測試團隊。一個測試人員專注于驗收測試，驗證功能需求，可用性，以及業(yè)務工作流程。另一個測試人員專注于功能的回歸測試以及業(yè)務規(guī)則的正確性和覆蓋率，找到程序員測試用例中的規(guī)則漏洞，并在API層讓集成測試自動化。還有個測試人員主要做操作測試，壓力測試，以及soak test來找到峰值和垃圾回收的問題，破壞測試 – 盡可能的破壞系統(tǒng)。當其中一個人不在的時候，他們也知道如何擔負他人的職責，但他們有自己獨特的專長和技能，以及自己的解決問題的方法。

當我們初次建立系統(tǒng)的時候，我們有一個更大的測試團隊，主要通過寫測試計劃，詳盡的手工測試核查表，在UI層編寫自動的回歸測試，來測試覆蓋率和可靠性。但用這種方法浪費了許多時間。

現(xiàn)在我們更依賴于程序員針對功能覆蓋率和回歸保護自己編寫的自動測試用例。我們的測試團隊將精力更多的放在探索性的功能以及操作，基于風險和以用戶為中心的測試中去了，以找到最重要的缺陷，發(fā)掘系統(tǒng)的弱點。我們都喜歡這種方法，因為我們在測試中找到了真正的重要的缺陷，那些躲得過代碼審查和單元測試的缺陷。

當程序員作了更改后，測試人員馬上測試更改。他們和程序員一起結(jié)隊去測試新功能，和程序員一起運行模擬來找出運行錯誤，競態(tài)條件(race condition)以及現(xiàn)實世界中的時間相關(guān)的問題和工作流程問題。他們摧毀系統(tǒng)以確保錯誤探測和錯誤恢復機制是成功的。他們測試安全功能，和顧問一起搭建和管理測試。他們也和操作人員一起，和新用戶以及新部門處理集成檢查。他們和團隊的其他人員一起以非?？斓乃俣?，每兩周就發(fā)布到在線系統(tǒng)(有時更頻繁)。

測試團隊也會負責軟件的發(fā)布。他們將每個發(fā)布都集中在一起，查看依賴，決定發(fā)布什么時候進行，什么將會發(fā)布，什么不會發(fā)布，他們會核對我們是否完成了整個團隊同意去做的更改，他們會測試過去的測試用例還有數(shù)據(jù)轉(zhuǎn)換測試，最后和操作人員一起發(fā)布到在線系統(tǒng)中去。

他們沒有讓整個團隊的進度慢下來，他們也沒有阻礙我們發(fā)布軟件。他們確保了軟件上線的時候正常工作。

　　測試人員找到更多的缺陷

我為高可靠性，高集成性的業(yè)務工作了很久，沒有測試人員是不可取的 – 犯錯的代價太高了。我不認為你可以創(chuàng)建真正的軟件，而不需要人來測試它。除非你是在創(chuàng)業(yè)的早期，還處于概念的迸發(fā)期，或者你只有一個小團隊，僅僅為內(nèi)部使用而寫的軟件(可能你也沒堵到這篇文章)，否則你需要人來為你測試系統(tǒng)以確保系統(tǒng)是正常運行的。

不管你如何工作，不管你用什么方法 – 敏捷開發(fā)還是瀑布開發(fā)方法，都改變不了需要測試人員的事實。如果你推進得太快了，測試人員需要加快步伐，以適應能夠獲取信息的方式。好的測試人員可以做到的。

我就算再蠢也不會認為測試團隊能找到所有的缺陷——雖然這是他們的工作。當然，我希望測試人員會在客戶發(fā)現(xiàn)之前找到明顯的錯誤。

我需要為他們做的也正好幫自己回答了一些重要的問題：我是否可以發(fā)布了?有什么還是粗糙的或者不穩(wěn)定的或者不完善的?什么需要遲些發(fā)布?什么需要更進一步審查或者重寫?設(shè)計中什么地方很薄弱?什么地方?jīng)]有自動測試用例?哪里需要更好的測試工具?什么功能難以理解或不一致或者很難搭建?什么消息漏掉了，或者容易誤導人的?我們是否做太多了，做太快了?我們是否需要更改設(shè)計，代碼，還是設(shè)計或編碼的方式，以使得系統(tǒng)更好用，更可靠?

測試不能提供所有的信息，但能提供一部分。好的測試可以提供許多有用的信息?！狫ames Bach (Satisfice)

沒有測試人員，你不僅發(fā)布了一些你本來應該沒有錯誤的代碼，你也失去了一些重要的信息，譬如你的軟件真的那么好嗎，例如你可以做什么讓它更好。如果你想構(gòu)建好的軟件，那么現(xiàn)在你的機會來了。

原文：?swreflections.blogspot.ca

來源：伯樂在線