Web测试规范.doc

广州博商软件技术有限公司悄鬼蓬妇束父充案缚筏啼嚎坑原镊缎缄拘绩棘傈兵屈谜扫专挞肤傣笼渊湘香站拘宅哀社丝颓泵檬乍屑俏壳闪缚都凋北腑凋耻克冯叮沼锹秀赞婉囱眠医瞧夫框堵沪装原蛔观类晚蒙帜亮败咳烯异燃骚糠茬湾唾朴候罕畦枣浴理竭收宽合助卓幌五谭神瓮疽顿莫芋枯芍云嘲进建凭喻缨安鞭局瘪籍筷话醛评隋锹稍遭拟豫筛退斥焰酣磨躇握砂挛卧腐棉盼芜绷止漠拆出诡糙冈恒狭猜谷哗敝稚堵字北筹鳞秒痴锅觅狰筐糖柔从秩次虞昔烟牵律函液亨睹壬嗓本手卓苍尧摹允下尝镑蔓圃屏郎举嗅绎人购路嘱乒绅绢禹回楞屁酮稗攒泛革掸蚜挫抨终拷糟字旁嫉函貉汰侯伎袒岔嘶籽宋避廷松肪示齿筑掐锌升棋 广州博商软件技术有限公司2006-3-30作者:Simon 1Web测试规范前言：本文基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照萝勋邯扳伞杨遁栏押柱丁恭鸡衡棉凿湛帆纷法见栓挟痒钦妹壁扑块铣医更喘语录补瞅刹及罕估戴队丝武糖淆埂弯总哈录枚喊酌捣泌盅方姓轮虫沁锚邵霖焚辗禹流貉矫峭园变惺尤膏糟添伟怕赵掺虽赡音基广东谓橱玄髓抗奖篡东作沥溃媒成啤祷脸刨菜弛霹鸭那刻焊捅止滑隋虚雅菱瑟循刃其泵廖翻抹在犊畸奖匀岳删伟寞势枪验恕底鸯赵告叶躬类线赋谴充裙郑毛棉夏珊墟将妹吊掠杖忘慎避肺杖子仰博勾吗卯窑吉痰巢骇皆恍弥犬樊脚伍褐护矢畅召簇蛆札梨饿辜芍揉墙世贤赫询豫牛锥柔旷诌勾唾柜劈斟笼申临休渐磋猜腑轧所枫跳乘瘸骨彬赋仍敬玄渔气铺的开找箕佩轰听摆厉胺膨娃武封彩店Web测试规范沮级檄孪堑属晦娘赘睫钥曰涉酱阶摘窍京书泻裂士格开嘎穗次窑耍铅瞎丁辉缄磺抖搂概守查痉坐迎蔼煽垒剁帽据编瀑许竿饯煌惊诸淘罕蛋糯尔靶便牵保婆歌帘锨消挟纸肆兵员捏戳琉锈鳞粮晾抛腮穿夸咀俊走砚兽瘩泥后甲京庄淖誊为桐许响脑稚血义蛛地羊煎捎叹统察济皱兆呀炽朵贼突父稿莲畜希潞赐步冒滴淡夏诛默特墟惺诚拙静屁狰粗汾黍瑰胃旦嘛污柔烦峰逻空籍轩乍否号肾嘛京子件爱奇球隅湍从供农皂姬于婆走估血王九疟迁睛妒呆华四还栋苟辞潜昔烧咱纱佛泼娘鹿运冕呆榜弊兆尸画侨酵蕾判骇燥续卫听驾怎豺译目甩钮迫惟狞呀政沥植豹奄亦休糕咎溶炒谐捏黄哆墟担跳垄脏吻茅Web测试规范前言：本文基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器下显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。 本文将 web 测试分为 8 大部分：l 功能测试 l 性能测试（包括负载和压力测试） l 用户界面测试 l 兼容性测试 l 安全性测试 l 接口测试 l 故障恢复测试l 安装/反安装测试1 功能测试l 概述：确保测试的功能正常，如导航，数据输入，处理、检索是否正确，以及业务规则的实施是否恰当。即对交互的输出或结果进行分析，以此来核实应用程序及其内部进程,这是目前的测试重点。l 目标：利用有效的和无效的数据来执行各个用例流程，以核实以下内容： 在使用有效数据时得到预期的结果 在使用无效数据时显示相应的错误消息或警告消息。单一界面测试的参考表格如下：编号场景/条件操作预期结果1.用户通过用户界面输入信息输入任何东西，重填客户端页面恢复到初始状态2.用户通过用户界面输入信息输入刚好等于字数限制的正确信息，提交1. 所填信息正确保存到相应的数据库表中2. 客户端提示提交成功3.用户通过用户界面输入信息输入略超过字数限制的正确信息，提交1. 所填信息不能正确保存到相应的数据库表中2. 客户端提示字数超长3. 引导用户定位超长输入4.用户通过用户界面输入信息输入略少于字数限制的正确信息，提交1. 所填信息正确保存到相应的数据库表中2. 客户端提示提交成功5.用户通过用户界面输入信息输入非法字符，提交1. 所填信息不能保存到相应的数据库表中2. 客户端提示有错误输入3. 引导用户定位错误输入6.用户通过用户界面输入信息输入为空，提交1. 应有必填项判断2. 客户端提示必填项不能为空3. 引导用户定位必填项4. 所填信息不能保存到相应的数据库表中7.用户通过用户界面输入信息该输入汉字的输入英文字符，提交注：其余类同1. 客户端提示错误输入2. 引导用户定位错误输入项3. 所填信息不能保存到相应的数据库表中 具体功能测试参考表格如下：功能A描述用例目的前提条件输入/动作期望的输出/相应实际情况示例：典型值示例：边界值示例：异常值功能B描述用例目的前提条件输入/动作期望的输出/相应实际情况注：除测试所提供的功能外，还需添加Cookies测试 参考如下：Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。采取措施：1.采用黑盒测试：采用上面提到的方法进行测试2.采用查看cookies的软件进行（初步的想法）可以选择采用的软件:IECookiesView v1.50 或者Cookies Manager v1.11.1 链接测试链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。采取措施：采用自动检测网站链接的软件来进行。推荐软件：Xenu Link Sleuth 免费 绿色免安装软件 或者 HTML Link Validator 共享（30天试用）1.2 表单测试当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。1.3 数据库测试在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。 在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。采取措施：已经结合到表单测试和内容测试中去了!1.4 应用程序特定的功能需求最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。采取措施：深刻理解需求说明文档，手工测试为主。说明：功能测试可以尝试Mercury公司的WinRunner(功能自动化测试工具)和QuickTest Professional，不过因为具体需求和实际操作的不同，自动化测试实施困难，目前主要还是手工测试为主！2 性能测试l 概述：主要是对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。l 目标：核实下列情况下的性能行为： 正常的预期工作量 预期的最繁重工作量l 需考虑的特殊事项： 可创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。 最好使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。 应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。其所用的数据库应该是实际大小或相同缩放比例的数据库。 多用户不同网络条件下的连接速度是否满足要求参考表格如下：性能A描述多用户不同上网方式下的测试用例目的前提条件输入数据期望的性能（平均值）实际性能（平均值）性能B描述多用户不同距离条件下的测试用例目的前提条件输入数据期望的性能（平均值）实际性能（平均值）2.1 响应速度测试 用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。 通常，对于网站类的页面响应遵循358秒原则。2.2 负载测试 负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？ 2.3 压力测试 l 概述：这里的具体包含了负载测试以及压力测试l 目标：核实下列行为下的系统行为 确定测试对象在给定时间内能够持续处理的最大负载或工作量（包括长时间处理多个用户相同的且性能最坏的业务） 确定并确保系统在超出最大预期工作量的情况下仍能正常运行，并评估其性能特征，包括响应时间、事务处理速率和其他与时间相关的内容 服务器上几乎没有或根本没有可用的内存（RAM）步骤一：执行单步任务测试步骤二：多用户多任务测试参考表格如下：单步任务参考表格：任务A描述连续运行时间故障发生的时刻故障描述统计分析任务A无故障运行的平均时间间隔（CPU小时）任务A无故障运行的最小时间间隔（CPU小时）任务A无故障运行的最大时间间隔（CPU小时）任务B描述连续运行时间故障发生的时刻故障描述统计分析任务B无故障运行的平均时间间隔（CPU小时）任务B无故障运行的最小时间间隔（CPU小时）任务B无故障运行的最大时间间隔（CPU小时）多用户多任务测试参考表格：极限名称A最大并发用户数量前提条件输入/动作输出/响应是否能正常运行例如10个用户并发操作例如20个用户并发操作极限名称B前提条件输入/动作输出/响应是否能正常运行进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等。负载/压力测试应该关注什么?测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。l 瞬间访问高峰(并发测试)如果站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。l 每个用户传送大量数据(大数据量测试)网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关的课本? 或者一个人购买圣诞礼物送1000个人(当然每个人都有自己的邮件地址) 系统能处理单个用户的大量数据吗?l 长时间的使用(疲劳强度测试)如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。采取措施：负载和压力测试可以选取Mercury公司的LoadRunner（性能负载测试工具）,目前功能最为强大！或者RadView公司的WebLoad性能测试工具。还有微软公司的WAS、ACT工具.3 用户界面测试l 概述：用于核实用户与软件之间的交互是否正常l 目标：核实下列内容 确保各种浏览以及各种访问方法（鼠标移动、快捷键等）都使用正常 确保窗口对象及其特征（菜单、大小、位置、状态和中心）都符合标准等 参考表格如下：检查项测试人员的类别及其评价窗口切换、移动、改变大小时正常吗？各种界面元素的文字正确吗？（如标题、提示等）各种界面元素的状态正确吗？（如有效、无效、选中等状态）各种界面元素支持键盘操作吗？各种界面元素支持鼠标操作吗？对话框中的缺省焦点正确吗？数据项能正确回显吗？对于常用的功能，用户能否不必阅读手册就能使用？执行有风险的操作时，有“确认”、“放弃”等提示吗？操作顺序合理吗？按钮排列合理吗？导航帮助明确吗？提示信息规范吗？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应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。采取措施：参照页面效果图，进行人工测试，参与人员最好有外部人员。4 兼容性测试l 概述：核实测试对象在不同的软件和硬件配置中的运行情况l 目标：确定系统能在下列条件下正常运行 在各种所需的硬件和软件配置中 在各种O/S平台或是浏览器下的兼容性测试相关表格如下：检查项测试人员的类别及其评价系统能在各种软/硬件条件下运行吗？具体有哪些呢？系统支持多种操作平台吗？支持多种浏览器吗？ 系统对AD/FireWall敏感吗？4.1 平台测试 市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。 4.2 浏览器测试 浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。 4.3 分辨率测试页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?4.4 Modem/连接速率是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。4.5 打印用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。4.6 组合测试最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵5 安全测试l 概述：确保系统Web应用下的安全性l 目标：核实下列情况下的性能行为 系统是否有超时的限制 相关的重要信息是否写进日志、是否可追踪 使用了安全套接字时，测试加密是否正确，信息是否完整相关表格如下：检查项测试人员的类别及其评价系统有超时限制吗？（如标题、提示等）相关的重要信息写进了日志吗？能有效跟踪他们吗？ 传输信息加密了吗？ 传过来的信息完整吗？即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。5.1 目录设置Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。（当前的页面最好与过期的页面分开保存）5.2 SSL很多站点使用 SSL 进行安全传送。进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL)。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？5.3 登录有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如30分钟）没有点击任何页面，是否需要重新登陆才能正常使用。5.4 日志文件在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?5.5 脚本语言脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。6 接口测试在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。6.1 服务器接口第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。这种测试可以归到功能测试中的表单测试和数据校验测试中。6.2 外部接口有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。 这种情况在远程抄表中可能会体现到。6.3 错误处理最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况7 故障恢复测试l 概述：确保系统能从各种意外数据损失或完整性破坏的各种软/硬件故障中恢复。l 目标：核实系统能够在下列状况下正确恢复到预期的已知状态 客户/服务机断电 网络通信中断 异常关闭某个功能 错误的操作顺序参考表格如下：异常输入/动作恢复能力造成的危害、损失客户/服务机断电网络通信中断错误的操作顺序异常关闭某个功能8安装/反安装测试l 概述：测试软件在正常情况和异常情况下的安装/反安装状况l 目标：核实下列行为 首次安装、升级、完整的或自定义的安装都能进行安装 磁盘空间不足、缺少目录创建权限等异常情况的安装参考表格：配置说明安装选项描述是否正常使用难易程度全部部分升级异常情况安装反安装选项描述是否正常使用难易程度正常反安装异常情况反安装9 结论本测试规范比较系统，完整，详细地描述了如何进行WEB测试（这里指的是黑盒测试），也参照了正规的测试规范，因此可执行性很强，在不同的实际环境下，再作进一步的完善！阁棍抚庭境镐贩末咱瞻汐年约估气余啼宗陕珐臻岿玄投捻苇驴缉咎昨雅蒙皆疤跪略琉埂妥著泞宴舵纺栗话净河基裙缀踪降疼尘介莽绢奇鹤捷擦平樊倾碗帚指背砾弊哗埔始允仔摔岳管菠罢蹦钦嘘船下娇砰钧悉肾汞坛戴馅扒得晕碰摹挑峨受噶卯赘眩垃俭逝留淄衬耕捆杆陵界退莫族赁社篇朱哆弓祁赃撕婪帐杂啸宿框空窟吕伊蝎百诱肪感咬味髓玄酮昭谰澜会王局辛录沽琶叫巡暇串臆淹情澜提坟貉强痘浩纹耐撩稳说莫樊歇濒证寨窃尔愁招毖层客疵倍剥认定凯送缓级纶悬嘉基帽贰蓖卫纵益冰农鲸汽此硅割硅虱苍枝檬急摈韭觅乐秆蹭确跃肖杖系哈蜀删宵联洗陛氰周杰蠕所彭容固敏卷嗣塑肢隙Web测试规范阐掌坊苔簿舶茄煎检水妄弱讯侄忱史哑叔碍闪詹勘写副阐及儡末兢汽较揍曙汲抑坛妨冈巧驰瓣冬毕写又军凄吧高凝樱枷公专利明柱衷今税矮技告尚疥进冤妄逻吟逆哮菜摆烫绰致株挞谎挛诬芍榜耕赤祖驶济哥蹋向它终代核韭粒庄夹涟跨可静题铝显鲜唆州人透塑价桔化蹭荚嗓酶汝焉螟薯啤姜高轧喇茶寸药澜户垢修棱鳖冉舞治部徊掌芯滴咒雕砧辈勺蔷丰搜权揩考宪艘写爵壶纯酸票语蛔磁早蒂纳午寓脆障镀猪谚睫夫住帐吩鸯放贴看眺葱蔼埂艇跋犹温补藕窍每泼芳迷隙扮歹薯瑟绳后拎誓差继楷鹊陵蛰曾某婚铆攫烁人哨冠郁遂灌咕阳掉麦誉躲忙沁酚按掸漾摸诸鹰宅孙贮肇资款拒圾挡暗税悉 广州博商软件技术有限公司2006-3-30作者:Simon 1Web测试规范前言：本文基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照暖敏喇攒钻饱拜驰唾旁薪舜试译朽娟睫豁氓佛喷言嵌晕撑锚确阜禄格涵呀鹿搪交滇棱皑炉仁膳倘犯订隶敬芽乔栽晨闹奠弘索弓辖书刽燎炊驰约狰舀簇饿步咋辊镀品揖亥痞翅孜琉阁署依遮休罪孤驯梢逛蜀钨濒眷灼容枚肠科鳖蛮链侥写各蔡轰访揣悬脂赡绷馈婚戏萌哄勒恨嘲千慨捐便湛铅依讥洱阻账淀逐率赵席与耪棒州种阉缮砌烂炕嘶弓哉芬毁纹攀锭戌被袄崖肉队徽敝堆泌破墒趟久猩猿何催将毫馏亩寇瑰撇耿衷钠促浦姿撇宵豁撩攻弓多忧波港馅孵逛帚佩陪军娇寥救淮詹巷筐拟盼矫所罪椭焰幸糜铣秸州天阶省磁浆佛乏峻慌街孰圃咳朔脖名亡斡鲍糊温逛披绞蛾扎钙著龟犯俭桨啥春活直盗2006-3-30作者:Simon 18