qileilove

請(qǐng)談下您對(duì)探索式測(cè)試的理解，請(qǐng)分享下這方面的實(shí)踐經(jīng)驗(yàn)？

　　徐毅：其實(shí)探索式測(cè)試是什么，Cem Kaner和James Bach的一些文章、PPT都已經(jīng)寫得非常清楚。

　　首先探索式測(cè)試是一種測(cè)試的“方式”（Way，或Approach），而不是測(cè)試“技術(shù)”（Technique），方式也即是指完成整體測(cè)試工作所選擇的辦法，而技術(shù)則是指對(duì)于局部測(cè)試工作進(jìn)行操作的方法。

　　其次，ET的目的在于“探索”，也即有一個(gè)明確的測(cè)試目標(biāo)，但是目標(biāo)的細(xì)節(jié)或是達(dá)成目標(biāo)的步驟尚不清晰，所以需要邊走邊看，同時(shí)間地進(jìn)行學(xué)習(xí)、設(shè)計(jì)、執(zhí)行、解析的結(jié)果，與PDCA循環(huán)頗有相似之處。

　　第三要區(qū)分開ET和手工測(cè)試的關(guān)系。“手工測(cè)試”所強(qiáng)調(diào)的是執(zhí)行的手段，也即“手工”。而ET主要強(qiáng)調(diào)目的，也即“探索”，當(dāng)然還有就是，執(zhí)行只不過是ET中的一部分而已，而這一部分，可以借助自動(dòng)化。例如，修改某個(gè)已有自動(dòng)化測(cè)試腳本中的部分測(cè)試數(shù)據(jù)，借助于腳本快速地執(zhí)行某些操作，而去掉或暫停分析部分的腳本執(zhí)行，因?yàn)榇藭r(shí)測(cè)試的結(jié)果未知，需要依賴人工來判斷、分析測(cè)試結(jié)果。

　　公直：探索式測(cè)試最近2年異常火爆，很多人以為是最新出的一個(gè)測(cè)試技術(shù)或者方法。Cem Kaner 在1983年（都快30年了）就提出了。這是一種強(qiáng)調(diào)個(gè)人自由與責(zé)任的測(cè)試方法，讓獨(dú)立測(cè)試人員可以借由不斷的學(xué)習(xí)來改善測(cè)試的規(guī)劃與測(cè)試的執(zhí)行，而在測(cè)試的過程中也會(huì)同時(shí)改善測(cè)試用例從而達(dá)到相輔相成的效果。在一淘這邊，其實(shí)很早就開始使用這種實(shí)踐方法了，但很多一線的測(cè)試人員并不知道自己的做法就是探索式測(cè)試，在互聯(lián)網(wǎng)研發(fā)模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一個(gè)月就要上線。在這樣的環(huán)境下，文檔少，在測(cè)試計(jì)劃制定設(shè)計(jì)上都不可能完善，一般在測(cè)試過程中是用freemind等腦圖工具來記錄測(cè)試執(zhí)行過程的同時(shí)做測(cè)試用例的設(shè)計(jì)，這種方式可以做常規(guī)測(cè)試的補(bǔ)充。

　　楊進(jìn)：我很喜歡探索性測(cè)試，它讓測(cè)試工作變得輕松和富有創(chuàng)造力，它能讓你無需復(fù)雜的測(cè)試準(zhǔn)備，就直接進(jìn)入最核心的測(cè)試工作，并且不拘泥用什么方法、什么工具，也不用考慮能否能被自動(dòng)化，只需要關(guān)注能否快速的找到bug就行。當(dāng)然好的探索性測(cè)試實(shí)際上對(duì)工程師的邏輯分析能力和產(chǎn)品整體理解要求很高，這種依賴于個(gè)人能力的測(cè)試手段，執(zhí)行的效果也比較難以控制。

　　探索性測(cè)試的實(shí)踐方面，我們之前嘗試過多人組隊(duì)測(cè)試，這種方式適用于多人進(jìn)行的大型項(xiàng)目，大家一起進(jìn)行探索性測(cè)試，bug系統(tǒng)即時(shí)顯示你在這個(gè)版本發(fā)現(xiàn)了多少個(gè)bug，并且排名，我們每天樂于尋找更多的bug，并且分享找bug的技巧，在這個(gè)過程中我們都得到了很多的成就感，并且對(duì)產(chǎn)品的理解和測(cè)試技巧也大幅提升。現(xiàn)在回想起來也還是一個(gè)很有意思的事情。

　　您怎么看敏捷測(cè)試，執(zhí)行后會(huì)質(zhì)量有哪些明顯的改善？

