日历

« 2008-10-13  
   1234
567891011
12131415161718
19202122232425
262728293031 

我的好友

统计信息

  • 访问量: 2003
  • 日志数: 21
  • 建立时间: 2007-04-30
  • 更新时间: 2008-09-19

RSS订阅

生命有限,测试无限!

我的最新日志

  • 默然回首,原来自己像只蜗牛

    2008-9-19

    一转眼10年的,工作9年了,现在回首看看自己,就像一只蜗牛一样,进步没多少

    大学的同学好多都已破茧成蝴蝶了,一片光明

    最近看看网上的一些招聘信息,虽然年限是够,但技术方面的信心都是缺缺的

    特别是外语,没有进步,反而是退步,现在我不知道怎么办?

    在网上看到一则这样的信息,说是做3年测试的,一般都是测试经理了,天啊,我都干5年了,现在也不过是个leader,这难道就是传说中的差距?我不知道,我迷茫了

    总结,自己在第一家公司呆在太久了(6年),浪费了自己大好的青春时光,这都怪自己,不思进取!

    这就是苦果,只能自己吃了

    真希望时间可以回去,我一定不会这么活了

     

  • 测试用例图形化

    2008-4-30

    现在很多的测试用例都是在规定的模板上堆着以后也不太会有人看的文字,一本接一本的,看得人云里雾里,还是没有搞清楚到底是要测的什么,也没有搞清楚要测的系统到底是要干什么。

    个人比较喜欢图形,在上个东家里做的系统都是跟图形打交道,认为图形其实是个很直接的东西。因为我的抽象思维很差,形象思维很好,很多东西要画出来,我一般都能知道是什么(印象派除外),而且人又很懒,不喜欢看全是字的东西。做了这么多年的测试工作,说起写测试用例,其实最多也就是1-2K行吧,不多,就是因为我不喜欢写,而且在写的过程中我也不知道我会写到哪里去,只能是写一些对付了事的,但总是能安全的没有被发现过关,也许也归功能我的测试执行其他跟我的用例并不是一样的,我的执行一定是比我所写的测试用例要多得多的。

    测试用例的图形化,在我认为其实也没有什么,就是在堆文字前,使用一些工具(现在在这方面开源的小工具很多)可以做出一些必要的图形,就像在做需求时,要做的需求分析一样,我们测试也可以没有必要一上来就抽出模板,不停的在上面写着自己也没有搞清楚的文字。

    那为什么不能直接就用需求分析时做出来的图呢(一般在需求时会做出一些用例图等),这些图太简单,只是一个大致的轮廓,如果按这图去做测试用例的话,真的写不出真正在后期执行中有用的用例,其实就目前我所做的项目中文字化测试用例的问题有这些:

    1、文字化测试用例是乏味的,因为全是文字,就象如果是看小说的话,一个人也一天也看不了两本书,更何况是没有情节的文字测试用例

    2、文字化测试用例是孤立的,虽然有文字说明他的接口,但并不直观,难以表现过程

    3、文字化测试用例是烦多的,一个小功能,就能写上成千上万行的用例,而且当需要修改时,那就更惨了,不是全推掉,就是让你找个半天然后改个一点

    4、文字化测试用例无法让不同的人统一理解的,当一个人写完一个测试用例,一段时间后,由其他的人接手做时,理解原来的测试用例不但花一定的时间,而且会对同一功能产生不一样的理解

    其实想想在做码case前,为什么我们不加入先把要写的测试用例图形化呢!现在很多人都在使用一种做脑图的工具(freemind),开源的,不错!可以把它应用到在测试用例前,先把整个系统在你脑子里的构造描绘出来,形成一个脑图(也可以叫做是一个系统的流图或是功能图等等),然后把这张图中的各个结点再去讨论,细化出更小的结点,再确认,最后在最小的结点中加入必要的描述注释,在关键的结点中做出标记,可以认为是重点测试,在描述注释中可写出相应的简化的测试用例,这样在测试团队中全体成图也就知道这个系统的功能以及关键是什么了!

    接下来做一些文字化的测试用例,对于一些特别重要的的结点可以做文字化的测试用例,以保证在测试覆盖达到最大。

    现在这种做图的工具很多,因为我用得多的是freemind,昨天刚看到一个叫keystone的,还没有用,不知道怎么样!但思想是一样的!

    先想到这么多了!

  • 最近无事,想研究一下性能测试工具!

    2008-4-15

    项目被无期限的推迟了,所以我被先release出来!这是我第一次在没有做完一个项目时就被弄出来了,有点生气!但也没有办法。

    出来后,就没有接到新的任务了,其实没有活干也挺难过的,天天无所事事的,上班也不知道要干嘛,但又不能让我们在家里睡大觉!痛苦

    所以想想用这段时间也研究一下测试工具,最主要的是性能测试工具中得出的性能结果的分析,因为一个工具的使用应该是很容易的,不容易的是他的结果的分析。

    公司里用的是LR,可是我的机器 不争气,上不了,一上就重启了,内存不够,只能去网上找个轻量级了,而且还要是开源的,找到了很多,选了一个:WebLoad,据说还不错

    先来说说这个WebLoad吧(以下的信息均来自网络)

    webload是radview公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能,用户创建的是基于javascrīpt的测试脚本,称为议程agenda,用它来模拟客户的行力,通过执行该脚本来衡量web应用程序在真实环境下的性能

  • 新的项目做到一半,需求得要更改

    2008-3-25

    完成第二个项目,又接到第三个项目了,这个项目不大,不过还是给多配了一个QA(本来就我一个QA),希望我能带带她,有点觉得受宠若惊了,没有带过毕业生,这是第一次偿试着。

    我想我应该会把我的一些对测试方面的理解告诉她的,但不知道她能理解多少!

    回头说说这个项目吧,不大,刚开始听说是只要1个多月就可以OK的,昨天又收到通知,说客户要更改需求了,可能更改会有很大,影响也不会小,唉,这段时间coding暂停了,testing完成现有的工作后,也要暂停,等着最新的需求下来,听DM说可能还会涉及到要重新评估呢,又搞大了!

    现在也只有等了!

    也好,这段时间可以空出来,让我学学关于性能测试的知识,不错,拿现在手头上这个项目做例子,使用webload来测试一下,公司里是用LR的,我想那个东西太大了, 还是搞个轻量型的,先进行学习一下!

    就写到这了。

    回上去看,有点胡言乱语了!

     

  • 新公司的第二个项目完成,总结一下!

    2008-2-26

    从第一个项目出来还没休息几天,就被直接拉到另一个项目中去做测试了,虽然只是做个小测试,没有做leader,但现在回想起来,还是很辛苦,原因主要有2个,1我从第一个项目里出来,还没有好好的休整好,就投入到另一个项目的工作中去了,(人年纪大了,精力体力都跟不上了);2就是我进项目前对项目的评估出现错误,以为项目的工作量不大,没有关系,但事实却是项目的计划被一再的提前,导致QA不断的加班,完成任务,很累!

    但不管怎么说,总算是熬过来了,总算是做完了,我可以退出来了,虽然这样,但不能说没有什么好总结的,还是有很多东西我学到了(当初就是因为我不想再做leader,我想看看别的leader是怎么带项目的,我可以多学习一些知识,我的目的达到了):

    1、带新人:在开始工作前就应该规范好他们应该要做什么,怎么做,要求出什么,这样新人在工作起来效率很很高,但不能让他们整天做,得定时给一些问题让他们去解决,并定时跟踪;

    2、要规范:不管开发做得怎么样,QA都应该做好自己的事情,QA就是为了提高质量而产生的,在全程中不仅是对系统的bugs提意见,对项目的流程如果发现不好的地方,也应该提出来,并且对问题的解决方案提出自己的建议,这样有助于项目越来越规范,努力让自己参与到项目的管理过程中去,为将来成为一名高级管理人员打下基础(我的目标是这样的,但如果是立志成为技术高手的人,我想应该多向测试的方法、技术方面考虑吧)

    3、快乐的工作:这是这个项目的PM常说的一句话,我个人认为是很有真理的,虽然在这个项目里,我并不怎么算happy的工作啦,但总的来说,还可以,不会让我太屈气(QA总会遇到这种情况),因为项目经常加班,而且是在年前的时候,天气又不好,我真的不喜欢加班,但我不是leader,只能这样,我发现在加班的时候我找bug的效率很低,我上午的工作效率是最好的,我能发现很多bug,因为我认为如果项目要加班,这个项目就已经不算是一个做的好项目了,好的项目是不加班(虽然这是理想想法,不能实现的),因为一个在经过一天8小时的工作后,还让加班,从人体注意力来说,已经没有那么集中了,如果这样的,还加班,那不是在浪费生命吗?而且效率不高(夜猫子除外了,我不做夜猫子很久了)

    4、技术上:学了一点oracle的知识(大侠们不要笑我),我一直都是用SQL SERVER的,好多oracle的东西我是一窍不通的,这次让我见识了,我也长了点知识,值了点!

    5、写文档:用户手册要简洁,把系统中如何实现业务的过程写清楚就行了,没有说明要写成什么样!

    目前就只有这些,但总体觉得做这个项目有点不值,没有得到什么!希望以后自己不要再犯这种错误了,在接项目前是得好好把项目评估一下了(这方面我得下多点功夫了!)

  • 07年关键词

    2007-12-29

    今天早上听广播里在进行年终总结,说是对07年关键词进行总结:

    我也来说说我对于07年的一个关键词的总结:

    金猪年OR土猪年,

    股票狂涨,

    关闭煤矿,

    油价涨,

    排队加柴油,

    猪肉价涨,

    黄金周调整,

    带薪年假,

    17大全国代表大会,

    升息,

    房价涨,

    动车组,

    医改药改,

    we are ready,

    F1红色法拉利队又得第一,

    。。。。。。

    现在只记得这么多了!

  • 关于探索性测试

    2007-12-12

    前几天与同事在MSN上聊天时,不知不觉地就聊到了关于探索性测试,这个名词我不熟悉,只能现从网络上google一下啦(有网络就是好,但老是中毒就不好啦),具体解释如下:

    摘抄51testing:

    探索性软件测试是一种强大和有趣的测试方法。在某些情况下,它比剧本化的测试更高效。其实,每个测试员都在不知不觉地在用到探索性测试方法,但是很少有人学习和重视这种方法。现在是时候认识一下探索性测试方法了:科学的实时的思考。

     
    Concurrent Test Design and Execution
    同时设计测试和执行测试
            对探索性测试的最直白的定义是:同时设计测试和执行测试。这与剧本化的测试方法相反(预先定义好测试步骤)。探索性测试不像剧本化的测试,不会预先定义,不会严格按照计划开展。然而,即使是精确定义的测试步骤也会有很多有趣的细节遗留给测试员(例如:在键盘上敲击的速度、怎样的行为才认为是错误);即使是方式非常自由的探索性测试也会对测试产品的哪些部分作出规定,或规定采用什么测试策略。
     
            好的探索性测试者会把测试的想法写下来,并应用在后来的测试循环中。这些记录下来的东西看起来有点像测试脚本。
     
            探索性测试有时候会与即兴测试(ad hoc testing)混淆。即兴测试通常是指临时准备的、即席的bug搜索的测试过程。从定义可以看出,谁都可以做即兴测试。由Cem Kaner提出的探索性测试,相比即兴测试是一种精致的、有思想的过程。
     
    Balancing Exploratory Testing With scrīpted Testing
    平衡探索性测试与剧本化测试
            如果做到了下一项测试被我们所做的上一测试的结果所影响,那么我们就是在做探索性测试。当我们在测试循环之前不知道应该运行什么测试时,或者我们还没机会创建测试,我们应该更多地探索。
     
            如果我们正在执行剧本化的测试的时候,新的信息提示我们可以有更好的测试策略,我们应该转成探索模式(例如发现了新的错误需要进行调查)。
     
            相反地,当我们非常清楚我们要做什么测试以及怎样做时,我们应该采取剧本化的测试方法。新的测试相对没那么重要,执行测试的效率和可靠性的需要使得测试值得剧本化,值得我们把它们文档化并维护。
     
            探索性的测试结果与剧本化的测试并没有根本性的区别,两种测试方式是完全兼容的。像Nortel和微软这样的公司通常在项目中两种方法都使用。
     
    Why Do Exploratory Testing?
    为什么要做探索性测试?
            在有效的探索性测试循环管理中的重复主题是:测试、测试策略、测试报告和测试任务。测试剧本化的方式企图将测试过程机械化,从测试设计者的脑袋中把测试的思想抽取出来并放到纸面上。这种测试方法的好处很多。
     
            但是探索性测试者持这样的观点:把测试剧本化地写下来并按照它们来测试会破坏快速寻找重要问题这一智力的过程。这一智力的过程越丰富、越流畅,我们越有机会在正确的时间执行正确的测试。这就是探索性测试的威力所在:测试过程的丰富性只是受限于我们的思维的广度和深度,还有我们对测试产品的洞察能力。
     
            剧本化的测试是有它存在的意义的,我可以想象测试的效率和可重复性是那么的重要,所以我们应该剧本化或自动化测试。在测试环境间歇有效的情况下,例如C/S结构的项目,只有几个配置的服务器有效并且要在测试和开发之间共享。这种情形下我们应该把测试小心仔细地提前剧本化,以便能充分利用有限的测试执行时间。
     
            探索性测试在复杂的测试情况下会特别有用,对产品了解甚少的情况下会特别有用,或者作为准备剧本化测试的一部分测试。基本规则是:应该在你准备进行的下一次测试内容并不明确的情况下进行探索性测试,或者你希望把这些不明确的因素明确了。
     
        看了以上的解释,我能理解的就是一句话:先使用,再边测试边写用例
        我并不知道这样是不是最好的方案,但在实际工作中,我却是主要使用的方法,但我对这种方法也是一种无奈的选择,知道从软件工程上来说,应该先有设计才能去实施,但理论永远是赶不上实际的变化,理论永远只是理论,在考试中也许很有用处,但实际工作中还是得找出真正适合于自己的方法。
        其实对于测试去搞什么探索性方法论,个人认为不如好好去想想如果保证项目的过程,这样来得更有价值,测试中是项目过程中的一个部分,无论测试专业人员去发现如何如何多的可以提高测试的方法,但如果这个项目的赛程本来就有很大的漏洞,那测试再好出来的东西也没有价值,就是所谓的“皮之不存,毛之焉覆”。
        不过话说回来,对于测试人员来说,考虑到这一点是应该的,但是为什么不能再把要考虑的东西提高一点呢!项目过程可能都只认为是那几个部分,无非是需求,设计,开发,测试,运行!虽然现在有很多项目过程都把测试提前了,保证尽早尽快的测试,但在实际中真正实施的却不多,原因也许都很心知肚明的,需求的不断变化,客户的要求不明确等等,难道这是无法解决的癌症吗?我想应该不是吧?我不知道。
        写到这里,我也不太明白自己到底要干什么了,一方面我在实施着探索性测试,另一方面我的心里却很排斥这种方法,真不懂自己要的是什么,但是我有一点很清楚,那就是测试只能是对项目过程中的一个环节,项目做得好不好,得要靠过程中所有环节的共同进步。
  • 测试用例在实际工作中真正的作用有多大(黑盒功能测试)?

    2007-11-14

    这几天,项目进入到了尾声了,但是就像是文章或是电影一样,一般高潮也都会在快结束的时候,所以,我们的项目在这段时间也进入到了最忙也最迷茫的阶段

    忙的是项目也结束了,但是可测的包却不能按时的提交,可是总体时间却没有变化,搞得我们测试人员急得在热锅上的蚂蚁一样

    迷茫就是这个项目完成了,不知道下一个项目将是怎么样了,每个人都有自己的想法,可是这种想法可以得到实现吗,似乎现在看来,在这个项目中没有学到什么东西,迷茫了,其实这并不是我这篇文章想要说的事情。

    时间很紧张了,可是客户却在这个时候告诉我们要加入新的测试阶段,因为我们的第三方不再帮我们做这个阶段了,搞死了,用例我都没有安排写过,唉,只有补了,可是用例太多了,好痛苦。

    写一点吧,对付一下了,说实话,我一直认为,测试用例对于我来说只是一种辅助记忆的,因为认为能在用例上写出来的,一般是不会发现缺陷的,发现缺陷的部分一般都是在用例以外的,因为在项目的设计过程中,开发人员与测试人员开会沟通,大家都知道在注意什么,要做什么,并且开发人员也不傻,测试人员也不笨,所以来说,测试用例上写全的东西,开发人员在提交可测试版本前均已把他们给处理掉了。对于一些不在用例里的,却是缺陷表中的主力军,因为软件这东西本来就不是实在的,他是虚拟的,谁也不知道这东西会有什么不一样的毛病出来,这个东西只能放在多实践的过程中才能真正现示出他的真面目,这对于开发来说是不可能的,而对于测试来说却是正中下怀的,不是吗?有人说,那就把用例给不停的补充进去,这就得说到现阶段的中国实情了,现在中国的项目能给你那多么的时间让你来加用例吗?本来在中国测试就没有开发来得受重视,这是不争的事实。还能让你有时间去补,再者即便优秀的测试人员真的认真地把用例补上去了,会有几个管理人员真正地看看这个用例,我想大家都很忙的。

    其实说到底,测试用例在大多的项目中最多只能说是一种形式罢了,特别是那些写满密密麻麻的文字信息的用例(个人私心,我是个不喜看大段文字的人),对于我来说,那只是增加我的烦恼,我认为在测试的过程中,应该针对不同的阶段的去设计不同的用例形式,没有必要非得用所谓的文字表达,比如用图,用树等表示就可以了,在软件测试过程中各种测试方法什么覆盖什么路径的,这些不是可以用图先做出来的吗,都已经有图了,为什么还得多此一举地去把图转成文字,其实对于外行的客户他们如果要来看我们的测试用例的话,图,树等也是很适合的。

    现在发现网上很多测试的模板,个人认为部分内容不适合我,因为用模板写出来的测试用例对于我来说,作用不大!

     

  • 开始自己试着写一些外语的短句

    2007-10-11

    l'll try to write english sentence -----one

    I shall lose my weight

    One day I suddently find that my body is fatter than ever.I think I shall lose my weight.
    I shall do many sports such as swimming,riding,running.... I know that it is not easy,but for my beauty and health,I must to insist on.
    I shall eat fewer food on the supper.I will eat an apple and a acid milk on my supper because I read up the literature from net and I find many people do it for losing their weight .
    I don't stay up all night for my computer's game. I shall go to the bed on time and wake up to temper with my friends.
     
    These is my arrangements to lose my weight.
     
     
    (也不知道我写的对不对,希望各位帮助我改正!)
     
  • 英语短文:我们这个时代的尴尬(转抄)

    2007-10-11

    1]We have bigger houses and smaller families; more conveniences, but less time; we have more degrees, but less common sense; more knowledge, but less judgement; more experts, but more problems; more medicine, but less wellness.

     

    [2] We spend too recklessly, laugh too little, drive too fast, get to angry too quickly, stay up too late, get up too tired, read too little, watch TV too often, and pray too seldom.

     

    [3] We have multiplied our possessions, but reduced our values. We talk too much, love too little and lie too often. We've learned how to make a living, but not a life; we've added years to life, not life to years.

     

    [4] We have taller buildings, but shorter tempers; wider freeways, but narrower viewpoints. We spend more, but have less; we buy more, but enjoy it less.

     

    [5] We've been all the way to the moon and back, but have trouble crossing the street to meet the new neighbor. We've conquered outer space, but not inner space. We've split the atom, but not our prejudice; we write more, but learn less; plan more, but accomplish less. 

    [6] We've learned to rush, but not to wait; we have higher incomes, but lower morals. We build more computers to hold more information, to produce more copies, but have less communication. We are long on quantity, but short on quality.

     

    [7] These are the times of fast foods and slow digestion; tall men and short character; steep profits and shallow relationships. More leisure and less fun; more kinds of food, but less nutrition; two incomes, but more divorce; fancier houses, but broken homes.

     


    [1]我们居住的房屋越来越宽敞,家庭却越来越小型化;可以享受的生活便利日益增多,属于自己的时间却日趋减少;我们获得了一张又一张学位证书,却愈加频繁地陷入对常识的茫然中;我们广泛地涉猎各类知识,却越来越缺乏对于外界事物的准确把握和判断;专家越来越多,问题却也日渐增加;药物越吃越多,健康却每况愈下。

    [2]我们花钱太疯,笑容太少,开车太快,发怒太急,熬夜太晚,起身太累,文章读得太少,电视看得太勤,祷告做得太少。

     

    [3]我们不断聚敛物质财富,却逐渐丢失了自我价值。我们的话语太多,真爱太少,谎言泛滥。我们掌握了谋生手段,却不懂得生活真谛;我们让年华付诸流水,却不曾将生命倾注其中。

     

    [4]我们的住房越来越好,脾气却越来越糟;我们行驶的道路越来越宽阔,眼光却越来越狭隘。我们付出很多,可获得的很少;我们购买了很多,可从中得到的乐趣却很少。

     

    [5]我们能够往返于地球与月球之间,却不乐于穿过马路向新邻居问好。我们可以征服外部空间,却慑于走进内心世界。我们可以击碎原子,却不能突破思想偏见;我们写得很多,可学到的很少;计划很多,可完成的很少。

     

    [6]我们学会了追赶时间,却没学会耐心等待;我们拥有的财富越来越多,道德品质却日益沦丧。我们生产更多的电脑用于存储更多的信息和制造更多的拷贝,而相互间的交流与沟通却越来越少。我们拥有的是数量,缺乏的是质量。

    [7]这是一个快餐食品和消化迟缓相伴的时代;一个体格高大和性格病态并存的时代;一个追名逐利和人情冷漠相生的时代。我们的休闲多了,乐趣却少了;食品种类多了,营养却少了;双薪家庭增加了,离婚率也激升了;居室的装修华丽了,家庭却残缺破碎了。

     


     

Open Toolbar