第1章 测试脚本开发从零开始

1.1 自动化测试从零开始

阶段要点

• 自动化测试的优势与劣势。

• 引入自动化测试的条件。

• 避免自动化测试的因素。

• 实例解读软件测试自动化。

• 严格的自动化测试流程。

• 自动化测试用例设计详解。

1.1.1 什么是自动化测试

1.1.1.1 引言

“自动化测试”，一个耳熟能详的软件测试行业术语、一个绝大部分测试界人员的奋斗目标、一个听上去就很有感觉的名词、一个甚至能牵动未来测试界发展水平快慢的技术。是的，以上说的几点都没有错，它就是软件测试行业中最高端的技术之一，测试自动化技术！它以程序测试程序、以代码代替思维、以脚本的运行代替手工测试。自动化测试同时涵盖各种各样的测试种类，常见的有以下几种：功能（黑盒）自动化测试、功能（白盒）自动化测试、性能测试、压力测试、GUI测试、安全性测试，它们都可以由测试自动化技术来代替手工测试，其实还有很多，作者只是概括了大家都熟悉的软件测试种类，其他的诸如作者曾经收到过这样一个问题，这名测友问：“网络游戏的功能可以引入自动化测试吗？”虽然作者并没有游戏行业的软件开发、测试经验，但是作者确信，网络游戏一样也可以引入测试自动化技术，为什么？因为网络游戏同样是用程序写出来的，只要是一种程序，那么它一定能用程序测试程序、用代码代替思维、用脚本的运行为手工测试代劳！

可以这么说，自动化测试这个术语，每天都索绕在我们的耳边，所以，掌握测试自动化这门技术，对测试工程师来说，是至关重要的，我们并不需要精通每种测试自动化技术，但是，至少我们需要精通其中的一种，只要精通其中一种，相信你在测试这个领域一定会占有一席之地，这门技术能带给你非常大的优势！虽然测试永远脱离不了手工测试，但是，未来测试行业一定会是由自动化测试来引导。这是不争的事实，中国测试行业发展之快也是有目共睹的，如果你现在能掌握这门技术，相信未来的测试路会越走越顺畅，你的测试职业生涯会越来越精彩。

1.1.1.2 自动化测试能做到什么及其优势，你心知肚明吗

万物存在即合理，自动化测试能不断地发展至今，足以证明其在测试领域中有着举足轻重的地位，能切实地帮助项目进度的推动、提高项目的质量和协助测试人员提高工作效率。那么自动化测试究竟有何功能呢？这里归纳了最重要的几点并予以分析。

回归测试更方便、可靠。通常来说，这是自动化测试最主要的任务和特点，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的业务流程操作和测试用例是预先完全设计好的，预期结果也是完全在项目人员掌握之中的，将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间。这里需要强调一点，上述说的程序修改比较频繁指的是新功能的不断加入，而老功能的逻辑是不变或者很少变化的，不是指整个程序全部或大批量地改动，因为这样是违反自动化测试原理的，在下文也会有类似的讲解。

可运行更多、更繁琐的测试，且快速、高效。自动化测试的一个明显好处是，可以在较少的时间内运行更多的测试。我们知道，有很大一部分业务功能由于业务逻辑极其繁琐（暂时不说有多复杂），使用手工测试往往耗费大量的时间，测试1次、2次、3次可以，但是，如果测试10次以上或者更多呢？当一个测试人员测试同一个业务功能10次以上，几乎可以断定，没有一个测试人员会继续耐心地测试下去。所以，此时自动化测试就能发挥作用，自动化测试的耐心是无限大的，而且计算机的执行速度远比人工快！

可执行一些对于手工测试来说相当困难或根本做不到的测试。比如，对于大量用户的测试并发，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户并发点击某一功能，从而达到测试的目的。再比如，人工不可能 24 小时不眠不休地进行测试，但是计算机则不用休息。当然，类似的例子还有很多，无法全部列举出来。

更好地利用资源，使资源的使用更有价值。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动化测试，仅适合于手工测试，将可自动化测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。在引入自动化测试后，测试人员的工作很大一部分可以交给计算机，而自己则解放出来，将精力投入新功能或者测试更深的业务逻辑，争取发现更深层次的缺陷，能做到这些，自动化测试可以说功不可没。

具有一致性和可重复性的特点。由于测试是机器自动执行的，每次测试的结果和执行的内容与操作的一致性是可以得到保障的，从而达到测试可重复的效果。机器可以按照相同的轨迹不断地执行测试并丝毫没有差错（即使错了也可以自动解决），但是人不能！

自动化测试脚本完全具有复用性。由于自动化测试通常以脚本的方式来实现，这样在不同的版本之间，就有可能只需要做少量的维护甚至不做任何修改，实现在不同的测试版本中使用相同的测试脚本执行相同的测试用例。

使软件更有信任度。由于测试是由计算机自动代劳的，所以，不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了具有说服力的自动化测试后，软件的信任度一定会大大增加。

多环境下测试。我们知道，一个系统往往会被要求能支持各种不同的环境并稳定运行，但是这么多不同的环境，比如常用浏览器有IE6、IE7、IE8、FireFox等，系统有Windows 2003、Windows XP、Windows Vista、Windows 7等，甚至还有杀毒软件，如卡巴斯基、360、诺顿等，那么多的环境组合，如果每一种环境组合我们都需要花人力、物力去把功能测试一遍的话，估计研发周期至少得增加10倍！在这种情况下，自动化测试又可以完全发挥其优势与作用了，由计算机去代劳，在不同的环境组合中执行测试。

1.1.1.3 自动化测试无法做到的事及其劣势分析

当然，自动化测试不是万能的，它的能力仍然是有限的。自动化测试同样有着各种各样的缺点和无法做到的事情。不过，人类是不断在进步的，测试自动化技术随着人类进步的步伐也一定会越来越强大。下面同样归纳了最重要的一些自动化测试的劣势以及它力不能及的事情。

永远不可能完全取代手工测试。自动化测试不能完全替代手工测试，这已经是业界中不需要再争辩的事实了。自动化测试无法做到手工测试的覆盖率。不是每个测试用例都适合转换成自动化测试用例的。另外，复杂性极强的操作也只能通过手工测试来完成，如果将这个复杂的操作写成代码那将会是件大麻烦事。还有一个例子也能证明，就是比如我们当前需要验证页面上的布局是否正确，那试问这该如何写成脚本代码呢？

