首先，我们要统一一个概念，被测试的页面是由HTML、CSS和JS所组成的。而Spider的应用，是可以用来快速的进行HTML的检查和遍历，但是对于CSS和JS就有其局限性了

通过Spider其实很容易的获取到了所需要测试的页面的HTML，然后采用正则表达式的方式去获取所需的页面对象。因为HTML是标准的标签格式的，所以，获取起来也是比较方便的，然后根据标签的属性，比如ID，Class可以对对象进行区分，这就有些类似于一般的自动化测试对象，对GUI的SPY了。既然有了对象，然后对对象的内容或属性进行检查也是很方便的。

这样做的好处是将HTML整个作为文本来处理，操作简单。

以下是C#的示例，以获取页面上所有的链接对象：

     //获取页面HTML并保存到Page

     Regex regex = new Regex("<a[^>]+>");
     MatchCollection mc = regex.Matches(page);
    
     //mc中包含了结果对象，可以分别进行处理

利用同样的方式，我们还可以获取页面上Div、Button、Text的对象，并且对其内容进行进一步的检查

有人会说，看上去和QTP，Selenium等有异曲同工之处，而且，似乎要去搭建这样一个Framework还是比较麻烦的，为什么要这么做呢。其实这里有一个很大的优点是其他自动化工具不能做到的，即Spider可以多线程进行工作。我们是不是经常会碰到QTP，Selenium工作时，占用了当前进程，以致我们只能等待，并且一旦测试的内容海量，我们还得等很长的时间呢？Spider多线程的优势就在这里了

在下认为，对于WEB的测试，利用Spider的方式，能够很大的提高测试效率的

Spider，其实就是抓取网页的爬虫，大部分搜索引擎都会使用Spider来做数据源的收集。这真是一个很好的设计，那么好的设计我们是不是也能拿来在测试中使用一下呢。

其实，目前还是有很多检查链接有效性的工具，诸如LinkBot等都是采用了Spider的概念来达到测试的目的的

那么我们就将这个思想再扩展一下。在互联网网的应用中，页面的数量一向是超级繁多的，我们在平时的测试中也很难做到各个页面都去检查，特别是一些小逻辑或UI的改动，我们一般是利用等价类的方法论来做一些抽样的测试，但是这样的测试其实是不充分的，碍于成本和产出的失比，我们不会去测试过多的等价类。

但是利用Spider的概念就可以很好的解决这种GET的问题了（当然POST的测试解决起来比较困难，还是建议采用“半自动化”），而且Spider可以进行多种行为控制，也是一种很灵活的应用。对于结果的分析，最简单的无非对于HTTP.STATUS的检查，那样很容易发现一些由于数据或者配置造成的异常。如果更进阶一步，可以Parse Spider获取到的Stream以精确地检查结果

今天正巧，公司正巧在51testing上挂了招聘启事，正巧被一个许久未联系的老同事看见，就顺便正巧找在下聊下天，又正巧的聊到了我那篇烂作“半自动化测试”。

对于测试人员，特别是.com的测试人员来说，提起“自动化测试”，那真是爱恨交加。个中缘由这里就不累述了，大家同道中人自然是体会深刻。时常会想，既然我们有“灰盒测试”的概念，为何不能有“半自动化测试”呢？

其实此处讲的“半自动化”的概念，归根结底就是：测试步骤自动化，结果检查人工完成。

目前比较流行的自动化测试框架也好，工具也好，在下觉得都未提供一种足够强大、灵活的结果检查方式。而测试人员在编写自动化测试脚本的时候往往需要把绝大多数精力投入到如何去判断测试结果的正确性上，特别是web的自动化测试，几乎无法面面俱到，甚至会遇到需要编写复杂的算法来验证结果的情况。反之通过手工肉眼去判断测试结果就来得方便的多，也直观的多。

再回过头去看测试框架和工具，本身自动化测试的宗旨就是大大减少繁复而枯燥的人为操作，岂不就是输入、点击等测试步骤嘛。通过获取操作对象，利用测试数据驱动，来完成自动化过程。这个过程就是自动化工具的长处了，脚本的编写也相对简单很多。利用这些特性，很方便的就能完成测试输入的自动化了。

当然这只是我们“半自动化”的一半，嘿嘿，四分之一自动化。利用测试框架的特性，我们大可以将一些测试输入封装，测试对象抽象。这样在对待同类型对象时又方便了很多，实例化就OK啦。由此我们已经基本解决了大部分对象的测试输入自动化的问题。设计好测试数据，数据——对象——输入，中断——检查——报告，done，半自动化了。

PS.开博第一篇，提供一些在下实际工作中的体会，与同道们分享，工具框架其实都是自动化测试的表象，好的适合自己的方法才是自动化测试的精髓。我们的目标是：用最简单的方法，做最复杂的测试。