編者按：測試、QA一直是大家關注的話題，只要有軟件開發，就離不開QA和軟件測試。本次特別邀請到一淘網測試架構師 @公直_黃利 ，諾基亞敏捷及精益教練 @徐毅-Kaveri 和百度高級測試工程師楊進，請他們談下各自對QA和測試的理解，內容涉及如何衡量軟件測試的有效性，探索式測試，敏捷測試，開源對測試的影響，測試的開放性以及測試框架推薦等。
請先做下自我介紹。
徐毅：我叫徐毅，現在在諾基亞北京擔任敏捷及精益教練的工作。我是從05年在杭州諾基亞網絡的時候開始轉做專職測試的，同期也加入公司剛成立的測試自動化小組，這對我的理念有很大的影響，基本上我認為所有的測試都應該自動化。06年初加入當時的第一個Scrum試點項目，體會了一把敏捷測試，當時還根據我們的經驗總結出了一套輕量化的測試流程。后來我們在公司內推廣使用robotframework這個工具，作為培訓師指導大家學會使用這個工具來進行測試自動化。后來還擔任了一段時間的測試自動化教練的工作。
公直：阿里巴巴一淘網測試架構師。
楊進：百度高級測試工程師，06年加入百度，之前有過4年的測試開發工作，加入百度以來，主要從事自動化開發、測試方法改進以及系統測試相關的工作。
最近主要在從事哪方面的工作？
徐毅：最近主要是在敏捷及精益教練這個方面做得比較多，輔助組織和個人進行敏捷轉型，由于有很強的測試背景，所以同時也做敏捷測試相關的工作。
公直：最近半年一直在做代碼質量的相關工作。在一淘業務線測試團隊支持之下，與測試、產品架構師、PE等合作，從系統層面出發，優化目前的測試策略和方法，提升系統的可測試性和可部署性。
楊進：近1年主要focus在系統測試和效果監控等系統層面的工作，目前是線下百度和大搜索效果監控的負責人，線下百度是一個基礎的系統測試平臺，對外提供預上線、故障預演、數據測試等系統層面的服務，而效果監控目標是快速發現產品嚴重影響用戶體驗的效果問題，它和線下百度相互相成，共同提升百度對外服務的質量。
國內外一直有很多人把測試與質量保證混為一談，其實測試屬于質量控制（QC），而QA還有更多內容，請談談您對QA和測試的理解。
徐毅：其實不管是保證還是控制，都很難達到名副其實的效果。測試做得再充分、再徹底、再快速，也無法把質量給控制起來，最多只能夠更頻繁地展現出質量的現狀。關于QA么，我曾經在微博上發起過一個討論，還是比較熱鬧的，大家可以去看看，What is the value of Quality Manager。至于“質量保證”這個詞，大家可以想一想，如果我跟你拍胸脯說某件事情包在我身上，我保證辦到，但實際情況是，回過頭去我得催著一撥人做這個做那個才能保證你的事情辦妥，你覺得這是你理解中的“保證”嗎？ 更重要的問題在于，“質量是什么”。如今，我們可以說質量的外延發生了變化，已經涵蓋了許多方面；也可以說，質量已經不再重要，用戶體驗才是最重要的。溫伯格在他的《質量 軟件 管理》書中說到“quality is value to some person”，對于不同的人來說，同一件東西的價值可以是不同的。
公直：其實一直以來個人不太喜歡把測試工程師稱呼為QA，QA一般是指質量保證，范疇更大一些，在一淘，像過程改進工程師、配置管理工程師都在做質量控制的事情。單純地靠測試工程師本身也是沒有辦法控制質量的，因為對決定軟件質量的還是開發工程師。這個在博客中的《Google如何測試》系列文章中提及，對于質量來說，預防問題比發現問題本身更重要。質量更多是開發人員的問題，而不是測試人員的。通過把測試工作融入到開發過程中，我們能降低那些富產Bug的人的出錯機會，不僅可以避免了大量最終用戶的使用問題，而且還可以極大地降低測試人員報無效Bug的數量。測試的未來在于發現設計和編程人員解決問題方法上的局限、思路中的狹隘和技能方面的不足，這是我對測試的理解，也認為是以后測試發展的一個方向。
楊進：我理解測試關注的更多是被測對象上線前的質量，而QA關注的是宏觀意義上的質量，包括開發環節的質量控制（如何提高代碼本身質量）、測試環節、上線環節以及運維環節（如線上出現問題后如何快速止損），甚至還包括用那種開發模式能更有效的提升項目開發質量和效率，因而是一個更寬泛的領域。
如何衡量軟件測試的有效性？
徐毅：衡量一個東西的有效性，對我來說就看比較有無之間的區別，也就是說比較“有軟件測試”和“無軟件測試”在“效果”上面的差異，那就是有效性啦，也即是有效的程度。那么，你所期望的“效果”又是什么呢？
公直：從90年代末開始，測試進入所謂的“Prevention oriented period ”（參見wiki）階段，強調2點，第一個缺陷預防，第二就是軟件度量。就是這個問題本身（如何衡量軟件測試的有效性），如何度量你做的測試有什么收益，如何判斷你的測試活動的有效性，無論是學術界還是工業界，好像也還沒有什么比較好的方法，特別是在國內目前的現狀（人治，部門經理或者項目經理決定太多東西），度量系統（例如sonar）計算出的測試ROI本身可能也不一定準確，人的因素變化太多。我就簡單說下我們這邊判斷測試有效性做法好了，基本上還是還是從結果來看，上線失敗次數、線上故障、線上Bug幾個維度來評估測試的有效性。
楊進：要想全面評判測試的有效性是比較困難的，目前比較通用的手段是在產品發布以后，利用用戶報告bug的數量和趨勢來判斷測試的有效性，然后這種判斷方法需要上線后才能進行因而顯得價值有限，上線前也有一些可參考的手段，比如UT完成后的代碼覆蓋率，測試用例完后的評審，測試報告的評審等。我自己比較喜歡手段是代碼覆蓋率，因為代碼覆蓋率是一個利用客觀標準進行判定的方法。此外基于測試需求覆蓋率也是一個好方法。
請談下您對探索式測試的理解，請分享下這方面的實踐經驗？
徐毅：其實探索式測試是什么，Cem Kaner和James Bach的一些文章、PPT都已經寫得非常清楚。
首先探索式測試是一種測試的“方式”（Way，或Approach），而不是測試“技術”（Technique），方式也即是指完成整體測試工作所選擇的辦法，而技術則是指對于局部測試工作進行操作的方法。
其次，ET的目的在于“探索”，也即有一個明確的測試目標，但是目標的細節或是達成目標的步驟尚不清晰，所以需要邊走邊看，同時間地進行學習、設計、執行、解析的結果，與PDCA循環頗有相似之處。
第三要區分開ET和手工測試的關系。“手工測試”所強調的是執行的手段，也即“手工”。而ET主要強調目的，也即“探索”，當然還有就是，執行只不過是ET中的一部分而已，而這一部分，可以借助自動化。例如，修改某個已有自動化測試腳本中的部分測試數據，借助于腳本快速地執行某些操作，而去掉或暫停分析部分的腳本執行，因為此時測試的結果未知，需要依賴人工來判斷、分析測試結果。
公直：探索式測試最近2年異常火爆，很多人以為是最新出的一個測試技術或者方法。Cem Kaner 在1983年（都快30年了）就提出了。這是一種強調個人自由與責任的測試方法，讓獨立測試人員可以借由不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時改善測試用例從而達到相輔相成的效果。在一淘這邊，其實很早就開始使用這種實踐方法了，但很多一線的測試人員并不知道自己的做法就是探索式測試，在互聯網研發模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一個月就要上線。在這樣的環境下，文檔少，在測試計劃制定設計上都不可能完善，一般在測試過程中是用freemind等腦圖工具來記錄測試執行過程的同時做測試用例的設計，這種方式可以做常規測試的補充。
楊進：我很喜歡探索性測試，它讓測試工作變得輕松和富有創造力，它能讓你無需復雜的測試準備，就直接進入最核心的測試工作，并且不拘泥用什么方法、什么工具，也不用考慮能否能被自動化，只需要關注能否快速的找到bug就行。當然好的探索性測試實際上對工程師的邏輯分析能力和產品整體理解要求很高，這種依賴于個人能力的測試手段，執行的效果也比較難以控制。
探索性測試的實踐方面，我們之前嘗試過多人組隊測試，這種方式適用于多人進行的大型項目，大家一起進行探索性測試，bug系統即時顯示你在這個版本發現了多少個bug，并且排名，我們每天樂于尋找更多的bug，并且分享找bug的技巧，在這個過程中我們都得到了很多的成就感，并且對產品的理解和測試技巧也大幅提升。現在回想起來也還是一個很有意思的事情。
您怎么看敏捷測試，執行后會質量有哪些明顯的改善？
徐毅：我認為，敏捷測試（關于敏捷測試的定義、介紹，請參考Lisa Crispin書中的描述）并無法單獨的執行，必須在敏捷的環境下，結合開發人員方面的敏捷實踐（以及組織結構）齊頭并進方可實現。而此時，質量的提升乃是源于軟件開發工作整體的改善，很難說一定是測試的功勞。另一方面則在于，測試本來就無法“控制”質量，自然也無法改善質量，因為測試工作本身并不改變那些可以影響質量產生的因素。但敏捷測試的實踐對于質量的提升是肯定有影響的。
● 敏捷中對于團隊內外參與、交流的追求，能夠更容易“do things right”
● 快速地交付和反饋，有助于做到更多地“do right things”
● 完整團隊、跨職能團隊等實踐，團隊負責自己的工作方式改進，更容易做到“do things rightly”
公直：敏捷測試是一個被過度炒作的概念，和架構師、云計算一起被大家私下稱呼“大忽悠”的工具，特別是最近幾年。傳統上將敏捷測試就是在敏捷研發流程下的測試，例如使用XP、或者scrum的研發流程下的測試活動，怎樣在這樣的研發背景下做測試，挑戰在于如何使用敏捷的流程。另外一種敏捷測試，就是按照敏捷宣言中的幾個關鍵詞，“速度快”、“反饋”、“持續”，做的測試。由于敏捷強調的重點，還是在“快”上，無論中文含義的字面解釋，“敏”、“捷”其實都是快的意思，這正是自動化程序的特長，機器的運行速度總是比人的操作要快，所以我們一般在敏捷項目中使用了非常多的自動化技術。個人感覺十分使用敏捷測試與質量提升方面沒有直接關系。
楊進：我理解敏捷測試就是讓項目相關的角色全體直接承擔項目最終目標，由于都是為最終目標服務，因而角色也變得模糊，并且每個人的工作也需要考慮是否對當前最急迫的事情，這種集中所有角色力量為共同目標前進的開發方式，減少了大家溝通和項目迭代成本，最終很容易得到項目整體效率和質量的提升。由于各角色對目標理解一致，對產品理解都很深入，因而可以更多的把bug消滅在開發的早期，比如單元測試、新功能測試階段，使得后期的集成和系統測試問題變得更少，尤其是產品最終的效果問題也會減少。
開源對測試的影響，如何看待測試的開放性？
徐毅：平臺、工具、框架在我看來屬于比較相同的情況，我就拿我自己的經歷來做例子吧。在諾西的時候，我們有使用過一個叫robotframework的測試自動化框架，它最開始是一個和諾西合作的芬蘭專家開發出來的，在諾西（當時還叫諾基亞網絡）最先開始使用， 而后逐步推廣，在此過程中這個框架也在不斷地更新、改進、完善。后來在公司之外也有很多的使用者，于是開發者和諾西把這個框架開源出來，也吸引了更多的人加入到這個框架的開發中來，包括衍生工具的開發，這都推動了這個工具的廣泛使用和不斷完善。諾西作為最主要的支持者，并沒有因為開源而受損，反而因為這個開源框架龐大的用戶群體和開發者隊伍而受益頗多，有更多的人可以分享經驗、討論問題，也有更強大的開發力量提供所需的功能。不過，開源的軟件，或者開源的社區相對來說更傾向于Linux的設計理念，也即是更專注于某一個領域、某一塊功能，做精，而不像是Windows那樣的設計理念，強調易用性、一站式體驗。這意味著，企業內要完成所有的測試工具，可能需要和多個開源工具、框架打交道，整體上如何協調使用并不容易，需要培養相關方面的人才。
測試開放性，沒有特別想法，也沒啥體驗，只能憑感覺談談。個人觀點比較悲觀或者比較現實。測試就是測自己產品的功能、特性，讓別人知道自己的測試，也就是知道了自己產品的細節和特性。出于商業上的考慮，我認為各企業恐怕會較難把最核心部分的東西拿出來公開。不過這個很可能會是一個趨勢，即使拿出來的測試用例的范圍比較小而已。對于產品也有要求，得要是相對標準化程度比較高的產品，不然拿出來的測試最多別人參考一下，而無法直接使用，也無法反饋改進，意味著拿出來的那一方也無法受益，這樣的話這些測試也就等同于是“死亡的文檔”（dead documentation），沒有實效。
公直：開源意味著更多可以利用的資源，特別是在測試工具上，開源也是一種開放的心態。測試的開放性，在于比較坦誠地把自己在怎樣的場景下如何去做測試給大家做個介紹。非常典型的就是Google，在James的帶領下，有一系列的博客、文章、工具在介紹他們的測試，介紹他們測試中遇到的問題已經他們是怎么解決的。非常期望各個公司，無論大小，測試做的程度，都可以把自己的測試通過微博、博客、文章、公開演講等形式公布出來，畢竟這一部分不太涉及太多的商業機密或者核心技術。
楊進：測試的開放性，或者說基于某種特性測試的開放性是未來發展的趨勢，原因是互聯網的創業越來越依托一些基礎的平臺，比如iOS、Android，而就一個公司內部而言，云的廣泛應用也使得不同產品基于一個相同的基礎，由于有了共同的基礎，這些都表征出測試也會慢慢走向開放，從部門走向公司，從公司內走向開源。一個好的開放性測試框架，是依托于具體測試資源，以滿足具體某種測試需求而誕生的。這種測試框架因為和用戶的某些需求綁定因而生存能力很強，并且也能很好的一站式完成用戶的需求。
我們把測試當成了質量保證的主要手段，當質量低下時，或者為了達到高質量時，一般的選擇都是加大測試的工作量。您怎么看？
徐毅：臨時抱佛腳，沒用。就算真要加大，同時也得加大開發的工作量，找出來的bug沒人修復的話，質量是不會提高的，只不過是我們更加清楚自己的產品質量很爛而已。
公直：測試工程師做的測試活動一般都被稱之為是“檢測”，與之對應的開發工程師做的測試都是在“預防”，質量高低可以通過測試“檢測”出來，但測試永遠無法提升產品質量。所以，為了達到高質量，可以做更多的測試，加大測試工作量來發現產品的缺陷并修復，但對于質量，這都是“事后”，是一種下策，不是不可以。更好的辦法，是測試前移，讓開發來做單元測試、簡單的功能測試，在這個過程中會發現大量的問題并自行修復，測試更過地關注在用戶使用上，這樣高質量會更容易達到一些。
楊進：質量的主體其實是Dev，試想QA完成某個被測對象的測試，它最核心的價值是什么？發現bug 或是證明產品能滿足具體應用的需求？我選擇后者，因而如何讓Dev開發出質量更高的代碼是每個產品質量可控的測試團隊首先考慮的事情。當然如果當前質量低下的時候，一個比較快速見效的方法就是投入更多的測試，但是這不能是唯一手段，必須有人走到開發的階段，從上游逐步開始改善代碼的質量和可測試性，否則這就是一個死循環。更多的低效投入，更多的測試和debug成本，這足以壓壞這個項目的所有角色，而不僅僅是QA。
工作中推薦的測試框架？使用的范疇？
徐毅：我推薦使用robotframework，它是一種基于關鍵字驅動理念的的測試自動化框架（也支持數據驅動），用于敏捷測試象限（參看Lisa的書或者Brian Marick的博客）中的Acceptance Testing。更多的信息可以參看它的主頁，www.robotframework.org。最初是由諾基亞西門子網絡資助開發的，如今已經開源，大家都可以使用，國內也有許多的實踐者可以交流經驗。它支持多種的測試文件格式，包括HTML、CSV和文本文件，測試用例的格式主要是一個表格形式，和FIT、FitNesse比較像。然后通過內部的機制驅動底層的Library進行測試，而Library可以用Python和Java編寫，目前已經有很多現成的，例如Selenium、Telnet、SSH、AutoIt等。
我使用這個工具已經很多年，覺得它非常的好用，非常貼合敏捷開發的方式，能夠支持我們的ATDD，如今它甚至已經內嵌可以支持BDD格式的關鍵字腳本。
公直：Selenium，主要做Web UI級別的功能測試； JUnit/GTest, 代碼級別的單元測試或者API調用級別的自動化測試；staf/stax，遠程調用，在測試環境部署自動化中可以用到；JMeter/ab/http_load, 性能相關的測試；另外，給大家推薦一款自動化調度的工具TOAST，http://toast.taobao.org/ ，是我們這邊的一個開源的測試調度工具，主要解決持續集成中的測試執行。
楊進：百度內部有一個測試工具平臺，里面有百度內部開發的很多很棒的工具和框架，后續這些工具會慢慢開源出來。大家熟知的工具中，比如：代碼覆蓋率的gcov、BullseyeCoverage（支持邏輯判斷的覆蓋率統計），代碼掃描工具pclint，內存泄露檢查工具Valgrind，單元測試工具GTest，如果測試移動產品，MTC會是一個好選擇
在工作中會遇到各種各樣的bug或缺陷，能否分享1-2個？
楊進：在測試分布式系統中，曾經遇到過在同一個目錄下出現兩個同名文件的情況，導致系統直接crash掉了，這個bug讓我覺得一切皆有可能。監控發現過工程師在進行換庫導致流量下降的問題，這個case讓我明白bug不僅來自程序和數據，也來自每個可能對線上造成影響的環節。