好久没有更新了。。。过段时间来整理下。。。。

夜陪朋友一起来上网，第一次在网吧上网，感觉还不错。很快的网速，很好的环境，让我感觉有点惬意，呵呵。

................

先说说我当初对公司Server测试时,测试工具的开发思路吧.选取了一部分,大家有个了解吧.这个思路最终没有行通.由于我们采用了新的框架.所以Window agent和server端的Listen program用更强大的开源项目代替了.其实思路是一样的,只是实现的东西变了.

1.系统分析

目前在Team里面大部分测试是基于黑盒测试的。尤其是在Function测试中，就没有自动化测试，一部分是由于Case条件所限制不能转化为自动化测试，但对于一些有条件的，我们可以试着去做些研究和转变。

由于Team的测试重点是在Server上面，按照黑盒测试的方法，Client端的Service一般用来作为测试的入口，通过Step去观察Server的行为。我们可以把整个测试过程分解成两部分，前台操作和Server后台。由于现在流行的自动化测试工具比较多，我们可以选择一种自动化测试工具用来录制前端的脚本，用来完成相应的Step，所有的客户端的操作，用自动化工具全部转化为相应的脚本。由于是自动化测试，我们可以增加更多的Step，这样做的好外可以考虑到在更多的客户端操作的情况下Server的行为和表现，因为以前考虑到黑盒测试的工作量问题，我们在前台操作Step通过是很少的，基本上只是一种，这样可能会考虑的不太周全。有了自动化测试这种方式以后。我们可以不考虑手工的工作量，尽可能的增加客户端的操作量，对Server进行更全面的测试。

现在关键的一个问题是如何对Server行为作为正确及准确的判断，大家都知道考虑Server端 最常见的几个标准是，是否Crash,是否High memory,是否High CPU,是否Memory leak等，这些标准在某种意义上就是我们在自动化测试中所说的检查点(Check Point)，这时候我们需要一个Server端的侦听程序，用来检查Server是否有上述情况发生。Server端的侦听程序需要我们来开发。

2.工具及开发语言选择

对于前端的工具选择，我比较倾向于QTP+TD，QTP(Quick test pro)是自动测试工具，TD(Test direct)，是自动化测试管理工具，主要用来管理相应的脚本及提供其它服务。这种工具组合我在前段时间试过，完成开会，加会，及运行各种Session没有问题，能符合我们的测试要求。主要是该工具提供了调用外部DLL文件的功能，这也是我们将要在后面设计中要使用到的功能。

Window Agent主要用来进行SERVER端和脚本之间通讯的Agent，运行在Window平台上，开发语言就有很多了，VC和VB都可以。

对于后台Server端的侦听程序的编写语言，我们将会采用C++或者Perl，这两者的功能都比较强大，可以完成我们程序需要的能力的设计。

3.系统设计及测试架构

现在的测试模式(黑盒测试)

 

 

自动化测试需要做的就是把相应的部分转化为自动操作，下面是与之相对应的结构图。

 

 

 

 

 

由于自动化测试工具使用的是第三方的软件，所以只需要建立好脚本就可以了。对于SERVER端的Listen Program是我们设计的重点。脚本和Listen program之间的工作流程是这样的，脚本在结束的时候，会调用Window Agent去向List program发送一个请求，去查询Server，List program在查询完之后将状态返回给Window Agent，同时Window Agent告之脚本，这里会以标志位的形式告诉脚本，在脚本里面做出判断是否有问题。接着再运行下一个脚本，以此类推。

List Program

    Listen Program包括了以下几个模块：侦听模块、系统设置、测试结果报告这几个大部分，下面是它的详细功能划分。

 

 

 

 

 

 

侦听

1.       侦听进程设置

本模块主要用来完成侦听进程设置，既，在本模块中，你可以对所需要侦听的进程进行添加、删除，修改等操作。

2.       侦听

本模块主要是完成侦听的功能，侦听的程序在本模块中实现，包括与Window agent的Socket的建立等等。本模块的侦听对象依赖于侦听进程设置中所设置的数据。

