专攻自动化&手动测试5年，工作经验分享给需要的你

Posted 2021-06-21 程序员小捣

最近要在新入职的公司准备一份自动化测试的培训，这是我在得知要做自动化测试培训以后，随手画了个图，给大家看下（见笑见笑）：

这是我能想到的关于自动化测试的一些要点（不过遗憾的是到目前为止，我接触的成功的敏捷开发项目还很少，虽然敏捷近些年一直很火。因此，本文不涉及敏捷测试的相关内容），跟大家做一个分享：

1、什么是自动化测试？

以程序测试程序，以代码代替思维，以脚本的运行代替手工测试。自动化的测试涵盖了：功能（黑盒）自动化测试，功能（白盒）自动化测试，性能测试，压力测试，GUI（Graphical User Interface）测试，安全性测试等。

（关于什么是自动化，我查阅了一些资料，并没有一份权威规范的解释）

我个人的理解：

自动化测试是测试思想的一个延伸，为测试工程师提供了一个“触须”，其行为可以看成一个工具，但是本质上自动化测试还是一种思想。

顺便提一句，狭义上的自动化测试指的就是基于GUI的自动化测试，而单元测试跟API测试，你有想过怎么用手工不借助任何工具去做吗？所以它们天生就属于测试自动化的范畴。

2、自动化测试的优势

回归测试更方便可靠；可运行更多，更繁琐的测试，且快速高效；可执行一些手工测试执行相当困难或者做不到的测试，如大量的用户并发；更好的利用资源，具有一致性和可重复性的特点，自动化测试脚本完全可复用；提升了软件的可信度；多环境下测试等。
我个人的理解：

自动化测试的优势都是自动化测试成功完成得到的结论，而自动化测试的劣势才是自动化项目立项的基础。

还有个优势：自动化测试可以将产品的知识固化到脚本中，以降低测试人员流动对项目造成的影响。但是这个优势的前提是，这些脚本易于维护，这就需要一些必要的文档，这又是另一个议题了。

3、自动化测试无法做到的事以及劣势

永远不可能完全替代手工测试，自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合做成自动化，如为一个页面布局是否正确提供建议，那么手工测试发现的缺陷远比自动化多。

对比手动测试，自动化测试是几乎无法发现新缺陷的，最大的用途在于实施回归测试，确保曾经的bug没有在新的版本上重新出现；另外，自动化测试工具是死的，它不具备任何想象力；自动化测试的好坏，完全取决于测试工程师；成本投入高，风险大；对测试人员的技术要求高，对测试工具同样有要求。

4、合适引入自动化

项目周期长，系统版本不断，并且需求不会频繁变更，此时是适合引入自动化测试的。

系统的测试对象基本可以正常识别，以及对无法识别的控件能否提供一个解决方案。

系统中不存在大量的不可识别第三方控件。

需要反复测试，如可靠性测试、回归测试等需要进行上千次的系统测试。

5、不适合自动化

项目周期短，需求频繁变更。即使是周期长的项目，如果经常需求变更，也不适合做自动化；

软件版本还没有稳定的情况下，主功能或大量功能有被重新更改的可能话，也不适合做自动化；

没有明确的项目测试自动化计划，措施和管理。多数对象无法识别，以及脚本维护频繁与艰难，二者有其一，自动化必定失败。

6、自动化测试的流程

合理的自动化切入点：通常，项目只有经历了完整的系统测试之后才算具备了基本的引入测试自动化的条件。

我个人的理解：

无论什么测试，越早介入则越有利于降低成本，降低风险。而随着新型的开发模式兴起，自动化测试也具备了尽早介入的条件。比如敏捷开发中，某核心模块核心功能完成后，则可针对该模块的该功能开始实施自动化测试。

7、测试自动化分析

（1）可行性分析；

（2）抽样demo分析,demo一般选取冒烟测试用例，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行；

（3）测试需求分析，分析哪些功能点准备进行自动化。

8、测试流程及设计

测试计划定制：自动化测试计划越全面，后期越能循规蹈矩的去实施，自动化测试的成功率越高。

计划赶不上变化，有时候太全面了或许也不是什么好事。

自动化测试设计阶段：主要分为自动化测试框架和自动化测试用例。

（1）自动化测试框架的设计，开发与搭建：应能保证测试的分布执行，脚本模块化，数据驱动，日志分析，错误截图，报表回收，共享对象库，公共函数库，环境配置，统一设计模式，异常处理，场景恢复的一个无人值守的，针对每个独立项目的测试框架。

（2）自动化测试用例设计三部曲：手工测试用例是从无到有，然后自动化测试用例是根据手工测试用例来写的。首先，筛选手工测试用例。然后转换手工测试用例，最后新增&补充自动化测试用例。

9、为什么自动化测试用例不能完全替代手工测试？

自动化测试用例的范围往往是核心业务流程或者重复执行率高的，自动化测试的覆盖率不能达到手工测试的覆盖率。自动化测试的用例选择一般以正向为主，而反向的情况却有很多，但是并不是所有反向情况自动化测试都会涵盖，而是有筛选的选取一部分。

也并不是所有的手工测试用例都可以用来做自动化的，如页面布局的检查。手工测试可以不需要回原点，但是自动化测试往往是必须的。自动化测试用例与手工测试用例不同，不需要每个步骤都写预期结果。

我个人的理解：

通常做自动化测试的时候我都会写一个叫做shake-down test的测试用例，这个用例会把系统里所有完成了的表单都过一遍，只是做一个Navigate的操作，以确保某个页面是否可用。

每次做回归测试前，可以先跑一遍shake-down test，很快可以确定哪些功能是accessible，相当于做了一整个系统的一个冒烟测试。

10、测试脚本设计与开发

测试脚本大致可划分为：

（1）线性脚本：通过录制直接产生的线性可执行的脚本

（2）结构化脚本：具有顺序，循环，分支等结构的脚本

（3）可共享脚本：可以被多个测试用例使用，被其他脚本调用的脚本（即模块化的脚本）

（4）数据驱动脚本：测试数据跟业务流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本

（5）关键字驱动脚本：脚本，数据，业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动的特点是，它更像是描述一个测试用例在做什么，而不是如何做。

（6）混合型脚本：以上任意两种及以上

11、自动化测试执行

（1）无人值守的测试：环境搭建，部署与配置；自动化测试用例与测试脚本相互绑定；自动化测试用例执行顺序排列与组合

（2）异常处理与场景恢复

提交自动化测试产物：大致需要提交执行情况，测试结果，分析报表，测试报告，质量情况等。

测试脚本维护：严格来讲，每个阶段都在做测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。

如果你已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的，都可以加入我们1033482984，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！微信公众号【软件测试小dao】

燃烧秀发输出内容，如果有一丢丢收获，点个赞鼓励一下吧！