无法完全保证测试的正确性。上面也说到了，自动化测试是由测试脚本组成，它的核心仍然是代码，说的简单点，自动化测试就是程序测试程序。我们知道，是程序就一定会有缺陷，所以，不能保证测试工程师开发的脚本就完全 100%没有缺陷，如果代码中出现一个小小逻辑错误，哪怕一个条件判断的误写也会导致测试结果完全出错。当然，对于一个有经验和优秀的自动化测试开发工程师来说，大多数的错误还是会在脚本调试中避免的。

手工测试能发现的缺陷远比自动化测试多。可以这么说，有85%的缺陷是归功于手工测试，而只有15%的缺陷归功于自动化测试（注意：这个标准并不是随便说的，而是由自动化测试专家共同总结得出的一组数据结论）。而且在这15%中，大约只有0.1%不到的缺陷属于新缺陷。的确，自动化测试几乎是无法发现新缺陷的，自动化测试大多是用来发现曾经发现过的缺陷在每个版本下有没有重新出现。当然，我们情愿自动化测试永远不要找出缺陷！自动化测试更适合缺陷预防而不是发现更多缺陷。请记住，自动化测试最大的用途就是回归……再回归。

对测试质量的依赖性极大。自动化测试的运行首先要建立在版本测试质量（在这里基本指手工测试质量）稳定的大条件下，如果当前版本的测试质量不够稳定，运行自动化测试将会非常不顺利，几乎是一种无用功和白白浪费时间的行为。

测试自动化可能会制约软件开发。由于自动化测试比手工测试更脆弱，以及脚本维护会受到限制，从而制约软件的开发。

自动化测试工具是死的，它本身没有任何想象力。自动化测试是无法做到像人类一样随心所欲地创造的，自动化测试的好坏，完全取决于自动化测试负责人和测试开发工程师的思想与技术，和自动化测试工具没有任何关系，工具是没有思想的，所有的操作全部由人通过输入代码的方式告诉工具它该怎么做。

成本投入过高，风险大。自动化测试需要很大的成本投入，并且如果没有良好的成本分析与控制手段以及自动化测试计划与执行过程控制，那么失败的自动化测试案例数不胜数，导致企业白白浪费人力物力还得不到任何回报。

自动化测试对测试人员的技术要求较高，对测试工具同样有一定要求。自动化测试对测试工程师来说必须有一定的开发技术背景，开发技术越高则写出来的脚本质量也就越高、越有技术性和想象力。不是每个测试工程师都适合或有能力开发质量好的测试脚本的。同样，也不是每一个测试工具能真正地被使用在真实的项目中并驾驭项目的，也没有听说过有一个自动化测试工具能做到适合每一个项目。

1.1.1.4 何时适合引入自动化测试

在之前的章节中，通过总结和分析，相信读者已经对自动化测试的特性和优劣有了一定的了解，接下来，分析在实际项目中关于自动化测试成败的点点滴滴。

在我们的自动化测试中，必须让读者知道哪些情况下才适合把项目的系统测试交给自动化测试来完成。但是，如果不能善加利用，则给自己或者组织造成的后果还是比较严重的。下面让我们一起认知何时才比较适合做软件测试自动化！

项目周期长，系统版本不断。如果你目前所在测试的项目（或系统）是属于一个周期比较长的项目的时候，可以说，的确非常适合引入自动化测试，把大量的回归测试托付给测试自动化是一个比较明智的选择。还有一种根据是从系统的版本数得来的，曾经测试领域专家有过相关的研讨并最后得出结论，一般自动化测试耗费的时间是手工测试的6～10倍，所以，如果你所在的项目（或系统）版本数在10个以上，那么，引入测试自动化也同样非常的睿智，并且和之前的项目周期综合下，时间越长随之而来需要测试的版本就会越来越多，这样，自动化测试可以发挥它最大的作用，给企业带来各方面的利益。

需求变更不频繁。当项目的需求非常稳定，不会经常出现变更的时候，此时也很适合引入测试自动化。

系统中的测试对象基本可以正常识别。一般来说，自动化测试的基本要求或者说自动化测试工具对系统的基本要求就是对象的识别，一个自动化测试工具的好坏评判最基本的标准就是，是否能够识别更多的系统控件以及对无法识别的控件能否提供各种解决方案或自定义开发各种控件的识别代码。

系统中不存在大批量第三方控件。有实际项目经验的读者一定会发现，无论什么系统，B/S架构的也好、C/S架构的也行，多少存在一些第三方控件，但是，如果这些第三方的控件数量不多的话，经过详细的计划与评估后，完全可以引入测试自动化，当然，如果第三方控件数量庞大或者形式种类庞大的话，就会带来很多麻烦，在下文中也会提到。

需要反复测试，如可靠性测试需要进行上千次的系统测试。在我们的1.1.1.2 项目的第一条例子中，提到过类似的情形。在项目中，如遇到这种情况，从理论上讲是相当适合使用自动化测试策略的，当然，前提条件是有能力把自动化测试做好，如果遇到这种情形，测试自动化实行最后成功的话，一定能给整个项目团队带来“丰功伟业”！

1.1.1.5 何时避免展开自动化测试

在 1.1.1.4 节中，归纳了自动化测试的适宜条件，但是万物都有另外一面，自动化测试也有很多禁忌，作为一名测试工程师或者未来的自动化测试工程师来说，如果触犯了禁忌还要执着地做下去，后果也只有一个，就是自讨苦吃，给企业、项目团队带来损失，使得领导以后再也不信任自动化测试，使自己对测试自动化技术更加迷茫！接下来，作者以自己多年自动化测试实战经验以及学习经验，一定要告诉读者，在自动化测试中，哪些是犯了大忌的，读者务必吸取前人的教训，扬长避短，如果以后在项目中和以下任何一条有冲突，千万不要开展自动化测试。

项目周期短，需求变更频繁。当你的项目周期不是很长的情况下，请不要引入测试自动化，因为这样的话，不但收不回成本，而且会延长产品的发布时间，并且这样的行为是毫无意义的！作者在1.1.1.3小节中的第一条已经提到了。自动化测试的成本计算方式及其计算实际参照，在这里则不再多加阐述。当然，还有一个问题，相信有项目经验的读者一定会碰到过类似的问题，即使这个项目是一个长期的项目，但是客户经常性地更改需求，甚至时常更改老功能的业务逻辑。这种情况下，即使周期再长的项目也最好别引入测试自动化，因为，即使你有再好的自动化测试方案和执行技术，但你始终赶不上客户变更的速度，最终仍然还是会放弃，因为永远在收拾“烂摊子”！

