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

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

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

赫然发现自己最后一篇技术文章居然是2年前写的，太不给力了！ 过来锄锄草！

做了一年的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有特别提出来作为检查点。

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

          做测试工作那么久了， 编程知识还是少的可怜，趁着这两周不太忙的时间， 组织组内的测试人员自己开发了一个Task系统（即任务管理系统）， 这是一个小的不能再小的系统，  但是我的想法是希望借此机会锻炼一下测试人员的编程能力，

          虽然这个小系统的功能少的可怜， 不外乎新增，修改，删除，查询什么的， 却可以让我们开始一个比较系统的学习， 系统虽然小， 但是从需求文档，需求确认，设计文档， 原型，数据库建表，到开发的三层架构，到最后的测试过程， 我们都一丝不苟的进行下去了，我感觉到收获还是很大的。

         今天下午， 我们发布了我们的第一个Release版本，这次的测试工作， 久换位交给了我们组的开发们，在此也特别感谢我们的项目经理和其他的开发人员对于我们的大力支持，至少他们没有认为我们在浪费时间，打扰他们， 反而给予我们很多的帮助和相关的培训，

         PS：他们找bug的时候也是一丝不苟啊， 还常常教育我们：“你们不是常说×××么， 看吧， 现在自己范这个错误了！”

         这次发布的是1.0版本， 我希望我们以后还有更多的2.0，3.0版本， 随着版本的提升，功能的增强， 我们可以更好的了解编程知识，这些必将有利于我们今后的测试工作。So，Keep Studying！  

之前在51testing 上维护的博客， 因为遭到黑客的攻击， 丢掉了不少文章， 很是可惜， 现在新的空间开通了， 把我以前仅存的一些文章copy到这里来，

希望以后可以常常来看看， keep thinking， keep studying！

copy from wonder 8月日志

因为面对的是两个开发项目，做的时间长了，很容易对这两个开发团队的流程优劣有个比较。

团队A：

大项目， 人手充足，开发人员能力跨度从高到低分布均匀，流程较规范， PM很有经验，比较善于和客户沟通以及争取时间。

缺点是 ：

的接口容易出现责任模糊的问题。由于人员互相之间对于别人的流程完全不清楚，一旦出现人手不够需要互补的时

候，接收较慢，同时因为大家不是很主动， 一方面测试人员需要针对每个开发人员去

进行追踪，效率较低，另外一个方面造成做的过程中需求有疑问，却没有及时暴露给

PM，等到达测试手中才暴露问题， 浪费了人力和时间资源。

团队B：

中等项目， 人手少，且能力较弱（除了PM外，其余都是应届毕业生），有些不太遵

守流程， 对于需求的颗粒度把握不够，项目不够熟悉， 时间估计不充分，造成前

期松散，但是后期却频繁加班的问题。

优点是：组员之间关系特别融洽，互相交流比较多， 且有心去克服目前的困难，做进一步的提升。

&nbsp;&nbsp;&nbsp;这样的两个团队， 对于测试人员来说， 应该可以从他们身上学到很多项目管理的东西， 且可以把A组的优点暴露给B组，把B组的优点推荐给A组，让大家可以共同进步。 随着最近事情越来越多， 问题保露的越来越明显， 觉得是时候彻底解决一下了。

今天做了两件大事， 觉得收获良多，
1，针对项目A，

&nbsp;&nbsp;&nbsp; 和PM一起，明确了各人的负责模块逻辑以及目前的进展情况，记录下了各人负责部分的疑问点，&nbsp;&nbsp;这样的一次交流方，便我和PM后期的跟踪和及时的问题处理。以后应该定期进行。

2，针对项目B，

 大家开了一个小会， 总结了前面项目delay以及频繁加班的原因，制定了一套更加科学的流程制度，希望后面大家可以遵守并且确实发现卓 &nbsp; 目前可以考虑到的就是这些了， 项目管理是一门大学问，希望我在后面的时间中可以想的更深远，并且有更好的实践。

组内人员沟通比较少，容易造成消息不灵通, PM掌握各人负责模块的进度比较费心，且各模块之间

copy from wonder 8月日志

测试数据库原则上应该和开发数据库独立开

问题:  目前公司测试人员的测试数据库和研发人员的开发数据库没有独立开。

解决：测试人员的测试数据库原则上应该和研发人员的开发数据库独立开，

原因分析：
       1，测试人员构建自己的测试数据，在测试过程中观察数据的正确性，避免了受研发人员开发过程中针对数据库进行变动所引起的不确定性。
       2，测试人员如果独立自己的测试数据库，使用人数少，在通过工具跟踪程序运行的SQL语句时（比如事件探查器），可以使跟踪语句单纯，便于测试人员迅速掌握数据库之间的关系，便于查找到正确的数据库链接数，
       3，测试人员独立测试数据库，对于数据库的版本变更掌握更清楚，方便针对不同版本的客户数据库进行升级和维护，这样的做法针对测试人员担任发布角色，且客户版本众多的公司，尤为重要。 

 

copy from wonder 3月日志

原因分析：

 

copy from wonder 2006.9 日志

什么样的需求是一个好的需求？？

