综合

上一篇 / 下一篇  2007-06-06 17:31:46

Web 测试的经验

 

1.功能测试
1.1.链接测试
   链接是 Web 应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证 Web 应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的 URL 地址才能访问。
   链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个 Web 应用系统的所有页面开发完成之后进行链接测试。
1.2. 表单测试
   当用户给 Web 应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
1.3.Cookies测试
Cookies 通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用 Cookies 访问了某一个应用系统时, Web 服务器将发送关于用户的信息,把该信息以 Cookies 的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。
   如果 Web 应用系统使用了 Cookies ,就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用,是否按预定的时间进行保存,刷新对 Cookies 有什么影响等。
1.4.设计语言测试
Web 设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的 HTML 等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了 HTML 的版本问题外,不同的脚本语言,例如 Java 、 Javascrīpt 、 ActiveX 、 VBscrīpt 或 Perl 等也要进行验证。
1.5.数据库测试
   在 Web 应用技术中,数据库起着重要的作用,数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

在使用了数据库的 Web 应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
2.性能测试
2.1.连接速度测试
   用户连接到 Web 应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长(例如超过 5 秒钟),用户就会因没有耐心等待而离开。
   另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
2.2.负载测试
   负载测试是为了测量 Web 系统在某一负载级别上的性能,以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量,也可以是在线数据处理的数量。例如: Web 应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象? Web 应用系统能否处理大量用户对同一个页面的请求?
2.3.压力测试
  负载测试应该安排在 Web 系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个 Web 系统能同时处理的请求数量将远远超出这个限度,所以,只有放在 Internet 上,接受负载测试,其结果才是正确可信的。
   进行压力测试是指实际破坏一个 Web 应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试 Web 应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到 Web 应用系统崩溃,接着当系统重新启动时获得存取权。
   压力测试的区域包括表单、登陆和其他信息传输页面等。
3. 可用性测试
3.1.导航测试
   导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个 Web 应用系统是否易于导航:导航是否直观? Web 系统的主要部分是否可通过主页存取? Web 系统是否需要站点地图、搜索引擎或其他的导航帮助?
   在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动,很快地扫描一个 Web 应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构,因此, Web 应用系统导航帮助要尽可能地准确。
   导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容,内容在什么地方。
Web 应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。
3.2.图形测试
   在 Web 应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
   ( 1 )要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
   ( 2 )验证所有页面字体的风格是否一致。
   ( 3 )背景颜色应该与字体颜色和前景颜色相搭配。
   ( 4 )图片的大小和质量也是一个很重要的因素,一般采用 JPG 或 GIF 压缩。
3.3.内容测试
   内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。
   信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般 Web 站点中的所谓 " 相关文章列表 " 。
3.4.整体界面测试
   整体界面是指整个 Web 应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览 Web 应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个 Web 应用系统的设计风格是否一致?
