移动测试
最近几年由于iOS和Android设备越来越普及，移动应用的出现了井喷，大部分都是个人开发者或者小型公司开发的个人应用或者手游。而且随着iOS和Android的设备和SDK的初步成熟，大量的大型商业公司已经或者准备开发移动应用。对于商业移动应用，稳定性非常重要。对于稳定性，测试就非常重要。由于智能系统越来越复杂和成熟，其上面的应用程序的功能也越来越多，所以自动化测试也就越来越重要。自动iOS在2007年和Android在2008年发布以来，基于这两个系统的自动化测试工具就初步发展起来。一般情况下最好使用和应用程序开发使用的语言来写功能测试，但是由于商业应用的业务需求越来越复杂，所以我倾向于使用基于BDD和SBE的测试工具来做业务测试。比如Calabash就是一个十分好用的基于Cucumber[2]的BDD移动测试工具，它同时支持Android和iOS。其Android的实现是基于robotium，而iOS的实现是基于Frank和UISpec。使用Calabash，测试人员可以使用自然语言来编写的cucumber测试脚本，然后通过在PC上运行cucumber脚本来测试iOS和Android设备上的应用程序。如果你的公司拥有大量的手动测试人员，并且希望进行移动自动化测试，ThoughtWorks针对这样的公司开发了一套全新的移动自动化测试工具：Lever，他和Calabash一样，同时支持Android和iOS。测试人员只需要通过打开一个网页，通过选择移动应用界面上的特定组件和对其的操作来进行组成自动化测试步骤，多个测试步骤可以形成一个测试场景，最终完成各种自动化测试案例并运行。由于Lever不是开源产品，也没有公开的详细资料，所以如果你想了解其详细功能和内容，可以BQConf上的Lever的专题演讲。
Web服务器性能测试
敏捷开发在当今软件行业里面扮演着越来越重要的角色，软件测试也随着逐步敏捷起来。由于软件系统，特别是服务器系统越来越复杂，规模也越来越大。开发人数也达到几十，甚至几百人，而且大规模使用第三方的软件库，比如Spring，Rails，Hibernate，.Net等。如果使用不当，将会引起很严重的性能问题甚至是稳定性问题，所以性能问题在当前的软件开发中已经越来越明显了。常规的持续集成验证了构建是否满足了功能设计要求，而持续性能测试增加了另外一重验证标准，程序是否满足了性能要求，从而是性能问题尽早被发现。持续性能测试主要的优点就是可以在代码改变以后可以快速的知道性能变化，比如如果发现性能问题，可以让提交这个Commit程序员去修复这个问题，因为他还能记住这个Commit。如果等到最后发布之前才发现，那么这个程序员可能已经不记得这个Commit，或者已经离开了公司，有可能导致修复这个问题的难度大大增加。如果这个是一个设计上的错误，那么团队就可以尽早修复它并避免以后的功能受其影响。
比如铁道部的12306购票系统上线后的第一个春节就遇到了严重的性能问题，面对预料中的高访问量，系统在春运期间经常长时间无法访问，导致大量用户无法购票。像这样严重的性能问题是在开发的时候是可以预见的，不过还是出现在产品环境上，由此可见系统在构架上没有对性能进行有效的设计，在测试上没有进行有效的性能测试（由于12306产生这个性能问题的原因很复杂，我们这里不做过多讨论，比如各种组织和利益等原因，也不讨论怎么解决。）。当这个性能问题出现的时候，根本无法在短时间内修复，导致了如此严重的性能问题维持了很长一段时间。在第二年的春运里面，系统才增加了排队系统，有效的缓解了性能问题，不过还是会时不时出现无法访问的情况。由于12306是中国唯一的网上火车票购票系统，就算出现这样严重的性能问题，人们还是只有继续使用它。但是如果有多个购票网站，一旦某个出现了性能问题而导致客户长时间无法访问，那么就会带来大量的客户流失，造成巨大的损失。因此性能测试对拥有大量用户软件系统十分重要，而且需要越早发现性能问题，越早修复越好，因为等到发布前，就算测试出性能问题，也有可能因为构架问题而无法修复。
让性能测试成为敏捷开发的一等公民对于更好的进行敏捷开发和高质量的持续部署越来越重要。持续性能测试不应该只是说说，特别是对于大型服务器项目和开发人员众多的情况下，持续性能测试将成为必不可少的组成部分。持续性能测试应该被看做持续交付的重要步骤，应该和回归测试一样，可以做到更频繁的高性能持续交付。在2013年5月发布的ThoughtWorks技术雷达中，让性能测试成为敏捷开发一等公民已经被列入了ADOPT。对于当今的软件系统，特别是对于大型服务器系统，并且它又拥有大量用户的情况下，持续性能测试将成为一个必不可少的组成部分。让我们一起去实践持续性能测试，比如新一代的性能测试工具Gatling 就是一个很好的试验田，通过它，我们可以很好的实践对于服务器系统的持续性能测试。
Web自动化功能测试
在过去几年，由于Web2.0的出现导致了Web的第二春的到来，并且我知道的公司和客户们都非常重视Web自动化测试，并且使用率也很高。但是我发现很多测试人员还在使用Selenium IDE或QTP等。对于Selenium，我认识的一般的测试人员只会使用Selenium IDE进行测试录制，然后使用“重播”进行测试。对于通过Selenium IDE录制的脚本是非常难以维护的，导致测试步骤的更改之后一般只能重新录制。对于开发中的项目的其Cost非常高，所以在实际中使用的效果很不好。
对于当前广泛使用的Agile的开发模型，Selenium IDE的方法基本不可用，所以需要更新到Selenium WebDriver（Selenium 2.0）。Selenium WebDriver提供了一套支持各种语言的WebDriver API，比如Java，Ruby, Python等。通过这套API用户可以启动各种不同的浏览器，比如IE，Chrome，Firefox等，并且通过API可以让浏览器访问不同的网页，模拟点击和输入等，获取网页中的内容等。使用WebDriver API比老的Selenium IDE带来了更多的好处，更为适合Agile开发，测试流程更为灵活，维护更为方便，测试流程更为清晰易读，断言也更为多样化等。但是对于测试人员也有一个麻烦，就是至少需要学习一门语言来开发测试案例。驱动Selenium WebDriver的测试可以使用xUnit或者各种BDD框架。
如果你们使用的是Ruby On Rails开发的Web系统，或者你想尝试一种新的快速的开发方式，你还有一个选择就是Watir。Watir是一个使用Ruby开发的测试API，和WebDriver API类似，而且它自带和Rails集成的组件，所以对于Rails的Web系统它有天生的优势。
由于Web Service的流行以及用户UI的需求越来越复杂，Web开发已经由MVC的模型发展到MVP和MVVM模型。由此一来前端的逻辑复杂程度和代码量（如Javascript等）就会大大增加，由此带来的问题就是测试量也会大大增加。对于如此大量的Javascript代码逻辑层的测试，并不适合使用做UI层功能测试的Selenium。所以我们应该在Javascript层做自动化测试。基于Javascript的自动测试框架很多，由于我倾向于Agile和BDD，所以我倾向于Jasmine，Mocha和Karma。其中Jasmine是一个支持BDD的自动化测试框架，而Macha是新的基于NodeJS开发的支持BDD的自动化测试框架。而Karma是一个自动化测试运行环境，它也是基于NodeJS开发的，Jasmine和Macha都可以在其上面运行。Karma支持多种browser，比如Firefox，Chrome， IE等，而且它使用也比较简单。