在软件版本还没有稳定的情况下。当你准备引入测试自动化时，请先确定你所在的项目，版本功能是否已经稳定，如果版本功能还不是很稳定，主功能或大量的功能有被重新更改的可能性的话，务必暂时缓一缓，不要随意地开始自动化测试之旅。

没有明确的项目测试自动化计划、措施和管理。在这里，作者根据多年的项目自动化测试实战经验可以用很确定的态度与语气告诉读者，软件自动化测试和软件开发工程是一脉相传的！作者在此不阐述软件开发工程的基本概念，但是作者一定会强调，在自动化测试的开发过程中，一样需要通过严格的开发计划、版本管理、代码管理等一系列相关措施，兢兢业业地做好每一步工作，踏实地管理和控制好每一个环节。自动化测试脚本不是一次性的，而是需要长时间维护下去的，如果事先没有制定良好的测试方案，实施过程中不严格根据方案执行，开发完毕后又不做任何改进或提出各种优化方案等，那么你说，最后项目自动化测试会成功吗？

领导不支持。目前，较多企业，特别是中小型企业的高级管理人员还是没有能力或者没有信心可以将软件测试自动化做好。在这种情况下，首先，作者认为还是先和领导沟通好，取得他们的支持、理解与信任后再引入测试自动化比较妥当；没有领导的肯定与支持，自动化测试之旅一定是无法顺利展开的，最终也达不到终点，多半情况下会中途不了了之，如果这样的话，还不如不要引入测试自动化呢。

多数对象无法识别以及脚本维护频繁与艰难，二者有其一，自动化测试注定失败。又一次提到了这个说法，因为它的确太重要了！希望读者能真正地通过作者一次又一次地重复，真切地了解到这个自动化测试的重大问题。根据前文的不断讲述，作者再总结一下，如果项目中存在大量无法识别的控件（这种情况基本是发生在系统中存在大量的第三方控件）或者没有获得相应的对象识别插件，是没有办法写出自动化测试脚本的。当然，对象的识别不一定要靠插件，还有其他解决方法，比如SDK插件扩展，或者让开发人员提供相应的DLL来识别等，但是，如果有一半的插件不能识别，那么再强行为之，耗费的人力、物力将会有多大？估计能够重新开发一个新项目了。脚本维护频繁是直接和前文所述的需求变更频繁有关的，需求一直在变，自动化测试工程师只能跟着将脚本永无止境地变化下去，直到头晕目眩、直到大量测试开发工程师受不了如此的“虐待”而离职。最终，自动化测试正式宣布“失败”！

1.1.2 严格的自动化测试流程

1.1.2.1 影响自动化测试成功与否的关键因素是流程

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

接下来，根据“图1-1”逐一讲解每一个关键过程（阶段），让读者明确自动化测试流程及其中的一些细节。

1．合理的自动化测试切入点

通常，项目只有在经历了完整的系统测试后才算具备了基本的引入测试自动化的条件。于是，一般也就在这个时间段，项目经理与测试经理才会以此定为自动化测试开始筹划与准备的时间点。到目前为止，绝大部分的公司都以系统测试完成为标准来作为自动化测试的切入点，因为在之前的任何阶段中都不是非常适合做自动化测试。

2．测试自动化分析

在具备了可自动化测试的基本条件后，仍然需要默认自动化测试工作展开的难度之大！我们必须通过各种分析来确定是不是要继续将测试自动化做下去。根据作者在完成了多个自动化测试项目后总结出的经验（有成功的经验、同样也有失败的经验），我们在做测试自动化分析时最该做的就是以下3种。

（1）可行性分析。

在进行项目自动化测试之前，第一步就是要确认其可行性，是否可以实行测试自动化。作者认为，在常见的不可行因素下，如果出现其中任何一种，自动化测试工作都是不应该展开的，项目常见不可行因素如下。

项目时间紧迫。如果项目进度很紧迫，开发周期的时间表很紧，每次交付间隔时间很短，你就没有时间进行测试自动化，也就不要考虑自动化测试了。

项目需求变幻无常。测试负责人应该及时和PM或专门的需求人员沟通来获得最直接的项目方面、客户方面的现有情况以及未来情况，从而最终通过分析来确认是否要进行自动化测试。因为PM和需求人员往往是对项目现今和未来的发展或对客户的思想及个性最了解的人群。举一个例，作者曾经经历过一个项目，是属于比较大型的长期项目，但是最终这个项目并没有展开自动化测试。为什么？因为这个项目的需求由于总是要“赶时髦”，所以一直在不断变化，那么即使它再耗人力、物力，作者所在的测试团队也只能老老实实在每个版本下来后去进行大批量的手工回归测试。当然，现在看来作者非常庆幸，在这个项目中放弃了自动化测试的念头，因为刚上线那时，作者就和PM进行了沟通，得知了这个项目以后会是一个需求时常变化的项目。如果那时候引入测试自动化的话，作者相信基本现在已经属于一个烂尾楼工程了！

项目周期短。如果你觉得在写完所有自动化测试脚本后，这些脚本只能仅仅为你服务几个（6个或更少）版本，不用多考虑了，放弃自动化测试吧。

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

（2）抽样demo分析。

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

（3）测试需求分析。

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

3．测试计划定制

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

4．自动化测试设计阶段

在这个阶段，把它分为两个核心部分。第一个部分就是自动化测试框架，第二部分就是自动化测试用例。

（1）自动化测试框架设计、开发与搭建。

自动化测试框架的好与坏直接影响以后项目的实施。作一个恰当的比喻，一个软件项目如果没有一个好的架构，那这个项目也不会好到哪里去，自动化测试框架对于整个自动化测试项目来说就相当于一个架构，这个架构越好、功能越强大和实用，那就可以给今后整个自动化测试项目的工作过程带来更多的好处。不过，国内目前很多自动化测试框架都过于浮夸，很多工程师为了把自动化测试框架设计得更加强大，开发了一个又一个的“强大”功能，其实到头来只是“花拳绣腿”，根本和自动化测试项目无法兼容！他们也忘了做自动化测试的基本目的是“测试”两个字，把自动化测试框架搞成了一个新项目来开发，真是得不偿失！自动化测试框架其实不止是一种程序，它也应该是、一种思想、一个规范。测试框架的好坏判定应该以实用、适用、扩展性强、使用范围广、稳定、思想先进为先，绝对不能以“强大”却又背道而驰的可用功能为主！在本书的自动化测试框架章节中，作者会把自己原创的自动化测试框架完全奉献给每一位读者。

