我们在做性能测试的时候， 经常会遇到response time太长的问题， 这里总结一下我所知道的需要考虑的问题如下：

1， 硬件配置不够好， 比如CPU， 内存， 硬盘。。
2， 数据库的数据库量大
3， 注意是否有杀毒软件和防火墙的影响， 比如： 杀毒软件忽然启动
4， 是否有做负载均衡， 如果有做， 检查发起的压力是否模拟了不同的IP，才能合理的运用到load balance
5， 考虑是否SQL语句需要优化， 比如多次查询同一个表， 没有使用到索引。。。
6， 检查是否设置了connection的限制，致使服务器只能处理有限数量的请求， 其他的处理等待状态。

欢迎大家根据自己的经验进行补充。

做了一年的BPT Framework，现在customer又提到了想要使用QTP framework，

借由这个契机，对于BPT framework和QTP Framework进行了简单的分析和研究：

 

1，QTP framework 通常是customized Framework，所以常常会由于被测环境的不同

以及designer 不同，每个公司的Framework 会有很大的差别，对于新人或者别的公司的人理解起来会需要消耗时间，

     BPT Framework则是HP推荐的标准Framework，只要使用的是BPT的框架，理解和融入它是非常容易的。

 

2，由于QTP framework的特性，scrīpt的重用性不高，BPT 重用性相对来说高很多。

 

3，QTP Framework 支持使用所有的验证点，但对于测试人员的编程语言和工具使用

要求更高，

   BPT在使用验证点上有所限制，即使是不怎么会编程语言的人员也可以创建自动化测试脚本

 

4，QTP framework，脚本编制时间， 调试时间以及运行时间相比BPT framework都会很短。

 

5，如果想要进行Peer review （double Check）， 对于 QTP framework 来说难度，对人员的

要求以及时间都会比BPT framework 要大的多。

 

比较下来，两种架构各有优劣，不过如果不考虑运行时间，对于公司来说，选用BPT Framework还是利大于弊。对于测试人员来说，如果要提高自己的编程水平和技术能力，选择QTP Framework 更有利于个人的发展。

Recently, one of my customer has met such problem:

He is trying to use FireFox to login QC8.2. as we all know that QC8.2 only support for IE6, and fortunately, we had found a add-in for Firefox2.0, here is the way to solve it:

1,download the file “mozactivex-ff-15.zip”

2,then rename the file as this format: “mozactivex-ff-15.xpi”

3,open FireFox, and then input “about:config” in the URL.

4,drag the file “mozactivex-ff-15.xpi” into the browser FireFox, browser will ask you whether you want to install the file. just install it.

5,find the Preference named “security_classID_allowByDefault” under list, then double click its status from false to true.

6, You can log on the QC8.2 By FireFox now.

经历过几次大规模的集成测试了, 每次都或多或少的会有一些问题, 这里做一个总结, 希望对后来人可以有一些帮助.

这里说的集成测试, 主要针对不同开发Team开发的系统之间的集成,

 

1,接口一定要定义清晰和明确

   接口定义阶段也需要测试人员的参与, 定义好的接口, 需要记录并形成相关的文档.

 

2,接口之间的规则, 命名等一定要规范, 且有据可依.,各自严格遵守约定.

 

3,集成测试之前, 集成的各自系统以及模块一定要做好充分的独立功能测试, 并且通过造数据的方式模拟

 过一定程度的集成测试.

   否则在集成测试中碰到的问题要花大量的时间去查找到底是模块自身的功能问题, 还是集成引起的问题.

   如果是自身引起的问题, 则会浪费很多时间在修改和回测, 造成其他集成方的时间浪费.

 

4,接口的任何变更一定要及时通知集成另外一方的开发和测试人员,

 

5集成测试点, 测试用例,甚至是测试数据都需要提前拟定, 由两方人员进行审核和确认.达成共识

 

6,其他:

     集成测试时间安排一定要一致, 避免无谓的时间浪费

      双方的版本控制问题.

     对于Bug的出现, 双方的开发人员都要去积极的寻找错误发生原因, 避免出现双方推诿的现象.

