我是个开发人员,也是个测试人员。我的梦想就在我的空间!

我的最新日志

  • 自动化测试+英语学习3

    2008-6-19

    "We need the new software application sooner than that" ."I need those new product features now."Sound familiar?

    客户提出"我们需要我们现在的应用程序上有像那样的一些功能吗?"

  • 学会思考,学会做人,学会做事!

    2008-6-19

        思考、做人、做事这三个词看起来没什么关系,可细细品味让人“回味悠长”!

        进了新公司,很偶然的遇到公司的总裁,很偶然的一个机会听总裁讲设计思路,很偶然的知道总裁不懂软件!

        大家都应该知道,国内很多软件企业的老总不是程序员出生,而我偏偏在一个不是软件公司的公司接受了一堂生动的需求分析课!

        主持会议的是我们的总裁,他从市场的角度分析软件如何才能有“灵魂”。他的思维和反应速度让我震惊,他所说的每句话都让我佩服。一个没有读过《软件工程》的人,竟然能说出那些我们没有注意的细节。是什么让他有如此的学识。思考了一下觉得的把三个词组合一下。

        思考,在做一件事的时候,请思考这件事是否值得你去做,对你以后的发展有何影响。我们拿黑盒测试做个例子吧。“公司让甲测试A功能,甲拿到代码后直接测试花了两天时间测出10个问题;公司让乙测试A功能,乙拿到代码后分析了一天,测试了一天,发现10个问题”,请问在这样的情况下,你会选择谁做你公司的测试?答案显而易见,是乙。那为什么会是乙呢?甲乙花了相同的时间查除了同样数量的问题,这就存在一个思考价值的问题。

        我们是测试(tester),而非工具,我们跟工具不同的是我们有思想,如何让测试用例有“灵魂”,需要我们花费时间去思考,去验证,去修改!这正是我们做事的态度,也就是做“人”。

        “人”这个字看起来简单,很佩服我们的祖先,一撇一那使之平衡,使之稳定。所以说做人不容易呀,稍微不留意,就能摔跤。而做事态度反应出人的本质。

        做事又跟思考分不开,回到我举的那个例子,如果之做事不思考是否能做“好”事呢?

        最近总是在考虑一个问题如何做好测试,测试的范围太广,如何来做好呢?请大家注意三个词“思考”、“做人”、“做事”。

  • 自动化测试+英语学习2

    2008-6-05

    Automated testing amounts to a development effort involving strategy and goal planning,test requirement definition,analysis,design,development,execution,and evaluation activites.

    自动化测试从测试计划、测试测试需求分析、设计测试、测试进度测试执行速度、测试评估、有效测试这几个方面得到体现。

  • 自动化测试+英语学习1

    2008-6-04

    Chapter1

    The Birth and Evolution of Automated Testing.自动化测试起源与发展。

    An effective test program,incorporating the automation of software testing,involves a mini-development life cycle of its own.小型的开发周期内,必须进行自动化测试。

  • 原创 小论——软件缺陷

    2008-5-12

        什么是软件缺陷?理论的解释如下:

    1. 软件未达到产品说明书中标明的功能。
    2. 软件出现了产品说明书中指明不会出现的错误。
    3. 软件功能超出了产品说明书指明的范围。
    4. 软件未达到说明书虽未指出但应达到的目标
    5. 软件测试人员认为软件难以理解、不易使用、运行速度慢,或最终用户认为不好使用。

        现在针对国内企业的某些情况来谈论一下,不正确之处希望大家多多提宝贵意见。

        软件未达到产品说明书中标明的功能
        这点无可厚非,产品说明书的功能都没能达到,这样的软件在用户的验收就不会过。可偏巧有某些公司说,我就要这几个功能,其他的你们给我去掉。公司偷笑:“白痴的钱真好赚。”
        大家想想,现在程序的设计思路是什?好多公司选用配置信息,软件所有的功能都能进行配置,需要什么样的功能给配什么样的功能。这样的思路很先进,软件开发实现的时候算法如何来写,确保软件的效率高呢?需求说明书应该怎么来设计,系统构架如何来设计?造成的弊端是不断的改需求分析,改程序,让程序越来越烂。就是俗语“出力不讨好~”!

       软件出现了产品说明书中指明不会出现的错误
       系统需求说明书在几天内完成,凭借开发经理根据以前老项目的经验写出来需求分析模板,再根据用户的要求东拼西凑出来需求分析说明书,测试凭借这样的需求分析说明书,能写出什么样的测试用例?能设计好测试用例吗?再加上测试思考的范围太狭隘,目的就是为了找出BUG,而设计的测试用例,这样的用例有何价值?

        软件功能超出了产品说明书指明的范围
        在很多人认为这是不可能产生的。但在实际开发中为了避重就轻,很容易产生某些说明书中并没指明的某些功能,这些辅助功能的目的是为了更好的完成系统主要功能,但是大家有没有想过,用户购买一个产品的目的是什么?答案是简化工作量。一个软件不能为用户减轻工作,请问谁还会来购买这个软件呢?

        软件未达到说明书虽未指出但应达到的目标
        这块可能说的是软件的可扩展性吧,一个软件的如果没有考虑到扩展性,设计思路肯定有问题。
        (总是觉得跟上一条冲突)不太敢评论!

        软件测试人员认为软件难以理解、不易使用、运行速度慢或最终用户认为不好使用。
        这点把测试人员的定位定太高了吧,测试人员认为软件难以理解?难道开发会根据测试的一句话:“我感觉软件不好理解、不好用”来重新设计需求分析了,重新设计代码了吗?
        运行速度慢,这更不好说了,“测试环境跟真实换进不一样,速度慢是正常的”,开发一句话就能打发了。试问有多少公司舍得花钱模拟真实环境?
        用户认为不好使用,对通用软件来说这是致命问题,不好使用就意味着别人不会购买这个产品。而对行业软件来说,不好使用,只要跟某些领导沟通好让上级强行下发购买任务,不好使用这是问题吗?

        以上只是个人观点,在国内开发、测试有太多太多无奈。

        研究标明64%的BUG出自需求说明书,由谁来设计需求说明书呢?值得讨论!

        国内有几个合格的系统构架师?

    PS:如需转载请联系本人。

     

  • 闲聊公司离职经过

    2008-5-05

    生活就像强奸,
    要么反抗要么就去享受;
    工作就像轮奸,
    你不行就让别人上;
    社会就像自慰,
    所有的事都要靠自己的双手解决!
    ——用这样的开头,多少有一些不雅,却觉得很贴切!

        4月23日下午我的测试经理突然把我叫到会议室说:“公司产品线缩减了,测试人员嫌多,更具公司职称评定,你……”,我惊讶的看着我们经理,问她那性能测试这块就不做了吗?

        性能测试公司2月开始的,我被老大从功能测试上调到性能测试上,既然公司把我调到性能测试上,公司性能测试之前是空白,那我就应该好好测试了。花了一个多月来学习性能测试,根据需求分析,跟老大商量性能测试培训事宜等等。三月中旬完成《预算执行系统》性能测试用例的编写,涉及的部分包含大数据量测试,并发测试,压力测试,网络测试。测试用例提交给我老大,老大很满意。

        4月开始搭建测试环境,本机安装服务端,客户端后,系统CPU满符合运转,跟项目经理沟通要单独的服务端,经过几次协商后在。领到了一台PC机做我的服务端。配置是P4(2.4),内存1G。

        把服务端和数据库移植到公司分配的机器上,程序跑起来就有错,无法做数据进去。一直到公司跟我提出离职的时候程序还没能跑起来。

        今天跟一个同事聊天的时候他说我测试方向跟别的测试不一样,不愿意同流合污,性格有点特立独行。

        思考了同事的话,也对,虽然公司非要把黑说成白我有什么办法呢?我只能用自己的行动表明,一个月的交接时间为什么不给公司一份漂亮的性能测试报告呢?我能,我一定行!不违背自己工作的原则。把自己的应该做的事情做完,走也要走的漂亮!

        在以后的工作中,坚持自己的原则,黑就是黑白就是白,工作上坚决不同流合污,性格稍微改一下,不要再特立独行了。

     

  • 性能测试基础知识

    2008-3-20

        狭义的性能测试主要用于描述常规的性呢测试,是指通过模拟产生运行的业务压力或者用户使用场景来测试系统的性能是否满足生产性能的要求。

        广义的性能测试则是压力测试、负载测试、强度测试、并发(用户)测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。

     

    预期性能测试用例

        在系统需求设计阶段预先提出的、期望系统达到的,或者向用户保证的性能指标。针对每个指标都要编写一个或多个测试用例来验证系统是否达到要求,如果达不到目标,则需根据测试结果来改进系统的性能。

     

    用户并发性能测试用例

        用户并发性能测试要求选择具有代表性的、关键的业务来设计测试用例,以便更有效的评测系统性能。

     

    疲劳强度与大数据量测试

        大数据量测试主要是针对那些对数据库有特殊要求的系统而进行的测试。(实时大数据量测试、极限状态下的测试、前面两种的结合)

     

    网络性呢功能测试

        基于硬件的测试:主要通过各种专用软件工具、仪器等来测试整个系统的网络运行环境,一般由专门的系统集成人员来负责。

        基于应用系统得测试:在实际的软件项目中,主要测试用户数目与网络带宽的关系。通过测试工具准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间。

     

    服务器性能测试

        高级服务器性能测试:主要指在特定的硬件条件下,由数据库、WEB服务器、操作系统相应领域的专家进行性能测试。

        初级服务器性能测试:主要指在业务系统工作或进行前面其他种类性能测试的时候,监控服务器的一些些计数器信息。通过这些计数器对服务器进行综合性能分析,找出系统瓶颈,为调优或提高性能提供依据。

  • 一年的测试菜鸟,写下测试心得。

    2007-9-29

    不知不觉中度过一年的测试生活,在此写下心得体会共同交流。
        1、做任何事情都的有计划,测试也不例外,给自己定个测试计划。
            第1阶段进行什么测试,预计花费多长时间进行测试。
            第2阶段进行什么测试……
            如果测试经理已经安排好了如何测试,那请估一下手头的工作量进行一下细化。
        2、有了测试计划还的写测试用例。测试用例包括功能测试用例和场景测试用例。
            别说测试用例没有用,测试用例在测试的时候能帮助整理测试思路。
            测试进行中,可以对写的不完整的测试用例进行补充。
        3、跟开发沟通掌握软件的需求资料。
            为什么要做这个软件
            各模块的功能
            模块之间的前置、后置条件是什么
        4、手工测试完成后,有时间可能可以进行自动化测试。
        5、别吝啬自己的经验,好东西需要分享,在不断的交流中会发现自己的不足。
        6、BUG描述要详细,记录BUG的过程也是自身成长的过程。BUG描述不仅自己能看懂,别人也需要能看懂,造成BUG产生的约束条件同样要描述清楚,方便重现问题。
        7、别忘记学习,“三人行必有我师”这句话是真理。
        8、定期反思这段时间是否进步了,有则加冕,无则反思。

    欢迎大家把心得写下来~~~~~~~~~~
  • 性能测试与瓶颈分析工具

    2007-9-10

     
    v负载压力测试工具,
      例如LoadRunnerQALoad
    v系统后台资源监控工具,
      例如ServerVantagePerformance Insight
    v网络应用监控,
      例如NetworkVantageSniffer
    v网络应用故障定位,
      例如ApplicationVantage

     

  • 功能测试模板

    2007-9-04

    东拼西凑,凑出来的一个测试用例模版,希望对自己的工作有所帮助.


    用例编号 :
    对应需求编号:  
    用例摘要:  
    版本号:   测试类型:   对应UI:  
    测试优先级:   设计日期:   对应UC:  
    测试方法:   测试日期:   用例设计者:  
    测试目的:          
       
     
    前置条件:  
    执行步骤(列出选用的输入项,覆盖正常、异常情况):          
       
       
       
       
       
       
     
    预期结果(逐条与执行步骤对应,列出预期输出):          
       
       
     
    测试结果:  
    结论:  
Open Toolbar