Web 应用程序视觉感知测试
视觉感知测试，对于很多 QA，包括我在 2013 以前对于它的认知都是手动测试领域的一个成员。在这个 Web 系统爆炸的年代，Web UI 界面布局测试，多浏览器测试，CSS 的 refactor 等都成为了 Web UI 测试的痛中之痛，特别是大型 Web 应用的功能回归测试量太大，从而导致很多时候根本无法完成，所以很少会有团队去做全方位的 UI 界面布局回归测试，特别是对于使用 Agile 流程开发的团队就更加困难。
为了缓解这样的困境，不断地有人思考怎么自动化 UI 测试，我以前的公司就有人尝试在手机上做自动 UI 测试，但是最后也没有什么成效。最几年，Web 应用程序发展得如火如荼，所以在去年，就有两个工程师，一个来自于 Google，一个来自于 ThoughtWorks 就在尝试解决 Web 应用程序测试上的这个问题。不过他们的思路和以前不一样，不是想做一个全自动的 UI 测试框架，而是基于 Agile 的持续集成和持续部署的概念上，使用半自动的方法来减少 UI 回归测试的时间，从而减少 WEB 应用程序 UI 回归测试的时间。
来自 Google 的工具是 Dpxdt[1],而来自 ThoughtWorks 的是 Viff[2]. 这两个工具的基本原理都是类似的，只是使用了不同的语言开发，以及适用的范围有点区别。
Dpxdt 是基于 Python 和 PhantomJS[3]开发的一个 Web Service 系统，其中 PhantomJS 可以理解为一个没有 UI 的浏览器。用户使用其提供的 RESTFul API 可以十分方便的对比两个页面，而且它还提供一个功能十分强大的报表系统。对于全部是静态页面的 Web 系统来说非常适用，不过对于需要手动导航，比如需要进行输入，点击等之后才能进行比较的页面，它现在的版本并不适合。它还提供了一个方式可以把他很方便的部署到 GWS 上，所以对于国内在 GFW 下的用户可以暂时不用考虑这个功能。
Viff 是基于 NodeJS 和 Selenium 开发的一个本地工具。通过编写 JavaScript 代码来调用 Selenium API, 并在真实的浏览器中进行截图比较。所以它比较适合动态的 Web 系统，因为可以编写代码模拟用户输入和点击操作。由于它底层使用的是 Selenium 作为驱动，所以他支持多种浏览器，比如 IE，Chrome，Firefox 等。在最新的 Selenium 中加入了对 Android 和 iOS 的支持，不过现在还不是很稳定，所以 Viff 还支持 Android 和 iOS 上的浏览器测试。如果对你来说搭建多浏览器环境比较困难，比如需要同时测试 IE8，IE9，IE10 等，可以选择 BrowserStack[4]。BrowserStack 是一个商业产品，他同时通过 Web 界面和 API 接口提供多浏览器环境给客户进行 Web 测试，Viff 可以使用期 API 进行进行多浏览器截图。对于 Viff，由于编写 JavaScript 代码也需要一定的门槛，所以对于没有代码能力的使用者在测试静态网页的时候应该选择 Dpxdt，但是如果你有一定的代码能力，建议选用 Viff。现在 Viff 正在开发 Web Service 功能，这样以后就可以作为一个 Service 进行部署和使用。
不过现在这两个工具都还不是很成熟，还存在一些 Bug，其中 Viff 还在继续开发新的功能中，不过基本使用还是可以的。如果在使用这两个工具的过程中发现任何 Bug，请通过 Github 的 Issues 跟踪功能来及时反馈给作者，帮助这两个开源系统越来越好。我在 BQConf 上有一个 Perceptual Testing 的演讲[5],有兴趣的可以听一听。
[1]https://github.com/bslatkin/dpxdt
[2]https://github.com/winsonwq/viff
[3]http://phantomjs.org/
[4]http://www.browserstack.com/
[5]http://v.youku.com/v_show/id_XNjQxMzk5OTYw.html
[6]https://github.com/winsonwq/viff/wiki/_pages
移动测试
最近几年由于 iOS 和 Android 设备越来越普及，移动应用的出现了井喷，大部分都是个人开发者或者小型公司开发的个人应用或者手游。而且随着 iOS 和 Android 的设备和 SDK 的初步成熟，大量的大型商业公司已经或者准备开发移动应用。对于商业移动应用，稳定性非常重要。对于稳定性，测试就非常重要。由于智能系统越来越复杂和成熟，其上面的应用程序的功能也越来越多，所以自动化测试也就越来越重要。自动 iOS 在 2007 年和 Android 在 2008 年发布以来，基于这两个系统的自动化测试工具就初步发展起来。一般情况下最好使用和应用程序开发使用的语言来写功能测试，但是由于商业应用的业务需求越来越复杂，所以我倾向于使用基于 BDD 和 SBE 的测试工具来做业务测试。比如 Calabash[1]就是一个十分好用的基于 Cucumber[2]的 BDD 移动测试工具，它同时支持 Android 和 iOS。其 Android 的实现是基于 robotium[3]，而 iOS 的实现是基于 Frank[4]和 UISpec[5]。使用 Calabash，测试人员可以使用自然语言来编写的 cucumber 测试脚本，然后通过在 PC 上运行 cucumber 脚本来测试 iOS 和 Android 设备上的应用程序。如果你的公司拥有大量的手动测试人员，并且希望进行移动自动化测试，ThoughtWorks 针对这样的公司开发了一套全新的移动自动化测试工具：Lever，他和 Calabash 一样，同时支持 Android 和 iOS。测试人员只需要通过打开一个网页，通过选择移动应用界面上的特定组件和对其的操作来进行组成自动化测试步骤，多个测试步骤可以形成一个测试场景，最终完成各种自动化测试案例并运行。由于 Lever 不是开源产品，也没有公开的详细资料，所以如果你想了解其详细功能和内容，可以 BQConf 上的 Lever 的专题演讲[6]。
对于最新版的 Android 4.2 系统，由于 Google 使用了新的测试基础控件 Google’s UiAutomator，导致 Calabash 并不适用了。最近一个新的开源项目 APPIUM[7]支持这个最新版的 iOS 和 Android 的自动化测试。由于 APPIUM 出来不久，还需要一定的观察期，我也会一直关注其进展。
[1]https://github.com/calabash
[2]https://github.com/cucumber/cucumber
[3]https://code.google.com/p/robotium/
[4]https://github.com/moredip/Frank
[5]https://code.google.com/p/uispec/
[6]http://v.youku.com/v_show/id_XNjQxMjgzMTk2.html
[7]http://appium.io/
Web 服务器性能测试
敏捷开发在当今软件行业里面扮演着越来越重要的角色，软件测试也随着逐步敏捷起来。由于软件系统，特别是服务器系统越来越复杂，规模也越来越大。开发人数也达到几十，甚至几百人，而且大规模使用第三方的软件库，比如 Spring，Rails，Hibernate，.Net 等。如果使用不当，将会引起很严重的性能问题甚至是稳定性问题，所以性能问题在当前的软件开发中已经越来越明显了。常规的持续集成验证了构建是否满足了功能设计要求，而持续性能测试增加了另外一重验证标准，程序是否满足了性能要求，从而是性能问题尽早被发现。持续性能测试主要的优点就是可以在代码改变以后可以快速的知道性能变化，比如如果发现性能问题，可以让提交这个 Commit 程序员去修复这个问题，因为他还能记住这个 Commit。如果等到最后发布之前才发现，那么这个程序员可能已经不记得这个 Commit，或者已经离开了公司，有可能导致修复这个问题的难度大大增加。如果这个是一个设计上的错误，那么团队就可以尽早修复它并避免以后的功能受其影响。
比如铁道部的 12306 购票系统上线后的第一个春节就遇到了严重的性能问题，面对预料中的高访问量，系统在春运期间经常长时间无法访问，导致大量用户无法购票。像这样严重的性能问题是在开发的时候是可以预见的，不过还是出现在产品环境上，由此可见系统在构架上没有对性能进行有效的设计，在测试上没有进行有效的性能测试（由于 12306 产生这个性能问题的原因很复杂，我们这里不做过多讨论，比如各种组织和利益等原因，也不讨论怎么解决。）。当这个性能问题出现的时候，根本无法在短时间内修复，导致了如此严重的性能问题维持了很长一段时间。在第二年的春运里面，系统才增加了排队系统，有效的缓解了性能问题，不过还是会时不时出现无法访问的情况。由于 12306 是中国唯一的网上火车票购票系统，就算出现这样严重的性能问题，人们还是只有继续使用它。但是如果有多个购票网站，一旦某个出现了性能问题而导致客户长时间无法访问，那么就会带来大量的客户流失，造成巨大的损失。因此性能测试对拥有大量用户软件系统十分重要，而且需要越早发现性能问题，越早修复越好，因为等到发布前，就算测试出性能问题，也有可能因为构架问题而无法修复。
让性能测试成为敏捷开发的一等公民对于更好的进行敏捷开发和高质量的持续部署越来越重要。持续性能测试不应该只是说说，特别是对于大型服务器项目和开发人员众多的情况下，持续性能测试将成为必不可少的组成部分。持续性能测试应该被看做持续交付的重要步骤，应该和回归测试一样，可以做到更频繁的高性能持续交付。在 2013 年 5 月发布的 ThoughtWorks 技术雷达中，让性能测试成为敏捷开发一等公民已经被列入了 ADOPT [1]。对于当今的软件系统，特别是对于大型服务器系统，并且它又拥有大量用户的情况下，持续性能测试将成为一个必不可少的组成部分。让我们一起去实践持续性能测试，比如新一代的性能测试工具 Gatling [2][3]就是一个很好的试验田，通过它，我们可以很好的实践对于服务器系统的持续性能测试。
[1]http://www.infoq.com/cn/articles/thoughtWorks-technology-radar
[2]http://gatling-tool.org/
[3]http://www.infoq.com/cn/articles/new-generation-server-testing-tool-gatling
Web 自动化功能测试
在过去几年，由于 Web2.0 的出现导致了 Web 的第二春的到来，并且我知道的公司和客户们都非常重视 Web 自动化测试，并且使用率也很高。但是我发现很多测试人员还在使用 Selenium IDE[1]或 QTP 等。对于 Selenium[2]，我认识的一般的测试人员只会使用 Selenium IDE 进行测试录制，然后使用“重播”进行测试。对于通过 Selenium IDE 录制的脚本是非常难以维护的，导致测试步骤的更改之后一般只能重新录制。对于开发中的项目的其 Cost 非常高，所以在实际中使用的效果很不好。
对于当前广泛使用的 Agile 的开发模型，Selenium IDE 的方法基本不可用，所以需要更新到 Selenium WebDriver（Selenium 2.0）[3]。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[4]。Watir 是一个使用 Ruby 开发的测试 API，和 WebDriver API 类似，而且它自带和 Rails 集成的组件，所以对于 Rails 的 Web 系统它有天生的优势。
由于 Web Service 的流行以及用户 UI 的需求越来越复杂，Web 开发已经由 MVC 的模型发展到 MVP 和 MVVM[5]模型。由此一来前端的逻辑复杂程度和代码量（如 Javascript 等）就会大大增加，由此带来的问题就是测试量也会大大增加。对于如此大量的 Javascript 代码逻辑层的测试，并不适合使用做 UI 层功能测试的 Selenium。所以我们应该在 Javascript 层做自动化测试。基于 Javascript 的自动测试框架很多，由于我倾向于 Agile 和 BDD，所以我倾向于 Jasmine[6]，Mocha[7]和 Karma[8]。其中 Jasmine 是一个支持 BDD 的自动化测试框架，而 Macha 是新的基于 NodeJS 开发的支持 BDD 的自动化测试框架。而 Karma 是一个自动化测试运行环境，它也是基于 NodeJS 开发的，Jasmine 和 Macha 都可以在其上面运行。Karma 支持多种 browser，比如 Firefox，Chrome， IE 等，而且它使用也比较简单。
[1]http://docs.seleniumhq.org/projects/ide/
[2]http://docs.seleniumhq.org/
[3]http://docs.seleniumhq.org/projects/webdriver/
[4]http://watir.com/
[5]http://www.codeproject.com/Articles/66585/Comparison-of-Architecture-presentation-patterns-M
[6]https://github.com/pivotal/jasmine
[7]http://visionmedia.github.io/mocha/
[8]http://karma-runner.github.io/0.10/index.html
Windows 应用程序测试
虽然 Web 从上个世纪 90 年代开始崛起，到现在的空前盛世，但是任然有很多公司仍在开发和维护 Windows 应用程序。并且 Windows 应用程序的开发也从 C 和 MFC 时代进入了.Net 和 Silverlight 时代。但是 Windows 应用程序的测试一直都是一个不大不小的问题，虽然有很多商用且成熟的自动测试系统，比如 Test Complete[1]和 QTP 等，不过大部分是基于录制或者 Action 模型来创建测试，更没有提供现代流行的脚本支持，比如 QTP 使用的是 VBScript，更不用说 BDD 的支持。在 Agile 的时代，测试工具 API 化才是一个正确的选择，如果能支持 DSL 那就更好了。使用 API 后，可以获得良好的可维护性，并且可以更为容易实现 CI 和 CD。幸好有一帮志士开发了一套针对 Windows 应用程序的免费自动化测试框架 White[2]，以及.Net 的 BDD 框架 SpecFlow[3]。White 封装了 Microsoft's UIAutomation Library，并提供了一套简单易用的 API。它支持 Win32, WinForms, WPF, Silverlight and SWT (Java) platforms 的应用程序，并且通过 MicroSoft Windows SDK 里面的 Inspect[4]工具可以非常容易的找到应用程序中 UI 控件的 ID 来进行自动化测试。
[1]http://smartbear.com/products/qa-tools/automated-testing-tools/
[2]https://github.com/TestStack/White
[3]http://www.specflow.org/
[4]http://msdn.microsoft.com/en-us/library/windows/desktop/dd318521(v=vs.85).aspx
Web 应用系统安全
安全，一个即神秘又兴奋还忧心的话题。其中安全世界里面的东西太多太多了，比如服务器安全，移动安全，网络安全，杀毒软件，入侵检测等等，不过今天我只想说说 Web 的安全。Web，在前面我已经用了各种的词汇来描述它的现状。正是由于它当前这种现状，我们不得不特别关注它。所以有一批黑客发起了一个关注 Web 安全的公益性项目 OWASP(Open Web Application Security Project)[1]。在这个项目里面，有各种关于 Web 安全的资料，比如文档有《OWASP 安全编码规范快速参考指南》，《OWASP 测试指南》 和 《OWASP 安全风险 Top 10 》2013 年版[2]等, 以及各种安全测试和培训工具，比如 ZAP[3]和 WebGoat[4]等。其中 ZAP 是一款简单易用并且免费的 Web 安全扫描工具，使用在针对网站渗透测试过程中的检测网站步骤中，并且很容易的和 maven 以及 CI 进行集成。由于它是由 java 开发的，所以也支持多种操作系统，比如 Windows 和 MacOS 等。而 WebGoat 是一个漏洞百出的 J2EE Web 应用程序，这些漏洞是故意设计用来演示 Web 应用程序安全课程的。这个应用程序提供了一个让用户可以真实去实践和学习的平台，让用户可以真实看到漏洞以及尝试去修复这个漏洞。
除了上面介绍的免费工具和练习平台以外其实还有很多其他的免费和商业版本的工具和平台，比如 w3af,Burp,metasploit,Google’s Gruyere 等。我暂时还没有用过这些，有兴趣的同学可以自己去学习研究。最后如果大家想学习和使用这些工具，并练习 Web 的安全问题，比如 OWASP Top 10，可以使用 Maven 公司的 Web Security Dojo[5]就可以非常方便的进行。
[1]https://www.owasp.org/index.php/Main_Page
[2]https://www.owasp.org/index.php/Top_10_2013-Top_10
[3]https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
[4]https://www.owasp.org/index.php
/Category:OWASP_WebGoat_Project
[5]http://sourceforge.net/projects/websecuritydojo/
总结
对于测试人员，需要了解各种测试方法，测试策略和测试工具，随着软件行业的迅速发展也需要更新它们，比如视觉感知测试, 移动测试，性能测试等等。但是随着敏捷开发和敏捷测试越来越普及，持续集成和持续部署的广泛使用，以及 TDD 的兴起，学习脚本将会成为测试人员的一门必修课。不要再犹豫了，更新自己吧，要知道不进则退哦。