MSMQ(MicroSoft Message Queue，微软消息队列)是在多个不同的应用之间实现相互通信的一种异步传输模式，

它的实现原理是：消息的发送者把自己想要发送的信息放入一个容器中（我们称之为Message），然后把它保存至一个系统公用空间的消息队列(Message Queue)中；本地或者是异地的消息接收程序再从该队列中取出发给它的消息进行处理。

 

消息队列建立在Computer Management中, 路径如下:

MSMQ的测试也算比较简单:,但是由于消息的编码大多是二进制, 为了让测试人员可以更清晰的查看到发送的消息内容是否正确, 我们使用了测试工具 QueueExplorer

使用工具的好处:

1, 会转化消息内容为XML格式, 方便测试者查看消息内容

2, 可以编辑, 保存并导出消息的body, 然后模拟发送重复的消息.

3, 可以远程链接并且查看其他机器上的消息队列

4, 可以模拟无数封消息的同时发送, 用于做性能测试.

 

二进制

XML

 

当然还有其他很多功能, 由于时间的原因, 我们还没有去研究和发现..

:另外也可以让开发帮助制作消息查看工具.

 

测试消息队列的主要check 点:

1, 检查是否发送成功, - check 消息队列中是否已经有特定队列名称的消息

   我们使用了Windows Service 来获取消息, 可以关掉服务来查看 队列中的消息, 如果开启了取消息服务, 则可以查看历史消息队列.

 

2, 检查发送的消息内容是否正确

   A, 检查XML的内容, 字节是否完整, 每个字节对应内容是否正确,

   B, 检查服务获取消息之后, 数据库中的更新和变化是否正确

3, check 异常信息

   A, 如果消息内容有错误,  Service 无法进行正确的处理, 会有怎样的表现?

     ________ 扔掉或者Send Mail (和开发人员进行事先的约定)

   B, 如果队列故障坏掉, 或者达到设置的存放消息最大数量限制 消息无法放进去, 会有怎样的表现?

     ________ 如果是重要的消息, 可以放在其他的Queue, 如果是不重要的消息是否可以扔掉?

   

一，问题发生原因：
New PO单（采购单），填写信息以后， 点击保存，系统生成流水号PO＃，客户反应有时会产生重复的PO＃。 （该问题属于历史遗留问题）

二，问题探索：
测试人员进行功能测试， 并没有这种现象的发生， 该问题在客户环境上出现频率也较低，
初步判定这是一个并发问题，

判定之后需要做的一件事情， 就是如何去重现这个问题， 以验证我们的判定是正确的：

1，  使用LoadRunner 模拟生成PO单的操作，并发点设置在Save 按钮处。

   经过尝试， LoadRunner对于Remoting 方式的程序支持程序不理想，无法进行新增PO的录制

2，  直接设置 PO主表的PO＃，为 unique（不可重复），使用do{} while()等类似语句，尝试生成流水号并插入数据表，如果插入不成功会重新生成一遍插入。

这样做的问题是：

A，  会导致插入失败，提示信息容易导致客户不满，

B，  会导致一些用户执行时间过长， 影响效率，

C，  该办法只是最快解决问题的一个办法，为备用办法

3，  直接验证New PO功能所调用的SP ，验证其并发是否有问题

由于不知道有没有性能测试工具可以进行SP的并发测试， 考虑到了自己写测试程序， 生成多个线程，每个线程并发调用SP的形式来模拟SP的并发运行。

三，方案验证：
考虑到SP执行的时间比较短， 而生成线程是采用循环方式生成， 毕竟还是有先后顺序，为了使并发情况产生的更加明显， 特意让每一个线程都连续调用三次SP，（次数可以自己设置， 这里使用三次主要是考虑到生成的PO＃也不要太多， 否则不容易看清楚），

界面元素：

User Number： 预计生成的线程个数。（Edit box）
Purno：最终生成的PO＃（ListView）
During：Sp执行需要花费的时间，顺便检查线程阻塞情况。（ListView）

主要代码如下：

for(int i= 0; i < num; i++)
     {
      ThreadStart start = new ThreadStart(CreatePONumber);
      Thread th = new Thread(start);

      th.IsBackground = true;
      th.Start();
     }

