Web测试规范02.docx
《Web测试规范02.docx》由会员分享，可在线阅读，更多相关《Web测试规范02.docx（21页珍藏版）》请在冰点文库上搜索。
Web测试规范02
无线城市测试规范
前言：
本文基于的系统测试，不但需要检查和验证是否按照设计的要求运行，而且还要测试系统的适配,安全性,易用性。
简单的将测试分为8大部分：
测试种类
关注点
测试方法
测试用例
功能测试
产需，流程覆盖，正逆向用例
黑盒
性能测试
目标值，关注指标，目标配置．
白盒
用户界面测试
图片，风格，导航。
黑盒，用户体验
兼容性测试
机型，浏览器，操作系统
黑盒
安全性测试
登录，验证码，安全扫描，
灰盒
接口测试
外部接口，鉴权，性能，监控
灰盒
故障恢复测试
错误处理方法，恢复机制。
黑盒
安装/反安装测试
黑盒
一、功能测试
●概述：
确保测试的功能正常，并且按照需求规定实现。
确保业务规则按照需求文档实现（如有可变的需求点，要在评审时提出，即便是变化的需求要找到变化原则或底线）。
重点关注内容，设计样式，交互内容，交互结果等，并以此来核实应用程序及其内部进程。
●目标
利用有效的和无效的数据来覆盖测试各个用例流程，以核实以下内容：
✧在使用有效数据时得到预期的结果
✧在使用无效数据时显示正常的错误消息或警告消息。
1.1测试输出框测试
单一界面测试的参考表格如下：
编号
场景/条件
操作
预期结果
1.
用户通过用户界面输入信息
输入任何内容，重填【正常】
页面恢复到初始状态
2.
用户通过用户界面输入信息
输入刚好等于字数限制的正确信息（边界值），提交【正常】
1.所填信息正确保存到相应的数据库表中
2.页面提示提交成功
3.
用户通过用户界面输入信息
输入略超过字数限制的正确信息（超范围值），提交【异常】
1.所填信息不能正确保存到相应的数据库表中
2.页面提示字数超长
3.引导用户定位超长输入
4.
用户通过用户界面输入信息
输入略少于字数限制的正确信息（典型值），提交【正常】
1.所填信息正确保存到相应的数据库表中
2.页面提示提交成功
5.
用户通过用户界面输入信息
输入*非法字符，提交【异常】
1.所填信息不能保存到相应的数据库表中
2.页面提示有错误输入
3.引导用户定位错误输入
6.
用户通过用户界面输入信息
输入为空，提交【异常】
1.应有必填项判断
2.页面提示必填项不能为空
3.引导用户定位必填项
4.所填信息不能保存到相应的数据库表中
7.
用户通过用户界面输入信息
该输入汉字的输入英文字符，提交
注：
可选类型汉字/字母/数字/下拉框
1.页面提示错误输入
2.引导用户定位错误输入项
3.所填信息不能保存到相应的数据库表中
1.2登录/注册场景测试内容
编号
场景/条件
操作
预期结果
1.
初始页面
页面元素完整，显示同设计一致
2.
不存在用户登录或空用户
非注册用户登录（admintest）
系统登录失败，并提示：
需求中合适的提示信息
3.
密码错误登录或空密码
系统登录失败，并提示：
需求中合适的提示信息
4.
验证码反复刷新，有效时间验证，失效验证码使用。
错误，过期，正确验证码使用。
系统登录成功/失败，并提示：
需求中合适的提示信息
5.
系统登录安全性。
用户多次登录失败是否限制。
多次登录失败，提示：
需求中合适的提示信息
6.
登录后session失效时间
长时无操作自动退出。
自动退出后，提示：
需求中合适的提示信息
7.
多ID登录
多ID登录场景。
依据产需测试
8.
多终端同一用户登录
多终端同一用户登录
据产需测试
9.
修正密码
修改密码后，之前密码登录，密码未变化修正。
是否即刻生效。
提示信息：
需求中合适的提示信息
10.
忘记密码
手机，邮箱修改密码。
修改密码信息的失效性。
修改密码可用。
过期修正链接不可使用。
过期验证码无法使用。
11.
特殊名称注册，重复名称注册
提示信息：
需求中合适的提示信息
注：
除测试所提供的功能外，还需添加Cookies测试
参考如下：
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在页面计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。
测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
如果在cookies中保存了注册信息，请确认该cookie能够正常工作而且已对这些信息已经加密。
如果使用cookie来统计次数，需要验证次数累计正确。
1.3链接测试内容
链接是互联网应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。
链接测试可分为三个方面。
1）测试所有链接是否按指示的那样确实链接到了该链接的页面；正确性
2）测试所链接的页面是否存在，死链接的排除；存在性
3）保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
继承性。
链接测试可以自动进行，现在已经有许多工具可以采用。
链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
编号
场景/条件
操作
预期结果
1.
页面URL安全性
页面参数是否明文传输。
2.
逐个页面提交工具测试
工具验证
Xenu检查链接可用性。
3.
验证链接可用，与提示内容相符。
5.
1.4搜索测试
搜索是门户网站的基本功能。
是在一定范围内准确定位信息的手段。
由于互联网信息的更新速度较快以及用户信息定位的需求，搜索功能有以下特
1）搜索具备相对稳定的搜索规则。
2）在一定时间内搜索内容要有稳定性。
3）搜索得到内容准确关联搜索关键字。
4）更新信息可被搜索到。
编号
场景/条件
操作
预期结果
1.
默认搜索条件
2.
含有特殊字符，脚本语言
含有特殊字符搜索
可被搜索而不报错。
3.
空格处理
过滤空格或分词处理。
根据相关规则测试。
1.5数据库测试（未细化）
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。
在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。
数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。
结合业务功能测试
采取措施：
深刻理解需求说明文档，手工测试为主。
二、性能测试
概述，主要关注以下指标值并对测试出的数据做定量的分析
响应时间
事务处理速率
吞吐量
错误率
性能评测的目标是核实性能需求是否都已满足。
目标，核实下列情况下的性能行为：
正常的预期工作量
预期的最繁重工作量
正常的预期工作量下负载工作的平稳度。
需考虑的特殊事项：
✧可创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。
✧最好使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。
✧应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
其所用的数据库应该是实际大小或相同缩放比例的数据库。
✧多用户不同网络条件下的连接速度是否满足要求
性能测试样例：
（待补充）
1
2
2.1响应速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化。
如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。
而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
通常，对于网站类的页面响应遵循3－5－8秒原则。
2.2负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。
负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
例如：
Web应用系统能允许多少个用户同时在线？
如果超过了这个数量，会出现什么现象？
Web应用系统能否处理大量用户对同一个页面的请求？
2.3压力测试
●概述：
这里的具体包含了负载测试以及压力测试
●目标：
核实下列行为下的系统行为
✧确定测试对象在给定时间内能够持续处理的最大负载或工作量（包括长时间处理多个用户相同的且性能最坏的业务）
✧确定并确保系统在超出最大预期工作量的情况下仍能正常运行，并评估其性能特征，包括响应时间、事务处理速率和其他与时间相关的内容
✧服务器上几乎没有或根本没有可用的内存（RAM）
步骤一：
执行单步任务测试
步骤二：
多用户多任务测试
参考表格如下：
单步任务参考表格：
任务A描述
连续运行时间
故障发生的时刻
故障描述
……
统计分析
任务A无故障运行的平均时间间隔
（CPU小时）
任务A无故障运行的最小时间间隔
（CPU小时）
任务A无故障运行的最大时间间隔
（CPU小时）
任务B描述
连续运行时间
故障发生的时刻
故障描述
……
统计分析
任务B无故障运行的平均时间间隔
（CPU小时）
任务B无故障运行的最小时间间隔
（CPU小时）
任务B无故障运行的最大时间间隔
（CPU小时）
多用户多任务测试参考表格：
极限名称A
最大并发用户数量
前提条件
输入/动作
输出/响应
是否能正常运行
例如10个用户并发操作
例如20个用户并发操作
…
极限名称B
前提条件
输入/动作
输出/响应
是否能正常运行
…
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。
压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。
黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么?
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。
可访问性对用户来说是极其重要的。
如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。
系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。
出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
●瞬间访问高峰（并发测试）
如果站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。
负载测试工具能够模拟X个用户同时访问测试站点。
●每个用户传送大量数据（大数据量测试）
网上书店的多数用户可能只订购1-5书，但是大学书店可能会订购5000本有关的课本?
或者一个人购买圣诞礼物送1000个人（当然每个人都有自己的邮件地址）系统能处理单个用户的大量数据吗?
●长时间的使用（疲劳强度测试）
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。
如果站点提供基于web的email服务，那么点最好能持续运行几个月，甚至几年。
可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。
你可以想象组织100个人同时点击某个站点。
但是同时组织100000个人呢。
通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。
而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
三、用户界面测试
用户界面是沟通功能和用户的直接途径，对于互联网应用尤其重要。
用于核实用户与软件之间的交互是否正常。
一般从以下几个方面考虑
1）合适性和正确性
2）容易理解
3）风格一致
4）及时反馈信息
5）出错处理
6）适应各种水平的用户
7）规范化
8）个性化
9）合理布局和谐色彩
通过以上各方面的考虑实现交互的易用高效。
具体检查点参考表格如下：
检查项
窗口切换、移动、改变大小时正常吗？
各种界面元素的文字正确吗？
（如标题、提示等）
各种界面元素的状态正确吗？
（如有效、无效、选中等状态）
各种界面元素支持键盘操作吗？
各种界面元素支持鼠标操作吗？
对话框中的缺省焦点正确吗？
数据项能正确回显吗？
对于常用的功能，用户能否不必阅读手册就能使用？
执行有风险的操作时，有“确认”、“放弃”等提示吗？
操作顺序合理吗？
按钮排列合理吗？
导航帮助明确吗？
提示信息规范吗？
1
2
3
3.1导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。
通过考虑下列问题，可以决定一个Web应用系统是否易于导航：
导航是否直观？
Web系统的主要部分是否可通过主页存取？
Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。
Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。
很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。
确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。
一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。
图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。
Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下
（5）最后，需要验证的是文字回绕是否正确。
如果说明文字指向右边的图片，应该确保该图片出现在右边。
不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。
如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。
另外，图案和图片可能会转移用户的注意力。
3.3内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。
例如，在商品价格列表中，错误的价格可能引起成本异常问题；信息的准确性是指是否有语法或拼写错误;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓“相关文章列表”。
对于开发人员来说，可能先有功能然后才对这个功能进行描述。
大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。
测试人员应确保站点看起来更专业些。
过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。
最后，需要确定是否列出了相关站点的链接。
很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。
但是如果用户无法点击这些地址，他们可能会觉得很迷惑。
3.4表格测试
需要验证表格是否设置正确。
用户是否需要向右滚动页面才能看见产品的价格？
把价格放在左边，而把产品细节放在右边是否更有效?
每一栏的宽度是否足够宽，表格里的文字是否都有折行？
是否有因为某一格的内容太多，而将整行的内容拉长?
3.5整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。
例如：
当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？
整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。
一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
四、兼容性测试
核实测试对象在不同的软件和硬件配置中的运行情况
目标：
确定系统能在下列条件下正常运行
✧在各种所需的硬件和软件配置中
✧在各种O/S平台或是浏览器下的兼容性测试
相关表格如下：
检查项
测试人员的类别及其评价
系统能在各种软/硬件条件下运行吗？
具体有哪些呢？
系统支持多种操作平台吗？
支持多种浏览器吗？
系统对AD/FireWall敏感吗？
4
4.1平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。
Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。
这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
4.2浏览器测试
浏览器是Web页面最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持。
例如，ActiveX是Microsoft的产品，是为InternetExplorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。
另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。
不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。
在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
4.3分辨率测试
页面版式在640x400、600x800或1024x768的分辨率模式下是否显示正常?
字体是否太小以至于无法浏览?
或者是太大?
文本和图片是否对齐?
4.4wifi/cmnet速率
是否有这种情况，用户使用28.8modem下载一个页面需要10分钟，但测试人员在测试的时候使用的是T1专线?
用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。
最后，需要确认图片不会太大。
4.5打印
用户可能会将网页打印下来。
因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。
有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。
有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。
测试人员至少需要验证订单确认页面打印是正常的。
4.6组合测试
最后需要进行组合测试。
600x800的分辨率在MAC机上可能不错，但是在IBM兼容机上却很难看。
在IBM机器上使用Netscape能正常显示，但却无法使用Lynx来浏览。
如果是内部使用的web站点，测试可能会轻松一些。
如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。
如果所有的人都使用T1专线，可能不需要测试下载施加。
（但需要注意的是，可能会有员工从家里拨号进入系统）有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。
但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
采取措施：
根据实际情况，采取等价划分的方法，列出兼容性矩阵
五、安全测试
●概述：
确保系统Web应用下的安全性
●目标：
核实下列情况下的性能行为
✧系统是否有超时的限制
✧相关的重要信息是否写进日志、是否可追踪
✧使用了安全套接字时，测试加密是否正确，信息是否完整
相关表格如下：
检查项
系统有超时限制吗？
（如标题、提示等）
相关的重要信息写进了日志吗？
能有效跟踪他们吗？
传输信息加密了吗？
传过来的信息完整吗？
Web站点收集的用户资料只能在公司内部使用。
如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5
5.1目录设置
Web安全的第一步就是正确设置目录。
每个目录下应该有index.html或main.html页面，这样就不会显示该目录下的所有内容。
（当前的页面最好与过期的页面分开保存）
5.2SSL
很多站点使用SSL进行安全传送。
进入一个SSL站点是因为浏览器出现了警告消息，而且在地址栏中的HTTP变成HTTPS。
如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面（适用于3.0以下版本的浏览器，这些浏览器不支持SSL）。
当用户进入或离开安全站点的时候，请确认有相应的提示信息。
是否有连接时间限制？
超过限制时间后出现什么情况？
5.3登录
有些站点需要用户进行登录，以验证他们的身份。
这样对用户是方便的，他们不需要每次都输入个人资料。
你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。
用户登录是否有次数限制?
是否限制从某些IP地址登录?
如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗?
口令选择有规则限制吗?
是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如30分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
5.4权限管理
对于网站管理的后台，应该有设计用户的层级，对应于不同级别的用户有各个级别的浏览和编辑权限。
5.5系统版本
部署系统的容易，文件服务器，负载均衡器，数据库软件是否都要按时补丁。
特别对于已经爆出的安全漏洞要及时打补丁。
5.6日志文件
在后台，要注意验证服务器日志工作正常。
日志是否记所有的事务处理?
是否记录失败的注册企图?
是否记录被盗信用卡的使用?
是否在每次事务完成的时候都进行保存?
记录IP地址吗?
记录用户名吗?
5.7脚本语言
脚本语言是常见的安全隐患。
每种语言的细节有所不同。
有些脚本允许访问根目录。
其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。
找出站点使用了哪些脚本语言，并研究该语言的缺陷。
还要
升级会员 