2022年2022年精通QTP自动化测试技术领航 .pdf

《2022年2022年精通QTP自动化测试技术领航 .pdf》由会员分享，可在线阅读，更多相关《2022年2022年精通QTP自动化测试技术领航 .pdf（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1.1.2严格的自动化测试流程1.1.2.1影响自动化测试成功与否的关键因素是流程作者通过多年的自动化测试实战经验认为，必须将整个自动化测试过程看成一个软件开发 项目的过程，因为测试脚本是由代码组成的，而测试代码又是自动化测试的根本。有效地开发并维护良好的测试脚本，是自动化测试过程的重中之重。但是，想要行之有效地管理好这些测试脚本并不是容易的事情，就像管理好项目代码一样！所以，自动化测试过程就是一个软件开发的过程，需要经历各类分析、测试计划、框架及测试用例 设计、脚本开发、测试执行、提交报告、脚本维护、版本控制等一系列繁琐的过程。图1-1 所示是作者经过的一些成功项目自动化测试后总结并描绘的一

2、张自动化测试流程图。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 8 页 - - - - - - - - - 图 1-1 接下来，根据 “ 图 1-1” 逐一讲解每一个关键过程（阶段），让读者明确自动化测试流程及其中的一些细节。1合理的自动化测试切入点通常，项目只有在经历了完整的系统测试 后才算具备了基本的引入测试自动化的条件。于是，一般也就在这个时间段，项目经理与测试经理才会以此定为自动化测试开始筹划与准备的时间点。到目前为止，绝大部分的公司都以系统测试完成为标准来作

3、为自动化测试的切入点，因为在之前的任何阶段中都不是非常适合做自动化测试。2测试自动化分析在具备了可自动化测试的基本条件后，仍然需要默认自动化测试工作 展开的难度之大！我们必须通过各种分析来确定是不是要继续将测试自动化做下去。根据作者在完成了多个自动化测试项目后总结出的经验（有成功的经验、同样也有失败的经验），我们在做测试自动化分析时最该做的就是以下3 种。（1）可行性分析。在进行项目自动化测试之前，第一步就是要确认其可行性，是否可以实行测试自动化。作者认为，在常见的不可行因素下，如果出现其中任何一种，自动化测试工作都是不应该展开的，项目常见不可行因素如下。 项目时间紧迫。如果项目进度很紧迫，开

4、发周期的时间表很紧，每次交付间隔时间很短，你就没有时间进行测试自动化，也就不要考虑自动化测试了。 项目需求变幻无常。测试负责人应该及时和PM 或专门的需求人员沟通来获得最直接的项目方面、客户方面的现有情况以及未来情况，从而最终通过分析来确认是否要进行自动化测试。因为PM 和需求人员往往是对项目现今和未来的发展或对客户的思想及个性最了解的人群。举一个例，作者曾经经历过一个项目，是属于比较大型的长期项目，但是最终这个项目并没有展开自动化测试。为什么？因为这个项目的需求由于总是要 “ 赶时髦 ” ，所以一直在不断变化，那么即使它再耗人力、物力，作者所在的测试团队也只能老老实实在每个版本下来后去进行大

5、批量的手工回归测试。当然，现在看来作者非常庆幸，在这个项目中放弃了自动化测试的念头，因为刚上线那时，作者就和PM 进行了沟通，得知了这个项目以后会是一个需求时常变化的项目。如果那时候引入测试自动化的话，作者相信基本现在已经属于一个烂尾楼工程了！ 项目周期短。 如果你觉得在写完所有自动化测试脚本后，这些脚本只能仅仅为你服务几个（6 个或更少）版本，不用多考虑了，放弃自动化测试吧。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 8 页 - - - - - - - - - 自动

