这个冰清的学习天地,以后我会把自己觉得重要的学习资料和大家一起分享。

发布新日志

  • 一些英语鼓励句子

    2011-11-21 11:35:26

    一、Don’t worry.别担心。(劝告对方别担忧)
      a.—Is my illness serious?我的病严重吗?
      —Don’t worry. You’ll be well soon.别担心,你很快就会好的。
      b.—Can I pass the exam?我能通过这次考试吗?
      —Don’t worry. I think you can.别担心,我认为你能通过。


      二、Don’t be afraid.别担心。(劝告对方别担心)
      a.—Will he agree to see me?他会同意见我吗?
      —Don’t be afraid.别担心。
      b.—Will the exam be very difficult?考试会很难吗?
      —Don’t be afraid.别担心。


      三、It’ll be OK/all right.行,没问题。(使对方放心)
      a.—Will my plan work?我的计划会起作用吗?
      —It’ll be OK/all right.没问题。
      b.—Will the meeting succeed?会议会成功吗?
      —It’ll be OK/all right.没问题。


      四、It’s all right.没问题。(请对方宽心)
      a.—Will you help me with my English?你会帮助我学英语吗?
      —It’s all right.没问题。
      b.—Will the car pass the test?汽车能通过检验吗?
      —It’s all right.没问题。


      五、Well done!干得不错!(肯定、鼓励对方工作)
      a.—What do you think of my article?你认为我的文章怎么样?
      —Well done.写得不错。
      b.—Is my work OK?我的工作还行吗?
      —Well done.干得不错。


      六、You can do it!你肯定行!(肯定对方能力)
      a.—I’m afraid I can’t pass the exam.恐怕这次考试我过不了关。
      —You can do it!你肯定行!
      b.—I wonder whether I can finish the task in time.我不知道是否能及时完成这项任务。
      —You can do it!你肯定行!


      七、Come on!别灰心。(劝告对方别灰心)
      a.—I’m afraid I can’t succeed.恐怕我难以成功。
      —Come on!别灰心。
      b.—I’ll not learn English any longer. I can’t remember all these words.我不想学英语了,我记不住这么多单词。
      —Come on!别灰心。


      八、That’s better. Keep trying.有长进,继续努力。(肯定对方的进步)
      a.—What do you think of my homework?你认为我的家庭作业做得怎么样?
      —That’s better. Keep trying.有长进,继续努力。
      b.—Is my composition still bad?我的作文还是不好吗?
      —That’s better. Keep trying.有长进,继续努力。

       九、cheer up (振作起来)

       Cheer up! Things are not so bad as they seem. 振作起来!情况并不象看上去那样糟

       Cheer up! I'm sure you'll feel better tomorrow. 振作起来!我肯定你明天会好些的

       十、take it easy (别着急,慢慢来--当别人在处理某种事情有困难的时候,提醒别人要放松)

       I'm afraid I can't finish my homework in time. ---Take it easy.You can do it.

  • 当好测试组长之测试计划的制定

    2009-12-30 15:14:20

    每个软件都要进行测试,每个软件公司也都会进行测试,但通常,测试都被当作最简单、最没有技术含量的工作,搞技术的人不愿意做,全都交给一群新人。其实测试是软件质量的最后一道关卡,没有测试,软件的质量很难保证。

      测试的过程可以分为计划、分析、设计、实现、执行、报告这几个阶段。诚然,执行测试的确不需要多少技术,新人经过一两天培训就能上手。但是,计划、分析、设计、实现、报告等过程,没有几年的软件工作经验,是不可能完成的。下面先来说说测试计划。

      测试的目的、定义和范围

      制定测试计划时,首先必须明确的是测试的目的、定义和范围。

      一般来说,测试的目的有三种:

      * 防止发生bug

      * 找出bug

      * 保证软件质量

      找bug的测试用例和保证质量的测试用例是完全不同的。比如,回归测试的目的是防止发生bug,每次产品发布都应该执行,所以应尽量让测试用例能自动执行,减少测试执行的工作量;而为了找出bug,就要尽可能全面地考虑各种特殊值、错误处理、安全问题等;而保证软件质量的测试,则应当模拟完整的业务流程。

      至于定义,也许你会觉得,“地球人都知道,有写的必要吗?”你可以去问问你的组员,单元测试、综合测试和系统测试是什么意思,可能十个人会给出十个答案。在流程完善的大公司里还好些,小公司里这种现象会很严重。所以有必要把大家对测试的认识统一起来。

      范围也是必须明确的因素。测试整个系统,还是特定的模块?在什么硬件、什么操作系统上测试?这些也都必须事先明确。

      测试的读者对象

      接下来还要明确,测试计划是给谁看的?可能你会认为是给测试者看的,那么该计划是否需要给客户看?是否其他项目干系人如上司、公司决策者会关心该计划?测试计划应该根据读者对象,写出读者最想知道的内容。

      测试的环境

      接下来就是测试环境了。这恐怕是最复杂的因素了:

      * 操作系统是XP,Vista,还是Win7?

      * Linux的话,是RHEL4,5还是CentOS?要不要支持Debian、SuSE等?

      * 浏览器是IE、Firefox还是Opera?IE的话需要测试什么版本?

      * 数据库MySQLOracle还是SQLServer?

      * 硬件配置有什么要求?

      * 网络环境有什么特殊要求(如IP地址、网络拓扑结构、带宽等)?

      * 服务器和客户端各需要架设几台?它们之间如何连接?

      * 安装时使用的序列号是什么?

      稍有经验的人就会知道,各种测试环境的组合会让测试数量成倍增长。比如测试网站,操作系统XP + Vista + Win7,浏览器 IE6 + IE7 + IE8 + Firefox,组合起来就是3 x 4 = 12种环境,原本500项测试用例就会膨胀到6000条。这显然是不现实的。因此要找出最有效的组合方式,避免测试用例爆炸。

      比如这个例子中,我们知道Vista下没有IE6,Win7下没有IE6和IE7,这样就能减少3种环境。另外,不同操作系统下,只要浏览器相同,表现形式也几乎相同,所以不用测试所有组合情况,只需测试 XP + IE6、Vista + IE7、Win7 + IE8、Vista + Firefox四种环境即可。另外,这些都是客户端的测试,假如500个用例中有200项是服务器端的测试,那么这200项只需在一个环境中测试即可。这样最后的测试数量是 300 x 4 + 200 = 1400,比最初的6000项要少了许多。

  • 负载、性能测试和容量测试的关系和区别

    2009-06-11 10:28:08

    .强度测试或压力测试

    强度或压力测试是在一种需要异常数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶颈。异常情况,主要指那些峰值、极限值、大量数据的长时间处理等,包括:


    • 连接或模拟了最大(实际或实际允许)数量的客户机;
    • 所有客户机在长时间内执行相同的、性能可能最不稳定的重要业务功能;
    • 已达到最大的数据库大小,而且同时执行多个查询或报表事务
    • 当中断的正常频率为每秒一至两个时,运行每秒产生十个中断的测试用例;
    • 运行可能导致虚存操作系统崩溃或大量数据对磁盘进行存取操作的测试用例等。

    压力测试可以分为稳定性测试和破坏性测试

    • 稳定性压力测试。在选定的压力值下,持续运行24小时以上的测试。通过压力测试,可以考察各项性能指标是否在指定范围内,有无内存泄漏、有无功能性故障等。
    • 破坏性压力测试。在压力稳定性测试中可能会出现一些问题,如系统性能明显降低,但很难暴露出其真实的原因。通过破坏性不断加压的手段,往往能快速造成系统的崩溃或让问题明显的暴露出来。

    在压力测试中,会给程序加上一些跟踪机制(如log、日志等),然后查看监视系统、服务器等性能的日志文件是必要的,找出问题出现的关键时间或检查测试运行参数,通过分析问题或参数从而有目的地调整测试策略或测试环境,使压力测试结果真实地反映出软件的性能。

     

    2.性能测试

    系统的性能指标,一般赢在产品需求文档中有明确定义,有三种形式描述软件系统的性能指标:


    • 给出产品性能的主要指标,如在100000记录中查询一个特定数据的时间为0.5秒。
    • 以某个已发布的版本为基线,如比上一个版本的性能提高30-50%。
    • 和竞争对手的同类产品比较。

    性能测试,根据其目的分为:


    • 产品性能质量测试,通过测试,决定产品是否达到产品规格书所要求的性能指标(非功能性需求)
    • 基准值测试,通过对当前产品的性能测试,确定产品具体的性能指标,建立性能指标基准。基准值,作为后继产品发布的性能参考(在新版本中,性能指标要求只升不降)或和竞争对手产品比较的参考。
    • 性能规划测试,通过不断的测试,确定所需要的硬件配置(内存、CPU、网络等)、软件配置,以满足实现定义的性能指标要求。这种测试,对于软件系统的部署是非常有意义的。同时,也可以进一步了解硬件参数、软件参数对系统性能的影响程度,从而保证系统具有很好的扩充性或事先制定较好的系统增容的计划。


    性能测试的方法,主要有:


    • 稳定压力加载,一次性将负载加到某个水平,持续一段时间,也称为flat测试。
    • 逐渐加载或交替加载到某个负载水平,也称为“ramp-up”测试。
    • 峰谷测试,确定从系统高峰时间的负载转为几乎空闲、再攀升到高负载这样峰值交替情况下的系统性能状态/指标。这种测试兼有容量测试的特点或属于容量测试的一部分。

    性能测试,一般都通过测试工具来模拟人为的操作而进行。性能测试的重点在于测试环境的建立、前期数据的设计与后期数据的分析。因为性能测试需要获得一定特定条件下(如100、200、500、1000个实时的连接)的系统占用资源(CPU、内存等)数据或系统行为表现,而且还要依靠测试工具或软件系统记录下这些指标变化的数据结果。例如,如果对一个Browser/Server结构的网络实时在线的培训系统软件进行测试,系统性能焦点是在不同数量的并发连接下,服务器的CPU、内存的占用率、客户端的响应时间等,如表1所示。

    表1 HTTP连接性能表

    HTTP

    1?

    1?0

    1?00

    1?00

    1?00

    1?00

    1?00

    1?00

    1?00

    ……

    10?

    60?

    CPU (%)

    1.2

    2.5

    4.5

    11

    20

    20

    28

    23

    25

    … 

    4

    24

    物理内存(M)

    55

    45

    38

    38

    32

    48

    75

    46

    37

    … 

    178

    232

    虚拟内存(M)

    836

    841

    831

    855

    865

    858

    867

    874

    884

    … 

    871

    1,472

    加入时间(s)

    12.04

    12.14

    11.6

    15.48

    126.1

    104.76

    168.1

    123.7

    218.11

    … 

    12.01

    9.17

    建会时间(s)

    12.01

    11.35

    12.38

    13.32

    13.63

    14.06

    16.35

    14.98

    17.68

    … 

    10.9

    11.39

    延时(s)

    …….

    断开时间(s)

    8.58

    9.11

    7.94

    9.09

    8.26

    8.35

    8.46

    11.41

    11.1

    … 

    8.79

    8.22

     

    测试过程中,并发连接的不断增加(负载的增加)在系统性能上的表现越来越明显。在系统性能测试时,加载过程中,每到一个测试点时须让系统平稳运行一段时间后再获取数据,以消除不同测试点的相互影响。从表中可以看出,同样是300个用户,1?00与60?的性能表现差别很大,加载的方式对系统性能影响也较大,所以,尽量模拟不同的加载方式来进行系统的性能测试。除此之外,还可以测试TCP、HTTPS等不同连接方式下的数据,进行比较。通过比较和分析,可以清楚知道系统的性能状况,以及什么样的条件下系统性能达到最佳状况、什么地方是性能的瓶颈。性能测试要求测试环境应尽量与产品运行环境保持一致,应单独运行,尽量避免与其他软件同时使用。

     

    3容量测试

    通过性能测试,如果找到了系统的极限或苛刻的环境中系统的性能表现,在一定的程度上,我们完成了负载测试和容量测试。容量可以看作系统性能指标中一个特定环境下的一个特定性能指标,即设定的界限或极限值。

    容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。对软件容量的测试,能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力,如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量,如果不能满足设计要求,就应该寻求新的技术解决方案,以提高系统的容量。有了对软件负载的准确预测,不仅能对软件系统在实际使用中的性能状况充满信心,同时也可以帮助用户经济地规划应用系统,优化系统的部署。

     

    3.压力测试、容量测试和性能测试的关系

    压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段,不是直接的测试目标。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。而容量测试和性能测试是系统测试的主要目标内容,也就是确定软件产品或系统的非功能性方面的质量特征,包括具体的特征值。容量测试和性能测试更着力于提供性能与容量方面的数据,为软件系统部署、维护、质量改进服务,并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。

    压力测试、容量测试、性能测试,测试的方法相似、相通,在实际测试工作中,往往结合起来进行,以提高测试效率。一般会设置专门的性能测试实验室,完成这些工作。即使用虚拟的手段模拟实际操作,所需要的客户端有时还是很大的,所以性能测试实验室的投资较大。

  • 测试如何更有效说服研发去修改bug?(转)

    2009-05-21 16:04:46

    题描述:测试过程中一些bug会被研发认为是无效bug,但从用户角度出发,测试认为该bug需要更改,此时测试如何更有效的说服研发去修改bug?

    精彩回答:

      1. 扭转研发领导的思想,提高研发人员的响应速度:

      a). 让研发团队的领导重视缺陷:

      很多研发团队的领导都是销售出生,懂技术的很少,他们和搞技术的想法明显不一样。我在的第一家公司,发布版本时很多时候,都是没有测试结束,功能开发的差不多就把产品卖掉了,后面再对版本不断升级,结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是做质量管理出生的,明显对测试的质量要求就不一样,每次要求都特严,对以前测试结束标准都做了进一步的修改。如果领导对缺陷都视而不见,你说研发人员还愿意花大量的力气去修改Bug吗?所以说,团队的领导的想法或意识,对缺陷是否修改起到非常重要的作用。我记得以前测试高手zhuzx也在每周一问中提到过,大家也可以借鉴一下。

      b). 采用常用的缺陷管理工具(QC9.0),提高缺陷的透明度:

      我们公司使用缺陷管理工具(QC9.0),测试经理任管理员,给公司高层领导、项目经理、开发经理都分配了权限,自己可以登录系统查询相关信息。在测试后期,特别是要发布版本前后,领导们一有空,也随时上去浏览一把,无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷,开发人员自然不敢怠慢。

      c). 把开发人员的修改缺陷的响应速度,记入绩效考核内容:

      由于公司总监特别关注产品质量,我们公司对缺陷修改这一点做得比较好,每次都是递交缺陷以后,开发人员响应特别快。如果有疑问,就马上和测试人员一对一交流,尽快修复或解决该缺陷。我们公司的口号是:“宁愿花出100倍的代价,也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候,我们测试人员要给开发人员打分,很重要的一点就是:开发人员对测试缺陷的响应速度,如果这一项很低的话,老大要找你谈话的,问具体原因是什么?呵呵。所以,我们公司很少有测试人员追着开发修改缺陷的情况,把修改缺陷的响应速度纳入个人绩效考核,我个人觉的是一种比较好的方式,值得借鉴或推广。

      2. 组建一个合理的研发团队,规范测试规范:

      a). 关键是建立一个完善的研发机制:

      在大多数情况下,是不是软件缺陷或者需不需要修改,怎样修改不是测试人员和开发人员说了算的,应该是靠研发部门的相关制度或相关部门去约束。毕竟在国内软件的软件企业缺少这样的部门,所以说把修改缺陷相关的重任推到了测试人员的头上,其实对测试人员实在是太不公平了。要解决这个问题,最关键就是建立一个完善的研发机制,让QA等相关部门督促解决这类问题,比较好。

      b). 分清团队成员的具体责任:

      对于研发团队中的每个成员,必须责任明确,否则像督促缺陷修改这样的事情本来不是测试人员的责任,现在都推到测试人员头上了。很郁闷!!

      c). 完善测试规范,明确Bug管理制度:

      大部分的公司,都没有单独的部门来单独管理督促缺陷是否修改,都默认为是测试部门的事情。个人觉的最好是赋予项目组中相关人员一定的资质,让他们去处理这些琐事。经常碰到这样的情况,很多争议的缺陷都一直放到后面一个版本,一段时间下来,几个版本争议的缺陷就多于100个,弄得后面版本也不好发布。我们的做法是,发布前几天,对每个争议的缺陷用邮件先发给项目组成员先看,后面在召开缺陷评审会议,如果通过,毫无疑问修改,否则关闭或保留到下一个版本。

    本文出自51Testing软件测试网,感谢会员sun_0910在每周一问(08-10-27)中的精彩回答。
    http://bbs.51testing.com/forum-157-1.html

      3. 从源头上杜绝无效缺陷的递交:

      a). 测试前细化测试需求,避免递交歧义缺陷:

      很多研发不愿意修改的缺陷,大部分都是由于需求不明确或者理解歧义引起的。所以,最好的做法是在测试以前,开个项目会议,细化一下测试需求,让研发去确认或项目组成员集体Review,达成一致观点。尽量减少理解上的歧义,力争尽早消除无效或争议的软件缺陷,避免递交的缺陷成争议的缺陷。测试人员无法说服研发,让研发去修复缺陷,长期这样,测试部的威信就大大降低了。

      b). 把握不准的缺陷,递交以前最好讨论一下:

      特别是在测试初期,由于测试介入项目时间较短,有时候测试人员对业务或需求了解不深,递交错Bug也是常有的事情。这个时候,往往测试认为自己递交正确了,开发人员认为自己开发软件是对的,互不相让,如果处理不好,很容易弄僵关系,弄得大家都不是很愉快。要是项目中出现这样的Bug,是很难说服研发去修改的,还有可能成为研发抓你的“小辫子”的有力证据,要是这样以后就更难做了。个人的一些做法:所有的测试缺陷相互审核后,才递交到缺陷系统上公开,是最为保险的方法。

      c). 清楚无歧义的描述Bug,减少随机测试,带来不可重现的Bug:

      很多时候,测试人员把缺陷描述不清楚或者缺陷有歧义,开发人员看不懂,不明白具体的意思,加上开发人员任务重时间紧,很容易产生逆反心里,这就让开发人员对测试人员有看法,以后递交的缺陷认可度就大大降低了。还有就是要减少随机测试,一定要保证递交的缺陷能够重复出现,最好要有截图、图片或者用数码相机照下来,让开发人员认识到这个问题确实存在,并且更具说服力。

      d). 做好版本配置管理工作,保证测试环境的准确性:

      很多同事发现的缺陷,只有在测试环境下重现,而在开发环境下不能够重现。这样的缺陷开发人员往往是看不到的,他们很容易得出结论,说测试人员递交无效的缺陷而被拒绝,大部分情况发现是版本弄错啦!!我们唯一能做的就是做好源代码的配置管理工作,保证测试环境版本的正确性和独立性,自己编译自己部署测试环境。只有这样,才会减少无效缺陷的递交,避免“费劲周折”说服开发人员修改缺陷。

      4. 正确分析测试中的软件缺陷:

      a). 为递交的每个缺陷准备几条充足的理由:

      一般情况下,我们提到一个Bug时,开发人员都会说出很多可以不修改缺陷的理由,尽量搪塞住我们的口,要求我们关掉缺陷或者置为无效或者延期到下一个版本。如果你很牛,你可以为自己递交的每个缺陷准备很充足的理由去说服开发人员;如果你不是太强,那就可以求助部门同事,集中测试部门团队的力量,想一些好的、站得住脚理由,详细介绍给研发人员听,只要我们递交的Bug,每个都具说服力的话,我想他们也会尽快修改的。这种方法还真是不错,大家不妨试一试。

      b). 详细分析缺陷给项目带来的各种可能影响或缺陷风险:

      比如说,我们递交一个缺陷,如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性,不修改,对客户带来哪种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信,当我们对缺陷分析的很详细时,研发人员一定会修改Bug的。

      5. 做一个聪明的测试工程师:

      a). 注意和研发人员的沟通技巧:

      如果测试人员没有做过开发工作,理解也许就比较片面。有的测试人员,对待问题没有耐心,性情比较急,也是常有的事。如果没有较好的沟通技巧,也许就是几句话的功夫,就和同事争吵了起来,弄得大家都比较尴尬。个人建议:谈话时,要注意沟通技巧,要有换位思维的方式,做事情对事不对人,处理事情一定要有一颗宽容的心。只有这样,才能够很好的说服研发去修改Bug。

      b). 和研发人员搞好私人关系,做研发的听众:

      比较明智的测试人员,一定要学会倾听研发人员的心生。很多时候,开发人员碰到工作困难的时候,很希望和人倾述,如果测试人员是他的听众,那么你们的关系一定会不错。搞好了私人关系,工作中你递交的缺陷,他们就不会那么斤斤计较了,毕竟关系是基础,关系好了好说话呀,在中国就是如此。如果私人关系好了,说服研发修改Bug就是很容易的事情。不过得提醒一句:不能因为关系好就把Open的缺陷给关了。

      6. 抓住时机,不要错过千载难逢的好机会:

      a). 求助公司上层领导:

      很多时候,测试到后期,开发人员把缺陷也修改的差不多了,公司领导(比如说老总、总监、项目经理或开发经理)就会随时来测试部门,找测试经理或负责人了解项目测试的具体情况。如果有一些问题都是争议问题,作为测试Leader的你不妨给领导聊聊,把更高层的人拉进来为测试部门说话,为测试部门撑腰,但是凡事都有一个度,不能太过分,否则很伤同事的和气。

      b). 要求客户代表援助:

      很多GUI的缺陷或可改可不该的缺陷,可能作为客户使用不是很方便。我们可以和客户代表聊聊这样的缺陷,如果客户代表同意这样做,那没问题,可以不修改;如果客户不同意,他自然会直接找项目经理或高层人员协调解决这个问题,这就不用我们测试人员操心了。因为客户就是上帝,这招不错吧!!!

      我目前想到的就这么多,希望同行指正!!!


  • 优秀的测试工程师应该具备的三项素质

    2009-01-04 13:56:06

    一个好的测试工程师应该具备怎样的素质?也许这是我们每一个测试工程师都非常关心和敏感的问题,测试这个行业在短短的几年里在我们的国家得到了快速的发展。他入门的门槛相对较低,企业(特别是软件型企业)人才缺口大,因此选择测试行业的人越来越多。但真正能在测试这个行业做出巨大成就的人却并不多。

      那么,怎样成为一个好的测试工程师呢?本人有以下几点看法:

      首先,必须有一颗执着的心。测试在一定程度上是一个相对枯燥的行业,太多的重复,太多的繁琐,甚至还有一些委屈(当自己的工作成绩不被开发人员或者项目经理认可的时候)。在这样的时候,我们很多的测试工程师会选择放弃或者消极对待所,但要想成为一个出色的测试工程师,这是我们必经的路,必须执着走下去!就好比一个拿到世界冠军的长跑运动员,在他小时候会经历无数次的摔倒,然后再爬起来;在他训练时会面对教练无尽的责骂,只能悄悄的擦干泪水重新再来。他之所以成功就因为他的执着。

      其次,一个好的测试工程师还必须具备灵敏的洞察能力和学习能力。当然我这里讲的洞察力和学习能力不仅仅指精通多少测试工具、能找到多少bug;我讲的是一种对自我升华的能力。当我们还是一个测试执行工程师的时候可曾想过什么时候成为一个测试设计工程师、测试项目经理、测试主管、乃至测试架构师;这种升华纵使需要我们点滴的积累,但更需要我们对自己刻意的培养,培养自己的技能,培养自己的全局观,培养自己的沟通能力和领导能力。

      最后,我觉得一个好的测试工程师必须要有自己明确的人生规划。没有目标的人生容易迷茫!我曾经在一家测试公司待过15天,这家公司的老总在一次谈话中告诉我:我们公司的定位是一家小公司,我们不会做大;后来我离开了,因为在那里我看不到激情、看到的是得过且过。看不到公司的未来、自己的未来,因为大家仿佛都没有想过。就像小时写作文一样:人生就像一条航行在大海中的船,如果没有了导航,我们只会被汹涌的波涛埋没。

  • 如何正确对待需求的变更

    2008-12-31 16:03:26

    1、对于需求和需求变更的理解

      软件需求是整个软件项目的最关键的一个输入,和传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性的特点,它不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题,同时又是关系项目成败的关键因素,因此对于需求分析和需求变更的处理十分重要。

      软件需求变更会给项目带来巨大的风险,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果,因而需求变更在软件开发项目中应该尽量避免。然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更,而这些因素往往不可避免。在软件开发过程中如果只有一条真理的话,那一定是:需求的变化是永恒的,需求不可能是完备的。因而,对于需求变更应该正确的对待,尽量将其负面影响降低到最低。

      2、减少需求变更

      正如前文所说,需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更,可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作,项目开发人员对于需求变更的正确态度应该和软件测试的态度一样,在需求并更发生之前尽量减少需求变更,以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更,这样做往往费力不讨好。

      相比于需求开发人员而言,客户可能对需求变更认识不足,认为他们出钱,程序员或软件开发公司就要为它服务,因此客户对需求变更往往将需求变更视为儿戏,随个人喜好随意变更需求。因此,在需求人员同用户代表或用户部门主管人员接触时,就应该向他们挑明态度,和他们协商好,特别是应该让他们清楚软件的定价应该与软件的功能相关,以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做,让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路,而不是等到程序员开始编码了,才提出以前原本在需求分析时就可以提出的需求。

      让客户明白减少需求变更的重要性后,需求分析人员应该采取合适的方法同客户交流,帮助他们明确他们的需求。需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者,他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和客户存在着服务商和顾客的关系,但是他们有着一个共同的目标:开发出适合客户需求的软件,因此需求分析人员除了记录客户提出的需求以外,还应和用户讨论,提出一些建议,使用合适的工具帮助客户提出需求。在需求分析时,尽量多的召集需求研讨会,邀请开发人员和客户共同协商探讨,在研讨会上允许任意的提出需求,并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能,这样能够尽量使得需求完备。在需求开发时,开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。

      虽然需求不可能是完备的,但是在项目开始设计时尽量使得需求完备还是应该的,也是值得的。

      3、规范文档

      需求文档作为客户和开发人员的接口在整个项目开发过程中起着举足轻重的作用。需求文档应该按照一定的格式和规范书写,而且应该具备完整性、一致性、基线控制、历史记录等特性。文档书写完毕以后应该交给客户审阅,在客户满意的基础上确定基线。一个完整规范的需求文档不仅能够有助于设计人员和编码人员完成项目开发,更重要的是它作为一个阶段性的成果可以供软件需求变更时参考。

      需求变更发生后,也应该生成相应的文档,并且这些文档的书写也应该采用规范的形式书写。需求变更文档也应该包含基线以供下一次修改参考,还应包含历史记录以供开发人员和客户清楚当前的文档内容的新旧以及历史文档的情况,以备以后查看。

      开发软件就如同建造一座房屋,软件体系结构则如同建房屋时的规划。两层高的家庭住宅和几十层高的商业大厦建造时的规划必然不同,同样,大型软件和小软件采用的体系结构也必然有所区别。因此,设计一个合理的体系结构对于项目的成败也是十分关键的。

      体系结构的建立一般位于需求分析结束之后,软件设计之前。软件体系结构的设计是从结构的角度对整个系统进行分析,选择合适的构件,安排构件间的相互作用以及他们之间的约束,形成一个系统框架以满足用户需求。在设计软件体系结构时,不仅应该想到如何完成满足现在已经提出的用户需求,同时也应适当地考虑到需求的变更。

      采用有弹性和可扩展的软件体系结构设计可以有效地降低需求变更引起的风险和维护代价,能够在项目范围未发生变化的前提下很好地适应需求的变化。体系结构的灵活和可扩展性设计使得开发者可以在这种体系结构上面进行各个功能层的组合和分离,也可以将各个功能层分布在各个不同的服务器上共同提供服务,因而能够快速的对需求变更作出响应,并且对已经开发好的系统产生尽可能少的影响。

      体系结构的设计除了考虑到体系结构的灵活性和可扩展性以外,还应尽量采用松散耦合的结构,使得结构中的各个构件之间的关联程度尽可能的少,这样就能在需求发生变更时一个构件的变化对另一个构件产生尽可能少的影响。

      现有的软件体系结构很多,包括管道-过滤器结构、B/S结构(含C/S结构)、解释器/虚拟机结构、黑板系统以及基于中间件技术的体系结构。在设计体系结构时,首先应该选出适合项目需求的系统结构,然后在从中挑选出那些扩展性比较好,构件之间耦合性比较小的体系结构。基于中间件技术的体系结构就是扩展性比较好的体系结构。采用中间件技术,中间件作为用户界面和操作系统以及网络的连接点,向上为用户提供服务,向下屏蔽操作系统和网络的细节。这种分层的思想能够很好的适应操作系统和网络的变化,可扩展性十分的好。同时,可以在中间件中给出容易改变的接口或是为系统将来改变预留接口来实现功能上的需求变更。当然可扩展性比较好的体系结构远不止基于中间件技术的体系结构这一种,具体的选择和运用应该由设计人员根据实际需要考虑。

      5、采用面向对象思想

      需求是不稳定的,因而没有不变的需求,然而需求之中却有稳定的东西,这就是对象。世界都是由对象组成的,而对象都是持久的,例如动物、植物已经有相当长的时间。虽然对象也在变化,动物、植物也在不断的进化。但对象在一个相当长的时期内都存在,动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象,以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多,因为企业的模式一旦变化,只需要将稳定的企业对象重新组织就行了。

      面向对象(OO)技术的三大特征保证了采用OO技术可以建立易于改变和加强可重用性的软件系统。封装可以把问题影响的范围缩小,外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中,从而改变系统的一部分相对简单;继承可以使改变基于原有技术基础,很大程度上减少重复开发工作;多态的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节,从而改变系统的行为。

      显然,OO技术是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法,可以在一定程度上快速对需求变更进行反应,并可相对减少需求变更需要的成本。因此,在系统开发过程中应该尽量的采用面向对象的思维方式来构建系统和开发系统。

      6、需求变更控制

      正如前文所言,需求变更不可避免的会发生,那么当需求变更发生后项目开发人员应该如何应对呢?

      一般来讲,需求的变更通常意味着需求的增加,需求的减少相对很少,而且处理也比较容易。当客户提出新需求的时候,项目开发人员应该分析这些新需求对项目现阶段带来的风险,得出双方实现变更需求的需要的成本,包括时间、人力、资源等等方面,再与客户商讨是否有必要进行变更和如何在最小代价下实现变更。

      当客户确实希望进行需求变更时,可以让开发人员开发一个快速原型,让用户体验一下,以确保客户确确实实的希望添加这些需求。在客户和项目开发人员共同确定了需求变更后,项目开发人员应该与客户签订一份新的合同。

      当客户提出需求变更并且签订了合同后或是开发人员根据市场和国家政策作出的需求变更得到确证后,项目开发人员应该决定何时实施这些变更。对于那些对系统影响不大和一些优先权十分高的需求变更可以立即在项目中实施,而对于那些对于整个系统现阶段的开发影响很大,而且又不是十分紧急的需求可以放在下一个版本中进行。无论是立即实施还是放在下一个版本中,都应该给新的需求一个充足的开发和测试时间,保证产品质量。

      结论

      在面对需求变更时,除了通过减少需求变更和规范文档,从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外,还应该改变我们设计的意识和对需求变更的理解,做好对需求变更的控制和管理,做到对需求变更的灵活应对,在一定程度上降低维护代价和提高用户满意度。 

  • 高并发测试下的一些问题及解决方式

    2008-12-31 16:01:21

    测试在sqlserver2000上进行,对工作流操作的相关方法在单元测试里进行多线程并发。测试发现sqlserver出现死锁的情况相当多,一些典型的情况:
    1、对同一张表先insert再update是很快会引起死锁的,不管操作的是否是同一记录

            解决方法:对于同一记录,需要调整hibernate的映射策略,使得一次insert完成操作。对于不同的记录需要在代码中手动flush,使得update先于insert。

    2、对两张表进行多次update操作时,两张表交替update也会很快引起死锁

            解决方法:在代码中手动flush,保证对两张表的update不会出现交替的情况。

    3、部分大范围扫描的select和update混合也会导致死锁

            解决方法:优化sql,尽量减少sql语句,通过给po增加持久化字段的方式减少关联查询

            经过优化,大部分情况下数据库死锁的情况得以避免,另外奇怪的是通过事件探查器在死锁时并未发现锁升级的事件。但是在一些特殊情况下(例如多个并发汇聚的直接联合),死锁依旧发生。最后不得不对方法进行synchronized关键字同步,这个通过synchronized flush完成。业务方法不必同步,最后批量操作数据库时进行同步。

            换oracle进行测试,在未synchronized的情况下,未发生死锁情况。由此可见sqlserver与oracle锁实现机制存在很大的差别。另,同事说,sqlserver2005后性能和机制发生了很大的变化,未测试。
     补充一下我的一个最简单情况下的测试用例: PO:

     

    view plaincopy to clipboardprint?
    public class TestPO {  
     
        String id;  
     
        String name;  
     
        int num;  
     
         
     
        ....  
     

    public class TestPO {

        String id;

        String name;

        int num;

      

        ....

    }映射文件 hibernate3: view plaincopy to clipboardprint?
    <hibernate-mapping default-access="field"> 
     
      <class table="WFMS_TESTPO" name="com.eway.workflow.test.po.TestPO"> 
     
     
     
        <id name="id" column="ID"><generator class="uuid" /></id> 
     
     
     
        <property name="name" column="NAME" type="string"/> 
     
     
     
        <property name="num" column="NUM" type="integer"/> 
     
     
     
      </class> 
     
    </hibernate-mapping> 

    <hibernate-mapping default-access="field">

      <class table="WFMS_TESTPO" name="com.eway.workflow.test.po.TestPO">

     

        <id name="id" column="ID"><generator class="uuid" /></id>

     

        <property name="name" column="NAME" type="string"/>

     

        <property name="num" column="NUM" type="integer"/>

     

      </class>

    </hibernate-mapping>被测试方法(都配置有事务): view plaincopy to clipboardprint?
    public void testSave(int num) {  
     
        TestPO po = new TestPO();  
     
        po.setName("ronghao");  
     
        po.setNum(num);  
     
        theadTestDao.save(po);  
     
        po.setName("haorong");  
     
    }  
     
     
     
    public void testSaveByJdbc(int num) {  
     
        String sql = "insert into WFMS_TESTPO (ID,NAME,NUM) values (?,'RONGHAO',?)";  
     
        Object[] params = new Object[]{num,num};  
     
        jdbcTemplate.update(sql, params);  
     
        sql="update WFMS_TESTPO set name='haorong' where id=?"  ;  
     
        params = new Object[]{num};  
     
        jdbcTemplate.update(sql, params);  
     

        public void testSave(int num) {

            TestPO po = new TestPO();

            po.setName("ronghao");

            po.setNum(num);

            theadTestDao.save(po);

            po.setName("haorong");

        }

     

        public void testSaveByJdbc(int num) {

            String sql = "insert into WFMS_TESTPO (ID,NAME,NUM) values (?,'RONGHAO',?)";

            Object[] params = new Object[]{num,num};

            jdbcTemplate.update(sql, params);

            sql="update WFMS_TESTPO set name='haorong' where id=?"  ;

            params = new Object[]{num};

            jdbcTemplate.update(sql, params);

        }测试用例: view plaincopy to clipboardprint?
         public void testSave() throws Exception {  
     
            TheadtestTemplate template = new TheadtestTemplate();  
     
            template.execute(new TheadtestCallback() {  
     
                public void doInThead(int suquence) {  
     
    //               theadTestManager.testSave(suquence);  
     
                    theadTestManager.testSaveByJdbc(suquence);  
     
                }  
     
            }, 10);  
     
        } 

         public void testSave() throws Exception {

            TheadtestTemplate template = new TheadtestTemplate();

            template.execute(new TheadtestCallback() {

                public void doInThead(int suquence) {

    //               theadTestManager.testSave(suquence);

                    theadTestManager.testSaveByJdbc(suquence);

                }

            }, 10);

        }

      测试结果:不论是hibernate还是jdbc,并发情况下都很快就会引起sqlserver2000的死锁,换用两种数据库驱动jtds和jturbo死锁的情况没有变化。 结论:sqlserver2000数据库的lock配置策略,不支持,或者数据库本身,就不支持对不同的行做同时操作(或者支持不完善),所谓的行锁支持很不完善,死锁情况非常容易发生。 补充:我对数据库的一些实现机制也并不是很了解,所以这里也只能列出现象而不能解释死锁的根本原因。

  • 软件测试中的性能调优概述

    2008-12-31 16:00:14

     性能调优无疑是个庞大的话题,也是很多项目中非常重要的一环,性能调优的难做是众所周知的,毕竟性能调优涵盖的面实在是太多了,在这篇blog中我们蜻蜓点水般的来看看性能调优这项庞大的工程都有些什么过程,同时也看看这些过程中常见的一些做法。

      确定性能调优的目标

      性能调优,首先是要确定性能调优的目标是什么,如果现在应用已经满足了需求,就没必要去做性能调优了,毕竟不经过一个系统的过程,其实是无法确定你所做的性能调整是否真的调优了性能,是否没有造成应用中其他的问题,所以确定性能目标是非常重要的,在定义性能目标的时候通常这么定义的呢:
      1、最大并发数
      2、Quality of Service
      服务的质量,在软件系统方面我们认为主要表现在请求的出错率,系统的load等。
      3、最长响应时间
      对于任何请求所能承受的最大响应时间。
      4、TPS
      每秒需要支持的最大事务数,最典型的指标是:“某页面最高需要支撑每秒7000次的访问次数”。

      例如一个web系统,需要定义出来的目标是:
      并发目标:最高支撑200并发;
      QoS:出错率须控制在万分之一,系统的load最高只能到达10;
      TPS:每秒完成7000次请求的处理;
      最大响应时间:最长允许的响应时间为5秒。
      至于请求的平均响应时间这些就不在性能调优目标中定义,因为要达到TPS的要求,响应时间是必须要达到一个级别的,而且响应时间随着高并发是会出现劣化的。
      当然,还可以把性能指标定到更为细节,例如某个方法的TPS在100并发时需要达到多少。
      在确定好了性能目标后,重要的就是如何来测量系统的性能了。

      测量系统性能

      对于新系统而言,需要评估出其正式运行时的数据量的增长情况;而对于已运行的系统,则需要根据监控获取到系统的运行数据(例如高峰并发数、系统的响应速度情况、系统的load、网络流量、每类请求在总的请求中所占的百分比等)。
      [NextPage]对于新系统而言,要评估出具体的性能相对来说稍微好做一点,因为此时系统通常较为单纯,数据量的增长也不可能是一夜之间增长的,因此基本可以按照一种正常的方法在测试环境评估出其正式运行的性能。
      而对于已运行的系统而言,则较为麻烦,因为通常来讲要在测试环境中模拟正式运行环境基本是不太可能的,因此这个时候通常要采取一些模拟的方法或更高压力的方法来尽量更为准确的评估出系统的性能。

      在测试系统性能时,通常可采用的方法有:
      1、单元测试;
      可借助单元测试来测试某个请求的性能;
      2、压力测试;
      压力测试无疑是测量系统性能中最常采用的方式,根据定义的性能目标对系统进行压力测试,以确定系统是否满足性能要求,同时也可以根据压力测试的结果来分析系统的瓶颈,进而进行对应的调优,可用于做压力测试的工具还是不少的,像loadrunner、jmeter等等,不过压力测试这个话题实在太大了,不在这里展开去讲了,不过我也不怎么懂就是,呵呵。

    分析系统性能瓶颈

      根据测量系统性能的结果,多数是可以分析出系统性能的瓶颈,同时还可以结合像jvm堆栈、jprofiler、系统日志等来进行进一步的确定,另外也可以根据性能调优人员的经验,例如可以去了解开发人员是否采用了不适合的数据结构等。
    简单说一个线程分析的例子:
      借助kill -3 pid来获取到目前jvm的线程堆栈信息,特别需要关注的是里面wait for monitor这样的线程,这种线程是指在等待锁的线程,等待一两分钟后再次kill -3 pid,看看这些wait for monitor的线程的变化情况,这对于分析线程中是否存在不合理的竞争过高的锁的分析是非常重要的。
    这一步无疑也是性能调优过程中最难的一步了,分析系统性能瓶颈这种基本只能结合实际例子来讲了,正确在后续抽取一两个例子来进行讲解。

      性能调优

      在分析出系统性能的瓶颈后,其实这一步相对来说还好做些,当然,需要建立在对软硬件知识都有很好的深入了解的基础上,在这里列举一些比较常见的性能调优的手段,多数是抄来或google来的,自己在这方面的经验还不多,希望大家多加指点,:)

      Redhat Linux内核
      Redhat linux内核版本升级到2.6,2.6和2.4的差别还是很多的,例如对epoll的支持、NPTL的采用;epoll的支持对于java而言也是很重要的,在高并发的情况下nio是否采用epoll还是有挺大的差别的;而NPTL的采用对于多线程程序而言更是极为重要。
      另外需要关注像linux的File Handles是多少、network buffer是多少、MTU是多少、Memory Page size是多少等等。
      [NextPage]JVM
      JVM调优的文章相对来说比较多,大家需要了解的主要是-Xms/-Xmx、并行GC、-XX:MaxPermSize/-XX:MaxNewSize、-XX:ThreadStackSize、NIO采用epoll等等。
    简单的列这两个,其实性能调优的手段还有非常的多,例如简单的增加CPU、买更快速度的硬盘、增加内存、提升网络带宽等这些从硬件角度下手的方式,还有像数据库调优、应用服务器调优等等。

      暂时就写这么些了,以后列一些具体的例子来写,那样更为清晰些,这样的话更多的是讲述一下过程,可以大概了解下做性能调优应该去学习的知识点,^_^,也欢迎有经验的同学们贡献出一些实例的分享。

  • 如何写好自动化友好的测试用例

    2008-12-31 15:57:59

    为了提高软件测试的效率,增进测试工作的广度和深度,越来越多的公司开始引入自动化测试。本文通过笔者对测试用例设计和表达上的一些理解,阐述如何写好功能自动化测试友好的用例,供大家参考。

      自动化测试有其自身的特点,按照笔者的经验,自动化在一个项目,乃至一个公司开展的成功与否,并不是仅仅依靠QTP等工具使用者的脚本编写水平的提高就可以掌控的。而因为其他的一些因素,一旦自动化测试失去了它本身的高效、可控的特点的话,那反而是得不偿失,会增加项目的成本。

      自动化测试人员进入项目的时间可能不是最早的,对需求的理解并不是在第一时间就很容易做到的。测试用例作为测试需求的载体、测试执行的依据和工作量的评估,它设计和表达的优劣直接影响到自动化测试开展的前几个阶段,如:需求学习、筛选适合自动化测试的用例以及提取公司级或项目的可重用脚本等方面的工作效率。

      1.步骤和数据的分离:

      好的测试用例,在执行的步骤(Step)的表达上应该是尽可能和数据相分离。举例来讲,有一个ATM机取款的功能,可能有以下几个场景:

      1) 密码正确的登录

      2) 密码错误的登录

      3) 密码输入三次错误,卡被锁定

      4) 取少于余额的款项

      5) 尝试取大于余额的款项

      6) 尝试取等于余额的款项(考虑手续费)

      6) 取款额度大于当次的限制

      7) 取款额度大于当天的限制

      8) 取款次数大于限制次数

      等等

      不管你用什么用例设计的方法论来做指导,作为这个简单的例子,有经验的人都应该能看出,此处的很多步骤是可以重用的,总结下来如下(此处只列出了操作的步骤,略去了系统的交互中的反馈结果):

      1) 插入卡->A:输入密码->B:按“确定”键->重复A-B

      2) A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D

      因此,我们只需要写出两套比较完整的步骤,将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢?

      2. 单独的测试基础数据准备工作

      第一个例子中的输入数据比较简单,但我们同样需要考虑的一个问题是:在测试中究竟我们输入什么样的具体数据呢?什么是”正确的密码“?什么又是”大于余额的款项“呢?

      对于大的应用系统,数据之间的关系和准备过程都会很复杂,甚至也有其他外部系统导入、传输或计算出的数据。一个比较好的做法是,将这些测试数据提前准备好,在每个阶段性测试前导入到系统中。一个比较典型的例子,假设要求你单独去测试几张复杂的财务报表,用其他的模块和外部系统,自己逐一的去创造数据,那会非常耗时耗力。这时,基础数据的准备就显得尤为重要,以此才能保证测试工作是高效的、测试结果是精确的。

     如果有可能,复杂的测试基础数据最好是提前准备好的,类似这里例子中简单的 一个帐号为1234567890,密码为66666的有效银行卡,里面有人民币1000元正,等等。将这些内容预先准备好(可以用自动化工具来准备,或导出已有的数据为一个SQL的脚本),写到你单独的测试数据准备文档中,而不是分散到 所有使用到它的case中才去描述。

     3. 测试用例的前置条件和后置条件

      除了第二点中谈到的数据需要准备外,在测试用例这个Level,必须有一些条件满足,您才能开始执行它。比如准备一个初始设置条件下的IE 浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件,可以考虑不作为特定用例的Step,而是把它提取出来,作为Setup Section或叫Pre-Condition。

      对于后置条件或Post-condition,往往我们用它来做一些处理或恢复,比如在上面的取款例子中,如果我们要用相同的帐号重复测试,在正好取完所有金额,余额为零的情况下,可以通过一些步骤或数据库脚本重置帐号余额。同样,您为某个用例设置浏览器禁用了Cookie,执行完该用例后,是不是也是需要回复到默认设置的状态呢?

      集中的把这些步骤整理成一个相对独立的操作单元,具体用例中只要引用就可以了,这样会便于对用例的理解和在多处复用。

      顺便说一下,对于一些类似软件运行环境的条件,比如安装和配置测试中,需要3种操作系统和3种浏览器的组合等,我们可以把他放在Test Set这个Level上来,不用写多个用例,只是在测试计划和执行的管理系统中作为测试集的一个环境参数,恰当地表达出来就可以。

      4. 常用业务操作(Knowledge Base)

      对于一个大型的应用,比如银行系统,开发和测试工作是长期的,持续的一个过程,这样的系统很适合引入自动化测试。它业务逻辑复杂,测试技术性要求高,往往使用了不同厂商的工具和多种脚本语言(如Shell,Python等),也存在了很多可用的遗留脚本。

      这些完成一些预定业务操作的脚本单元,是可以直接借用的。为了在公司和产品层面,管理好这些可复用的资源,一种好的方式是给它们标上号,如KB_PRJ01_Module02_XXX,集中管理起来,以后的用例中只要调用即可。

      举例来说,在银行业务测试中我们,需要模拟和银联的接口,让测试帐号向外汇款,取得响应信息,并保存结果,这可能是个复杂而底层的处理过程,对一般员工是不需要,也没有权限去深入掌握的。这时,将他们包装成一个个Shell脚本或小工具,做好使用说明和统一建档,在以后的项目测试中,只要调用就可以了。如此,可以大大提高各个有相关接口的模块的自动化测试工作效率。

    根据以往工作中常见的一些问题,对于如何写好测试用例(不仅针对自动化测试),做以下做几点补充:

     

    推荐

    不推荐

    将用例的内容描述清楚,强调怎么操作,验证什么,然后期待的结果是什么。 Copy需求和设计文档中的内容;描述成:什么条件下,逻辑会是怎样。这样对测试用例的阅读和执行人员,不具有可操作性。
    期待的结果要写具体,如:系统反应是什么;结果数字是多少;用户被带到什么页面;显示什么成功信息;后台或数据库中该记录的修改后结果是怎么样的。 描述成:”验证系统返回正确结果“;”页面元素显示跟SPEC一致“;”操作成功“等 比较抽象的说法。
    业务逻辑性较强的应用软件,做到以业务流为主线,来组织用例。 以页面形式组织用例。
    以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式,分层次组织用例;使用用例管理工具。 Word格式的扁平组织结构,不利于管理和阅读。
    用一个属性字段,建立用例和Spec等文档的某个章节间的映射。 无法和需求对应,以后难以计算 用例覆盖率,测试执行覆盖率。
    每个Module、Function、特定业务的一组测试用例,之间做到独立、没有耦合。 用例之间有依赖,无法做到:挑选30%的用例做回归测试。
    在时间和成本允许的情况下,尽量做到:用例粒度为“一种不同的操作,得到不同的结果,就单独写一个用例“。 在用例中的操作步骤中,甚至期待结果中,仍然存在条件分支。
    对于复杂的业务操作过程,如”一次顺序的表单签核过程“和”一次完整的信贷手续“,单独增加一些贯穿整个业务流的大型测试用例。 对于一个长业务操作,只存在比较零散的细节用例。
    将用例分优先等级,便于在回归测试时挑选核心业务或用户操作密集的用例。 用例 没有优先级和重要程度的定义。

  • 微软测试工程师面试题

    2008-10-08 16:34:42

    1. 你如何在pocket pc 上TEST 你的程序. 你考虑了哪些方面.

      2. 如果将你的程序的语言扩展到非英语,例如中文, 你如何测试.

      3. 给你一个COCAN, 你如何测试(解释说就是罐装的可口可乐).

      4. 当你的程序遇到BUG的时候,你选择怎样处理.

      5. 你如何isolation 你程序里的BUG.

      6. 给你一个产品有10个functionality,如果时间紧迫, 只能测其中的5个, 你如何选择.

      其它相关:

      如果别人问我这些题目,我想我会大致这样回答,各位从事软件测试的同志们帮我看看回答的怎么样。

      01. 为什么要在一个团队中开展软件测试工作?

      答:软件测试在整个一个团队中占有非常重要的地位,具体来说就是测试是一个发现软件错误的过程,执行软件测试会以最少的人力和时间,系统的找到软件存在的缺陷和错误,建立起开发人员和使用者对软件的信心。

      02. 您是否了解以往所工作的企业的软件测试过程?如果了解,请试述在这个过程中都有哪些工作要做?分别由哪些不同的角色来完成这些工作?

      答:软件测试部门配合系统分析人员软件需求分析讨论,并根据需求说明书制定《项目测试计划》,编写测试用例,建立测试环境。

      软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试,负责软件问题解决过程跟踪,负责软件开发文档开发工作的规范化及管理开发部门的产品文档,制作用户手册及操作手册,负责产品的上线测试,监督软件开发过程的执行,提高产品质量。

      03. 您是否了解以往所工作的企业的软件开发过程?如果了解,请试述一个完整的开发过程需要完成哪些工作?分别由哪些不同的角色来完成这些工作?(对于软件测试部分,可以简述)

      答:需求人员连同系统分析人员&测试人员开会讨论需求。系统分析人员写出需求分析说明,并连同系统分析人员&测试人员&需求人员开会讨论可行性。系统分析人员写出详细设计说明书,程式人员编码,给出系统流程图。交与测试人员,测试人员给出Bug统计表。

      04. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

      答:从事过write test plan,creation of test case,进行功能测试,性能测试,编写测试工具,文档的管理等,比较擅长与写测试用例和进行功能测试。

      05. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(如功能测试、性能测试……)

      答:有功能测试,性能测试,可靠性测试,安全性测试,负载测试,压力测试,安装/卸载测试,启动/停止测试,兼容性测试,互连测试,文档测试,恢复测试,回归测试,可使用性测试,容量测试。

      功能测试只对软件的功能是否满足用户需求来做测试。性能测试需要和压力和负载测试联合起来。

      06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

      黑盒测试:把测试对象当成一个黑盒子,测试人员完全不考虑逻辑结构和内部特性,只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。

      白盒测试:把测试对象当成一个透明的盒子,允许测试人员利用程序内部逻辑结构及相关信息,设计或选择测试用例,对程式所有逻辑路径进行测试。

      单元测试:白盒测试的一种,对软件设计中的单元模块进行测试。

      集成测试:在单元测试的基础上,对单元模块之间的连接和组装进行测试。

      系统测试:在所有都考虑的情况下,对系统进行测试。

      验收测试:第三方进行的确认软件满足需求的测试。
  • 使用JMeter 完成常用的压力测试

    2008-09-26 14:45:56

     本文介绍了 JMeter 相关的基本概念。并以 JMeter 为例,介绍了使用它来完成最常用的三种类型服务器,即 Web 服务器、数据库服务器和消息中间件,压力测试的方法、步骤以及注意事项。         讲到测试,人们脑海中首先浮现的就是针对软件正确性的测试,即常说的功能测试。但是软件仅仅只是功能正确是不够的。在实际开发中,还有其它的非功能因素也起着决定性的因素,例如软件的响应速度。影响软件响应速度的因素有很多,有些是因为算法不够高效;还有些可能受用户并发数的影响。

                在众多类型的软件测试中,压力测试正是以软件响应速度为测试目标,尤其是针对在较短时间内大量并发用户的访问时,软件的抗压能力。本文以 JMeter 为例,介绍了如何使用它来完成常用的压力测试:Web 测试、数据库测试和 JMS 测试。

        概述

                JMeter 最早是为了测试 Tomcat 的前身 JServ 的执行效率而诞生的。到目前为止,它的最新版本是2.1.1,它的测试能力也不再仅仅只局限于对于Web服务器的测试,而是涵盖了数据库、JMS、Web Service、LDAP等多种对象的测试能力。在最新的 2.1.1 中,它还提供了对于 JUNIT 的测试。

                JMeter 的安装非常简单,从官方网站上下载,解压之后即可使用。运行命令在%JMETER_HOME%/bin 下,对于 windows 用户来说,命令是 jmeter.bat。运行前请检查JMeter 的文档,查看是否具备相关的运行条件。对于最新版(即2.1.1),需要JDK的版本要求是JDK 1.4。

                JMeter 的主要测试组件总结如下:

        1. 测试计划是使用 JMeter 进行测试的起点,它是其它 JMeter 测试元件的容器。

        2. 线程组代表一定数量的并发用户,它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义,它被线程组包含。

        3. 监听器负责收集测试结果,同时也被告知了结果显示的方式。

        4. 逻辑控制器可以自定义JMeter发送请求的行为逻辑,它与Sampler结合使用可以模拟复杂的请求序列。

        5. 断言可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域,即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。

        6. 配置元件维护Sampler需要的配置信息,并根据实际的需要会修改请求的内容。

        7. 前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置,后置处理器则常常用来处理响应的数据。

        8. 定时器负责定义请求之间的延迟间隔。

        JMeter的使用非常的容易,在 ONJava.com 上的文章 Using JMeter 提供了一个非常好的入门。

        常用测试

                压力测试不同于功能测试,软件的正确性并不是它的测试重点。它所看重的是软件的执行效率,尤其是短时间内访问用户数爆炸性增长时软件的响应速度,压力测试往往是在功能测试之后进行的。在实际的开发过程中,软件潜在的效率瓶颈一般都是那些可能有多个用户同时访问的节点。

                就目前 Java EE 的平台下开发的软件来说,这种节点通常可能是:Web 服务器、数据库服务器和 JMS 服务器。它们都是请求主要发生的地点,请求频率较其它的节点要高,而且处于请求序列的关键路径之上。如果它们效率无法提高的话,对于整个软件的效率有致命的影响。而且在这些节点上一般都会发生较大规模的数据交换,有时其中还包含有业务逻辑处理,它们正是在进行压力测试时首先需要考虑的。

        本文以这三种节点为例,介绍如何使用 JMeter 来完成针对于它们的压力测试。

        Web 服务器

                对于大多数的项目来说,并不会自行开发一个Web服务器,因此Web服务器压力测试的对象实际就是--发布到Web服务器中的软件。最简单的Web测试计划只需要三个 JMeter 的测试元件,如下图:
              

            其中:

        在线程组中定义线程数、产生线程发生的时间和测试循环次数。 在http请求中定义服务器、端口、协议和方法、请求路径等。 表格监听器负责收集和显示结果。 这种设置对于包含了安全机制的 web 应用是不够的,典型的 web 应用一般都会:

        1. 有一个登录页,它是整个应用的入口。当用户登录之后,应用会将用户相关的安全信息放到 session 中。

        2. 有一个 filter,它拦截请求,检查每个请求相关的 session 中是否包含有用户安全信息。如果没有,那么请求被重定向到登录页,要求用户提供安全信息。

                在这种配置下应用上面的测试计划,那么除了登录页之外的其它请求都将因为缺少用户安全信息,而使请求实际定位到登录页。如果不加断言,那么在监听器看来所有的请求都是成功。而实际上,这些请求最终都没有到达它们应该去的地方。显然,这种测试结果不是我们所期望的。

        为了成功的测试,至少有2种方法:

        方法一,去掉程序的安全设置,如filter,使得不需要用户安全信息也能访问受限内容; 方法二,不修改程序,使用JMeter提供的"Http URL重写修饰符"或"Http Cookie管理器"。 对于第一种方法,有其局限性:

                需要修改程序配置,如去掉web.xml中关于安全filter的设置。需要维护多个版本的web.xml,如压力测试和功能测试分别各自的web.xml,增加了维护成本,而且有可能会在测试之后忘记将web.xml修改回来。         对于一些需要用户安全信息的页面无能为力,如某些业务审计操作需要用户安全信息来记录。因为缺少这样的信息,注定了测试的失败。如果解决为了这个问题进一步的修改程序,那么因为存在多个版本的程序,那么其维护难度将大大增加。         虽然,第二种方法配置难度增加了,但是它不用修改程序。而且还可将测试计划保存成文件,以便重复使用。因此,选用第二种方法是较为理想的做法。下面以一个简化的例子说明使用方法二的配置步骤。

    1. 例子由以下几个文件组成:

                AuthorizenFilter.java,过滤器负责检验session中是否存在用户信息。如果没有,那么就转向到 login.jsp。它的主要方法 doFilter 内容如下:

        public void doFilter(ServletRequest request,
                          ServletResponse response,
                          FilterChain chain)
                          throws IOException, ServletException {
         HttpServletRequest req = (HttpServletRequest)request;
         HttpServletResponse res = (HttpServletResponse)response;
         HttpSession session= req.getSession();
         User user = (User)session.getAttribute("user");     if(null == user){
             String uri= req.getRequestURI();
             //如果请求页是登录页,不转向
             if( uri.equalsIgnoreCase("/gWeb/login.jsp")){
                 chain.doFilter(request, response);
       } else{
                 res.sendRedirect("/gWeb/login.jsp");
       }  }else{
             chain.doFilter(request, response);
         }
        }

        User.java,用户类负责记录用户的信息。为了简化,这里的登录操作只允许指定用户名和密码。主要内容如下:

        public class User
    {
      private String user;  private String pwd;  public User(String user, String pwd) {
       this.user = user;   this.pwd = pwd;
      }
      public boolean login(){
       return user.equals("foxgem") && pwd.equals("12345678");
      }  public String getUser() {
       return user;  }
      public void setUser(String user) {
       this.user = user;
      }
    }

        Login.jsp 和welcome.jsp。其中 login.jsp 负责生成 User 对象,并调用 User 的login。当 login 返回为 true 时转向到 welcome.jsp。其验证部分的代码:

        <%   if( request.getParameter("Submit") != null) {
        User ur= new User( request.getParameter("user"), request.getParameter("pwd"));
           if( ur.login()){
             session.setAttribute("user", ur);
              response.sendRedirect("/gWeb/welcome.jsp");
           } else{
              session.setAttribute( "LOGIN_ERROR_MSG", "无效的用户,可能原因:用户不存在或被禁用。");
              response.sendRedirect("/gWeb/index.jsp");
              return;
           }
       }
    %>

        web.xml,配置 filter 拦截所有访问 JSP 页面的请求:

        <filter>
         <filter-name>authorizen</filter-name>
         <filter-class>org.foxgem.jmeter.AuthorizenFilter</filter-class> </filter> <filter-mapping>
         <filter-name>authorizen</filter-name>
      <url-pattern>*.jsp</url-pattern> </filter-mapping>

        2. 创建如下结构的Web测试计划:

          

    其中主要测试元件说明如下:

                http请求默认值负责记录请求的默认值,如服务器、协议、端口等。
             第一个http请求,请求login.jsp,并附加验证所需要的参数(user=foxgem,pwd=12345678,Submit=Submit);其包含的响应断言验证url中包含"welcome.jsp",这一点可以从程序中反应。
             第二个http请求,请求是welcome.jsp;其包含的响应断言验证响应文本中包含"foxgem",它是welcome.jsp页面逻辑的一部分。
             http cookie管理器负责管理整个测试过程中使用的cookie,它不需要设置任何属性。
             循环控制器设置发送第二个请求的循环次数,表格监听器负责收集和显示第二个请求的测试结果。
             启动测试计划之后,执行的顺序是:首先,第一个请求登录页进行登录;成功登录之后,使用循环控制器执行第二个请求。请求welcome.jsp时,响应断言用来验证是否确实是welocme.jsp来处理请求,而不是因为其它页。在这个测试计划中需要注意的是http cookie管理器。正是由于它的作用,使得第二个请求能顺利的发送到welcome.jsp进行处理,而不是因为缺少用户安全信息转发到login.jsp。

                在这个例子中,我们并没有在程序中使用cookie(使用的是session),那么http cookie管理器怎么会起作用呢?这是因为在servlet/jsp规范中对于session的状态跟踪有2种方式:

                使用cookie,保留和传递sessionid。它不要求程序对于url有什么特殊的处理,但是要求浏览器允许cookie。在这个例子中,就是这种情形。
             使用url重写,每次显式的在浏览器和服务器之间传递sessionid。它要求程序对url进行编码,对浏览器没有要求。         对于第二种情形,可以使用JMeter前置管理器中的http url重写修饰符来完成。对于Tomcat,Session参数是jsessionid,路径扩展使用";"。使用url编码时需要注意,必须将浏览器的cookie功能关闭。因为url编码函数,如encodeURL,会判断是否需要将sessionid编码到url中。当浏览器允许cookie时,就不会进行编码。

                如果cookie而不是session来保存用户安全信息,那么直接使用http cookie管理器就行了。此时,需要将使用的cookie参数和值直接写到管理器中,由它负责管理。对于其它的cookie使用,也是如此操作。

                登录问题解决之后,对于 Web 服务器的测试就没什么难点了。剩下的就是根据实际需要,灵活运用相关的测试组件搭建编写的测试计划。(当然,对于安全问题还有其它的使用情景。在使用时需要明确:JMeter 是否支持,如果支持使用哪种测试组件解决。)

        数据库服务器

                数据库服务器在大多数企业项目中是不可缺少的,对于它进行压力测试是为了找出:数据库对象是否可以有效地承受来自多个用户的访问。这些对象主要是:索引、触发器、存储过程和锁。通过对于sql语句和存储过程的测试,JMeter 可以间接的反应数据库对象是否需要优化。

                JMeter 使用 JDBC 发送请求,完成对于数据库的测试。一个数据库测试计划,建立如下结构即可:

           

        其中:

                JDBC连接配置,负责配置数据库连接相关的信息。如:数据库url、数据库驱动类名、用户名和密码等等。在这些配置中,"绑定到池的变量名"(Variable Name Bound to Pool)是一个非常重要的属性,这个属性会在JDBC请求中被引用。通过它, JDBC请求和JDBC连接配置建立关联。(测试前,请将所需要的数据库驱动放到JMeter的classpath中)。 JDBC请求,负责发送请求进行测试。 图形结果,收集显示测试结果。         在实际的项目中,至少有2种类型的JDBC请求需要关注:select语句和存储过程。前者反应了select语句是否高效,以及表的索引等是否需要优化;后者则是反应存储过程的算法是否高效。它们如果效率低下,必然会带来响应上的不尽如人意。对于这两种请求,JDBC请求的配置略有区别:

        Select语句

           

    存储过程

            

            如果对于oracle,如果测试的是函数,那么也可以使用select语句来进行配置,此时可以使用:select 函数(入参) from dual形式的语句来测试,其中dual是oracle的关键字,表示哑表。对于其它厂商的数据库产品,请查找手册。

    JMS服务器

            MOM 作为消息数据交换的平台,也是影响应用执行效率的潜在环节。在 Java 程序中,是通过 JMS 与 MOM 进行交互的。作为 Java 实现的压力测试工具,JMeter 也能使用 JMS 对应用的消息交换和相关的数据处理能力进行测试。这一点应该不难理解,因为在整个测试过程中,JMeter 测试的重点应该是消息的产生者和消费者的本身能力,而不是 MOM本身。

    根据 JMS 规范,消息交换有2种方式:发布/订阅和点对点。JMeter针对这两种情形,分别提供了不同的Sampler进行支持。以下MOM我们使用ActiveMQ 3.2.1,分别描述这两种消息交换方式是如何使用 JMeter 进行测试。

    1. 测试前的准备(两种情况都适用)

            JMeter 虽然能使用 JMS 对 MOM 进行测试,但是它本身并没有提供JMS需要使用的包。因此,在测试之前需要将这些包复制到 %JMETER_HOME%/lib 下。对于 ActiveMQ 来说,就是复制 %ACTIVEMQ_HOME%/lib。%ACTIVEMQ_HOME%/optional 是可选包,可根据实际情况来考虑是否复制。

            JMeter 在测试时使用了 JNDI,为了提供 JNDI 提供者的信息,需要提供 jndi.properties。同时需要将 jndi.properties 放到 JMeter 的 classpath 中,建议将它与 bin下的 ApacheJMeter.jar 打包在一起。对于 ActiveMQ,jndi.properties 的示例内容如下:

    java.naming.factory.initial = org.activemq.jndi.ActiveMQInitialContextFactory java.naming.provider.url = tcp://localhost:61616

    #指定connectionFactory的jndi名字,多个名字之间可以逗号分隔。 #以下为例: #对于topic,使用(TopicConnectionFactory)context.lookup("connectionFactry") #对于queue,(QueueConnectionFactory)context.lookup("connectionFactory") connectionFactoryNames = connectionFactory

    #注册queue,格式: #queue.[jndiName] = [physicalName] #使用时:(Queue)context.lookup("jndiName"),此处是MyQueue queue.MyQueue = example.MyQueue

    #注册topic,格式: # topic.[jndiName] = [physicalName] #使用时:(Topic)context.lookup("jndiName"),此处是MyTopic topic.MyTopic = example.MyTopic  

    2. 发布/订阅

            在实际测试时,发布者和订阅者并不是需要同时出现的。例如,有时我们可能想测试单位时间内消息发布者的消息产生量,此时就不需要消息发布者,只需要订阅者就可以了。本例为了说明这两种Sampler的使用,因此建立如下的测试计划:

               

            其中JMS Publisher和JMS Subscriber的属性:选择"使用jndi.properties",连接工厂是connectionFactory,主题是MyTopic,其它使用默认配置。对于JMS Publisher,还需提供测试用的文本消息。

            启动ActiveMQ,运行测试计划。如果配置正确,那么与ActiveMQ成功连接之后,在JMeter的后台会打印出相关信息。在测试过程中,JMeter 后台打印可能会出现java.lang.InterruptedException 信息,这个是正常现象,不会影响测试过程和结果。这一点可以从 bin 下的 jmeter.log 看出。

    3. 点对点

            对于点对点,JMeter只提供了一种Sampler:JMS Point-to-Point。在例子中,建立如下图的测试计划:

               

            其中:Communication style是Request Only。对于另一种风格:Request Response,会验证收到消息的JMS Header中的JMSCorrelationID,以判断是否是对请求消息的响应。

    结论

            本文介绍了如何使用JMeter完成最常用的三种类型服务器的压力测试,这三种类型的压力测试涵盖了很大一部分的使用情形,然而需要记住的是工具毕竟是工具。效果好不好,关键还是在于使用的人。而且,对于压力测试,测试计划的好坏是关键。针对不同的情况,分析后有针对的进行测试,比起拿枪乱打、无的放矢显然要高效得多。

  • 如何对一个U盘存储设备进行测试

    2008-09-23 15:06:58

    1、是否支持格式化类型
    2
    、不同情况下LED灯的情况(文件传输,删除文件,格式化)
    3
    U盘的加锁功能是否正常

    4
    、传输文件时,断电或拔掉,U盘中的数据是否丢失
    5
    、传输文件时,Cancel后,文件传输是否停止
    6
    、存储不同格式的文件,是否能正确显示
    7
    U盘中塞满图片,浏览时的反应速度是否正常
    8
    、在U盘中观看大型的影视文件,看读盘会不会hang up
    9
    、不同的应用程序打开U盘中的文件是否正确

    10
    、不同的系统是否可以正确识别出U
    11
    U盘的盘符是否正确
    12
    、网络共享时,其它用户是否能找到该U
    13
    U盘容量显示是否正确
    14
    、传输速度的测试(USB1.02.0)
    15
    、是否支持热插拔

    16
    、是否便于携带
    17
    U盘通过USB线连接电脑,传输是否正常
    18
    U盘满后,住Ucopy文件时是否正确提示
    19
    、安装好U盘驱动后,U盘是否正确工作
    20
    U盘的外观,重量
    21
    U盘在极端的工作温度范围内,是否正常工作
    22
    U盘的已用空间和可用空间显示是否正确
    23
    、系统中是否正确显示U盘的型号
    24
    、更换别的USB插口,U盘是否正常工作
    25
    U盘未格式化之前,是否充许存储文件
    26
    U盘制作成引导盘后,是否能正确引导系统
    27
    U盘的防震功能
    28
    U盘格式化后,U盘中的数据是否丢失
    29
    、在系统中移除U盘,U盘的盘符是否消失

    U
    盘的插拔识别
    U
    盘的容量
    U
    盘的读写
    U
    盘文件的加密解密
    格式化U
    U
    盘的读写速度
    U
    盘多盘符
    U盘上创建、修改、删除文件
    U
    盘的超时
    U盘复制大文件(U盘空间够大或者不够大)
    操作系统的兼容性(XP自带U盘驱动,自己编写的U盘驱动能否被成功安装?)
    U
    盘与虚拟磁盘驱动的冲突

  • 邮件服务器的协议有哪几个?有什么特点

    2008-09-23 14:51:44

    邮件服务器是一种Internet服务软件产品,支撑着Internet众多网络服务的是各种服务协议。在选择邮件服务器产品时,要重点考虑其支持服务协议方面的能力,因为它是衡量产品性能的重要指标。与邮件服务器产品有关的网络服务协议主要有以下6,其中我们重点介绍和我们关系最密切的两个:
    1
    SMTP 协议
      SMTP协议 (Simple Mail Transfer Protocol,简单邮件传输协议)是最早出现的,也是被普遍使用的最基本的Internet邮件服务协议。正如它的名称,SMTP协议支持的功能确实比较简单,并且有安全方面的缺陷。经过它传递的所有电子邮件都是以普通正文形式进行的。它不能够传输诸如图像等非文本信息。在网络上明码传输文本信息意味着任何人都可以在中途截取并复制这些邮件,甚至对邮件内容进行窜改。邮件在传输过程中可能丢失。别有用心的人也很容易以冒名顶替的方式伪造邮件。为了克服上述缺陷,后来出现了ESMTP (Extended SMTP,扩展的SMTP协议)
    2
    POP3 协议
      POP 协议(Post Office Protocol,邮局协议)是一种允许用户从邮件服务器收发邮件的协议。它有2种版本,即POP2POP3,都具有简单的电子邮件存储转发功能。POP2POP3本质上类似,都属于离线式工作协议,但是由于使用了不同的协议端口,两者并不兼容。与 SMTP协议相结合,POP3是目前最常用的电子邮件服务协议。
      POP3除了支持离线工作方式外,还支持在线工作方式。在离线工作方式下,用户收发邮件时,首先通过POP3客户程序登录到支持POP3协议的邮件服务器,然后发送邮件及附件;接着,邮件服务器将为该用户收存的邮件传送给POP3客户程序,并将这些邮件从服务器上删除;最后,邮件服务器将用户提交的发送邮件,转发到运行SMTP协议的计算机中,通过它实现邮件的最终发送。在为用户从邮件服务器收取邮件时,POP3是以该用户当前存储在服务器上全部邮件为对象进行*作的,并一次性将它们下载到用户端计算机中。一旦客户的邮件下载完毕,邮件服务器对这些邮件的暂存托管即告完成。使用POP3,用户不能对他们贮存在邮件服务器上的邮件进行部分传输。离线工作方式适合那些从固定计算机上收发邮件的用户使用。
      当使用POP3在线工作方式收发邮件时,用户在所用的计算机与邮件服务器保持连接的状态下读取邮件。用户的邮件保留在邮件服务器上。
    3
    IMAP4 协议 (Internet Message Access ProtocolInternet消息访问协议)
      为用户提供了有选择地从邮件服务器接收邮件的功能、基于服务器的信息处理功能和共享信箱功能。

    4
    HTTP 协议和 HTML 语言
      支持这个协议的邮件服务器可以提供基于Web的电子邮件收发服务。借助HTML语言,管理员可以自己定义和编写面向用户的电子邮件服务网页。这样,用户可以使用任何Web浏览器,通过Internet在任何地点收发电子邮件。系统管理员也可以使用Web浏览器,实现对邮件服务器的远程管理*作。
    5
    MIME 协议
      多用途 Internet邮件扩展 (Multipurpose Internet Mail Extensions)协议。作为对SMTP协议的扩充,MIME规定了通过SMTP协议传输非文本电子邮件附件的标准。
    6
    LDAP 协议
      轻量目录访问协议 (Lightweight Directory Access Protocol)。通过将相关的内容存放在统一的目录之下,目录服务为用户提供了基于客户/服务器工作方式的信息查询手段。

  • 升级测试

    2008-06-13 16:27:59

    什么是升级测试?比如说你们公司开发的产品现已经发布的是V1.0,由于被发现存在缺陷,这时就需开发PatchHot Fix,并进行升级测试,然后发布V1.1

    升级测试听起来似乎挺平常的,但它其实也是软件测试中比较重要的一部分,它通常包括以下内容:

    • 安装测试
    • 数据库测试
    • 应用测试
    • 文档测试

    安装测试

    当发布一个系统的新版本时,程序代码肯定是被修改过了,安装测试的目的是确保安装完成后修改过的文件被复制到了正确的位置,比如说某个文件夹包含了所有更新的HTML文件,这时就要检查相关的CSS文件夹下的文件是不是更新了,如果只更新了HTML而没更新CSS,那么相应的颜色/字体就不能正确地显示。

    如果公司研发过程比较规范,安装测试通常是在配置管理员的配合下完成的。首先,是文件夹级的测试,检查安装过程中复制到系统中的文件夹的时间戳是否变化;其次,检查被修改过的文件的大小,并和之前的版本进行比较,当然,这分两种测试,如果是白盒测试,测试人员要打开相应的文件确认新代码和改过的代码,如果是黑盒测试,那就要检查文件大小应与旧版本的不同。

    数据库测试

    很多情况下,系统的升级都是伴随着数据库脚本的更新,数据库测试通常也是由DBA人员或在DBA的配合下进行。升级前要停止数据库并做备份,然后执行升级脚本,之后测试人员需要查看数据库日志,并检查库中被修改的记录是否正确。如果升级脚本是在库中创建一个新的Table或是新的Relation,那么数据库测试应该关注对空库的测试,比如先建一个空库V1.0,只包含一些空的TableRelation,而不包含任何数据,然后测试人员执行升级脚本,并查看日志文件里是否有报错,如果没有报错一切ok,则通过应用程序连到数据库上执行一些功能测试用例来确保数据的InsetUpdate都是正确的。

    应用测试

    当安装测试和数据库测试都通过之后,进行应用测试,有两种方法:

    方法一:先配一个空的数据库(即除了一些必需的初始化数据再没有其他数据),然后把应用程序升级一下,执行业务流程测试看系统是否能够正常运行。

    方法二:也是先配好数据库,但库里存有一些实际数据,然后把程序升级一下(比如从V1.0升至V1.1),运行应用程序,检查那些已有的数据在V1.1上是否也能被正确的展现和使用,最后执行业务流程测试看系统是否能够正常运行。

    有的时候升级完后还要手工修改库中已有的记录,比如一个网上银行的系统,它里面有很多支付或转帐的数据,在做升级测试时,就可能要修改那些在上一版本中生成的数据,因为它们可能涉及到多个表之间的数据转换或一二级约束。

    文档测试

    文档测试主要是验证相关的版本说明或者安装手册等文档是否和系统升级相匹配,这点很重要,因为客户通常都是根据版本说明和安装手册进行系统的安装或升级。

    进行文档测试必须理解详细的升级步骤,比如文档中应建议用户升级前要备份数据库、数据文件、配置文件等,再比如升级需要复制某些文件到特定目录,应当在版本说明中有所体现,总之,升级时任何必要的说明都应当在版本说明或安装手册内阐述清楚,安装时可以做什么以及不可以做什么都应在版本发布前得到确认。

  • 推荐两款Pdf转换成Wrod格式软件

    2008-06-05 10:57:26

    第一款:e-pdfconverter
    官方下载地址:  http://www.e-pdfconverter.com/

    霏凡软件下载地址:http://www.crsky.com/soft/7162.html
    e-PDF To Word Converter v2.5.0.1 汉化版

    介绍:批量转换 PDF 文件为 Word 文档(DOC) 或者 富文本格式(RTF) 以便于重复利用你的 PDF 文档内容,不需要安装Microsoft Word、Adobe Acrobat软件来提供支持,对包括各种编码在内的中日韩等东亚语系的方块字支持良好。对待转换文件的路径名和文件名也没有特殊要求,并非只支持 ASCII 字符构成的路径名和文件名。是一款相当方便的 PDF 解码工具。


    第二款:SolidConverterPDF
    官方下载地址:
    http://www.soliddocuments.com/products.htm?product=SolidConverterPDF

    绿色下载站:http://www.greendown.cn/soft/1548.html
    Solid Converter PDF V3.0汉化绿色版

    介绍: Solid Converter PDF对Word来说是要将PDF文件转换成Microsoft Word文件(和Word文件转换成PDFs)。Solid Converter在Adobe收取少量成本费的情况下可以让你的文本,版面和图象重新获得正本单据。
  • 基于Web的系统测试方法

    2008-06-05 10:37:48

    基于Web的系统测试方法

    基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试

      本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

      随着InternetIntranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。

      Yogesh DeshpandeSteve Hansen1998年就提出了Web工程的概念。Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。

      在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对WebInternet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

      在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,InternetWeb媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

      一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

      一、功能测试

      1、链接测试

      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

      链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试

      2、表单测试

      当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

      3Cookies测试

      Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

      如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

      4、设计语言测试

      Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如JavaJavascrīpt ActiveXVBscrīptPerl等也要进行验证。

      5、数据库测试

      在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

    在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试

      二、性能测试

      1、连接速度测试

      用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

      另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

      2、负载测试

      负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

      3、压力测试

      负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

      进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

      压力测试的区域包括表单、登陆和其他信息传输页面等。

      三、可用性测试

      1、导航测试

      导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

      在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

      导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

      Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试

  • 软件测试BUG参考标准

    2008-05-30 16:39:35

    一、目的

            对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范,以便进一步指导我们的软件测试工作

        二、概念

            BUG :软件中存在的瑕疵,可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。

        三、 BUG 的类型划分

        功能类

        A. 重复的功能

        B. 多余的功能

        C. 功能实现与设计要求不相符

        D. 功能使用性、方便性、易用性不够

        界面类

        A. 界面不美观

        B. 控件排列、格式不统一

        C. 焦点控制不合理或不全面

        数据处理类

        A. 数据有效性检测不合理

        B. 数据来源不正确

        C. 数据处理过程不正确

        D. 数据处理结果不正确

        流程类

        A. 流程控制不符和要求

        B. 流程实现不完整

        提示信息类

        A. 提示信息重复或出现时机不合理

        B. 提示信息格式不符和要求

        C. 提示框返回后焦点停留位置不合理

        建议类
     
        A. 功能性建议

        B. 操作建议

        C. 检校建议

        D. 说明建议
     
        性能类

        A. 并发量

        B. 数据量

        C. 压缩率

        D. 响应时间

        常识类

        A. 违背正常习俗习惯的,比如日期 / 节日等

        特殊类

        A. 不符合 OEM 版本或 DEMO 版本特殊要求的

  • 软件测试中容易忽略的缺陷

    2008-05-30 16:31:04

    摘要
            在系统测试和确认测试中,有些缺陷由于某些原因往往被忽略了,这就给软件留下了隐患或者危机。本文通过描述这些容易忽略的缺陷,提供一个完善测试用例和测试执行的参考。

    正文:
            通常软件测试会暴露软件中的缺陷,经过修正后可以保证软件系统的功能满足需求并正确运行。但是,在系统测试和确认测试中,测试人员容易遗漏一些隐藏的缺陷。众所周知,软件测试不可能发现所有的缺陷,而软件开发周期各个阶段仍然存在注入缺陷的可能,但是,有一些缺陷是测试中容易忽略的,也就是说,通过测试方法和用例可以充分暴露这些缺陷,遗憾的是,它们往往被忽略或者某种原因忘记测试了,这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括:
    1、安装缺陷
            通常项目组完成代码后,发布时候安装打包是最后一个环节,而软件测试人员通常在测试的时候,没有仔细的测试这一部分,而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件,结果正式安装时候出现问题,引起例如控件没有注册,注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件,造成数据丢失;使用绝对路径;安装顺序没有说明书。
    2、配置文件
            有些文件在 ini 等配置文件中写出了管理员口令密码等信息,而且是明文的!这是一个安全隐患。另外,有些安装文件的 XML 文件,为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员,必须检查这些可以用记事本打开的文件。因为,一个稍有常识而且喜欢探索的用户,可能从中获取信息而成为不自觉的黑客。所以,配置文件可能成为软件安全方面的一个缺陷。
    3、网页安全缺陷
            现在网站开发已经注意到:登陆网站进入其内部网页后,直接拷贝网址,然后粘贴到另一IE 窗口输入,可以绕过登陆直接访问。也许商业网站很关注这个问题,但是很多行业软件却很容易忽略。
            网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件,在主页面关闭的时候子页面还可以运行,这是一个明显的漏洞,而且还大大增加了错误发生的几率。
    4、判断顺序/逻辑缺陷
            对界面进行多个输入判断的时候,非常容易出现这种问题。例如判断年月顺序,判断长度,判断非空等。假如操作员仅仅满足单个条件,保存不能成功;而按界面从上之下顺序一一满足条件之后,保存是没有问题的。但是,改变一下输入的次序,校验失效。例如,一一满足条件之后,不保存,倒过来将上面的输入改成非法输入,然后保存,结果居然也能成功,这是因为原先的判断由于发生过,或者根据语句顺序只检查最后一个判断,所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确,有可能引起系统崩溃或者后续数据错误。所以,在测试的时候,不要按照正常的顺序输入,而是要打乱步骤,看看代码是否强健,是否在判断逻辑上没有错误。良好的代码应该经得起折腾,至少保存时会再此全部进行判断,而不只是简简单单走到判断的最后一行。
    5、调试语句和冗余信息
            维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息,会使不明真相的用户产生误以为系统发生了严重故障,从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用,其结果可想而知;而多余的按钮会误导好奇心强的用户操作,产生不必要的错误。
            同样值得关注的还有参数设置,由于没有实际数据,开发人员在调试或者单元测试的时候,习惯性的进行自我设定而忘了删除,软件测试人员可能会忽略掉了这部分测试,也可能导致在客户现场发生错误而影响系统发布和验收。
    6、不可重现的故障
            新参加软件测试的人员或者新来的开发人员总是要问,不可重现的缺陷是否需要记录,有必要吗?回答是肯定的。测试必须如实的记录发生的问题,也许不能重现,或者使非软件系统本身问题,但是,可能这些偶然性背后是有规律的,不记录这些,就不可能发现这些规律。
    7、多节点的逆向流转缺陷
            当前软件不少喜欢使用工作流来驱动。工作流的问题,就是可能出现多个流向分支。测试容易忽略的部分,就是工作流多节点的逆向流转。例如,通过不通过涉及两个分支,但是流程逆转的时候,有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外,有些时候默认分支在向前的时候是有默认值的,例如默认通过,那么保存的时候要提示用户是否通过,否则可能由于操作疲劳而走错了节点,引起回退。
    8、输入框缺陷
            试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候,输入框会根据长度大小自动截断输入长度。但是用鼠标,截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了,保存的时候,数据库崩溃。有些网站登陆的口令****可以拷贝下来的,只要放在剪贴板里面马上明文显示。
            输入框可以说是问题最多的部分,能够引起的麻烦也很多。日期、数字、文本等等,都需要耐心的测试一下。
    9、界面布局缺陷
            曾经有一次,项目经理回来向测试部反映一个问题,客户对界面不满意。原因很简单,因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员,很容易误按。这个问题是测试人员没有意料到的,因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。
            界面布局还可能发生在窗口最大化和最小化上,有可能窗口缩小的时候没有下拉框或不匹配分辨率,对用户来讲,这个错误实在很低级。有些用户由于操作习惯,非常不喜欢腾出手使用鼠标,尤其是大量输入的界面,因此,要注意设置键盘的快捷方式。还有,按 Tab定位到下一焦点时要注意顺序,避免跳转太灵活而让操作人员感到无从适应,在界面进行维护或者修改的时候,不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。
    10、版本和补丁包的环境问题
            理论上讲,这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包,问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例,多用不同软件版本的机器跑一跑。软件测试有个定律是:你没跑过的地方,就一定会出事。经常听到开发人员抱怨,怎么我的机器没问题,你的机器就有事了呢?这不能完全靠配置管理员解决问题,环境配置项是大家最容易忽略的。
    11、用户管理缺陷
            用户管理的角色和授权需要好好研究一下,作过测试的人员都知道,有时候为了测试的方便,测试用户都是具有超级权限的用户。而且,比较容易忽略用户管理这一部分的测试。往往发往客户的时候,很多测试用户都没有删除。
            另外,有些接口的用户和口令,到软件使用寿命结束都没有更改过。在一次测试中,软件测试人员发现,给一个用户授超级用户权限,之后更改这个用户为受限权限。使用中发现,用户居然没有真正回收权限,用户管理界面上没有任何不对。及早准备用户管理用例,不要等到测试快结束时候才想起。
    12、常识缺陷
            从逻辑或者统计学上讲,计算机是允许如此处理的,但是从常识上来讲,这些情况不可能发生。例如电话号码不可能出现小数点,终止时间不能大于开始时间等等。除此之外,常识还要结合业务特点来进行判断,因此,开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现,对用户来说,这些错误可能是很荒谬的。
            尽管我们不可能完美的测试一个软件,但是我们仍然可以改进我们的软件测试。每次测试结束,及时总结测试中的不足,进一步完善用例。思考一下那些容易忽略的软件缺陷,能提高对软件测试的认识,提高所在组织软件的质量。

  • 关于“卸载测试”

    2008-05-12 11:25:49

    关于“卸载测试”


    ============卸载测试==============
    文件----安装目录里的文件及文件夹(如:程序安装在几处的)
          非安装目录(向系统其它地方添加的文件及文件夹)
                它们包括(exe,dll,配置文件等)
    快捷方式-(桌面,菜单,任务栏,系统栏,控件面板,系统服务列表等)
    复原方面-卸载后,系统能否恢复到软件安装前的状态(包含目录结构、动态库,注册表,
    系统配置文件,驱动程序,关联情况等)
    卸载方式--程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具(如:优化大师)
    卸载状态--程序在运行/暂停/终止等状态时的卸载
    非正常卸载情况-卸载软件过程中,取消卸载进程,然后,观察软件能否继续正常使用
    冲击卸载--在卸载的过程中,中断电源,然后,启动计算机后,重新卸载软件,如果软件
    无法卸载,则重新安装软件,安装之后再重新卸载。
    卸载环境--不同的(操作系统,硬件环境,网络环境等)下进行卸载
    卸载后,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
    ==========安装测试============
    一:基本目标
    1.安装程序能正确运行
    2.程序安装正确
    3.程序安装后能正确运行
    4.完善性安装后程序能正确运行
    二:一些方面
    0、安装手册给的所有步骤得到验证;
    1、安装过程中所有缺省选项得到验证;
    2、安装过程中典型选项得到验证;
    3、测试各种不同的安装组合,并验证各种不同组合的正确性(包括参数组合,控件执行顺序
    组合,产品安装组件组合,产品组件安装顺序组合(如b/s)等)
    4、安装过程中异常配置或状态(非法和不合理配置)情况进行了测试(如:断电;数据库终
    止,网络终止等)
    5、安装后是否能产生正确的目录结构和文件,文件属性正确;
    6、安装后动态库是否正确;
    6、安装后软件能否正确运行;
    7、安装后没有生成多余的目录结构,文件,注册表信息,快捷方式等;
    9、安装测试应该在所有的运行环境上进行验证(手册上指定如:操作系统,数据库,硬件环
    境,网络环境等);
    10、自动安装还是手工配置安装
    11、至少要在一台笔记本上进行安装/卸载测试,因为有很多产品在笔记本中会出现问题,
    尤其是系统级的产品
    13、安装,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
  • 我们需要真正的脚本语言

    2008-05-12 11:13:30

    大部分测试工具绑定了工具生产商指定的特定脚本语言,我们叫它厂商语言。这些语言很难学,实现得很弱,最重要的是,它们不鼓励测试员与开发人员之间的合作。测试员应该得到全特性的、标准的测试开发语言。为什么呢?
     
    现在市面上的大部分测试工具,我们在使用时都要使用工具的脚本语言。令我最烦恼的是,为了使用他们的工具,我必须学习指定的脚本语言。大部分工具有录制功能,为你产生一些脚本,但是不可避免地,你要对脚本进行修改,自己编写脚本。这样的话,你就必须要学习额外的语言-厂商语言-这个语言只是在这个特定的工具上能使用!
     
    破坏合作
    因为厂商语言是特定的语言,开发人员对其知之甚少并且也不愿意学习它。我经常鼓励测试员和开发人员在自动化项目中一起合作。这是高效的合作方式。但是厂商语言挡在中间。它们把测试员和开发人员分开,孤立在指定的工具语言上。减少了共享、合作和改进的机会。
     
    要把测试员和开发人员整合在测试过程中,我们已经有很多困难了。现在又多了个厂商语言的学习问题。你如果叫一个开发人员学习VB?没问题,因为他们毕竟可以在将来有使用得上的机会。你如果叫一个开发人员学习一个指定的语言,这个语言只能在这个工具上使用?你做梦吧!你已经很难让开发人员把注意力放在测试上了,现在又增加了一个困难。
     
    为什么要把钱花在一个会破坏测试员与开发人员之间的合作关系的工具上?
     
    方言
    有很多这种厂商脚本的方言。有些是类C语言。意味着什么?意味着写出来的代码想C语言的代码,但是没有指针,所以你不能使用在C课程和书本上学习到的任何复杂的数据结构。C作为脚本语言来说是很差的。它是编译的,但是测试脚本语言是解释执行的。这是为什么类C语言不支持指针。
     
    其它的有些使用类VB语言的方言。如果你了解VB,则代码会看起来很眼熟,但是你不能使用VB的标准库。而且,你在VB中学到的东西未必被应用在厂商脚本语言上。
     
    也有一些工具使用类似面向对象的厂商脚本语言。面向对象是好的,但是你会发现对一个类的修改不会继承到它的子类。什么?因为厂商脚本语言认为这样更方便测试的管理安排。这样是否真的能帮助测试员还有待讨论,但是测试员真正需要的不是为测试特定设计的语言。他们应该得到标准的语言实现,这样才会更好地帮助他们的测试工作。
     
    一些更新的测试工具现在开始使用真正的脚本语言,像Javascrīpt或VB。我希望这种趋势能继续下去。而且,如果一些旧的工具能重新设计以支持标准语言则会更好。标准语言有正式的规范,会帮助你的测试组更好地用在测试上。
     
    重复地发明轮子
    最近有些文章在描述怎样使用厂商脚本添加堆栈和队列,这其实是厂商脚本的落后体现。厂商语言使自动化测试人员浪费很多时间和精力在重新发明轮子。堆栈和队列在标准语言上已经得到很好的实现。
     
    我自己也有同感。我必须为不同的厂商语言创建库来支持sting操作、日期计算、计算排列组合等。有些厂商语言也有这样的库,但是标准语言的库会更大、更全面,也更加健壮。
     
    回到以前
    很多非测试工具也嵌入了厂商语言。使其更难使用。John Ousterhout发明了TCLTool Control Language),使得跟C的集成更容易,并发布到公共领域。TCL现在被用在一些公共领域的测试工具上。
     
    Ousterhout区分了系统编程语言(像Pascal、C、C++、Java等)和脚本语言(像Perl、Python、Rexx、TCL、VB、Unix shells等)。系统编程语言在从头开始构建方面和性能方面会更好点。而脚本语言在重用代码和快速开发方面有优势,是理想的自动化测试语言。
     
    有些测试工具的厂商语言是在OusterhoutTCL出现之前,当时Perl也还不成熟。但是那是那时候,现在则有了很多选择。
     
    让厂商脚本语言退休
    因为有了很多的选择,所以厂商脚本语言应该退休了。如果出现异常,没有什么第三方的书可以使用,只能参考和依赖厂商提供的书或帮助文档,这些文档未必会坦白告诉你厂商脚本语言的缺点。语言的课程也很难随工具附上,很昂贵,可能还要你亲自去学习。
     
    测试自动化会很难,如果我们需要熟悉不同工具的不同语言的话。开发人员不会忍受有这么多限制和缺点的编程语言,我们也不应该忍受。
     
    进一步学习请参考:
    scrīpting: Higher Level Programming for the 21st Century, John K. Ousterhout, IEEE Computer, March 1998.
    Breaking the Language Barrier, Christopher Meisenzahl and Ferry Firmansjah, STQE magazine, Nov 2000.
     
     
     
281/212>