如何使自动化测试与手工测试达到最优的结合？（09-12-29）（获奖名单已公布）

默默巫

如何使自动化测试与手工测试达到最优的结合？


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

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

51testing-wn

觉得有的同学是偏移了主题。这个问题的主题是，如何使自动测试与自动测试达到最优组合？
首先，应当理解什么是自动化测试，什么是手工测试。优缺点是什么？
其次，应该考虑项目目前的实际情况（人力、设备、自动化工具、测试工程师的技能水平）以及长远的发展方向。
我认为得搞清楚这两方面的内容，才能在实际的项目中把自动化测试和手工测试的“性能”放大到最大值。

dulein

顶~~！ 31楼简单明确~

jshyy

顶!!!!

wzxshi

都说的不错

Jackc

飘过~~~~~~

存在即有道理~~~~

zhaoprive

很有意义，不过偶一直徘徊在手工测试上

UU1983

顶

qijinhua

最近也在做自动化的考虑。需要先清楚自动化测试的目的，节约成本？提高测试覆盖度？
如果是节约成本，一定要先规划，盘点测试用例库，区分出适合自动化的部分。
全集=自动+手动。
自动化用例识别的通用原则：频度高、稳定的Case，压力测试

chop123

要兼顾自动化测试和手工测试，首先要有专门的自动化测试团队来做，做手工测试的团队专门负责手工测试。术业有专攻。在项目启动阶段，就让自动化测试团队介入，他们也熟悉需求，参加评审，他们的目的是弄清楚项目的哪些地方需要做自动化测试。什么样的功能值得自动化测试投入，哪些地方页面改造不大，哪些是p1p2级主流程，哪些测试数据制造比较复杂，哪些地方回归点经常要用到。这些考虑了，再决定自动化测试应该投入什么程度。自动化测试脚本一般在功能测试稳定后，就可以进行脚本制作，对开发修复某些bug，也可以通过自动化脚本回归来测试主流程是否受到影响。同时也减轻了手工测试人员的手工局限和负担。

1316016

大家好多都是在说自动化和手动测试分工的问题，总是在谁测哪部分，谁更适合测试哪部分种纠缠，这只是二者结合的一部分，一个小部分，当这个问题解决了之后，还会有更多的问题困扰我们。以下，我们将一一道来。
我们现将自动测试粗略的分为如下几个阶段，并讨论在各阶段，经常出现的矛盾及误会，该如何配合：
１．整体的测试策略
最重要的问题就是哪些Case要做自动化？也就是大家常说的分工问题。可以从以下几个方面考量：
　　ａ）．根据自己Ｔｅａｍ的实际情况，来选择自动化的程度，如：自动化人充足，或者技术高，就可以多选一些Ｃａｓｅ；如果自动化刚起步，就可以选择一些简单的，重复的Ｃａｓｅ实现。
　　ｂ）．老板或客户的要求．现实中，自动化的比例也多数会被领导要求，搞一些形象工程，强制某些模块或者什么的自动化比例多少，我们必须硬着头皮做的。
　　ｃ）．传统的Ｃａｓｅ分割。比如，重复的，稳定的，等等Ｃａｓｅ适合做的，我们就拿来做。之所以把这项放在最后，想说明的就是虽然这个是评判Ｃａｓｅ是否自动化的最根本标准，但是面对ａ）和ｂ）状况的时候，我们只能在一定范围内应用ｃ）的策略。
总之，根据各公司的策略可以分出要哪些自动化。这时看似和自动手动测试无关，是ｈｉｇｈｌｅｖｅｌ的事情，但是，如果各方的ｔｅｓｔ　ｌｅａｄｅｒ有远见的话，在后续的执行力上是有很大差异的。
２．测试脚本生成
当测试策略订定，下面面对的就是自动化脚本生成了
大多数的状况下，写自动化Ｃａｓｅ的范本，是基于手动测试的测试用例，很少有直接对需求人员的，这对自动化开发人员了解需求和手动测试用例都是很大的考验。结果，问题出来了：
   ａ）．编写自动化脚本的人，往往会对业务逻辑不太熟悉，这个时候就需要和手动测试人员沟通，而在沟通的时候，势必会影响手动测试的正常进行，部分手动人员则不配合或消极配合。
   ｂ）．在沟通的过程中，手动测试的人员往往无法设想到自动化的情境，认为某个功能实现自动化很容易或者很不容易，自动化人员则又认为手动人员什么也不懂，无法沟通．
