51Testing软件测试论坛

标题: 上课记得一点关于QTP自动化测试的笔记 [打印本页]

作者: willjo 时间: 2007-3-13 15:28
标题: 上课记得一点关于QTP自动化测试的笔记
上QTP时记得一点笔记，供大家参考
QTP自动化测试的思路：录制——回放

自动化测试流程：                                                 手工测试的流程：
1.录制前的准备                                                       1.准备（测试环境的搭建）
2.录制测试脚本（keyword driven  设计过程）               2.用例的设计
3.增强测试脚本（check point 同步点，参数化）          3.评审改进测试用例  （对应自动化测试的3.4项）
4.脚本调试                                                             4.测试执行.
5.运行脚本（回放）                                                 5.分析结果
6.分析结果                                                             6.提交bug
7.提交bug

旁边列举了手工测试的过程进行对比。

作者: qiqi 时间: 2007-3-13 19:14
标题: 一点意见
你的手工测试过程只是整体测试过程中一个比较小的环节。而且自动化测试同样需要用例的设计、评审和改进。再接再厉sdlkfj2

作者: songfun 时间: 2007-3-13 22:25
楼上这位qiqi同学，willjo 同学这里贴上来的只是我上课的板书，其实这个地方不是在讲解完整的测试过程，它只是关于其中的执行阶段，也就是在描述测试执行流程（process）中的具体过程（procedure）。通过这个部分把自动化测试执行的思路理一遍，并且和手工测试的过程做个类比（不是严格意义上的对比）。目的是为了引出使用自动化工具做项目的思路，而不是就QTP的功能而掌握功能，就工具而学工具。

至于你所说的process是《测试过程》课程里的内容（计划、设计、实现、执行），而评审则是贯穿在这个过程中所有输出的一个PDCA循环。
两者不是同一个东西，呵呵sdlkfj2

[ 本帖最后由 songfun 于 2007-3-15 00:23 编辑 ]

作者: songfun 时间: 2007-3-13 22:27
具体的自动化流程我以前已经描述过，可以看看我写的这篇文章：
http://www.51testing.com/html/58/2070.html

原帖由 qiqi 于 2007-3-13 19:14 发表
你的手工测试过程只是整体测试过程中一个比较小的环节。而且自动化测试同样需要用例的设计、评审和改进。再接再厉sdlkfj2

[ 本帖最后由 songfun 于 2007-3-15 12:16 编辑 ]

作者: qiqi 时间: 2007-3-14 09:34
1、对于手工测试部分，我接受楼上的理解。
2、对于自动化测试部分，我不同意楼上的说法。
楼主的意思很明显，他将 “录制测试脚本” 和 “用例的设计” 相对应，将 “增强测试脚本”、
“脚本调试 ” 与 “评审改进测试用例” 相对应，这样肯定是不对的。
3、楼上推荐的文章甚是不错，我想在软件质量要求越来越高、软件投资越来越大的未来会实现的。

作者: songfun 时间: 2007-3-15 00:16
小兄弟断章取义了sdlkfj2
这个同学的笔记只是把我上课的板书整理在一起，并没有说它们是测试过程中的一一对应关系。
列出这个地方只是告诉大家做一件事的思路，通常就是先做个计划、然后去设计、改进设计、然后才去实施（做执行），再之后去评估结果。无论是在大的流程中，还是在小的过程中，都会有类似的事要做。比如 “增强测试脚本”、 “脚本调试 ” 与 “评审改进测试用例” 这两个地方都是在“修改东西”，一个是改脚本，一个是改用例。
这里的目的是强调大家不要一拿到工具就兴冲冲的开始录制脚本什么也不考虑，而是应当先有个思路，你想验证什么，想怎么测。
其实在QTP这个工具的学习过程中，最重要的就是要把思路理顺，知道个来龙去脉了，再具体的去用工具，这样的学习会很顺，思路自始自终都很清晰。

原帖由 qiqi 于 2007-3-14 09:34 发表
1、对于手工测试部分，我接受楼上的理解。
2、对于自动化测试部分，我不同意楼上的说法。
楼主的意思很明显，他将 “录制测试脚本” 和 “用例的设计” 相对应，将 “增强测试脚本”、
“脚 ...

[ 本帖最后由 songfun 于 2007-3-15 00:29 编辑 ]

