【IT168 技术文章】

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

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

　　员工：“没有。”

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

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

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

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

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

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

　　普遍按照刚才的自动化回归论，就是基本建立在场景用例的基础上，“录制-回放”的模式。我们需要的是产品的定型，稳定后，我们的自动化工作才能展开。自然，在团队开发中，自动化工程师就成了一个单打独斗的角色，并且自动化的优势被这样的定位完全弱势化，自动化工程师早期就在哪里凉菜，后期又跟着别人后面跑，如果你是领导，你会被说服去让产品如此自动化吗？

　　我们在长期的实践中，我们慢慢摸索出如何让自动化的更为容易被大家所接受，普及并改进。在这里我们重新对自动化测试定位：

　　独立于产品的成熟与稳定

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

　　更大的贯穿软件生命周期

　　可维护性

　　通用性

　　敏捷性

　　高效性

　　为什么如此定位而且我们要如何做到呢。

　　一、定位能独立与产品的成熟与稳定，这点是很多自动化工程师所期望的，与第二点其实有着必然的联系，也是因为我们建立在功能测试用例的基础上，让我们能不局限于产品的现态。关于产品的稳定，我们使用了基于功能测试的自动化脚本，主要需要把握的是对异常的捕获，它越不稳定，我们抓到的BUG会更多，自然也需要考虑到错误恢复。

　　二、我们要如何做到基于功能能测试用例的基础上并让脚本更通用，敏捷。

　　简单举个例子：输入框测试功能测试用例大概包括：这个输入框是否可输入，是否为密码框，最大长度，最小长度允许是否正确，是否隐藏，是否能输入全角，是否能输入数字，是否能输入特殊字符等等自然想实现这样的自动化测试脚本，我们需要一定的编码基础，建议不要太指望自动化测试工具，他们只是给你一种测试的思想，而我们现在做的和它们截然不同。

　　1)脚本编写：根据功能测试用例编写测试脚本。2)通用性 ：把对象，以及我们的期望值传给脚本。

　　3)敏捷性 ：在传递对象，期望值能“高效快速实现”与“简便”，这样可以很快投入测试中并考虑到以后给其它黑盒测试人员使用。

　　4)可维护性：搭建优秀的测试框架，把通用性，敏捷性囊括其中。

　　三、自动化测试更大贯穿在软件的生命周期中，为了达到这样的目的，我们需要再把脚本细化成另外的2部分并让它们在运行过程中结合起来，分别是功能测试与流程测试，这样才能很在软件周期中占据更多。

　　同样我们需要考虑到手工测试与自动化脚本带来的效益，区别：

　　手工测试的即兴发挥找到BUG比脚本找到的更多。

　　脚本编写是一个漫长的过程，更考虑到可拓展与通用，成本高。

　　手工测试的缺乏规范，会出现漏测问题。

　　手工测试效果被测试员情绪影响着。

　　自动化测试能减少劳力与乏味重复测试。

　　自动化测试能在早期比全面而迅速找到BUG。

　　随着脚本规范的增多，脚本测试面增光，能找到更多的BUG。

　　随着自动化的普及与提高，我们憧憬的一幕：

　　上司：“怎么这么准时就走呢？工作缺乏激情呀！”

　　员工：“脚本下午已经4点到5点已经整个系统跑完一次，BUG提交并开发已经在改了，估计周末他们要加班（周五是无BUG日）。”

　　上司：“这系统环境不是下午3点才搭建的吗？怎么哪么快呢？！”

　　员工：“是呀，凌晨1点会跑第2次，到时候会自动发邮件给您和开发员，是否需要加班您再定吧”

　　走出电梯，快步消失….