测试人员的工作通常并不像开发人员那样能直接体现出来，让大家一目了然。开发人员做的是建设性的工作，如开发了哪些功能，写了几行代码，设计了几个类，都能直观地看到，而且，通过软件能很鲜活地演示开发人员的工作成果。
        但是测试人员的工作相对隐蔽一点，测试人员做的是破坏性的工作，并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说：“你们做测试的真好，整天坐在那里”。当然，这是外行人看内行时说的话，但是给笔者的一个启示是：测试人员需要更多地表现自己，展现自己的工作成果。
        说明：由于缺陷列表太细、太大，测试用例过于专业，很多人对其不感兴趣，因此测试报告能很好地展示自己的工作状况，测试报告是提供给很多人看的一份文档。
        下面是一个项目的测试报告的纲要：
1 简介
1.1 编写目的
1.2 项目背景
1.3 术语和缩略词
1.4 参考资料
2 目标及范围
2.1 测试目的及标准
2.2 测试范围
3 测试过程
3.1 测试内容
3.2 测试时间
3.3 测试环境
3.4 测试方法及测试用例设计
4 测试情况分析
4.1 测试概要
4.2 测试用例执行情况
4.3 缺陷情况
4.4 测试覆盖率分析
4.5 产品质量情况分析
5 测试总结
5.1 测试资源消耗情况
5.2 测试经验总结
6 附件
附件1 测试用例清单
附件2 缺陷清单
一、缺陷分类报告
        缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
1．缺陷类型分布报告
        缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如，如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。
缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示，用饼图表示了几种类型的缺陷各自所占的比例。

2.缺陷区域分布报告
        缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如，如果缺陷主要集中在单据的审批过程中，那么就要分析是否是审批流程调用的工作流接口设计不合理。
        缺陷区域分布报告一般使用饼图或柱状图表示。如图7.30所示，用柱状图表示缺陷分布在不同的功能模块的个数。

                                                        
3.缺陷状态分布报告
        缺陷状态分布报告主要描述缺陷各种状态的比例情况，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状：
        如果Open的Bug比例过高，则考虑让开发人员暂停开发新功能，先集中精力修改Bug；
        如果Fixed状态的Bug很多，则考虑让测试人员暂停测试新功能，先集中精力做一次回归测试，把修改的Bug验证完；
        如果Closed的Bug居多，则可能意味着功能模块趋于稳定；
        如果Reopen的Bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不彻底；
        如果Rejected的Bug比例过高，则要看开发人员与测试人员是否对需求存在理解上的分歧；
        如果Delay的Bug比例过高，则要考虑这个版本是否满足用户的要求，是否缺少了太多应该在这个版本出现的功能特性。
        缺陷状态分布报告一般使用饼图或柱状图表示。如图7.31所示，用饼图表示各种状态的缺陷个数以及所占的百分比。

    注意：其他的缺陷分类报告也可以写到测试报告中，例如，严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但是要注意，应该用这些分类报告来说明问题，而不要用来指责别人，例如使用负责人分类报告来嘲笑某个开发人员是“Bug大王”等。
二、缺陷趋势报告
        缺陷趋势报告主要描述一段时间内的缺陷情况。如果项目管理比较规范，缺陷管理和测试流程比较正常的话，缺陷趋势报告还可以用来估算软件可发布的日期。
例如，如图7.32所示的缺陷趋势图，表示在2001年9月3号至2001年9月24号之间的Bug状态变            从图7.32可以看出，Open状态的Bug在不断地增加，Fixed状态的Bug在2001年9月16号后开始骤然下降，这表示，这段时间开发人员有可能在开发几种新的功能，忽略了Bug的修改工作。
        发现并录入Bug，与修改并关闭Bug是一对互相对冲的两个变量，软件产品就是在这样此消彼涨的过程中不断完善和改进质量的。有经验的项目经理和测试人员会非常关注这样的发展曲线，从而判断项目产品的质量状态和发展趋势。笔者曾经在某个项目中与一位项目经理在项目的待发布阶段每天都在观察缺陷趋势图，这位项目经理甚至把它戏称为软件产品的“股市”技术图。
        但是确实能从这些图中看出一个产品的质量趋势，如果项目管理得比较规范的话，甚至可以从这些图的某些关键点推算出可发布版本的日期。在微软的项目管理中，把这种关键点称为零Bug反弹点。例如，图7.33中就有几个零Bug反弹点（用圆圈圈住的地方）。

        项目在第一次达到零缺陷，即所有Bug（或者大部分Bug）都基本处理掉了，没有发现新的Bug时，还不能马上发布版本，因为Bug会反弹。由于缺陷的“隐蔽特性”和“免疫特性”，第一个零缺陷点是一个质量安全的假像，测试人员很快就会在新版本中发现更多的Bug，有些项目甚至要到第三个或第四个零Bug点才能安全地发布，这取决于项目的实际控制方式

 

