我曾經(jīng)和來(lái)自不同開(kāi)發(fā)機(jī)構(gòu)的人探討過(guò)關(guān)于他們?nèi)绾喂芾碥浖_(kāi)發(fā)，如何組織，他們遵循什么樣的開(kāi)發(fā)實(shí)踐，以及什么樣的開(kāi)發(fā)實(shí)踐真正有效。工作在小團(tuán)隊(duì)的大部分人都沒(méi)有人手幫他們測(cè)試程序，因?yàn)闇y(cè)試人員們不是真正開(kāi)發(fā)軟件的人，所以通常覺(jué)得他們是多余的。這就意味著程序員許要自己測(cè)試他們的軟件 – 或者用戶(hù)來(lái)測(cè)試。

敏捷團(tuán)隊(duì)中的測(cè)試人員能做什么？

很少敏捷團(tuán)隊(duì)會(huì)覺(jué)得需要測(cè)試人員。測(cè)試人員被看作是瀑布時(shí)代的產(chǎn)物（需求、設(shè)計(jì)、編碼、測(cè)試）。在XP團(tuán)隊(duì)，每個(gè)人都是程序員，每個(gè)程序員都要負(fù)責(zé)測(cè)試自己的代碼，寫(xiě)自動(dòng)的單元測(cè)試，使得用戶(hù)需要的驗(yàn)收測(cè)試自動(dòng)化。Scrum根本沒(méi)有定義測(cè)試要做什么 – 團(tuán)隊(duì)會(huì)最終找到解決方案，因?yàn)樗麄儠?huì)檢閱自己并調(diào)整自己，以獲得最佳的實(shí)踐。

如果程序員已經(jīng)測(cè)試了他們的代碼（也通過(guò)結(jié)隊(duì)的方式進(jìn)行了代碼審查），那么他們需要測(cè)試人員做什么呢？

Janet Gregory和 Lisa Crispin寫(xiě)了一本書(shū)來(lái)說(shuō)明敏捷團(tuán)隊(duì)中測(cè)試人員的作用，它向程序員和測(cè)試人員說(shuō)明測(cè)試人員是如何配合敏捷開(kāi)發(fā)的，但這仍然沒(méi)有改變大多數(shù)團(tuán)隊(duì)的看法，尤其在“工程驅(qū)動(dòng)的文化”（程序員創(chuàng)立的創(chuàng)業(yè)團(tuán)隊(duì)）中更是如此。

他們的論點(diǎn)是敏捷團(tuán)隊(duì)的步伐相對(duì)于測(cè)試人員來(lái)說(shuō)太快了，黑盒測(cè)試人員們僅僅通過(guò)寫(xiě)測(cè)試計(jì)劃，通過(guò)手動(dòng)的測(cè)試代碼來(lái)測(cè)試，或許要不斷的更新他們的質(zhì)量中心或Selenium UI回歸測(cè)試，這些都不可能追得上在短時(shí)間內(nèi)就要發(fā)布新功能的團(tuán)隊(duì)的進(jìn)度。如果測(cè)試人員不會(huì)用Fitness或Cucumber寫(xiě)驗(yàn)收測(cè)試，或者沒(méi)有足夠的業(yè)務(wù)知識(shí)幫助填補(bǔ)客戶(hù)/產(chǎn)品擁有者的空當(dāng)，不能回答程序員的問(wèn)題的話(huà)，那么他們又有什么優(yōu)勢(shì)呢？

這個(gè)問(wèn)題在持續(xù)開(kāi)發(fā)中更為顯著，一些公司如IMVU和Facebook，使得某種編程實(shí)踐變得流行起來(lái)，他們查看自己的工作，寫(xiě)自動(dòng)測(cè)試用例，查看代碼看看測(cè)試是否通過(guò)了，更新都是很快的，然后自動(dòng)發(fā)布到在線(xiàn)系統(tǒng)中去。

[[92578]]

讓用戶(hù)來(lái)測(cè)試你的代碼

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

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

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

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

你需要從測(cè)試團(tuán)隊(duì)中獲得什么？

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

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

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

當(dāng)我們初次建立系統(tǒng)的時(shí)候，我們有一個(gè)更大的測(cè)試團(tuán)隊(duì)，主要通過(guò)寫(xiě)測(cè)試計(jì)劃，詳盡的手工測(cè)試核查表，在UI層編寫(xiě)自動(dòng)的回歸測(cè)試，來(lái)測(cè)試覆蓋率和可靠性。但用這種方法浪費(fèi)了許多時(shí)間。

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

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

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

他們沒(méi)有讓整個(gè)團(tuán)隊(duì)的進(jìn)度慢下來(lái)，他們也沒(méi)有阻礙我們發(fā)布軟件。他們確保了軟件上線(xiàn)的時(shí)候正常工作。

測(cè)試人員找到更多的缺陷

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

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

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

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

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

英文原文： swreflections.blogspot.ca

本文鏈接：http://blog.jobbole.com/25723/