6、化测试工具对系统的有效性。如果上述的前3 个和你所在的项目不沾边，那么请再看看这条因素。我们知道，想要开发自动化测试脚本，那么必须具备一款匹配的自动化测试工具，可以是开源的也可以是商业化的，甚至是自主研发一款。此时，就需要确切地了解这款测试工具能否应付项目中的需要。举个例，假设你所在的公司购买了一款商业化的自动化测试工具，项目系统中全部是一些Java 控件，但是测试工具自带的插件中又不包含Java 控件的识别插件， 那么此时就算拥有这款自动化测试工具，但由于无法有效地识别到项目中的控件，所以，对于项目来说是毫无作用的。（2）抽样 demo 分析。通过可行性分析后，接下来要做的就是一个做demo

7、 了，等待 demo 完成后，可以再次通过分析看看自动化测试工作能否顺利地展开下去，因为demo 已经是一个实体案例，所以，可以完全通过透析demo来发现是否存在技术上的致命问题。通常在demo 完成之后，有经验的自动化测试工程师或组长就能对这个项目的自动化测试工作有一个大体的把握了。换言之，可以把demo 看成更深层次的可行性分析，一旦通过了抽样 demo 分析，自动化测试就可以展开了。关于demo 的选取，一般直接选择冒烟测试用例（大冒烟）写成测试脚本后执行，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行到即可。（3）测试需求分析。到了测试需求分析这一步，分析的就不再是能否在项目

8、中引入测试自动化了，而是在为下一阶段定制具体计划打下基础。测试需求其实就是测试目标，也可看做测试自动化的功能点，也就是自动化测试工程师想完成的任务。比如我们需要分析项目中具体哪些测试需求（功能点）准备进行自动化测试。一条测试需求可以包含多条自动化测试用例，通过测试需求分析来判定项目中测试自动化要做到什么程度。举个例子，在自动化测试用例的设计上，大体是以正向、反向（见小提示）划分的，一般在自动化测试中，优先考虑实现正向的测试用例后再去实现反向的测试用例，而且反向的测试用例大多都是需要进行分析然后筛选出来的，因为反向的测试用例实在太多了。我们知道，自动化测试是不需要也没有必要做到100% 覆盖率的

9、。所以，在测试需求分析这个阶段，确定测试覆盖率以及自动化测试粒度、测试用例上的筛选等都是重点工作。小提示：自动化测试用例设计中的“ 正向 ” 和“ 反向 ” 指什么？通俗点讲， “ 正向 ” 测试用例就是正常的业务操作流，几乎没有什么非正常情况操作融入在其中。反之， “ 反向 ” 测试用例就是异常的业务操作流。我们可以想象一下，做出来的软件是给谁用的？当然是给用户使用的，一般情况下，用户在基本使用上不会像测试工程师那样去 “ 破坏 ” ，他们只关注软件的功能是否好用、是否有异常、是否有差错。所以，“ 正向 ” 的测试用例就是只针对正常的操作，不会去考虑异常情况，当然，也必须是自动化测试脚本优先

10、要写出来的。待名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 8 页 - - - - - - - - - 把这些正常的业务操作的测试脚本全部完成后，才去考虑加入部分最重要且优先级最高的“ 反向 ” 测试用例进去，比如一个注册页面中某表单的填写，用户一样比较关心系统对错误的处理情况，这时候，就需要把自动化测试用例设计成“ 反向 ” 的，然后加入到回归测试中。不过，“ 反向 ” 测试用例实在太多，如果全部都写成脚本，是没必要也不符合自动化测试的特性。所以，才需要分析、筛选、决

11、策。3测试计划定制在经过了测试需求分析阶段后，项目PM 和自动化测试组长就该正式起草正式方案了。写一个优秀、完善、精致的测试计划是必须的工作。当然，这里不会讲述测试计划是如何写的。只是要告诉读者，测试计划的质量和以后的工作顺利进展有着密切的联系，能越早地把各种情况都考虑在计划中对以后自动化测试项目的展开都是很有利的，想要使得自动化测试最终成功，也必须踏踏实实抓住每一个环节，测试计划定制阶段如果能做好，则可以看作是一个良好的开始。而且，通过作者的经验发现，自动化项目的测试计划越全面， 后期越能够循规蹈矩的去实施，自动化测试的成功率就越高；如果自动化测试计划设计不周全，靠后期去完善、补充，基本上这