下面，作者也来谈谈是如何看待“自动化测试框架”这个“香馍馍”的吧。自动化测试的基本概念有以下两点。

自动化测试框架是能保证测试的分布执行，脚本模块化,数据驱动，日志分析，错误截图，报表回收,共享对象库，公共函数库，环境配置，统一设计模式，异常处理,场景恢复等的一个无人值守的，针对每个独立项目的测试框架。

自动化测试框架就是一个“舞台”，可以让所有自动化测试工程师在“舞台”上表演，没有这个“舞台”，自动化测试工程师就只能单干，在一段时间内是可以的，但是长期发展后会遇到很大的瓶颈，这时候就需要自动化测试框架来突破瓶颈。

（2）自动化测试用例设计三部曲。

自动化测试流程其实跟手工测试流程差不太多，要先编写测试用例，只是被叫作自动化测试用例而已。先设计好自动化测试用例，再严格根据设计完成的测试用例编写测试脚本，这是一种规律、一个过程。

自动化测试用例设计和手工测试用例设计是有明显区别的。手工测试用例是从无到有的过程，而自动化测试用例不是的。自动化测试用例是有参考物的，它就是手工测试用例。它有时候可以直接拿来用、有时候需要稍加修改，作者把整个自动化测试用例设计过程分为 3步，我们就把它叫做自动化测试用例设计三部曲。

筛选手工测试用例的过程。自动化测试用例设计应该是拿来主义，首先要根据测试需求分析阶段得出的“分析结果”筛选出所有要被“测试自动化”的手工测试用例。在全部筛选完毕后，再分成两部分，一部分是可以直接二次复用的手工测试用例，不要客气，直接拿来即可。另外一部分则要经历下一个过程。实际上，大多数还是需要经过改造的，毕竟自动化测试用例的设计方法和手工测试用例的设计方法有点出入，哪怕是冒烟测试用例多少也要稍加修改。

转换手工测试用例的过程。把无法直接复用的手工测试用例部分依据自动化测试用例设计方法与规则转换成自动化测试用例。一般转换要素无非两种，一种就是测试用例的格式和规则，另一种就是优化自动化测试业务流程。自动化测试业务流程和手工测试业务流程还是有一定区别的。自动化测试业务流程更精简、严格（是一就是一，是二它就绝对不应该是三）！

新增&补充自动化测试用例的过程。最后就是新增和补充一些手工测试用例没有涉及的自动化测试业务流程了，请严格根据自动化测试用例设计的方法和规则进行增补（关于“自动化测试用例设计”请见下一章节内容）。

自动化测试用例经过“三部曲”的“洗礼”后基本算是搞定了，但是读者千万别忘了今后我们仍然会重新回到这个阶段，经历自动化测试用例的维护、不断优化的过程。

5．测试脚本设计与开发

世间万物皆有灵魂，而自动化测试的灵魂则是测试脚本的设计与开发。自动化测试项目的开发过程的重要性绝不亚于软件项目开发过程。脚本开发阶段也是整个自动化测试流程中最关键的一个阶段。

在自动化测试中，测试脚本大致可划分为5种。

（1）线性脚本：通过录制直接产生的线性执行的脚本。

（2）结构化脚本：具有顺序、循环、分支等结构的脚本。

（3）可共享脚本：可以被多个测试用例使用，被其他脚本调用的脚本。

（4）数据驱动脚本：测试数据和业务流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本。

（5）关键字驱动脚本：脚本、数据、业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动脚本的特点是，它看起来更像描述一个测试用例在做什么,而不是如何做。

从上面5种不同的脚本特性可以看到，自动化测试脚本开发的发展是和软件工程思想的发展一脉相承的。软件开发的模式从面向计算机、到面向过程，再到面向对象、面向服务，是一个从底层到高层、从具体到抽象，复用的粒度从细到粗的发展过程。而软件开发中的模块化、层次化、松耦合等思想对自动化测试脚本的设计与开发都具有借鉴意义。

作者认为，如果作为一名自动化测试新手，应该多学习并吸取前人的经验，在学习过程中乃至平时的工作中不断地模仿、深刻钻研，钻研后的尝试最后达到融会贯通。同时，作者也总结了几点关于自动化测试脚本开发的经验与感悟，希望能给读者更多的参考。

自动化测试脚本代码必须严谨、规范。

自动化测试脚本是参照自动化测试用例开发出来的，测试用例即是开发参照物。

发挥自己的想象尽一切可能使自动化测试脚本更智能、高效、稳定、复用性高。

开发过程中多利用程序插桩+断点，检查业务组件是否存在缺陷或代码是否存在漏洞。

自动化测试脚本开发完毕后，至少运行成功3次以上，方可认为脚本已经没有问题。

此外，项目中也必须具备一款优秀的代码版本管理软件来管理好每一个测试版本的自动化测试脚本，这也是自动化测试项目中非常重要的环节。

6．自动化测试执行

这个阶段可以说已经是自动化测试流程中的后期阶段了，所有的自动化测试脚本全部开发完毕并发布后会进入合并联调阶段，脚本联调（见小提示）成功后方能进入这一阶段。

这个阶段的开始也就意味真正的自动化测试开始了。会很开心，辛辛苦苦写的脚本终于有了用武之地，系统开始进行“自动化测试”！既然是自动化测试，那当然可以由计算机来测试啦，人就不用管了，而且出了问题计算机自动会帮我们解决并重新自动测试。

（1）无人值守的测试。

使测试自动执行，大致会经历以下步骤。

环境搭建、部署与配置。

首先搭建一个自动化测试执行环境是必不可少的，这部分的功能往往以自动化测试框架来支持，此外市面上还有很多类似的批量脚本执行工具也可以做此类的操作。如果是自动化测试框架支持的话，通常需要根据实际情况做相应的配置使其生效。

自动化测试用例和测试脚本互相绑定。

接下来的工作就是将自动化测试脚本与当初设计的自动化测试用例做关联和绑定了（这部分在前期也可以做）。

自动化测试用例执行顺序排列与组合。

在完成了上面的工作后，就可以创建一个测试集，在测试集里添加各种各样的自动化测试用例。当然，根据业务实际情况，测试用例的先后排列顺序和各种组合是非常有讲究的。