作者: qiqi 时间: 2007-3-15 10:10
也许是我断章取义了，但是楼主的 “3.评审改进测试用例（对应自动化测试的3.4项）”让人很难不去误会呀。尤其是找工作面试的时候，也许他理解得是老师讲的那样，但是这样说出来不免会让面试官怀疑他的自动化测试能力。老师你说对吗？而且对于自动化用例的设计更是要慎之又慎，不然回头修改的时候不仅要改用例还要改脚本，比手工测试所需的时间精力更加多了。
而且很多同学在就业之后不一定会做自动化方面的工作，等他们过了很久之后再回头看这样的笔记是不是也会受到误导呢？

作者: dzhot 时间: 2007-3-15 10:48

原帖由 qiqi 于 2007-3-15 10:10 发表
也许是我断章取义了，但是楼主的 “3.评审改进测试用例（对应自动化测试的3.4项）”让人很难不去误会呀。尤其是找工作面试的时候，也许他理解得是老师讲的那样，但是这样说出来不免会让面试官怀疑他的自动化 ...

同意，不管如何，willjo 出去应聘，或是工作。都应该有个清晰的思路和正确的观念，对于测试的整体的把握，而不是之鳞片抓的一些东西，让人听来似是而非。企业中测试的管理层不乏51的学员，和一些资深的测试人士，可不能砸了51的招牌啊。

作者: 陈建军 时间: 2007-3-15 11:18
标题: 学海无涯
学习学习再学习
听老师讲是一回事，要整理成思路变成自己的东西还有很多方面要考虑啊

作者: songfun 时间: 2007-3-15 12:12
先明确一个问题，“增强测试脚本、调试脚本”类似于coding阶段的代码调试，不是说自动化测试不需要做用例设计、用例的评审和修改了——完全是两码事。
难道做了需求评审、HLD评审、LLD评审之后，开发就不需要debug了吗？设计的再好，评审的再好，程序总还是需要调试的。自动化也一样。
至于“调试脚本”，这只是在修改脚本，不见得要修改对应的用例。同理，coding的时候做debug，难道就要修改LLD？这想法岂不是很荒唐？
调试的目的是什么？根本目的就是要达到预期所设计的输出（Expected Results）。如果LLD没有错，那所做的debug只是在修改代码自身的错误了。
自动化的脚本调试也是这样，这是一个不断修改、改进的过程，就像写了用例为什么要评审再修改一样。
曾子说“吾日三省无身”，也是这个道理。说白了，任何事都需要一个持续改进的过程。

呵呵，认真的态度是非常好的，只是学习的时候千万不要钻牛角尖，否则你会发现任何一个人说的话都是破绽。
我相信一个真正懂自动化的面试官是不会在这种问题上打转的，否则我要开始怀疑面试官的能力了。
我相信有听过课的同学是不会被误导的，他们所学到的是整个阶段完整的课程，而不是只鳞片爪。

原帖由 qiqi 于 2007-3-15 10:10 发表
也许是我断章取义了，但是楼主的 “3.评审改进测试用例（对应自动化测试的3.4项）”让人很难不去误会呀。尤其是找工作面试的时候，也许他理解得是老师讲的那样，但是这样说出来不免会让面试官怀疑他的自动化 ...

作者: qiqi 时间: 2007-3-15 12:59
我相信您的知识体系是非常完整的，授课也是尽善尽美的，我没有任何怀疑您的意思。可是说实话，有多少面试官是像你一样专业、有丰富自动化经验的呀？实际情况就是这样，有经验的人觉得很多东西都是默认了的，不需要去解释，可是对于那些没有经验的人来说呢？他们若发现学员没有掌握好这些基本的问题，就会从很大程度上否定我们的学员。对学生要细心，就算只是一个思路也应该尽量完整。

钻牛角尖没意思，但是我想说，据我所看到的，很多公司对培训过的又没有相关工作经验的学员并没有太大的认可，如果面对一个态度如此经验又一般的面试官，是不是应该把最这些基本的测试过程表述得基本完整呢？（是“基本完整”，不是“基本完美”）

到此为止，我不愿意再争论下去了。希望我们的学员都能前程似锦，也愿51越办越红火。