对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
   对所有的可用性测试来说,都需要有外部人员(与 Web 应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
4. 客户端兼容性测试
4.1.平台测试
   市场上有很多不同的操作系统类型,最常见的有 Windows 、 Unix 、 Macintosh 、Linux等。 Web 应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
   因此,在 Web 系统发布之前,需要在各种操作系统下对 Web 系统进行兼容性测试。
4.2.浏览器测试
   浏览器是 Web 客户端最核心的构件,来自不同厂商的浏览器对 Java ,、 Javascrīpt 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如, ActiveX 是 Microsoft 的产品,是为 Internet Explorer 而设计的, Javascrīpt 是 Netscape 的产品, Java 是 Sun 的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。
   测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
5.安全性测试
Web 应用系统的安全性测试区域主要有:
   ( 1 )现在的 Web 应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
   ( 2 ) Web 应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如 15 分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
   ( 3 )为了保证 Web 应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
   ( 4 )当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。
   ( 5 )服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
6. 总结
   本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。
基于 Web 的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

  • 功能测试用例的书写方式

    2007-04-15 21:19:39

    功能测试用例的书写方式

    功能性测试用例
    1. 测试的来源,即测试的需求
    测试用例的主要来源有:
    1) 需求说明”及相关文档

    2)相关的设计说明(概要设计,详细设计等)

    3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)

    4)已经基本成型的UI(可以有针对性地补充一些用例)

    简而言之,所有你能得到的项目文档,都尽量拿到。 从所得到的资料中,分解出若干小的“功能点”,理解“功能点”,编写相应的测试用例。

    2. 用例的组织方式

    不同的公司有不同的做法,原则上,只要方便管理和跟踪,怎么组织都可以的。

    用例可以按大的功能块组织,如查询功能模块的用例,可以组织在一起,打印模块的测试用例,可以另外组 织在一起。

    在没有专门的测试用例管理工具的情况下,用例执行后会产生2种状态:“通过”、“失败”——这样加上“未 执行”的用例的状态,共3种状态。

    即从“未执行”用例中执行一个用例后,该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

    至于用例文件格式,可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。

    3. 用例与其他材料的关联方式,即如何解决用例跟踪的问题 测试用例面临的比较大的风险有:

    需求的变更、设计的修改、需求的错误和遗漏等等。

    由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟踪,需求和设计的 变更势必引起测试用例的变更。

    如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列出各个(编号的)功 能点和测试用例间的关联关系。

    这样,当需求和设计发生变化时,你只需要跟踪“功能点”是否变化,是否增 加了新的功能点。

    重要和困难的是,不手头的资料和信息一定要是最新的。

    4. 一个好的用例的表述要点,即用例中应当包含的信息

    一个优秀的测试用例,应该包含以下信息:

    1) 软件或项目的名称

    2) 软件或项目的版本(内部版本号)

    3) 功能模块名

    4) 测试用例的简单描述,即该用例执行的目的或方法

    5) 测试用例的参考信息(便于跟踪和参考)

    6) 本测试用例与其他测试用例间的依赖关系

    7) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限

    8) 用例的编号(ID),如可以是 软件名称简写-功能块简写-NO.。

    9) 步骤号、操作步骤描述、测试数据描述

    10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)

    11)开发人员(必须有)和测试人员(可有可无)

    12)测试执行日期

    5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。

    项目/软件技术出口合同网络申领系统 (企业端)程序版本1.0.25
    功能模块名Login编制人  xxx
    用例编号-TC-TEP_Login_1编制时间  2002.10.12
    相关的用例
    功能特性用户身份验证
    测试目的验证是否输入合法的信息,允许合法登陆,阻止非法登陆
    预置条件特殊规程说明如数据库访问权限
    参考信息需求说明中关于“登陆”的说明
    测试数据用户名=yiyh 密码=1
    操作步骤操作描述数 据期望结果实际结果实际结果

    测试状态

    1输入用户名称,按“登陆”按钮。用户名=yiyh,密码为空显示警告信息“请输入用户名和密码!”
    2输入密码,按“登陆”按钮。用户名为空,密码=1显示警告信息“请输入用户名和密码!”
    3
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=2
    显示警告信息“请输入用户名和密码!”

    4
    输入用户名和密码,按“登陆”按钮。
    用户名=xxx,密码=1
    显示警告信息“请输入用户名和密码!”
    5
    输入用户名和密码,按“登陆”按钮。
    用户名=xxx,密码=2
    显示警告信息“请输入用户名和密码!”
    6
    输入用户名和密码,按“登陆”按钮。
    用户名=空,密码=空
    显示警告信息“请输入用户名和密码!”
    7
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=1
    进入系统页面。
    8
    输入用户名和密码,按“登陆”按钮。
    用户名=Admin,密码=admin
    进入系统维护页面。
    9
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh',密码=1
    显示警告信息“请输入用户名和密码!”
    10输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=1'
    显示警告信息“请输入用户名和密码!”
    11输入用户名和密码,按“重置”按钮。用户名=yiyh,密码=1清空输入信息
    测试人员开发人员项目负责人


    备注:本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入,如非法输入中可能会有

    “user=*,pw=*”的组合,对回车的默认操作,空格输入,对输入上溢的处理的处理(可能会跳过身份验证) 等等。

    如果你有兴趣,至少可以再补充5-10条左右的输入组合

    (当然,如果步骤超过15步,用例的易操作 性就降低,你可以再创建一个测试用例如TC-TEP_Login_2)。


  • TAG:

    快乐的港湾 引用 删除 huazi1026   /   2007-06-07 11:23:30
    1
    学习一下
     

    评分:0

    我来说两句

    日历

    « 2024-04-28  
     123456
    78910111213
    14151617181920
    21222324252627
    282930    

    数据统计

    • 访问量: 26200
    • 日志数: 47
    • 建立时间: 2007-06-05
    • 更新时间: 2007-09-29

    RSS订阅

    Open Toolbar