（2）异常处理和场景恢复。

俗话说：“天有不测风云”。谁都没法预料在自动化测试过程中会碰到什么问题，系统服务器崩溃？电脑卡机？服务器无响应？如果发生了这些情况怎么办？如果在白天的话，自动化测试工程师守候在执行机器旁边那还好，重新花时间整理。那如果晚上呢？自动化测试工作就要被迫停止了？当然不行！这个时候，一个优秀的异常处理与场景恢复机制就显得尤为重要了，有了这个机制，我们才能放心地将测试交给计算机执行。在本书以后的章节中，也会详细和精辟地分享这方面的具体内容。

（3）一个自动化测试执行实例。

在本阶段讲解的最后，作者举一个 QC 自动化测试框架（HP 公司产品 Quality Center，一款集测试解决方案、测试流程管理、缺陷管理的工具，其本身也是一个自动化测试框架）的例子，其实也算是一个完整过程。

我们将测试脚本上传至QC服务器并与相应的测试用例绑定。最后，可以生成一个测试集，测试集里可以导入之前设计的测试用例，如果导入的用例和脚本有过绑定，则脚本也随之自动加载到测试集中，只需要点击“执行”按钮，QC就会自动执行脚本，开始测试了。

如果在执行过程中发生意外情况，只要预先设置了各种异常情况及处理应对方式，QC就会自动进行处理，并把测试场景恢复到预置的状态重新自动执行测试。

等测试集中的测试用例全部运行完毕后，QC 就会显示这些测试用例的运行结果并生成图表，然后自动将缺陷提交到服务器中，方便测试工程师了解自动化测试运行以及完成的情况乃至发现的缺陷情况。

7．提交自动化测试产物

这个阶段，是对自动化测试项目开展、实施的反馈。通常，在自动化测试执行后，大致需要提交执行情况、测试结果、分析报表、测试报告、质量情况等（具体每个项目都会有所不同）。其实细心的读者应该能察觉到，在上面那个阶段讲解最后的实例中，已经有这个阶段的影子了。

值得开心的是，在提交了自动化测试产物后，自动化测试就算大功告成了！接下来，通常需要做一些会议总结、经验分享、自动化整体测试过程分析、自动化测试项目改进建议等工作，为了在后续的版本使自动化测试能取得更大的硕果。

8．测试脚本维护

其实到了“提交自动化测试产物”这个阶段，一个自动化测试流程就算是结束了。测试脚本维护阶段不能单纯地被看作是一个阶段，因为测试脚本维护的工作是时刻穿插在各个阶段中的（“第五阶段 测试脚本设计与开发”开始）。严格来讲，每个阶段都在做测试脚本维护的工作。只是，测试脚本维护对于整个自动化测试项目非常重要，也是需要做最久的一项工作，所以，作者将其单独列为一个阶段来讲解。

自动化测试脚本维护也是一个持续性的优化过程，总是不断地在优化、改进、修正。作者觉得，做自动化测试最多的还是“维护”！不值得“维护”的自动化测试项目是不值得立项的！

1.1.2.2 自动化测试项目“标配”

了解了自动化测试流程的繁琐与严格后，再了解以下自动化测试团队的人员标准配置。从目前国内企业实际角度出发，算上自动化测试项目管理人员，我们以5人的团队为例。先让我们看以下这5人团队内存在的角色及其角色定义。

自动化测试组长：自动化测试团队的最高管理，拥有发言权。负责自动化测试项目从自动化立项到进度实施，到验收报告等整个测试流程；负责团队人员调度与管理；负责与上级领导、项目经理、手工测试负责人沟通与协调，并带领整个自动化小组工作。

高级测试开发工程师：团队中技术最牛的角色，通常负责自动化测试框架的设计与搭建；负责自动化项目实施过程中各类技术难点的解决；负责公共数据的提炼和开发，如公共函数库等。

自动化测试用例设计人员：由团队中对业务和手工测试情况最熟悉的人员担当。负责自动化测试用例的设计开发工作，及今后的测试用例维护工作；负责测试脚本的验收工作，监督测试脚本业务逻辑是否与设计好的自动化测试用例一致。

脚本开发人员：“战场前线”人员。负责自动化测试脚本的设计与开发；负责脚本合并联调工作；负责后期的脚本维护工作。

自动化项目库管理人员：类似文职人员，可以没有代码开发经验。负责整个自动化团队日常工作中的文档变更记录的整理、公共对象库管理、代码版本管理及公共函数库管理等。

基本职责为。

A某：自动化测试组长。

B某：高级测试开发工程师。

C某：自动化测试用例设计人员。

D某：脚本开发人员。

E某：自动化项目库管理人员。

接下来，就让我们看以下5人团队怎么样人员配置（注：一人可同时兼任多种角色）吧。

自动化测试组长：1人次（A）

高级测试开发工程师：1～2人次（B、A）

自动化测试用例设计人员：2人次（C、E）

脚本开发人员：3～4人次（D、A、B、C）

自动化项目库管理人员：1人次（E）

以上就是一个5人自动化测试小组的标准配置和角色划分，仅供读者参考。

1.1.3 自动化测试用例设计详解

通常，在项目的测试过程中，测试工程师都会首先获取测试需求，接着熟悉测试需求，等待测试计划产出后，编写和设计测试用例，一般测试工程师都会根据事先设计好的测试用例来验证实际结果是否符合预期，包括后期的回归测试。而自动化测试项目同样也有这样一个流程，需要自动化测试工程师首先分析测试需求，产出自动化测试计划，设计好自动化测试用例后才能开始进入后续的脚本设计开发阶段。那么，既然要写自动化测试用例，有些读者可能会问，不是有手工测试用例吗，为什么还要去完成自动化测试用例？为什么不能用手工用例来直接替代自动化测试用例呢？它们之间到底有什么区别呢？自动化测试用例的设计原则到底又是什么呢？在上一章节中，内容虽有涉及，但作者并没有作细化介绍，因为自动化测试用例设计是一个非常重要的环节，所以必须单独列为一个章节进行系统化的解析。

很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能是导致最后自动化测试项目失败的最大原因。那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？有以下几点原因，同时也是自动化测试用例的设计原则。

原则1：自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。

