昨天整个QTP调用外面DLL的代码，头都大了。基本摸清楚了个大概，下一步去探索Win32_API。

      正事没办好，倒弄出了一个歪点子。

      QTP用的VBS脚本，昨天有同事机器关不了机，点关机执行的即是注销操作。刚好用VBS有一开放的脚本是关于 关机的。大家可以照下面的办法自己做一个关机程序。

打开记事本，输入或直接复制：
cscrīpt shutDown.vbs
保存为 shut.bat (注意修改后缀名)。

在打开记事本，输入或直接复制：
Mychoice = inputbox ( "请按提示输入：" &  chr(13) & "普通关机请输入 1 "& chr(13) & "重新启动请输入 2 "& chr(13) & "强制注销请输入 3 "& chr(13) & "强行关机请输入 4 "& chr(13) & "强制重启请输入 5 " , "选择操作" , "5"  ) '此句不换行
If Mychoice=1 Then
 DownFlag=8
 elseif Mychoice=2 then
 DownFlag=2
 elseif Mychoice=3 then
 DownFlag=4 
 elseif Mychoice=4 then
 DownFlag=12
 elseif Mychoice=5 then
 DownFlag=6
 else
 msgbox "未执行任何操作！",64+0,"提示"
End If
set win32_OS=getobject("winmgmts:{(Shutdown)}//./root/cimv2").execQuery("select * from win32_operatingsystem where primary=true") '此句不换行
for each OS in win32_OS
OS.win32shutdown(DownFlag)
next
set win32_OS=nothing
保存为 shutDown.vbs (注意修改后缀名)。

双击shut.bat即提示关机操作，直接双击shutDown.vbs也可得到同样的结果（IE6支持）。

很简单，不会编程的同志们也可以自己玩玩乐乐了

用QTP调用自己写的DLL失败，不顺利。  

Extern.Declare micLong, "SetWindowText", "user32.dll", "SetWindowTextA", micHwnd, MicString '声明 SetWindowText 方法

hwnd = Extern.FindWindow( "notepad","无标题 - 记事本") '获取记事本窗口的 HWND

if hwnd = 0 then

MsgBox "找不到指定窗口"

else

msgbox   hwnd

res = Extern.SetWindowText(hwnd, "Set Title") '在此也可看出SetWindowText的用法了  '更改记事本窗口的标题

end if

FindWindow函数用于查找窗体   
函数原型
HWND FindWindow(
LPCTSTR lpClassName, // pointer to class name
LPCTSTR lpWindowName // pointer to window name
);
lpWindowName是要查找窗体的标题，即这里的“无标题 - 记事本”。
如果找到窗体，函数返回该窗体的句柄；如果找不到，函数返回空值或者零 。

句柄和窗口标题，若只知其中之一，""要用vbNullString表示  

    TD（TestDirector）是一个功能强大的测试管理系统，此系统涵盖了整个测试流程。相对一些其它的一些缺陷管理工具而言，TD容易操作、易学易上手。

    由于最早学习的就是TD，到现在已经有一段时间了，前两篇文章（自动化、QTP）居然把这个给淡忘了，惭愧万分   。

下面开始介绍一下TD吧：
    安装与我就不细说了，上网下载安装手册“下一步”就OK了。如果可以的话，安装程序里也有英文的帮助说明。配置此篇暂略过……  

TD主要分为四个功能版块：
    1、需求 Requirements
    2、测试计划 Test Plan
    3、测试实验室 Test Lab
    4、缺陷 Defects

    TD上需求是定义测试内容与详细的需求，理论上是由测试组完成的。但综合公司的具体环境，有些时候可能需要开发来完成。
    测试计划可以由需求直接转化（tools —> Convert to tests），也可根据需求文档自定义测试计划。
    测试实验室里，你可以创建执行流程。这里记录了所有你执行过的测试与结果。
    缺陷管理栏，记录了测试过程中发现的所有问题，与开发的交互多在于此。

    其实TD的操作并不难，没有代码，不会有太多文字，也全部都是很常用的控件组合。只要你熟悉这个测试流程，使用TD没有问题！  
    整体流程可概括为：创建项目，明确需求；根据需求生成测试计划；按照计划设计并执行测试；发现问题记录问题。
