上课记得一点关于QTP自动化测试的笔记

willjo

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

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

songfun

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

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

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

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

lxm

那要看情况：（理论与实际总有距离）

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

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

songfun

《测试过程》课中，可能大家在第一阶段课程的学习中印象最深刻的是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 编辑 ]

willjo

刚开始只是机械的把笔记抄上来，现在看了大家的讨论，学到了不少东西，谢谢~~

songfun

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

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

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

songfun

这位同学和我讨论技术，我喜欢 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 编辑 ]

zhou840401

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

yuyang@testing

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

stringw

可能songfeng老师表述的有点问题吧。

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

lylibra

学术帖，签名顶先

songfun

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

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

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

songfun

答疑解惑是老师的任务，而看到学员的主题以及你的回帖后，我觉得可以通过回帖来达到这个教学目的。而不是你所说的争论的意思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 发表
我相信您的知识体系是非常完整的，授课也是尽善尽美的，我没有任何怀疑您的意思。可是说实话，有多少面试官是像你一样专业、有丰富自动化经验的呀？实际情况就是这样，有经验的人觉得很多东西都是默认了的，不需 ...

sidneylover

万恶的50贴
新手区还能看到书上的内容，抄下来发的贴一点都没变

dzhot

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

qiqi

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

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

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

songfun

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

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

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

陈建军

学习  学习  再学习
听老师讲是一回事  ，要整理成思路变成自己的东西还有很多方面要考虑啊

dzhot

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

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

qiqi

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