51Testing软件测试论坛

标题: 如何使自动化测试与手工测试达到最优的结合?(09-12-29)(获奖名单已公布) [打印本页]

作者: 默默巫    时间: 2009-12-29 17:46
标题: 如何使自动化测试与手工测试达到最优的结合?(09-12-29)(获奖名单已公布)
如何使自动化测试与手工测试达到最优的结合?


此话题由会员centurystone提供,如果你也有问题想提出来和大家一起讨论,请点击此处>>
说不定下期讨论的问题就是由你提出的哦,请快快参与吧!



获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
1316016
50元当当网礼品
二等奖
five3
300论坛积分

作者: happy_wendi    时间: 2009-12-29 19:28
标题: 回复 1# 的帖子
可以从以下方面进行考虑:
1、测试用例的定位:需要分别考虑自动化脚本同手工测试用例的定位。比如将自动化脚本定位在覆盖功能需求,而不是发现问题,而手工用例则定位在发现问题。这样,每个版本出来的时候,执行一遍自动化脚本,根据测试策略挑选手工用例即可;
2、测试版本的定位:测试版本是要保证基本功能还是提升质量。如果版本是要提升质量,建议使用手工用例,否则则可以多用自动化脚本;
3、测试团队的组成:这里需要考虑测试组人员的组成,如果测试组人员技能、人力等都可以足够支撑手工测试,则建议多选择手工测试用例,否则则可以多选择自动化脚本;
作者: UU1983    时间: 2009-12-30 09:09
标题: 手工和自动化的结合要有一定的前提
首先大家要清楚为什么手工测试,和什么时候使用自动化测试
需要手工测试最重要的一点就是系统还不够稳定,需求改动量很大。
那这个时候就不可以进行自动化测试吗?当然可以,但是需要大量的脚步,这些都需要人力,物力的,简而言之,这样的自动化测试会使成本急剧上升,详细大多公司都不会这样做。
从这个方面反映,自动化测试建立在需求稳定或改动很少的情况下,系统也比较成熟
那如何将手工测试和自动化测试进行最优结合呢
其实在理想的情况下是不难的
对系统了手工测试,当系统进入了一定成熟度时,就可以自动化测试了
不过我说的是理想情况,可是我们必须面对现实,因为现实是不理想的,有各种因素导致,所以自动化测试往往不能有理想中的那么顺利,大多数还是以手工测试为主。
这对于测试人员来说是一个课题也是对整个IT产业来说也是一个有思考性的课题,我们只能做好我们的工作,在时间的流逝中等待,中国软件产业走向成熟之路
作者: davy_chen    时间: 2009-12-30 10:04
从目的出发,而非实现手段出发,就可以达到手动和自动的良好结合。
即,目的--〉相关条件--〉方法--〉操作实施
手动和自动的结合作为后续阶段方法和操作实施内容而言,只要从目的出发,适应相关条件就自然而然的可以达到良好的结合效果。
作者: davy_chen    时间: 2009-12-30 10:06
现在测试中表现出来的一个通病就是,过分关注方法,工具,概念等等,而忽略了测试本身的意义。
作者: 狩猎者    时间: 2009-12-30 15:55
自动化测试还是手工测试,这个一个问题!问题的解决不是看哪种测试更好,而是哪种测试更适合你要做的工作!
    我认为采用何种测试,要看一下几个方面:
1、做那方面的测试
    测试分为单元测试、集成测试、系统功能测试、性能测试等。采用手工测试还是自动化测试主要还是看哪种方式效率更高、效果最明显。
    如在性能测试的时候,手工测试在效率和准确率等方面都无法和使用自动化工具相比。当然手工编写测试脚本或测试工具进行测试也是可以的,但有现成的自动化工具不用,而非要自己动手,那就有点资源浪费了。性能测试的重点还是在于测试结果的分析,使用自动化工具明显可以使我们得到我们想要的东西。