设置

1.       Check Point管理

本模块主要用来完成对Check Point进行添加、删除、修改等操作。Check Point主要是我们平时判断Server是否出问题的标准，如是否有Core文件，是否Crash，是否high Memory等。

2.       进程管理

本模块主要用来完成对系统的进程进行管理，目前Webex的进程是固定的，或许以后会有变化，在这里进行修改。

3.       其它设置

一些小项的设置都包括在这里面。根据实际情况来做。

 

Window Agent的设计

由于Window agent的设计其实只是提供了一个中间通讯的作用，也就是信息中转站这样一个角色，所以功能不多，只是负责与Server端建立起链接，同时向List program发送并把接受到的信息传递给脚本就可以了。

 

 

 

 

 

脚本与Window Agent的交互的具体实现

只有当脚本与Window Agent进行交互，才构成了整个系统的信息流通，这是至关重要的一环，在QTP里面可以调用DLL来完成，具体的步骤可以参考下面，事先用VC6编写好了一个简单的动态库，在QTP中调用该动态库中的函数是非常容易的事情。首先创建一个空的测试项目。

 首先启动 QTP，生成一个新的测试脚本，如下图所示：

 

 

 在下面的步骤中，我们不是选择录制操作，而是在脚本中直接编程。我们切换到
脚本的专家试图 Expert View 中，写下如下代码：

  

Extern.Declare micInteger, "TuxCALL", "D:\Develop\MyDLL\Debug\MyDLL.dll","",micString, micString
MsgBox Extern.TuxCALL("A", "B")

这段代码很简单，先是通过 QTP 的对象 Extern 声明一个方法 TuxCALL，然后调
用 MsgBox 把 TuxCALL 的返回值打印出来。我们使用 F5 热键运行这段代码，得到
的结果如下：

 

  看到这个结果，我们可以肯定地说，我们已经成功地在 QTP 中调用了 VC6 编写的一个动态库 MyDLL.dll 中的一个函数 TuxCALL。这个就是在 QTP 中调用外部动态库的基本方法。通过这个实验我们可以看到，QTP 有一个机制，可以确保 QTP 的脚本调用外部更加强大的开发工具开发的程序，使得 QTP 脚本变得功能非常强大。这个机制的关键点就是 Extern 对象。这种机制非常重要，它保证了 QTP 具有良好的扩充性。通过这个机制，我们可以立即在 QTP 测试脚本中调用几千个 Windows 操作系统的 API，还可以调用自己编写的函数，这些函数可能是用 VC/VB/Delphi 等自己熟悉的开发工具开发的。利用这种机制，我们可以让测试脚本运行过程中发现错误，就自动发一个邮件到我们的邮箱，或者发送一个短消息到我们的手机上。总之，通过这个机制，你可以让 QTP的测试脚本干任何 Windows 平台上的软件能干的事情。

     上面说了各个部分要完成的功能以及如何完成，其实这里面最关键的就是Linux端的List program 的设计。也可能是花费时间最长的部分。这目前只是我对于在Eureka Server这边实现自动化测试的一个思路，我还有些思路是建立在目前的思路的基础上的。如果这个能顺利完成，将对我后面的工作有非常大的帮助。

开了几天会,最终将第二季度的Goal确定下来了.难呀!没有办法,只能一步步来了.不过对于做开发-->QA-->开发的我来说呢.心里只能有点小底了.呵呵,臭P下了.从没想过要做一个自动化的测试工具.而且是用IBM的开源项目去做.有挑战,但我喜欢.嘿嘿.第一季度总算走的碰碰撞撞的,但算是知识积累吧.STAF+SAFS/RRAFS+STAX,我来了!

今天是使用51testing Blog的第一天,留个笔纪念下.稍后会有更好的东西放上来.先准备放个STAF+SAFS+STAX这样的Key-word driven 测试框架的东西上来,现在正在做.还没有整理好.