但实际应用中可能会遇到一系统的阻力了。
    例如你公司开发整个流程是否正规，是否有文档可依。你是否有权力或有能力参与需求的设计与修改。之所以我所谓的“需求有些情况由开发定义”。TD的功能就在那里，该怎么做合适，我想没有定论，需要根据企业实际情况来定了。  
    对于测试而言，我觉得能设计出一个合理有效的测试用例是最很需要的。这个需要你动脑筋，需要对你产品的功能及业务非常熟悉，否则写用例也是纸上谈兵。用例的设计格式，可以参考TD安装生成的默认测试演示库，那里就是设计整个“订飞机票”网站的测试流程，很有学习价值。  
    在测试实验室里，你可以像开发设计业务流程一样，设计出一个测试步骤一步步的执行（Execution Flow）。在执行网格里你可以看到测试的历史记录与结果，我们需要在这里查看测试的进度和BUG的分部。
    缺陷管理里，就是测试和开交流的天堂了。我个人觉得很好用！你可以通过对列的筛选，很快到找到你要需要的信息并进行分析。在测试执行时可以自动添加缺陷，里面还自动记录一些测试信息。在以后的回归测试中，R&D Comments里记录了开发和测试的交互过程，也可以查看历史记录（history）。分析结果并输出……
    有一个很隐蔽的功能，在右上角的 tools -> Document Generator 。你可以选择TD里任何你想要的信息，然后设置格式输出到WORD，下班后拿回宿舍分析。  
    菜单里的Analysis也是比较常用的工具，可以帮助你分析结果并输出报告。
      在Add-Ins Page里有很多插件，可以根据需要下载安装。有office插件、TD浏览器等等……
    不同版本的TD，功能核心都是一样的，只是外观有些变化，增加了一些小功能。至于现在出现的QC我也有幸尝试过，界面色调完全改了，多了文字处理功能、强化了图像分析功能。这些我想用过TD的朋友们肯定很容易上手的啦。
    讲到最后，连最重要的用例设计都没详细讲到。因为每家公司的产品和面对客户都不尽相同，其实没有一个固定的说法。我只浅谈一下我的感想吧：  
    1、设计用例之前，你必要非常熟悉产品。用产品的每个功能模块与关联要很清楚。
    2、更多的去了解客户的需要，有机会多和客服勾通。如果能和客户面对面最好了，客户对产品的要求往往和开发者会有一定的差距。了解业务流你会设计更实际的用例，发现更有意义的BUG。
    3、多和组内同事讨论，“三人行必有我师”。即使你再强，你也会有想不到的地方，一个人的力量是有限的。
    4、用例的描述，要简要、清晰。因为你设计的用例可能被别人执行、新员工的参考和学习。
    5、每个步骤，尽可能多的想到他的关联，但不要冗余（容易理解不容易做）。
    6、一个完整的用例应涉及所有的功能与业务需求（需要很周全的考虑）。
暂时想到的就这么多吧，欢迎广大的测试朋友们前来补充。
    所以，要设计出一个精炼而有效的测试用例，是不容易的。也是我们每个测试人员力求的！  
