功能自动化测试工具给我们带来了什么

　　功能自动化测试工具给我们带来了什么?我不知道大家如何看待这个问题，我总觉的很多人把功能的自动化测试工具看的特别的“厉害”，觉得可以完成很多的工作。领导会说，如果我们用工具进行回归测试，会很快的发现问题，然后减少回归测试的时间，提高项目的效率，如此这般公司开始推行自动化工具。

　　幸运的，我开始成为自动化工具的推广者，曾经用过自动化测试工具selenium进行简单的自动化测试，因为项目是多省系统，进行系统测试时，重复内容比较多，但是程序又相对稳定。于是在测试的间隙，完成自动化测试脚本，在系统测试中运行测试。效果还是比较好的，现在想想当时的脚本真的是非常脆弱而且是简单的，没有任何的控制语句，场景回复，脚本的维护量比较大，一旦出现问题，脚本跑不通，只能人工排查原因，自动化测试的部分只在系统测试中站系统测试百分之五十的工作量，但是在整个测试的工作量中百分之十都不到，大家仿似看到此时自动化测试的甜头，希望在整个公司中推广自动化测试工具，觉得自动化测试是一种趋势，一种必然，于是我站在风头浪尖开始试着完成这项工作。

　　自动化测试同手工测试一样，都需要有一个计划，测试的覆盖率，评估自动化测试工具是否能带来收益来确定测试的内容，其实，并不是所有项目都适合自动化测试工具的，如果项目周期短，是不适宜做自动化测试的，自动化测试虽然在运行中比较省时间，但是在前期的设计，脚本的编写和维护都会浪费较多的时间，如果自动化测试脚本不能重复利用多次，自动化对于我们只是一种时间的浪费，只会令整个项目延期。如果你要用qtp这种识别gui属性的工具必须要等待页面功能稳定以后才能进行自动化脚本的设计，因为任何一个控件的修改都会导致自动化工具不能识别控件。其次，自动化和手工测试都需要完成用例的设计，手工测试用例有相应的输入输出，自动化脚本也需要，最好能参数化进行。

　　自动化测试是否能代替手工测试呢?多少人重复的问这这个问题，答案是不能，自动化测试最大的用处是保证测试的质量，而不是发现问题，而手工测试是发现问题。因为我们每次的回归测试，如果是手工测试的情况由于时间的关系并不能因为一个模块的bug，去测试其他的模块，而自动化测试工具的加入，可以保证所以模块的基本功能，每次回归用手工去发现验证问题，用自动化工具去保证整个软件的基本功能正常运行，自动化的推广是逐步的，首先做一些冒烟测试的自动化，随后把一些主要的功能和测试点也加进来，但是千万不要太细化，到所有手工测试的点，这样，会带来很大的风险，自动化程度越高，风险将越大。

　　自动化的另外一个注意点就是管理，引入一项内容，必然就需要花一定的时间对引入的内容做管理，例如用td管理工具，一定有相应的说明文档，使他不依赖于某个人，以至于某个人的离职不会对自动化工作造成太大的打击。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。