• 现在， 3条产品线的自动化都已在进行中，平时大家也都会碰到一些问题，这些问题的解决思路也是决定我们的工作效率的一个关键因素。 今天帮媛媛解决一个问题后，突然有一点感触，就把它写了下来，比较凌乱，大家凑合看看吧！ 重点不是在这个问题的复杂程度，而是在我们平时的问题解决思路上。 问题重现： 最初，我们对这个问题的定位：如何实现点击弹出框上的确定按钮。 好，这种情况，我们第一反应肯定是会想到popupwin 1. 于是，不加思索的就直接在代码后面添加了如下的代码      ie.popupwin.button(:name=>"确定").click 运行代码，页面如上面截图所示，hold在这里，没有继续的意思，关掉IE再想想。 这个时候，我以为是popupwin的问题，接着，思路就开始偏离了。我对问题的定义变为：“这个弹出框是通过一个js弹出来的，捕获不到。” 接着，我google了下“waitr js弹出框”，找到了下面的2种方法，打算分别式试一试： 2.  watir1.6.5中有原生方法操作JS的弹出框。 在watir/dialog文件中定义了2个类：Dialog和DialogButton。 Dialog.close方法可以关闭1个js弹出框； Dialog.exists?方法可以判断弹出框是否存在； Dialog.button(name).click方法包含name的窗口模拟按下Enter键; 使用方法： require 'watir/dialog' dia = Watir.Dialog.new Dialog::WindowName = ''...

    思路决定出路

    发表于 2012/04/26 | 3 条评论
    现在， 3条产品线的自动化都已在进行中，平时大家也都会碰到一些问题，这些问题的解决思路也是决定我们的工作效率的一个关键因素。 今天帮媛媛解决一个问题后，突然有一点感触，就把它写了下来，比较凌乱，大家凑合看看吧！ 重点不是在这个问题的复杂程度，而是在我们平时的问题解决思路上。 问题重现： 最初，我们对这个问题的定位：如何实现点击弹出框上的确定按钮。 好，这种情况，我们第一反应肯定是会想到popupwin 1. 于是，不加思索的就直接在代码后面添加了如下的代码      ie.popupwin.button(:name=>"确定").click 运行代码，页面如上面截图所示，hold在这里，没有继续的意思，关掉IE再想想。 这个时候，我以为是popupwin的问题，接着，思路就开始偏离了。我对问题的定义变为：“这个弹出框是通过一个js弹出来的，捕获不到。” 接着，我google了下“waitr js弹出框”，找到了下面的2种方法，打算分别式试一试： 2.  watir1.6.5中有原生方法操作JS的弹出框。 在watir/dialog文件中定义了2个类：Dialog和DialogButton。 Dialog.close方法可以关闭1个js弹出框； Dialog.exists?方法可以判断弹出框是否存在； Dialog.button(name).click方法包含name的窗口模拟按下Enter键; 使用方法： require 'watir/dialog' dia = Watir.Dialog.new Dialog::WindowName = ''...

    继续阅读...

  •        今天，KPI自评的时候，看着三个月前给自己定下的目标，有点惭愧！回头想想，一直想做的事情没做，一直都要研究的技术也没研究，最后留下的只是项目，项目，还是项目………        从个人的成长来看，有些技术还是需要花时间去研究的，比如说，hadoop，分布式计算，dubbo……. 但目前这些方面，我基本还是没有涉足，DA团队已经在做这方面的技术选型了，所以跟上去应该没错！        工作也快4年了，也该转型寻求突破，不能这样子混下去，从某些领域上找突破口，成为领域的技术专家，这才比较靠谱。如果一味的多方面发展，反而会成为短板。        生活方面，也面临结婚，买房的压力，杭州的房价也没看到有什么大的松动，还需要等待……..下半年，需要先把房子的事情搞定。        这段时间一直都没有写博客，精力太分散了。分享一句话，无意中想到的，可能以前什么地方看到的，只是无意中忽然想到的。   谁都会有梦想，但是你必须得先满足了别人的梦想，然后别人才能给你实现梦想的机会。梦想和现实就是这样子。

    压力啊！

    发表于 2012/03/29 | 1 条评论
           今天，KPI自评的时候，看着三个月前给自己定下的目标，有点惭愧！回头想想，一直想做的事情没做，一直都要研究的技术也没研究，最后留下的只是项目，项目，还是项目………        从个人的成长来看，有些技术还是需要花时间去研究的，比如说，hadoop，分布式计算，dubbo……. 但目前这些方面，我基本还是没有涉足，DA团队已经在做这方面的技术选型了，所以跟上去应该没错！        工作也快4年了，也该转型寻求突破，不能这样子混下去，从某些领域上找突破口，成为领域的技术专家，这才比较靠谱。如果一味的多方面发展，反而会成为短板。        生活方面，也面临结婚，买房的压力，杭州的房价也没看到有什么大的松动，还需要等待……..下半年，需要先把房子的事情搞定。        这段时间一直都没有写博客，精力太分散了。分享一句话，无意中想到的，可能以前什么地方看到的，只是无意中忽然想到的。   谁都会有梦想，但是你必须得先满足了别人的梦想，然后别人才能给你实现梦想的机会。梦想和现实就是这样子。

    继续阅读...

  • 最近，在GP上执行ETL测试的时候，感觉重复的动作太多，常常会window/linux切换，对于sql语句也没有一个很好的检查机制，最后管理这些脚本也不太方便。最后，我下定决心，重新用python来改写一个gpunit的框架，这里我只介绍该框架中用到db模块——Psycopg2 选择使用这个模块来做DB相关的操作，也完全是一个巧合，不做过多解释，我没去比较常见几个模块的优缺点，只是图方便而已。 1. 下载及安装： 去官网选择一个对应的版本下载，我的环境是python 2.7 windows 64位，就直接下载相应的即可： 地址:  http://www.stickpeople.com/projects/python/win-psycopg/ 执行下载的exe文件，无须再做其他的操作，该环境就已经准备好了！ 2. 数据库连接 我们都知道，要想对数据库进行操作，第一步肯定就是先练上该库，以我们的测试库为例：      host=‘10.**.***.**’, port=5432, user=’etltest’, password=’etltest’, database=’test’ 于是，我们链接PostgreSQL(GP的客户端实际上就是postgresql)并设定Cursor ，代码如下： import os import psycopg2 import psycopg2.extras import dbassert...

    Psycopg2模块试用

    发表于 2012/03/21 | 评论暂缺
    最近，在GP上执行ETL测试的时候，感觉重复的动作太多，常常会window/linux切换，对于sql语句也没有一个很好的检查机制，最后管理这些脚本也不太方便。最后，我下定决心，重新用python来改写一个gpunit的框架，这里我只介绍该框架中用到db模块——Psycopg2 选择使用这个模块来做DB相关的操作，也完全是一个巧合，不做过多解释，我没去比较常见几个模块的优缺点，只是图方便而已。 1. 下载及安装： 去官网选择一个对应的版本下载，我的环境是python 2.7 windows 64位，就直接下载相应的即可： 地址:  http://www.stickpeople.com/projects/python/win-psycopg/ 执行下载的exe文件，无须再做其他的操作，该环境就已经准备好了！ 2. 数据库连接 我们都知道，要想对数据库进行操作，第一步肯定就是先练上该库，以我们的测试库为例：      host=‘10.**.***.**’, port=5432, user=’etltest’, password=’etltest’, database=’test’ 于是，我们链接PostgreSQL(GP的客户端实际上就是postgresql)并设定Cursor ，代码如下： import os import psycopg2 import psycopg2.extras import dbassert...

    继续阅读...

  •        经历了无数的被墙之后，尤其是最近想看google test的blog，众多因素导致我下定决心，翻墙了！经过权衡，选择了利用google goagent来完成这一重任！       翻墙的步骤大概分为三步，利用google帐号申请app engine帐号，然后部署应用，最后设置代理！ 这个步骤非常简单，网上也有比较多的资料，我觉得写得比较好的就是下面这个，大家参考下:       详细步骤可以参考： http://maolihui.com/goagent-detailed-version-of-the-tutorial.html 从目前使用来看，这个完全够用！   下面来几个炫耀图：  

    终于翻墙成功了

    发表于 2012/03/20 | 评论暂缺
           经历了无数的被墙之后，尤其是最近想看google test的blog，众多因素导致我下定决心，翻墙了！经过权衡，选择了利用google goagent来完成这一重任！       翻墙的步骤大概分为三步，利用google帐号申请app engine帐号，然后部署应用，最后设置代理！ 这个步骤非常简单，网上也有比较多的资料，我觉得写得比较好的就是下面这个，大家参考下:       详细步骤可以参考： http://maolihui.com/goagent-detailed-version-of-the-tutorial.html 从目前使用来看，这个完全够用！   下面来几个炫耀图：  

    继续阅读...

  •       闰年bug导致微软Azure故障，原因其实很简单，就是程序员在计算日期的时候偷懒了，本来需求是算出第二年的今日，但是程序员想当然的直接取了当前日期，然后把年份加一，结果导致出现了2013年2月29号这样的悲剧日期。         微软Windows Azure也给出了相应的故障分析和总结的报告,如下链接: http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx 这份报告相对于阿里目前的故障处理报告来说，更有价值一些，可以从这个报告中学习他们对故障的分析和处理改进思路。很有参考的价值。         这个故障出来之后，有人翻出了Joel同学的软件随想录中关于微软和闰年的典故：详细的故事见下面的链接：http://turingbook.group.iteye.com/group/wiki/2022-BillG-Joel-Program-Manager 大致的故事简介就是：“1991年，Joel在微软还是vba的程序经理的时候，比尔盖茨会review所有的技术设计，joel在准备Excel的文档的时候，碰到的一个设计比较不清晰的地方，关于1990年2月29号的处理问题”          到这里，这个故障相关的原委都已经清楚了，我也从这个故障中看到了一些问题，结合在阿里的这段时间的项目经验，我觉得有些东西还是相通的，可以借鉴和学习。  1. 测试过程中，必须要全面考虑，把握细节：在我还未得知微软的这个故障之前，我其实已经碰到了一个类似的问题。我们的系统涉及到中美时间，当美国夏令时开始的时候，实际上与中国这边的时间已经有一个小时之差了，但是我们当时的程序用js简单的+8就完了，导致后来出现了时间上的误差。这个故障与微软的这个其实是很类似的问题。所以，测试人员在考虑这个问题的时候，是否有想到这个问题就非常关键了。 2. 问题无大小之分，也无轻重之分：看似这次的产生的原因非常微不足道，但是事实证明,一个小小闰年bug，就能让你标榜高可用的云计算平台，像多米诺骨牌一样迅速坍塌。 3. 自动化不是一切：从故障分析中看到微软提到，他们经过了完全的代码检查，自动化测试等等。缺少了必要的人工检查。 4. 故障不可怕，但需要从故障中吸取经验： 微软的这份报告，针对Prevention, Detection, Response, Recovery 四个方面做出了改进计划，这个值得借鉴。从问题中找到改进的方案和计划才是学习故障的重点。

    微软云平台的一个故障引发的思考

    发表于 2012/03/18 | 1 条评论
          闰年bug导致微软Azure故障，原因其实很简单，就是程序员在计算日期的时候偷懒了，本来需求是算出第二年的今日，但是程序员想当然的直接取了当前日期，然后把年份加一，结果导致出现了2013年2月29号这样的悲剧日期。         微软Windows Azure也给出了相应的故障分析和总结的报告,如下链接: http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx 这份报告相对于阿里目前的故障处理报告来说，更有价值一些，可以从这个报告中学习他们对故障的分析和处理改进思路。很有参考的价值。         这个故障出来之后，有人翻出了Joel同学的软件随想录中关于微软和闰年的典故：详细的故事见下面的链接：http://turingbook.group.iteye.com/group/wiki/2022-BillG-Joel-Program-Manager 大致的故事简介就是：“1991年，Joel在微软还是vba的程序经理的时候，比尔盖茨会review所有的技术设计，joel在准备Excel的文档的时候，碰到的一个设计比较不清晰的地方，关于1990年2月29号的处理问题”          到这里，这个故障相关的原委都已经清楚了，我也从这个故障中看到了一些问题，结合在阿里的这段时间的项目经验，我觉得有些东西还是相通的，可以借鉴和学习。  1. 测试过程中，必须要全面考虑，把握细节：在我还未得知微软的这个故障之前，我其实已经碰到了一个类似的问题。我们的系统涉及到中美时间，当美国夏令时开始的时候，实际上与中国这边的时间已经有一个小时之差了，但是我们当时的程序用js简单的+8就完了，导致后来出现了时间上的误差。这个故障与微软的这个其实是很类似的问题。所以，测试人员在考虑这个问题的时候，是否有想到这个问题就非常关键了。 2. 问题无大小之分，也无轻重之分：看似这次的产生的原因非常微不足道，但是事实证明,一个小小闰年bug，就能让你标榜高可用的云计算平台，像多米诺骨牌一样迅速坍塌。 3. 自动化不是一切：从故障分析中看到微软提到，他们经过了完全的代码检查，自动化测试等等。缺少了必要的人工检查。 4. 故障不可怕，但需要从故障中吸取经验： 微软的这份报告，针对Prevention, Detection, Response, Recovery 四个方面做出了改进计划，这个值得借鉴。从问题中找到改进的方案和计划才是学习故障的重点。

    继续阅读...

  •        导读：本文译自 James Whittaker 在 Google 测试官方博客发表的文章《How Google Tests Software 》（英文被墙了）。       在所有我被问及的问题中，最多的就是关于谷歌是如何测试的。尽管在博客中（google testing blog）中有过零碎的解释说明，但还是需要更多的系统阐述。虽然谷歌的技术路线在执行的过程中不断地进化，但公司的测试策略却从来没有变化过。谷歌现在 是一家拥有搜索、应用、广告、移动、操作系统等产品的公司，我们在这些涉及到的产品领域里发挥着非常有意义的作用。当我们涉及到一些新的领域或者在旧领域 里快速成长的时候，必须要求我们的测试也在同步的扩张和改进。在这个系列文章中提及的测试技术，多数是我们当前正在使用的，还有一些是希望以后在不久的将 来可以用到。        首先，先介绍一下组织结构，这一部分也可能会让你感到惊奇。其实在谷歌没有真正的测试部门，测试依托在各个产品领域部门里，我们称之为“工程生产 力”（Engineering Productivity）。工程生产力部门拥有数量不等的水平或者垂直的工程学科，测试是其中的大头。简单地说，工程生产力部门由以下几部分构成： 1. 一个工具产品团队（a product team），负责内部和外部开源的促进生产力的工具开发与维护，这些工具会被公司范围内的各种工程师使用。这些工具包括代码分析工具、IDE、测试用例管 理系统、自动化测试工具、Build系统、源码管理系统、代码审核调度系统、缺陷管理系统等等。 这些工具的都是为了提高工程师效率的，并且这些工具在策略上的目标多数是为了防止问题的发生，而不是发现问题本身。 2. 一个服务团队（a...

    Google是如何做测试的？

    发表于 2012/03/14 | 评论暂缺
           导读：本文译自 James Whittaker 在 Google 测试官方博客发表的文章《How Google Tests Software 》（英文被墙了）。       在所有我被问及的问题中，最多的就是关于谷歌是如何测试的。尽管在博客中（google testing blog）中有过零碎的解释说明，但还是需要更多的系统阐述。虽然谷歌的技术路线在执行的过程中不断地进化，但公司的测试策略却从来没有变化过。谷歌现在 是一家拥有搜索、应用、广告、移动、操作系统等产品的公司，我们在这些涉及到的产品领域里发挥着非常有意义的作用。当我们涉及到一些新的领域或者在旧领域 里快速成长的时候，必须要求我们的测试也在同步的扩张和改进。在这个系列文章中提及的测试技术，多数是我们当前正在使用的，还有一些是希望以后在不久的将 来可以用到。        首先，先介绍一下组织结构，这一部分也可能会让你感到惊奇。其实在谷歌没有真正的测试部门，测试依托在各个产品领域部门里，我们称之为“工程生产 力”（Engineering Productivity）。工程生产力部门拥有数量不等的水平或者垂直的工程学科，测试是其中的大头。简单地说，工程生产力部门由以下几部分构成： 1. 一个工具产品团队（a product team），负责内部和外部开源的促进生产力的工具开发与维护，这些工具会被公司范围内的各种工程师使用。这些工具包括代码分析工具、IDE、测试用例管 理系统、自动化测试工具、Build系统、源码管理系统、代码审核调度系统、缺陷管理系统等等。 这些工具的都是为了提高工程师效率的，并且这些工具在策略上的目标多数是为了防止问题的发生，而不是发现问题本身。 2. 一个服务团队（a...

    继续阅读...

  • What? 先说说什么是代码覆盖率: 它是反映测试用例对被测软件覆盖程度的重要指标，也是衡量测试工作进展情况的重要指标。它是对测试工作进行量化的重要指标之一。 我们平时所说的测试覆盖率分为三大类： 1. 行覆盖率：     度量被测代码中每个可执行语句是否被执行到 int foo(int a, int b) {   return  a / b; } 测试用例: TeseCase:  a = 10, b = 5 .csharpcode, .csharpcode pre {...

    说说覆盖率统计的相关事情

    发表于 2012/03/08 | 评论暂缺
    What? 先说说什么是代码覆盖率: 它是反映测试用例对被测软件覆盖程度的重要指标，也是衡量测试工作进展情况的重要指标。它是对测试工作进行量化的重要指标之一。 我们平时所说的测试覆盖率分为三大类： 1. 行覆盖率：     度量被测代码中每个可执行语句是否被执行到 int foo(int a, int b) {   return  a / b; } 测试用例: TeseCase:  a = 10, b = 5 .csharpcode, .csharpcode pre {...

    继续阅读...

  •  对于PHP的代码，我们写了非常多的基于PHPUnit测试框架的测试类，这些测试类覆盖范围比较大，从简单的判读真假的单元测试到大规模的后端服务的集成测试。开发人员把运行这些基于PHPUnit的测试用例作为他们工作中的一部分，同时这些用例也在一些专用的设备上不停地被运行(注：持续集成模式)。当开发人员对一些代码做了比较大的修改时，在开发机器上的自动化工具会运行这些测试用例的同时也会生成相应的代码覆盖率数据，对于需要提交到代码库的diff，在做代码review的时候回自动地产生一份带有覆盖率的测试报告。   Facebook 怎样做自动化测试         最近Quora上有个讨论，原意是：“facebook是如何做自动化测试的，他们是怎样测试才能保证每周的升级都可以不出差错的呢?” 参见Link          来自Facebook的Steven Grimm很好地回答了这个问题，觉得还不错，这里以第一人称翻译了一下。 对于PHP的代码，我们写了非常多的基于PHPUnit测试框架的测试类，这些测试类覆盖范围比较大，从简单的判读真假的单元测试到大规模的后端服务的集成测试。开发人员把运行这些基于PHPUnit的测试用例作为他们工作中的一部分，同时这些用例也在一些专用的设备上不停地被运行(注：持续集成模式)。当开发人员对一些代码做了比较大的修改时，在开发机器上的自动化工具会运行这些测试用例的同时也会生成相应的代码覆盖率数据，对于需要提交到代码库的diff，在做代码review的时候回自动地产生一份带有覆盖率的测试报告。           对于前端的代码，我们使用Waitir(注：Waitir是前端UI的自动化测试框架)做了基于浏览器的界面自动化测试。这些测试用例涵盖了网站页面的功能，特别是针对隐私方面，比如：“用户X发布了Y，而Y应该/不应该被用户Z看到”，有着大量的基于浏览器级别的这种用例。(这些隐私规则当然也会使用一些更低级别的方法被测试到，但是这些规则的实现是必须要严格执行的，并有着非常高的优先级，因此这部分必须要有足够的测试用例来覆盖)          除了一些使用watir的全自动化用例以外，我们也有一些半自动化的测试。这些测试也使用了waitir技术，这样可以使一些表格填充或者点击button来完成整改界面上的流程的测试不太单调乏味，而且我们可以很清楚地检查和验证当前的步骤或流程是否正确合理。 我们也在尝试开始使用JSSpec (注：JavaScript单元测试框架)去做一些JavaScript代码的单元测试，但当前也是刚刚开始做。          对于后端服务的测试，根据不同的服务特性我们采用了许多不同的测试框架与方法。对于一些需要开源发布的项目，我们会使用开源的测试框架，像Boost和JUnit测试框架(注：Boost是针对C++/JUnit是针对Java的测试框架);对于另外一些项目，可能永远都不会发布到外界，我们就是使用内部开发的可以很紧密地与我们build系统集成在一起的C++测试框架。还有少数项目会使用项目级别的测试工具。多数后端服务的测试都会紧紧地和持续集成/Build系统结合在一起，这些持续集成的build系统会不停地针对源代码自动地运行测试用例并生成测试结果，测试结果在存储在数据库的同时会发送到通知系统中去。 HipHop(注：HipHop for PHP是Facebook的PHP项目)有一套类似的持续集成系统，HipHop的单元测试和所有基于PHPUnit的测试都会被运行。所有的这些测试结果会和基于普通的PHP解释器的结果做对比，从而可以看到不同PHP上的行为的不同;          Facebook的测试工具将测试结果存储在数据库的同时会发送一份通知邮件，这个邮件会包含执行失败的信息并且邮件的接收范围是开发同学可以自己调整的。(例如，你可以选择只有在测试连续失败一段时候的时候才接收到通知邮件，或者当一个用力失败的时候立刻收到通知)。在浏览器UI上，测试结果和...

    Facebook 的自动化测试

    发表于 2012/03/05 | 评论暂缺
     对于PHP的代码，我们写了非常多的基于PHPUnit测试框架的测试类，这些测试类覆盖范围比较大，从简单的判读真假的单元测试到大规模的后端服务的集成测试。开发人员把运行这些基于PHPUnit的测试用例作为他们工作中的一部分，同时这些用例也在一些专用的设备上不停地被运行(注：持续集成模式)。当开发人员对一些代码做了比较大的修改时，在开发机器上的自动化工具会运行这些测试用例的同时也会生成相应的代码覆盖率数据，对于需要提交到代码库的diff，在做代码review的时候回自动地产生一份带有覆盖率的测试报告。   Facebook 怎样做自动化测试         最近Quora上有个讨论，原意是：“facebook是如何做自动化测试的，他们是怎样测试才能保证每周的升级都可以不出差错的呢?” 参见Link          来自Facebook的Steven Grimm很好地回答了这个问题，觉得还不错，这里以第一人称翻译了一下。 对于PHP的代码，我们写了非常多的基于PHPUnit测试框架的测试类，这些测试类覆盖范围比较大，从简单的判读真假的单元测试到大规模的后端服务的集成测试。开发人员把运行这些基于PHPUnit的测试用例作为他们工作中的一部分，同时这些用例也在一些专用的设备上不停地被运行(注：持续集成模式)。当开发人员对一些代码做了比较大的修改时，在开发机器上的自动化工具会运行这些测试用例的同时也会生成相应的代码覆盖率数据，对于需要提交到代码库的diff，在做代码review的时候回自动地产生一份带有覆盖率的测试报告。           对于前端的代码，我们使用Waitir(注：Waitir是前端UI的自动化测试框架)做了基于浏览器的界面自动化测试。这些测试用例涵盖了网站页面的功能，特别是针对隐私方面，比如：“用户X发布了Y，而Y应该/不应该被用户Z看到”，有着大量的基于浏览器级别的这种用例。(这些隐私规则当然也会使用一些更低级别的方法被测试到，但是这些规则的实现是必须要严格执行的，并有着非常高的优先级，因此这部分必须要有足够的测试用例来覆盖)          除了一些使用watir的全自动化用例以外，我们也有一些半自动化的测试。这些测试也使用了waitir技术，这样可以使一些表格填充或者点击button来完成整改界面上的流程的测试不太单调乏味，而且我们可以很清楚地检查和验证当前的步骤或流程是否正确合理。 我们也在尝试开始使用JSSpec (注：JavaScript单元测试框架)去做一些JavaScript代码的单元测试，但当前也是刚刚开始做。          对于后端服务的测试，根据不同的服务特性我们采用了许多不同的测试框架与方法。对于一些需要开源发布的项目，我们会使用开源的测试框架，像Boost和JUnit测试框架(注：Boost是针对C++/JUnit是针对Java的测试框架);对于另外一些项目，可能永远都不会发布到外界，我们就是使用内部开发的可以很紧密地与我们build系统集成在一起的C++测试框架。还有少数项目会使用项目级别的测试工具。多数后端服务的测试都会紧紧地和持续集成/Build系统结合在一起，这些持续集成的build系统会不停地针对源代码自动地运行测试用例并生成测试结果，测试结果在存储在数据库的同时会发送到通知系统中去。 HipHop(注：HipHop for PHP是Facebook的PHP项目)有一套类似的持续集成系统，HipHop的单元测试和所有基于PHPUnit的测试都会被运行。所有的这些测试结果会和基于普通的PHP解释器的结果做对比，从而可以看到不同PHP上的行为的不同;          Facebook的测试工具将测试结果存储在数据库的同时会发送一份通知邮件，这个邮件会包含执行失败的信息并且邮件的接收范围是开发同学可以自己调整的。(例如，你可以选择只有在测试连续失败一段时候的时候才接收到通知邮件，或者当一个用力失败的时候立刻收到通知)。在浏览器UI上，测试结果和...

    继续阅读...