全国咨询热线：136-9172-9932
自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具(相当于软件开发工具)，经过对测试需求的分析(软件开发过程中的需求分析)，设计出自动化测试用例(软件开发过程中的需求规格)，从而搭建自动化测试的框架(软件开发过程中的概要设计)，设计与编辑自动化脚本(详细设计与编码)，测试脚本的正确性，从而完全该套测试脚本(即主要功能为测试的应用软件)，然后投入使用以执行测试(用户使用，只不过这里的用户一般是测试人员)。
自动化测试一般按以下流程执行。
当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，便可以开始进行自动化测试需求分析。此过程需要确定自动化测试的范围，以便于建立自动化测试的框架。
在展开自动化测试之前，最好做个测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。
通过测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化方式来执行，所以需要将能够执行自动化测试用例汇总成自动化测试用例。用例的设计分为两个方面，一方面是自动化测试所要执行的操作和验证，另一方面是测试所需的数据。
自动化测试的框架类似于软件开发过程中的基本框架，主要用于定义在开发中将使用的公共内容。
根据自动化测试用例，很容易能够定位出以下自动化框架的测试框架的典型要素。
不同的测试用例会重复使用一些相同的对象，例如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变化而变化时，只需求修改对象的属性即可，而无需修改所有的相关的测试脚本。
各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活使用，也能增强脚本的可维护性。
当测试用例没有需求的方法，而该方法又会被经常调用时，便需要自己编写改方法，以便脚本的调用，例如Excel读写、数据库读写、注册表读写等公共方法。
也许多个测试用例需要多次使用某个测试数据，可将这类测试数据放在一个独立的文件中作为公共测试数据，有测试脚本执行到该用例时读取数据文件。
在该框架中需要将这些数据字典要素考虑进去，在测试用例中抽取公用的元素放入已定义的文件，设定好调用的过程。
在公共框架开发完毕后，既可以进入脚本编写的阶段，根据自动化测试计划，将之前所写的自动化测试用例转换为自动化测试脚本。自动化测试用例就像软件开发中的详细设计文档，用于指导自动化测试脚本的开发。
接下来就是执行自动化测试了，一般来说，自动化测试多用于冒烟测试或回归测试。在每次新功能上线后，都需要执行自动化测试，及时分析测试结果并发现缺陷。如果发现了Bug，应及时记录到相应的管理工具中，并继续跟踪改Bug，直到它变为关闭的状态。
这是一个重头戏，也许前面的所有工作量加起来都没有维护所用的时间成本大。一个软件可能会多次上线新功能，或者对就得业务进行更改。那么这将涉及新脚本的添加或就脚本的修改，以适应变更后的系统。不幸的是，软件不出现变更，就没有自动化测试的必要。如果出现变更，就得花时间成本进行维护，新需求永远是自动化测试的最大麻烦，所以一定要在早期就选好自动化测试的范围。