12、个自动化测试项目就成了一个实验项目。4自动化测试设计阶段在这个阶段，把它分为两个核心部分。第一个部分就是自动化测试框架，第二部分就是自动化测试用例。（1）自动化测试框架设计、开发与搭建。自动化测试框架的好与坏直接影响以后项目的实施。作一个恰当的比喻，一个软件项目如果没有一个好的架构，那这个项目也不会好到哪里去，自动化测试框架对于整个自动化测试项目来说就相当于一个架构，这个架构越好、功能越强大和实用，那就可以给今后整个自动化测试项目的工作过程带来更多的好处。不过，国内目前很多自动化测试框架都过于浮夸，很多工程师为了把自动化测试框架设计得更加强大，开发了一个又一个的“ 强大 ” 功能，其实到头来只

13、是“ 花拳绣腿 ” ，根本和自动化测试项目无法兼容！他们也忘了做自动化测试的基本目的是“ 测试 ” 两个字，把自动化测试框架搞成了一个新项目来开发，真是得不偿失！自动化测试框架其实不止是一种程序，它也应该是、一种思想、一个规范。测试框架的好坏判定应该以实用、适用、扩展性强、使用范围广、稳定、思想先进为先，绝对不能以“ 强大 ” 却又背道而驰的可用功能为主！ 在本书的自动化测试框架章节中，作者会把自己原创的自动化测试框架完全奉献给每一位读者。下面，作者也来谈谈是如何看待“ 自动化测试框架 ” 这个 “ 香馍馍 ” 的吧。自动化测试的基本概念有以下两点。名师资料总结 - - -精品资料欢迎下载 -

14、 - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 8 页 - - - - - - - - - 自动化测试框架是能保证测试的分布执行，脚本模块化 ,数据驱动， 日志分析， 错误截图， 报表回收 ,共享对象库，公共函数库，环境配置，统一设计模式，异常处理,场景恢复等的一个无人值守的，针对每个独立项目的测试框架。 自动化测试框架就是一个“ 舞台” ，可以让所有自动化测试工程师在“ 舞台 ” 上表演，没有这个“ 舞台 ” ，自动化测试工程师就只能单干，在一段时间内是可以的，但是长期发展后会遇到很大的瓶颈，这时候就需要自动化测

15、试框架来突破瓶颈。（2）自动化测试用例设计三部曲。自动化测试流程其实跟手工测试流程差不太多，要先编写测试用例， 只是被叫作自动化测试用例而已。先设计好自动化测试用例，再严格根据设计完成的测试用例编写测试脚本，这是一种规律、一个过程。自动化测试用例设计和手工测试用例设计是有明显区别的。手工测试用例是从无到有的过程，而自动化测试用例不是的。自动化测试用例是有参考物的，它就是手工测试用例。它有时候可以直接拿来用、有时候需要稍加修改，作者把整个自动化测试用例设计过程分为3 步，我们就把它叫做自动化测试用例设计三部曲。 筛选手工测试用例的过程。自动化测试用例设计应该是拿来主义，首先要根据测试需求分析阶段

16、得出的 “ 分析结果 ” 筛选出所有要被 “ 测试自动化 ” 的手工测试用例。在全部筛选完毕后，再分成两部分，一部分是可以直接二次复用的手工测试用例，不要客气，直接拿来即可。另外一部分则要经历下一个过程。实际上，大多数还是需要经过改造的，毕竟自动化测试用例的设计方法和手工测试用例的设计方法有点出入，哪怕是冒烟测试用例多少也要稍加修改。 转换手工测试用例的过程。把无法直接复用的手工测试用例部分依据自动化测试用例设计方法与规则转换成自动化测试用例。一般转换要素无非两种，一种就是测试用例的格式和规则，另一种就是优化自动化测试业务流程。自动化测试业务流程和手工测试业务流程还是有一定区别的。自动化测试业

