做自动化测试的人，经常碰到这样的问题：

上司：“脚本跑得如何了？找到BUG没有？”

员工：“没有。”

上司：“没找到BUG？！不可能吧？是不是你脚本写得不够好？”

员工：“自动化是拿来确保后期产品的质量的，不是来找BUG的”（心里一百个不情愿，埋怨上司不懂什么叫自动化，网上都这么说）

上司：（我给你哪么多时间你搭建的自动化给我一个这样的结果？）

自然，这样的对话会让上司觉得普及自动化的意义的存在与是否再愿意投入。

自动化测试的意义，在很早以前被自动化老手定位在回归测试中，或者说是由于主流的测试工具带来的负面影响，目的在于确保工程质量。因此这个理念也随着时间的推移根深蒂固，很多人不愿意思考，自动化是回归测试的人力代替品，这样也导致了自动化普及成了一个瓶颈。敢说现在很多公司对自动化的重视远远没有手工测试来得多，在这里与自动化的定位脱不了干系。

在这里先说下场景测试用例与功能测试用例，场景用例是测试建立在某种已模拟的环境上，包括数据准备，数据传递等的流程用例。而功能测试用例更偏重的是某个环节，控件等的可操作性与功能的测试用例。

普遍按照刚才的自动化回归论，是基本建立在场景用例的基础上，“录制-回放”的模式。我们需要的是产品的定型，稳定后，我们的自动化工作才能展开。自然，在团队开发中，自动化工程师成了一个单打独斗的角色，并且自动化的优势被这样的定位完全弱势化，自动化工程师早期在哪里凉菜，后期又跟着别人后面跑，如果你是领导，你会被说服去让产品如此自动化吗？
我们在长期的实践中，我们慢慢摸索出如何让自动化的更为容易被大家所接受，普及并改进。在这里我们重新对自动化测试定位：

独立于产品的成熟与稳定

早期能建立在功能测试用例基础上，并开展测试，后期建立于场景用例基础上

更大
的贯穿软件生命周期

可维护性

通用性

敏捷性

高效性