CreatePONumber 为执行SP的函数，函数主要内容如下：

for(int i = 0; i < 3; i++)
    {
     DateTime startDate = DateTime.Now;

     object ōbj = cmd.ExecuteScalar();

     DateTime endDate = DateTime.Now;

     if (obj != null && obj != DBNull.Value)
     {
      ListViewItem lvi = new ListViewItem();
      lvi.Text = obj.ToString();
      lvi.SubItems.Add(endDate.Subtract(startDate).TotalMilliseconds.ToString());

      listView1.Items.Add(lvi);
     }

运行结果： 果然生成了重复的 PO＃，并且重复的形式如下：

            19998，19999， 20000，20002，20002，20003 （在20000之后没有出现20001）

            重现成功！

          

四，解决问题：
经过分析， 发现是因为SP中的 一个语句顺序错误引起的， 错误语句流程如下：

   Update SysData set PoNo=PoNo+1  where sysid='ABS' 

   select PoNumber=PoNo from sysdata where sysid='ABS'

   － 说明： PO最大number号会保存在 SysData 表中。 SP中先Update 了这个Data 表中的PO#, 让PO＋1，再查询这个最新的PO＃， 最后我们会将查询到的PO新number， insert 到PO主表中

分析之后发现，在进行update的时候因为会有排它锁， 在进行并发操作时， 前一个线程还没有来得及进行select语句， 后一个线程又开始update了， 于是会造成 前后两个线程都select 了后面的那个Po Number，导致出现PO number重复

修改之后部分语句如下：

BEGIN TRAN

       DECLARE @PONumber int

       select @PoNumber=PoNo from sysdata (tablockx) where sysid='ABS'

    IF @@ERROR <> 0 GOTO ErrorHandle

       SET @PONumber = @PONumber + 1

    IF @@ERROR <> 0 GOTO ErrorHandle

       Update SysData set PoNo=PoNo+1  where sysid='ABS' 

    IF @@ERROR <> 0 GOTO ErrorHandle

       COMMIT  TRAN

       SELECT @PONumber AS PONumber

       RETURN

ErrorHandle:

       ROLLBACK TRAN

       SELECT PoNumber = 0

 

五，回测：
     经过回测，功能正常， 没有发现有重复PO出现， 且 SP执行耗用时间前后对比 差不多， 没有引发效率问题。

结束语：
     这是一个没有使用性能测试工具的简单性能测试实例， 这里分享给大家，希望可以对于各位今后的工作有所帮助。

QTP 工具的使用在经过了5天早起的折磨和全英语授课的磨难后， 终于培训完了， 培训归培训， 需要的是持续的学习和大量的实践， 在同时经历过QTP和RObot的培训后，今天想说一些我感觉中的QTP 和Robot 的区别（针对自动化测试部分）：

1， QTP的确比较容易上手，操作也比较人性话，这也是大家公认的，

2， QTP 在9.1版本中增强了 Object Repository 功能，增加了Object Repository Manager 功能 可以让定义过或者曾经识别过的Object在其他录制脚本中重复使用， 这是robot 没有的功能。

3，在录制过的脚本中需要进行增加某些步骤时，QTP使用了KeyWord－Driven的概念， 可以手动设置，

   Robot 在则可以通过 Insert at Cursor 方式 进行插入录制， 这里是各有各的好处。 

4，QTP 如果想要在某个test flow 中使用某个录制过的action， 需要将该action设置为reused，

    Robot 只需要语句call 就可以完成。

5，Robot 可以通过环境变量设置自行启动和运行的时间，和Test manager 协作自动按照顺序运行某些脚本。

   QTP 我还没有了解到相关的功能。

6，QTP 支持 c/s 架构的程序还是不如 Robot， 起码对于我目前测试的 .net 程序来说， QTP居然不识别一些常用控件， robot 则完全没有问题。

7， Robot 检查点更多一些， 比如windows Existence 和Alphanumeric有特别提出来作为检查点。

上面只是我学习之后最直观的一些想法，可能由于使用深度的原因有些出入， 也欢迎大家指正。