　　徐毅：我認(rèn)為，敏捷測(cè)試（關(guān)于敏捷測(cè)試的定義、介紹，請(qǐng)參考Lisa Crispin書中的描述）并無法單獨(dú)的執(zhí)行，必須在敏捷的環(huán)境下，結(jié)合開發(fā)人員方面的敏捷實(shí)踐（以及組織結(jié)構(gòu)）齊頭并進(jìn)方可實(shí)現(xiàn)。而此時(shí)，質(zhì)量的提升乃是源于軟件開發(fā)工作整體的改善，很難說一定是測(cè)試的功勞。另一方面則在于，測(cè)試本來就無法“控制”質(zhì)量，自然也無法改善質(zhì)量，因?yàn)闇y(cè)試工作本身并不改變那些可以影響質(zhì)量產(chǎn)生的因素。但敏捷測(cè)試的實(shí)踐對(duì)于質(zhì)量的提升是肯定有影響的。

　　● 敏捷中對(duì)于團(tuán)隊(duì)內(nèi)外參與、交流的追求，能夠更容易“do things right”

　　● 快速地交付和反饋，有助于做到更多地“do right things”

　　● 完整團(tuán)隊(duì)、跨職能團(tuán)隊(duì)等實(shí)踐，團(tuán)隊(duì)負(fù)責(zé)自己的工作方式改進(jìn)，更容易做到“do things rightly”

　　公直：敏捷測(cè)試是一個(gè)被過度炒作的概念，和架構(gòu)師、云計(jì)算一起被大家私下稱呼“大忽悠”的工具，特別是最近幾年。傳統(tǒng)上將敏捷測(cè)試就是在敏捷研發(fā)流程下的測(cè)試，例如使用XP、或者scrum的研發(fā)流程下的測(cè)試活動(dòng)，怎樣在這樣的研發(fā)背景下做測(cè)試，挑戰(zhàn)在于如何使用敏捷的流程。另外一種敏捷測(cè)試，就是按照敏捷宣言中的幾個(gè)關(guān)鍵詞，“速度快”、“反饋”、“持續(xù)”，做的測(cè)試。由于敏捷強(qiáng)調(diào)的重點(diǎn)，還是在“快”上，無論中文含義的字面解釋，“敏”、“捷”其實(shí)都是快的意思，這正是自動(dòng)化程序的特長(zhǎng)，機(jī)器的運(yùn)行速度總是比人的操作要快，所以我們一般在敏捷項(xiàng)目中使用了非常多的自動(dòng)化技術(shù)。個(gè)人感覺十分使用敏捷測(cè)試與質(zhì)量提升方面沒有直接關(guān)系。

　　楊進(jìn)：我理解敏捷測(cè)試就是讓項(xiàng)目相關(guān)的角色全體直接承擔(dān)項(xiàng)目最終目標(biāo)，由于都是為最終目標(biāo)服務(wù)，因而角色也變得模糊，并且每個(gè)人的工作也需要考慮是否對(duì)當(dāng)前最急迫的事情，這種集中所有角色力量為共同目標(biāo)前進(jìn)的開發(fā)方式，減少了大家溝通和項(xiàng)目迭代成本，最終很容易得到項(xiàng)目整體效率和質(zhì)量的提升。由于各角色對(duì)目標(biāo)理解一致，對(duì)產(chǎn)品理解都很深入，因而可以更多的把bug消滅在開發(fā)的早期，比如單元測(cè)試、新功能測(cè)試階段，使得后期的集成和系統(tǒng)測(cè)試問題變得更少，尤其是產(chǎn)品最終的效果問題也會(huì)減少。

　　開源對(duì)測(cè)試的影響，如何看待測(cè)試的開放性？

　　徐毅：平臺(tái)、工具、框架在我看來屬于比較相同的情況，我就拿我自己的經(jīng)歷來做例子吧。在諾西的時(shí)候，我們有使用過一個(gè)叫robotframework的測(cè)試自動(dòng)化框架，它最開始是一個(gè)和諾西合作的芬蘭專家開發(fā)出來的，在諾西（當(dāng)時(shí)還叫諾基亞網(wǎng)絡(luò)）最先開始使用， 而后逐步推廣，在此過程中這個(gè)框架也在不斷地更新、改進(jìn)、完善。后來在公司之外也有很多的使用者，于是開發(fā)者和諾西把這個(gè)框架開源出來，也吸引了更多的人加入到這個(gè)框架的開發(fā)中來，包括衍生工具的開發(fā)，這都推動(dòng)了這個(gè)工具的廣泛使用和不斷完善。諾西作為最主要的支持者，并沒有因?yàn)殚_源而受損，反而因?yàn)檫@個(gè)開源框架龐大的用戶群體和開發(fā)者隊(duì)伍而受益頗多，有更多的人可以分享經(jīng)驗(yàn)、討論問題，也有更強(qiáng)大的開發(fā)力量提供所需的功能。不過，開源的軟件，或者開源的社區(qū)相對(duì)來說更傾向于Linux的設(shè)計(jì)理念，也即是更專注于某一個(gè)領(lǐng)域、某一塊功能，做精，而不像是Windows那樣的設(shè)計(jì)理念，強(qiáng)調(diào)易用性、一站式體驗(yàn)。這意味著，企業(yè)內(nèi)要完成所有的測(cè)試工具，可能需要和多個(gè)開源工具、框架打交道，整體上如何協(xié)調(diào)使用并不容易，需要培養(yǎng)相關(guān)方面的人才。

