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.ltesting.net