如何使自动化测试与手工测试达到最优的结合？（09-12-29）（获奖名单已公布）(页 1) - [51Testing软件测试沙龙] - [每周一问] - 51Testing软件测试论坛软件测试 | 软件缺陷跟踪 | 软件配置工具 | 测试用例设计 | Web测试

默默巫 发表于 2009-12-29 17:46

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

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

[color=#0000ff]此话题由会员[url=http://bbs.51testing.com/viewthread.php?tid=129915&page=1#pid960530]centurystone[/url]提供，如果你也有问题想提出来和大家一起讨论，[/color][url=http://bbs.51testing.com/thread-129915-1-1.html][color=red]请点击此处>>[/color][/url]
[color=#0000ff]说不定下期讨论的问题就是由你提出的哦，请快快参与吧！[/color]
[color=#0000ff][/color]
[img]http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif[/img]

[align=center][table=345][tr][td][align=center][font=宋体][size=2][color=#ff0000]获奖名单[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#0000ff]奖项[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]获奖名单[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]奖励[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]答案链接[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]一等奖[/color][/size][/font][/align][/td][td][align=center][size=2][color=black]1316016[/color][/size][/align][/td][td][align=center][font=宋体][size=2][color=#000000]50元当当网礼品[/color][/size][/font][/align][/td][td][align=center][font=宋体][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=178992&page=2#pid1401372][font=宋体][size=2][color=#000000]32#[/color][/size][/font][/url][/color][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2]二等奖[/size][/font][/align][/td][td][align=center][size=2][color=#000000]five3[/color][/size][/align][/td][td][align=center][font=宋体][size=2]300论坛积分[/size][/font][/align][/td][td][align=center][font=宋体][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=178992&page=2#pid1401351][font=宋体][size=2][color=#000000]31#[/color][/size][/font][/url][/color][/font][/align][/td][/tr][/table][/align]

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、无招胜有招
如何达到我们的测试目的是我们工作的根本，至于何时采用自动化测试，何时采用手工测试，做什么必须要自动化测试，做什么必须要手工测试，不要拘泥形式，每个人都有自己的测试习惯和测试风格，并不是都有一定的套路，从需要出发，这样才能将自动化测试和手工测试完美结合。

jimmyseraph 发表于 2009-12-30 16:06

回复 3# 的帖子

这一点我持反对意见。
为什么一定要在系统稳定的情况下才用自动化测试呢？这种传统思维祸害不小。
反问一句，在系统还不稳定，需求改动量很大的情况下，要不要写代码？是不是我们停留在需求分析和设计阶段，等需求稳定下来了再写代码，成本会小很多呢？恐怕大部分人会觉得就算系统还不稳定，需求改动量很大，我们还是会进行编码吧，否则岂不是连个可运行的输出都没有？既然代码都可以写，那为什么测试脚本不能写？恐怕还是因为潜意识里把开发和测试完全割裂开来的缘故吧。
我的观点是，越是不稳定的系统，需求变更越频繁，自动化测试越是要尽早开展，只有这样才能使系统尽快稳定下来，在不断有新需求修改的情况下保证代码重构是稳定的，不会对其他部分造成冲击。这是符合敏捷理念的。
自动化测试应该尽可能去覆盖所有的功能和全部的通用场景以及大部分的性能测试，将手工测试从这部分重复劳动中解放出来，使手工测试能够集中经历关注那些异常的、极限的应用场景，和重要性能的标杆比拼。这样的手工测试是具有创造性的，更能够使测试人员获得成就感。

UU1983 发表于 2009-12-31 09:07

是的，如果以个人的角度来看，这些都无所谓，因为你只要拿工资就行了，其他的不必考虑，只要老板给的合适，你会很乐意这么做，但是从企业的角度来看，这无疑是增加了成本，什么都所以要钱的，请一个合格的自动化测试工程师价格不菲，何况这中情况，不是一个或者两个就可以，现在中国的it产业是以中小型企业为主，如果是微软，甲骨文那样的公司这样的成本只是九牛一毛，但是对于中小型企业来说，是高昂的，你的成就感并不是企业的需求，企业的需求永远是用最少的成本创造对大的利润，我们必须正视这一点。
所以中国的IT产业道路并不平坦，达到规范化还是有一段距离

UU1983 发表于 2009-12-31 09:11

正视企业需求来谈手工和自动化的结合

我们必须正视当今企业需求，才能和实际结合，不然就是空谈
是毫无意义的
及时你的是最优但是你的公司并不允许用这样的物力支持你，你的再好有什么用呢？

jimmyseraph 发表于 2009-12-31 09:19

回复 8# 的帖子

ok，咱们来谈成本。不管是大企业还是小企业，都会考虑成本，就像你说的微软和甲骨文，他们难道会不考虑自动化测试的成本吗？他们的项目都是相当大的，产品的规模根本不是中国的中小企业所能想象的，自动化测试的成本绝对不是你所说的九牛一毛，他们坚持自动化的原因是什么？当然是因为自动化能帮助他们降成本！中小企业为什么不能做？为什么会手工测试成本低，自动化测试成本高？这本身就是误解。从全流程的角度看成本，自动化是非常有效的降成本手段。如果不是因为自动化能降低成本，早就无法发展了。

jimmyseraph 发表于 2009-12-31 09:26

回复 9# 的帖子

不能站在测试部的角度来谈成本，成本一定是全流程的，包括前期的市场分析，后期的运营维护，以及中间的一切，都是成本。仅仅站在测试的角度谈成本只是盲人摸象。

UU1983 发表于 2009-12-31 09:30

现实就是这样

企业看效益，如果他一年只赚100万还是毛利润，你认为他会像微软一样，五脏俱全吗，别说一年一百万，我们这部门的毛利润是1.8个亿，可是我们的测试工程师不到10个，自动化的2人，还都是初级的那种，根据我以前的工作经历，国内的企业在认知度上就有很大的差距，说白了就算他赚3个亿，也不会掏出100万来请像样的自动化工程师，因为他并不能直接的看到利润。不过我要攒下日本的IT企业，测试的规模和国内相比是一个天一个地，为什么他们会形成这样的规模呢，日本人傻吗，从他们做出的产品来看，是不傻的，归根结底是认知度，国内的企业要达到这样的认知度，可不是几天的事情，我们处于发展中国家都多少年了，所以大家不要心急，路还是要一步一步的走出来。

UU1983 发表于 2009-12-31 09:32

偶还是很有信心的:loveliness:
大家还是讨论下在国内的形势下怎样做到最优的结合吧

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

ami冰河 发表于 2010-1-4 14:18

在手工Regression Test后进行自动化测试

虽然说在手工测试后开展自动化测试，但是对于自动化测试的准备工作则需要与手工测试进行同步的展开。例如计划的执行，场景的分析等。

shaofei19820625 发表于 2010-1-4 14:50

[quote]原帖由 [i]jimmyseraph[/i] 于 2009-12-30 16:06 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=1397127&ptid=178992][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
这一点我持反对意见。
为什么一定要在系统稳定的情况下才用自动化测试呢？这种传统思维祸害不小。
反问一句，在系统还不稳定，需求改动量很大的情况下，要不要写代码？是不是我们停留在需求分析和设计阶段，等需求 ... [/quote]
我是觉得3楼的和7楼的好像不是在说同一个问题。3楼和7楼说的都有道理，应该是一个结合。
自动化如果要做，肯定越早投入越好（7楼的观点），之前我们公司有做一个大型重构项目，自动化的脚本和开发程序基本是一前一后的，就是说开发实现一个模块就要提交一个模块的说明出来给自动化小组，自动化小组紧接着马上开展自动化脚本的编写。
但是写好的自动化脚本在什么时候去用最合适？肯定是在系统稳定的时候去用比较合适啊。（3楼的观点）
另外，狂顶一下6#的，说的相当好！！

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

UU1983 发表于 2010-1-4 17:10

顶

lantianwei 发表于 2010-1-4 17:42

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

测来测去 发表于 2010-1-4 22:57

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

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

jimmyseraph 发表于 2010-1-6 09:49

原来还有这么多观念守旧的……
首先，自动化测试并不单指测试人员的自动化测试，研发人员自己进行的单元测试同样可以是自动化测试。单元测试自动化是趋势，而且自动化也很方便，在VS2005开始就内嵌了这一块功能，方便开发人员随时写随时测。这一部分根本就和系统是否稳定、需求是否稳定无关，既然能写代码，自然就能进行自动化单元测试，甚至可以写一个自动化用例，写一小段代码运行一下，这就是代码和用例同时演进的TDD方式。
其次，测试人员现在也提倡与开发要紧密结合，现在大家不都在追捧敏捷开发吗，就以敏捷开发为例。为什么敏捷开发能应对需求的不断变化？是因为它实现了小粒度交付，把最稳定的用户需求先做出来，难道测试就做不到？开发与测试在本质上是一样的。测试同样可以按照研发的节奏先测最稳定的。所以说害怕需求变更而不去实现测试自动化的理由根本不成立。而且自动化测试对需求的覆盖比手工测试更全面，效率更高，目前自动化测试薄弱的地方是对复杂场景的模拟，这一点可以用手工去覆盖。
请注意自动化测试绝不仅仅是用LR或者QTP去录脚本，测试人员要对写测试脚本非常熟练，只会做功能层面的手工测试是没有发展前途的。

freedom_me 发表于 2010-1-6 10:30

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

UU1983 发表于 2010-1-6 11:22

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

jimmyseraph 发表于 2010-1-6 11:43

其实大家这种想法我也理解。因为在很多小公司里，研发的设计能力很差，在开发完全完成之前连一个可运行的系统都没有。原因就是特性间的耦合性太强，结构不合理，每个特性都不具备独立交付能力。表象层（界面）与处理层也没有解藕，导致没界面就做不了测试。这些都是开发人员的设计能力太差，编码没有规范，随便想到什么就写什么。从程序语言的发展来看，为什么会出现“面向对象”、“抽象”、“虚函数、虚类”、“接口”、“mock”技术？这是一种趋势，程序语言一直在试图让函数、功能、特性更独立，更方便应对需求变更（我们都知道，接口设计是一个非常好的应对需求变更的技术）。但是很多程序员都没有编写结构化代码的意识。我觉得在这种情况下更要进行测试自动化，用自动化测试来推动研发更合理的进行设计，让代码的可测性提高，同时也就自然而然提升了质量。如果抱着等研发自己改变的想法，那么测试永无出头之日。

five3 发表于 2010-1-6 18:01

自动化回归本位就是为了提高效率，简化繁冗的工作。另外还有就是做某些人为不能做的（这种就不说了，因为你必须要用自动化没有选择的）。
所以要不要自动化，就要看能不能实现提高效率了，不管是从长远还是眼前。

主要因素大概有以下一些（不是所有）：
1。产品是否长期稳定
2。自动化是否容易实现
3。自动化工程师的能力是否达到要求
。。。

注意自动化的介入时间点：
1。等手动测试稳定后再开始跑自动化
2。手动和自动的人员分工明确，2者并行执行各自的任务
。。。

当然这只是一般概念上的，没有一种固定的说法能适合所有的情况。体味理解了初衷，细节需要自己结合实际情况分析。
而且自动化和手动也是没有绝对之分。正常测试都是手动和自动相结合的，只是我们没有细化。

总结：手动是正道，自动化是补充和升华。没有做自动化的都想做自动化。做了自动化了以后可能就会在想手动可能更接近测试的本质。
因为测试一部分来说是测试我们预定和知道的情况，另一部分其实是在测试我们不知道的隐藏的错误，而这些通常在使用中才能出现。
但是作为一名测试人员要具备做自动化能力的无可厚非的。所以努力。

1316016 发表于 2010-1-6 18:46

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

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

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楼简单明确~

页: [1] 2

51Testing软件测试论坛 's Archiver