TD对于管理而言，相对于对工作进行了量化的标准。在TD上，你可以看到某个人什么时候在做什么事情、当前测试进度到哪了、某个版本缺陷的分布等等等等。对公司而言，产品库的建立是公司的一个资本。IT的工作量的一直是很难衡量的一个问题，TD在此对企业的管理者也提供了一些帮助。

    由于某些需要，可能我们需要尝试一些其它的管理工具。我个人也尝试过Rational、开源、其它的。Rational的那一套，我在自动化里有谈到。内容太多了，关于他的CQ，仅仅是缺陷管理，没有TD强大。但Rational是一套解决方案，CQ只是其中一个模块，拿起来和TD比有些不合适。Rational的资料在网上可利用的就更少了，我一直没有研究出什么成绩来，在此就不多说了  。网上还有很多缺陷管理工具，开源的bugzilla就有很多人推荐。但安装都很麻烦，不易维护，功能不也多，我也没有多研究了。还有试过TestTrack..... 这些功能都很少，仅相当于TD中的Defects。还是推荐用TD吧，其它小工具也有他存在的理由，适合一定的需求环境，需要大家可以搜一下。  

    这些可都是白手起家，“搜”出来的喔 :-0     

    在此我也谈谈对测试自动化的看法和经历吧。关于测试自动化的文章，网上有很多，大家可以去baidu、google搜索一下，会有很多文章值得我们参考和学习。

    刚刚接触测试，对测试里的一切都是非常有新鲜感的，而且也非常愿意去学习所有自己想知道的东西。慢慢地，我渐渐地了解了测试，融入到软件测试这个行业中来。从最初的学习软件使用、了解业务流程，到开始设计用例、执行测试……

    当一切开始不是你想象的那么神奇之后，你就会去尝试探索一些新东西，不断的充实自己。往往对于测试同胞来讲，除了理论知识，就是测试工具了。因为人们往往会用你所熟悉的测试工具来衡量你的技能。

    我经常会抽出时间学习自动化工具，虽然它会占用到我的个人时间，但学习的过程是快乐的。刚开始，我也听说了网上所谓的优缺点，然而不去尝试往往不会真正的去理解它。我的实践也证实了这一点。

    最初我安装了很多自动化工具，如WinRunner（WR）、LoadRunner（LR）、QuickTestPro.（QTP）、QALoad、Robot…… 好多，安装完成的那一刻仿佛自己已经学会了很多东西一样。然后有些没有试用版、不注册不能使用的，安装上去试试两下就再也没有用了。 最多尝试的就是WR、LR、QTP了，由于WR脚本类似C语言，最初我就选择了它。  

    使用WR时，当时才刚介入测试不久，也没有写过程序，对全英文界面、大量的代码，有点不从适应。虽然逐句去看，大概能看懂意思，但当时由于没有养成看帮助的习惯，学着学着就没兴趣了。
   对于LR，由于一气之下装了全部组件，弄了好久才把他的一些组件摸清楚。在网上下载了一些中文的说明和演示步骤，按照说明，我是一步步的学啊学，看啊看。照着说明一步步来确实没有问题，但是没有人告诉你为什么要这样操作？这一步操作和下一步操作有何关联？照流程走下来，也得到说明书上的结果，但结果里面又会有很多为什么。如：这个图示从哪里可以得来？如何去验证？    再者，抛开说明书，想来点“自定义”，那么问题就更多了……   
   然后就是QTP了，QTP对于我这个没有写过程序的，比较容易接受。简单的操作可以完全不接触代码，也是对着说明一步步来操作“嗯，通过，下一步……”。由于当时公司产品都还没熟悉完，了解了皮毛想拿来用，简直说明了我当时的天真~~~

   公司任务慢慢多了，时间越来越少了，该尝试的也尝试过了。慢慢的，那些自动化工具就这样被搁浅了。其实回想起来还有个原因：这些工具没有得到公司的支持、没有完善的资料、没有权威人可以讨教。

   日子久了，项目总有该完成的一天吧。都快一年了，自来公司后近一年内都在测试同一个项目，压抑了很久了。从再开始的“错误堆”到“使劲找BUG”，这个过程我想每位有做过测试的都必须经历的。

   我终于解放了，项目成功部署了、再次成功部署。留下的维护工作量就不那么大了，因为有客户帮我们做测试了    。空闲时间，我又捡起了阔别已久测试工具。从上次的尝试到现在，我已经重新了几次系统了，它们也从我的机器上消失了。前不久还在外面报了个程序设计的培训，会了一点编码。

   我又带着迷惑开始学习测试工具了，这些我就装了QTP，因为网上说他是WR的升级。这一装，我收获还不少。刚结束完编程的学习，对代码还算能接受。刚好学习的是VB，而QTP也刚好是用VB脚本，学以活用。干脆一不做二不休，我决定要把QTP学会。

   学习还是从说明书开始  ，可能是我急于求成吧，我学会一点东西就想拿到实践中来。刚好当时已经结束了一个项目，有C/S结构的也有B/S结构的。多就拿了一个WEB系统开刀了  。还真不巧，我还把一些功能真正的用到了公司的产品上。当然，中间有很多曲折的故事，在此我就不细说了，再另作文章详述。

自动化过程中，我就领悟到：
      1、自动化并不是很自动，需要花精力才能让他自动。
      2、自动化工具不是万能的，他也有自己的缺陷。
      3、并不是什么功能都可以自动化的，不要为了自动化而去做自动化。
      4、自动化永远不可能取代人工的位置。
      5、自动化脚本的维护有时是很致命的，需要有一定的经验才能做好。
      6、我们需要适度的应用自动化，某些时候他确实可以减轻我们的负担，
         代替我们做一些很机械的事情。
      7、某些测试必须用工具，如性能测试、负载压力测试etc.。
暂时就想到这些吧 *^_^*

