谈谈自动化测试（一）

大学毕业后，我进入了H公司的测试部，从事灰盒测试工作，业务上全是协议，协议一般上是标准的，因此所有测试都可以有很明确的输入输出，存在二义性的可能性是极少的，测试用例做到100%自动化，部门在那几年也是在H公司测试实力最强的，大量其他测试部门来到本部门取经。一度我们的测试部技术上都能达到架构师的水平，最次达到SE的层次，每次做项目都是测试先行，测试驱动开发的模式开展工作。在自动化测试方面我们积累了自己的一系列工具，各种测试指导书，后来我们甚至有了测试用例自动生成工具，测试建模，基于风险的测试技术等。

2年半前，我加入了D公司，重点进行自动化测试尝试和实践，虽然此项工作进行了4-5个月，有一定的起色，但从现在看，个人认为自动化测试实践是失败的，并且短时间内在D公司不会有大的进展，这和行业特点，公司历史技术架构，开发设计能力，测试人员技能等有重大关系，以后我再慢慢聊。

测试界大师Jamesbach对自动化测试有这样的定义：

Test automation is any use of tools to aid testing。 注意是帮助测试的工具。我认为这是对自动化测试的较好的定义。同样，百度百科有如下定义：

自动化测试一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件；自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

在测试业界，大体会有狭义的理解和广义的理解，狭义的理解认为自动化测试是指测试脚本的开发与执行，利用脚本模拟手动测试步骤，控制被测系统的执行，完成全自动(不需人工干预)或半自动测试(部分人工干预)的过程。广义的理解认为软件测试活动的自动化，包括测试分析设计，结果分析等的自动化，测试脚本的开发与执行。

看完这些定义，返回测试的本质，如下图：

test_essential

实际上测试是对系统进行一定的激励（输入），进而通过预期输出和系统的响应（实际输出）的对比给出判决结果的过程。那么自动化测试需要做什么呢?

1. 构造输入
2. 给出预期输出
3. 判决结果

这3点是狭义的理解自动化测试要素。从广义理解看，围绕这3点形成的各种工具，加上测试用例设计和组织管理等工具基本上构成了自动化测试的范畴。