网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
- 项目周期足够长
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
- 自动化测试脚本可重复使用
如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，
自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。
另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试，配置测试、大数据量输入测试等。
当满足了这几点之后就可以进行自动化测试的实施了。
自动化测试的实施，最重要的是自动化工具的选择。系统的 GUI 是图形界面，使用的自动化测试工具是公司的开发人员基于系统框架开发的，提供了一些获取系统单元格和其他数据的函数，保证了自动化测试的顺利进行。
现在比较好用的selenium工具，可以选用DDT数据驱动框架进行编写测试脚本。
自动化测试工具确定之后，主要是测试脚本的培训和开发。由于自动化测试脚本语言和系统使用的二次开发语言相通，在二次开发人员的帮助下，测试人员很快掌握了测试脚本语言的使用方法。
接下来就是确定自动化测试的范围。如果系统能达到 100%的自动化测试，当然这是最好的。项目的实际情况是有些功能的 UI 变化大和测试结果数据变化频繁，这些都不在自动化测试脚本开发的范围内。
因此，我们最后确定的自动化测试的范围是版本迭代时验证系统的核心功能。
紧接着就开始自动化测试脚本的编写。编写第一个脚本是最费时间的，首先需要确定读取的配置文件格式及参数内容，参照数据的存放形式（Excel、Access、XMl 或其他文件格式），实现的功能脚本，测试结果的存放形式（html、txt、Excel 或其他文件格式）。开发脚本完成后，就是调试，在调试的过程中遇到问题时若三十分钟不能解决，则应向有经验丰富的同事请教，以免耽误脚本开发进度。第 1 个脚本开发完成后，接下来的开发工作可以在第 1 个脚本的基础上进行修改，并将常用的函数存在公共函数文件中，这样会大大提高开发效率。
自动化测试脚本的应用。每次版本迭代时，手工测试完成，需求变更等功能趋于稳定，这时运行自动化测试脚本的时机相对来说比较合理，这样保证了发布的系统的核心功能的准确性和稳定性。
最后要做的事就是自动化测试脚本的维护。系统 GUI 变化，自动化测试范围的增加，这些皆应在系统定版后安排进行，待下一次版本迭代时，用于验证系统功能的正确性。
经过这几年的自动化脚本用于项目的实战经验，我的个人看法是自动化测试并不能完全替代手工测试。每个系统都会发生需求变更，若系统的核心功能不变，则可以将不变的核心功能用自动化测试来替代，其他功能手工完成，这才是有效利用资源和时间的最佳方式，才能获得良好的 ROI。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
扫一扫
1063
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