作者: dzhot 时间: 2007-3-15 13:26
我们这里说的热闹可也不见正主儿 willjo 出现
songfun 与其有时间在这里和大家翻来覆去的争长论短，不如抽点时间，询问一下willjo 看看他到底是不是掌握正确的知识。sdlkfj3

作者: sidneylover 时间: 2007-3-15 14:05
万恶的50贴
新手区还能看到书上的内容，抄下来发的贴一点都没变

作者: songfun 时间: 2007-3-15 14:16
答疑解惑是老师的任务，而看到学员的主题以及你的回帖后，我觉得可以通过回帖来达到这个教学目的。而不是你所说的争论的意思sdlkfj2
大家就事论事的去谈各自的观点，而且没有任何限制，无论是老师、学生、版主、网友，都欢迎。‘

不知道你是不是真的认真的去看了我的回复，我解释过，那个笔记不是关于测试过程的，也不是在介绍软件的生命周期。完整的测试过程应该在《测试过程》课程上讲，QTP课只讲关于QTP和自动化的知识，任何其他知识都是为了这个主题。至于你所说的完整的自动化测试过程的具体描述，我之前已经有过完整的阐述（http://www.51testing.com/html/58/2070.html）。
你非要把我课上所说的“做一件事的流程”认定是“测试过程里的过程”，这很无奈。而且尴尬的是，针对测试过程这个知识点，你一边在否定我（同学的笔记和我的回帖），一边在肯定我（说我的 http://www.51testing.com/html/58/2070.html 文章“甚是不错”）。

至于面试官，那取决于他们的个人素质，我认为和自动化不自动化没有关系。
我们16期的学员还碰到过某公司的面试官，说：“要是早知道你是51testing的，我就不会让你进来面试（原话不知道是不是这样，大致这个意思）”。请问对于这种面试官，我们还有必要跟他解释什么问题吗？sdlkfj2

我通过回帖希望参加学习的同学能容易把握到学习重点，高效的掌握这个阶段的课程——这就够了。

原帖由 qiqi 于 2007-3-15 12:59 发表
我相信您的知识体系是非常完整的，授课也是尽善尽美的，我没有任何怀疑您的意思。可是说实话，有多少面试官是像你一样专业、有丰富自动化经验的呀？实际情况就是这样，有经验的人觉得很多东西都是默认了的，不需 ...

作者: songfun 时间: 2007-3-15 14:18
不是争长论短，而是答疑解惑、沟通交流——性质一旦改变，会导致个人的理解偏差。
无论前面回了多少贴，都可以看到：我一直在围绕着技术本身去说。
sdlkfj2

原帖由 dzhot 于 2007-3-15 13:26 发表
我们这里说的热闹可也不见正主儿 willjo 出现
songfun 与其有时间在这里和大家翻来覆去的争长论短，不如抽点时间，询问一下willjo 看看他到底是不是掌握正确的知识。sdlkfj3

[ 本帖最后由 songfun 于 2007-3-15 15:02 编辑 ]

作者: lylibra 时间: 2007-3-15 16:04
学术帖，签名顶先

作者: stringw 时间: 2007-3-15 16:27
可能songfeng老师表述的有点问题吧。

自动化测试只是用技术手段代替了手工的执行过程。所以它要比也是
和手工测试的执行阶段比。而且帖子里写得是自动化测试的流程和手
工测试的过程，可以比吗？
另外，有点疑惑的是，环境的搭建到了用例设计的前面吗？系统测
试的用例在需求后就要写了，这么早搭环境干吗？
难说面试官会不会问出这样的问题。楼主准备怎么回答？

作者: yuyang@testing 时间: 2007-3-15 18:05
标题: 楼主该出来说说话了~~~
看了上面的老师和qiqi的争论，觉得问题就出在楼主这份完全copy的板书上，没有添加任何个人的理解在里面，过程大家都了解，那么发这个帖子的意义究竟在哪呢？最好讲清楚，老师的知识传授到你那里究竟接受了多少。板书只是一个总结，但是很多东西都没有被表达清楚，或许老师想教授的东西是对的，但是难说人家只看了板书之后不会产生其他想法，重要的是楼主怎么想的？

作者: zhou840401 时间: 2007-3-15 18:29
有争论才有进步，我也来想几句，是自己对功能自动化的理解，录制回放在自动化实施的整个过程当中，时间占的比例应该是很少很少的一部分，而且我相信大部分的脚本是手工写出来的，因为程序刚开始未必能够运行得通。想问一个songfeng老师，根据你以往的经验，自动化的用例如何设计呢？还有脚本应该如何来编写，我指的自动化是数据驱动自动化。

