Thread per connection VS Event loop

Advantage:
more memory consumption thread blocked waiting for I/O operation

  • Q: So why not Event loop, callbacks, non-blocking I/O
  • A: cultural and infrastructural.
    1. cultural, we thought that the I/O should be blocking.
    2. infrastructural
      • single threaded event loops require I/O to be non-blocking, but most libraries are not.
      • too much options: EventMachine, Twisted
  • Q: Why javascript?
  • A: javascript has the following features:
    1. Anonymous functions, closures. – easy to create callback
    2. Only one callback at a time. – only one callback at a time
    3. I/O through DOM event callbacks –non-blocking
    4. promise: a promise is a kind of EventEmitter which emits either “success” or “error”. (But not both.)

1. 从http://ctags.sourceforge.net/ 下载最新版本的ctags文件,目前为ctags-5.9.tgz.

2. 解压缩 tar -xf ctags-5.8.tgz

3. 安装: cd ctags-x-x && configure && make && make install

    这里需要注意一下,ctags默认会安装到/usr/local/bin/目录下,当你安装完毕后执行ctags命令,可能仍然执行的是Unix系统自带的那个ctags,而非你新安装的这个exuberant ctags,我的解决思路是,在 .bash_profile里创建一个名为 ectags的alias,指向我们新安装的这个exuberant ctags。

4. cd <工程目录>,  ectags -R, 就会自动生成tag文件了。

 

注:本文假设你对CucumberSelenium-WebDriver有一定的了解。

####什么是回归测试? 回归测试(regression test)是QA对程序功能问题的验证,通常我们的做法是:
QA 手工测试 -> 报告bug -> Dev 修bug -> 提交到代码库 -> 构建程序包 -> 部署-> QA手工测试 -> 报告bug, 如此反复…

试想随着版本需求范围的增加,回归测试的测试用例也会如滚雪球般越积越多,在实施回归测试的过程中,因此,手工测试对于QA来说是重复的、乏味的。

让我们来看一下回归测试的定义:

回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
回归测试的目的是,通过了回归测试的软件,至少其基本功能是可用的。

####回归测试应该覆盖哪些内容? 从上面的定义,我们就可以识别出哪些测试用例需要被包括到回归测试中:

  1. 与外部件集成的功能。
  2. 主干功能。
  3. 容易被break的测试。

####自动化回归测试 既然测试范围已经确定了,接下来就要考虑如何减少这些重复的工作。我们很自然地想到了自动化。随之而来的问题是:

  1. 我们如何实施自动化?
  2. 我们的项目时间很紧,如何在不影响项目进度的前提下实现自动化的回归测试?
  3. 对于web项目,如何保证其在各个浏览器下面都能够正常工作?

对于第一、三个问题,有个成熟的方案,selenium-webdriver,其支持多种语言API, 包括Java,C#,Python,Perl,PHP,Ruby。也支持对多种浏览器的调用,可以模拟多种浏览器下对app的访问,并且支持对结果页面进行检查。 对于第二个问题,在经历过几次不是很成功的实践之后,我个人很反对对项目采用”休克疗法”,即完全停止目前的工作,采用另外一种看起来更好的方式来解决当前的问题,最具代表性的例子就是”打着重构的幌子进行重写”,在所谓的”重构”完成之前,项目其他成员的工作都是被阻塞住的,而且一旦”重构”失败,也难以恢复到”重构”前的状态。

在这里,我推荐一种循序渐进的方式逐步实现回归测试的自动化。
举个例子: 在确定了回归测试的范围后,我需要测试一个网上书店的从最新书籍列表进入书籍详情页面的功能,我们分别用普通的测试用例和DSL描述的用例:

普通的测试用例:
预置条件
数据库中有三本书,其信息如下:

          ISBN          书名                       作者            价格 
         111111    Head First Design Pattern      Somebody         12
         222222    Test Driven Development       Kent Beck         22
         333333         Refactor                 Martin Fowler     20

操作步骤:
进入书籍列表页面,点击书籍”Head First Design Pattern”的链接
预期结果:
进入书籍《Head First Design Pattern》详情页面,能够正确展示书籍名,价格,作者

