软件自动化测试概述

自动化测试概述
所谓的自动化测试简单来说就是有计算机代替 人来单击被测软件的界面，执行一系列操作并进行验证。
自动化有点：通过执行自动化测试，可以节省大量的人力、时间或硬件资源，同时也能大大提高测试效率。
自动化虽好，但是不是适应与任何测试，自动化测试满足以下条件：
1）软件需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改和调试，必要的时候还要修改自动化的测试框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
项目中的某些模块相对稳定，而某些模块需求变动性很大，可以对相对稳定的模块进行自动化测试，而变动较大的仍然采用手工测试。

2）项目周期足够长
自动化测试的过程包括自动化测试需求的确定 ，自动化测试框架的设计、测试脚本的编写和调试等，这个过程本省就是一个测试软件的过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试也是没有意义的。

3）自动化测试脚本可以重复使用
如果费劲心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使期间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而非是真正可以产生效益的测试工具了。

自动化测试的流程
自动化测试与软件开发的过程从本质上来讲是一致的，无非是利用自动化测试工具，经过对测试需求的分析，设计出自动化测试用例，从而搭建自动化测试框架，设计与编写自动化脚本，测试脚本的正确性，从而完成该套测试脚本，然后投入使用执行测试。
自动化测试一般按照以下流程执行
1、分析自动化测试需求
简单来说就是当测试项目满足自动化的前提条件了，并确定在该项目中需要使用自动化测试时，便可以开始自动化测试需求分析。此过程需要确定自动化测试的范围，以便于建立自动化测试框架。

2、制定自动化测试计划
在展开自动化测试之前，最好做一个测试计划，明确测试对象、测试目的、测试的项目内容、测试方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。

3、设计自动化测试用例
通过测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能够用自动化的方式来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。用例的设计分为两个方面，一方面是自动化测试所需要的执行的操作和验证，另一方面是测试所需要的数据。

4.搭建自动化测试框架
自动化测试框架类似于软件开发中的基础框架，主要用于定义在开发中将要使用的公共内容。根据自动化测试用例，很容易能够定位出一下自动化测试框架的典型要素。
1）公用对象
不同的测试用例会重复使用一些相同的对象，例如窗口、按钮、页面等。这些公用的对象可以被抽取出来，在编写脚本时随时调用。当这些对象因为需求的变更而改变时，值需要修改该对象的属性即可，而无须修改所有相关的测试脚本。
2）公用的环境
各测试用例会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。
3）公用的方法
当测试工具没有需要的方法，而该方法又会被经常使用时，便 需要自己编写该方法，以方便脚本的调用。
4）公共测试数据
也许多个测试 用例需要多次使用某个测试数据，可以将这类测试数据放在一个独立的文件中作为公共测试数据，有测试脚本执行到该用例时读取数据文件。在测试用例中抽取出的公用的元素放入已定义的文件，设定好调用的过程。

5、编写自动化测试脚本
在公共框架开发完毕之后，即可进入 脚本编写的阶段，根据自动化测试计划，将之前所写的自动化测试用例转化为自动化测试脚本。自动化测试用例就像软件开发中的详细文档设计，用于指导自动化测试脚本的开发。

6、分析自动化测试结果
接下来就是执行自动化测试了，一般来说，自动化测试多用于毛岸测试或回归测试。在每次新功能上线后，都要执行自动化测试，及时分析测试的结果并发现缺陷。如果发现Bug，应及时记录到相应的管理工具中，并持续追踪该Bug，直到它变为关闭状态。

7、维护自动化测试脚本
这是一个重头戏，也许前面所有的工作量加起来都没有维护所用的时间成本大。一个软件可能会多次上线新功能，或对旧的业务进行更改。那么这将设计新脚本的添加或就脚本的修改，一适用变更后的系统。所以在早期选好自动化的测试范围就显得至关重要。
低下附一张从51Testing截下来的，给大家一个更加直观的介绍

下面分享领测链接，里面记录了一个较早时间从事软件自动化测试人员分享的他的故事和一些建议
http://www.ltesting.net/ceshi/ceshijishu/zdcs/2012/0110/203891.html