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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

走出电梯，快步消失….