以上的问题都是我们切身经历过的，针对这样的状况，我的建议是：在平常的时候，手动测试的人员要了解一下本公司主流的自动测试工具及流程，对自己能力也是一种提升。自动测试人员也要多去了解业务逻辑和一些手动测试的技能，而不是单纯的坐为一个开发者。总之，这个阶段一旦出现问题，就不是一时半会可以解决的，而且相当影响双方的士气。
３．测试比对
当测试脚本写好后，如何判断这个脚本是可以替代手工测试的？这个决定着手动测试对自动脚本的信任度的问题，更决定着一个自动脚本好坏的时候。衡量自动化好坏有两个标准：
１）．测试Ｐａｓｓ的，则确实是Ｐａｓｓ的
２）．测试为Ｆａｉｌ的，则即为Ｂｕｇ．
    如果这二者都可以达到，那就是个完美的Ｐｒｏｊｅｃｔ了。不过，当前能做到这些的有几个呢？我们还没有找到真理，我们在通向真理的路上．．．．．．
    针对第一个，我认为通过努力，是可以实现的。如果测试步骤，数据和检查点都是和手动测试人员确认过的，并且我们在写脚本的时候也有很细致的出入口判断，这个标准是很容易攻破的。但是说起来容易，做起来难，每个人设计Ｃａｓｅ的思路和步骤都是不一样的，同样的Ｃａｓｅ，　让不同的人操作，都可能有不同的结果，又如何保证一个机器的操作呢？这里最强调的就是检查点，有时人眼测到这个界面，可以看到有Ｅｒｒｏｒ　ｍｅｓｓａｇｅ或者其他，就会认为有问题，但是脚本只看设定的那几个点，如果那几个点都是没有问题的，脚本则会视为成功。所以，在沟通ｃｈｅｃｋｐｏｉｎｔ时，手动人员要尽量详细说一下哪几个点或者容易出错的地方，否则漏了就是漏了，有些时候，有些检查点是人下意识就去检查了，他并没有意识到这是个ｃｈｅｃｋｐｏｉｎｔ，就很可能造成遗漏。
    针对第二个，业界也是不可避免的。不过自动化人员可以通过某些技术手段，使得自己的脚本更健壮一些。也希望手动测试的GGMM们体谅这一点，自动的东西，有些时候会有一些诡异的事情发生，科学所无法解释的，只要这样的问题控制在一定比例，就还可以接受的，不要因为这一点点的瑕疵，而否定所有自动化的成果，这样我们会很伤心的。。。
４．测试执行
自动测试脚本全部写好后，需要执行一轮测试时，这个时候又该怎么办呢？我怎么知道哪些Ｃａｓｅ是自动会跑的，又有哪些是需要手动测试的呢？
目前我们的做法是，对已有的测试管理工具进行二次开发，将已经实现自动化的Ｃａｓｅ做标记和关联。当启动一轮测试时，自动化脚本运行的同时，将会手动执行标记为没有自动化的Ｃａｓｅ 。当脚本运行完，如果有Ｆａｉｌｅｄ　ｃａｓｅ，再手动ｃｈｅｃｋ是脚本的问题还是Ｂｕｇ．
看似完美的一次合作就执行完了，还有什么问题吗？往下看。。。
5．自动化报告的可读性
一般情况下，一个自动的Case会涵盖多个手动测试所谓的Case, 当一个自动Case 失败之后，如何判断是哪个手动case失败呢？定位到手动测试case之后，如何判断该 case 是脚本问题还是Bug? 这个问题如果抛给直接开发这个case的人，可能他都要分析很久，那如何让一名手动的测试人员很快的定位问题呢？这就涉及到了自动脚本运行完成后的测试报告了。
测试报告的格式和内容也需要和手动测试人员反复沟通确认的，而不是自动人员一厢情愿的写自己认为很不错的报告，其实没有人能看懂。

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

以上是我作为一个自动测试人员的看法和观点，希望有手动测试的人员也发表自己的看法，多沟通讨论

UU1983

呵呵，如果研发的为自己的面包发愁也许会

freedom_me

呵呵 新人学习~
坚决**22#用刺眼字体颜色

thjk2009testing

MARK

UU1983

ding

白发三千

自动化这个概念太广了，不知道楼主专指功能自动化测试，还是泛指自动化测试

UU1983

大家多多发言

测来测去

很简单，从自动化和手工的需求入手。
手工测试目的在于能够更好的覆盖需求，更快的找出bug。
自动化测试目的更多的在于回归，这基本上也是自动化测试多数情况下存在的价值。
从需求上不难看出，粗略的讲自动化测试的输入就是手工测试的输出。
所以我认为比较合理的安排方法就是手工与自动化并行。
1、在手工测试刚开始分析需求，设计案例的时候，自动化测试进行独立的自动化测试环境的搭建，以及对被测系统在自动化中可能遇到的问题进行分析、试验并解决。（例如被测系统的开发语言能否与选用的自动化工具兼容；自动化过程中是否存在外设，是否需要仿真等等）。
2、在以上测试初步过程完成后，手工测试开始进入了测试执行阶段，而这时自动化测试就可以将自动化案例进行自动化了。
我觉得大概其应该是这样的。

lantianwei

1。评估哪些能自动化哪些不能
2。评估哪些值得自动化哪些不值
3。评估有多少资源来做自动化在有效的时间内
4。 完美结合需要一平台进行支撑

UU1983

顶

shaofei19820625

原帖由 jimmyseraph 于 2009-12-30 16:06 发表
这一点我持反对意见。
为什么一定要在系统稳定的情况下才用自动化测试呢？这种传统思维祸害不小。
反问一句，在系统还不稳定，需求改动量很大的情况下，要不要写代码？是不是我们停留在需求分析和设计阶段，等需求 ...

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

[ 本帖最后由 shaofei19820625 于 2010-1-4 14:52 编辑 ]