atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[Thinking different]]></title>
  <link href="http://raulhu.github.io/atom.xml" rel="self"/>
  <link href="http://raulhu.github.io/"/>
  <updated>2014-09-07T21:26:52+10:00</updated>
  <id>http://raulhu.github.io/</id>
  <author>
    <name><![CDATA[YaoHu]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[6ways To Speedup Testing]]></title>
    <link href="http://raulhu.github.io/blog/2014/08/31/6ways-to-speedup-testing/"/>
    <updated>2014-08-31T00:00:00+10:00</updated>
    <id>http://raulhu.github.io/blog/2014/08/31/6ways-to-speedup-testing</id>
    <content type="html"><![CDATA[<h1>6 ways to speed up your tests 【译】</h1>

<h2>概要</h2>

<p>在现代的软件开发实践诸如敏捷实践中，测试自动化是必不可少的。随着项目代码的日益增多，自动化测试集也会变得越来越庞大，自动化测试用例的健壮性也越来越重要，有时候测试执行的速度成为软件发布的瓶颈，这是许多团队都会面临的问题，但是通过对自动化测试集进行有效的改善，就可以避免这个问题。我们是这么做的：</p>

<h3>1 - 识别不可靠的测试用例</h3>

<p>什么是不可靠的测试用例？</p>

<p>让我们从项目中找出一个典型场景: 为了可以提交你的代码，你已经花了几个小时等构建工具构建出一个成功的版本，结果发现是因为有自动化测试脚本失败了，你决定修复这些失败的测试脚本。当你重新执行这些自动化测试用例时，它们全部都通过了。这类测试执行会随机失败的，当没有任何代码修改，重新执行又通过的测试用例称为不可靠的测试用例。</p>

<p>不可靠的测试用例会破坏自动化测试的稳定性，只有当自动化测试执行稳定时，自动化的价值才会体现出来。因此，我们的首要任务是让构建过程顺利，重拾我们对自动化测试脚本的信心。有如下的步骤可以参考:</p>

<p>隔离不可靠的测试 -> 分析原因 -> 修复不可靠测试 -> 持续关注</p>

<h3>2 - 将测试归类</h3>

<p>另一个快速得到测试结果的方法是将测试集划分成不同的种类，可以按照测试的功能点划分，或者按照测试的类别划分，诸如冒烟测试，是测试应用程序的基本功能和关键业务；而回归测试是会覆盖所有的业务和功能点。</p>

<p>冒烟测试建议在每次提交后执行，而回归测试可以在多次提交或者每隔一段时间后执行，这样我们可以确保每次提交只运行最核心的测试用例。</p>

<p>如果将测试归类需要耗费大量时间，那么还有一个方法是并行的运行测试用例。目前市场上有很多并行运行测试的工具，诸如Selenium grid, Test Load Balancer。通过并行运行，测试执行的时间会大大缩短。</p>

<h3>3 - 灵活的创建测试数据</h3>

<p>“一个好的自动化测试应该是能够创建数据并且在使用后恢复数据的测试”</p>

<p>我们应该避免花在创建测试数据上的时间比创建测试本身的时间还要多的情况。很多web自动化测试都是用过浏览器来创建测试数据，实际上直接在数据库里创建数据会有效得多。通过减少与用户界面的交互，测试会变得更快速和有效。</p>

<h3>4 - 使用有条件的wait方法</h3>

<p>在Web自动化测试里，当有页面跳转或者我们等待异步调用结束时，我们通常会使用Wait方法。这些wait方法会让测试变慢，并且让测试变得不稳定。我们可以将固定的wait方法替换成有条件的wait方法，诸如当页面加载成功时，wait方法结束；或当一个控件定位成功时，wait方法结束。有条件的wait方法会在特定的操作开始或者操作结束后执行。</p>

<h3>5 - 有效利用单元测试</h3>

<p>测试金字塔告诉我们在金字塔的底层（单元测试）添加更多测试，而在金字塔的顶层（UI测试）添加尽量少的测试。金字塔底层的单元测试执行速度会比界面测试的速度快的多。一些操作诸如验证下载文件，在浏览器里测试会很耗时并且较复杂。单元测试可以利用虚拟的数据有效地测试某些功能。通过识别测试层级，并且更多的创建金字塔底层的测试会让测试执行更迅速。和开发人员一起审查单元测试，可以避免在不同的测试层级上创建重复的测试用例。</p>

<h3>6 - 合理使用xpath</h3>

<p>在Web自动化测试中，经常需要定位某个元素。我们很少意识到定位器的选择会大大影响测试执行速度。当我们使用xpath进行对象识别时，很多后台处理和过滤会被执行。通过<a href="http://link.springer.com/chapter/10.1007%2F978-3-540-24607-7_2">这里</a>我们可以了解到xpath是怎样被执行的。
xpath比其他的对象识别方式速度都要慢。因此，在对象识别时建议使用直接的属性比如ID,名字等，你也可以使用CSS选择器代替xpath。</p>
]]></content>
  </entry>
  
</feed>