2、测试系统的需要
    根据系统的复杂度和设计结构进行选择。
    一个复杂的系统测试时,使用自动化测试工具有一个明显的好处,就是回归测试时会比较节省时间、且不容易有遗漏。而对于一个复杂度很低的系统使用自动化测试工具反而会降低工作效率。
    系统的设计结构也会影响到测试方式的选择,如一个以录入、查询统计为主的系统,使用自动化测试工具进行测试,工作效率一定比手工要高。而一个绘图类的工具如果使用自动化测试工具反而会降低测试的覆盖率。
    总而言之,规律性强的使用自动化测试工具比较有优势,而随机性强的还是手工测试比较好。  
3、公司或用户要求
   有的项目公司或用户会要求,必须使用什么样的工具进行测试,并出具相应的测试报告,这就没什么好说的了,按照要求做吧,即使这样效率不高,即使这样浪费精力,那也只有按要求做。
4、对自动化测试工具的熟悉程度
   为了自动化测试而使用测试工具,就失去了使用工具的真正意义。使用一个不熟悉的自动化测试工具还不如手工测试,因为测试的根本目的是找出程序存在的bug,而不是实现测试的自动化。使用最低的成本,到达最大的效果才是我们要做的。
5、无招胜有招
   如何达到我们的测试目的是我们工作的根本,至于何时采用自动化测试,何时采用手工测试,做什么必须要自动化测试,做什么必须要手工测试,不要拘泥形式,每个人都有自己的测试习惯和测试风格,并不是都有一定的套路,从需要出发,这样才能将自动化测试和手工测试完美结合。
作者: UU1983    时间: 2009-12-31 09:07
是的,如果以个人的角度来看,这些都无所谓,因为你只要拿工资就行了,其他的不必考虑,只要老板给的合适,你会很乐意这么做,但是从企业的角度来看,这无疑是增加了成本,什么都所以要钱的,请一个合格的自动化测试工程师价格不菲,何况这中情况,不是一个或者两个就可以,现在中国的it产业是以中小型企业为主,如果是微软,甲骨文那样的公司这样的成本只是九牛一毛,但是对于中小型企业来说,是高昂的,你的成就感并不是企业的需求,企业的需求永远是用最少的成本创造对大的利润,我们必须正视这一点。
所以中国的IT产业道路并不平坦,达到规范化还是有一段距离
作者: UU1983    时间: 2009-12-31 09:11
标题: 正视企业需求来谈手工和自动化的结合
我们必须正视当今企业需求,才能和实际结合,不然就是空谈
是毫无意义的
及时你的是最优但是你的公司并不允许用这样的物力支持你,你的再好有什么用呢?
作者: UU1983    时间: 2009-12-31 09:30
标题: 现实就是这样
企业看效益,如果他一年只赚100万还是毛利润,你认为他会像微软一样,五脏俱全吗,别说一年一百万,我们这部门的毛利润是1.8个亿,可是我们的测试工程师不到10个,自动化的2人,还都是初级的那种,根据我以前的工作经历,国内的企业在认知度上就有很大的差距,说白了就算他赚3个亿,也不会掏出100万来请像样的自动化工程师,因为他并不能直接的看到利润。不过我要攒下日本的IT企业,测试的规模和国内相比是一个天一个地,为什么他们会形成这样的规模呢,日本人傻吗,从他们做出的产品来看,是不傻的,归根结底是认知度,国内的企业要达到这样的认知度,可不是几天的事情,我们处于发展中国家都多少年了,所以大家不要心急,路还是要一步一步的走出来。
作者: UU1983    时间: 2009-12-31 09:32
偶还是很有信心的
大家还是讨论下在国内的形势下怎样做到最优的结合吧
作者: jiguoling    时间: 2009-12-31 09:34
标题: 在手工测试之后进行自动化测试!
自动化得实施与否完全与个人能力有关!
1.如果是自动化测试专家,可能就会在开发时就进行测试脚本的开发了,软件的每一个小的字段每一个小的功能都是用自动化,这也不是不能实现的事情。当然以上这种情况应不会是大多数人的习惯做法!
2.个人的习惯,由于自己的自动化水平不是很高,每次先手工测试小的功能点或字段,在手工测试通过后,开始编写便于以后大量数据验证和回归测试的自动化测试脚本,这样可以节省很多的后期测试时间,一句话,在测试基本稳定了之后再进行自动化测试。
3.个别性能的测试,要用专门的工具在开发或者开发之后进行测试!


