Try to break software...

发布新日志

  • WinRunner Compared to QuickTest Professional(QTP)

    2008-12-11 16:40:59

    WinRunner和Quick Test Professional(简称QTP)都是MERCURY公司开发的非常强大功能自动化测试工具,从时间上来看,WinRunner在1995年便已经推出,而QTP直到2002年才正式推出。

    我想从以下几点来谈谈我个人的看法,这里只列出它们两者的不同点:

    1.从界面来看:WinRunner只有一个显示脚本的界面,而QTP的Keyword View 、Expert View、Data Table、Active Screen四个界面可以显示在同一个窗口,在脚本回放时让人可以时时刻刻了解到脚本运行的情况,虽然这些功能WinRunner都可以实现,但相比较下QTP更直观、更好;

    2.从支持的语言来看:如上表列出的,两者有所不同,在这我就不再列出;

    3.从生成的脚本来看:WinRunner生成的是TSL脚本,这是MI公司独有的语言,是一种类C语言,而QTP生成的是VBscrīpt,从编程能力上,WinRunner更胜一筹,因为它拥有相当丰富的C语言函数库,相对而言QTP则更显得大众化,它面向的是没有太多技术背景和编程经验的测试人员;

    4.从适用范围来看:WinRunner比较适用于C/S架构软件,而QTP虽然对于C/S架构的也适用,但对于B/S架构的适用性更剩一筹;

    5.QTP8.0具有的一大特性:关键字驱动测试(keyword-driven testing)其原理和特点如下:

    a.         关键字驱动测试是数据驱动测试的一种改进类型

    b.         主要关键字包括三类:被操作对象(Item)、操作(Operation)和值(value),用面向对象形式可将其表现为 Item.Operation(Value)

    c.         将测试逻辑按照这些关键字进行分解,形成数据文件。

    d.         用关键字的形式将测试逻辑封装在数据文件中,测试工具只要能够解释这些关键字即可对其应用自动化

  • WEB的性能测试分析

    2008-12-11 16:33:43

    性能测试的结果分析是性能测试的重中之重。在实际工作中,由于测试的结果分析比较复

    杂、需要具备很多相关的专业知识,因此常常会感觉拿到数据不知从何下手。这也是我学习性能

    测试过程中感觉比较尴尬和棘手的事,为此我在研读了《WEB性能测试实战》后特作了以下笔

    记,这里只是书中第4章WEB应用程序性能分析的一

    部分,贴出来希望和大家共同讨论:

    一:性能分析的基础知识:

        1.几个重要的性能指标:相应时间、吞吐量、吞吐率、TPS(每秒钟处理的交易数)、点

    击率等。

        2.系统的瓶颈分为两类:网络的和服务器的。服务器瓶颈主要涉及:应用程序、WEB服务

    器、数据库服务器、操作系统四个方面。

        3.常规、粗略的性能分析方法:

       当增大系统的压力(或增加并发用户数)时,吞吐率和TPS的变化曲线呈大体一致,则系统

    基本稳定;若压力增大时,吞吐率的曲线增加到一定程度后出现变化缓慢,甚至平坦,很可能是

    网络出现带宽瓶颈,同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现颈。

        4.作者提出了如下的性能分析基本原则,此原则本人十分赞同:

                ——由外而内、由表及里、层层深入

        应用此原则,分析步骤具体可以分为以下三步:

       第一步:将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈;

       第二步:比较Tn(网络响应时间)和Ts(服务器响应时间)可以确定瓶颈发生在网络还是服

    务器;

       第三步:进一步分析,确定更细组件的响应时间,直到找出发生性能瓶颈的根本原因。

    二:以WEB应用程序为例来看下具体的分析方法:

        1.用户事务分析:

        a.事务综述图(Transaction Summary ):以柱状图的形式表现了用户事务执行的成功与

    失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。若失败的事务非常多,则

    说明系统发生了瓶颈或者程序在执行过程中发生了问题。

        b.事务平均响应时间分析图(Average Transaction Response Time): 该图显示在

    测试场景运行期间的每一秒内事务执行所用的平均时间,还显示了测试场景运行时间内各个事务

    的最大值、最小值和平均值。通过它可以分析系统的性能走向。若所有事务响应时间基本成一条

    曲线,则说明系统性能基本稳定;否则如果平均事务响应时间逐渐变慢,说明性能有下降趋势,

    造成性能下降的原因有可能是由于内存泄漏导致。

        c.每秒通过事务数分析图(Transaction per Second即TPS):显示在场景运行的每一

    秒中,每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务

    负载。若随着测试的进展,应用系统在单位时间内通过的事务数目在减少,则说明服务器出现瓶

    颈。

         d.每秒通过事务总数分析图(Total Transactions per Second):显示场景运行的

    每一秒中,通过、失败以及停止的事务总数。若在同等压力下,曲线接近直线,则性能基本趋于

    稳定;若在单位时间内通过的事务总量越来越少,即整体性能下降。原因可能是内存泄漏或者程

    序中的缺陷。

          e.事务性能摘要图(Transaction Performance Summary):显示方案中所有事务的

    最小、最大平均执行时间,可以直接判断响应时间是否符合客户要求(重点关注事务平均、最大

    执行时间)。

          f.事务响应时间与负载分析图(Transaction Response Time Under load):通过

    该图可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性

    能数据。

          g.事务响应时间(百分比)图(Transaction Response Time(percentile)):该

    图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发,若可能事务的最大响

    应时间很长,但如果大多数事务具有可接受的响应时间,则系统的性能是符合。

          h.事务响应时间分布情况图(Transaction Response Time (Distribution)):该

    图显示了测试过程中不同响应时间的事务数量。若系统预先定义了相关事务可以接受的最小和最

    大事务响应时间,则可以使用此图确定系统性能是否在接受范围内。

  • 界面测试

    2008-12-11 16:11:05

    界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。
     
    目前流行的界面风格有三种基本方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。
     
    1:易用性:
    按钮名称应该易懂,用词准确,屏弃摸棱两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
    易用性细则:
    1):完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。
    2):完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。
    3):按功能将界面划分局域块,用Frame框括起来,并要有功能说明或标题。
    4):界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。
    5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
    6):同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。
    7):分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab
    8):默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。
    9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
    10):Tab键的顺序与控件排列顺序要一致,目前流行总体从上到下,同时行间从左到右的方式。
    11):复选框和选项框按选择几率的高底而先后排列。
    12):复选框和选项框要有默认选项,并支持Tab选择。
    13):选项数相同时多用选项框而不用下拉列表框。
    14):界面空间较小时使用下拉框而不用选项框。
    15):选项数较少时使用选项框,相反使用下拉列表框。
    16):专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。
     
    2: 规范性:
    通常界面设计都按Windows界面的规范来设计,即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具箱。
     
    规范性细则:
    1):常用菜单要有命令快捷方式。
    2):完成相同或相近功能的菜单用横线隔开放在同一位置。
    3):菜单前的图标能直观的代表要完成的操作。
    4):菜单深度一般要求最多控制在三层以内。
    5):工具栏要求可以根据用户的要求自己选择定制。
    6):相同或相近功能的工具栏放在一起。
    7):工具栏中的每一个按钮要有及时提示信息。
    8):一条工具栏的长度最长不能超出屏幕宽度。
    9):工具栏的图标能直观的代表要完成的操作。
    10):系统常用的工具栏设置默认放置位置。
    11):工具栏太多时可以考虑使用工具箱。
    12):工具箱要具有可增减性,由用户自己根据需求定制。
    13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
    14):状态条要能显示用户切实需要的信息,常用的有:
     
    目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,
     如果某一操作需要的时间较长,还应该显示进度条和进程提示。
    15):滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
    16):状态条的高度以放置5号字为宜,滚动条的宽度比状态条的略窄。
    17):菜单和工具栏要有清楚的界限;菜单要求凸出显示,这样在移走工具栏时仍有立体感。
    18):菜单和状态条中通常使用5号字体。工具栏一般比菜单要宽,但不要宽的太多,否则看起来很不协调。
    19):右键快捷菜单采用与菜单相同的准则。
     
    3:帮助设施:
     
    系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
     
    帮助设施细则:
    1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)。
    2):打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
    3):操作时要提供及时调用系统帮助的功能。常用F1。
    4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    5):最好提供目前流行的联机帮助格式或HTML帮助格式。
    6):用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
    7):如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
    8):在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。
     
    4:合理性:
     
    屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
     
    合理性细则:
    1):父窗体或主窗体的中心位置应该在对角线焦点附近。
    2):子窗体位置应该在主窗体的左上角或正中。
    3):多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
    4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。(默认界面应该只显示目标用户最常使用的功能,至于不常用到的高级功能,可以“隐藏”起来,比如说,放到菜单里,不要都做成按钮摆到界面上。果真需要需要这些高级功能的话,用户自然会到菜单里去找的。 )
    5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
    6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。
    7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    8):非法的输入或操作应有足够的提示说明。
    9):对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
    10):提示、警告、或错误说明应该清楚、明了、恰当。
     
    5:美观与协调性:
    界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
    美观与协调性细则:
    1):长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
    2):布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
    3):按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
    4):按钮的大小要与界面的大小和空间要协调。
    5):避免空旷的界面上放置很大的按钮。
    6):放置完控件后界面不应有很大的空缺位置。
    7):字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。
    8):前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。蓝色文字以白色背景容易识别,而在红色背景则不易分辨,原因是红色和蓝色没有足够反差,而蓝色和白色反差很大。除非特殊场合,杜绝使用对比强烈,让人产生憎恶感的颜色。常用色考虑使用Windows界面色调。
    9):整个界面色彩尽量少的使用类别不同的颜色。统一色调,针对软件类型以及用户工作环境选择恰当色调:如:安全软件,根据工业标准,可以选取黄色,绿色体现环保,蓝色表现时尚、紫色表现浪漫等等,淡色可以使人舒适,暗色做背景使人不觉得累等
    10):如果使用其他颜色,主色要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
    11):大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
    12):界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
    13):如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
    14):对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。
    15):通常父窗体支持缩放时,子窗体没有必要缩放。
    16):如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。

    6:菜单位置:
    菜单是界面上最重要的元素,菜单位置按照按功能来组织。
    菜单位置细则:
    1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列,符合流行的Windows风格。
    2):常用的有“文件”、“编辑”,“查看”等,几乎每个系统都有这些选项,当然要根据不同的系统有所取舍。
    3):下拉菜单要根据菜单选项的含义进行分组,并切按照一定的规则进行排列,用横线隔开。
    4):一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。
    5):没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头, 不常用的靠后放置;重要的放在开头,次要的放在后边。
    6):如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
    7):菜单深度一般要求最多控制在三层以内。
    8):对常用的菜单要有快捷命令方式,组合原则见8。
    9):对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式——即只有需要的菜单才显示——最好。
    10):菜单前的图标不宜太大,与字高保持一直最好。
    11):主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。
    12):主菜单数目不应太多,最好为单排布置。

    7:独特性:
    如果一味的遵循业界的界面标准,则会丧失自己的个性.在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    独特性细则:
    1):安装界面上应有单位介绍或产品介绍,并有自己的图标。
    2):主界面,最好是大多数界面上要有公司图标。
    3):登录界面上要有本产品的标志,同时包含公司图标。
    4):帮助菜单的“关于”中应有版权和产品信息。
    5):公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
     
    8:快捷方式的组合
    在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。在西文Windows及其应用软件中快捷键的使用大多是一致的。
    菜单中:
    1):面向事务的组合有:
            Ctrl-D 删除
            Ctrl-F 寻找
            Ctrl-H 替换
            Ctrl-I 插入
            Ctrl-N 新建
            Ctrl-S 保存
            Ctrl-O 打开
    2):列表:
            Ctrl-R   刷新
            Ctrl-G   定位
            Ctrl-Tab 下一分页窗口或反序浏览同一页面控件
    3):编辑:
            Ctrl-A 全选
            Ctrl-C 拷贝
            Ctrl-V 粘贴
            Ctrl-X 剪切
            Ctrl-Z 撤消操作
            Ctrl-Y 恢复操作
    4):文件操作:
            Ctrl-P 打印
            Ctrl-W 关闭
    5):系统菜单
            Alt-A 文件
            Alt-E 编辑
            Alt-T 工具
            Alt-W 窗口
            Alt-H 帮助
    6):MS Windows保留键:
            Ctrl-Esc 任务列表
            Ctrl-F4 关闭窗口
            Alt-F4 结束当前程序
            Alt-Tab 切换当前程序
            Enter 缺省按钮/确认操作
            Esc 取消按钮/取消操作
            Shift-F1 上下文相关帮助
    按钮中:
    可以根据系统需要而调节,以下只是常用的组合。
            Alt-Y 确定(是)
            Alt-C 取消
            Alt-N 否
            Alt-D 删除
            Alt-Q 退出
            Alt-A 添加
            Alt-E 编辑
            Alt-B 浏览
            Alt-R 读
            Alt-W 写
    这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母(不推荐)。

    9:安全性考虑:
    在界面上通过下列方式来控制出错几率,会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
    如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

    安全性细则: 
    1):最重要的是排除可能会使应用非正常中止的错误。
    2):应当注意尽可能避免用户无意录入无效的数据。
    3):采用相关控件限制用户输入值的种类。
    4):当用户作出选择的可能性只有两个时,可以采用单选框。
    5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
    6):当选项特别多时,可以采用列表框,下拉式列表框。
    7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
    8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
    9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
    10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
    11):对错误操作最好支持可逆性处理,如取消系列操作。
    12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
    13):对可能造成等待时间较长的操作应该提供取消功能。
    14):特殊字符常有;;’”><,`‘:“[”{、\|}]+=)-(_*&&^%$#@!,.。?/还有空格。(此外,还要注意全角和半角符号的区别)
    15):与系统采用的保留字符冲突的要加以限制。
    16):在读入用户所输入的信息时,根据需要选择是否去掉前后空格。
    17):有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。

    10:多窗口的应用与系统资源:
    设计良好的软件不仅要有完备的功能,而且要尽可能的占用最底限度的资源。
    应用细则:
    1):在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换甚至最小化其他窗口来显示该窗口。
    2):显示多个窗口时,窗口的名称是否被适当地表示?
    3):活动窗口是否被适当地加亮?
    4):如果使用多任务,是否所有的窗口被实时更新?
    5):在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS系统资源。
    6):关闭所有窗体,系统退出后要释放所占的所有系统资源 ,除非是需要后台运行的系统。
    4):尽量防止对系统的独占使用。
    美丽的事物常常会让人无法抗拒。这就是为什么产品出色的外观设计对于电脑、汽车、日用品、家具、食品、服装等等几乎所有商品的销售与推广,都有着举足轻重的作用的原因。
    同样的道理,对于软件公司来说,软件产品就是他们的商品,而软件界面就是他们产品的外观,界面的美观与否,直接关系到了软件产品的营销成败。

  • 负载测试、容量测试和强度测试的区别

    2008-12-11 16:08:12

    负载测试:负载测试是一种性能测试,指数据在超负荷环境中运行,程序是否能够承担。 强度测试:强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。容量测试:确定系统可处理同时在线的最大用户数。

    1.强度测试或压力测试:强度或压力测试是在一种需要异常数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶颈。异常情况,主要指那些峰值、极限值、大量数据的长时间处理等,包括:连接或模拟了最大(实际或实际允许)数量的客户机; 所有客户机在长时间内执行相同的、性能可能最不稳定的重要业务功能;已达到最大的数据库大小,而且同时执行多个查询或报表事务当中断的正常频率为每秒一至两个时,运行每秒产生十个中断的测试用例;运行可能导致虚存操作系统崩溃或大量数据对磁盘进行存取操作的测试用例等。压力测试可以分为稳定性测试和破坏性测试:
    稳定性压力测试。在选定的压力值下,持续运行24小时以上的测试。通过压力测试,可以考察各项性能指标是否在指定范围内,有无内存泄漏、有无功能性故障等。 破坏性压力测试。在压力稳定性测试中可能会出现一些问题,如系统性能明显降低,但很难暴露出其真实的原因。通过破坏性不断加压的手段,往往能快速造成系统的崩溃或让问题明显的暴露出来。
    在压力测试中,会给程序加上一些跟踪机制(如log、
    日志等),然后查看监视系统、服务器等性能的日志文件是必要的,找出问题出现的关键时间或检查测试运行参数,通过分析问题或参数从而有目的地调整测试策略或测试环境,使压力测试结果真实地反映出软件的性能。

    2.性能测试系统的性能指标,一般赢在产品需求文档中有明确定义,有三种形式描述软件系统的性能指标:
    给出产品性能的主要指标,如在100000记录中查询一个特定数据的时间为0.5秒。以某个已发布的版本为基线,如比上一个版本的性能提高30-50%。 和竞争对手的同类产品比较。
    性能测试,根据其目的分为:产品性能质量测试,通过测试,决定产品是否达到产品规格书所要求的性能指标(非功能性需求)基准值测试,通过对当前产品的性能测试,确定产品具体的性能指标,建立性能指标基准。基准值,作为后继产品发布的性能参考(在新版本中,性能指标要求只升不降)或和竞争对手产品比较的参考。
    性能规划测试,通过不断的测试,确定所需要的硬件配置(内存、CPU、网络等)、软件配置,以满足实现定义的性能指标要求。这种测试,对于软件系统的部署是非常有意义的。同时,也可以进一步了解硬件参数、软件参数对系统性能的影响程度,从而保证系统具有很好的扩充性或事先制定较好的系统增容的计划。
    性能测试的方法,主要有:稳定压力加载,一次性将负载加到某个水平,持续一段时间,也称为flat测试。 逐渐加载或交替加载到某个负载水平,也称为“ramp-up”测试。 峰谷测试,确定从系统高峰时间的负载转为几乎空闲、再攀升到高负载这样峰值交替情况下的系统性能状态/指标。这种测试兼有容量测试的特点或属于容量测试的一部分。
    性能测试,一般都通过
    测试工具来模拟人为的操作而进行。性能测试的重点在于测试环境的建立、前期数据的设计与后期数据的分析。因为性能测试需要获得一定特定条件下(如100、200、500、1000个实时的连接)的系统占用资源(CPU、内存等)数据或系统行为表现,而且还要依靠测试工具或软件系统记录下这些指标变化的数据结果。例如,如果对一个Browser/Server结构的网络实时在线的培训系统软件进行测试,系统性能焦点是在不同数量的并发连接下,服务器的CPU、内存的占用率、客户端的响应时间等。测试过程中,并发连接的不断增加(负载的增加)在系统性能上的表现越来越明显。在系统性能测试时,加载过程中,每到一个测试点时须让系统平稳运行一段时间后再获取数据,以消除不同测试点的相互影响。从表中可以看出,同样是300个用户,1?00与60?的性能表现差别很大,加载的方式对系统性能影响也较大,所以,尽量模拟不同的加载方式来进行系统的性能测试。除此之外,还可以测试TCP、HTTPS等不同连接方式下的数据,进行比较。通过比较和分析,可以清楚知道系统的性能状况,以及什么样的条件下系统性能达到最佳状况、什么地方是性能的瓶颈。性能测试要求测试环境应尽量与产品运行环境保持一致,应单独运行,尽量避免与其他软件同时使用。

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

       压力测试、容量测试和性能测试的关系:压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段,不是直接的测试目标。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。而容量测试和性能测试是系统测试的主要目标内容,也就是确定软件产品或系统的非功能性方面的质量特征,包括具体的特征值。容量测试和性能测试更着力于提供性能与容量方面的数据,为软件系统部署、维护、质量改进服务,并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。压力测试、容量测试、性能测试,测试的方法相似、相通,在实际测试工作中,往往结合起来进行,以提高测试效率。一般会设置专门的性能测试实验室,完成这些工作。即使用虚拟的手段模拟实际操作,所需要的客户端有时还是很大的,所以性能测试实验室的投资较大。

  • 网站安全性测试

    2008-12-11 15:54:24

    本文出自51Testing软件测试论坛,作者: jacky19840707   

    一个完整的Web安全体系测试可以从部署与基础结构,输入验证,身份验证,授权,配置管理,敏感数据,会话管理,加密,参数操作,异常管理,审核和日志记录等几个方面入手

      数据加密:某些数据需要进行信息加密和过滤后才能进行数据传输,例如用户信用卡信  息、用户登陆密码信息等。此时需要进行相应的其他操作,如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多,越来越复杂,但一般数据加密的过程时可逆的,也就是说能进行加密,同时需要能进行解密!

      登录: 一般的应用站点都会使用登录或者注册后使用的方式,因此,必须对用户名和匹配的密码进行校验,以阻止非法用户登录。在进行登陆测试的时候,需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制,最多可以尝试多少次登录,哪些页面或者文件需要登录后才能访问/下载等。

      超时限制:WEB应用系统需要有是否超时的限制,当用户长时间不作任何操作的时候, 需要重新登录才能使用其功能。

      SSL:越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写,是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。(RSA),在位于HTTP层和TCP层之间,建立用户与服务器之间的加密通信,确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的,任何用户都可以获得公共密钥来加密数据,但解密数据必须要通过相应的私人密钥。进入一个SSL站点后,可以看到浏览器出现警告信息,然后地址栏的http变成 https,在做SSL测试的时候,需要确认这些特点,以及是否有时间链接限制等一系列相关的安全保护。

      服务器脚本语言:脚本语言是常见的安全隐患。每种语言的细节有所不同。有些   脚本允许访问根目录。其他只允许访问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

      注:黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。这个网站包含了脚本代码(有允许访问根目录的特性)就可能有这个安全隐患。

      日志文件:在服务器上,要验证服务器的日志是否正常工作,例如CPU的占用率是否很高,是否有例外的进程占用,所有的事务处理是否被记录等。

      目录:WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当,通过简单的URL替换和推测,会将整个WEB目录完全暴露给用户,这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式,如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限,将这种隐患降低到最小程度。

  • 纪念

    2008-11-04 21:06:27

       学习软件测试的路还很漫长...努力ing

数据统计

  • 访问量: 3336
  • 日志数: 6
  • 建立时间: 2008-11-04
  • 更新时间: 2008-12-11

RSS订阅

Open Toolbar