QTP是HP Quick Test Professional的简称，主要用于Windows应用软件和Web应用程序的自动化功能测试。该工具是目前软件自动化测试领域的佼佼者，占有商业市场的绝对主导地位，所以这方面的教材和网络教程都非常多，所以本文不打算涉及与讲解QTP的基础知识和使用，而是通过笔者所主持的多个企业级大型QTP自动化测试项目（项目开发周期三年以上，自动化测试与开发周期一年半以上），并结合以下几个问题的角度来探讨QTP的实际应用经验与最佳实践：
● 什么样的项目（产品）适合用QTP实现自动化测试？
● 自动化测试工程师在项目的什么阶段介入最合适？
● 企业的测试能力成熟度可以分为哪几个阶段？QTP在其中承担什么样的角色？
● 自动化测试团队组织结构的特点有哪些？
● 如何以相对小的开发成本实现QTP对于非标准化控件的识别与操作？
一、什么样的项目适合用QTP实现自动化测试
简单来说，两句话就可以说明第一个问题，第一，产品或长期项目适合于QTP自动化测试，短期项目或一次性项目不适合于QTP自动化测试；第二，界面为主要交互方式的项目（产品）适合于用QTP，基于底层服务或协议的项目（产品）不适合于用QTP；另外，对于同一产品有多个客户定制版，并且各个定制版本功能基本相同的场合也是非常适合于做自动化测试的，因为这种情况下，自动化脚本的利用率很高。
二、自动化测试工程师在项目的什么阶段介入最合适
理想情况下，自动化测试工程师应该在项目开发的初期就介入到整个过程中。但是任何项目开发的初期都不适合大规模展开QTP脚本的开发，因为在这个阶段产品的界面设计还没有稳定，会导致QTP脚本的频繁变更，增大不必要的工作量，还会造成测试人员的抵触情绪，不利于自动化测试工作的顺利开展。但是，这并不是说在项目开发的初期，自动化测试工程师可以不参与到整个项目中。这个阶段，自动化测试工程师应该研究调查QTP对于所采用的开发技术的可用性，也就是必须对待开发系统的QTP可测试性进行调查，同时自动化测试工程师在这个阶段应该很好地学习被测系统的业务知识。期间主要考虑以下几个方面的问题：
a. QTP对被测系统控件的支持程度与稳定性
b. 若需要进行QTP二次开发，二次开发的难度与时间成本
c. 拟使用的自动化策略与框架
d. 考虑QTP上层的平台级测试框架（比如STAF/STAX等）的选型与应用策略
……………………
查看全文请点击下载：http://www.51testing.com/html/07/n-221707.html
随着测试工程师对于QTP学习和使用的深入，数据驱动的测试用例将被逐渐采用，这一方面提高了部分测试用例的效率，另一方面也增强了测试人员对于QTP应用的信心。但是随着项目的推进，自动化测试用例的数量越来越多，当被测系统发生变更时，自动化测试脚本的维护工作量也随之增大，往往一个小小的界面或设计变更会导致大量的测试脚本的修改，这个阶段的主要矛盾将集中在如何更好的组织自动化测试脚本结构，提高脚本的可重用性与脚本使用的灵活性。最佳实践是对于测试过程中的基本操作进行抽象，产生“原子”脚本与“分子”脚本，在实际的测试用例中调用这些可重用的“原子”脚本或“分子”脚本,这样可以大幅度提高脚本的重用性，并且可以很好的应对变更。
为了帮助更好地理解“原子”脚本与“分子”脚本的设计思想以及应用场景，这里举个简单的例子，假设我们有以下两个测试需求，一个是登录一个Web系统，然后通过输入条件来查询数据，最后退出系统。另一个是登录同一个Web系统，然后插入某条数据，最后退出系统。简单的录制/回放就是“一气呵成”，把整个操作过程录制成两份脚本。但是当用户登录界面变更的时候，两份脚本中关于登录的操作都要修改。当用户的测试用例非常多的时候，显然这个改动的工作量是相当大的。这个时候我们就可以采用“原子”脚本的思想，把登录操作，查询操作，插入操作和退出操作分别设计成四个“原子”脚本，其中登录操作脚本带有两个输入参数,分别是用户名和密码；查询操作脚本以查询条件作为输入参数；插入操作脚本以插入的数据作为输入参数；退出脚本不带参数。然后对于第一个测试需求，我们的测试用例只需依次调用登录脚本，查询脚本和退出脚本；对于第二个测试需求，只需依次调用登录脚本，插入脚本和退出脚本（这里同样可以采用数据驱动的参数化方法）。当用户登录界面变更的时候，我们只需要简单修改登录脚本。测试用例的脚本将不做任何的变动。这就是“原子”脚本的应用场景。至于“分子”脚本是对应于更高一个层面的，我们知道，现在的被测系统很多都是基于业务流的，要完成一个业务流的测试往往需要很多步操作，那么把完成这些操作的“原子”脚本组合起来就构成了“分子”脚本。通常要完成一个高层次的测试用例往往需要多个业务流的配合，这个时候的测试用例就是对“分子”脚本的调用了。简单来说，最基本的操作可以设计成“原子”脚本，对“原子”脚本的调用就构成能够完成特定业务逻辑功能的“分子”脚本，对“分子”脚本的调用就构成了测试用例。当然，测试用例也可以直接由“原子”脚本构成，这取决于测试用例的粒度和被测试系统的特点与复杂程度。
