[有奖问答5]针对WEB应用，您会关注哪些方面的测试？
测试应该是全面的，应该包括功能、性能、安全等多个方面的测试。针对WEB应用，您会关注哪些方面的测试？答题前请复制以下回贴格式(蓝字部分)，并填写好个人真实有效信息，以确保奖品发送无误。
**** Hidden Message *****
答题: **** Hidden Message *****
答题：
鉴于web应用的特殊性，除了关注功能方面的测试外，我们还关注：
易用性测试、安全性测试、网页效率测试和性能测试
[ 本帖最后由 dqar 于 2009-11-11 13:41 编辑 ] **** Hidden Message *****
答题：根据web应用的特点，我会着重关注
1. 界面：
1）界面配色是否友善，符合行业特性
2）各功能点是否清晰明了
3）使用不同分辨率情况下，页面显示是否一致，不会出现错格或排列混乱
4）字体设置是否一致
6）是否存在错别字或语法错误
5）错误提示是否友善，清晰明了
2. 功能：
1）检查各个链接地址是否正确，是否存在死链接
2）各功能点的基本测试
3）各功能点的容错性测试
3）系统的易用性
2. 性能：
因为web应用对服务器的请求会很多，所以必须关注服务器的性能。使用性能测试工具，对服务器进行负载和压力测试，找出性能瓶颈，确保系统的性能。
3. 安全：
在网络发达的今天，一个系统的安全性至关重要。利用渗透测试或SQL注入等测试手段，对系统进行全面的安全性检测，尽可能减少系统的安全漏洞。
4. 兼容性：
测试系统与各种主流系统（Windows，Linux）及主流浏览器（IE,FireFox,Opera,Chrome等）的兼容。
知识较为缺乏，只想到这一些 **** Hidden Message *****
答题:在功能测试完成的基础上，多关注性能测试、安全性测试、兼容性测试、用户界面测试等 **** Hidden Message *****
答题:
1.功能测试: 链接测试\表单测试\Cookies测试\数据库测试\业务流测试
2.性能测试：连接速度测试、负载测试、压力测试
3.界面测试：易用性测试，导航测试、图形测试、内容检查
4.兼容性测试：操作系统平台测试、浏览器、分辨率、
5.安全性测试
等 **** Hidden Message *****
答题:
重点关注的是功能方面的测试，在提高功能质量的同时确保兼容性测试方面的相关内容，以及用户体验的相关缺陷的优化 **** Hidden Message *****
答题:
一、功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或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，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 **** Hidden Message *****
答题:
1.功能测试：基本功能，常用功能，以及通常情况的错误处理
2.界面及易用测试：基本排版，页面内容，以及对消息的显示形式
3.基本安全性测试：如果是只对内网用户则基本不考虑此项，如果对外网用户会使用基本的注入及XSS进行测试
4.基本性能测试：主要是页面的访问以及查询或者输入的提交，
5.兼容性：在测试时，就由不同人使用不同的主流浏览器进行测试
基本上在自己进行测试时，第5条是由不同人员进行的，其他都是在1，2，3都是在功能测试时顺带进行的，第4条也是看需要才确认是否需要专门执行
但需要注意的是对多用户的数据提交操作进行并行最好也当成是一个功能测试项进行
答题
功能方面的测试：首先看该应用是不是基本功能可用，应该是大致做一下冒烟测试。其次由于是基于WEB的，应该有用户登录，注册这些网站具有的基本功能。性能方面：找到压力边界。还有用户登录的时候对CPU，内存等资源的影响。
安全方面：主要是防止黑客，注意隐藏文件，Server端杀毒软件是否正常运行。
Web测试
通用◇ 所有测试是否运行在干净系统上？
◇ 系统是否正常运行？
◇ 是否显示正确输出？
◇ 系统是否能提供所需功能？
◇ 普通用户是否能轻松地操作该系统？
◇ 是否易学易用？
◇ 系统是否会为客户提供服务？如响应的、有帮助的、正确的服务？
◇ 是否可以简单辨别系统的正确性与可靠性？
◇ 是否能轻易地修复或修改系统？
◇ 当系统需要提交或修复时，开发人员是否可以在限期内完成？
◇ 新版本中未经修改的功能是否能与老版本保持一致？
◇ 系统是否能使硬件、网络及人力资源得到有效利用？
◇ 系统是否能匹配相关的技术水平？
◇ 系统是否能匹配适当调整的需求？
◇ 是否可以有效验证系统的工作方式是适当的？
◇ 本系统内一些组成部分是否可以被其他的系统再利用？
◇ 不同用户不同平台上安装系统是否同样快捷便利？
◇ 系统是否设置有未来更新的路径？
◇ 是否可以方便地获取信息？
◇ 网站是否能被搜索？
可用性、界面及导航
◇ 系统为一个用户、十个用户或一千个用户服务时，是否同样工作正常？
◇ 是否可以快速登陆主页？
◇ 网站的操作方法是否清晰地展示给用户？
◇ 如果按操作方法进行操作是否可以得到预期结果？
◇ 是否所有新用户都理解网站内的所有术语？
◇ 是否所有窗体都有导航栏？
◇ 导航栏的位置是否始终保持一致？
◇ 是否导航栏仅作用于使用中的文本？
◇ 用户是否可以在不用鼠标的情况下使用导航栏功能？
◇ 视力障碍者是否可以使用网站？红绿色盲，少于 20/20
◇ 网站标志是否风格一致？
◇ 每个单独页面内是否包含主页链接？
◇ 每个页面的排版是否统一？
◇ 每个页面的管理风格是否一致？
◇ 网站内图表的使用是否协调？
◇ 快速下载的图表是否质量优化？
◇所有图片是为页面添彩，还是浪费网速？
◇ 是否使用了图表的最佳尺寸？
◇ 图表/图片周围的文字布局是否合理？
◇ 是否对所有的参考网站或电子邮件地址都设置了超链接？
◇ 超链接颜色设置是否标准？
◇ 网站在 640 x 480、600x800 等像素下是否显示正常？
◇ 字体是否太小（切忌并非每个人都能获得相同的视图效果）？
◇ 字体是否太大？
◇ 所有文本是否排列适当？
◇ 所有图标是否排列适当？
◇ 图片是否能被完整打印？
◇ 网站内是否有站内地图？
◇ 站内地图的每个超链接是否有对应的目标链接页？
◇ 站内地图是否包含了网站内所有的超链接？
◇ 每个页面的超链接是否正常工作？
◇ 内容是合法正确的（非单元测试期间开发者设置的填充内容）
◇ 页面背景（颜色）是否会分散注意力？
◇ 返回按钮是否正常工作？不会打开一个新的浏览器窗口，或重定向其他站点。
◇ 返回上页或转至新页面时，是否会导致本页面内容丢失？
◇ 从主页开始是否可以通过 3 次或更少的点击数到达目标页面？
◇ 图表或表格中的内容是否完整？是否正确列出？是否能确定所选文本处于图表或表格的正确区域内？
◇ 页面上的链接是否和先前一致？有没有新出来的或消失的链接？
有没有链接失败的情况？
◇ 点击链接是否能到达正确的目标页面？
◇ 目标页面是否存在？
◇ 站主的联系信息是否能从网站中获得（姓名、电话、电子邮件地址、邮寄地址、传真号）？
◇ 如果用户需要为某个页面作标签，该页面的名称是否易懂？
◇ 如果用户有获取历史页面纪录的权限，那网站地址是否会出现在 History 列表中？
◇ 网站页面的状态栏是否真实反映出页面登陆的进度、信息等？
表格
◇ 表格是否过长，经常需要通过拖动滚动条才能看到表格右边的栏目？
◇ 表格是否能正确打印？
◇ 表格内的列宽和行高是否合适？
◇ 会不会因为某个输入而使行高变化异常？
框架
◇ 是否会出现浏览器不支持的框架？
◇ 框架是否能自动准确地调整大小？用户是否可以操控框架的尺寸？
◇ 滚动条是否会适时出现？
◇ 框架页面上是否有明确的数据供书签或收藏夹识别？
◇ 搜索引擎是否可以找到框架中的内容？
◇ 框架边框是否美观？
◇ 框架内更新是否会出现问题？
数据认证
◇ 网站内面向用户的数据描述是否清楚？
◇ 隐私制度是否制定清楚？用户能否看到该制度？
◇ 保存的数据是否准确？
◇ 工作站是否对数据进行认证？
◇ 服务器是否对数据进行认证？
◇ 是否可以确保用户在工作站录入的信息可以被服务器正确接收？
◇ 在不同的时间段是否可以避免录入相同的信息（订单表等）？
◇ 是否为每个用户分配有唯一标识符，用于录入表格数据，保证表格对象的唯一性？
◇ 要求用户录入的信息是否是进程所必需的？例如：要求用户录入生日信息是用于其订单编号？或
是仅仅为了多获得一些用户信息？
◇ 数字录入区域是否可以录入文字？
◇ 搜索中能否使用通配符？
◇ 是否可以在域内录入空格和空值？
◇ 是否可以录入长串？
◇ 域内是否可以录入文本最大的数量？
◇ 复选框和控件按钮的初值是否设置正确？
◇ 一个组内的控件按钮是每次只能选中一个？
◇ 复选框是否会触发预期事件？
◇在表格域内用户是否不能输入 HTML 代码？
◇智能错误处理是否会引发数据认证？ IE.如生日域的需求格式为 MM/DD/YYYY，则用户输入出声年
份为 1857 是不匹配的。
外部界面
◇ 系统界面是否与相关的外部系统相匹配？
◇ 界面是否通过验证？
◇ 是否所有的支持的浏览器都经过测试？
◇ 一旦外部应用程序不可用或服务器连接失败，是否所有与外部界面相关的错误环境都经过测试？
◇ 代理缓存是否经过测试？
◇ 是否所有可能从网站内部安装的应用程序都经过测试？
内部界面
◇ 网站是否支持无下载功能的用户使用？
◇ 网站是否设置有防火墙？
◇ 网站是否可以灵活使用卸载插件？
◇ 网站处于不同模式或运行速度的情况下可能需要使用插件，网站是否支持？
◇ 是否所有的插件可以协同工作？
◇ 是否所有平台都支持，且能打开链接文件（如 Solaris 操作系统是否可以打开 Microsoft Word
文件）？
◇ 是否所有浏览器都支持这些插件？
◇ 一旦 Java 不可用，是否网站就不可用？
◇ 是否所有的插件都能正常启动？
◇ 如果下载时遇到错误，是否会有错误处理？
◇ 网站功能中是否有使用"非标准"硬件（如话筒、线缆调制解调器等）的功能存在？
◇ 是否可以下载注册的 ActiveX 控件？
◇ 是否可以下载未注册的 ActiveX 控件？
◇ 是否可以初始化并编译未被认定为安全的 ActiveX 控件？
◇ 是否可以运行 ActiveX 控件和插件？
◇ 是否可以编译被认定为安全可编译的 ActiveX 控件？
◇ 反馈结果是否需要 cookie？
◇ 如果用户不支持 cookie，反馈结果是否正常？
◇ 反馈结果是否允许使用每个对话 cookie？
◇ 反馈结果是否需要文件下载？
◇ 如果用户不要下载文件，网站是否仍可以使用？
◇ 反馈结果是否需要使用特定字体？
◇ 反馈结果是否需要用户跨越多个站点/域链接数据源？
◇ 用户是否可以使用拖拉和点击功能？
◇ 用户是否可以使用复制/粘贴功能？
◇ 反馈结果是否需要下载任何桌面项？
◇ 反馈结果是否需要登陆或安装任何带框架的文件？
◇ 是否允许提交未加密数据？
◇ 网站是否允许通过脚本复制操作？
浏览器 - IE、Netscape、AOL、Mac 等
◇ HTML 版本是否与相应的浏览器版本相匹配？
◇ 测试时，JAVA 源码/脚本是否被浏览器支持？
◇ 测试时，浏览器是否可以正确显示图片？
◇ 是否可以确定在任何浏览器上，字型都是可用的？
◇ 与每个浏览器相关的安全性设置/风险是否经过检验？
◇ 是否在多个浏览器上验证过数字证书？
◇ 与浏览器配套的插件是否和网站一起经过测试？
◇ 是否设置了源码不可见？
◇ 不同浏览器上的网站内容是否都可打印？
◇ 是否影响整体的内容大小（可靠性、一致性）？
◇ 是否验证过应用程序与框架是否兼容？
◇ 鼠标和键盘是否经测试适用于不同的浏览器？
◇ 是否执行过智能错误处理（如：cookie 不可用）？
◇ 128 位编码是否经验证可用？
◇ 在不同浏览器上 GIF 是否经测试可用？
Cookies
◇ cookie 储存的信息是否经过验证？
◇ cookie 信息是否经过加密？
◇ cookie 信息是否适量增加？
◇ 是否阻止用户编辑 cookie？
◇ 是否检查过如果用户浏览网站期间删除 cookie，会发生什么？
◇ 是否检查过如果用户关闭网站后删除 cookie，会发生什么？
◇ cookie 储存的路径是否正确？
◇ cookie 的信息是否正确有效，用户是否可以使用该信息连接网站？
登陆/并发使用
◇ 系统是否达到预期的响应时间、流量以及实用价值？
◇ 系统是否可以承受极限用户量的访问？
◇ 系统是否可以长期无故障地正确运行？
◇ 是否监视过 CPU 的使用、响应时间、硬盘空间、内存用量及泄露？
◇ 是否定义标准响应时间（如：所有的页面的显示时间应小于 10 秒）？
◇ 是否验证防火墙、证书、服务提供商以及可以网络的影响？
◇ 不同速度的调制解调器上网页的登陆性能是否可接受？
◇ 同一用户是否可以长时间连续使用网站？
◇ 多个用户是否可以长时间连续使用网站？
◇ 在高流量的情况下，网站是否能支持短时间的使用？
◇ 网站是否可以维持大量数据的处理，而不崩溃？
◇ 如果事务是无效的，网站是否仍允许大订单，而不会死锁目录？
错误处理
◇ 是否建立自动错误监察恢复机制，以保持系统运行？
◇ 如果系统崩溃，重启和恢复机制是否有效可靠？
◇ 如果半途断开网站，事务是否随之取消？
◇ 如果网络忽然中断，事务是否随之取消？
◇ 反馈结果是否处理文件传输的中断？
◇ 反馈结果是否处理浏览器崩溃？
◇ 当网站和应用服务器连接中断时，反馈结果是否处理？
◇ 反馈结果是否处理数据库服务器中断链接的情况？
◇ 应用程序是否通报用户事务的状态？
◇ 网站是否包含 24 x 7 性能监控？
◇ 监控软件 MAPI 的电子邮件协议/限制
◇ 网站是否可以链接到页面系统？
◇ 时间 - 连续、每时、每天、每周
◇ 硬件限制 - 监视软件是否必须运行在专用机器上？
◇ 内存 - 泄露、隐藏、持续运行导致的问题
网络影响
◇ 是否考虑过 32 位和 64 位版本的 IP 问题？
◇ 是否测试过安全代理服务器的影响？
安全
◇ 是否足够安全？
◇ 是否机密/用户私密保护？
◇ 是否只有使用 128 位浏览器才能成功链接？
◇ 网站是否提示用户姓名和密码？
◇ 网站是否需要孩童输入个人信息？如果需要，是否在安全页面进行，且警示其家长？
◇ 服务器和客户端是否都有数字证书？
◇ 是否验证密码开始和结束的地方？
◇ 是否允许同时注销？
◇ 应用程序是否支持因静止而导致超时？
◇ 安全页面内书签是否不能使用？
◇ 在非安全/安全页面的状态栏上是否有显示钥匙/锁？
◇ 右击、查看、源文件是否不可用？
◇ 是否不能在 URL 上通过编辑内容而进行直接搜索？
◇ 如果使用数字证书，请通过注册证书、按规定填写安全信息测试浏览器缓存。安装证书后，试着
使用回车键，看安全信息是否仍保存在缓存中。如果仍旧存在，那任何使用者都可能有机会获取这些高敏
感的数字证书中的安全信息。
◇ 由于 SSL 和低于 3.0 版本的浏览器不兼容，是否有第二种方法可以连接到安全页面？
◇ 用户是否清楚何时进入、何时离开网站的安全部分？
◇ 当用户多次使用无效登陆名/密码信息登陆失败时，服务器是否会拒绝该用户再次尝试链接？ **** Hidden Message *****
楼上回答很全面呀
答案：页面部分
（1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
（2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
（3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
（5） 页面特殊效果显示是否正确
2 页面元素部分
（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
（2）素是否显示（元素是否存在）
（3）页面元素是否显示正确（主要针对文字、图形、签章）
（4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
（5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
（6） 页面元素的容错性列表（如输入框、时间列表或日历）
（7） 页面元素的容错性是否存在
（8） 页面元素的容错性是否正确
3 功能部分
（1） 数据初始化是否执行
（2） 数据初始化是否正确
（3） 数据处理功能是否执行
（4） 数据处理功能是否正确
（5） 数据保存是否执行
（6） 数据保存是否正确
（7） 是否对其他功能有影响
（8） 如果影响其他功能，系统能否作出正确的反应
（9） 其他错误
（10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加 （新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
（11）查询功能分为两种情况，验证操作结果。
一、打开页面时自动显示结果，则不特别强调；
二、需要手工操作进行查询，则每次在其他功能完成后进行。
4 提示信息
（1） 成功、失败提示
（2） 操作结果提示
（3） 确认提示
（4） 危险操作、重要操作提示
（5） 返回页面 提示后显示的页面
5 容错性
注意以下几种情况
（1） 为空、非空
（2） 唯一性
（3 ）字长、格式
（4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
（5） 日期、时间
（6） 特殊字符 （对数据库）英文单、双引号，&符号
6 权限部分
功能权限： 指定用户可以使用那些功能，不能使用那些功能
数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可以合并到功能测试
操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合并到功能测试
权限变化： 可以合并到功能测试
（1） 功能权限是否存在
（2）功能权限是否正确
（3） 数据权限是否存在
（4） 数据权限是否正确
（5）操作权限是否存在
（6） 操作权限是否正确
（7） 引起权限变化的功能列表
（8） 功能权限变化还是数据权限变化，或两者兼有
（9） 权限变化是否正确
7 键盘操作
（1） Tab键的使用
（2） 上下方向键的使用
（3） Enter键的使用
（4） 系统设定快捷键的使用（如果设置有快捷键）
8 测试中还应注意的其他事项
（6） 完整性：是否是一个整体，没有功能缺损
（7） 易用性：使用是否方便
（8） 一致性：类似的问题用类似的方法处理
（9） 提示信息：提示信息是否完整、正确、详细
（10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
（11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
（12） 可扩展性：是否由升级的余地，是否保留了接口
（13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
（14） 运行速度：运行的快慢，带宽占用情况
有几点：
1.功能点测试：是否满足需求所要求的功能
2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
7.界面测试：界面的正确性、一致性、友好性、易用性。
用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
1.易用性检查：确保软件易于理解，方便使用。
2.一致性检查：
a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
b.提示信息的表达方式是否一致。
c.按钮排列顺序是否一致。
d.back, cancel等按钮跳转页面处理是否一致。
e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
4.友好性检查：
a.提示信息是否友好.
b.系统应该在用户执行错误的操作之前提出警告，提示信息.
c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。
[ 本帖最后由 月上百合 于 2009-11-13 22:15 编辑 ] **** Hidden Message *****
答题:
在功能测试完成的基础上，多关注性能测试、安全性测试、兼容性测试、用户界面测试，包括现在最流行的边界测试，界面美观度测试，以及用户易用性等等
回复 1# 的帖子
1.功能2.性能
3.安全性（IP LINK, SQL INJECTION）
4.界面
5.易用性 **** Hidden Message *****
答题:
功能测试：系统功能实现是否与需求文档匹配，功能是否齐全，各功能点实现的正确性等
界面测试：界面设计、布局、颜色搭配等是否合理，控件命名通俗易懂
易用性测试：产品操作简单、便捷，能快速提高用户工作效率
性能测试：负载测试、强度测试、容量测试
安全测试：用户及权限分配是否合理，系统是否存在安全漏洞，如SQL注入、跨站点脚本攻击等 **** Hidden Message *****
答题:
软件首要的就是要满足其所要满足的功能，不管什么测试，功能方面的测试肯定是必不可少的。
工作时间不长，从我接触项目的web测试来看，除了功能方面的测试，我关于的比较多的可能是界面UI测试，各个浏览器的兼容性测试，
性能方面由于能力有限还不曾接触。
界面UI测试：不同的开发人员，所开发的东西或多或少会带有各自的一些风格，在没有很好的准则的情况下，界面元素的排列、按钮大小、以及输入框的长度都有可能有不一致的地方，还有一些提示信息也有可能会不一致，
为了使得web看上去是个完整统一的整体，这方面我是会常关注的。
浏览器的兼容性：用户使用什么样的浏览器是不确定的，即使出现的问题并不严重，也会给用户带来不好的影响。
在工作中，几个主流浏览器的测试肯定是不能缺少的。现实也是如此，不同的浏览器总是带来了一些问题，
当然问题改不改并不是我们所关心的了，发现了问题，我们的使命也就达到了。
新人一个，能做到的也就只有这些了。像其他高人讲的安全性方面，sql注入之类，还在研究学习中。 **** Hidden Message *****
答题：
1.首先进行功能测试：保证功能符合用户需求
2.界面测试：界面是否友好，是否易操作
3.性能测试：链接速度是否在用户允许范围内
4.安全测试：系统是否有漏洞等
5.兼容性测试：在不同的操作系统，不同的浏览器下网页是否正常
2. 简单概述主要是：功能、性能、界面、易用性 **** Hidden Message *****
答题:
1 UI测试
看页面是否美观养眼(包括页面的布局是否合理，策划是否舒服美观，页面长度是否合理，前景色与背景色是否搭配，页面风格是否统一，色调是否适合人眼，会不会太刺眼，字体大小是否合适，字体的颜色是否与背景色搭配，字体链接时是否会出现设置怪异的背景色，字体颜色有没有与背景色太接近或差距太大导致我们没办法看清字体或刺激了我们的视觉，点击链接时图片和字体会不会产生移位)，表格和DIV测试，是否网页设计师在表格或DIV里放置了过多的东西导致表格或 DIV拉长，表格或DIV之间对齐了没有，中间是否有空隙，是否产生了错位，如果在表格或DIV中设置了溢位，表格或DIV中的内容是否可以全部看到，有没有出现一半字的情况，如果使用了框架结构.框架结构是否合理，表格每行的宽度是否足够，是否有折行。
2 链接测试
点击链接时是否可以进入我们要找的页面，进入了我们要找的页面后能否正确返回，链接页面会不会是空白页面或孤立页面或根本没链接(也就是说链接的是自己本身)，如果链接的是空白页我们是否可以再正确返回，如果使用了框架或内嵌框架是否可以正确在本框见页内显示要查找的页面，使用内容置顶时是否可以正确实现。
3 表单测试
表单的测试包括单选按钮，复选框，文本框，密码项和菜单项和提交按钮类按钮的测试和后台数据库的测试.首先如果是单选按钮我们选择了一个后可不可以再选第二个，如果是复选框的话我们能不能同时选择多个选项，选择多个选项时若需要全选那摸我们是要一个个的选择还是只需要选择一次就可以，在文本框里我们输入的字数有无特别限定，若与特别限定条件不符那摸我们是否可以操作成功，在对用户名和密码的设置时用户名是否可以为数字，汉字，非英文字符，中间是否可以有空格，标点符号，对密码的长度有无特别限定，若超过特别限定或少于特别限定我们是否可以操作成功，密码是否可以为汉字，英文，特殊字符和标点符号，中间是否可以空格，密码是否设置了屏蔽菜单项分级是不是太多，过长(特别是我们为了节省空间在导航上设置的菜单)点击菜单选项上的各分级目录是否可以正确进入链接页面，进入链接页面我们是否可以正确返回，点击提交按钮看是否可以提交成功，点击取消按钮看其是否生效，提交后看我们的资料是否保存成功，保存后刷新页面看我们的资料是否可以正确显示，我们是否还可以再回到原始页面，如果未输入用户名或密码会不会提示出错，错误提示是否可以关掉，提示出错后我们能否回到原始页面，用户提交的数据是否真实有效，如填写的所属省份与所在城市是否匹配，出生年月与身份证号是否匹配等。
4 兼容性测试
在各种配置不同操作系统上和分辨率不同的电脑上及使用不同的浏览器对其测试，看其是否可以正确显示，是否有图片和页面错位和太大太小等问题使有的部分无法看到，是否有图片或视频无法显示。
5 网络配置测试
看看网页是否可以打印或保存(如果是保密的网页或不想让别人保存的页面可以将其作成FLASH格式的，不让用户保存)，看看网页冗余代码是否过多或容量太大导致网络运行速度过慢。
6 负载测试
多个用户同时上网，其最大的承受能力是多大，如果超过了这个极限会有何反应。
7 压力测试
看看几百，几千甚至几万个人同时上网网页还能显示不，运行速度会有怎样的变化，是否响应时间太长或运行过慢，到啥时候会崩溃。
8 安全测试
用户名和密码是否有长度限制，是否有复杂度限制，登陆次数是否受限，如果超过了登陆次数，关闭页面重新登陆是否还可以登陆进去，换了台电脑或在另外的地方登陆呢，WEB系统是否有超时限制，超时以后是否会提示登陆，日志文件是否记录登陆后用户进行的操作操作，是否记录登陆失败的操作，事物完成后，会不会记录拥护进行的操作，会不会记录用户名，是否在ASP，JSP，JAVAscrīpt，VBscrīpt等脚本语言里有设置可以访问服务器的语言，是否使用了安全套接字层协议SHTTP，若使用了这种协议，那摸在网页中是否有备份替换的页面。
9 接口测试
在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？
[ 本帖最后由 金子 于 2009-12-1 10:14 编辑 ] **** Hidden Message *****
答题: 简单概括为下面几个方面：
1 UI测试
2 链接测试
3 表单测试
4 兼容性测试
5 网络配置测试
6 负载测试
7 压力测试
8 安全测试
9 易用性测试等等
**** Hidden Message *****
答题:
一、功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或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，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
页:
[1]