以上是我的一些看法!
作者: fengyupeng1984    时间: 2009-12-31 13:06
确实,现在在国内IT行业,测试的理论值和实际投入的差距太大了
我是一名国内典型小型IT公司员工,由于新公司,从我组建测试部门到现在已经一年多了,可是公司对测试的资源投入还是相当有限,而且老板口头讲注重质量,但是实际开发中将开发的时间压得相当有限,基本开发完整项目提交的时间就是要客户上线的时间了。
作者: UU1983    时间: 2009-12-31 13:31
谢谢支持
作者: ami冰河    时间: 2010-1-4 14:16
原帖由 jimmyseraph 于 2009-12-30 16:06 发表
这一点我持反对意见。
为什么一定要在系统稳定的情况下才用自动化测试呢?这种传统思维祸害不小。
反问一句,在系统还不稳定,需求改动量很大的情况下,要不要写代码?是不是我们停留在需求分析和设计阶段,等需求 ...


虽然我也同意这样的观点,但是基于某些情况,系统不稳定的状况下是无法开展自动化测试的,例如:需要使用工具进行脚本的录制。在代码和界面都没有稳定的情况下,提早开展自动化测试只会提高后期的维护脚本的成本。
作者: ami冰河    时间: 2010-1-4 14:18
标题: 在手工Regression Test后进行自动化测试
虽然说在手工测试后开展自动化测试,但是对于自动化测试的准备工作则需要与手工测试进行同步的展开。例如计划的执行,场景的分析等。
作者: shaofei19820625    时间: 2010-1-4 14:50
原帖由 jimmyseraph 于 2009-12-30 16:06 发表
这一点我持反对意见。
为什么一定要在系统稳定的情况下才用自动化测试呢?这种传统思维祸害不小。
反问一句,在系统还不稳定,需求改动量很大的情况下,要不要写代码?是不是我们停留在需求分析和设计阶段,等需求 ...

我是觉得3楼的和7楼的好像不是在说同一个问题。3楼和7楼说的都有道理,应该是一个结合。
自动化如果要做,肯定越早投入越好(7楼的观点),之前我们公司有做一个大型重构项目,自动化的脚本和开发程序基本是一前一后的,就是说开发实现一个模块就要提交一个模块的说明出来给自动化小组,自动化小组紧接着马上开展自动化脚本的编写。
但是写好的自动化脚本在什么时候去用最合适?肯定是在系统稳定的时候去用比较合适啊。(3楼的观点)
另外,狂顶一下6#的,说的相当好!!

[ 本帖最后由 shaofei19820625 于 2010-1-4 14:52 编辑 ]
作者: UU1983    时间: 2010-1-4 17:10

作者: lantianwei    时间: 2010-1-4 17:42
1。评估哪些能自动化哪些不能
2。评估哪些值得自动化哪些不值
3。评估有多少资源来做自动化在有效的时间内
4。 完美结合需要一平台进行支撑
作者: 测来测去    时间: 2010-1-4 22:57
很简单,从自动化和手工的需求入手。
手工测试目的在于能够更好的覆盖需求,更快的找出bug。
自动化测试目的更多的在于回归,这基本上也是自动化测试多数情况下存在的价值。
从需求上不难看出,粗略的讲自动化测试的输入就是手工测试的输出。
所以我认为比较合理的安排方法就是手工与自动化并行。
1、在手工测试刚开始分析需求,设计案例的时候,自动化测试进行独立的自动化测试环境的搭建,以及对被测系统在自动化中可能遇到的问题进行分析、试验并解决。(例如被测系统的开发语言能否与选用的自动化工具兼容;自动化过程中是否存在外设,是否需要仿真等等)。
2、在以上测试初步过程完成后,手工测试开始进入了测试执行阶段,而这时自动化测试就可以将自动化案例进行自动化了。
我觉得大概其应该是这样的。