　　測(cè)試開放性，沒有特別想法，也沒啥體驗(yàn)，只能憑感覺談?wù)劇€(gè)人觀點(diǎn)比較悲觀或者比較現(xiàn)實(shí)。測(cè)試就是測(cè)自己產(chǎn)品的功能、特性，讓別人知道自己的測(cè)試，也就是知道了自己產(chǎn)品的細(xì)節(jié)和特性。出于商業(yè)上的考慮，我認(rèn)為各企業(yè)恐怕會(huì)較難把最核心部分的東西拿出來公開。不過這個(gè)很可能會(huì)是一個(gè)趨勢(shì)，即使拿出來的測(cè)試用例的范圍比較小而已。對(duì)于產(chǎn)品也有要求，得要是相對(duì)標(biāo)準(zhǔn)化程度比較高的產(chǎn)品，不然拿出來的測(cè)試最多別人參考一下，而無法直接使用，也無法反饋改進(jìn)，意味著拿出來的那一方也無法受益，這樣的話這些測(cè)試也就等同于是“死亡的文檔”（dead documentation），沒有實(shí)效。

　　公直：開源意味著更多可以利用的資源，特別是在測(cè)試工具上，開源也是一種開放的心態(tài)。測(cè)試的開放性，在于比較坦誠(chéng)地把自己在怎樣的場(chǎng)景下如何去做測(cè)試給大家做個(gè)介紹。非常典型的就是Google，在James的帶領(lǐng)下，有一系列的博客、文章、工具在介紹他們的測(cè)試，介紹他們測(cè)試中遇到的問題已經(jīng)他們是怎么解決的。非常期望各個(gè)公司，無論大小，測(cè)試做的程度，都可以把自己的測(cè)試通過微博、博客、文章、公開演講等形式公布出來，畢竟這一部分不太涉及太多的商業(yè)機(jī)密或者核心技術(shù)。

　　楊進(jìn)：測(cè)試的開放性，或者說基于某種特性測(cè)試的開放性是未來發(fā)展的趨勢(shì)，原因是互聯(lián)網(wǎng)的創(chuàng)業(yè)越來越依托一些基礎(chǔ)的平臺(tái)，比如iOS、Android，而就一個(gè)公司內(nèi)部而言，云的廣泛應(yīng)用也使得不同產(chǎn)品基于一個(gè)相同的基礎(chǔ)，由于有了共同的基礎(chǔ)，這些都表征出測(cè)試也會(huì)慢慢走向開放，從部門走向公司，從公司內(nèi)走向開源。一個(gè)好的開放性測(cè)試框架，是依托于具體測(cè)試資源，以滿足具體某種測(cè)試需求而誕生的。這種測(cè)試框架因?yàn)楹陀脩舻哪承┬枨蠼壎ㄒ蚨婺芰軓?qiáng)，并且也能很好的一站式完成用戶的需求。

　　我們把測(cè)試當(dāng)成了質(zhì)量保證的主要手段，當(dāng)質(zhì)量低下時(shí)，或者為了達(dá)到高質(zhì)量時(shí)，一般的選擇都是加大測(cè)試的工作量。您怎么看？

　　徐毅：臨時(shí)抱佛腳，沒用。就算真要加大，同時(shí)也得加大開發(fā)的工作量，找出來的bug沒人修復(fù)的話，質(zhì)量是不會(huì)提高的，只不過是我們更加清楚自己的產(chǎn)品質(zhì)量很爛而已。

　　公直：測(cè)試工程師做的測(cè)試活動(dòng)一般都被稱之為是“檢測(cè)”，與之對(duì)應(yīng)的開發(fā)工程師做的測(cè)試都是在“預(yù)防”，質(zhì)量高低可以通過測(cè)試“檢測(cè)”出來，但測(cè)試永遠(yuǎn)無法提升產(chǎn)品質(zhì)量。所以，為了達(dá)到高質(zhì)量，可以做更多的測(cè)試，加大測(cè)試工作量來發(fā)現(xiàn)產(chǎn)品的缺陷并修復(fù)，但對(duì)于質(zhì)量，這都是“事后”，是一種下策，不是不可以。更好的辦法，是測(cè)試前移，讓開發(fā)來做單元測(cè)試、簡(jiǎn)單的功能測(cè)試，在這個(gè)過程中會(huì)發(fā)現(xiàn)大量的問題并自行修復(fù)，測(cè)試更過地關(guān)注在用戶使用上，這樣高質(zhì)量會(huì)更容易達(dá)到一些。

