随着互联网技术的发展，无论哪个公司，哪个团队都在谈论自动化测试、动手实现自动化测试，从而让测试显得更加“高大上”。
那么是不是所有的业务都适合自动化？是不是自动化做的越多，效果越好呢？下面就自己一些经验和感悟，聊聊自己的一些体会。
二、为什么自动化测试?
- 在测试时，你进行了新的部署、bug修复，这是你如何保证新bug没有被引入老功能？你需要测试之前的功能。
因而，每当有bug修复，或新功能添加时，你都要手工测试所有功能？考虑到花费、资源、时间等等因素，你这么测试不是高效的。
因而自动化有了需求：
当你有太多回归测试工作要做时，请自动化你的测试工作
- 当你正在测试一款web应用时，与此同时，这个应用可能有数千用户正在使用。
你将如何测试这样的web应用？你将如何使用手工方式，同时模拟这些多的用户呢？这是一件十分困难的手工操作。
模拟众多虚拟用户，来测试应用的负载容量时，请将你的负载测试自动化
- 你正在测试一款代码被频繁修改的应用，虽然GUI几乎一样，但功能变动越多，需要的测试“维修”就越多。
当你的GUI几乎不变，功能频繁发生变化时，请将你的测试工作自动化。
三、关于自动化测试，有哪些风险?
在一些不同的情况下，你可以考虑自动化测试工作。这里我介绍自动化测试的一些风险。如果你已经下定决心要做自动化或者想要更早地采取措施，那么请先考虑以下问题。
- 你能找到有经验的人力吗?
想要自动化，你需要有一些编程经验的人员。
考虑一下你的人力资源。他们有足够的自动化测试经验吗？如果没有，他们有 技术
能力或编程背景来轻松应对新技术吗？你打算投资建立一个好的自动化团队吗？如果你的答案是肯定的，那么考虑自动化你的工作吧。
- 自动化的初始成本非常高
我赞同这个观点：由于要雇用熟练的手动测试人员，因而手动测试的相关成本很高。但如果你正在考虑将自动化作为方案，请三思而后行。
自动化的初始新建成本太高，例如：自动化工具的购买，测试脚本的培训和维护。
很多自动化工具用户都会后悔做自动化。如果你花费了很高的成本，却只得到了一些好看的测试工具和一些基本的自动化脚本，那么自动化的用途是什么？
- 如果UI不是一成不变的，不要试图自动化
自动化测试用户界面前务，请必要小心。如果用户界面正在大范围发送变化，那么自动化脚本的维护成本将会非常高。在这种情况下，基本的UI自动化就足够了。
- 你的应用是否足够稳定，可以支持你的自动化测试工作?
在早期的开发周期中自动化测试工作将是一个坏主意（除非它处在一个敏捷的环境）。 在这种情况下，脚本的维护成本将非常高。
- 你正在考虑100%自动化?
别异想天开了，你不可能100%将测试工作自动化。当然，有一些领域，如性能测试，回归测试，负载/压力测试，你可以有机会达到接近100％的自动化。但用户界面，文档，安装，兼容性和恢复等领域，必须手动完成测试。
- 不要自动化只执行一次的测试任务
某些识别应用领域和测试用例，可能只需要运行一次，并且不需要包含在回归测试中。避免自动化此类模块或测试用例。
- 你的自动化套件会长期使用吗?
每个自动化脚本套件都应该有足够长的使用寿命，其新建成本应该绝对低于手动执行成本。然而分析每个自动化脚本套件的有效成本有点困难。
对于单独的构建（一般假设，取决于具体的应用程序的复杂性），大约应该使用或运行至少15到20次自动化套件，才能获得良好的ROI。
四、总结
自动化测试是实现大多数测试目标和有效利用资源和时间的最佳方式。但在选择自动化工具之前，你应该谨慎。在决定自动化测试工作之前，请确保有熟练的人力。否则，您的工具只是一个空架子，无法获得ROI。
将昂贵的自动化工具交给非技术人员会带来失望。在购买自动化工具之前，请确保该工具最适合你的要求。你不太可能拥有与你的要求100％匹配的工具。
你需要找出最符合你要求的工具的局限性，然后使用手动测试来克服这些测试工具的限制性。开源工具也是开始自动化的好选择。
不是100％依赖于手动或自动化，而是要使用手动测试和自动化测试的最佳组合。这是每个项目的最佳解决方案（我认为）。自动化套件不会找到所有的错误，也不能替代真正的测试人员。在许多情况下，随机测试也是必要的。
如果想学习交流，就快加入：893694563，群内学软件测试，分享技术和学习资料，陪你一起成长和学习。那就：码上开始