作者: UU1983    时间: 2010-1-5 11:06
大家多多发言
作者: 白发三千    时间: 2010-1-5 12:35
自动化这个概念太广了,不知道楼主专指功能自动化测试,还是泛指自动化测试
作者: UU1983    时间: 2010-1-5 14:09
ding
作者: thjk2009testing    时间: 2010-1-5 15:14
MARK
作者: freedom_me    时间: 2010-1-6 10:30
呵呵 新人学习~
坚决**22#用刺眼字体颜色
作者: UU1983    时间: 2010-1-6 11:22
呵呵,如果研发的为自己的面包发愁也许会
作者: 1316016    时间: 2010-1-6 18:46
大家好多都是在说自动化和手动测试分工的问题,总是在谁测哪部分,谁更适合测试哪部分种纠缠,这只是二者结合的一部分,一个小部分,当这个问题解决了之后,还会有更多的问题困扰我们。以下,我们将一一道来。
我们现将自动测试粗略的分为如下几个阶段,并讨论在各阶段,经常出现的矛盾及误会,该如何配合:
1.整体的测试策略
最重要的问题就是哪些Case要做自动化?也就是大家常说的分工问题。可以从以下几个方面考量:
  a).根据自己Team的实际情况,来选择自动化的程度,如:自动化人充足,或者技术高,就可以多选一些Case;如果自动化刚起步,就可以选择一些简单的,重复的Case实现。
  b).老板或客户的要求.现实中,自动化的比例也多数会被领导要求,搞一些形象工程,强制某些模块或者什么的自动化比例多少,我们必须硬着头皮做的。
  c).传统的Case分割。比如,重复的,稳定的,等等Case适合做的,我们就拿来做。之所以把这项放在最后,想说明的就是虽然这个是评判Case是否自动化的最根本标准,但是面对a)和b)状况的时候,我们只能在一定范围内应用c)的策略。
总之,根据各公司的策略可以分出要哪些自动化。这时看似和自动手动测试无关,是highlevel的事情,但是,如果各方的test leader有远见的话,在后续的执行力上是有很大差异的。
2.测试脚本生成
当测试策略订定,下面面对的就是自动化脚本生成了
大多数的状况下,写自动化Case的范本,是基于手动测试的测试用例,很少有直接对需求人员的,这对自动化开发人员了解需求和手动测试用例都是很大的考验。结果,问题出来了:
   a).编写自动化脚本的人,往往会对业务逻辑不太熟悉,这个时候就需要和手动测试人员沟通,而在沟通的时候,势必会影响手动测试的正常进行,部分手动人员则不配合或消极配合。
   b).在沟通的过程中,手动测试的人员往往无法设想到自动化的情境,认为某个功能实现自动化很容易或者很不容易,自动化人员则又认为手动人员什么也不懂,无法沟通.
以上的问题都是我们切身经历过的,针对这样的状况,我的建议是:在平常的时候,手动测试的人员要了解一下本公司主流的自动测试工具及流程,对自己能力也是一种提升。自动测试人员也要多去了解业务逻辑和一些手动测试的技能,而不是单纯的坐为一个开发者。总之,这个阶段一旦出现问题,就不是一时半会可以解决的,而且相当影响双方的士气。
3.测试比对
当测试脚本写好后,如何判断这个脚本是可以替代手工测试的?这个决定着手动测试对自动脚本的信任度的问题,更决定着一个自动脚本好坏的时候。衡量自动化好坏有两个标准:
1).测试Pass的,则确实是Pass的
2).测试为Fail的,则即为Bug.
    如果这二者都可以达到,那就是个完美的Project了。不过,当前能做到这些的有几个呢?我们还没有找到真理,我们在通向真理的路上......
    针对第一个,我认为通过努力,是可以实现的。如果测试步骤,数据和检查点都是和手动测试人员确认过的,并且我们在写脚本的时候也有很细致的出入口判断,这个标准是很容易攻破的。但是说起来容易,做起来难,每个人设计Case的思路和步骤都是不一样的,同样的Case, 让不同的人操作,都可能有不同的结果,又如何保证一个机器的操作呢?这里最强调的就是检查点,有时人眼测到这个界面,可以看到有Error message或者其他,就会认为有问题,但是脚本只看设定的那几个点,如果那几个点都是没有问题的,脚本则会视为成功。所以,在沟通checkpoint时,手动人员要尽量详细说一下哪几个点或者容易出错的地方,否则漏了就是漏了,有些时候,有些检查点是人下意识就去检查了,他并没有意识到这是个checkpoint,就很可能造成遗漏。
    针对第二个,业界也是不可避免的。不过自动化人员可以通过某些技术手段,使得自己的脚本更健壮一些。也希望手动测试的GGMM们体谅这一点,自动的东西,有些时候会有一些诡异的事情发生,科学所无法解释的,只要这样的问题控制在一定比例,就还可以接受的,不要因为这一点点的瑕疵,而否定所有自动化的成果,这样我们会很伤心的。。。
