上司：“脚本跑得如何了？找到BUG没有？”
员工：“没有。”
上司：“没找到BUG？！不可能吧？是不是你脚本写得不够好？”
员工：“自动化是拿来确保后期产品的质量的，不是来找BUG的”（心里一百个不情愿，埋怨上司不懂什么叫自动化，网上都这么说）
上司：（我给你哪么多时间你搭建的自动化就给我一个这样的结果？）
自然，这样的对话会让上司觉得普及自动化的意义的存在与是否再愿意投入。
自动化测试的意义，在很早以前就被自动化老手定位在回归测试中，或者说是由于主流的测试工具带来的负面影响，目的在于确保工程质量。因此这个理念也随着时间的推移根深蒂固，很多人不愿意思考，自动化就是回归测试的人力代替品，这样也导致了自动化普及成了一个瓶颈。敢说现在很多公司对自动化的重视远远没有手工测试来得多，在这里与自动化的定位脱不了干系。
在这里先说下场景测试用例与功能测试用例，场景用例是测试建立在某种已模拟的环境上，包括数据准备，数据传递等的流程用例。而功能测试用例更偏重的是某个环节，控件等的可操作性与功能的测试用例。
普遍按照刚才的自动化回归论，就是基本建立在场景用例的基础上，“录制-回放”的模式。我们需要的是产品的定型，稳定后，我们的自动化工作才能展开。自然，在团队开发中，自动化工程师就成了一个单打独斗的角色，并且自动化的优势被这样的定位完全弱势化，自动化工程师早期就在哪里凉菜，后期又跟着别人后面跑，如果你是领导，你会被说服去让产品如此自动化吗？
我们在长期的实践中，我们慢慢摸索出如何让自动化的更为容易被大家所接受，普及并改进。在这里我们重新对自动化测试定位：
独立于产品的成熟与稳定
早期能建立在功能测试用例基础上，并开展测试，后期建立于场景用例基础上
更大的贯穿软件生命周期
可维护性
通用性
敏捷性
高效性
为什么如此定位而且我们要如何做到呢。
一、定位能独立与产品的成熟与稳定，这点是很多自动化工程师所期望的，与第二点其实有着必然的联系，也是因为我们建立在功能测试用例的基础上，让我们能不局限于产品的现态。关于产品的稳定，我们使用了基于功能测试的自动化脚本，主要需要把握的是对异常的捕获，它越不稳定，我们抓到的BUG会更多，自然也需要考虑到错误恢复。 二、我们要如何做到基于功能能测试用例的基础上并让脚本更通用，敏捷。简单举个例子：输入框测试功能测试用例大概包括：这个输入框是否可输入，是否为密码框，最大长度，最小长度允许是否正确，是否隐藏，是否能输入全角，是否能输入数字，是否能输入特殊字符等等自然想实现这样的自动化测试脚本，我们需要一定的编码基础，建议不要太指望自动化测试工具，他们只是给你一种测试的思想，而我们现在做的和它们截然不同。
1)脚本编写：根据功能测试用例编写测试脚本。2)通用性 ：把对象，以及我们的期望值传给脚本。
文章来源于领测软件测试网 https://www.ltesting.net/