作者: songfun 时间: 2007-3-15 18:38
这位同学和我讨论技术，我喜欢 sdlkfj3

关键是举的例子太接近了，可能反而误会了。换个例子，
例子A：
某公司打算盖个大楼。流程： 1.准备（可能包括计划的制定和一部分资源的落实） 2.设计方案 3.建筑专家们评审改进设计方案（包括建立各种模型去论证它） 4. 工人们盖楼 5. 盖完后评估这个工程实施的情况和结果 6. 把总结的问题汇总起来，为下一次的工程项目提供有力的经验数据。

拿这个例子做比较，可能会好一些，虽然它不是测试的过程，但是思路都是一样的：事前做准备，然后做设计，然后调整设计，然后去实施，实施的过程还有一个调整的过程，都实施完了做一次评估，给将来做借鉴。

下面说环境搭建。
在上课的时候，我们都说环境搭建是在实现阶段做的事（因为我们学的是V模型，它严格定义了各个阶段的先后顺序），但实际在企业当中往往不可能这么严格的。这得具体情况具体分析。
测试环境分硬件环境、软件环境。其中有些部分的确可能在前期准备阶段就要开始搭建了，比如硬件配置（需要一台HP UX），这个前期不搭建好会影响到后续的工作。

其实在企业当中实施测试工作，不太可能象我们上课学的V模型那样：各个阶段是严格的串行关系，等设计完了用例再去部署环境。因为这从项目管理的角度来看是很糟糕的，事实上，这个过程通常采用H模型，环境搭建和用例设计同步展开，他们没有时间先后的必然顺序，完全可以同步展开。只不过其中有一部分必须等到用例设计完了才能完成——比如用例中要求提供一些测试数据，这涉及到环境的，就必须等用例设计完才能完成。

透过现象看本质，我们能得出这样的结论：关键不在过程顺序的正确还是错误，而在你们的企业选取什么样的测试模型来实施测试过程。

以上，就是我回答的“如果面试官出这样的问题”的回答，欢迎 stringw 同学回帖交流。

原帖由 stringw 于 2007-3-15 16:27 发表
可能songfeng老师表述的有点问题吧。

自动化测试只是用技术手段代替了手工的执行过程。所以它要比也是
和手工测试的执行阶段比。而且帖子里写得是自动化测试的流程和手
工测试的过程，可以比吗？
另外 ...

[ 本帖最后由 songfun 于 2007-3-15 21:17 编辑 ]

作者: songfun 时间: 2007-3-15 18:59
对的，录制只是其中很小的一段时间，后期的脚本调试、以及脚本维护（比如需求变更了，自动化脚本也要做相应的修改，对吧）可能要占用很大的比例。
这就是我们所强调的自动化实施不是想当然的，而是要充分评估，考虑我们的投入产出比的。

自动化的用例——如果是功能测试的话，可以选取系统测试的预测试项来做，脚本的编写要考虑复用性、可扩展性，和开发编程一样，也要遵循高内聚低耦合的思路。

原帖由 zhou840401 于 2007-3-15 18:29 发表
有争论才有进步，我也来想几句，是自己对功能自动化的理解，录制回放在自动化实施的整个过程当中，时间占的比例应该是很少很少的一部分，而且我相信大部分的脚本是手工写出来的，因为程序刚开始未必能够运行得通。想问一个songfeng老师，根据你以往的经验，自动化的用例如何设计呢？还有脚本应该如何来编写，我指的自动化是数据驱动自动化。

作者: willjo 时间: 2007-3-15 20:16
刚开始只是机械的把笔记抄上来，现在看了大家的讨论，学到了不少东西，谢谢~~

作者: songfun 时间: 2007-3-15 22:08
标题: 建议大家能够从项目管理的角度去理解测试过程
《测试过程》课中，可能大家在第一阶段课程的学习中印象最深刻的是V模型，而对于W模型、H模型则只做一些了解。
但是我觉得确实有必要说明这个H模型，在我个人看来，这个模型才是“实用派”模型，事实上的大部分企业都不知不觉中采用着H模型。

