專家眼中的QA、敏捷測試

　　編者按：測試、QA一直是大家關注的話題，只要有軟件開發，就離不開QA和軟件測試。本次特別邀請到一淘網測試架構師 @公直_黃利 ，諾基亞敏捷及精益教練 @徐毅-Kaveri 和百度高級測試工程師楊進，請他們談下各自對QA和測試的理解，內容涉及如何衡量軟件測試的有效性，探索式測試，敏捷測試，開源對測試的影響，測試的開放性以及測試框架推薦等。

　　InfoQ：請先做下自我介紹。

　　徐毅：我叫徐毅，現在在諾基亞北京擔任敏捷及精益教練的工作。我是從05年在杭州諾基亞網絡的時候開始轉做專職測試的，同期也加入公司剛成立的測試自動化小組，這對我的理念有很大的影響，基本上我認為所有的測試都應該自動化。06年初加入當時的第一個Scrum試點項目，體會了一把敏捷測試，當時還根據我們的經驗總結出了一套輕量化的測試流程。后來我們在公司內推廣使用robotframework這個工具，作為培訓師指導大家學會使用這個工具來進行測試自動化。后來還擔任了一段時間的測試自動化教練的工作。

　　公直：阿里巴巴一淘網測試架構師。

　　楊進：百度高級測試工程師，06年加入百度，之前有過4年的測試開發工作，加入百度以來，主要從事自動化開發、測試方法改進以及系統測試相關的工作。

　　InfoQ：最近主要在從事哪方面的工作?

　　徐毅：最近主要是在敏捷及精益教練這個方面做得比較多，輔助組織和個人進行敏捷轉型，由于有很強的測試背景，所以同時也做敏捷測試相關的工作。

　　公直：最近半年一直在做代碼質量的相關工作。在一淘業務線測試團隊支持之下，與測試、產品架構師、PE等合作，從系統層面出發，優化目前的測試策略和方法，提升系統的可測試性和可部署性。

　　楊進：近1年主要focus在系統測試和效果監控等系統層面的工作，目前是線下百度和大搜索效果監控的負責人，線下百度是一個基礎的系統測試平臺，對外提供預上線、故障預演、數據測試等系統層面的服務，而效果監控目標是快速發現產品嚴重影響用戶體驗的效果問題，它和線下百度相互相成，共同提升百度對外服務的質量。

　　InfoQ：國內外一直有很多人把測試與質量保證混為一談，其實測試屬于質量控制(QC)，而QA還有更多內容，請談談您對QA和測試的理解。

　　徐毅：其實不管是保證還是控制，都很難達到名副其實的效果。測試做得再充分、再徹底、再快速，也無法把質量給控制起來，最多只能夠更頻繁地展現出質量的現狀。關于QA么，我曾經在微博上發起過一個討論，還是比較熱鬧的，大家可以去看看，What is the value of Quality Manager。至于“質量保證”這個詞，大家可以想一想，如果我跟你拍胸脯說某件事情包在我身上，我保證辦到，但實際情況是，回過頭去我得催著一撥人做這個做那個才能保證你的事情辦妥，你覺得這是你理解中的“保證”嗎? 更重要的問題在于，“質量是什么”。如今，我們可以說質量的外延發生了變化，已經涵蓋了許多方面;也可以說，質量已經不再重要，用戶體驗才是最重要的。溫伯格在他的《質量 軟件 管理》書中說到“quality is value to some person”，對于不同的人來說，同一件東西的價值可以是不同的。

　　公直：其實一直以來個人不太喜歡把測試工程師稱呼為QA，QA一般是指質量保證，范疇更大一些，在一淘，像過程改進工程師、配置管理工程師都在做質量控制的事情。單純地靠測試工程師本身也是沒有辦法控制質量的，因為對決定軟件質量的還是開發工程師。這個在博客中的《Google如何測試》系列文章中提及，對于質量來說，預防問題比發現問題本身更重要。質量更多是開發人員的問題，而不是測試人員的。通過把測試工作融入到開發過程中，我們能降低那些富產Bug的人的出錯機會，不僅可以避免了大量最終用戶的使用問題，而且還可以極大地降低測試人員報無效Bug的數量。測試的未來在于發現設計和編程人員解決問題方法上的局限、思路中的狹隘和技能方面的不足，這是我對測試的理解，也認為是以后測試發展的一個方向。

　　楊進：我理解測試關注的更多是被測對象上線前的質量，而QA關注的是宏觀意義上的質量，包括開發環節的質量控制(如何提高代碼本身質量)、測試環節、上線環節以及運維環節(如線上出現問題后如何快速止損)，甚至還包括用那種開發模式能更有效的提升項目開發質量和效率，因而是一個更寬泛的領域。

　　InfoQ：如何衡量軟件測試的有效性?

　　徐毅：衡量一個東西的有效性，對我來說就看比較有無之間的區別，也就是說比較“有軟件測試”和“無軟件測試”在“效果”上面的差異，那就是有效性啦，也即是有效的程度。那么，你所期望的“效果”又是什么呢?

　　公直：從90年代末開始，測試進入所謂的“Prevention oriented period ”(參見wiki)階段，強調2點，第一個缺陷預防，第二就是軟件度量。就是這個問題本身(如何衡量軟件測試的有效性)，如何度量你做的測試有什么收益，如何判斷你的測試活動的有效性，無論是學術界還是工業界，好像也還沒有什么比較好的方法，特別是在國內目前的現狀(人治，部門經理或者項目經理決定太多東西)，度量系統(例如sonar)計算出的測試ROI本身可能也不一定準確，人的因素變化太多。我就簡單說下我們這邊判斷測試有效性做法好了，基本上還是還是從結果來看，上線失敗次數、線上故障、線上Bug幾個維度來評估測試的有效性。

　　楊進：要想全面評判測試的有效性是比較困難的，目前比較通用的手段是在產品發布以后，利用用戶報告bug的數量和趨勢來判斷測試的有效性，然后這種判斷方法需要上線后才能進行因而顯得價值有限，上線前也有一些可參考的手段，比如UT完成后的代碼覆蓋率，測試用例完后的評審，測試報告的評審等。我自己比較喜歡手段是代碼覆蓋率，因為代碼覆蓋率是一個利用客觀標準進行判定的方法。此外基于測試需求覆蓋率也是一個好方法。

　　InfoQ：請談下您對探索式測試的理解，請分享下這方面的實踐經驗?

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

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

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