上课记得一点关于QTP自动化测试的笔记
上QTP时记得一点笔记，供大家参考QTP自动化测试的思路：录制——回放
自动化测试流程： 手工测试的流程：
1.录制前的准备 1.准备（测试环境的搭建）
2.录制测试脚本（keyword driven 设计过程） 2.用例的设计
3.增强测试脚本（check point 同步点，参数化） 3.评审改进测试用例 （对应自动化测试的3.4项）
4.脚本调试 4.测试执行.
5.运行脚本（回放） 5.分析结果
6.分析结果 6.提交bug
7.提交bug
旁边列举了手工测试的过程进行对比。
一点意见
你的手工测试过程只是整体测试过程中一个比较小的环节。而且自动化测试同样需要用例的设计、评审和改进。 再接再厉sdlkfj2 楼上这位qiqi同学，willjo 同学这里贴上来的只是我上课的板书，其实这个地方不是在讲解完整的测试过程，它只是关于其中的执行阶段，也就是在描述测试执行流程（process）中的具体过程（procedure）。通过这个部分把自动化测试执行的思路理一遍，并且和手工测试的过程做个类比（不是严格意义上的对比）。目的是为了引出使用自动化工具做项目的思路，而不是就QTP的功能而掌握功能，就工具而学工具。至于你所说的process是《测试过程》课程里的内容（计划、设计、实现、执行），而评审则是贯穿在这个过程中所有输出的一个PDCA循环。
两者不是同一个东西，呵呵sdlkfj2
[ 本帖最后由 songfun 于 2007-3-15 00:23 编辑 ] 具体的自动化流程我以前已经描述过，可以看看我写的这篇文章：
http://www.51testing.com/html/58/2070.html
原帖由 qiqi 于 2007-3-13 19:14 发表
你的手工测试过程只是整体测试过程中一个比较小的环节。而且自动化测试同样需要用例的设计、评审和改进。 再接再厉sdlkfj2
[ 本帖最后由 songfun 于 2007-3-15 12:16 编辑 ] 1、对于手工测试部分，我接受楼上的理解。
2、对于自动化测试部分，我不同意楼上的说法。
楼主的意思很明显，他将 “录制测试脚本” 和 “用例的设计” 相对应，将 “增强测试脚本”、
“脚本调试 ” 与 “评审改进测试用例” 相对应，这样肯定是不对的。
3、楼上推荐的文章甚是不错，我想在 软件质量要求越来越高、软件投资越来越大 的未来会实现的。 小兄弟断章取义了sdlkfj2
这个同学的笔记只是把我上课的板书整理在一起，并没有说它们是测试过程中的一一对应关系。
列出这个地方只是告诉大家做一件事的思路，通常就是先做个计划、然后去设计、改进设计、然后才去实施（做执行），再之后去评估结果。无论是在大的流程中，还是在小的过程中，都会有类似的事要做。比如 “增强测试脚本”、“脚本调试 ” 与 “评审改进测试用例” 这两个地方都是在“修改东西”，一个是改脚本，一个是改用例。
这里的目的是强调大家不要一拿到工具就兴冲冲的开始录制脚本什么也不考虑，而是应当先有个思路，你想验证什么，想怎么测。
其实在QTP这个工具的学习过程中，最重要的就是要把思路理顺，知道个来龙去脉了，再具体的去用工具，这样的学习会很顺，思路自始自终都很清晰。
原帖由 qiqi 于 2007-3-14 09:34 发表
1、对于手工测试部分，我接受楼上的理解。
2、对于自动化测试部分，我不同意楼上的说法。
楼主的意思很明显，他将 “录制测试脚本” 和 “用例的设计” 相对应，将 “增强测试脚本”、
“脚 ...
[ 本帖最后由 songfun 于 2007-3-15 00:29 编辑 ] 也许是我断章取义了，但是楼主的 “3.评审改进测试用例（对应自动化测试的3.4项）”让人很难不去误会呀。 尤其是找工作面试的时候，也许他理解得是老师讲的那样，但是这样说出来不免会让面试官怀疑他的自动化测试能力。老师你说对吗？ 而且对于自动化用例的设计更是要慎之又慎，不然回头修改的时候不仅要改用例还要改脚本，比手工测试所需的时间精力更加多了。
而且很多同学在就业之后不一定会做自动化方面的工作，等他们过了很久之后再回头看这样的笔记是不是也会受到误导呢？ 原帖由 qiqi 于 2007-3-15 10:10 发表
也许是我断章取义了，但是楼主的 “3.评审改进测试用例（对应自动化测试的3.4项）”让人很难不去误会呀。 尤其是找工作面试的时候，也许他理解得是老师讲的那样，但是这样说出来不免会让面试官怀疑他的自动化 ...
同意，不管如何，willjo 出去应聘，或是工作。都应该有个清晰的思路和正确的观念，对于测试的整体的把握，而不是之鳞片抓的一些东西，让人听来似是而非。企业中测试的管理层不乏51的学员，和一些资深的测试人士，可不能砸了51的招牌啊。
学海无涯
学习学习再学习听老师讲是一回事，要整理成思路变成自己的东西还有很多方面要考虑啊 先明确一个问题，“增强测试脚本、调试脚本”类似于coding阶段的代码调试，不是说自动化测试不需要做用例设计、用例的评审和修改了——完全是两码事。
难道做了需求评审、HLD评审、LLD评审之后，开发就不需要debug了吗？设计的再好，评审的再好，程序总还是需要调试的。自动化也一样。
至于“调试脚本”，这只是在修改脚本，不见得要修改对应的用例。同理，coding的时候做debug，难道就要修改LLD？这想法岂不是很荒唐？
调试的目的是什么？根本目的就是要达到预期所设计的输出（Expected Results）。如果LLD没有错，那所做的debug只是在修改代码自身的错误了。
自动化的脚本调试也是这样，这是一个不断修改、改进的过程，就像写了用例为什么要评审再修改一样。
曾子说“吾日三省无身”，也是这个道理。说白了，任何事都需要一个持续改进的过程。
呵呵，认真的态度是非常好的，只是学习的时候千万不要钻牛角尖，否则你会发现任何一个人说的话都是破绽。
我相信一个真正懂自动化的面试官是不会在这种问题上打转的，否则我要开始怀疑面试官的能力了。
我相信有听过课的同学是不会被误导的，他们所学到的是整个阶段完整的课程，而不是只鳞片爪。
原帖由 qiqi 于 2007-3-15 10:10 发表
也许是我断章取义了，但是楼主的 “3.评审改进测试用例（对应自动化测试的3.4项）”让人很难不去误会呀。 尤其是找工作面试的时候，也许他理解得是老师讲的那样，但是这样说出来不免会让面试官怀疑他的自动化 ... 我相信您的知识体系是非常完整的，授课也是尽善尽美的，我没有任何怀疑您的意思。可是说实话，有多少面试官是像你一样专业、有丰富自动化经验的呀？实际情况就是这样，有经验的人觉得很多东西都是默认了的，不需要去解释，可是对于那些没有经验的人来说呢？他们若发现学员没有掌握好这些基本的问题，就会从很大程度上否定我们的学员。对学生要细心，就算只是一个思路也应该尽量完整。
钻牛角尖没意思，但是我想说，据我所看到的，很多公司对培训过的又没有相关工作经验的学员并没有太大的认可，如果面对一个态度如此经验又一般的面试官，是不是应该把最这些基本的测试过程表述得基本完整呢？（是“基本完整”，不是“基本完美”）
到此为止，我不愿意再争论下去了。希望我们的学员都能前程似锦，也愿51越办越红火。 我们这里说的热闹 可也不见正主儿 willjo 出现
songfun 与其有时间在这里和大家翻来覆去的争长论短，不如抽点时间，询问一下willjo 看看他到底是不是掌握正确的知识。sdlkfj3 万恶的50贴
新手区还能看到书上的内容，抄下来发的贴一点都没变 答疑解惑是老师的任务，而看到学员的主题以及你的回帖后，我觉得可以通过回帖来达到这个教学目的。而不是你所说的争论的意思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 发表
我相信您的知识体系是非常完整的，授课也是尽善尽美的，我没有任何怀疑您的意思。可是说实话，有多少面试官是像你一样专业、有丰富自动化经验的呀？实际情况就是这样，有经验的人觉得很多东西都是默认了的，不需 ... 不是争长论短，而是答疑解惑、沟通交流——性质一旦改变，会导致个人的理解偏差。
无论前面回了多少贴，都可以看到：我一直在围绕着技术本身去说。
sdlkfj2
原帖由 dzhot 于 2007-3-15 13:26 发表
我们这里说的热闹 可也不见正主儿 willjo 出现
songfun 与其有时间在这里和大家翻来覆去的争长论短，不如抽点时间，询问一下willjo 看看他到底是不是掌握正确的知识。sdlkfj3
[ 本帖最后由 songfun 于 2007-3-15 15:02 编辑 ] 学术帖，签名顶先 可能songfeng老师表述的有点问题吧。
自动化测试只是用技术手段代替了手工的执行过程。所以它要比也是
和手工测试的执行阶段比。而且帖子里写得是自动化测试的流程和手
工测试的过程，可以比吗？
另外，有点疑惑的是，环境的搭建到了用例设计的前面吗？系统测
试的用例在需求后就要写了，这么早搭环境干吗？
难说面试官会不会问出这样的问题。楼主准备怎么回答？
楼主该出来说说话了~~~
看了上面的老师和qiqi的争论，觉得问题就出在楼主这份完全copy的板书上，没有添加任何个人的理解在里面，过程大家都了解，那么发这个帖子的意义究竟在哪呢？最好讲清楚，老师的知识传授到你那里究竟接受了多少。板书只是一个总结，但是很多东西都没有被表达清楚，或许老师想教授的东西是对的，但是难说人家只看了板书之后不会产生其他想法，重要的是楼主怎么想的？ 有争论才有进步，我也来想几句，是自己对功能自动化的理解，录制回放在自动化实施的整个过程当中，时间占的比例应该是很少很少的一部分，而且我相信大部分的脚本是手工写出来的，因为程序刚开始未必能够运行得通。想问一个songfeng老师，根据你以往的经验，自动化的用例如何设计呢？还有脚本应该如何来编写，我指的自动化是数据驱动自动化。 这位同学和我讨论技术，我喜欢 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 编辑 ]
页:
[1]
2