在选取自动化测试用例范围时，很多测试工程师或者上级领导可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。其实恰好相反，这样的想法往往会导致自动化测试最终失败。在一些大型项目中，往往测试用例的数量会很庞大，而且如果遇到一些繁杂的被测程序（特别是C/S 架构），脚本开发工作往往会相当耗时间，并且很多测试用例甚至根本就不能通过自动化来实现。举些例子，现在很多公司自动化测试都是刚起步，对自动化测试的了解程度只是停留在字面上，在公司对测试也不是非常重视的情况下，当然不太愿意去花精力招一个具有自动化测试开发经验的工程师，很多还是停留在使用工具的录制回放功能来完成自动化测试。正是存在这样的技术限制情况下，往往在实施中，会出现很多录制回放不能解决的问题，测试工具完全无法识别测试对象，无法识别一些特殊的加密测试控件。还有，如果项目的变更频率，测试用例数量大的话，增加了后期的维护工作量等，都是造成最终失败的一些隐患。投入越大，损失越大。因此，往往我们会选取最核心的一些业务路径或者是重复执行率较高的一些手工测试用例进行自动化测试，这样能够充分发挥出自动化测试的优势。

原则2：自动化测试用例的选择一般以“正向”为主。

手工测试用例分正常情况和异常情况，在设计的时候，可能往往会去设计很多异常情况来验证程序是否有Bug，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的预期结果。在自动化测试中，很多人喜欢将正常情况称为“正向”；反之，异常情况则称为“反向”。下面，我们试想以下，如果将这些异常情况全部转化、反应到自动化测试脚本中，那肯定需要非常繁琐的判断才能做到。这个对于自动化测试工程师来说，其现有的工作量还是今后的脚本维护量都是不可小视的。对于整个自动化测试项目来说，如果每个异常情况都要写进脚本中，那真的是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。使每个东西都能发挥其最大的作用才是企业最想看到的。功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。而自动化测试则是让测试人员从繁琐又枯燥的重复手工测试中解放出来，这就是目的和目标。

原则3：不是所有手工测试用例都可以使用自动化测试来实现的。

这里纠正许多测试从业人员的一个错误观念，刚接触测试自动化的普遍都会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施的时候，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要去自动化的。例如，有些用例会牵涉到硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有这样的重视程度的更不多）；再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，以及根据具体情况给予响应的，这些情况多数还是只能使用手工人为地来完成。当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试哪些是不需要的，否则测试工程师就会不知所措，没有一个标准。一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去完成需要转化部分的自动化测试用例的脚本开发工作了。

原则4：手工测试用例可以不用回归原点，而自动化用例往往是必须的。

很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻就会报错，原因就是没有回归原点。所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态，如果没有回归原点，就会把此脚本称之为死脚本。举个最简单的例子，比如添加用户功能，我们都知道每个用户名都是唯一的，当写完一个添加用户的脚本之后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时，程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下，我们就需要在自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据，比如ATM机取款，假设需要执行取款100元的操作，而银行卡余额是120元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成为了死脚本，解决方案有两种：一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于100即可）；第二种方法可以在用例执行前，先查询下余额是否大于100，若大于等于则继续，若小于则做一笔充值100的操作，这样即可解决。两种方式可以看具体情况使用，数据初始化方便，但有时候初始化之后可能会影响到其他自动化测试用例的执行，而第二种方式相对在脚本上需要稍微花点功夫。究竟使用哪种方式还需要具体情况具体分析。总之，在执行自动化测试用例之前做好数据准备，这也是自动化测试的关键步骤。

原则5：自动化测试用例和手工测试用例不同，不需要每个步骤都写预期结果。

在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。但是，在自动化测试用例的设计中并不采用，在自动化测试用例中，只有准备在测试脚本中设置成检查点的步骤才有预期结果，其他所有的步骤只将它看作一个步骤，这样做的好处是一目了然、目的明显、层次分明，以后写测试脚本直接跟着自动化测试用例就行了。因为经过前面的探讨应该已经知道，自动化测试中并不是所有的东西都需要验证的。所以，作者在前面的章节中也提到过，基本上手工测试用例多多少少都要进行一些转换的，就是因为它们之间的格式是不一致的。举一个简单的例子，假设需要设计一个注册页面的自动化测试用例，有10几个表单需要填写，在手工测试用例中，每个表单的填写都一定会有预期结果，因为它的确在检查每一项是对了还是错了，只是用的是你的眼睛在检查而已，所以速度非常的快，甚至你自己潜意识都忽略了其实你已经检查了。但是，在自动化测试中，我们知道如果你要检查，那一定需要写代码，如果每项都检查，那代码量有多大是可想而知的，不是说做不到，只是这样做根本不符合自动化测试的特点。所以，绝大部分时候，这些在自动化测试中可有可无的检查，我们全部“不检查”，只当做一个业务流程和步骤，是不需要设立预期结果的。

1.1.4 教父级自动化测试工具QTP

由于测试工程师经常会遇到许多循环重复劳动，非常枯燥乏味，给测试工程师带来了许多不必要的重复任务，因此，为了减少测试从业人员的工作量，自动化测试工具就这样诞生了。

目前，市面上的自动化测试工具有很多，选择面也非常的广，比如目前全球市场占有率最高的QTP，还有SilkTest、WinRunner、Watir、Rational Robot、TestComplete、RFT 等。这些都是目前主流的自动化测试工具，我们再来参考一下 Indeed.com 网站提供的一项从 2005年～2010年的主流自动化测试工具趋势分布图，如图1-2所示。

从图1-2中可以分析出，从2005年～2006年左右，WinRunner一直是主流地位，占有率最高，而从2007年开始，QTP慢慢地兴起，开始有超越WinRunner的势头，这段时间Mercury已经停止了WinRunner的版本更新、下载以及服务，而把主要战略方向转投向他们近几年非常成功的QTP。从2007年后半年开始，WinRunner开始走下坡路，而此时QTP和Selenium正以十分迅猛的势头赶超上来。直到今天，QTP 成为了最终的霸主，而Selenium排行老二， WinRunner 只能位居第三，其余自动化测试工具基本没有多大的变化。不过趋势图有些地方还是只能作为参考的，而且这张数据图的出处在国外论坛，不能完全反应国内的一些情况。作者个人感觉目前Web测试中开源的Watir测试框架在全球也有一定的市场占有率。那么接下来我们就来看一下商业化自动化测试工具QTP的实力。这里作者就拿QTP与Watir进行一个简单的对比作为参考，如表1-1所示。

