專家眼中的QA、敏捷測試(2)

　　其次，ET的目的在于“探索”，也即有一個明確的測試目標，但是目標的細節或是達成目標的步驟尚不清晰，所以需要邊走邊看，同時間地進行學習、設計、執行、解析的結果，與PDCA循環頗有相似之處。

　　第三要區分開ET和手工測試的關系。“手工測試”所強調的是執行的手段，也即“手工”。而ET主要強調目的，也即“探索”，當然還有就是，執行只不過是ET中的一部分而已，而這一部分，可以借助自動化。例如，修改某個已有自動化測試腳本中的部分測試數據，借助于腳本快速地執行某些操作，而去掉或暫停分析部分的腳本執行，因為此時測試的結果未知，需要依賴人工來判斷、分析測試結果。

　　公直：探索式測試最近2年異?；鸨?，很多人以為是最新出的一個測試技術或者方法。Cem Kaner 在1983年(都快30年了)就提出了。這是一種強調個人自由與責任的測試方法，讓獨立測試人員可以借由不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時改善測試用例從而達到相輔相成的效果。在一淘這邊，其實很早就開始使用這種實踐方法了，但很多一線的測試人員并不知道自己的做法就是探索式測試，在互聯網研發模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一個月就要上線。在這樣的環境下，文檔少，在測試計劃制定設計上都不可能完善，一般在測試過程中是用freemind等腦圖工具來記錄測試執行過程的同時做測試用例的設計，這種方式可以做常規測試的補充。

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

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

　　InfoQ：您怎么看敏捷測試，執行后會質量有哪些明顯的改善?

　　徐毅：我認為，敏捷測試(關于敏捷測試的定義、介紹，請參考Lisa Crispin書中的描述)并無法單獨的執行，必須在敏捷的環境下，結合開發人員方面的敏捷實踐(以及組織結構)齊頭并進方可實現。而此時，質量的提升乃是源于軟件開發工作整體的改善，很難說一定是測試的功勞。另一方面則在于，測試本來就無法“控制”質量，自然也無法改善質量，因為測試工作本身并不改變那些可以影響質量產生的因素。但敏捷測試的實踐對于質量的提升是肯定有影響的。

　　敏捷中對于團隊內外參與、交流的追求，能夠更容易“do things right”

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

　　完整團隊、跨職能團隊等實踐，團隊負責自己的工作方式改進，更容易做到“do things rightly”

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

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

　　InfoQ：開源對測試的影響，如何看待測試的開放性?

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

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

原文轉自：http://www.anti-gravitydesign.com