对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程.

回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包括:

1.测试用例库的维护

为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征.

测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面.

(1)、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除.

(2) 改进不受控制的测试用例

软件质量管理不经理,要达到怎样的能力呢
学10:19:23
我个人认为，要掌握一定的开发知识，然后掌握丰富的软件测试知识，然后对软件工程有一定的了解，当然组织和协调能力那是抽象的不好说
缤雪  10:19:24
我只知道写好的用例是质量经理必须要做的事情.
学习10:19:39
写好的用例是测试工程师必须做到的事情
缤雪  10:20:32
质量经理应该是更要吧!要不怎么控制质量啊?
学习10:20:48
这还用说吗
缤雪 10:26:23
学习者,能指导下吗,我现在的测试工作一直是一个人在摸索中,我正在为怎样在测试前写好测试用例考虑着,也没见过比较规范的好的测试用例,能对一个最简单的主要是对数据库增删改查的管理的系统怎么规划怎么设计TEST CASE给个建议吗?写用例有没有度的问题啊?
学习10:28:31
首先如果你想把增删改这样的测试做好，你必须有去后台数据库中查询数据的能力。增删改的用例很好写的，一些涉及到因增删改之后有异动的业务逻辑流可能将是你必须关注的地方，这就要看需求分析或详细设计中的具体内容了。
学习 10:30:45
一个很简单的例子，比如删除一个部门，用例很简单，就是核对此部门是否删除掉，在前后台都可验证，保险的方式是去后台验证，因为有的JS缓存会有假像，如果JS没处理好或刷新不及时，但部门被删除后涉及主外键关系的部门底下的员工怎么办，前提是此部门底下没有员工了，那这个判断将是你用例中的重点，
 
缤雪 10:32:43
需求提到某角色对某些数据进行修改或者删除或者只可以查看的.
那么就是说删除部门就一个TEST CASE 就可以了
学习10:34:08
这个具体情况具体分析，建用例的划分要合理，一个是好让开发人员看到这条BUG后容易地通过追踪用例过程就可以发现是哪出的问题，太复杂的用例会把开发人员搞晕，另一个是过份简单的用例将导致你的用例条数很多，会把自己搞得很累
缤雪 10:35:31
我感觉不够,似乎要好多个用例
能请问下 ,比如你们对删除部门这样一个操作动作,而部门设计到的主要是用户,用户关系到角色,角色关系到对系统的操作权限,这样大概要设计几个用例.
学习10:37:30
你可以一个CASE 然后底下有多个步聚
学习 10:37:48
还比如，增和改其大部份是相同的，那你可以用例共享
缤雪  10:38:05
这个具体情况具体分析，建用例的划分要合理，一个是好让开发人员看到这条BUG后容易地通过追踪用例过程就可以发现是哪出的问题，太复杂的用例会把开发人员搞晕，另一个是过份简单的用例将导致你的用例条数很多，会把自己搞得很累
我想这就是度的问题,也就是这个度让我迟迟不知道该怎么写好用例
学习:39:20
多混些日子就可以了，这只是接触过与没经历过的差别，没多大技术性，建议你多学开发知识，这对测试非常有用
缤雪 10:39:34
我用BUGFREE2.0可以直接COPY ,修改,写起来倒是方便
学习 10:39:58
你要用TD或别的一些，COPY都不用
缤雪 10:44:37
那么就说对增删改的用例也就是可以多个步骤写在一起,就比如我对一个文本框的输入用例,可以简单写成一个用例,分步骤为:1.正常值输入2.边界值输入3.特殊字符输入 4......这样的?
学习10:45:03
就是这样的，你太有才了
学习10:46:04
当然，仁者见仁，每个人的习惯和公司对用例的要求不一样
缤雪 10:46:12
终于让我明白了!谢谢!是你耐心指导啊!
缤雪 10:46:54
怎么说,我想知道,一些规范的公司,比如经过CMMI认证的公司他们用例写的是一样呢,还是有区别?
缤雪10:47:08
应该说是用例设计
学习10:47:26
和这个没有关系的，大多会和公司系统的性质有关系，产品化和项目化的要求会有不太一样的地方
学习10:48:24
还有包括产品版本升级的频率，变更的频率，和产品所涉及的技术强度等都会决定你什么模块的用例要到什么程度
缤雪10:50:48
那么如果按刚才说的这样写,我要写的这个项目"基础数据管理系统"(就AMDR)的用例那不是很少,就只有两方向了:把权限问题搞定和保证AMD数据正常就可以了
缤雪10:51:46
我也要写产品的用例,那么产品的用例该怎么写呢
学习 10:51:51
这样我替你分析不了的，要从整个项目出发来把握
学习 10:52:24
理论上产品的用例要求会对项目化的用例高点。
缤雪 10:53:54
是否写得要不能偷懒些,写得详细些
学习 10:54:15
产品化的项目，用例的延续性和复用性更高。
学习 10:54:42
这个要根据你公司具体情况来定的
缤雪10:54:55
哦,也就是你说要考虑到升级的问题
缤雪 10:56:13
先考虑到了,测试用例复用性高也就能省事,但是延续性和复用性有区别吗?是指可以对某个用例进行补充?
学习10:56:40
 