使用Cucumber DSL描述的测试用例:

    Given There are books as follows : 
        | ISBN   | 书名                      | 作者          | 价格 |
        | 111111 | Head First Design Pattern | Somebody      | 12   |
        | 222222 | Test Driven Development   | Kent Beck     | 22   |
        | 333333 | Refactor                  | Martin Fowler | 20   |
     And I am on the book list page
     And I follow "Head First Design Pattern"
     Then I should be on book detail page
     And I should see "Head First Design Pattern" as title
     And I should see "12" as price
     And I should see "somebody" as author</span>

####渐进式实现自动化回归测试 比较这两种形式的测试用例,我们排除语言实现的差异(中文和英文,而且Cucumber也是支持中文DSL的), 它们的共同点是,都是人类可以理解的语言,任何一个QA都能够编写上述两种形式的测试用例。不同点在于,使用Cucumber DSL描述的测试用例可以在以后的某个时间点很容易地转换成自动化测试用例.

于是,我们可以在项目中采取如下形式逐步把回归测试自动化:
阶段一: 确定回归测试覆盖功能点的范围, 使用cucumber DSL描述测试用例 手工执行这些用例 阶段二: 利用项目间歇期,把这些使用cucumber DSL描述的测试用例转换成自动化测试。 此时,项目中回归测试会存在自动化和手工测试两种形式,部分地节省了人力。 阶段三 : 所有的回归测试用例都被实现为自动化测试。 这些测试都是可重复的,可以大大节省QA手工执行测试用例的时间。 后期对回归测试用例的修改都相应地将其自动化。 就像重构一样,你可以在上面这三个阶段中的任何一个时刻停止,你也可以在停止之后继续。 如果你能够在你的项目里实践到阶段三,那么恭喜你,你们已经做到了让合适的人做合适的事情了。

    所谓“闭包”,就是在构造函数体内定义另外的函数作为目标对象的方法函数,而这个对象的方法函数反过来引用外层函数体中的临时变量。这使得只要目标对象在生存期内始终能保持其方法,就能间接保持原构造函数体当时用到的临时变量值。尽管最开始的构造函数调用已经结束,临时变量的名称也都消失了,但在目标对象的方法内却始终能引用到该变量的值,而且该值只能通这种方法来访问。即使再次调用相同的构造函数,但只会生成新对象和方法,新的临时变量只是对应新的值, 和上次那次调用的是各自独立的

 分享了个关于closure的ppt在这里

     在最近的两周里,和一个同事一起搭建一个持续交付的demo工程,到目前为止,已经基本接近尾声。不过, 这个demo之前是根据一个ruby应用搭建的,但是考虑到国内目前的软件行业的现状,ruby仍然是一门小众语言,因此考虑通过一个java应用搭建一个CD Demo,这就是后面一周的工作重点啦。

成果:

  • 设计了一个包含了Go master、Go agent、puppet master,target nodes, Dev Env演示环境的部署策略:
  • 使用shell编写了一个简陋的rails应用远程部署脚本。
  • 对于puppet有个基本的认识,使用puppet搭建了上述的环境的基础设施。

收获:

   1)  对bash 有个基础的了解,知道了interactive shell和non-interactive shell、登陆shell与非登陆shell之间的区别(他们启动的startup不一样)

   2)  更加体会到了tasking的好处,尤其在考虑上述5个部件之间的交互关系时,采用这种方式能够帮助我理清思路,找出合理的解决办法。

   3)  对于SSH有了基本的了解,知道了可以通过发布公钥在多个节点之间建立信任关系,用shell脚本实现了通过ssh远程登陆目标机器完成相应操作。

 

计划:   

  • 了解open stack,目前仅知道这是一个开源的云计算平台软件集合
  • 搭建一个open stack环境。
  • 搭建一个java项目的持续构建、自动部署平台。

遗留问题:

  1) 对于rvm加载的机制尚不太清楚,需继续研究

  2) 对于maven还是不够了解,需要继续学习,通过maven对该java demo项目进行构建