我的最新日志

  • trc文件的无限扩张

    2008-9-28

    这次测试中，遇到了一个问题，测试过程发现数据库服务器的CPU过了一会就涨到了100%，感觉奇怪，去一查，发现数据库服务器的硬盘空间满了。

    原来在性能测试过程中，TRC后缀的跟踪文件太大了，有70多个G,把硬盘给占满了。最后，请教公司的DBA,才搞定。限制TRC文件的无限制增长。

    --登录数据库
    sqlplus "/as sysdba"

    --;查dump文件存储路径

    show parameter core_dump_dest;

    --查dump文件大小设置
    show parameter max_dump_file_size;

    --修改max_dump_file_size配置
    alter system set max_dump_file_size=500000 scope=both;

     

    修改后，终于搞定。

    查看(10) 评论(0)

  • 组合查询的参数化

    2008-9-22

     

    测试GIS中有组合查询。主题词和地址进行组合查询。

    1、参数的选择
    主题词：主题词包括一级、二级和三级主题词。在参数选取中不区分主题词级别，将1、2、3级主题词都做为查询条件，在测试时随机选择。
    地址：地址在数据库中存储的是完整的地址。根据实际需求，一般会选择前三个字与主题词进行组合进行查询。在数据库中使用select distinct substr(address,1,3) from customer; 选择地址的前三个字并且不重复的记录，做为地址参数。如果参数超过65534，就需要使用ULTRAEDIT进行编辑，不能使用EXCEL.

    2、脚本的验证。由于组合的条件有一些是查询没有结果的，需要手工选择组合后查询有结果的参数。可以在客户端先进行查询，得出查询结果，然后将主题词和地址分别放在各自己参数表的第一行，然后选择顺序执行，以验证运行的结果。不过，在执行场景时，要记得将参数表的执行方式改回到随机方式

    查看(21) 评论(0)

  • 如何判断LR事务是否成功

    2008-9-16

    如何判断LR事务是否成功

     

    这周测试到ECOM项目的订单处理，操作过程为打开已提交，未完成的订单，将其状态修改为正常完成，确定。

    如何判断订单处理事务是否成功完成。可以在脚本中使用判断提交表单是否成功和检查点来区分事务是否成功；也可以在场景运行完成后来判数。

    在脚本中。1、订单处理怎么样判断是成功的。LR提供判断事务是否成功的函数。使用lr_start_transaction和lr_end_transaction.在事务结束时判断事务是否成功。

    lr = web_submit_data("operate.do",
    "Action=http://172.16.91.6:10080/ecom/hotel/order/audit/operate.do?op=audit&bookId={bookid}",
    "Method=POST",
    "RecContentType=text/html",
    "Referer=http://172.16.91.6:10080/ecom/hotel/order.do?op=edit&bookId={bookid}&module=manage",
    "Snapshot=t11.inf",
    "Mode=HTML",
    ITEMDATA,
    "Name=bookStatus", "Value=2", ENDITEM,
    LAST);


    wi= web_image_check("savesuccess", "Alt=保存成功", LAST);
    if (lr==0&&wi==0) {

    lr_end_transaction("订单处理",LR_PASS);

    lr_log_message("订单处理成功，订单号为：%s",lr_eval_string("{bookid}"));
    }

    else

    { lr_end_transaction("订单处理",LR_FAIL);

    lr_log_message("订单处理失败，订单号为：%s",lr_eval_string("{bookid}"));

    }

    lr为submit事务的值，如果返回0为事务处理成功。
    wi= web_image_check("savesuccess", "Alt=保存成功", LAST); 是使用图片检查。检查图片中是否存在“保存成功”的提示，如果存在，wi返回值为0.根据lr和wi的返回值，判断事务是否成功。（需要在运行时设置中设置检查检查点）

    以上两项是在脚本的判断事务是否成功。

    场景执行完成后，一种方式可以查看“订单处理”完成的事务，与数据库的订单的状态改变的数量来比较（在数据准备时，先记录订单正常完成的数量）。 第二种方式是查看执行日志，统计日志中事务成功的记录数。（需要设置运行设置中设置输出日志）

    查看(198) 评论(0)

  • QC客户端连接不到服务器

    2008-8-29

    客户端在操作时，网络中断，网络重新连通时，打开QC，报错。并且提示一些组件未下载。如图：

    按以下步骤进行检查：

    1、检查QC服务器没有使用代理

    2、清除CACHE,COOKIES,重启浏览器，或重启计算机。

    3、检查QC服务器的路径名、参数是否正确。

    4、ActiveX组件最好使用客户端安装（查看ADD-IN），而不要从服务端直接下载

    朋友告诉我，可以装QC EXPLORE.

    我自己重启了浏览器，就搞定了，所以没有试

    查看(25) 评论(0)

  • 职业发展瞎谈－－简历篇

    2008-8-27

    本来不想写的，这类东西太多了。不过这两天面试了几个人后，感触较多，就发发牢骚吧。

    这几天收到7、8份简历，发现都来自某地的不同大学，并且都是毕业后有一年的测试经验，我还想着，原来这个地方的测试业都发展的这么好了。广州发展的倒感觉慢了些。 

    面试了几个后发现有些问题：

    1、不同大学，不同的工作经验，但却有着相同的项目经历。都包括OA项目和太平洋网上商城。

    2、问过他们相互不认识，简历无抄袭，也没有一起参加培训。

    3、可能大部分公司都有OA项目吧，但查了一下所在的公司，发现有些公司根本就没有OA项目，有的公司有，但主要业务不是OA，象有一家公司是做GIS的，但此员工居然不知公司是做什么的。

    4、也不是同一个地域，在网上把OA项目的介绍一查，发现居然还有别的城市，也有这样的简历。

    5、精通了很多，面试时却发现基本的测试知识都没有掌握。用了工具，却根本不知道工具是做功能还是性能测试的。

    我无语，在浪费了查看简历的1个小时和面试的1个小时后，对测试应聘人员有些失望，非常失望。

    我一直认为，初级人员的简历可以写的美化一些，夸大一些，更可能获得面试的机会，但绝不是造假。

    唉，不评论吧。因为我无法知识简历如此雷同的原因是什么。

    最后引用一句话：“如果有一种语言，人没有办法用它说慌，那我一定要学；如果有一种语言，人用它说谎而不会被发现，这种语言我更要学”

      既然说谎不会被发现的语言还没有诞生，就让我们尽量多些诚实吧。

    查看(122) 评论(2)

  • 我自己表扬了自己

    2008-8-13

     

     

    每天睡觉前给儿子讲故事，都要讲一个“今天乖不乖”的故事，象往常一样，

    问他：“中午饭吃的快不快？”

    答：“快。”

    再问：“老师表扬你了没有？”因为小班的时候吃的快也会受表扬的。

    答：“没有，吃饭快老师不表扬，帮老师搬椅子才会表扬”。

    问：“那你搬了没有？”

    答：“搬了。”

    问：“老师表扬你了吗？”

    答：“没有，老师没有看见。”

    听到这里，我有些担心，怕会影响儿子的积极性。可马上听到儿子说：“我自己表扬自己了。”我笑，笑完后倒觉得很有些道理。小孩也知道只要是对的，哪怕老师没有看到，自己也为自己做的事情感到自豪。我们工作呢？在领导看到的时候肯定是振奋百倍，但你的成绩领导没有看到呢？你会不会也表扬自己，为自己加油呢？

     

    忘记领导吧，自己表扬自己！

    查看(42) 评论(0)

  • LR9.1 定义SLAs--平均响应时间度量

    2008-8-13

          LR9.1分析器里增加了SLA报告，其实就是把整个运行过程分解，对每个阶段都能够进行分析，并能列出每个时间段是否成功、失败，并对详细的状态进行分析。下面的例子是以平均响应时间为例的。 

         SLAs 使得你能够为你的负载测试场景定义目标。在场景运行时，Controller度量性能和收集数据。Analysis将这些数据与SLAs中定义的阀值进行比较。

    一、            定义SLAs

    当你设计负载测试场景时，你可以为性能度量定义目标或SLAs。当你运行场景时，LR收集并存储性能相关数据。当你分析运行情况时，Analysis将数据与SLAs进行比较，以决定定义的度量指标的SLA状态。

     

    根据你的度量值，LR按照以下方式之一确定SLA状态。

    按照运行的时间间隔确定SLA状态。Analysis按照设定的时间间隔显示SLA状态――如：每10秒－作为运行时的一个时间轴。

    在整个运行上确定SLA状态。Analysis为整个场景的运行显示一个SLA状态。

    二、            按时间间隔定义SLA目标度量

    对于平均交易响应时间（Average Transaction Response Time）和每秒错误数(Errors per Second) 两种度量，Analysis在每个时间轴内按照设定的时间间隔显示SLA状态。

    在时间轴内的每个时间间隔，如10秒钟，Analysis检查度量指标的性能是否符合在SLA中定义的阈值。

    三、            为平均响应时间度量创建SLAs

    1.            打开SLA向导

    Ø                    如果是在Analysis中，选择Tools>Configure SLA Rules。点击New。

    Ø                    如果是在Controller中，在设计标签中，在SLA面板中，点击New。打开了SLA向导。

     

            

    2.              度量――选择一个度量值。

      对于平均响应时间，LR在运行中使用设定时间间隔评估SLA状态的方式。

      在SLA status SLA status determined per time intervals over a timeline下，选择Average Transaction Response Time.

    3.              交易――选择交易

      在Available Transactions列表中，做为你SLA的一部分，选择你想评估的交易，点击Add. 你可以按住ctrl键选择多个交易，选中的交易会显示在Selected Transactions列表中。

    4.              负载标准――选择负载标准

       为你的目标选择负载标准并定义适当的负载值范围

    Ø        在Load Criteria框中，选择你想使用的相关的负载标准，如Running Vusers。

    要定义一个没有负载标准的SLA,在Load Criteria中选择None。

    Ø        设置小于负载的范围。在Less than框中，输入一个范围的最大值。这个范围在0和你输入的最大值之间，但不包括最大值本身。

    Ø        设置包含（in_between）的范围。在Greater than or equal to/Between框中，选择Between,输入最大值和最小值范围，最小值包含在范围内，最大值不包含

    你可以设置3个in_between范围。

    Ø        设置超过负载的范围。在Greater than or equal to/Between框中，选择Greater than or equal，输入范围的最小值，最小值包含在这个范围内。

    有效的范围应该是连续的。跨度从0到无穷大。

    5.               阈值――设置阈值

      为你要评估的每个度量设定最大的阈值。

    Ø        如果你在前面的步骤中定义了负载标准，你要为每个交易的负载值范围定义阈值。

    Ø        如果你没有定义负载标准，你要为每个交易定义一个单独的阈值。

    如果你想为所有的交易设置一样的阈值，在下面的Apply to all中设置阈值，然后Apply to all transactions。

    完成。可以退出。也可以设定其它的SLA

     

     

     

    查看(22) 评论(0)

  • 谈一下我关于测试意识的想法

    2008-8-07

    一、     什么是意识？

    意识是生物和非生物共同具有的一般规定和本质。是人脑从生物和非生物的行为和存在中抽取出来的普遍性规定，是存在于世界万物之中的绝对抽象事物。

    意识和本能的最大区别在于，前者是在物质作用下形成的，后者不需要物质作用是先天具有的。我们在刚出生的时候，就知道吃、喝、拉、撒、睡这五件事，并没有外界作用。

    而意识的形成一定要有外界的作用，意识可以分为深层意识（潜意识）和浅层意识（表意识）。 表意识在你接触到外界事务时，会进行确认、分析、决定，是一个思考的过程；而潜意识在我们使用的时候，我们甚至都不会注意到它的存在。就象天生就会一样。

    二、     什么是测试意识？

    首先，测试意识是一种意识，需要外界的作用，测试不是一种本能。

    而当你拿到一个待测试软件后，你一般会对软件进行分析、思考、行动一系列的过程，是你的表意识在起作用。而一般人们说的，高手一眼就能看出问题来，让他自己说为什么？他却不知道，这就是潜意识在起作用了。那我们下面说的测试意识就是指测试的潜意识。

    三、     测试意识可以通过学习掌握吗？

    人们通过表意识进行学习和思考，所获得的新知识和新技能也首先表现为表意识，但如果同一种学习过程重复不断地进行（这样的过程叫做“强化训练”），那么大脑对所获得的新知识和技能的运用就从表意识就转化成了潜意识，即形成了条件反射

    所以潜意识是可以学习和修炼的。不过这是一个比较深层次的修炼。它对我们的学习和成长非常重要。只要有决心，有毅力学习，就一定会达到目标的。不是那个人天生就是测试专家，每个专家的成长都必须经过学习和实践，然后不断地总结、升华，然后才有可能达成自己的目标，或者更上一层楼。

     

    四、     测试潜意识的表现

    1、用户思维

       在我们初做测试的时候，很多时候在站在开发的角度，或者是测试的角度来找BUG的。但实际上，测试要求的是以用户为中心，一切以用户为前提。那么在你做测试的时候，会有意识地站在用户的角度去考虑，这个提示是否合理，是否人性化。这个界面，是否符合用户的使用。久而久之，就形成了潜意识。看到软件，就是站在用户的角度上思考，去找出软件中与用户习惯，用户思维不一致的地方，这就是用户思维。

    2、只要是软件，就有错误的意识

        你刚学测试的时候，看到软件，尤其是高手写的软件，并不觉得里面就一定有BUG。但只要是软件，就有错误的，因为软件是人写的，因为是人都会犯错误。这种观念被灌输多了，看到软件，立即就想找BUG了

    3、测试方法意识

    你刚学习测试时，对于回归测试，就要对照一下回归测试的方法，一点一点分析要测试哪些相关的范围，测试到怎样的程度。如果有了回归测试方法的意识，一看到开发的修改，马上就说，这个BUG可能影响那些功能，影响有多大。你把XX几个用例重新跑一下就行了。

     

    五、     怎么获得测试意识？

     

    1、学习；2、实践；3、总结；4、升华

     

    首先，学习是获取知识的一个重要过程，如果通过学习获取了知识，当遇到问题时，虽然你一下子想不出怎么解决，但你可以想一下，你学习到的方法，参照学习过的东西去得出一个解决方案。此时，只是表意识在起作用。

     

    在通过不断的实践后，你将你的知识运用到实践中解决了问题，那些这些知识在你的意识里更加牢固。但此时，你可能只是具备解决同样或类似问题的能力。如在某个测试工具中遇到了一个问题解决了，但在另一个测试工具中遇到问题，你却不知道如何处理。

     

    总结就是将你的经历沉淀，成为经验。也许一些人经历到一个问题后，就不会在同一个地方跌倒。而另一些人遇到同样的问题时，却没有更好的解决方法。这就是总结的能力不同。所以我们说经验，并不是说你经历过多少个项目，而是说你经历过了项目，从项目中学到了多少东西，成为你自己的能力。

     

    升华：从量变到质变。  量是你的积累，就是你的经验。质变，就是你整个能力的提升。需要多少量的积累，才能上升到质的变化。这要看你的努力，以及你的目标是否明确、专注。这在职业生涯规划中也有体现。如果你的职业规划不明确，或者在你中间与职业目标有偏离，都无法在你的职业中加上重的砝码，这就是有些人几年就可能成功，有些人却总在一个平台上绕圈。  升华还表现在，你对本质的抽象。如测试管理工具，不论是QC、TESTLINK、还是其它的测试管理工具，只要软件测试的过程没有重要的变化，那么所有的这些工具就都是相类似的。 测试方法也一样，你测试软件和你测试一根铅笔并没有什么本质的不同。所以建议下次面试别人的同事，就不用拿来搞个出其不意了。

     

     

    查看(122) 评论(0)

  • VuGen工作流

    2008-8-06

     

     

    1.         录制脚本

    a)         选择协议

                             i.              录制协议时只考虑客户端与它所连接的服务器间的协议，如B/S结构，一般选择HTTP协议，如果用户界面使用XML定义和描述，可以选择webservice协议（infogis项目），但协议只支持最多100个用户

                           ii.              HTTP协议：录制考虑

    1、  Recording Level：如果程序中包含了Javascrīpt并且该脚本向服务器产生了请求，选择URL-based scrīpt，否则选择HTML-based scrīpt。在advance选项中选择默认方式。

    2、  Browser： 除对浏览器有特殊要求后，都默认或选择IE进行录制。

    3、  Advanced:需要录制思考时间，并支持字符集：UTF-8

    b)        初始化、活动、结束

    LR场景在执行时，只执行一次init和end中的脚本，但可以对action中的脚本进行多次迭代，所以要进行区分。如进行“需求录入”测试时，登录退出只执行一次，那么“登录”和“退出”脚本可以分别放在init和end中，而“需求录入”脚本放置在action中。     

    c)        添加事务

    事务可以在录制脚本完成时添加，但最好在录制时添加重要的事务，以防止多个事务在脚本生成后无法区分开来。

    2.         验证脚本

    a)         录制完回放

                             i.              录制完脚本后，应该立即回放一次，主要是目的是验证脚本中是否存在关联，象动态的端口或session值，服务器端每次返回的不一样，如果下次客户端提交上次服务器端返回的结果，就会报错。此时，可以让LR自动检查关联，或者手工设定。手工设定关联时，可以以树形脚本的形式，查看服务器端返回的内容，以确定哪些是需要关联的值，也可以明确一下关联值的左右边界。

                           ii.              有一些内容是录制完成后，无法重新回放的，象增加订单，如果订单号重复，是无法插入到数据库中的，此时，需要对脚本稍微地修改一下，再进行回放。

    b)        查看回放结果

                             i.              回放完成后，可以查看回放的结果，只有回放结果中显示脚本回放正确，才可以进行下一步的工作。

    c)        验证数据库和客户端

                             i.              如果脚本执行完成后，在数据库中会增加记录，或者在客户端可以查看到，需要进行验证。如增加需求书，在数据库中可以查到新增的记录；而登录，有时有会有登录日志可以查看到。

                           ii.              如果一个脚本中，分多个事务，并且多事务可以分别验证的话，需要设置断点，对多个事务分别验证其正确性。

    3.         增强脚本

    a)         增加交易

                             i.              脚本录制并验证成功后，需要对脚本中的交易进行明确，如“需求录入”，前面有“打开需求书”页面的过程，此时要添加交易，把脚本按交易划分开来。

    b)        参数化

                             i.              如果脚本中有需要变化的值，需要进行参数化。参数化的内容需要和开发讨论，主要的原则如下：

    1.         真实：尽量模拟实际环境，其参数执行的方法也要尽量真实。如删除时，需要数据库中存在足够的数据，并且每次只删除一条，那么参数中应该选择唯一值的方法。

    2.         数据量：数据量要保持足够，最保守应该同数据库中的数据量在同一个数量级上。少于一定量数据的话，最好将数据库中的所有数据都拿来做参数。

    3.         数据来源：应该从数据库中导出。如果数据库中无数据，可以自己编造一些参数。

    c)        检查点

    d)        集合点

                             i.              使并发用户在集合点前等待，然后统一释放，以给服务器最大的压力。一般我们的测试尽量模拟真实环境。这种情况，象一些公用网站会发生。如奥运订票系统，一打开，马上就会有非常大的压力发生，这时需要增加集合点，模拟大而集中的压力。

    e)         备注

                             i.              好的脚本象好的程序一样，需要明确详细的备注，以备维护和重用。

    f)         日志

                             i.              输出日志到文件是查看结果好的方式，在运行后可以用来查看交易的详细信息

    4.         准备负载

    a)         要重新验证修改后的脚本。尤其是参数化后，参数选择的方式是否同设置的方式一致，结果是否正确

    b)        可以检查检查点、和日志输出是否正确。

    5.         完成脚本

     

    里面还有很多东西未写:(

    查看(26) 评论(0)

  • 订单号必须连续的处理和性能问题

    2008-8-05

    交易，会自动生成编号，同类需求的编号必须是连续的.

    两种处理方法：1、线程同步
                  2、数据库锁机制


    1、线程同步的方式，无法支持多应用服务器集群

         线程同步的方式：由于在应用服务器上就排队等待，客户端响应时间会增加。

    未解决的问题：10用户时响应时间超出了30用户，处理时间超出了LR设置的120超时，所以LR事务失败，但数据库中插入的数据成功。

         不知道是不是共享资源释放有问题，导致

    2、使用数据库锁机制。

        没有使用触发器+序列号的方式，因为如果事务回滚的话，序列号会丢失。

        开发自己写了一张表，存放记录，生成订单时锁住表中的一条记录。

    未解决的问题：5用户运行一段时间后，访问数据库的线程被挂死，等待客户端发送请求。不清楚是不是客户端请求未发送。
     
        使用的程序加锁和使用数据库锁有什么区别？

    3、也可以使用文件锁的方式

    查看(16) 评论(0)

我的最新文件