那么什么是H模型呢？解释完这个模型，我相信大家能够更加明确“环境的搭建到底和用例设计是处于什么样的阶段”？

以下摘抄一部分同学们已经有的《实用软件测试方法与应用》中的测试过程一章：

我们知道V模型也好，W模型也好，他们都有不妥之处。首先，他们都把软件的开发过程视为需求、设计、编码等一系列的串行活动。而事实上，虽然这些活动之间的确存在着互相牵制的关系，但在大部分的时间内，他们是互相独立的，是可以并发进行的。虽然我们希望在软件开发的过程中要有清晰的需求、清晰的设计等阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试也不存在严格的先后次序，只要测试条件满足，就可以进行测试。
……
其次，V模型和W模型都没能很好的表示测试流程的完整性。测试流程可以大致分为两类活动，一类是测试准备活动，包括测试需求分析、测试计划、测试分析、测试编码、测试验证等；另一类是测试执行活动，包括测试运行、测试报告、测试分析等。
……
H模型就是为改进这些缺陷而产生的。

可以从这个地方看到H模型强调的思想是：并发活动——只要条件满足，就可以开展活动。
那么串行和并行到底有什么区别呢？
我们就以环境搭建应该处于什么阶段的例子来解释。
比方说，你现在是公司的测试经理，手下有20个测试工程师。现在有一个项目给你来做，用例设计的工作量在200人天左右，环境搭建在4人天左右，……（其他的计划、评审以及测试执行的工作量这里就不列具体数字了，因为不影响下面的例子举证）。
现在有两种方案：
（一）串行方案：让20个工程师一起去写用例，那么200/20=10，需要10天的时间完成这个工作，接下来就是做环境搭建，你指派4个工程师做环境搭建，4/4=1，又用了1天，总共用去了11天；
（二）并行方案：第一天先让4个工程师去搭建环境，另外16个去写用例，第二天开始，环境搭建的任务完成了，这4位工程师的资源得以释放，他们和16位工程师一道去进行用例设计，那么这个用例设计总共耗时几天呢？(200-16*1)/20=9.2天，总共用去了 1+9.2=10.2天。

请问，如果你是测试经理，你会选取哪一种方案？
是“先写用例再搭建环境”的串行方案；还是“先抽一部分人搭建环境再一起写用例”的并行方案？
显然，如果选择了第二种方案第10天就可以开始做测试执行了，而第一种方案必须等到第12天。
如果有面试官质疑我先搭建环境的策略，那么我就会以这个例子告诉他。。。

原帖由 stringw 于 2007-3-15 16:27 发表
另外，有点疑惑的是，环境的搭建到了用例设计的前面吗？系统测
试的用例在需求后就要写了，这么早搭环境干吗？
难说面试官会不会问出这样的问题。楼主准备怎么回答？

[ 本帖最后由 songfun 于 2007-3-15 22:17 编辑 ]

作者: lxm 时间: 2007-3-16 11:41
那要看情况：（理论与实际总有距离）

如果必须用例全部完成后才能执行那么：
派1个去做环境搭建，4天完成；第5天写用例；
另外19人写用例；

如果只要环境有了就可执行；
派16人做环境搭建，2小时完成；
4人写用例，2小时后，他们完成的用例就可以执行了；

作者: songfun 时间: 2007-3-16 13:22
呵呵，意思对了。
不过你这里举的两个例子已经都是并行活动了，而且都是搭建环境和用例设计一起开展。
但是，让16个人搭建环境属于“理论”情况。做过大型系统的人会知道，事实上环境搭建有别于coding、用例设计、用例执行等工作，环境搭建属于“硬消耗”，它的耗时主要不在于“量多”，而在机器本身需要这么多耗时（硬件因素），如软件系统重部署需要多少时间、框架编译需要多少时间，而这些过程往往在很多因素干扰下可能进展缓慢，而这不是加了多少人就可以压缩部署时间的。
环境搭建好比开车，让1个人开一辆车和10个人开一辆车，结果都不能改变车速。

原帖由 lxm 于 2007-3-16 11:41 发表
那要看情况：（理论与实际总有距离）

如果必须用例全部完成后才能执行那么：
派1个去做环境搭建，4天完成；第5天写用例；
另外19人写用例；

如果只要环境有了就可执行；
派16人做环境搭建，2小时完成； ...

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)