【自动化测试的错误定位】

假装不在

做自动化测试的人，经常碰到这样的问题：
上司：“脚本跑得如何了？找到BUG没有？”
员工：“没有。”
上司：“没找到BUG？！不可能吧？是不是你脚本写得不够好？”
员工：“自动化是拿来确保后期产品的质量的，不是来找BUG的”（心里一百个不情愿，埋怨上司不懂什么叫自动化，网上都这么说）
上司：（我给你哪么多时间你搭建的自动化就给我一个这样的结果？）
自然，这样的对话会让上司觉得普及自动化的意义的存在与是否再愿意投入。

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

同样我们需要考虑到手工测试与自动化脚本带来的效益，区别：
u手工测试的即兴发挥找到BUG比脚本找到的更多。
u脚本编写是一个漫长的过程，更考虑到可拓展与通用，成本高。
u手工测试的缺乏规范，会出现漏测问题。
u手工测试效果被测试员情绪影响着。
u自动化测试能减少劳力与乏味重复测试。
u自动化测试能在早期比全面而迅速找到BUG。
u随着脚本规范的增多，脚本测试面增光，能找到更多的BUG。

随着自动化的普及与提高，我们憧憬的一幕：
上司：“怎么这么准时就走呢？工作缺乏激情呀！”
员工：“脚本下午已经4点到5点已经整个系统跑完一次，BUG提交并开发已经在改了，估计周末他们要加班（周五是无BUG日）。”
上司：“这系统环境不是下午3点才搭建的吗？怎么哪么快呢？！”
员工：“是呀，凌晨1点会跑第2次，到时候会自动发邮件给您和开发员，是否需要加班您再定吧”
走出电梯，快步消失….





[ 本帖最后由 假装不在 于 2008-11-6 00:43 编辑 ]

刀客

所以我一直认为：做人要踏实，要一步一个脚印

BS这样的上司，虽然现实生活中有很多

kevin_swpi

假装对这个理解比较独到
公司用自动化  很大原因就是听多了以为工具能更快的找到更多的bug
所以  自动化的实施  还很大程度上却决于你上级乃至公司的重视和认识程度

要想实施自动化
首先一个就是要获得他们一致的认可 或者  说是说服他们
不然即使实施起来肯定就是困难重重

假装不在

::yiwusuoyou:::
我是认真的理解，没有假装理解

自动化的普及需要自动化高手以及领导的认知。
当靠当前主流的自动化工具，会让自动化测试留在一个比较简单的自动化思想层次中。
当我们学会了如何用思想后，我们需要再拓展这种思想。
单纯录制回放的时代已经过去了，我们需要的是在测试过程中，插入自己更多的思想而不局限于此。

kevin_swpi

能有你这样思想的人太少了
很多人都是相信所谓的权威
所以现在很多人都不思考了  自动化也自然就进展缓慢

谁不想提高效率
谁又不想获得技能上的提高
但是作到这些的仅仅是少数  很多人都是站在巨人的肩上  却又永远停留在了那里。。。
。。。

期待你的书。 。 。哈哈

假装不在

::yiwusuoyou:::

你说得太深奥了，我的思想修为跟不上....哈哈

大家互相学习，慢慢摸索吧，软件工程也才走了50几年的路，软件自动化测试也是起步不久，摸索。

kuerzhao

有点小启发，在经历了无数尝试，终于跑了自动化测试GUI，却独独忘记了，可以针对各种GUI对象，比如输入框等开发一些自动化测试的执行工作。

vprince

假装不在这位仁兄的见解我深有体会啊，老是被上司追着问找到多少bug，我不很自信的回答：不是很多，
老板接着回答：不多那怎么行，说明自动化工作还没有达到预期的效果。
我无语。

hyper

呵呵 同意
自动化主要就是用来回归的， case都是跑过的，哪那么容易发现新bug；
还有就是都已经自动化了，做些控制，监控，应该比较好转成性能测试

eastsurfer

要做到第二点那就要依赖于自动化测试框架而不单纯是自动化测试工具了。

我的观点：
不管是自动化还是手工都不能脱离测试的目的性---找到BUG而不是单纯的验证功能。
而性能测试多是自动化是因为很多场景手工是无法做到的。

edison1256

走出电梯，快步消失….
这个好喜欢

huangli_miffy

我对qtp还没有入门，我都感觉它好深了，要怎么学啊？不知道方向

park_p

知易行难，谁都想让自动化贯彻整个软件周期，都想是主动的找bug而不是被动的验证而已。
但是如何做是个很大的问题：
第一，如果因为这个原因，开发脚本和维护脚本投入的成本太大，我想谁都不想再投入其中，因为有更为便宜的手工测试就能达到目的，你可能不这么想，可老板一定是这么想，这是个成本收益比的问题，超出工程师的能力范围之外了。
第二，自动化不是人工智能，所以很多很牛x的bug发现还是要靠牛人的思索，去认为的测试，这个自动化也是不好办到的，毕竟程序是按照你写的脚本执行的，它不会思考，而如果想写出个智能的程序来，不是不可能，而是有可能的话，成本也太大，不是嘛。
第三，就是脚本程序本身的兼容性或者说通用性的程度能有多大，脚本也是程序，是程序就有这个限制，就是开发也写不出一通百通的程序来，这本身也对自动化实施是有限制的。
第四，如果真的能达到你想要做到那样，我本身也非常想这样，是个挑战，哈哈，但是这就需要公司给出一定的测试范围和方式，才可能写出在此环境下通用性比较强的脚本，否则，脚本的变化永远是没人的思维变的快的。有了这个范围，有了公司的投入和肯定，前期的培养、培育，让自动化发挥的更好不是没可能，但是我想说的是此路很漫长，需要努力，包括我，哈哈～～
这就是为什么性能自动化被广泛接受的原因，因为如果靠人模拟性能环境，一个办不到，二是如果办到投入要比自动化大的多，这就是为什么老板们对性能测试不指手画脚的原因，因为他没得选，不管性能测试做的好坏，他只能接受。

park_p

自己顶下，哈哈～

ermine

收藏一下

其实我们都向往敏捷的自动化测试，
但是就像上面13#说的，对于大部分公司来说，成本大于手工测试，尤其是中小公司。
路漫漫啊。。