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

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

　　楊進：測試的開放性，或者說基于某種特性測試的開放性是未來發展的趨勢，原因是互聯網的創業越來越依托一些基礎的平臺，比如iOS、Android，而就一個公司內部而言，云的廣泛應用也使得不同產品基于一個相同的基礎，由于有了共同的基礎，這些都表征出測試也會慢慢走向開放，從部門走向公司，從公司內走向開源。一個好的開放性測試框架，是依托于具體測試資源，以滿足具體某種測試需求而誕生的。這種測試框架因為和用戶的某些需求綁定因而生存能力很強，并且也能很好的一站式完成用戶的需求。

　　InfoQ：我們把測試當成了質量保證的主要手段，當質量低下時，或者為了達到高質量時，一般的選擇都是加大測試的工作量。您怎么看?

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

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

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

　　InfoQ：工作中推薦的測試框架?使用的范疇?

　　徐毅：我推薦使用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會是一個好選擇

　　InfoQ：在工作中會遇到各種各樣的bug或缺陷，能否分享1-2個?

　　楊進：在測試分布式系統中，曾經遇到過在同一個目錄下出現兩個同名文件的情況，導致系統直接crash掉了，這個bug讓我覺得一切皆有可能。監控發現過工程師在進行換庫導致流量下降的問題，這個case讓我明白bug不僅來自程序和數據，也來自每個可能對線上造成影響的環節

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