自动化测试理解

1 定义

把以人为驱动的测试行为转化为机器执行的一种过程。

• 简单讲：比如使用自动化测试框架、脚本、工具等自动打开测试对象（引用），自动去执行测试用例（此过程中包含自动化查找元素、控件等），自动输入测试数据、自动生成测试报告等一系列的自动化过程；
• 通俗讲：用机器来模拟用户的实际行为，如键盘、鼠标等操作，来达到预期。

2 做自动化的目的是什么？

• 测试工作量比较大，使用自动化来完成一部分工作；
• 测试过程有大量重复的工作，使用自动化来进行提升效率；
• 手工测试难以覆盖的场景，需要自动化造数据等来完成；
• 有些测试结果，可能自动化比手工更为精确。

3 自动化测试的优缺点

优点	缺点
重复执行、频繁操作	不能100%替代人工测试
模拟手动测试无法覆盖的场景	不能达到100%覆盖率
利用空闲时间执行	需要时间去分析结果
释放一部分测试人员精力	对软件质量依赖大（前提是软件稳定、改动小等）
测试结果客观公正	需要专业的工程师投入专门的时间开发
/	投入成本可能会大一些

4 自动化测试的前提条件（重要）

即做自动化前先对软件进行分析，是否满足或者要不要做自动化，有几个前提条件需要注意。

4.1 需求变动不频繁

• 脚本的稳定性最直观的决定要素是需求的变动，如果需求变化大，隔三差五的进行需求更改，那脚本势必也要进行同步更新，这样投入的维护成本就很大，得不偿失，还不如不做。

4.2 项目周期比较长

• 自动化测试和普通的测试一样，需要前期的规划、框架设计、脚本开发、人员选择、脚本执行、后期维护以及结果跟踪分析等，是一个比较全的且投入较多的一个过程，如果项目周期很短，就不适合做自动化，其实也没必要；
• 另外项目周期短，手动测试都无法保证的前提下，更不用谈及做自动化了。

4.3 脚本的重复使用率高

• 我们投入了较大的人力、物力、财力等最终完成了一套比较完美的自动化脚本、框架或者平台，但是复用率很低，只能在单个产品单独使用，那么这样的代价就太大了。此时我们需要评估是否必须要进行自动化测试，如果非必须，可以不做；
• 相反的，如果自动化的一系列东西都能迁移到其他的产品测试，那这样的投入是值得的，也是必要的。我们也应该投入更多的精力进行测试开发。

4.4 团队实力

• 做自动化，不是随便摘抄一些代码拿来用，他是一个专项测试，需要投入专门的人力去研究及测试，那么我们要想做好自动化，先要对自己的团队进行评估，团队的人员、技术能力等是否满足要求；
• 另外，自动化需要不断的进行迭代和优化，不能拿着脚本运行看看结果，那其实很多时候，并不能给产品带来客观的价值。我们需要进行不定期的升级维护，针对项目业务要进行优化，根据测试过程和结果的数据反馈要进行稳定性的升级等等。所以这也需要专门投入人力进行研究。

4.5 部门的规划和上级的支持

这个是我加的，根据个人的经验的总结；

• 部门的规划：如果自动化是在部门规划中，以及有考核目标，那肯定是要做的。如果不是规划，也没有纳入计划，那就要根据实际情况定，毕竟这不会直接影响你团队的实际考评。你的重点应该是在其他的地方，优先保证工作重点内容的完成；
• 上级的支持：这个很重要，做自动化无非是为了提升效率和质量，但是如果没有得到应有的效果，领导看不到成绩，也无感知，那么做自动化也许不会长久。这个得慢慢体会了，哈哈。

5 应用场合

自动化测试主要应用在以下场合，具体还要根据项目以及自动化的实际开发情况开定：

场景	说明
测试周期	项目周期长，轮次较多的软件
数据量级	需要制造大量的测试数据
软件稳定性	使用稳定和成熟阶段的产品测试
回归测试	需要进行简单回归的测试
冒烟测试	主线功能的冒烟
巡检测试	线上环境的定期巡检
发布验证	主线功能的发布验证测试

6 自动化认识误区（重点）

6.1 自动化可100%覆盖

• 概率不大，要使得自动化的测试覆盖率达到100%，需要投入专门的人力、物力、财力等，成本比较大；
• 某些业务的特殊性，或者场景的复杂性，用自动化是无法进行覆盖的；
• 项目的周期限制，不允许投入更多的精力去开发；

6.2 自动化可替代人力

• 领导的口头禅：你就告诉我，自动化能干掉多少人力？！====每次听到这样的话，不知道你们怎么想的，反正我是很无奈。但从领导的角度来思考，也不为错；
• 这里存在一些误区，自动化测试是辅助功能测试的，或者说是为了解决某些人工不能覆盖的场景；
• 另外，不存在完完全全的自动化，都是需要人工参与的；
• 遇到类似的认识，建议自动化测试人员需要进行解释，不能任由这个观点滋生，不然===你猜会咋办！！

6.3 自动化很牛逼

• 任何的事情，都是看谁先知道而已，与其说牛逼的技术，不如说牛逼的人。
• 自动化只是一门技术，我们不能脱离业务搞自动化；
• 很多人认为自动化很厉害，就脱离了工作的重心，天天喊着自动化、自动化，最后到头来啥也不是，啥也没得到。当然如果是专业、专门搞自动化测试开发的那就另说了。因为他们的工作就这，就是转、精。

6.4 万物皆可自动化

• 这个其实和前边的提到的一致，搞自动化，先要符合一些前提条件以及明白他的应用场景，不是所有软件都要搞自动化。
• 盲目的自动化，只会适得其反。

6.4 自动化很简单

• 这是一个很复杂的但是又简单的话题，对自动化的方向、工具、技能等研究的程度不同，对他的认识就不一样；
• 如果只是解决一些简单的问题，你掌握他很简单。如果是复杂的一些东西，可能需要深入研究；
• 自动化方向也是很多，不论是功能、性能，还是面向接口、UI、GUI、协议，更或是自动化工具开发等，都需要不同的技能和知识，入门或许简单，要做的很专一，还是需要点积累的。

6.5 自动化尽早做

不一定。不同的自动化，介入时间可能有差异，比如

• UI的，建议软件稍微稳定或者需求变更不频繁的时候再去开发；
• 接口的，可以在开发阶段同步进行；

7 自动化测试工具

太多了，举个例子，不代表所有的。事例而已：