• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• QTP Framework 和BPT Framework 利弊比较

  2008-7-29

  做了一年的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 更有利于个人的发展。

  查看(31) 评论(0)

• 如何使用FireFox 登陆QC8.2

  2008-3-05

  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.

  查看(26) 评论(0)

• 集成测试需要注意的问题

  2007-6-21

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

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

   

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

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

   

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

   

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

   过一定程度的集成测试.

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

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

   

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

   

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

   

  6,其他:

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

        双方的版本控制问题.

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

  查看(147) 评论(0)

• MSMQ 的测试总结

  2007-6-21

  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, 如果是不重要的消息是否可以扔掉?

     

  查看(70) 评论(0)

• 一个简单的性能测试案例分享－“生成重复采购单号”问题的解决

  2007-3-17

  一，问题发生原因：
  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执行耗用时间前后对比 差不多， 没有引发效率问题。

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

  查看(177) 评论(1)

• 浅谈QTP和Robot 使用的区别

  2007-2-07

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

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

  查看(321) 评论(1)

• 从头学习编程知识

  2006-12-30

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

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

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

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

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

  查看(56) 评论(1)

• 有个新家了

  2006-12-08

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

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

  查看(64) 评论(3)

• 风险进行时

  2006-12-08

      一个新的项目正在进行中， 9月初就需要release的项目，现在都已经进入了开发后期，测试初期， 但是有一些需求，无论是开发还是测试都是迷迷糊糊的，项目的需求文档虽然出了几份了， 但也只是描述了大概，有些情况在编写测试用例，甚至有些到了执行测试阶段， 才发现原来流程中还存在这样那样的疑问。 让我感觉到心力憔悴的是， 如果我不去抠字眼，摸清楚流程，几乎没有人去质疑这个需求描述的是否清楚， 开发人员只是一味的做， 我都不知道他们是怎么做出来的？？？。。。

      我也知道这样做的危险性， 可我却是干着急没有办法，这个项目有一个特殊性， 一方面是时间压力大，开发人员就憋着劲的往前做， 一方面是我虽然是测试组长，却不能直接和客户进行沟通，这是规定， 不能改，还有一个方面是因为测试组为了弥补人力的不足，又增加了两名测试新人， 但是他们毕竟有一个熟悉期，测试理论的培训， 业务的熟悉，于是就造成了在他们可以接手的时候， 开发人员已经在提交测试了。。。于是问题很多是自然的，几乎每天我都去找PM要需求，确认问题。

      最近，遇到一个更严峻的问题， PM马上就要去美国出差了。虽然有人代理PM，但是我的顾虑还是很多 ， 他是否同样可以把握好需求？ 是否可以针对我的问题给出及时的反馈？对于这个项目， 我真的很担心。 理了一下我现在可以做的事情：

  1,自己尽量要把所有的需求都弄清楚， 尽可能早的把问题暴露出来， 让疑问更快的清晰化，但是这样做要耗费不少精力，因为项目太大，需求点多。

  2,尽可能多和代理PM沟通， 和远在美国的PM保持邮件的沟通。

  3,每天了解各个测试人员的测试进度以及疑问，进行汇总寻求解决方案。

  4,如果实在不行， 可能需要申请上早班， 便于和美国的PM直接电话交流。

  5,及时通报测试进度给PM知道

  
  
  copy from wonder 8月日志

  查看(49) 评论(1)

• 从两个团队中学到的

  2006-12-08

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

  团队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月日志

  查看(45) 评论(0)

我的主题

• 求助怎么可以让QTP识别command line?
• PM， Developer， Tester的组织结构应该