使用QTP+框架做自动化的一些想法

+J"_'{*]C#nj(`0  使用自动化框架，首先还是先要了解框架，源代码，运行机制，数据处理机制，错误处理，如何写报告|日志等，这也是一个自我提高的过程。51Testing软件测试网&x1d~EvR
  写脚本之前，场景分析不可或缺，如何写基础的业务函数，从而一劳永逸。简而言之，有两个相似场景，A\B,然后你要先实现A,先要开发个函数c以供b调用，那么你就要综合考虑，这个c对于以后的B场景，甚至DEF场景是否适用,不能图简单，先随便写个凑合用，等到最后，你会发现重构这个函数c将会耗费你大量时间精力，好比盖房子，打好地基最重要。51Testing软件测试网szPRI0ic
   封装:封装qtp的函数，一来统一脚本风格，二来方便自己使用51Testing软件测试网2b+~Mt_}/J
   现在比较常见的qtp框架，qtp+excel+vbs，qtp是最起码的，excel用来管理数据、写报告等，毫不夸张的说，如果你对vba（Visual Basic for Applications）足够了解，vbs也不差，那么你也可以自己写框架51Testing软件测试网:G!Crc*p_:x
   做自动化，首先要明确目的，是来冒烟，还是用来回归测试？做到什么程度？覆盖率多少，？成功率要做到多少？尤其是，现在敏捷盛行，当自动化遭遇持续改进持续交付的敏捷开发，我们要怎么应对？
'P6KXn2d'd1]0   如果冒烟，顾名思义，不用做太多，主流程，主功能，迅速冒烟之。
@|[1sx;Dw
e!y0   如果是回归测试，那么问题来了，自动化做哪些？覆盖率，成功率，问题接踵而来……，51Testing软件测试网l G^,V qa
  首先，可以找手工测试人员要一份全功能列表，然后自动化小组成员来评审，哪些场景适合做自动化，从实现成本、维护成本等因素来考虑，qtp过于依赖界面，如果界面频繁改动，那么就不适合做，一些复杂的场景、界面关注元素比较多的场景，果断放弃，可以做一些比较稳定的，基本的主功能，异常、分支流程等；51Testing软件测试网fjc s!jDs
   覆盖率，这个因系统而定，一般来说，30%差不多，50%就已经很不错了；
yF*T8Ir*y}?M0   至于成功率，当然是越高越好，但机器终究是机器，受多方面因素影响，80%-90%，可以接受，当然这个也要看boss们的要求，这也正是让自动化测试人员倍数煎熬的地方。51Testing软件测试网'SjW(W(eqd
   对于敏捷模式下的测试，持续交付持续改进下，个人觉得自动化的意义在于频繁的代码改动部署后，迅速的进行回归，发现问题，从而让开发人员迅速的响应解决问题，这也正符合敏捷的思想，因为，手工测试人员不可能在每次部署代码后，都把全部功能一个不漏的执行一遍，而最主要的是，你不知道，每次打包后，将会出现多少不可预知的缺陷。51Testing软件测试网-[0b8V1Ve_3ws$_
   当然，稳定、健壮、高质量的自动化脚本是前提。51Testing软件测试网7R8ak!G rM8P-i+i

)\2mX,^\:FY'^i0
z]*B3W+tz!I}v)c0 51Testing软件测试网j [VdD3m9@!B$O