软测自动化之矛与盾

      相比于之前的全手工测试，现在的测试无疑自动化的多，回首看颇有封建社会过渡到资本主义社会之感。已经“自动化”了好几个月了，一直想总结总结这种由鸟枪更换成的大炮到底给我们测试带来多少生产力的提高，它适用什么场景，它对于测试的最终目的有多少帮助，又会带来多大的影响？
       其实说起来听可笑的，我对于自动化测试起初还是挺抵触的，总觉得自动化了之后会有一些很“隐藏”的缺陷会被放掉，而且针对小作坊式的软件生产，不需要对每个软件模块都进行全方位测试。往往将前后端一集成，发布一个包，部署给环境，测试就好了，没有那么多的要求。可是当软件进入批量和大规模之后，各个模块之间的接口通信就变得异常重要，每个环节首先必须保证自己是没有问题的才能集成进环境，还有软件开发都是这样，先后台再前端，往往到了项目后期，才集成UI联调，此时后端的功能和接口都必须已经测试过保证没有大问题的情况下进行的；再者软件后台的程序都属于项目前期开发，更多的不确定和更多的缺陷等着测试人员去发掘。在这种情况下手工测试的缺点就暴露出来，一是不能及时提供有效的页面给予手工测试，二是不停的代码变更让手工测试已经很难满足复用的需要，这时候的自动化就犹显重要。
     啰嗦了一堆，其实就是想说自动化在软件进入规模化生产之后测试人员的必经之路，可以大大的提升测试效率和节省测试时间，让这个软件过程在最短的时间内完成。
     前面提到了自动化测试适用的测试过程，现在结合几个月测试过程简单的谈谈自动化的优缺点，共享资源。
     自动化适用的用例程度最好的就是参数值校验的用例了，对于自动化脚本来说，无论是脚本语言还是高级语言都可以采用一个模板，就是一个套子，每次使用的时候只需要更换传递的参数即可。这种测试，同样基于最基本的等价类边界值的用例划分，测试设计的基本思想，自动化同样适用。
       其实对于参数值用例校验本身，其集成在功能模块测试之中，每个用例都最原始功能模块的一部分，软件的程序就是这样，我们测试每个功能模块是否有缺陷也就是靠传递参数查看其返回是否达到期望结果。PS：不能向拆开汽车或者X光检查身体那样…………
      自动化测试无法比手工测试发挥更好的地方就是执行用户级用例的时候，具体到执行的时候就是界面测试和用户场景测试，其实这两种测试有交集的，都已直接和用户打交道为主，因为是人，所以自动化即使执行通过不代表易用性等等方面达到要求，还是要具体使用情况。
      自动化测试适用前期没有页面、需要验证程序功能模块的情况，不但能够尽早的发现问题，而且自动化本身的复用性也让后期的回归测试和冒烟测试变得效率十足。对于测试前端页面和用户体验性测试，不建议使用，因为自动化脚本编写和调试本身就很耗时，保证脚本的正确性也需要费些周折，测试脚本执行完成后还需要测易用性测试，时间上需要花费的更多。