17、务流程更精简、严格（是一就是一，是二它就绝对不应该是三）！ 新增 &补充自动化测试用例的过程。最后就是新增和补充一些手工测试用例没有涉及的自动化测试业务流程了，请严格根据自动化测试用例设计的方法和规则进行增补（关于“ 自动化测试用例设计” 请见下一章节内容）。自动化测试用例经过“ 三部曲 ” 的“ 洗礼 ” 后基本算是搞定了，但是读者千万别忘了今后我们仍然会重新回到这个阶段，经历自动化测试用例的维护、不断优化的过程。5测试脚本设计与开发名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第

18、5 页，共 8 页 - - - - - - - - - 世间万物皆有灵魂，而自动化测试的灵魂则是测试脚本的设计与开发。自动化测试项目的开发过程的重要性绝不亚于软件项目开发过程。脚本开发阶段也是整个自动化测试流程中最关键的一个阶段。在自动化测试中，测试脚本大致可划分为5 种。（1）线性脚本：通过录制直接产生的线性执行的脚本。（2）结构化脚本：具有顺序、循环、分支等结构的脚本。（3）可共享脚本：可以被多个测试用例使用，被其他脚本调用的脚本。（4） 数据驱动脚本： 测试数据和业务流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本。（5）关键字驱动脚本：脚本、数据、业务分离，数据和关键字在不同的

19、数据表中，通过关键字来驱动测试业务逻辑。关键字驱动脚本的特点是，它看起来更像描述一个测试用例在做什么,而不是如何做。从上面 5 种不同的脚本特性可以看到，自动化测试脚本开发的发展是和软件工程思想的发展一脉相承的。软件开发的模式从面向计算机、到面向过程，再到面向对象、面向服务，是一个从底层到高层、从具体到抽象，复用的粒度从细到粗的发展过程。而软件开发中的模块化、层次化、松耦合等思想对自动化测试脚本的设计与开发都具有借鉴意义。作者认为，如果作为一名自动化测试新手，应该多学习并吸取前人的经验，在学习过程中乃至平时的工作中不断地模仿、深刻钻研，钻研后的尝试最后达到融会贯通。同时，作者也总结了几点关于自

20、动化测试脚本开发的经验与感悟，希望能给读者更多的参考。 自动化测试脚本代码必须严谨、规范。 自动化测试脚本是参照自动化测试用例开发出来的，测试用例即是开发参照物。 发挥自己的想象尽一切可能使自动化测试脚本更智能、高效、稳定、复用性高。 开发过程中多利用程序插桩+断点，检查业务组件是否存在缺陷或代码是否存在漏洞。 自动化测试脚本开发完毕后，至少运行成功3 次以上，方可认为脚本已经没有问题。此外，项目中也必须具备一款优秀的代码版本管理软件来管理好每一个测试版本的自动化测试脚本，这也是自动化测试项目中非常重要的环节。6自动化测试执行这个阶段可以说已经是自动化测试流程中的后期阶段了，所有的自动化测试脚

21、本全部开发完毕并发布后会进入合并联调阶段，脚本联调（见小提示）成功后方能进入这一阶段。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 8 页 - - - - - - - - - 小提示：“ 脚本联调 ” 是很关键的一个时期， 联调如果不通过是无法进行下一个环节的，毕竟都到了这个阶段了，已经花了许多工时了！想要联调的时候顺利通过，功夫还得花在平时！平时写代码规范点，严格按照规范标准去写代码，到了这个阶段遇到的问题就少，即使发生了也好解决。这个阶段的开始也就意味真正的自动化测

