功能测试转自动化测试好不好转型？

手工测试做了好多年，点点点···成了每天必须做的事情。但是随着自动化测试趋势的日渐明显，以及受到薪资、技能的双重考验，掌握自动化测试成为了必备技能。

手工转自动化测试，不是一蹴而就的。“预先善其事，必先利其器”，凡事之前都需要一个良好的准备，自动化测试何尝不是呢？

在测试行业，一个一直被讨论的问题就是：手工测试没有前途，自动化测试会取代手工测试？

如今随着软件需求的变化比以往任何时候都快，越来越多的企业正在采用敏捷方法来缩短开发周期并加快上市时间 (TTM)。

在这个瞬息万变的技术环境中，应用程序质量比以往任何时候都更重要，手动测试似乎既耗时又重复，并且容易出现人为错误。

从手动测试转向自动化测试似乎非常适合快速变化的技术业务环境。与手动测试相比，移动（或迁移）在很大程度上可以归因于更好的测试覆盖范围和早期检测、解决问题的灵活性。

尽管手动测试必须与强大的自动化测试相结合，但它永远不会消失。起初，从手动测试转向自动化的想法似乎令人生畏。你可能会被诸如如何开始以及从哪里开始之类的问题所困扰。

结论：手工测试是由人一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一种。

优点：自动化测试无法代替探索性测试、发散思维类无既定结果的测试。

缺点：执行效率慢，量大易错。

不管是自动化测试还是手工测试都是测试，只不过测试的方式不一样，就像走路去上班和做车去上班，你目的都是去上班，这不过一个是走路，一个是坐车。那么现在问题来了，是不是有车子就不用走路啦？

当然，有车子还是要走路，有自动化测试还是要有手工测试，而且手工测试是必不可少的，自动化测试一般在回归测试的会使用的比较多，前期都是使用手工测试。

自动化测试不会取代手工测试，这完全是两个维度的事情。还是那句话机会是留给有准备的人？多个技能多条路，我们要学习新的知识才能扩宽我们的道路。人生是一个逆水行舟的过程，不进则退。

在本文中，我将重点介绍在你决定从手动测试转向自动化测试之前要牢记的一些关键注意事项。

一、什么是自动化测试？

自动化测试，顾名思义，自动完成测试工作。

通过一些自动化测试工具或自己造轮子实现模拟之前人工点点/写写的工作并验证其结果完成整个测试过程，这样的测试过程，便是自动化测试。

因为每一个自动化测试的case都是从手工测试做起的， 所以自动化测试的基础是手工测试 。

二、为什么要进行自动化测试

（1）自动化测试节约成本(根据项目)

（2）有些测试项目手工很难实现(手工成本较高)

（3）项目质量流程需要

三、自动化测试的优势及劣势

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

劣势： 维护成本相对比较高

系统开发时间不一定能缩短

还是得依赖手工测试，很多问题无法发现

四、自动化测试分类

按测试目的分类大致可划分为：功能自动化测试，性能自动化测试

按测试对象可以划分为：Web应用测试，APP测试，接口测试，单元测试等

功能自动化

测试目的是发现软件中实现功能是否符合用户需求规格，实践证明，往往我们实施UI自动化测试的目的不是去发现软件系统中的缺陷，更多的是为了验证系统是否可以正常运行。

除了可以基于UI进行自动化测试，我们还可以基于网络服务接口提供者进行测试，基于接口进行功能测试较为常见，也是非常有效的手段。

另外还可以基于系统基础代码进行测试，比如单元测试，集成测试阶段，这一阶段的测试也称白盒测试，我们可以直接对DAO，Service服务进行测试，这里常用的测试技术包括Junit, TestNG, Mock, Stub等 。

性能自动化

性能自动化测试是通过测试工具模拟高并发负载进行压力测试，以发现软件系统在高负载情况下运行瓶颈， 包括 应用程序本身的性能瓶颈，网络瓶颈，服务器硬件资源瓶颈，数据存储服务器等，通常唯有借助自动化测试工具来完成，常见的性能测试工具包括，Loadrunner, Jmeter, Ngrinder, Gatling等，不管哪一款测试工具，基本有三大部分组成：测试脚本管理，测试场景配置，监控结果。

与功能自动化类似的是，性能测试工作对象也可以面向用户UI层，或者服务接口提供方，甚至可以直接面向底层基础业务逻辑层，绝大多数通过用户层进行性能测试模拟的是最接近真实用户场景的测试，也是性能测试必然实施的阶段 。

五、 自动化测试的流程

1. 制定测试计划

　在开始自动化测试之前，最好的办法是做个测试计划，明确测试对象、测试目的、测试的项目内容、测试方法以及测试的进度要求等，确保测试所需的各种资源都准备充分。

2. 分析测试需求

　　用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求树，使用例设计时能够覆盖所有的需求点。

3. 设计测试用例

通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。因为不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。有时候，还需要将系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。

4. 搭建测试环境

　　自动化软件测试流程在进行用例设计时就可以开始搭建测试环境。自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装和设置以及网络环境的布置等。

5. 编写测试脚本

一般先通过录制的方式获取测试所需的页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据进行参数化。还可以用其他高级功能编辑脚本。脚本编写好了之后，需要反复执行，不断调试，直到运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。

6. 分析测试结果、记录测试问题

及时分析自动化测试结果，对自动化测试结果进行分析，以便尽早地发现缺陷。如果采用开源自动化测试工具，建议对其进行二次开发，以便与测试部门选定的缺陷管理工具紧密结合。如果是系统缺陷就提交开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。

7. 跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对此问题执行回归测试，就是重复执行一次该问题对应的较薄，执行通过则关闭，否则继续修改。如果问题的修改方案与客户达成一致，但与原来的需求有所偏离，那么在回归测试前，还需要对脚本进行必要的修改和调试。

 

六、 自动化测试常用工具

七、总结 

我有一个核心观点：软件测试的核心是效率。而不是什么设计方法，也不是什么测试思路。不管你有没有方法，有没有思路，只要时间花下去，总能找到bug。这也是为什么很多时候，测试人员累死累活测了半天的应用。来一个外行的xx总监，随便点开来就能发现一两个测试人员漏掉的bug。久而久之总监们就会质疑，测试人员到底有什么用，这么明显的问题发现不了。然而事实上，发现一个问题不难，发现一百个问题也不难，难的是在有限的时间里发现足够多的问题。也就是说，外行也能找到bug，但外行不可能在有限的时间内找到足够多的反映软件质量问题的信息。

”是雇十个应届生点点点来测，还是雇三个资深测试来做系统化的测试？“、”是买商业工具做自动化，还是自己研发测试工具自己搞一套？“软件测试一切的一切都是围绕着效率这个点来思考的。也正是为了提高效率，测试必须要引入自动化的手段。注意，不是替代不替代手工测试的问题，而是必须引入自动化才能进一步提高效率。手工测试仍然在，只要他在一些领域上效率高于自动化，就仍然会继续存在下去。自动化测试，并不是QTP，不是selenium，不是任何一种工具。

自动化测试，并不是回归测试，不是冒烟测试，不是任何一种测试阶段或类型。

自动化是一种提高效率的方法和理念。自动化测试，仅仅是自动化的一种应用。

从自动化测试开始，自动化部署，自动化发布，自动化日志收集，自动化环境管理，等等，越来越多的东西都在被自动化。这些自动化的东西我把他们划分到一起，他们的学习方法都是一样的，理念都是类似的。用到的开发语言也都是通用的。可能这些领域以后真的会融合成为一个技术领域

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取