I believe I can fly!

发布新日志

  • LR性能测试:集合点释放失败

    2008-06-12 14:19:38

    主题:Rendezvous release failed
    环境:一台测试机,一台WEB服务器,一台装有ORACLE的数据库服务器
    测试计划:380个VU   10%并发    ramp up 10/5s   run for 1hour     ramp down 10/5s
    结果:在运行1小时之后,部分action释放失败,导致无法得到测试结果
    推测:是否380个VU 超过了当前测试机所能承受的能力范围(一般情况下,当前一台主流的PC设备能支持150-200个WEB协议的VUSER)
    分析:200个以下VU能够正常运行并保存结果;如果按上面的计划(380个VU)只运行10分钟时,结果也能保存,怀疑是因为时间太短并没有对测试机产生释放的压力.也有人分析是测试机内存不足;很有可能是因为负载生成时内存空间不足.
    网上资料:根据经验,每生成一个虚拟用户,需要花费负载生成器大约 2M 的内存空间。通常运行 controller的主机很少用作负载生成器。负载生成器的工作多由其他装有 LR Agent的PC 机来担任。如果负载生成器内存的使用率大于了 70%,负载生成器就会变成系统的瓶颈,导致性能测试成绩下降。这种问题需要添加负载生成器来解决。一台 512M内存的 PC 机大约可以生成 80 个左右的负载,而一台 256M 内存的 PC 机大约可以生成50到 60 个左右的负载。

  • 针对系统中新模块出现较多问题的情况做出的分析

    2007-12-27 10:45:02

    关于新模块出现问题较多的情况,我个人认为测试人员和开发人员还包括公司都需要做出总结,并在以后的项目中引起高度重视,正所谓前事不忘,后事之师。

    首先,需要关注的就是时间问题。安排测试的项目周期本来就不是很充裕的,更何况新的模块基本都是在靠近项目实施上线才基本开发完毕,项目测试越接近尾声,对于测试人员来说时间就是更为紧迫,需要完成的工作就越多,一边要负责已修复BUG的复测,一边还要完成用户手册的编写,甚至完成视频。测试文档资料的提供也是测试过程必不可少的一部分,而且是相当重要的一部分。很多时候都会因为系统界面上或者流程做了微小的调整而不得不重新调整用户手册或者录制视频,导致新模块的测试时间相对减少。

    其次,开发人员与测试人员的沟通不够。在新模块基本开发完毕时,也许只有开发人员还对新的模块有些熟悉,测试人员对新开发的模块就会显得略微茫然。因为是新模块,测试人员甚至都无法在需求中找到相应的参考规范,无疑影响了测试人员对新模块理解的广度和深度。比如模块间细微的关联性,各种状态代表不同的含义等等。只要开发人员能抽一点时间与测试人员做些交流,这样对测试人员在探究新模块的过程中,就会起到事半功倍的效果,提高了工作效率。

    最后,也是项目进行过程中最关键的一点:在未完成测试通过的前提下就直接去现场实施。大致浏览了一下最近的几个项目的TD,会发现出现问题多的模块都是BUG的状态还处于“open”较多或者还有部分“fixed”的。所以我提议如果要提高系统质量,测试主管对项目的评估和把关必须得到充分重视,不能一切都以项目经理为中心。

    以上纯属个人观点,如有不恰当之处,请指正,谢谢!

  • 分享知识(TD)

    2007-11-12 15:23:21

        十月最忙的一个月,终于在十一月初结束了忙碌的日子。主管安排了部门内的几个人相互分享知识。这个提议不错,我正愁着没办法学到更多的“未知数”。借此机会,取长补短,大家互相学习,共同进步。
        各自挑选了自己拿手的或者喜欢的课题。通过学习让我学会了很多之前都是一知半解的问题。今天我终于把TD给攻克:照着同事讲解的,自己根据资料,一步步操作下来。
    一、测试管理过程
    指定需求—》计划测试—》执行测试—》记录缺陷


    二、常用功能
    (一)基本功能
    1。导出到WROD ,EXCEL
    2。修改密码
    3。定义列
    (二)数据操作
    4。数据过滤
    5。记录分类
    6。刷新和清除设置
    (三)其他
    7。添加附件
    8。使用自己喜欢的界面
    (四)配置工程
    (五)配置用户
    (六)配置用户组权限
    (七)邮件配置

    三、四大模块
    (一)指定需求
    1。定义测试范围
    2。建立需求大纲
    3。建立需求树
    4。需求树上查询
    5。需求树上查看
    6。修改/删除需求树
    (二)计划测试
    1。定义测试策略
    2。定义测试主题
    3。建立测试计划树
    4。将测试加入到计划树中
    5。查看测试计划树
    6。将BUG关联到测试上
    7。查找测试
    8。测试计划树分类
    9。修改测试计划树
    10。建立测试覆盖
    11。设计测试步骤
    12。自动测试
    13。分析测试计划
    (三)执行测试
    没有具体实际操作(公司TD不支持)
    (四)记录缺陷
    这个模块在工作中用的比较多,所以学习起来容易上手
    1。添加缺陷
    2。比较缺陷
    3。修改/删除缺陷
    4。查看缺陷历史
    5。发送邮件
    6。查看关联的测试
    7。缺陷的状态

    四、图表分析
    这个功能模块用来统计报表,效果不错。偶喜欢。哈哈

        一路下来感觉自己对TD有了进一步的了解,终于体会到TD的强大的功能。在我学习的过程中,由于某些因素还没有完全把TD收为己用,希望在以后的使用过程中,我能更多的利用它,将它的价值充分地体现出来。希望自己再接再厉!加油。也希望在我们公司能将TD充分利用起来,别浪费了这么好一个资源。在我的提议下,主管终于让我们把新项目从需求开始做起。

  • 做测试真的很受伤很受伤

    2007-09-06 10:36:55

    这个月接手了一个“新项目”,其实并不能说是新项目,因为它早已经“属于”别人的项目,而我只是在后期负责对细节问题的测试,主要原因是在给客户上线演示时,出现了好多明显的BUG(比如点击“保存”按钮,出错),导致项目经理不得不让我重新负责测试(原先的测试负责人已经接手别的项目,而我刚巧完成了一个保险的项目,新项目也才刚启动),自然而然这个收拾烂摊子的活就落到我头上。我每天都将测试出的BUG记录在记事本(领导说以这个方式打开,速度快),然后整理到WORD(负责开发的工程师出差在外,不能用 TD来管理),以不同颜色标记修改的侧重点,然后发邮件给相关的开发工程师,由于对需求的不熟悉,这几天都在琢磨着如何把问题测的更透彻些,每天除了测试新的BUG,还要负责对已修改的BUG的复测。似乎忙得不亦乐乎,毕竟久而久之,就会明白哪个模块也哪个模块是有所联系的,哪里的一点改动就会引起哪几部分的变化。这样反复地测试,让我对系统有了进一步的了解。可是,让我郁闷半天的是,开发工程师回来我跟他说:如果有些问题你不打算修改的话,请跟我说一声我也就不用复测了。他的回答就当头一棒把我打得快吐血:你只负责测出问题,修不修改由我来决定。这是什么态度呀?我辛辛苦苦来给你们的烂摊子做测试,居然用这种态度对待我?心里郁闷极了。

  • 不同的对待方式产生不同的结果

    2007-08-16 16:23:14

    一件事情,“做”和“做好”是不一样的;一件事情,因为“钱”去做和因为“喜欢”去做,结果是不一样。

  • 文档测试

    2007-07-26 14:02:08

    昨天下午时分,主管交给我一个新任务,就是修复客户提出的BUG。这BUG可奇怪了,全部都是些文档BUG。之前还没遇到过。大致看了下BUG,才领悟到,原来是要补充用户使用手册。问题就六、七个并不是很多。但是针对系统全局问题,我这个新手还是有点怕怕的。新手也有些好处,啥都不会啥都敢接手。硬着头皮把活接了下来,只能安慰自己:也许这正是一个锻炼的好机会,可以对整个系统有个全面的了解,理清了一次,以后就类似的系统我就可以了如指掌。主要是难在以下几个问题:

    1.  工作流中所涉及的状态;(我连总共有多少工作流还不清楚呢,嘿嘿。)

    2.  业务流程的状态;(多少业务流程呢,心里也没底。)

    3.  单据的编号规则。

    最后请教了开发人员才勉强理清了思路,整理好文档后,自己松了一口气。花了一个下午的时候,结果我收获的也不少。在以后的测试过程中,我会更留意系统的一些细节问题,总结规律,分析各系统之间的共同点以及差异。

  • 终于等到这一天

    2007-06-07 16:09:30

        早上去了趟领导办公室,柳总说来了个新同事,顶替你的岗位,今天就把工作交接一下吧。我听了乐开了怀,终于是等到了这么一天。我是生怕公司只是忽悠我一下,没想到这回来真的啦。一直都是在公司里充当跑腿的角色,哪里有缺人往哪赶。一会儿说让我转客服部,可惜公司还没成立客服部门呢。想当时老板和柳总都找我谈话了,嘱咐我要多学习,培训个把月就去做客服。结果一个月过去了,一点音讯都没,这事也就不了了之。从此我就坚信凡是没有成定局的事情都随时变化的可能,特别是企业里,象这种小企业没有规范。
        我把所有关于销售的资料统统整理了出来,并写了一份报告清单,以便新同事核对任务的交接。我仔仔细细跟她讲了一些重要的工作流程,还有部分工作我会在实际操作中给予指导。交接工作一直会持续到这周结束,因为正巧有个投标项目要我跟踪,随便也指导一下新来的同事。希望她做的好,那我也可以转的安心一点。当销售经理听到我要转部门的消息,往着他们那惊奇的眼神,我还真是有点舍不得,有一份眷恋,有一份信任,有一份并肩作战的感情。许多往事浮现在我的脑海里,我曾奋斗过,我曾受挫过,我曾努力过,我曾开心过,我曾悲伤过,在这片土地上我慢慢成长。。。
        我只能告诉自己:人总是要往前走的。迎接我的将是新的一片天空,在那片向往的天空中我将风雨兼程,不管前方有多少阻碍,我都要克服,让暴风雨来的更猛烈些吧!

  • 新项目 新起点

    2007-05-15 17:04:57

        昨天下午测试主管给我发了个邮件,附件是新项目的需求规格书,让我抽时间熟悉熟悉.从昨天下午开始我就开始慢慢的"文档熟悉长征".刚开始看得津津有味,可是渐渐地头有点晕,字也变得密密麻麻,象蚯蚓在蠕动.文档实在太枯燥无味了,以前我也负责过文档的编写工作,由于我的脑袋里没有新鲜的词汇,没有华丽的词藻,没有一点点的创意.可是现在我得克服困难,我得硬着头皮看.测试员需要从项目前期就介入到项目中,只有完全了解了客户的需求,才能真正测试好客户所期待的系统.需要理解:系统架构图,流程图;熟悉:组织机构划分,流程步骤,流程之间关联性,接口问题等等.我尝试着做好准备,等待测试主管的考核.
        也许我做的不是很合理,但是我会尽力去做好每件事.我没有经过专门培训,很多流程上,专业学识上都是存在问题的,希望我能通过这个项目慢慢成长起来.

Open Toolbar