我们怎么把自动化测试落地到一个项目上呢？_怎么将自动化测试技术用到项目职责里

现在的软件测试行业已经不是原先的点点点的功能测试，要想在软件测试这一行中扎根稳住，就需要你会的很多，不局限于功能测试，还要会自动化测试、接口测试、性能测试等。

今天就来说一下自动化测试，首先什么是自动化测试呢？

一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。

其实说的清楚一点就是人工来写脚本，然后执行脚本，让脚本来自己跑用例。

现在很多公司都需要自动化测试的人才，许多软件测试工程师都会往自动化测试工程师方向发展。为什么要做自动化测试呢？

因为正常进行功能测试会执行很多的测试用例，后期进行回归测试时工作量非常的大，因为每次有版本迭代时都需要进行回归测试，把原先的测试用例再跑一边，包含大量的重复步骤。并且大部分工作都是非智力创造性的工作。

所以在你项目周期足够长的情况下，为了提高工作效率，我们需要从功能测试的测试用例中挑选一些用例来进行自动化测试。

那么我们怎么把自动化测试落地到一个项目上呢？

首先实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：

1) 需求变动不频繁

测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

2) 项目周期足够长

自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

3) 自动化测试脚本可重复使用

如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，

自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试，配置测试、大数据量输入测试等。

当满足了这几点之后就可以进行自动化测试的实施了。

自动化测试的实施，最重要的是自动化工具的选择。系统的 GUI 是图形界面，使用的自动化测试工具是公司的开发人员基于系统框架开发的，提供了一些获取系统单元格和其他数据的函数，保证了自动化测试的顺利进行。

现在比较好用的selenium工具，可以选用DDT数据驱动框架进行编写测试脚本。

自动化测试工具确定之后，主要是测试脚本的培训和开发。由于自动化测试脚本语言和系统使用的二次开发语言相通，在二次开发人员的帮助下，测试人员很快掌握了测试脚本语言的使用方法。

接下来就是确定自动化测试的范围。如果系统能达到 100%的自动化测试，当然这是最好的。项目的实际情况是有些功能的 UI 变化大和测试结果数据变化频繁，这些都不在自动化测试脚本开发的范围内。

因此，我们最后确定的自动化测试的范围是版本迭代时验证系统的核心功能。

紧接着就开始自动化测试脚本的编写。编写第一个脚本是最费时间的，首先需要确定读取的配置文件格式及参数内容，参照数据的存放形式（Excel、Access、XMl 或其他文件格式），实现的功能脚本，测试结果的存放形式（html、txt、Excel 或其他文件格式）。开发脚本完成后，就是调试，在调试的过程中遇到问题时若三十分钟不能解决，则应向有经验丰富的同事请教，以免耽误脚本开发进度。第 1 个脚本开发完成后，接下来的开发工作可以在第 1 个脚本的基础上进行修改，并将常用的函数存在公共函数文件中，这样会大大提高开发效率。

自动化测试脚本的应用。每次版本迭代时，手工测试完成，需求变更等功能趋于稳定，这时运行自动化测试脚本的时机相对来说比较合理，这样保证了发布的系统的核心功能的准确性和稳定性。

最后要做的事就是自动化测试脚本的维护。系统 GUI 变化，自动化测试范围的增加，这些皆应在系统定版后安排进行，待下一次版本迭代时，用于验证系统功能的正确性。

经过这几年的自动化脚本用于项目的实战经验，我的个人看法是自动化测试并不能完全替代手工测试。每个系统都会发生需求变更，若系统的核心功能不变，则可以将不变的核心功能用自动化测试来替代，其他功能手工完成，这才是有效利用资源和时间的最佳方式，才能获得良好的 ROI。