可以看出，在表1-1中，QTP很多功能都是Watir无法比拟的。当然，此表也只是列举了一些表面功能上的对比，QTP还有许多更深层次的功能是其他任何自动化测试工具所无法比拟的。不过呢，任何事物都有两面性，有好的一面也总有不大好的一面，QTP最大的缺点就是价格相当昂贵，而且由于其商业工具的特殊性，所以不可能开源，导致无法对测试工具本身的核心进行个性化的扩展定制。这点Watir就比较好了，虽然有很多功能没有QTP那么强大，但其开源的特性使得我们可以对其进行随意的修改和扩展，可以把需要实现的功能进行二次扩展开发，同样也可以使其成为一款非常强大的自动化测试工具。不过这肯定需要非常强大的编程功底以及一定的开发工作量，需要投入大量的时间和精力。

从下一章开始，本书将对自动化测试工具QTP进行深度的剖析，同时结合大量新鲜实例，使读者能够在实际项目中掌握 QTP 的应用。内容会由基础核心、到高级扩展、到领先技术、再到框架展示，拨洋葱式的层层深入，让读者能够由浅入深地掌握好测试自动化这一门技术。

1.1.5 总结

本章节是作者根据其多年的自动化测试项目实战经验和学习经验的一个深度总结。可以使读者绕开弯路，循规蹈矩地认知到底什么是自动化测试，以及其中的一些精髓理论！章节中穿插了大量的实践、实用元素。

知识点巩固和举一反三练习

一、请审题后根据题目的素材设计“最最简单的登录功能”的自动化测试用例。

素材1：系统名称<XX自动化测试用例设计练习系统>，B/S架构。

素材2：整个登录功能的验证只涉及2个页面<登录页面>、<内容页面>。

素材3：“登录页面”具备4个控件[用户名输入]、[密码输入]、[登录]、[重置]。

素材4：“内容页面”中存在文字<欢迎回来，xx>，具备1个控件[退出系统]。

素材5：该系统如果不用手工清除IE缓存，不点击[退出系统]，直接关闭网页，下次访问无须重新登录，直接以已登录状态访问<内容页面>，非常方便。

素材6：在“素材4”中，内容页面里的文字专门用作检查登录系统是否成功。

二、请根据要求将手工测试用例转化成自动化测试用例。

要求1：需要验证点击[注册]按钮后是否能够成功进入注册页面。

要求2：“用户昵称”需要在测试脚本中验证字段。

要求3：需要验证注册完毕后系统的反应。

1.2 帮助文档（HELP）-QTP的说明书

阶段要点

• F1 的简单介绍。

• 焦点功能引导法。

• 脚本定位跟踪法。

• 查阅Example 实例技巧。

1.2.1 永远任劳任怨的良师益友“F1”

1.2.1.1 “F1”的简单介绍

F1 键相信很多朋友都不会陌生，举个最简单的例子，当用户打开Windows 自带的notepad （记事本），按下F1键后，系统就会自动弹出notepad的帮助文档，如图1-3所示。

不止是notepad有F1，微软Office的Word/Excel/PowerPoint有F1，QQ/MSN有F1，IE有F1，甚至是Windows的桌面也会有F1，不管你使用的是什么软件，F1总是能如影随形的跟着我们，在我们最需要的时候给予最大的帮助。这就是F1，在你刚刚入门时，它会成为你的向导栏；当你处于迷茫时，它会成为你的指路牌；当你准备学习前，它会成为你的教科书；当你需要查询时，它将成为你的小词典。

接下来就来看一下QTP中F1的使用，首先打开QTP，切换到ExpertView后，点击F1，就可以看到QuickTestProfessional Help 文档，如图1-4 所示。

从图1-4中可以看到有4个tab，在第一个tab中可以看到一共有8本书。

Welcome。

大致对QTP做了简单的介绍以及帮助文档的使用与更新。

What’s New in QuickTest Professional。

主要介绍了当前QTP版本的一些新特性。

XHP QuickTest Professional User Guide。

QTP的一些基本知识，建议初学者能认真的把这本书通读一遍。

HP QuickTest Professional for Business Process Testing User Guide。

介绍如何使用业务组件功能来进行测试。

HP QuickTest ProfessionalAdd-ins Guide。

对QTP所有支持的插件的使用方法进行了简单介绍。

HP QuickTest Professional Object ModelReference。

用于查阅QTP所有封装对象的接口与用法。

HP QuickTest ProfessionalAdvanced References。

QTP的一些高级用法，需要深入学习的建议读一下。

VBScript Reference。

对QTP的平台语言进行详细的介绍，查阅时也相当有用途。

1.2.1.2 如何获取最新的帮助文档

如果需要获取 QTP 最新版本或者任意版本的帮助文档，可以直接打开 IE，进入 http://h20230.www2.hp.com/selfsolve/manuals （需注册登录）。如图1-3 所示。

Product：

QuickTest Professional。

Product Version：

选择需要的版本。

Operating System：

Windows。

按要求选择产品以及所需要的版本并点击Search按钮后，页面下方即会显示所有文档的列表。左边一栏是标题，右边一栏是文档更新的日期，如图1-6所示。

1.2.2 妙用F1可事半功倍

做任何事情都会有一定的方式方法，好的方式方法可以达到事半功倍的效果，下面我们就来看一下如何才能更好地利用F1键来解决实际中遇到的问题。

1.2.2.1 焦点功能引导

之前说过F1对于新手来说是个非常有利的工具，它可以引导用户熟悉QTP的每项功能。当你的手指按下F1键的瞬间，F1就会被激活并且激活的内容会与当前的焦点自动匹配。这样的一种引导模式对于新手的学习来说，是非常便捷的。

→技术指导：切换焦点后点击F1。

焦点切换到DataTable，如图1-7 所示。

焦点切换到对象库（图1-8）。

焦点切换到SPY（图1-9）。

无论焦点走到哪里，F1都能精确地对内容进行匹配，可以充分利用此功能进行模块化以及针对性的学习。对于已经熟悉QTP的读者，此功能也是非常有帮助的。因为我们不可能把QTP的所有功能都一一吃透，大多数情况都只是对常用的功能比较熟悉，当在项目中遇到了瓶颈需要使用QTP的新功能或者新技术来解决问题的时候，在面对QTP的一些不是很了解或者相对比较陌生的功能时，此时最好的帮助老师就是F1。当然还可以找“百度大叔”。如果是对于每次 QTP 升级版本时的新功能发布而言，“百度大叔”也就束手无策了，最终还是只能靠F1。