总结一下自动化中常见的困难吧：
     1、对测试工具和自动化没有一个正确的认识和定位。
     2、企业没有进行相关的培训，没有真正开展测试自动化。
     3、没有一个好的技术主管或有经验的同事。
     4、测试工具自身的一些缺陷，包括文档的引导。
     5、没有一个学习自动好的环境和氛围。

    在我的学习过程中，文档往往都是在网上找的；出现问题没有人可问，一般都上Q找一些群发表问题、进论坛发贴子；学习的时间是自己抽出来的，利用上班时间不会得到领导的支持。

    发表这篇文件，是对过去经历的一次回忆，当自己低落的时候看看可能也有助于找回自我。

    一定也有一些朋友有过一些和我很类似的经历。也会有些朋友正在其中……  

     对于我来说，学习QTP是一个漫长而有艰苦的过程  。首先我不是计算机及相关专业毕业的（医学相关）。跳入测试部时，我正在接受程序员的培训课程。由于自己认为需要，于是开始学习QTP。

    刚开始使用QTP，就一直对着说明书，不停的“订飞机票”（订飞机票是说明书里的一个例子）。学会了一个步骤就拿到公司产品上玩玩，回忆起来还是挺有趣的。

   当我用一些简单的功能开始录制脚本时，发现保存ActiveXScreen的话，生成的脚本很中空间（因为程序会保存每个不同的录制页面），多录一些硬盘空间就满了，而且回放过程会很慢。  但如果不保存活动页（ActiveXScreen），对脚本的再改造/维护起来就相对困难一些。

   于是我开始去了解“关键字”视图里的内容，尝试了解代码。慢慢的，我了解到“关键字”视图显示了整个操作步骤，第个组件相对于程序里一个元素。同时还记录了录制过程对该元素的操作和结果。

    然后我又开始在论坛在找些资料看看，从有点所谓的高级应用中，我发现脚本的维护并不一定要有“活动页”。实际是QTP所有对象的识别，都存在脚本的一个对象库里了。QTP经常出现无法识别对象的问题，可以从这里着头修改。  
   为了减少QTP脚本占用空间大、录制慢的问题。我查阅了一些资料，可以在设置中进行修改，让脚本中不保存活动控件（ActiveX）或仅保存出错时的录制页面。干脆，我就从此录制页面了。所有的调试都从“关键字”视图和“专家”视图中进行修改。而且关于对象库，QTP也有个选项，可以设置加载页面上所有的对象，我修改成只保存页面上录制过程使用的对象。  这样，脚本的容量问题就解决了，录制后的脚本会比以前小很多，来了个彻底的瘦身。关于录制速度的问题，和保存“活动页”、动态脚本也有一定的关系，另外可以减小启动的加载项（如：去掉VB插件、.net插件，不需要的就不加进来）。这样的脚本上传到TestDirector上，或从TestDirector上调用就不会太慢了。

   然而真正的问题，棘手的问题就不是上面所述的那么简单了。不过都是有办法解决了的，嘿嘿……
   以下是我经常遇到的问题：
       一、无法识别控件。
       二、错误回放过程未知弹出窗口。
       三、加载.net插件后和TD的关联问题。
       四、动态加载元素的识别问题。
       五、调用外部dll的问题。
       六、随机验证码的问题。

问题一，解决办法有三种：
   1、更改QTP自身对某控件的识别方式，在 tools——Object Identification 中。在这里列出了所有QTP能识别的控件，以及控件的识别方式。你可以给他添加X、Y坐标进行识别。或更明显的，列表中的信息，不按名称识别，而是按ID识别。这个修改可以解决一些问题，具体的赶紧动手试试吧……
   2、使用虚拟物件，来定义一个控件，在 tools——Virtual Object 中。在这里可以自定义一个控件。例如在ASP的程序中，程序出错，在客户端的表现形式大部分是一样的，你可以把整个错误页面当成一个控件来识别（感觉不错）。如果加一个判断，出错后你想做什么就由你自己定了。
   3、使用低级录制或鼠标录制。用 Test——LowLevelRecording/AnlogRecording 吧，用它录制就不需要什么设置了，他会记录你的程序控件相对屏幕的位置。用LowLevelRecording还有代码可改，用AnlogRecording动作就被封装了（维护性极差）。两者因实际环境更取其长吧……

问题二的解决过程：
关于弹出提示的问题，我当时需要情况是这样的。一个信息录入系统，由于数据量很大，查询需要一段时间。QTP回放时动作比较快，点了保存，程序还没反应过来它就进行了下一步操作。这时的操作就和录制时不一样了，程序给出一个提示，但这个提示是录制过程没有的。弹出框是一般都是POP形势（至上）的，导致QTP无法继续回放，结果就是回放失败。  
解决办法有两个：
        1、进行判断，当出现这个提示时，点是/否/取消按钮。
        2、通过 Tools——Recorvery Scenario Manager 设置默认操作。
    我最初就是用的第一种方法。写一个函数判断是否出现这个提示，如果出现就点“取消”然后wait(2)。    每个可能出现弹出框的动作后都调用一次这个函数。虽然可以解决这个问题，但回放的效率就低了，而且需要你预知提示框的信息。
    当我知道了第二种方法，显然更科学^_^。它可以对所有预知甚至不知的提示进行指定的操作。
    实际上，当程序出现了未预知的提示时，可能就是程序的BUG，所以使用上述办法解决工具问题时，也要考虑是否会掩盖程序的缺陷。

