Facebook 的自動化測試(2)

　　We’re starting to use JSSpec for unit-testing JavaScript code, though that’s still in its early stages at this point.

　　For backend services, we use a variety of test frameworks depending on the specifics of the services. Projects that we release as open source use open-source frameworks like Boost’s test classes or JUnit. Projects that will never be released to the outside world can use those, or can use an internally-developed C++ test framework that integrates tightly with our build system. A few projects use project-specific test harnesses. Most of the backend services are tied into a continuous integration / build system that constantly runs the test suites against the latest source code and reports the results into the results database and the notification system.

　　HipHop has a similar continuous-integration system with the added twist that it not only runs its own unit tests, but also runs all the PHPUnit tests. These results are compared with the results from the same PHP code base run under the plain PHP interpreter to detect any differences in behavior.

　　Our test infrastructure records results in a database and sends out email notifications on failure with developer-tunable sensitivity (e.g., you can choose to not get a notification unless a test fails continuously for some amount of time, or to be notified the instant a single failure happens.) The user interface for our test result browser is integrated with our bug/task tracking system, making it really easy to associate test failures with open tasks.

　　A significant fraction of tests are “push-blocking”—that is, a test failure is potential grounds for holding up a release (this is at the discretion of the release engineer who is pushing the code in question out to production, but that person is fully empowered to stop the presses if need be.) Blocking a push is taken very seriously since we pride ourselves on our fast release turnaround time.

　　My team, Test Engineering, is responsible for building the common infrastructure used by all the above stuff, as well as for maintaining PHPUnit and Watir. Facebook has no dedicated QA team; all Facebook engineers are responsible for writing automated tests for their code and keeping the tests maintained as the underlying code changes.

　　Facebook’s test setup is still very much a work in progress, but the above is at least a taste of what we do in that area.

　　From http://www.quora.com/What-kind-of-automated-testing-does-Facebook-do

　　發表在 未分類 | 留下評論

　　<谷歌是如何測試> 序

　　發表于 2012 年 02 月 21 日 由 HuangLi

　　吳軍的<浪潮之巔>中有這么一章，他在里面歷數了二十世紀五十年代以后的偉大的科技公司，無一例外，這些公司背后的驅動力都是技術，而技術的根本就是人。無論是基因科技還是藍色巨人，里面都有一批做技術的人，可能是在這個行業已經工作了20年，但還在一直堅持做技術的工作，也正是這些人，推動著浪潮不斷地拋向更高。

　　在國內，多數剛剛開始工作的同學，特別是應屆生或者剛剛轉行到計算機工種的同學，都是非常崇敬技術的，特別是在軟件公司，感覺如果做出一套優雅的界面或者牛逼的系統，那將是一件非常屌的事情。但慢慢地隨著時間的漂移，過了幾年，隨著一些年長的工程師的跳槽或者升遷，突然發現自己在項目組里已經是做技術里比較厲害的一個了，于是乎，伴隨著某個“機會”，從團隊主管開始，慢慢地走上了“管理”的道路，與技術也漸行漸遠，雖然偶爾回想起來心有不甘，有心再去追逐，但也無能為力，技術領域日新月異的速度超過了你的想象，這仿佛變成了一個規律似的，像兩千年的王朝，不斷地迭代。至今，在多數國內科技公司，很難找到工作10年以上技術老兵，看看一系列開發者大會上，嘉賓也多數是二三十歲的小伙。所以，對于那些堅持在一線做技術的人，非常欣賞和崇拜，相信這些人也將是推進國內公司走向浪潮之巔的根本動力。如果有一天，你有機會站在Career Path的十字路口，不要猶豫，選擇技術，大致原因，

　　技術是推進社會、科技進步的根本原因;

　　問下自己內心是否真的喜歡現在的狀態，還是被迫上位;

　　技術是了解一線問題的真正來源;聽得見炮灰人，都是前線的工程師;

　　管理工作主要是在做人的管理，相比較和機器與程序打交道，務虛一些，想做好比較難，特別是在當下國內的大環境，容易變形;

　　招聘市場上的技術崗位遠遠比管理崗位多，人無遠慮，必有近憂;

　　薪資待遇上，技術人員越來越受重視;

　　好了，還是步入正題，討論測試的事情吧。軟件開發模式，特別是互聯網，最近幾年都在追求快速迭代發布，例如Gmail或者新浪微博，都是Beta版本線上運營，知道軟件開發流程的人都清楚，Beta版意味著潛在Bug和Issue，離正式的Release還有一段距離，但還是會帶著潛在風險上線。為什么這樣，難道是沒有經過系統的測試?真正的原因還是風險的控制，詳細的幾點原因以后再講。但卻造就了一些對測試的誤解，

　　這些應用沒有經過很好地測試，好多功能使用上都有問題;

　　測試水平比較有限，沒有能及時的發現潛在問題;

　　測試本身沒有太多的技術，基本上是功能確認，點點鼠標、搭建環境驗證下就可以;

　　只要認真仔細，有責任心就可以做好測試;

　　等等諸如此類的誤解，讓許多不明真相的群眾，特別是應屆生，都不會把測試作為自己的職業規劃來考慮，讓我們的招聘HR也傷透了腦筋。也想通過這個系列的討論，讓大家清楚測試工作如果做好，方法其實并不是想象中的那么簡單和表面上的膚淺，是非常好有挑戰的。

原文轉自：http://www.kjueaiud.com