　　楊進(jìn)：質(zhì)量的主體其實(shí)是Dev，試想QA完成某個(gè)被測(cè)對(duì)象的測(cè)試，它最核心的價(jià)值是什么？發(fā)現(xiàn)bug 或是證明產(chǎn)品能滿足具體應(yīng)用的需求？我選擇后者，因而如何讓Dev開發(fā)出質(zhì)量更高的代碼是每個(gè)產(chǎn)品質(zhì)量可控的測(cè)試團(tuán)隊(duì)首先考慮的事情。當(dāng)然如果當(dāng)前質(zhì)量低下的時(shí)候，一個(gè)比較快速見效的方法就是投入更多的測(cè)試，但是這不能是唯一手段，必須有人走到開發(fā)的階段，從上游逐步開始改善代碼的質(zhì)量和可測(cè)試性，否則這就是一個(gè)死循環(huán)。更多的低效投入，更多的測(cè)試和debug成本，這足以壓壞這個(gè)項(xiàng)目的所有角色，而不僅僅是QA。

　　工作中推薦的測(cè)試框架？使用的范疇？

　　徐毅：我推薦使用robotframework，它是一種基于關(guān)鍵字驅(qū)動(dòng)理念的的測(cè)試自動(dòng)化框架（也支持?jǐn)?shù)據(jù)驅(qū)動(dòng)），用于敏捷測(cè)試象限（參看Lisa的書或者Brian Marick的博客）中的Acceptance Testing。更多的信息可以參看它的主頁(yè)，www.robotframework.org。最初是由諾基亞西門子網(wǎng)絡(luò)資助開發(fā)的，如今已經(jīng)開源，大家都可以使用，國(guó)內(nèi)也有許多的實(shí)踐者可以交流經(jīng)驗(yàn)。它支持多種的測(cè)試文件格式，包括HTML、CSV和文本文件，測(cè)試用例的格式主要是一個(gè)表格形式，和FIT、FitNesse比較像。然后通過內(nèi)部的機(jī)制驅(qū)動(dòng)底層的Library進(jìn)行測(cè)試，而Library可以用Python和Java編寫，目前已經(jīng)有很多現(xiàn)成的，例如Selenium、Telnet、SSH、AutoIt等。

　　我使用這個(gè)工具已經(jīng)很多年，覺得它非常的好用，非常貼合敏捷開發(fā)的方式，能夠支持我們的ATDD，如今它甚至已經(jīng)內(nèi)嵌可以支持BDD格式的關(guān)鍵字腳本。

　　公直：Selenium，主要做Web UI級(jí)別的功能測(cè)試； JUnit/GTest, 代碼級(jí)別的單元測(cè)試或者API調(diào)用級(jí)別的自動(dòng)化測(cè)試；staf/stax，遠(yuǎn)程調(diào)用，在測(cè)試環(huán)境部署自動(dòng)化中可以用到；JMeter/ab/http_load, 性能相關(guān)的測(cè)試；另外，給大家推薦一款自動(dòng)化調(diào)度的工具TOAST，http://toast.taobao.org/ ，是我們這邊的一個(gè)開源的測(cè)試調(diào)度工具，主要解決持續(xù)集成中的測(cè)試執(zhí)行。

　　楊進(jìn)：百度內(nèi)部有一個(gè)測(cè)試工具平臺(tái)，里面有百度內(nèi)部開發(fā)的很多很棒的工具和框架，后續(xù)這些工具會(huì)慢慢開源出來。大家熟知的工具中，比如：代碼覆蓋率的gcov、BullseyeCoverage（支持邏輯判斷的覆蓋率統(tǒng)計(jì)），代碼掃描工具pclint，內(nèi)存泄露檢查工具Valgrind，單元測(cè)試工具GTest，如果測(cè)試移動(dòng)產(chǎn)品，MTC會(huì)是一個(gè)好選擇

　　在工作中會(huì)遇到各種各樣的bug或缺陷，能否分享1-2個(gè)？

　　楊進(jìn)：在測(cè)試分布式系統(tǒng)中，曾經(jīng)遇到過在同一個(gè)目錄下出現(xiàn)兩個(gè)同名文件的情況，導(dǎo)致系統(tǒng)直接crash掉了，這個(gè)bug讓我覺得一切皆有可能。監(jiān)控發(fā)現(xiàn)過工程師在進(jìn)行換庫(kù)導(dǎo)致流量下降的問題，這個(gè)case讓我明白bug不僅來自程序和數(shù)據(jù)，也來自每個(gè)可能對(duì)線上造成影響的環(huán)節(jié)。