自动化测试概况和认知

@TOC
《测试架构师修炼之道》是我的一本枕边书，每次看的时候总是有不同的感受。今天来整理下书中提到的自动化测试相关的知识，更多的是概况、认知或者理论方面的东西。

前言

书中说测试架构师掌握自动化测试的目的不是设计自动化架构或是具体来部署自动化，而是用好自动化。其实这一点我觉得对涉及自动化测试的人员都是通用的，只是偏重点不同。

往往自动化测试前期投入成本可能会大一点，比如框架设计、技术选型、人力成本等等，但是这个步调确定好了之后，更多就是怎么去用好自动化，把它和业务结合起来。

书中主要从以下方面开展：

• 建立正确的自动化观念；
• 如何评估自动化收益；
• 自动化工具的选型。

## 1、自动化测试真相
一提到自动化测试，大家很容易就想到 “7*24小时不间断测试”、“反复测试”、“效率高”等等，然而发现，自动化测试做的人多，成功的却不多。其实原因有很多。
### 1.1、自动化并不廉价，相反，自动化很贵

• 开发自动化脚本需要不少时间，往往很多团队部署自动化的原因是因为项目紧，想通过自动化测试提升效率，既然时间都不够用了，哪有时间去开发脚本呢？这无疑于缘木求鱼；
• 自动化测试需要懂技术的人来操作，其过程也是开发代码，也需要专业的人才能胜任此工作；
• 某些自动化工作需要购买和二次开发；

总结为时间成本、技术成本、人力成本，都是自动化测试需要考虑的。所以说它很贵。在部署之前，一定要考虑团队的消费能力。

1.2、自动化脚本往往没有想象中的那么可靠

很多团队部署自动化另一个原因是想通过自动化来验证不会漏掉用例中的步骤，觉得自动化是忠实可靠的。但自动化测试给你的“OK”，可能真的只是幻想，因为脚本只会按照指定的步骤去运行和确认结果，不会去捕捉一些突发异常（至少不能全面的捕捉）。
另外，自动化工作或者环境可能并不是那么可靠。
无论是正确的自动化测试结果，还是错误的自动化测试结果，都需要人再去确认。

1.3、自动化测试不是单靠测试就能搞定的事儿

自动化测试需要SE、开发、测试、自动化工程师紧密配合才能有效运作起来。开发自动化脚本之前有很多先决条件：

• “需求”要确定清楚，特别是用户的数去和输出，一定要确认清楚，这时候SE就要给力些；
• “UI”后者“命令行”需要确定下来，而且确定了最好不要随随便便修改，这样才利于自动化脚本中的一些“中间层”的设计，这需要开发给力；
• 测试用例要尽快写出来，这需要测试给力。

## 2、如何评估自动化收益？

2.1、自动化测试的实施成本

公式：自动化实施成本 = 前期开发成本 + 后期的维护成本

2.1.1、前期开发成本

• 人力成本：和自动化开发人员相关的费用成本；
• 时间成本：自动化准备时间，自动化脚本开发、调试的时间成本；
• 金钱成本：工具购买、开发、维护的费用成本。

#### 2.1.2、后期维护成本

• 产品变更引起的自动化测试脚本变更的成本；
• 定位、修复自动化运行环境引起的脚本的健壮性问题的成本；
• 定位、修复自动化运行环境引起的可靠性问题的成本；
• 其它未知的引起测试脚本变更的因素引发的成本。

### 2.2、自动化测试的运行次数

自动化测试的收益和自动化测试运行的次数是成正比的，脚本能够被运行的越多，自动化测试的收益才会越高。

公式：自动化测试的收益 = 自动化测试运行的次数

2.3、自动化测试实施成本

计算公式：p = (k*n) / (c1+c2)

k : 手工执行自动化用例所花费的时间成本；
n ：自动化测试用例执行的次数；
c1：花费在自动化测试前期的成本（时间成本 + 人力成本 + 金钱成本）；
c2：花费在自动化测试后期的成本（时间成本 + 人力成本 + 金钱成本）；

3、自动化测试工具介绍

3.1、单元测试工具

• Parasoft系列单元测试工具

• Compuware系列单元测试工具

• Xunit系列单元测试工具

3.2、UI自动化测试工具

3.3、性能自动化测试工具

注：本文内容主要来源于《测试架构师修炼之道》刘琛梅·著，版权归作者所有，本文只是整理汇总成学习笔记，如有问题，请联系删除，谢谢。