1,主要流程是否描述清楚,是否有二义性, 如“3个月以上”是否包括3个月,表现形式是否已经确定?

2,流程的分支结构以及分支处理情况是否考虑完全??

3,是否定义清楚与其他模块和产品的交互流程

4,是否考虑了新增功能点对原有功能的影响？

5,是否所有的系统输入已确定，包括其来源、准确性，取值范围和频率？ 9,所有的需求之间不互相冲突吗？

6,是否所有的系统输出已确定，包括其目的地、准确性，取值范围、频率和格式？

7,是否已确定所有的通信接口信息包括握手、错误检查、通讯协议、返回码的统一定义？

8,是否考虑了数据合法性校验的规定？

9,是否有说明系统非功能性外的其他要求?? 详细包括:操作系统支持??分辨率支持??其他软件版本(比如office,数据库)的支持??语言类别(简体,繁体,英文)的支持??

10,是否提供量化的性能指标 14,是否有系统失败和成功的定义

11,每项需求都可测试吗？每项需求是否能够独立得到验证？

12,从用户观点来看，是否考虑了操作的易用性和可用性？

（忘了在哪里看到的了， 加了点自己的想法）

copy from wonder 2006.05 日志

copy from wonder 2006.07 日志

目前的工作都是功能测试，每天就是不停的重复工作，最多进行业务上的扩展，如果光靠每天的工作， 很难再学习到更多的东西， 很想让自己的测试小组成员在测试这个领域上都能有长足的进步，当然也为了不断的提升自己， 所以想在小组里营造一种自我学习和互相分享的氛围， 不知道应该怎么样去开展？

目前的想法是每两周开一次分享会，但是分享的内容不知道怎么去确定，分享人又该怎么确定，如果不指定人员，大家一般不会主动请缨，很难有持续的过程；如果指定了人员，感觉就象是一种任务一样，不知道学习效果如何？ 另外关于分享的内容应该如何确定，现在也不太清楚，是应该1对多，即一个人学习之后，分享给每个人，还是多对多，即提供一篇文章，或者技术，由每个人去领悟，然后互相讨论呢？

因为没有这方面的经验，所以感觉很迷茫， 不知道大家在这些地方有些什么建议和经验可以分享和指点？？

&nbsp;

Link URL: http://blog.csdn.net/wonder4203/archive/2006/11/30/1421548.aspx

当一个项目同时来了两个需求， 且要求提交时间不一致，应该如何进行版本控制？ 怎么保证充分利用人力的情况下， 同时进行两个需求的修改，但是先发布的一个需求不会包含没有测完的第二个需求的bug呢？ 目前我们的做法是： 1， 当两个需求都比较小，且需求不紧急的时候， 和客户沟通， 争取将两个需求都做完之后同时发布， 2， 当一个需求做的时间比较长， 而另外一个需求很小，甚至就是简单的debug一下，需要马上发布， 则在VSS上保留原始的code 目录 来做时间相对而言较长的项目， 然后开出一个上次发布版本的Code 分支， 做时间紧急的项目。这样就可以两边同时进行修改而互相不影响， 最后在发布大需求的时候将小需求的code合并回去，（ 这里还是会增加一些重复的工作量）。注意在发布大需求之前，需要一直保留小需求的code分支， 方便合并之前的修改。

copy from wonder 2006.09 日志

 刚刚提上日程的自动化测试， 又被拖了下来，从一开始，我大概就是知道这个结局的，因为我就经历过这样一段挣扎的过程。不过我还是把它提出来了，因为如果没有真正的使用过，有过这方面的经验，有过这样力不从心的感受， 你就不会那么深刻的体会到， 为什么我们组的测试工作还不能使用到自动化测试工具？ 为什么我们还要一直停留在最最基本的手动测试上面?

我现在大概知道了一些玲玲当时的想法， 因为我也真的很希望大家可以多学一些知识， 可能明知这些知识暂时还用不上， 但是还是要给大家一个激励，自己学习固然是好，有一个推动和激励会让我们更加有动力。

很多人觉得做测试工作， 如果只是停留在手动测试的基础上，就没有意义了， 就太简单了， 就没有技术含量了 然而目前国内的现状很多都是这样的，毕竟我们的公司还在起步阶段，系统没有稳定，测试流程还不够规范，项目逻辑非常复杂的同时，测试人员的整体技术水平还有待提高， 在这样的大前提下， 要推行自动化测试真的很难。往往在浪费了很多人力之后， 才发现那些脚本起到的作用几乎微不足道， 才发现使用这些工具如果不具备良好的编程能力，不对脚本进行维护， 很多的check点，我们真的力不从心， 才发现常常很多脚本还没有使用到就又要被迫进行修改，导致我们觉得自己象白痴一样做了好多无用功。。。这些都是我们的阻碍。但是我要恭喜你们的是，在这样的公司里， 你可以学到很多在流程规范的大公司里学习不到的东西： 你可以以体验到一个变化的过程， 你更能体会到每一个规范的形成原因以及使用它的好处， 你可以从如何找到一个合适自己公司自己项目的流程的过程中学习到经验，你更可以从中找到分析问题解决问题，在挣扎后破茧而出的乐趣，而这些东西都是很宝贵的。

copy from wonder 2006.10 日志