缤雪10:57:02
延续性=?接口
学习10:57:03
改天我们面谈一下，这样会累死的

1.

use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。

2.

中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。

3.

现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当.把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。

 

1、测试自动化实现到何种程度为好

　　（1）、测试自动化的程度再高都不可能取代手工测试，即测试工具不可能取代测试人员；

　　（2）、一般来讲，测试自动化在整个测试过程中只能占到30%左右；

　　（3）、实现、运用自动化的程度还取决于各方面的资源，特别是软件的行业规范性和软件开发的稳定性；

　　（4）、对于部分白盒测试可以使用测试工具，如对代码性能分析等；

　　2、如何实现测试自动化的计划

　　（1）、首先将测试的基本管理形成自动化，如BUG管理等；

　　（2）、然后利用测试自动化工具来实现一些手工无法进行的测试活动，如：压力，并发，强度测试等；

　　（3）、接着利用测试自动化工具来完成回归测试中的缺陷跟踪测试；

　　（4）、再往后就可以利用测试自动化工具来记录两个版本的异同，以找出缺陷；

　　（5）、最后将整个回归测试都用自动化脚本保存，以完成每次的回归测试；

　　（6）、而对于白盒测试则可以引入测试工具进行代码分析；

　　3、对测试工具的使用现状及分析

　　（1）、目前，软件测试方面的工具很多，主要有MercuryInteractive（MI）、Segue、Rational、 Compuware和Empirix等公司的产品，而MI公司的产品占了主流。以下就各种常用测试工具进行简要对比：

　　主要厂商及其测试工具如下表：

　　Mercury Interactive Winrunner、loadrunner、TestDirector、Astra QuickTest

　　Rational Rational Purify （测试时用，检查运行时内存错误）

　　Rational Quantify （性能检测工具，查出系统瓶颈以便改进运行速度）

　　Rational TestManager （测试管理）

　　Robot （软件测试用，通过scrīpt自动模拟输入输出）

在"我的电脑'-_"属性"里设置完远程连接后,用户远程连接时候,提示"无权限无法登陆",可以检查

1. "我的电脑--"属性'里的用户权限

2. 远程访问的用户是否设置有密码

问题:虚拟机可以PING通主机;而主机不可以PING同虚拟机

待解决:

 

当用户对系统的使用权限有限的时候,可以不采用用户登陆系统,在首页提示的方式(如移动基站管理系统)

可以借鉴"BUGFREE"左下方的提醒方式:

指派给我   我的创建   我的查询

1.

2.

3.

....

 

 

有两个项目的角色权限管理采用的是瀑布式设计,优点是能一目了然,但是页面太长!

角色权限的控制页面可以采取模块标签式,缺点是不能一目了然,如:

角色名称:

角色说明:

角色权限:

模块一     模块二    模块三     模块四......

子模块一   子模块一  子模块一    子模块一.....

子模块二   子模块二  子模块二    子模块二.....

 

 

测试:在Windows XP下安装"税务直通车3.0"

环境:按照"安装说明"完成ORACLE 9I CLIENT 安装和配置,完成IIS安装和配置,完成安装"税务直通车 3.0"STUP安装,完成WEB.CONFIG配置

问题:点击桌面的"税务直通车 3.0"图标,提升"网页无法显示"

解决:给ORA92赋予NETWORK SERVERVICE权限.

基于Web的系统测试方法 基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。 　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 　　随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。 　　Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它”使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统”。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。 　 在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。 　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

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

　　一、功能测试

　　1、链接测试

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

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

　　2、表单测试

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

　　3、Cookies测试

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

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

　　4、设计语言测试

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

　　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应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

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

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

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

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

　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

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

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

　　4、整体界面测试

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

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

　　对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

　　四、客户端兼容性测试

　　1、平台测试

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

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

　　2、浏览器测试

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

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

　　五、安全性测试

　　Web应用系统的安全性测试区域主要有：

　　（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

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

　　（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

　　六、总结

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

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

一、测试用例的切面设计

所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。

1、功能点切面

这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。

2、特定切面

除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。

3、隐含切面

这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

（1）、后台功能

常见的如一些定时自动启动的服务；以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。

 

（2）、完整业务流程的测试

我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。

（3）、某种特定情况下的系统运行

这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试；又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

（4）、其它相关系统

即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数；以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项；若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。

（5）、除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。