22、试开始了。会很开心， 辛辛苦苦写的脚本终于有了用武之地，系统开始进行 “ 自动化测试 ” ！既然是自动化测试，那当然可以由计算机来测试啦，人就不用管了，而且出了问题计算机自动会帮我们解决并重新自动测试。（1）无人值守的测试。使测试自动执行，大致会经历以下步骤。 环境搭建、部署与配置。首先搭建一个自动化测试执行环境是必不可少的，这部分的功能往往以自动化测试框架来支持，此外市面上还有很多类似的批量脚本执行工具也可以做此类的操作。如果是自动化测试框架支持的话，通常需要根据实际情况做相应的配置使其生效。 自动化测试用例和测试脚本互相绑定。接下来的工作就是将自动化测试脚本与当初设计的自动化测试用例做关联

23、和绑定了（这部分在前期也可以做）。 自动化测试用例执行顺序排列与组合。在完成了上面的工作后，就可以创建一个测试集，在测试集里添加各种各样的自动化测试用例。当然，根据业务实际情况，测试用例的先后排列顺序和各种组合是非常有讲究的。（2）异常处理和场景恢复。俗话说： “ 天有不测风云 ” 。谁都没法预料在自动化测试过程中会碰到什么问题，系统服务器崩溃？电脑卡机？服务器无响应？如果发生了这些情况怎么办？如果在白天的话，自动化测试工程师守候在执行机器旁边那还好， 重新花时间整理。那如果晚上呢？自动化测试工作就要被迫停止了？当然不行！这个时候，一个优秀的异常处理与场景恢复机制就显得尤为重要了，有了这个机制

24、，我们才能放心地将测试交给计算机执行。在本书以后的章节中，也会详细和精辟地分享这方面的具体内容。（3）一个自动化测试执行实例。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 8 页 - - - - - - - - - 在本阶段讲解的最后，作者举一个QC 自动化测试框架（HP 公司产品Quality Center ，一款集测试解决方案、测试流程管理、缺陷管理的工具，其本身也是一个自动化测试框架）的例子，其实也算是一个完整过程。我们将测试脚本上传至QC 服务器并与相应的测试用

25、例绑定。最后，可以生成一个测试集，测试集里可以导入之前设计的测试用例，如果导入的用例和脚本有过绑定，则脚本也随之自动加载到测试集中，只需要点击 “ 执行 ” 按钮， QC 就会自动执行脚本，开始测试了。如果在执行过程中发生意外情况，只要预先设置了各种异常情况及处理应对方式，QC 就会自动进行处理，并把测试场景恢复到预置的状态重新自动执行测试。等测试集中的测试用例全部运行完毕后，QC 就会显示这些测试用例的运行结果并生成图表，然后自动将缺陷提交到服务器中，方便测试工程师了解自动化测试运行以及完成的情况乃至发现的缺陷情况。7提交自动化测试产物这个阶段，是对自动化测试项目开展、实施的反馈。通常，在自

26、动化测试执行后，大致需要提交执行情况、测试结果、分析报表、测试报告、质量情况等（具体每个项目都会有所不同）。其实细心的读者应该能察觉到，在上面那个阶段讲解最后的实例中，已经有这个阶段的影子了。值得开心的是，在提交了自动化测试产物后，自动化测试就算大功告成了！接下来，通常需要做一些会议总结、经验分享、自动化整体测试过程分析、自动化测试项目改进建议等工作，为了在后续的版本使自动化测试能取得更大的硕果。8测试脚本维护其实到了 “ 提交自动化测试产物” 这个阶段，一个自动化测试流程就算是结束了。测试脚本维护阶段不能单纯地被看作是一个阶段，因为测试脚本维护的工作是时刻穿插在各个阶段中的（“ 第五阶段测试脚本设计与开发 ” 开始）。严格来讲，每个阶段都在做测试脚本维护的工作。只是，测试脚本维护对于整个自动化测试项目非常重要，也是需要做最久的一项工作，所以，作者将其单独列为一个阶段来讲解。自动化测试脚本维护也是一个持续性的优化过程，总是不断地在优化、改进、修正。作者觉得，做自动化测试最多的还是“ 维护” ！不值得 “ 维护 ” 的自动化测试项目是不值得立项的！名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 8 页 - - - - - - - - -