近Quora上有個討論，原意是：“facebook是如何做自動化測試的，他們是怎樣測試才能保證每周的升級都可以不出差錯的呢?”
　　來自Facebook的Steven Grimm很好地回答了這個問題，覺得還不錯，這里以第一人稱翻譯了一下。 　
      對于PHP的代碼，我們寫了非常多的基于PHPUnit測試框架的測試類，這些測試類覆蓋范圍比較大，從簡單的判讀真假的單元測試到大規(guī)模的后端服務(wù)的集成測試。開發(fā)人員把運行這些基于PHPUnit的測試用例作為他們工作中的一部分，同時這些用例也在一些專用的設(shè)備上不停地被運行(注：持續(xù)集成模式)。當(dāng)開發(fā)人員對一些代碼做了比較大的修改時，在開發(fā)機器上的自動化工具會運行這些測試用例的同時也會生成相應(yīng)的代碼覆蓋率數(shù)據(jù)，對于需要提交到代碼庫的diff，在做代碼review的時候回自動地產(chǎn)生一份帶有覆蓋率的測試報告。
      對于前端的代碼，我們使用Waitir(注：Waitir是前端UI的自動化測試框架)做了基于瀏覽器的界面自動化測試。這些測試用例涵蓋了網(wǎng)站頁面的功能，特別是針對隱私方面，比如：“用戶X發(fā)布了Y，而Y應(yīng)該/不應(yīng)該被用戶Z看到”，有著大量的基于瀏覽器級別的這種用例。(這些隱私規(guī)則當(dāng)然也會使用一些更低級別的方法被測試到，但是這些規(guī)則的實現(xiàn)是必須要嚴格執(zhí)行的，并有著非常高的優(yōu)先級，因此這部分必須要有足夠的測試用例來覆蓋)
     除了一些使用watir的全自動化用例以外，我們也有一些半自動化的測試。這些測試也使用了waitir技術(shù)，這樣可以使一些表格填充或者點擊button來完成整改界面上的流程的測試不太單調(diào)乏味，而且我們可以很清楚地檢查和驗證當(dāng)前的步驟或流程是否正確合理。
    我們也在嘗試開始使用JSSpec (注：JavaScript單元測試框架)去做一些JavaScript代碼的單元測試，但當(dāng)前也是剛剛開始做。
    對于后端服務(wù)的測試，根據(jù)不同的服務(wù)特性我們采用了許多不同的測試框架與方法。對于一些需要開源發(fā)布的項目，我們會使用開源的測試框架，像Boost和JUnit測試框架(注：Boost是針對C++/JUnit是針對Java的測試框架);對于另外一些項目，可能永遠都不會發(fā)布到外界，我們是使用內(nèi)部開發(fā)的可以很緊密地與我們build系統(tǒng)集成在一起的C++測試框架。還有少數(shù)項目會使用項目級別的測試工具。多數(shù)后端服務(wù)的測試都會緊緊地和持續(xù)集成/Build系統(tǒng)結(jié)合在一起，這些持續(xù)集成的build系統(tǒng)會不停地針對源代碼自動地運行測試用例并生成測試結(jié)果，測試結(jié)果在存儲在數(shù)據(jù)庫的同時會發(fā)送到通知系統(tǒng)中去。
      HipHop(注：HipHop for PHP是Facebook的PHP項目)有一套類似的持續(xù)集成系統(tǒng)，HipHop的單元測試和所有基于PHPUnit的測試都會被運行。所有的這些測試結(jié)果會和基于普通的PHP解釋器的結(jié)果做對比，從而可以看到不同PHP上的行為的不同;
　　Facebook的測試工具將測試結(jié)果存儲在數(shù)據(jù)庫的同時會發(fā)送一份通知郵件，這個郵件會包含執(zhí)行失敗的信息并且郵件的接收范圍是開發(fā)同學(xué)可以自己調(diào)整的。(例如，你可以選擇只有在測試連續(xù)失敗一段時候的時候才接收到通知郵件，或者當(dāng)一個用力失敗的時候立刻收到通知)。在瀏覽器UI上，測試結(jié)果和 缺陷/開發(fā)任務(wù)跟蹤系統(tǒng)會結(jié)合在一起，可以很容易的將測試失敗與開發(fā)任務(wù)關(guān)聯(lián)起來。
      測試中一個非常重要的現(xiàn)象是“導(dǎo)致阻塞”，也是一個測試用例失敗有可能會阻止發(fā)布(在Facebook，有發(fā)布工程師會來評估是否可以將帶有問題的代碼發(fā)布到生產(chǎn)環(huán)境，發(fā)布工程師在必要的情況下會得到授權(quán)去阻止產(chǎn)品的發(fā)布)。阻止產(chǎn)品發(fā)布上線的事情是被認為是非常嚴重的問題，因為在Facebook大家對于這種快速發(fā)布的模式是深深引以為豪的。
      我所在的團隊是測試工程部門，主要職責(zé)是打造通用基礎(chǔ)工具，這些工具會被上述的所有人用到，同時我們也在維護測試框架，像PHPUnit和Watir。Facebook沒有專職的測試團隊，所有的工程師都需要為他們的代碼寫自動化測試用例，并維護這些測試用例，保證產(chǎn)品代碼改變的同時這些測試代碼可以正確地運行。
　　Facebook的測試還處于一個初期起步嘗試階段，上面的介紹都只是我們在當(dāng)前運行的方法而已。
　　公直 2012/2/27
　　附錄原文，
　　What kind of automated testing does Facebook do? How do they make sure they aren’t breaking things in their weekly pushes?
　　Steven Grimm， 2005-2012
　　We do several kinds of testing. Some specifics:
　　For our PHP code， we have a suite of a few thousand test classes using the PHPUnit framework. They range in complexity from simple true unit tests to large-scale integration tests that hit our production backend services. The PHPUnit tests are run both by developers as part of their workflow and continuously by an automated test runner on dedicated hardware. Our developer tools automatically use code coverage data to run tests that cover the outstanding edits in a developer sandbox， and a report of test results is automatically included in our code review tool when a patch is submitted for review.
      For browser-based testing of our Web code， we use the Watir framework. We have Watir tests covering a range of the site’s functionality， particularly focused on privacy?there are tons of “user X posts item Y and it should/shouldn’t be visible to user Z” tests at the browser level. (Those privacy rules are， of course， also tested at a lower level， but the privacy implementation being rock-solid is a critical priority and warrants redundant test coverage.)
      In addition to the fully automated Watir tests， we have semi-automated tests that use Watir so humans can avoid the drudgery of filling out form fields and pressing buttons to get through UI flows， but can still examine what’s going on and validate that things look reasonable.