问题三的解决办法：
      用好QTP后，会不自觉的和TD关联起来。但从TD直接启动QTP时，程序只会加载QTP自带的插件，如果你安装了其它插件（如.net、java、etc.），默认是不加载的。这会导致上传的脚本无法正确执行。解决办法很简单，去 Test——Setting里进行Modify 吧。从本地打开的脚本，这里不能进行Modify的。所以办法很简单，但如果不知道的话就很难了。当初为这个问题我可是废了八牛三虎之力呢……

问题四的解决过程：
     当我开始改代码时，定义一个动作，然后可以生成N个动作。假设N个动作产生了N个结果，你要对这结果进行处理时，你会发现这N个结果都不能被识别:

网页上有个表格，是往数据库里加数据的。
两个表格显示在同一个页面上，左边为父表，右边为子表。
点击左表，右表显示其子项目。 
结构如下：  
A
├─1
├─2
├─3
└─4
B
├─1
├─2
├─3
└─4
                    ……
思想很清晰：
添加一个父项A、选中此父项A、对其添加子项1、2、3、4
添加一个父项B、选中此父项B、对其添加子项1、2、3、4  ……

代码也很简单：
dim M          '定义父项数
dim N          '定义每个父项包含的子项数

For i=1 to M
      Call 添加父项( i )       
      选中父项( i )              '问题就出在这里  
   For j=1 to bwfl step 1
       Call 添加子项( j )
    Next       
Next

现在问题出来了，思路应该没有问题（除非这方法真的行不通），循环也是顺着思想来的。

问题是，无法实现选中的父项（最多识别到一个）。
由于此循环可以在录制过程进行，如果不改变变量名称，循环可且只可以成功运行一次。问题是这个名称都是从DataTable里获取的。
因为，在运行过程中生成的项目没有加到对象库中，无法被识别。

   这个问题最后是从思想上解决的。答案是我做的是功能测试，为什么不先加父项，检查父项的功能是否正常，然后再去测子项的功能。不去改变名字，因为那没有必要。核心答案“功能测试、测试功能”。即对测试工具首先需要有正确的认识。
   当然，这个问题可以用代码去实现，但那需要有一定的编程功底且耗时，可维护性不一定好。有需要的朋友可以去试一下，然后把你的经验也共享一下。  *^_^*

问题五，是对QTP很大的一个扩充。  
    对于QTP调用外部DLL的功能，由于我的编程功底不够，没有相关人士配合我，我只能望之垂涎了！
    如果能调用外部DLL的话，QTP的功能就可以变得很强大。自己写的程序，自己编一些过程用QTP进行测试，我想“后果很严重”  。真想有一次给我尝试的机会……

问题六，解决办法有4个：
    1、测试的时候，让程序员把这块限制去掉，免去验证这关。
    2、让程序员提供一个万能验证码，测试可以绕过这一关。
    3、请程序员提供识别的方法，从获取的图片读出验证数据，再传给QTP。
    4、进行位图检查，将验证码分段进行图像验证。
    实际上，验证码的目的就是防止用程序灌水或机器录入信息。所以有点为难我们测试了。
方法1，如果程序已在发布并有客户使用，危险性是可想而知的。方法2虽然可以解决验证这一关，但跳过了输入码与验证码一致性问题。方法3就需要程序员配合了，可能就需要调用DLL了。方法4却将图像分段，把获取的图像和已经的图像进行比对，比对通过取对应的值；这个在数字验证会好做一点，因为最多就四个图像的比对。
    关于网上的汉字验证码，那块的测试我就不知道他们是怎么做的了。真想了解一下！  

    以上就是我对过去QTP学习过程的一个总结。供天下各界朋友参观、发言、讨论，也是对我过去的一个写照，可能N年后，自己看到会很有感觉呢  。

    现在又有项目来了，我学习的时间慢慢也少了。新项目里融合了C++程序，QTP对C++的识别似乎很不理想，也许是需要插件支持吧。过程中我尝试了Rational的Robot，Robot对C++的识别很好，但Rational一套组件内容太多，对汉字的支持似乎也不是很好。用了一段时间我就把它从硬盘中给清掉了……  
    QTP的学习就在此停住了，不能应用到项目中，单纯看着说明书的学习，我好像不太在行。  也许是真的需要活学活用，边学边用吧。或者我不够书呆子吧……