PMP ,专注于WEB功能测试、性能测试、安全测试的研究,从事全面质量管理工作。曾任多家公司测试经理、测试主管。在电子政务、银行、电商、跨境电商、直播电商领域工作多年,曾获得某龙头集团公司公测一等奖,曾任职某头部直播电商公司测试团队负责人,具有业务敏感性,擅长从0到1搭建测试团队,具有海外工作经历,以及质量管理体系搭建。邮箱:89233502@qq.com

发布新日志

  • WEB 项目测试实战例子

    2013-12-13 09:43:39

      WEB 项目测试实战  
    http://pan.baidu.com/share/link?uk=3274830006&shareid=3607796718

    http://pan.baidu.com/share/link?uk=3274830006&shareid=2457564458
  • windows 性能监视器常用指标分析【转】

    2013-06-25 08:46:40

    怀疑内存不足时:
    方法1:
    【监控指标】:Memory Available MBytes ,Memory的Pages/sec, page read/sec, Page Faults/sec
    【参考值】:
    如果 Page Reads/Sec 比率持续保持为 5,表示可能内存不足。
    Page/sec 推荐00-20(如果服务器没有足够的内存处理其工作负荷,此数值将一直很高。如果大于80,表示有问题)。

    方法2:根据Physical Disk 值分析性能瓶颈
    【监控指标】:Memory Available MBytes ,Pages read/sec,%Disk Time 和 Avg.Disk Queue Length
    【参考值】:%Disk Time建议阈值90%
            当内存不足时,有点进程会转移到硬盘上去运行,造成性能急剧下降,而且一个缺少内存的系统常常表现出很高的CPU利用率,因为它需要不断的扫描内存,将内存中的页面移到硬盘上。

    怀疑内存泄漏时
       【监控指标】:Memory Available MBytes ,Process/Private Bytes和Process/Working Set,PhysicalDisk/%Disk Time
    【说明】: 
    Windows资源监控中,如果Process/Private Bytes计数器和Process/Working Set计数器的值在长时间内持续升高,同时Memory/Available bytes计数器的值持续降低,则很可能存在内存泄漏。内存泄漏应该通过一个长时间的,用来研究分析当所有内存都耗尽时,应用程序反应情况的测试来检验。

    CPU分析
    【监控指标】:
    System %Processor Time CPU,Processor %Processor Time CPU
    Processor%user time 和Processor%Privileged Time
    system/Processor Queue Length
    Context Switches/sec 和%Privileged Time
    【参考值】: 
    System/%Total processor time不持续超过90%,如果服务器专用于SQL Server,可接受的最大上限是80-85% ,合理使用的范围在60%至70%。
    Processor %Processor Time小于75%
    system/Processor Queue Length值,小于CPU数量的总数+1

    CPU瓶颈问题
    1:System/%Total processor time如果该值持续超过90%,且伴随处理器阻塞,则说明整个系统面临着处理器方面的瓶颈.
    注: 在某些多CPU系统中,该数据虽然本身并不大,但CPU之间的负载状况极不均衡,此时也应该视作系统产生了处理器方面的瓶颈.
    2:排除内存因素,如果Processor %Processor Time计数器的值比较大,而同时网卡和硬盘的值比较低,那么可以确定CPU 瓶颈。(内存不足时,有点进程会转移到硬盘上去运行,造成性能急剧下降,而且一个缺少内存的系统常常表现出很高的CPU利用率,因为它需要不断的扫描内存,将内存中的页面移到硬盘上。)

    造成高CPU使用率的原因:
    频繁执行程序,复杂运算操作,消耗CPU严重
    数据库查询语句复杂,大量的 where 子句,order by, group by 排序等,CPU容易出现瓶颈
    内存不足,IO磁盘问题使得CPU的开销增加

    磁盘I/O分析
    【监控指标】:PhysicalDisk/%Disk time,PhysicalDisk/%Idle Time,Physical Disk/ Avg.Disk Queue Length, Disk sec/Transfer
    【参考值】:%Disk Time建议阈值90%

    Windows资源监控中,如果% Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。
    Processor%Privileged Time该参数值一直很高,且如果在 Physical Disk 计数器中,只有%Disk time 比较大,其他值都比较适中,硬盘可能会是瓶颈。若几个值都比较大, 那么硬盘不是瓶颈。若数值持续超过80%,则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值(Processor%Privileged Time)也一直很高, 则考虑使用速度更快或效率更高的磁盘子系统。

    Disk sec/Transfer 一般来说,该数值小于15ms为最好,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了

  • 基于Selenium2与Python自动化测试环境搭建

    2012-07-04 18:29:29

    • 基于Selenium2与Python自动化测试环境搭建

      工具选择

      Python版本: 选择2.7.2, Why? 目前大部分第三方库和工具对2.7都有简单的安装包,不需要自己做太多处理,比2.6内置了一些包,不需要再安装; Python3.x不支持Se2.0

      Selenium版本:选择2.0+,Why? 因为从2.0开始,Se已经和WebDriver集成在一起了,WebDriver提供了非常多的API和自动化测试处理方法。

      脚本开发:Eclipse(JDK:选择1.6版本),其中插件选择:PyDev

      代码库管理:SVN,使用SVN对整个框架下的内容进行版本管理

       

      环境搭建步骤(WindowsXP, 32位)

      第一步:安装Python

      根据下面的地址,直接一键安装,全部默认方式。

      下载地址:http://www.python.org/ftp/python/2.7.2/python-2.7.2.msi

      然后设置Python的环境变量, Path:“C:\Python27;”

      Windows下安装配置python

      分类:python31人阅读评论(0)收藏举报

      Windows不像ubuntu那样方便,不能直接使用一条命令就下载安装好python,所以得一步一步手工来进行

      1. 下载python

           这是官方下载的链接(2.x或者3.x均可) 

           http://www.python.org/getit/

      2. 安装

           安装就不多说了,默认安装的路径是C:\Python27(以python2.7为例)

      3. 环境变量

           python也要配置环境变量,不过比Java简单多了,windows7下:计算机->属性->计算机名称、域和工作组设置(更改设置)->高级->环境变量,在变量PATH中加入C:\Python27,即之前的安装路径。

      4. 测试安装是否成功

          打开cmd,输入python,回车,看是否能够进入python终端

       

      第二步:安装Python的SetupTools

      其实SetupTools就是一个帮助你安装第三方工具包的增强工具软件,根据下面的地址下载,然后一键安装。下载地址:

      http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11.win32-py2.7.exe#md5=57e1e64f6b7c7f1d2eddfc9746bbaf20

      第三步:安装Python的包管理工具 pip—有点类似SetupTools ,但是比它强大

        利用第二步安装的SetupTools进行安装,打开DOS界面,进入到目录:

      C:\Python27\Scripts, 然后敲入命令: easy_install pip, 等待完成就OK。

        第四步:安装基于Python的Selenium包

      打开DOS界面,进入到目录: C:\Python27\Scripts,

      然后敲入命令: pip install selenium or pip install –U selenium,其中:里面一些警告可以暂时不用管,如果想找到原因,Pls 百度 or 谷歌 一下!

      注:关于网上的有一段环境搭建步骤描述,那个是指支持Se1.0版本的,2.0版本不需要那个启动server-jar文件

        第五步:验证Selenium安装是否成功

           在记事本中编写下面的代码:(保存为 pytest.py,然后直接运行即可!)

      如果代码运行成功,就表示Selenium安装成功了! Very Good!

        第六步:python的开发环境配置-Eclipse-PyDev插件安装

      关于这个插件的安装,就不多说了!网上很多!可以看看下面的链接
      http://www.cnblogs.com/Realh/archive/2010/10/04/1841907.html

      但是注意:网上的这个是以Python2.6为例讲解的,咱们安装的是2.7版本

       

       

      具体DOS命令:windows +r 进入dos界面

      c:\users\mxc>c:
      c:\users\mxc\cd\
      c:\>dir

      c:\>cd python27
      c:\python27>

      c:\python27>cd scripts
      c:\python27\scripts>easy_install pip

      ..................

      参考以上dos命令格式

  • IECollection 兼容性测试工具

    2011-09-15 18:07:41

    看名字便可以知道,又是一个整合版本的IE,可以说它就是Multiple IE的新兄弟,因为它们实在是太像了,只是Multiple IE有些更新的嫌疑,而IECollection的更新速度会让我们惊讶,刚出IE8 Beta 2,IECollection已经进行了整合。

    Internet Explorer Collection contains the following versions of IE:
    - Internet Explorer 1.0 (4.40.0.308)
    - Internet Explorer 1.5 (0.1.0.10)
    - Internet Explorer 2.01 (2.1.0.46)
    - Internet Explorer 3.0 (3.0.1152)
    - Internet Explorer 4.01 (4.72.3110.0)
    - Internet Explorer 5.01 (5.00.3314.2100)
    - Internet Explorer 5.5 (5.51.4807.2300)
    - Internet Explorer 6.0 (6.00.2800.1106)
    - Internet Explorer 7.0 (7.0.5730.13)
    - Internet Explorer 8.0 (8.0.6001.18241)

    Warning: Never use Internet Explorer as primary browser.

    官方:http://finalbuilds.edskes.net/iecollection.htm

    下载:Internet Explorer Collection 1.1.0.0 (43.0 MB, 45.154.305 bytes)

    截图:

    IE_Collection

    安装

    IE_Collection_2 

    快捷方式(其中和一个为IE6绿色版的图标)

    IE_Collection_3

    使用效果(IE6、IE7、IE8)

    下载:http://jsufly.javaeye.com/blog/634893

    文章引用地址:http://www.iefans.net/ie6-ie7-ie8-ieduobanben/ 作者:iefans

    提示  装ghost 系统的同学 就不要用了   装了后 IE 会有问题   

  • 如何进行WEB测试2

    2010-05-17 18:15:00

    和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

    4.6 组合测试

    最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错,但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示,但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点,测试可能会轻松一些。如果公司指定使用某个类型的浏览器,那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线,可能不需要测试下载施加。(但需要注意的是,可能会有员工从家里拨号进入系统) 有些内部应用程序,开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是,理想的情况是,系统能在所有机器上运行,这样就不会限制将来的发展和变动。

    采取措施:根据实际情况,采取等价划分的方法,列出兼容性矩阵

    5 安全测试

    即使站点不接受信用卡支付,安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露,客户在进行交易时,就不会有安全感。

    5.1 目录设置

    Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html main.html 页面,这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片,单击鼠标右键,找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径,发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ,点击 jackpot。在该目录下有很多资料,其中引起我注意的是已过期页面。该公司每个月都要更改产品价格,并且保存过期页面。我翻看了一下这些记录,就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息,他们在谈判桌上肯定处于上风。

    5.2 SSL

    很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息,而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?

    5.3 登录

    有些站点需要用户进行登录,以验证他们的身份。这样对用户是方便的,他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录,而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面?

    Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

    5.4 日志文件

    在后台,要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

    5.5 脚本语言

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

    6 接口测试

    在很多情况下,web 站点不是孤立。Web 站点可能会与外部服务器通讯,请求数据、验证数据或提交订单。

    6.1服务器接口

    第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务,然后查看服务器记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。

    这种测试可以归到功能测试中的表单测试和数据校验测试中

    6.2 外部接口

    有些 web 系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡, 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别,例如 3 表示 American Express4 表示 Visa5 表示 Mastercard6 代表Discover)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。  

    这种情况在远程抄表中可能会体现到

    6.3 错误处理

    最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?如果用户自己中断事务处理,在订单已保存而用户没有返回网站确认的时候,需要由客户代表致电用户进行订单确认。

    采取措施:在理解需求的基础上,充分发挥想象力,尽量比较全面的列出各种异常情况

    7 结论

    无论你在测试 internetintranet 或者是 extranet 应用程序,web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下,就像业务功能一样,页面用于维护和发展公共关系,所以第一印象非常重要。

  • 如何web项目测试1

    2010-05-17 17:28:28

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

    本文将 web 测试分为 6 个部分

    • 功能测试
    • 性能测试(包括负载/压力测试)
    • 用户界面测试
    • 兼容性测试
    • 安全测试
    • 接口测试

    本文的目的是覆盖 web 测试的各个方面,未就某一主题进行深入说明。

    1 功能测试

    1.1 链接测试

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

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

     

    采取措施:采用自动检测网站链接的软件来进行。

    推荐软件:

    Xenu Link Sleuth 免费 绿色免安装软件

    HTML Link Validator 共享(30天试用)

     

    1.2 表单测试

    当用户通过表单提交信息的时候,都希望表单能正常工作。

    如果使用表单来进行在线注册,要确保提交按钮能正常工作,当注册完成后应返回注册成功的消息。如果使用表单收集配送信息,应确保程序能够正确处理这些数据,最后能让顾客能让客户收到包裹。要测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息。

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

    1.3 数据校验

    如果系根据业务规则需要对用户输入进行校验,需要保证这些校验功能正常工作。例如,省份的字段可以用一个有效列表进行校验。在这种情况下,需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值,确定系统能够接受这个测试值)

    在测试表单时,该项测试和表单测试可能会有一些重复。

    1.21.3的采取措施:第一个完整的版本采用手动检查,同时形成WinRunnerQTP)脚本;回归测试以及升级版本主要靠WinRunnerQTP)自动回放测试。

    1.4 cookies测试

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

      如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息,请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数,需要验证次数累计正确。

    采取措施:

           1 采用黑盒测试:采用上面提到的方法进行测试

    2 采用查看cookies的软件进行(初步的想法)

    可以选择采用的软件

    IECookiesView v1.50

    Cookies Manager v1.1

          

    1.5 数据库测试

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

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

    采取措施:暂时没有更好的测试方法

           考虑结合到1.21.3的测试中

     

    1.6 应用程序特定的功能需求

    最重要的是,测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作:下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因,一定要确认网站能像广告宣传的那样神奇。

    采取措施:深刻理解需求说明文档

    1.7 设计语言测试

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

    暂时没有方法测试,可以多参考一点讨论组内的更新信息

    2 性能测试

    2.1 连接速度测试

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

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

    2.2 负载测试

     

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

    2.3 压力测试

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

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

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

     

    负载/压力测试应该关注什么

    测试需要验证系统能否在同一时间响应大量的用户,在用户传送大量数据的时候能否响应,系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到系统忙的信息,他们可能放弃,并转向竞争对手。系统检测不仅要使用户能够正常访问站点,在很多情况下,可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因,测试人员应该知道当系统过载时,需要采取哪些措施,而不是简单地提升系统性能。

    瞬间访问高峰
    如果您的站点用于公布彩票的抽奖结果,最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

    每个用户传送大量数据
    网上书店的多数用户可能只订购 1-5 书,但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

    长时间的使用
    如果站点用于处理鲜花订单,那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 webemail 服务,那么点最好能持续运行几个月,甚至几年。可能需要使用自动测试工具来完成这种类型的测试,因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常,测试工具在第二次使用的时候,它创造的效益,就足以支付成本。而且,测试工具安装完成之后,再次使用的时候,只要点击几下。

    采取措施:采用测试工具WAS、ACT协助进行测试

    3 用户界面测试

    3.1 导航测试

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

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

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

      Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    3.2 图形测试

    Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

      (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

      (2)验证所有页面字体的风格是否一致。

      (3)背景颜色应该与字体颜色和前景颜色相搭配。

      (4)图片的大小和质量也是一个很重要的因素,一般采用JPGGIF压缩,最好能使图片的大小减小到 30k 以下

     

    5)最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

     

    通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。另外,图案和图片可能会转移用户的注意力。

    3.3内容测试

    内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

      信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"

    对于开发人员来说,可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能,然后开始开发,在开发的时候,开发人员可能不注重文字表达,他们添加文字可能只是为了对齐页面。不幸的是,这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则,公司可能陷入麻烦之中,也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时,最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章,所以相信您也希望自己的站点能更专业一些。 最后,需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址,或者从某个站点下载浏览器。但是如果用户无法点击这些地址,他们可能会觉得很迷惑。

    3.4 表格测试

    需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一格的内容太多,而将整行的内容拉长?

    3.5 整体界面测试

    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

      对所有的用户界面测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

     

    采取措施:手动测试,参与人员最好有外部人员

    4 兼容性测试

    4.1 平台测试

    市场上有很多不同的操作系统类型,最常见的有WindowsUnixMacintoshLinux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

      因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

    4.2 浏览器测试

    浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript ActiveX plug-ins或不同的HTML规格有不同的支持。例如,ActiveXMicrosoft的产品,是为Internet Explorer而设计的,JavaScriptNetscape的产品,JavaSun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

      测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

     

    4.3 分辨率测试

    页面版式在 640x400600x800 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

    4.4 Modem/连接速率

    是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候,可能会等待比较长的时间,但却不会耐心等待首页的出现。最后,需要确认图片不会太大。

    4.5 打印机

    用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题,注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕,因此需要验证网页打印是否正常。有时在屏幕上显示的图片和

  • 如何测一个门户网站是否支持10万用户同时在线

    2008-11-17 11:01:22

    这个帖子的内容比较典型,大家有兴趣可以也思考一下。帖子源于51testing论坛

    先是楼主提出问题:
    最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案
    一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略)
    一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)
    还有一种则需要测试服务器能否接受10万用户同时在线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案?


    后面跟着大家的回复:

    网友 xingcyx 的回复:
    1、找10台电脑也没用,license仍然只支持10000个。
    2、找HP支持。当然,前提是你有足够的钱。
    3、测到10000用户并发。我认为,通常情况下10000用户并发,支持100000用户在线,没有问题的。


    网友 jackloo 的回复:
    总的来说这一类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求。
    如果是用IIS做应用服务器的话,单台可承受的最大并发数不可能达到10万级,那就必须要使用集群,通过多台机器做负载均衡来实现;
    如果是用websphere之类的应用服务器的话,单台可承受的最大并发数可以达到10万级,但为性能考虑还是必须要使用集群,通过多台机器做负载均衡来实现;
    那么,你只要集群的服务器足够多,10万并发数当然可以达到了。
    通常有1个简单的计算方式,1个连接产生1个session,每个session在服务器上有个内存空间大小的设置,在NT上是3M,那么10万并发就需要300G内存,当然实际使用中考虑其他程序也占用内存,所以准备的内存数量要求比这个还要多一些。
    还有10万个用户同时在线,跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢?
    这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息,还需要有用户操作次数的日志信息,这2个数据的比例就是你同时在线用户转换到并发数的比例。
    另外根据经验统计,对于1个JAVA开发的WEB系统(别的我没统计过,给不出数据),一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过 500个(这个状态下大部分操作都是超时报错而且服务器很容易宕机,其实没什么实际意义),可正常使用(单步非大数据量操作等待时间不超过20秒)的最大并发数不超过300个。
    假设你的10万同时在线用户转换的并发数是9000个,那么你最少需要这样的机器18台,建议不少于30台。
    当然,你要是买个大型服务器,里面装有200个CPU、256G的内存,千兆光纤带宽,就算是10万个并发用户,那速度,也绝对是嗖嗖的。


    楼主的回复:
    谢谢jackloo !
    再请问如果我想测试10000个用户同时在线做常用操作的话(每两秒加一个用户,一直加到10000),对服务器的要求有多高?

    网友 jackloo 的回复:
    套用1句经典台词“高,实在是高”
    呵呵。另外暴寒1下,你的设置光全部进入运行状态就需要接近6个小时。
    具体的你可以拿1个系统来压一下看看,可能会出现以下情况:
    1。服务器宕机;
    2。客户端宕机;
    3。从某个时间开始服务器拒绝请求,客户端上显示的全是错误;
    4。勉强测试完成,但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽,百兆/10000=10K,那每个用户只能得到10K,这个速度接近1个64K的MODEM上网的速度;
    另外以上分析全都没考虑系统的后台,比如数据库、中间件等。
    我从没遇到你说的这样的性能需求过,也只好凭感觉随便掰掰:
    1。服务器方面:上面说的那样的PC SERVER需要50台;
    2。网络方面:按每个用户50K,那至少5根百兆带宽独享,估计仅仅网络延迟就大概是秒一级的;
    3。如果有数据库,至少是ORACLE,最好是SYSBASE,SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器;
    4。如果有CORBA,那至少再准备10台4CPU、16G内存的机器;
    再加上负载均衡、防火墙、路由器和各种软件等,总之没个1000万的资金投入,肯定搞不定。

    网友 mybasswood 的回复:
    如果是10万用户的话要看做些什么哈.
    比如对于voip来说,假设有10万用户的话,服务器规定每个client至少要在3600秒内到服务器成功报到一次,否则就被服务器cancel掉.
    client是每隔60秒注册一次.
    所以就要推算在3600秒内,每一个client至少成功报到一次是最少的标准.要10万用户在3600秒内被服务器吃掉才可以---这是最低要求.
    最高要求是: 在60秒内所有的10万用户去注册,如果服务器在60秒可以都吃掉的话,每秒种的平均并发差不多是3334.
    最低要求是:在3600秒内所有的10用户去注册,如果服务器在3600秒内都可以吃掉的话,每秒钟的平均并发用户差不多是60个.还有一过问题是客户端要在3600秒内发送至少60次,至少有一次成功.再加上这些用户分布在全球各地的话,这样数值应该还会有变化的.



    下面是偶的看法:
    给楼主一个建议吧。

    你在公司中的测试环境是一定的,你需要做得是现在这个环境中确认一下系统在当前环境下的实际处理能力。如果还有资源,再做一下可伸缩性的测试。
    然后对测试结果进行分析,对系统的处理能力和可伸缩性做一个描述。

    当然,要在报告中说明你的测试环境。


    另外一位网友robust 的留言:
    你的意思是否想用10000个用户测试结果来推测一下10万个用户?
    还是如有些老兄说的,测试一下什么伸缩性测试.然后也来个报告,无非也是想用1万个来推测10万个的情况?(评注:那样的话要你做什么性能测试,只要计算一下就可以得性能结果了.)
    还是如有些老兄说的,这一类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求?(评注:那样的话要你做什么性能测试,做什么性能调优,只要计算一下,添加硬件就可以了.)
    实际上,"实践是检验真理的唯一标准!"这句话才是硬道理.只有真实地测试过才知道.任何推测只是推测,并不能反映真实的情况.
    至于性能测试工具,LR只是普及率高(市场占有率高),并不是在性能指标上有优势.世界上比它厉害的工具有不少,举个例子siprent通信公司的avalanche2500,大型计算机实验室配备的性能测试工具.支持录制/回放,测试结果分析等.它可以模拟从数据层到应用层的协议,(当然也包含http-web),单个支持100万并发连接.拿它也可以测试100万级的并发性能.



    又是偶的回复:
    楼上的提到的见解不错,不过对性能测试的理解有些偏差。

    先抛开性能测试工具不谈,其实这个问题是讨论到一个性能测试到底该怎么做。

    简单举个例子,如果你想知道一种新的疫苗对人的作用,是不是要把所有的地球人全部找来每个人打一针试试呢?当然不是,只能是通过试验和抽样,然后通过统计学的方法来计算出一个模型,通过样本的表现来估算总体的特征。这就是统计学研究的领域,。不过请注意,统计学所包含的内容并不是像楼上的老兄所说的一样:只要计算一下就可以得性能结果了。

    性能测试也同样如此。

    楼主提到的性能需求应该是系统上线以后可能要面临的压力,先不讨论这个需求是否准确和有效,我们先假定它是有效的。那么,既然要验证的是系统在上线以后是否有能力应对10万用户同时在线的情况,那么自然要用生产环境来测试。如果有,那么 OK,可以作这个测试。至于工具,其实可以由开发人员帮忙写一些简单的脚本负责加压,再通过其他第三方工具收集测试数据就是了。

    但是如果没有生产环境,只有一台双CPU,3G内存的 2850 服务器,怎么办?这就好像上面提到的例子。可行的方法是在这台服务器上使用不同级别的负载来进行测试,并根据测试数据获得系统在这种环境下的最佳负载和最大负载,并根据测试数据对负载和资源消耗的情况进行估算,找到它们之间的关系。

    一般来说,大型的门户网站不会只用一台超级超级的服务器来承担所有的负载,因为采用负载均衡和集群技术可以更好的解决这个问题,一定是多台服务器分布在不同的地方,内容通过内容分发网络同步到各台服务器上。用户在访问时,其实是被应用层或者前端设备路由到一个合适的服务器去的。所以在测试时,对于可伸缩性的测试是必需的,一定要了解到 cluster 数量增加时,系统的响应能力是否可以线性的增加,也就是说是否可以承受更大的压力,为更多的用户提供服务。

    最后总结一下,对于性能测试,要作的是确认系统的响应能力,然后看系统是否可以满足性能需求。

    如果大家有不同的见解,欢迎 PK 讨论

    继续偶的回复:
    to jackloo


    你所提到的对于硬件资源和软件资源的要求并不完全准确。因为实际的资源消耗要根据网站所提供的业务类型来推算。
    对于大多数门户网站来说,可供访问的大多是静态页面。在用户访问时,系统只是返回一个静态页面给用户,并不需要保持 session,而且这种情况下负载主要集中在I/O和网络流量方面——这也是为什么大型门户网站都会采用分布式的方式来部署服务器。当然,如果使用了 cache,内存的使用会随着服务器运行时间的延长而增加,但是 CPU 通常不会成为关键资源。

    这是门户网站同企业应用或者在线游戏的区别。

    还是偶:

    to 楼主

    上面我也提到了,你需要进一步的明确你的测试需求是否有效,合理。

    性能需求需要根据网站具体提供的业务类型来作为依据进行衡量。就如同上面提到的,是只提供了静态页面的访问?还是有其他的业务?

    要区分清楚注册用户、在线用户和并发用户的区别。

    另外,你最迫切需要担心的并不应该是 LR 的 license 问题,而是被测的系统能否支持的了几百或者几千并发用户,如果连这个都支持不了,就更不用考虑上万的并发访问了。


    希望大家有不同的看法和意见都可以写下来,大家一起讨论,共同进步

  • 故障转移和恢复测试

    2008-10-16 22:21:43

     

    故障转移和恢复测试可确保测试对象能成功完成故障转移,并从硬件、软件或网络等方面的各种故障中进行恢复,这些故障导致数据意外丢失或破坏了数据的完整性。

    故障转移测试可确保:对于必须始终保持运行状态的系统来说,如果发生了故障,那么备选或备份的系统就适当地将发生故障的系统“接管”过来,而且不会丢失任何数据或事务。

    恢复测试是一种相反的测试流程。其中,将应用程序或系统置于极端的条件下(或者是模仿的极端条件下),以产生故障,例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字。启用恢复流程后,将监测和检查应用程序和系统,以核实应用程序或系统是正确无误的,或数据已得到了恢复。

    测试目标:确保恢复进程(手工或自动)将数据库、应用程序和系统正确地恢复到了预期的已知状态。测试中将包括以下各种情况:

    1、客户机断电

    2、服务器断电

    3、通过网络服务器产生的通信中断

    4、DASD 和/或 DASD 控制器被中断、断电或与 DASD 和/或DASD 控制器的通信中断

    5、周期未完成(数据过滤进程被中断,数据同步进程被中断)。

    6、数据库指针或关键字无效

    7、数据库中的数据元素无效或遭到破坏

    测试方法:

    应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点,就应该分别执行或模拟以下操作:

    1、客户机断电:关闭 PC 的电源。

    2、服务器断电:模拟或启动服务器的断电过程。

    3、通过网络服务器产生的中断:模拟或启动网络的通信中断(实际断开通信线路的连接或关闭网络服务器或路由器的电源)。

    4、DASD 和 DASD 控制器被中断、断电或与 DASD 和DASD 控制器的通信中断:模拟与一个或多个 DASD 控制器或设备的通信,或实际取消这种通信。

    一旦实现了上述情况(或模拟情况),就应该执行其他事务。而且一旦达到第二个测试点状态,就应调用恢复过程。

    在测试不完整的周期时,所使用的方法与上述方法相同,只不过应异常终止或提前终止数据库进程本身。

    对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时,应该以手工方式在数据库中(通过数据库工具)直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行,并且应执行完整的周期。

    完成标准:在所有上述情况中,应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏,以及表明进程或事务因中断而未被完成的报表。

    需考虑的特殊事项:

    1、恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法(模拟断电或通信中断)可能并不可取或不可行。所以,可能会需要采用其他方法,例如诊断性软件工具。

    2、需要系统(或计算机操作)、数据库和网络组中的资源。

    3、这些测试应该在工作时间之外或在一台独立的计算机上运行。
  • 31个用来测试你网站各项性能的免费在线工具

    2008-10-16 13:28:59

     你是否肯定你的网站完全兼容各大浏览器?是否知道多少秒可以打开你的网站? 是否可以自信地说你的网站根本就没有打不开的时候? 是否……

      虽然它看似不重要,但这些在一定程度上也对你的网站的访问量产生了影响 ( 其它一部分影响浏览量的原因及解决办法 )。这里列出了一份31个我最喜爱的免费在线测试工具,你可以通过这些工具来测试你的网站,并根据结果对你的网站进行修改。

      网站代码验证没人可以细致到保证自己的网站代码都是正确的,你可以通过以下测试来验证网站代码是否正确。

      1 . WDG HTML Validator

      一个很好的工具,能找出网站语法错误的地方,并标注出来,也可选择对网站上单独的每一页进行单页分析。(强烈推荐)

      2 . W3C Markup Validation Service

      对 HTML 和 XHTML 都能进行代码测试,自称是互联网络上第一个(也是使用者最多的)的 HTML 验证工具。

      3 . W3C CSS Validation Service

      用于验证 css 源代码,能够标注出不好的 css 代码设计。例如:“Same colors for color and background-color in two contexts”。

      4 . RUWF XML Syntax Checker

      用于查找 XML 文件的错误。

      5 . W3C Feed Validation Service

      用于查找 Atom 和 RSS feed 中的错误语法。(这个我经常用到)

      6 . W3C Link Checker

      用于搜寻查明你网站内的所有链接里是否有断链。(强烈推荐)

      7 . Juicy Studio Link Analyser

      测试网站内的链接的 URL 是否存在死链,与 W3C Link Checker 很类似。网站的使用性我们常常看到网站设计者把重点放在怎网站的吸引力上,而完全不考虑会不会影响来访者的使用,一个浏览难度很大的网页是注定要失败,要让你的来访者方便的得到他要的信息(从而成为重复访客),你的网站应当遵循 WCAG section 508 易用性规则。

      8 . Watchfire WebXACT

      所有严谨的设计师和开发者都必须使用的工具,它会生成一个非常详尽的报告书,包括:网站质量,易用性和隐私等。(强烈推荐)

      9 . ATRC Web Accessibility Checker

      测试网站的 WCAG 2.0 Level2 兼容性,它会生成一份报告,提出一系列建议,如:如何提升页头,链接,数据,图表和文字的访问速度。

      10 . WAVE 3.0 Web Accessibility Tool

      高度可定制的工具,它采用了图形化模型展示网站兼容性问题( WCAG 1.0 and section 508 )。(强烈推荐)

      11 . TAW Web Accessibility

      Test测试网页是否存在冲突( WCAG 1.0 兼容性 ),通过图形模式生成一份依据 wcag 优先模式为基础的网站修改建议。

      12 . HiSoftware CynthiaSays portal

      采用了非常严格的规则来测试网页( 根据 section 508 和 WCAG 1.0 规则 ),生成的报告也极为详细( 详细到很难看懂 )。

      13 . HERA Accessibility testing with Style

      使用一种极为复杂但容易理解方式指出网页的 wcag1.0 兼容性问题。

      14 . Juicy Studio CSS Analyser

      进行了色彩对比测试,以确保你的网站的色调会符合 WCAG 1.0 的要求。

      15 . Juiciy Studio Readability Test

      分析你网站上的文字是否有语法错误或拼写错误等问题,容易让人理解不( 根据 the Flesch Reading Ease 和 Flesch-Kincaid grade level algorithms 规则 )。( 适合英文网站使用)网站的速度打开你的网站的速度快慢,是来访者会不会再次访问网站的关键因素,在一般情况下,一个网络不是很快的来访者是不愿意访问一个充满着图片、 flash 动画、多媒体文件的网站。为了使你的网站覆盖人群的范围最大化,你必须优化你的网站,使它的打开速度尽可能的快。

    16 . Web Page Analyzer from Website Optimization

      一个很好的工具,它在分析完一个网页后,会为减少加载时间提出优化建议,着重优化物体的数目,图片和网站的总体大小。(强烈推荐)

      17 . WebSitePulse Test Tools

      有一系列的工具来确定网站的加载速度和主机信息。

      18 . Internet Supervision Url Check

      从世界各地不同的服务器来测试你的网站的加载时间,用于确定是不是各地的来访者都能顺利快速的打开你得网站。
      浏览器模拟工具这是一个普遍的问题,因为现在有着很多的操作系统和浏览器,你得网站必须得兼容它们,但这绝不是一件容易的事。通过下列工具,你可以了解你得网站在各种浏览器上的显示效果。

      19 . Browsershots

      能给出你的网站在不同浏览器下显示效果的截图,包括:Firefox 和 Internet Explorer ( Windows )、Firefox 和 Safari ( Mac OS X )、Iceweasal 和 Konqueror ( Linux ),但是结果要在 1 - 3 小时后才能出来。

      20 . IE NetRenderer

      实时生成你的网站在 Internet Explorer 5.5 、6.0 和 7.0 下的截图。

      21 . MobiReady Report

      分析使用手机访问网页的兼容性问题,会生成一份详细的报告,并提供了在两种不同类型的手机浏览器上你得网站可能显示的样子。
      搜索引擎优化 (SEO) 一个网站,如果对搜索引擎有着比较好的友好度,一定会比较有竞争力。

      22 . UrlTrends

      会显示网站的访客是如何通过搜索引擎来到你的网站,还有各个流量是多少。这些数据是包括 Google, Yahoo, MSN, Alexa, AlltheWeb, AltaVista 和其他一些网站。( 强烈推荐)

      23 . iWEBTOOL Backlink Checker

      一个很好的工具,它能找出有什么站点链接到你的站点,那些站点是什么类型的站点。

      24 . iWEBTOOL Multi-Rank Checker

      显示你网站的 Alexa 和 Google PageRank 数值。

      25 . Microsoft adCenter Labs: Advertising and Keyword Research Tools

      一个极好的工具,用于分析和预测你网站的来访者和市场。(强烈推荐 )

      26 . Domain Tools Whois lookup

      一个 WHOIS 网络工具。

      27 . SEO-Browser

      可以让你看到在搜索引擎眼里一样的网站( 去掉所有的”美丽”配件)。

      28 . SEO Workers SEO Analysis Tool

      非常有用的工具,分析了网站上的各种分类特征,包括 meta 标签、关键字密度及加载时间。(强烈推荐 )

      29 . Seekport Seekbot

      可以分析网站的数据和内容,以得出搜索引擎会如何有效的解释分析的网站。

      30 . SEO Chat SEO Tools

      用以分析网站 Google adsense 盈利潜力,关键字密度,Meta tag 等等……

      31 . Marketleap Search Engine Marketing Tools

      用来分析网页,让你知道你的网站检索、设定的关键字好不好。


  • 网站安全性测试

    2008-10-16 13:21:40

    • 个人认为网站安全测试应分为两部分:安全体制测试和应用与传输安全测试。以下为简单说明:

        一.安全体制测试

        1.部署与基础结构

        网络是否提供了安全的通信。

        部署拓扑结构是否包括内部防火墙。

        部署拓扑结构中是否包括远程应用程序服务器。

        基础结构安全性要求的限制是什么。

        目标环境支持怎样的信任级别。

        2.输入验证

        是否清楚入口点

        是否清楚信任边界

        是否验证web页输入

        是否对传递到组件或web服务的参数进行验证

        是否验证从数据库中检索的数据

        是否依赖客户端的验证

        应用程序是否易受规范化问题的影响

        应用程序是否易受SQL注入攻击

        应用程序是否易受XSS攻击

        3.身份验证

        是否区分公共访问和受限访问

        是否明确服务帐户要求

        是否在网络中传递明文凭据

        是否实现自己的用户存储

        是否使用表单身份验证

        是否使用SQL身份验证

        是否使用进程帐户

        是否使用服务帐户

        是否考虑使用匿名Internet用户身份

        是否使用原始用户身份

        如何保存数据库连接字符串

        是否强制使用强帐户管理措施

        4.授权

        是否使用深层防御策略

        使用了哪些网关守卫

        是否使用基于角色的方法

        角色是否提供足够的特权隔离

        设计是否使用代码访问安全性

        应用程序使用哪些身份

        5.配置管理

        是否支持远程管理

        是否保存配置存储的安全

        是否隔离管理员特权

        6.敏感数据

        是否存储机密信息

        是否在网络中传递敏感数据

        是否记录敏感数据

        7.会话管理

        如何交换会话标识符

        是否限制会话生存期

        如何确保会话状态存储的安全

        8.加密

        是否开发自己的加密技术

        是否使用合适的密钥大小来应用正确的算法

        如何确保加密密钥的安全性

        9.异常处理

        是否使用结构化的异常处理

        是否向客户端公开太多的信息

        10.审核和日志记录

        是否明确了要审核的关键活动

        是否考虑过如何流动原始调用者身份

        二.应用及传输安全

        1.注册与登录

        2.在线超时

        3.操作留痕

        4.备份与恢复

        5.HTTPS和SSL测试

        6.服务器端的脚本漏洞检验

        7.防火墙测试

  • WEB网站系统测试点

    2008-10-10 13:23:36

    感觉对WEB网站系统总结的很全哦,转载过来看一下

    1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文,中文字符显示为乱码;HTML Link Validater只能测试以Html或者htm结尾的网页链接;Xenu无需安装,支持asp、do、jsp等结尾的网页,xenu测试链接包括内部链接和外部链接,在使用的时候应该注意,同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试,也可以使用QTP的页面检查点检查链接。

    2. 相关性检查:

      Ø 功能相关性:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确,常见的情况是,增加某个数据记录以后,如果该数据记录某个字段内容较长,可能会在查询的时候让数据列表变形。

      Ø 数据相关性:下来列表默认值检查,下来列表值检查,如果某个列表的数据项依赖于其他模块中的数据,同样需要检查,比如,某个数据如果被禁用了,可能在引用该数据项的列表中不可见。

    3. 检查按钮的功能是否正确:如新建、编辑、删除、关闭、返回、保存、导入,上一页,下一页,页面跳转,重置等功能是否正确。常见的错误会出现在重置按钮上,表现为功能失效。

    4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的,有时候会出现,需求规定的字符串长度太短而无法输入业务数据。

    5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

    6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理,可能添加的时候,将空格当作一个字符,而在查询的时候空格被屏蔽,导致无法查询到添加的内容。

    7.特殊字符检查:输入特殊符号,如@、#、$、%、!等,看系统处理是否正确。常见的错误是出现在% ‘ \ 这几个特殊字符

    8. 中文字符处理: 在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

    9. 检查信息的完整性: 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查,有时候,会出现部分字段更新了而个别字段没有更新的情况。

    10. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    11. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。如果有多页,翻页选,看系统是否都正确删除,并且要注意,删除的时候是否有提示,让用户能够更正错误,不误删除。

    12. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

    13. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

    14. 重复提交表单:一条已经成功提交的纪录,返回后再提交,看看系统是否做了处理。对于Web系统来说,可以通过浏览器返回键或者系统提供的返回功能。

    15. 检查多次使用返回键的情况: 在有返回键的地方,返回到原来页面,重复多次,看会否出错。

    16. 搜索检查: 有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确,搜索的时候同样要注意特殊字符,某些系统会在输入特殊字符的时候,将系统中所有的信息都搜索到。

    17. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

    18. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。下载文件能否打开或者保存,下载的文件是否有格式要求,如需要特殊工具才可以打开等。上传文件测试同时应该测试,如果将不能上传的文件后缀名修改为可以上传文件的后缀名,看是否能够上传成功,并且,上传文件后,重新修改,看上传的文件是否存在。

    19. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加“*”;对必填项提示返回后,焦点是否会自动定位到必填项。

    20. 快捷键检查:是否支持常用快捷键,如Ctrl+C、 Ctrl+V、 Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

    21. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。

    22.刷新键检查:在Web系统中,使用浏览器的刷新键,看系统处理如何,会否报错。

    23.回退键检查:在Web系统中,使用浏览器的回退键,看系统处理如何,会否报错。对于需要用户验证的系统,在退出登录后,使用回退键,看系统处理如何;多次使用回退键,多次使用前进键,看系统如何处理。

    24.直接URL链接检查:在Web系统中,直接输入各功能页面的URL地址,看系统如何处理,对于需要用户验证的系统更为重要。如果系统安全性设计的不好,直接输入各功能页面的URL地址,很有可能会正常打开页面。

    25.空格检查:在输入信息项中,输入一个或连串空格,查看系统如何处理。如对于要求输入整型、符点型变量的项中,输入空格,既不是空值,又不是标准输入。

    26.输入法半角全角检查:在输入信息项中,输入半角或全角的信息,查看系统如何处理。如对于要求输入符点型数据的项中,输入全角的小数点(“。”或“.”,如4.5);输入全角的空格等。

    27.密码检查:一些系统的加密方法采用对字符Ascii码移位的方式,处理密码加密相对较为简单,且安全性较高,对于局域网系统来说,此种方式完全可以起到加密的作用,但同时,会造成一些问题,即大于128的Ascii对应的字符在解密时无法解析,尝试使用“uvwxyz”等一些码值较大的字符作为密码,同时,密码尽可能的长,如17位密码等,造成加密后的密码出现无法解析的字符。

    28.用户检查:任何一个系统,都有各类不同的用户,同样具有一个或多个管理员用户,检查各个管理员之间是否可以相互管理,编辑、删除管理员用户。同时,对于一般用户,尝试删除,并重建同名的用户,检查该用户其它信息是否重现。同样,提供注销功能的系统,此用户再次注册时,是否作为一个新的用户。而且还要检查该用户的有效日期,过了有效日期的用户是不能登录系统的。容易出现错误的情况是,可能有用户管理权限的非超级管理员,能够修改超级管理员的权限。

    29.系统数据检查:这是功能测试最重要的,如果系统数据计算不正确,那么功能测试肯定是通不过的。数据检查根据不同的系统,方法不同。对于业务管理平台,数据随业务过程、状态的变化保持正确,不能因为某个过程出现垃圾数据,也不能因为某个过程而丢失数据。

    30.系统可恢复性检查:以各种方式把系统搞瘫,测试系统是否可正常迅速恢复。

    31.确认提示检查:系统中的更新、删除操作,是否提示用户确认更新或删除,操作是否可以回退(即是否可以选择取消操作),提示信息是否准确。事前或事后提示,对于Update或Delete操作,要求进行事前提示。

    32.数据注入检查:数据注入主要是对数据库的注入,通过输入一些特殊的字符,如“’”,“/”,“-”等或字符组合,完成对SQL语句的破坏,造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from table where id = ‘ ’ and  name = ‘  ’,通过在id输入框中输入“12’-”,会造成查询语句把name条件注释掉,而只查询id=12的记录。同样,对于update和delete的操作,可能会造成误删除数据。当然还有其它一些SQL注入方法,具体可以参考《SQL应用高级SQL注入.doc》,很多程序都是基于页面对输入字符进行控制的,可以尝试跳过界面直接向数据库中插入数据,比如用Jmeter,来完成数据注入检查。

    33.刷新检查:web系统中的WebForm控件实时刷新功能,在系统应用中有利有弊,给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响(白屏),检查控件是否回归默认初始值,检查是否对系统的性能产生较大影响(如每次刷新都连接数据库查询等)。

    34.事务检查:对于事务性操作,断开网络或关闭程序来中断操作,事务是否回滚。

    35.时间日期检查:时间、日期验证是每个系统都必须的,如2006-2-29、2006-6-31等错误日期,同时,对于管理、财务类系统,每年的1月与前一年的12月(同理,每年的第1季度与前一年的第4季度)。另外,对于日期、时间格式的验证,如2006年2月28日、2006-2-28、20060228等。日期检查还要检查日期范围是否符合实际的业务,对于不符合时间业务的日期,系统是否会有提示或者有限制

    36.多浏览器验证:越来越多的各类浏览器的出现,用户访问Web程序不再单单依赖于Microsoft Internet Explorer,而是有了更多的选择:Maxthon、Firefox、Tencent Traveler等,考虑使用多种浏览器访问系统,验证效果。

    37.安装测试:对于C/S架构的系统,安装程序的测试是一个重要方面,安装程序自动化程度、安装选项和设置(验证各种方案是否都能正常安装)、安装过程中断测试、安装顺序测试(分布式系统)、修复安装及卸载测试。

    38.文档测试:主要是对用户使用手册、产品手册进行测试,校验是否描述正确、完整,是否与当前系统版本对照,是否易理解,是否二义性等。

    39.测试数据检查:事实告诉我们,测试数据比代码更有可能是错的,因此,当测试结果显示有错误发生的时候,怀疑代码错误前要先对测试数据检查一遍。

    40.请让我的机器来运行:在某些项目中,出现一个病态的问题:系统没有问题呀,它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG。“是否所有的一切都受到了版本控制工具的管理?”、“本机的开发环境和服务器的环境是否一样?”、“这里是否存在一个真正的BUG,只不过是在其他的机器里偶然出现?”。所有的测试必须在所有系统要求的机器上运行通过,否则的话,代码就可能存在问题。

    41.Ajax技术的应用:Ajax有很多优点,但也有很多缺点,如果利用优点、避免缺点,是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验,用户体验的效果直接关系到是否使用Ajax技术。“会做,并不意味着应该做、必须做”,这就是对Ajax技术的很重要的注解。

    42.Ajax技术的应用:Ajax采用异步调用的机制实现页面的部分刷新功能,异步调用存在异常中断的可能,尝试各种方法异常中断异步的数据调用,查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作,已经如果页面数据较多的时候的刷新。

    43.脚本错误:随着Ajax、IFrame等异步调用技术的发展,Javascrīpt技术也越来越受到开发人员的重视,但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题,因此在Web系统中,可能会出现脚本错误。同时,脚本错误造成的后果可大、可小,不能忽视。

  • Web性能测试术语

    2008-10-10 13:19:25

    WEB性能测试主要通过自动化的测试工具模拟多种正常,峰值以及异常负载条件来对系统的各项性能指标进行测试.WEB性能测试中出现频繁的术语主要有并发用户,并发用户数量,请求响应时间,事务响应时间,吞吐量,吞吐率,TPS,点击率,资源利用率等。

      并发用户:并发一般分为2种情况。一种是严格意义上的并发,即所有的用户在同一时刻做

    同一件事情或者操作,这种操作一般指做同一类型的业务。比如在信用卡审批业务中,一定数

    目的用户在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有用户进行完全一

    样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。

      另外一种并发是广义范围的并发。这种并发与前一种并发的区别是,尽管多个用户对系统

    发出了请求或者进行了操作,但是这些请求或者操作可以是相同的,也可以是不同的。对整个

    系统而言,仍然是有很多用户同时对系统进行操作,因此也属于并发的范畴。

      可以看出,后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况

    ,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发 ”。对于WEB性能测

    试而言,这2种并发情况一般都需要进行测试,通常做法是先进行严格意义上的并发测试。严格

    意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不是很大,但是一旦发

    生性能问题,后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来,因为并

    发功能遇到异常通常都是程序问题,这种测试也是健壮性和稳定性测试的一部分。

      用户并发数量:关于用户并发的数量,有2种常见的错误观点。一种错误观点是把并发用户

    数量理解为使用系统的全部用户的数量,理由是这些用户可能同时使用系统;还有一种比较接

    近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户

    发生并发,例如正在浏览网页的用户,对服务器没有任何影响,但是,在线用户数量是计算并

    发用户数量的主要依据之一。

      请求响应时间:指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中,请

    求响应时间通常会被成为"TLLB",即"Time to last byte",意思是从发起一个请求开始,到客

    户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为"秒"或者"

    毫秒"。

      事务响应时间:事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于

    宏观上的概念,是为了向用户说明业务响应时间而提出的。例如:跨行取款事务的响应时间就

    是由一系列的请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。

      吞吐量:指的是在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间,就

    是吞吐率。

      TPS:每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。

      点击率:每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标

    :WEB应用是"请求-响应"模式, 用户发出一次申请,服务器就要处理一次,所以点击是WEB应

    用能够处理的交易的最小单位。如果把每次点击定义为一个交易,点击率和TPS就是一个概念。

    容易看出,点击率越大,对服务器的压力越大。点击率只是一个性能参考指标,重要的是分析

    点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击

    操作中,客户端可能向服务器发出多个HTTP请求。

      资源利用率:指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率

    等。资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点

      资源利用率主要针对WEB服务器,操作系统数据库服务器,网络等,是测试和分析瓶颈的

    主要参考。在WEB性能测试中,更根据需要采集相应的参数进行分析。


Open Toolbar