1.2.2.2 脚本定位跟踪

刚开始学习使用专家视图的读者一定会非常困惑一个问题，那就是每个QTP的封装对象都会有N多个方法，每个方法都代表着不同的含义，有着不同的用法，在调用方法时还会有不同的参数，不同的参数类型以及是否有返回值等一系列的问题。

→技术指导：双击定位选取后点击F1。

我们来看一段很简单的脚本：

'************Launch IE **********
Systemutil.Run "IEXPLORE.EXE","http：//bbs.51testing.com/default.php"

' ************CLOSE BROWSER************
Browser("51Testing软件测试论坛软件测试|").Close

此脚本所实现的功能就是启动 IE，打开 51Testing 论坛后，关闭浏览器。这里的 Close其实就是Browser下的一个方法。这个方法可以实现关闭浏览器。这是一个非常简单的脚本，在Browser对象后输入一个“点”后，QTP会弹出很多的方法，而有些方法对于新手来说不是很了解，可以使用脚本定位跟踪的方法来掌握每个方法的含义和具体用法。

定位对象。

双击选中专家试图中的对象名Browser后，自动选中Browser脚本字符串，F1后页面显示对象的所有方法介绍，如图1-10所示。

定位方法。

当需要直接定位对象方法时，可以直接双击选中专家视图中的方法名Close，按F1键后页面显示Close方法的描述、参数个数、返回值等，如图1-11所示。

1.2.3 请遗忘脑中的代码，掌握查阅Example实例技巧

1.2.3.1 封装方法实例查阅

上一章我们讲了脚本定位跟踪，这一章主要来讲跟踪后查阅Example实例的技巧。在这里再次提醒读者，脚本不是死记硬背的，而是要活学活用的，成千上万个方法也不可能都把它背下来。所以，必须掌握这个技巧来应对下一个未知的方法。还是用上一节的例子查阅一个方法的描述如表1-2所示。

学会查阅方法是一种必备的技能，当看到一个陌生的方法时，必须能够会使用定位跟踪方法进行查阅，仔细查看对象的方法描述、语法使用、语法细节、返回类型、举例说明。特别是举例说明这一栏，作者个人感觉是很实用的。有时候一个过于复杂的方法，介绍也写的有些含糊，这时可以点击example实例进行查看能够省去很多的时间。如Close方法，如果没有看懂说明，就可以直接点击example，页面就会显示此方法的具体实例，如图1-12所示。

实例程序如下：

Sub Close_Example()
'The following example uses the Close method to close the
'Mercury Tours application.

Browser("Mercury Tours").Page("Search Results").Image("reserveFlights").Click 41, 20
Browser("Mercury Tours").Page("Method of Payment").Image("buyFlights").Click 11, 5
Browser("Mercury Tours").Close

End Sub

当看完此实例后，就能够轻松掌握Close方法的所有用法了。

1.2.3.2 VBScript 方法函数查阅

QTP的底层语言是VBScript，因此是否能够灵活运用好VBScript脚本语言在自动化测试中是至关重要的。VBScript虽然语法不多，也不是很严谨，但是方法和函数却非常繁多，往往新手在学习时都不能把全部的函数和方法都熟记下来，因此必须找出一种方式方法来摆脱这种非常被动的局面。通过F1定位进行实例查询，现学现用。

实例InStr 函数的定位。

首先在QTP里输入Instr，双击选取Instr后，点击F1进行内容定位匹配，接着就可以看到Instr方法的介绍与用法，如图1-13所示。

从帮助文档的说明中可以看到，此函数返回的是一个字符串在另一个字符串中的首个位置，参数一共有4个，如下所示。

Start：起始位置，可选。

String1：需要被搜索的字符串，必选。

String2：需要搜索字符串，可选。

Compare：比较方式，可选。

对于新手来说，看完以上这些说明之后，若还是比较迷茫。怎么办呢？可以直接把Example的内容拷贝到QTP中执行一遍，相信一定会恍然大悟的，并且会发现原来这个函数的用法是那么的简单，对自动化测试的学习也会越来越有信心。

InStv实例程序如下：

Dim SearchString, SearchChar, MyPos
SearchString ="XXpXXpXXPXXP" ' String to search in.
SearchChar = "P" ' Search for "P".
MyPos = Instr(4, SearchString, SearchChar, 1)
' A textual comparison starting at position 4. Returns 6.
MyPos = Instr(1, SearchString, SearchChar, 0)
' A binary comparison starting at position 1. Returns 9.
MyPos = Instr(SearchString, SearchChar)
' Comparison is binary by default (last argument is omitted). Returns 9.
MyPos = Instr(1, SearchString, "W")
' A binary comparison starting at position 1. Returns 0 ("W" is not found).

通过Example可以很明显地看出，需要搜索的范围是XXpXXpXXPXXP，而搜索的内容为P，第一个则是在这个搜索范围里从第4个位置开始搜索P，直到找到P位置，然后停止搜索，并返回找到的位置。由于此处的第4个参数是1，为文本比较，是忽视大小写的，因此，此处返回的位置为第6个，所以返回值也就是6，后面3个原理基本也是一样的，读者可以自行尝试琢磨一下看。

通过以上的例子相信读者应该已经学会了，如果通过灵活地运用F1来定位内容并匹配，能够现学现用。此技巧不管是对于新手来说，还是已经能够熟练运用QTP的来说都是必备的技能。一旦能够做好了这一点，就相当于把整个 F1 文档都搬到了自己的大脑里、相当于上升到了一个新的台阶。

1.2.4 总结

这一章节主要介绍了F1的使用，以及如何通过F1来提高学习与工作的效率，以便掌握现学现用解决实际问题的技巧。虽然这一章的内容较为简单，但是这一章的一些技巧基本会贯穿整个自动化测试学习的过程。需要掌握的是定位跟踪的查阅技巧，而不是去背F1。这才是作者要讲这章节内容的关键所在。希望读者能够牢记并灵活应用。

知识点巩固和举一反三练习

1．请利用F1查阅SystemUtil对象的具体用法。

2．请根据以下代码利用F1脚本跟踪定位法来查阅filter方法在如下代码中的用法。

Dim arrIndex
Dim arr (3)
arr(0) = "Quick"
arr(1) = "Quick Test"
arr(2) = "Quick Test Professional"
arrIndex = Filter(arr, "Test") ' MyIndex(0) contains "Monday".
MsgBox arrIndex(0)