4.测试执行
自动测试脚本全部写好后,需要执行一轮测试时,这个时候又该怎么办呢?我怎么知道哪些Case是自动会跑的,又有哪些是需要手动测试的呢?
目前我们的做法是,对已有的测试管理工具进行二次开发,将已经实现自动化的Case做标记和关联。当启动一轮测试时,自动化脚本运行的同时,将会手动执行标记为没有自动化的Case 。当脚本运行完,如果有Failed case,再手动check是脚本的问题还是Bug.
看似完美的一次合作就执行完了,还有什么问题吗?往下看。。。
5.自动化报告的可读性
一般情况下,一个自动的Case会涵盖多个手动测试所谓的Case, 当一个自动Case 失败之后,如何判断是哪个手动case失败呢?定位到手动测试case之后,如何判断该 case 是脚本问题还是Bug? 这个问题如果抛给直接开发这个case的人,可能他都要分析很久,那如何让一名手动的测试人员很快的定位问题呢?这就涉及到了自动脚本运行完成后的测试报告了。
测试报告的格式和内容也需要和手动测试人员反复沟通确认的,而不是自动人员一厢情愿的写自己认为很不错的报告,其实没有人能看懂。

总之,在面对这样合作的问题时,我们多换位思考一下,无论自动手动,我们都是一个名字,叫QA,只要都这样想,无论面对什么样的环境,我们的合作都会很融洽的。

以上是我作为一个自动测试人员的看法和观点,希望有手动测试的人员也发表自己的看法,多沟通讨论
作者: chop123    时间: 2010-1-6 20:05
要兼顾自动化测试和手工测试,首先要有专门的自动化测试团队来做,做手工测试的团队专门负责手工测试。术业有专攻。在项目启动阶段,就让自动化测试团队介入,他们也熟悉需求,参加评审,他们的目的是弄清楚项目的哪些地方需要做自动化测试。什么样的功能值得自动化测试投入,哪些地方页面改造不大,哪些是p1p2级主流程,哪些测试数据制造比较复杂,哪些地方回归点经常要用到。这些考虑了,再决定自动化测试应该投入什么程度。自动化测试脚本一般在功能测试稳定后,就可以进行脚本制作,对开发修复某些bug,也可以通过自动化脚本回归来测试主流程是否受到影响。同时也减轻了手工测试人员的手工局限和负担。
作者: qijinhua    时间: 2010-1-6 22:08
最近也在做自动化的考虑。需要先清楚自动化测试的目的,节约成本?提高测试覆盖度?
如果是节约成本,一定要先规划,盘点测试用例库,区分出适合自动化的部分。
全集=自动+手动。
自动化用例识别的通用原则:频度高、稳定的Case,压力测试
作者: UU1983    时间: 2010-1-7 16:19

作者: zhaoprive    时间: 2010-1-8 10:50
很有意义,不过偶一直徘徊在手工测试上
作者: Jackc    时间: 2010-1-8 14:09
飘过~~~~~~

存在即有道理~~~~
作者: wzxshi    时间: 2010-1-11 11:28
都说的不错
作者: jshyy    时间: 2010-1-14 18:19
顶!!!!
作者: dulein    时间: 2010-1-17 21:25
顶~~! 31楼简单明确~
作者: 51testing-wn    时间: 2010-2-20 00:16
觉得有的同学是偏移了主题。这个问题的主题是,如何使自动测试与自动测试达到最优组合?
首先,应当理解什么是自动化测试,什么是手工测试。优缺点是什么?
其次,应该考虑项目目前的实际情况(人力、设备、自动化工具、测试工程师的技能水平)以及长远的发展方向。
我认为得搞清楚这两方面的内容,才能在实际的项目中把自动化测试和手工测试的“性能”放大到最大值。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2