关于web测试的资料集

月上百合

最近发现论坛里有好多做web测试的同行，我也趁这两天有空，把我手上的关于web测试方面的资料贴上来，大家看看，了解一下，为了方便查看，我不用附件形式了，发贴形式，大家如想收集到自己电脑里，可以copy一下。
安全性测试：
Web应用系统的安全性测试区域主要有：
　　（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
　　（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
　　（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
　　（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
　　（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

导航测试：        导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
        　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
        　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
        　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
整体界面测试 ：
整体界面是指整个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应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
    （1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
　　（2）验证所有页面字体的风格是否一致。
　　（3）背景颜色应该与字体颜色和前景颜色相搭配。
　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
　　3、内容测试
　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证 是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而， Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将 web 测试分为 6 个部分：
1.       功能测试
2.       性能测试（包括负载/压力测试）
3.       用户界面测试
4.       兼容性测试
5.       安全测试
6.       接口测试
本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。
1 功能测试
1.1 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可 分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页 面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）
1.2 表单测试
当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送 信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解 释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的 正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指 定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3 数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。
1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
　 　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行 保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。
采取措施：
     1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
可以选择采用的软件
IECookiesView v1.50
Cookies Manager v1.1
1.5 数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
采取措施：暂时没有更好的测试方法
     考虑结合到1.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
采取措施：深刻理解需求说明文档
1.7 设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开 发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
2 性能测试
2.1 连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某 个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现 象？Web应用系统能否处理大量用户对同一个页面的请求？
2.3 压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性 对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有 黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。
每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用测试工具WAS、ACT协助进行测试

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应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷； 信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文 章列表"。
对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的 时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内 容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可 能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望 自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户 无法点击这些地址，他们可能会觉得很迷惑。
3.4 表格测试
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?
3.5 整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
4 兼容性测试
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 安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"… com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以 估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情 况？
5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统 阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
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 结论
　  无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

[ 本帖最后由 月上百合 于 2010-6-23 10:47 编辑 ]

月上百合

发个用例，不会写的可以看看，学习一下，这也是以前从51上down的，不可以全面，大家只是学习一下方法吧。

[ 本帖最后由 月上百合 于 2010-6-23 10:28 编辑 ]

月上百合

测试方法
1．        划分等价类
把所有可能的数据输入划分为若干部分，然后从每一部分选择少数具有代表性的数据作为测试用例。
（1）有效等价类
   合理，有意义的输入数据构成的集合，检验程序是否实现规格说明预先规定的功能和性能。
（2）无效等价类
   不合理，无意义的输入数据构成的集合，检验程序的容错能力。
2．        边界值分析
       大量的错误发生在输入或输出的边界上，而不是某个范围的内部。
3．        语句覆盖
       设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次，语句覆盖是最弱的逻辑覆盖在准则。
4．        判定覆盖
       设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值都能满足。
5．        条件覆盖
       设计若干测试用例，运行被测程序，要使判断中的每个条件的可能取值至少满足一次。
6．        路径覆盖
       覆盖所有可能的路径。
7．        判定-条件覆盖
      使得每个条件的所有可能至少出现一次，并且至少每个判断本身的判断结果出现一次。
8．        功能测试的常用方法
（1）        页面链接检查，每一个链接是否有对应的界面
（2）        相关性检查，删除/增加一项会不会对其他项产生影响，如果产生影响，是否正确
（3）        检查按钮功能是否正确
（4）        字符串长度检查，输入超出需求所说明的字符串长度的内容，看系统是否检查，会不会出错。
（5）        字符类型检查
（6）        标点符号检查
（7）        中文字符处理 ，乱码或出错
（8）        检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。
（9）        信息重复，在一些需要命名，且名字唯一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的前后输入空格，看系统是否处理。
（10）        检查删除功能 ，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理
选择一个或多个时又如何处理
（11）        检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
（12）        检查修改重名，修改时把补能重名的项改为已存在的内容，看会否处理，报错，同时看会否报和自己重名的错。
（13）        重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理。
（14）        检查多次处理back键的情况
（15）        Search检查:在有search功能的地方输入系统存在和不存在的内容，看结果是否正确；
如果可以输入多个search条件，同时可以添加合理和不合理的条件，看系统是否处理正确。
（16）        输入信息的位置，输入信息时，光标的位置
（17）        上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息。
（18）        必填项检查，必填项是否有提示信息
（19）        快捷键检查，是否支持常用快捷键检查
（20）        回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。
9．        界面测试的常用方法
     界面测试要遵循的规则：
          一．易用性，按钮名称通俗易懂，望文知意。
              （1）完成相同或相近功能的按钮，要用Frame框起来，常用按钮要有快捷键
              （2）完成同一功能或任务的元素要集中放置，减少鼠标的移动距离
              （3）按功能将界面划分区域块，并要有功能说明和标题
              （4）界面要支持键盘自动浏览按钮功能，Tab，回车键等
（5）界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
（6）同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
（7）分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
（8）默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
（9）可写控件检测到非法输入后应给出说明并能自动获得焦点
（10）Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
（11）复选框和选项框按选择几率的高底而先后排列。
（12）复选框和选项框要有默认选项，并支持Tab选择。
（13）选项数相同时多用选项框而不用下拉列表框。
（14）界面空间较小时使用下拉框而不用选项框。
（15）选项数叫少时使用选项框，相反使用下拉列表框。
（16）专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
         二．规范性，通常界面设计都按Windows界面的规范来设计
（1）常用菜单要有命令快捷方式
（2）完成相同或相近功能的菜单用横线隔开放在同一位置。
  （3）菜单前的图标能直观的代表要完成的操作。
（4）菜单深度一般要求最多控制在三层以内
（5）工具栏要求可以根据用户的要求自己选择定制。
（6）相同或相近功能的工具栏放在一起。
（7）工具栏中的每一个按钮要有及时提示信息。
（8）一条工具栏的长度最长不能超出屏幕宽度。
（9）工具栏的图标能直观的代表要完成的操作。
（10）系统常用的工具栏设置默认放置位置
（11）工具栏太多时可以考虑使用工具箱。
（12）工具箱要具有可增减性，由用户自己根据需求定制。
（13）工具箱的默认总宽度不要超过屏幕宽度的1/5。
（14）状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
（15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
（16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
（17）菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感
（18）菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
（19）右键快捷菜单采用与菜单相同的准则。
           三．独特性
（1）　安装界面上应有单位介绍或产品介绍，并有自己的图标。
（2）　主界面，最好是大多数界面上要有公司图标。
（3）　登录界面上要有本产品的标志，同时包含公司图标。
（4）　帮助菜单的“关于”中应有版权和产品信息
（5）　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
           四．安全性
   （1）最重要的是排除可能会使应用非正常中止的错误。
（2）应当注意尽可能避免用户无意录入无效的数据
（3）采用相关控件限制用户输入值的种类。
（4）当用户作出选择的可能性只有两个时,可以采用单选框。
（5）当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
（6）当选项特别多时，可以采用列表框，下拉式列表框。
（7）在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作
（8）对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
（9）对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
（10）对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
（11）对错误操作最好支持可逆性处理，如取消系列操作。
（12）在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
（13）对可能造成等待时间较长的操作应该提供取消功能。
（14）特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。
（15）与系统采用的保留字符冲突的要加以限制。
（16）在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
（17）有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

月上百合

测试计划的编写
1．        概念
描述软件测试努力的目标，范围，方法和焦点的文档。
测试用例：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
2．        测试计划的内容
(1)        标题
(2)        确定软件的版本号
(3)        修订文档历史，包括作者，日期和批示
(4)        目录表
(5)        文档的目的和适合的读者群
(6)        测试的目的
(7)        软件产品的概述
(8)        相关的文档列表，包括需求，设计文档，其他测试计划等
(9)        相关的标准和合法的需求
(10)        可跟踪性需求
(11)        相关的命名规范和标识符规范
(12)        整个软件项目的组织和人员/联系信息/责任
(13)        测试组织和人员/联系信息/责任
(14)        假设和依赖关系
(15)        项目风险信息
(16)        测试优先级和焦点
(17)        测试范围和限制
(18)        测试提纲，测试类型，特点，功能性，过程，系统，模块等
(19)        测试环境的设置和配置问题
(20)        数据库的设置需求
(21)        概述系统日志/错误日志/其他性能，有助于描述和汇报问题的屏幕捕获工具等
(22)        有助于测试者跟踪问题根源的具体软硬件工具的论述
(23)        测试自动化的可能性和概述
(24)        使用测试工具，包括版本，补丁等
(25)        使用的测试项目度量
(26)        报告需求和测试的可传递性
(27)        软件入口和出口准则
(28)        初始的理性测试阶段和标准
(29)        测试终止和重新开始的标准
(30)        人员安排
(31)        测试地点
(32)        用到的测试外的组织，他们的目的，责任，可传递性，联系人和协作问题
(33)        相关的财产，分类，安全性和许可证的问题
(34)        公开的一些问题
(35)        附录-词汇表，缩略语等

月上百合

这是一个同行对测试的总结，也很详细，大家也来看看学习一下。

软件测试中有关界面测试经验总结
1.应验证界面显示内容的完整性：
　　a) 报表显示时应考虑数据显示宽度的自适应或自动换行。
　　b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常;
　　2.应验证界面显示内容的一致性：
　　a) 如有多个系统展现同一数据源时，应保证其一致性;
　　3.应验证界面显示内容的准确性：
　　a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。
　　4.应验证界面显示内容的友好性：
　　a) 对统计的数据应按用户习惯进行分类、排序。
　　b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;
　　c) 界面内容更新后系统应提供刷新功能。
　　d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;
　　5.应验证界面提示信息的指导性：
　　a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。
　　b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。
　　c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。
　　d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);
　　6.应验证界面显示内容的合理性：
　　a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。
　　b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。
　　c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;
　　7.界面测试时，应考虑用户使用的方便性：
　　a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。
　　8.界面测试时，应考虑界面显示及处理的正确性：
　　a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。
　　b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复;
　　c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。
　　d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。
　　e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变;
　　9.界面测试时，应考虑数据显示的规范性：
　　a) 确保数据精度显示的统一：如单价0元，应显示为0.00元;
　　b) 确保时间及日期显示格式的统一;
　　c) 确保相同含义属性/字段名的统一;
d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。
1.1.1        文本框的测试

如何对文本框进行测试
a,输入正常的字母或数字。
b,输入已存在的文件的名称；
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入     256个字符，检查程序能否正确处理；
d,输入默认值，空白，空格；
e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
g,输入特殊字符集，例如，NUL及\n等；
h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：

1,输入非法数据；
2,输入默认值；
3,输入特殊字符集；
4,输入使缓冲区溢出的数据；
5,输入相同的文件名；

命令按钮控件的测试

测试方法：

a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

单选按钮控件的测试

测试方法：

a,一组单选按钮不能同时选中，只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

up－down控件文本框的测试

测试方法：

a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
c,直接输入超边界值，系统应该提示重新输入；
d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法：

a,条目内容正确，其详细条目内容可以根据需求说明确定；
b,逐一执行列表框中每个条目的功能；
c,检查能否向组合列表框输入数据；

复选框的测试

测试方法：

a,多个复选框可以被同时选中；
b,多个复选框可以被部分选中；
c,多个复选框可以都不被选中；
d,逐一执行每个复选框的功能；

列表框控件的测试

测试方法：

a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
b,列表框的内容较多时要使用滚动条；
c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

滚动条控件的测试

要注意一下几点：

a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
c,单击滚动条；
d,用滚轮控制滚动条；
e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试

a,控件间的相互作用；
b,tab键的顺序，一般是从上到下，从左到右；
c,热键的使用，逐一测试；
d,enter键和esc键的使用；

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作
案例演示:打开word中的"替换"对话框
测试本功能有通过测试和失败测试两种情况
通过测试:
1,输入内容直接查找,或查找全部
2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.


失败测试:
1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;


替换测试大体相同.
关于编辑操作窗口的功能测试的用例:
1,关闭查找替换窗口.不执行任何操作,直接退出;
2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
4,热键, Tab键.回车键的使用.


插入操作
1,插入文件
测试的情况
a,插入文件;
b,插入图像;
c,在文档中插入文档本身;
d,移除插入的源文件;
e,更换插入的源文件的内容;


2,链接文件
测试方法:
a,插入链接文件;
b,在文档中链接文档本身;
c,移除插入的源文件;
d,更换插入的源文件的内容.


3,插入对象
要测试的内容
a,插入程序允许的对象,如,在word中插入excel工作表;
b,修改所插入对象的内容.插入的对象仍能正确显示;
c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.


编辑操作
编辑操作包括剪切,复制,粘贴操作.


测试剪切操作的方法
a,对文本,文本框,图文框进行剪切;
b,剪切图像
c,文本图像混合剪切
复制操作方法与剪切类似.


测试时,主要是对粘贴操作的测试,方法是:
a,粘贴剪切的文本,文本框及图文框;
b,粘贴所剪切的图像;
c,剪切后,在不同的程序中粘贴
d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
e,利用粘贴操作强制输入程序所不允许输入的数据.


界面测试用例的设计方法
1,窗体
测试窗体的方法:
a,窗体大小,大小要合适,控件布局合理;
b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

2,控件
测试方法:
a,窗体或控件的字体和大小要一致;
b,注意全角,半角混合
c,无中英文混合.


菜单

进行测试时要注意
a,选择菜单是否可以正常工作,并与实际执行内容一致;
b,是否有错别字:
c,快捷键是否重复;
d,热键是否重复;
e,快捷键与热键操作是否有效
f,是否存在中英文混合
g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
h,鼠标右键快捷菜单


特殊属性
1,安装界面应有公司介绍或产品介绍,有公司的图标
2,主界面及大多数界面最好有公司图标
3,选择"帮助"->"关于"命令,应看见相关版权和产品信息

月上百合

这是一个中英文的标准web测试文档。我没有怎么用过，只是了解了一下，不过看着挺好的，应该对有些同行有用，也放上来吧

< Company name > 公司名称
ACCEPTANCE TEST验收测试过程
PROCEDURE
<roject name>项目名称
Document Version x.x文档版本
Revision Date: January, 2000
CONFIDENTIAL - INTERNAL USE ONLY保密级别－仅在内部使用
Copyright 2000 <company name>. All Rights Reserved.
This document contains confidential and trade secret information of <company name> . <company name> has prepared this
document for use by its internal personnel in developing new software and hardware products. Any unauthorized use or disclosure
of the information herein is prohibited, and the information may not be reproduced, copied, or used in whole or in part without
the prior written approval of <company name>.
File: WebTestProcedure.doc COMPANY CONFIDENTIAL AND PROPRIETARY 2
2000, <company name> All Rights Reserved.
Revision History修订历史
Title: Document Title Project Name 标题：项目文档标题
Revision: 1.0
Rev Date Description of Comments Modified by
1.0 [enter date] Initial Release [author]
[ver #] [date of
change]
[enter comments] [your name]
Distribution List 分发列表
Name Dept. Electronic/Hard Copy
[Name of Recipient] [Department] [Date]［接受者］［部门］［时间］
QS Mgt. 质量标准
Development/Prod. Mgt. 开发标准
Customer Support 客户支持
Tech. Assist.
EDI 电子数据交换
Open Issues 公开发行
{{Any items not resolved at this time.}} 这时没有任何结果
Copyright, 1998 by Mitchell International, San Diego, California
All Rights Reserved, Printed in USA Confidential, Unpublished Property of Mitchell International
THIS DOCUMENT AND INFORMATION HEREIN IS THE PROPERTY OF MITCHELL INTERNATIONAL
AND ALL UNAUTHORIZED USE AND REPRODUCTION IS PROHIBITED.
File: WebTestProcedure.doc COMPANY CONFIDENTIAL AND PROPRIETARY 5
2000, <company name> All Rights Reserved.
1. Overview 概述
{{Description of product being tested}} 将要被验收产品的描述
1.1 Purpose 目的
From Requirement Analysis and Functional Specifications, the Acceptance Test Procedure documents
the criteria a product/project must meet in order to be accepted into the Acceptance Test Phase. This
document provides detailed information to enable Quality Systems to run the pre-agreed tests/scripts
so that the product is sufficiently tested before exiting the Quality System Organization.
2. Test Summary & Scope 概要和作用域
{{ Summary and scope of Test Procedure }} 测试过程的摘要和作用域
3. Entrance Criteria 进入标准
To Be Determined in future meetings...在将来的会议上决定
4. Exit Criteria 退出标准
To Be Determined in future meetings... 在将来的会议上决定
5. Estimated Duration 估计时间
{{Complete time to run all manual and automated tests (including preparation, installation and
restoration) for this test procedure.}}完成所有的手工和自动测试过程（包括准备，安装和恢复）的时间
{{n Hours}} Total Test Procedure Duration
6. Test Bed Configuration 测试配置
The following are the supported Mitchell test beds, as outlined in the Functional Specs, which QS certifies.
6.1 Hardware Requirements硬件需求
{{XXX}}
6.2 Software Requirements软件需求
{{XXX}}
6.3 Unique Platform Requirements 统一平台需求安装／更新测试
{{XXX}}
7. Installation/Update Tests.
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图
{{Repeat entire sections above, as necessary}}作为需要结果的完整片段
8.Web Application Usability  web应用可用性测试
8.1 HyperText Markup Language (HTML) / DHTML 超文本标志语言(HTML/DHTML)
•Run HTML verification tool验证HTML
•HTML consistent with supported browser用浏览器运行一致的HTML
•All tags accounted for 全部的标志都被说明
8.2 Links/Anchors 连接/锚点
•Run Links verification tool 验证连接
•Valid external & internal links 外观连接是有效的/内部连接
•Linked pages can be loaded 连接页能被加载
•ActiveX components  ActiveX组件
•Java Applets  JAVA小程序
8.3 Cascading Style Sheets 层叠样式表
•Run CSS verification tool 验证CSS
8.4 Browsers 浏览器
•Appearance of web pages web页面的外观
•Screen resolution 分辨率
•age response to maximize/minimize browser window 最大最小化浏览窗口显示的应答页面
•Structural vs functional differences 页面结构对功能差异
•Centering & Scaling of objects 对象的居中和缩放
•Color of standard objects 标志对象的颜色
•Text appearance 文字外观
File: WebTestProcedure.doc COMPANY CONFIDENTIAL AND PROPRIETARY 7
2000, <company name> All Rights Reserved.
8.5 Frames 框架
•Automatic sizing 自动变换大小
•Scroll bars provided if needed 是否需要滚轴
•New page displays in appropriate target 在适当的target中显示新的页面
8.6 Tables 表格
•Automatic sizing自动变换大小
8.7 Forms 窗体
•Form fields behavior (wrap, resize with window size)形成字段显示的动作(限制大小,窗体尺寸大小)
8.8 Graphics 图像
•Color saturation and contrast 颜色的饱和度和对比度
•Easily identifiable as a link if required 是否需要标志为一个易懂的图像连接
•Do all graphics load 加载所有的图像
8.9 Navigation 导航
•Consistency of navigation thru-out the site贯穿整个站点导航的一致性
•Easy to understand/follow 容易理解和使用
9. Feature Tests 功能测试
9.1 <Section of Software/Environment>《软件和环境的组件》
Test Setup: 测试步骤
9.1.1 <Feature Test>功能测试
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}}为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results 预期结果
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图
{{Repeat entire sections above, as necessary}}作为需要结果的完整片段
10. Performance Tests 性能测试
10.1 Traditional Software 软件习惯
The following tests certify all performance criteria, as specified in the Functional Specs
下列各测试项证明全部的性能标准，作为功能规格列入清单.
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}}必要的动作产生预期结果
Expected Results预期结果
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}} 只是为预期结果任意矩阵图
10.2 Web Application web应用
•Downloading of document 下载文件
•Calculations 计算
•age switching 页面切换
•ActiveX controls ActiveX控制
•Loading of audio/video components 载入声音图像组件
•Time to process Credit Check
11. Product Interaction Tests 产品交互测试
{{ Overall product interaction tests to ensure that products work in conjunction on the same system.}}
验证产品在相同系统的交互测试
The following tests certify product interaction, as specified in the Functional Specs.
下列测试证明了产品的交互性，将功能规格列入清单
11.1 <rogram/Product>程序／产品
Test Setup:测试步骤
11.1.1 <Feature Test>特征测试
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图
{{Repeat entire sections above, as necessary}}作为需要结果的完整片段
12. Product Import/Export Tests 导入导出测试
The following tests certify data is properly imported/exported into/from products, as specified in the

Functional Specs. 下列测试证明了完全的从／导入产品，下列测试证明了产品的交互性，将功能规格列入清单
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图
{{Repeat entire sections above, as necessary}}作为需要结果的完整片段
13. Web Application Backend Transactions   web应用的后端通信
•Save new data 保存新数据
•Update existing data 更新已有数据
•Links/buttons that execute transactions执行连接和按钮时
•CGI Scripts CGI脚本
•ActiveX controls ActiveX控件
•Java applets java小程序
•Database queries 数据库查询
•Server down time 服务器停机时间
14. Multi-User Tests多用户测试
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图
{{Repeat entire sections above, as necessary}}作为需要结果的完整片段
15. Stress Tests 负载测试
The following tests certify all Stress criteria, as specified in the Functional Specs.
下列测试证明负载标准，将负载规格列入清单
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图

16. Web Application Security Web应用的安全性
•Server 服务器安全
•Integrity of data 数据的完整性
•Unauthorized access 未授权访问
•Expiration of cookies/certificates 停止cookies和证书
•Firewalls 防火墙
•Application应用
•Supports http 支持http
•Supports SSL 支持SSL安全套接字
17. Web Application Off-Site Access
•erformance 性能
•Functionality 功能
18. On-Line Help 在线帮助
•Test Description
{{ Specific item tested}}
Preparation
{{ Steps necessary to put environment/software in the exact condition for this test.}}
Procedures
{{ Action required to produce the Expected Result(s).}}
Expected Results
{{Result 1 = Requirement 1}}
{{Repeat Results as necessary}}
{{Optional Matrix Chart for Expected Results Only.}}
19. Context-Sensitive Help
•Test Description测试描述
{{ Specific item tested}}功能项测试
Preparation准备
{{ Steps necessary to put environment/software in the exact condition for this test.}} 为这个测试准备需要的精确环境和软件
Procedures规程
{{ Action required to produce the Expected Result(s).}} 必要的动作产生预期结果
Expected Results
{{Result 1 = Requirement 1}}需求＝结果
{{Repeat Results as necessary}}需要的可重复结果
{{Optional Matrix Chart for Expected Results Only.}}只是为预期结果任意矩阵图

APPENDIX A - Reference Documents 附录A引用文档
Description File Name 描述文件名
Design Specifications 设计规格说明书{{File Name}}-
Product Requirement Documents 产品需求文档{{File Name}}-
Function Specification Documents 功能描述文档{{File Name}}-
Unit Test Reports 单元测试报告{{File Name}}-
APPENDIX B - Automated Test Procedures附录B自动测试规程
Test Case Features 测试用例特征
Specific Feature Test Robot Script Robot - Test Case Shell Procedure
测试程序脚本程序特征－测试用例外壳规程
APPENDIX C - Glossary附录C术语表
Term Definition 限制定义
APPENDIX D - Notes附录A历史
{{Document any items that will be retained in future revisions.}}
任何历史修订文档内容将被保留
APPENDIX E - Installed Files List附录E安装文件列表
APPENDIX F - File Conversion List 附录F文件转换列表

月上百合

因为有图表，所以文本太乱，见附件吧

月上百合

常规测试方法


一.        功能测试

1. 安装测试：
1)        安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装；
2)        若是选择安装，查看能否实现其相应的功能；
3)        在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程序组及程序项产生）；
4)        软件安装后，对其它已经安装的软件是否有影响；
5)        裸机安装后，各功能点是否可用；
6)        安装前，安装程序是否判断可用磁盘空间大小，如果不能满足安装空间要求，安装程序能否继续；
7)        安装过程中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准；
8)        安装过程中界面显示与提示语言是否准确、友好；
9)        重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存；
10)        是否有注册码或硬件加密狗，在没有它们（或错误）存在的情况下能否顺利安装。

2．配置测试
1)        是否可以按照用户手册的说明，运行于多种操作系统（Windows 各版本 、Unix 、Linux 等）；
2)        按系统最低要求进行软件的安装配置，查看能否正常实现各种功能；
3)        数据源等信息配置不正确时能否给出提示信息；
4)        是否可以按照用户手册的说明，支持多种数据库。

3. 卸载测试
1)        卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉；
2)        卸载过程中完全删除共享文件后，看其它程序能否正常运行；
3)        卸载后，是否对其它已经安装的软件有影响；
4)        系统卸载后用户建立文档是否保留；
5)        软件卸载画面上的软件名称及版本信息是否正确；
6)        在所有能中途退出卸载的位置是否能正确退出；
7)        卸载过程中界面显示与提示语言是否准确、友好；
8)        卸载后安装此系统能否打开原来保存的文件，并一切运行正常；
9)        卸载程序如果要求重新启动机器，在重启动之间是否给用户提示以保存现有的己运行的程序的资料；
10)        是否可以选择组件进行卸载；
11)        卸载过程中，对意外情况的处理（掉电等）。
12)        在卸载过程中，是否有终止或者结束按钮。

4. 运行与关闭测试
1)        运行时是否与其它应用程序有冲突(内存冲突)；
2)        是否可以同时运行多个程序；
3)        任务栏有无程序运行提示；
4)        若有未保存的数据，关闭系统时是否有提示；
5)        后台服务程序在点击关闭按钮时是否有确认提示；
6)        运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

5. 服务程序的测试：
1)        系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响；
2)        服务程序能否长时间正常运行；
3)        外界异常后，服务程序的自动恢复能力（服务器掉电、网络中断后恢复、数据库异常后恢复…）；
4)        在点击关闭按钮时是否有确认提示；
5)        应用程序与其他程序是否兼容（能否避免内存冲突）。

6. 系统管理（参数设置）
1)        参数设置后，能否正确的进行应用；
2)        设置错误参数，系统的容错能力；
3)        修改参数，对与之相关模块的影响；
4)        系统是否有默认的参数，A 有：默认的参数是否起到作用 ；B 没有：不设置，系统能否运行或者给出提示。

7. 用户、权限管理
1)        赋予一个人员相应的权限后，在界面上看此人员是否具有此权限，并以此人员身份登陆，验证权限设置是否正确（能否超出所给予的权限）；
2)        删除或修改已经登陆系统并正在进行操作的人员的权限，程序能否正确处理；
3)        重新注册系统变更登陆身份后再登录，看程序是否能正确执行，具有权限是否正确；
4)        在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；
5)        不同权限用户登录同一个系统，权限范围是否正确；
6)        覆盖系统所有权限设定；
7)        能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)；
8)        能否添加长用户名及长口令，如果允许，新用户能否正确登录；
9)        系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；
10)        登录用户能否修改自己的权限；
11)        添加用户（有标识或编号）:标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；
12)        登录用户能否修改本人（或其他人）的信息，删除本人（或其他人）；
13)        修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；
14)        修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；
15)        不给用户授权，是否允许登录；
15)        改某些设置时，是否会影响具有上级权限及相同权限人员的设置；
16)        系统管理员修改了某些数据，以其他人员身份登录时数据是否改变；
17)        用户能否同时属于多个组，各个组的权限能否交叉；
18)        删除后重新添加的用户是否具有以前的权限；更改用户各项属性（包括权限）看对权限是否有影响。

8. 系统登录测试
1)        使用合法用户登录系统；
2)        用户名、口令错误或漏填时能否登陆；
3)        系统是否容许多次非法登陆,是否有次数限制；
4)        使用已登录账号登录系统系统能否正确处理；
5)        使用禁用帐号登陆系统能否正确处理；
6)        删除或修改后的用户用原用户登录；
7)        不输入用户名和口令，重复点“确定”和“取消”按钮，是否允许登录。

9.        注销
1)        注销为原模块、新模块系统能否正确处理；
2)        中止注销能否返回原模块、原用户；
3)        注销为原用户、新用户系统能否正确处理；
4)        使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。

10. 修改口令
1)        正常情况；
2)        输入错误的原口令或新口令与确认口令不一致系统能否正确处理；
3)        修改口令后，用原口令是否能登录（同时验证新口令是否有效）；
4)        是否能修改其它用户的口令。
               
11. 右键功能
1)        右键菜单中的功能是否与菜单（或工具栏）中对应的功能一致；
2)        右键菜单中的功能能否正确实现；
3)        同一菜单下的热键是否相同。

12. 记录列表
1)        增加重复记录、空白记录，系统能否正确处理；
2)        修改后不保存（有保存按钮），系统能否正确处理；
3)        删除或修改正在使用信息，系统能否正确处理；
4)        删除级联记录的上游或下游记录，系统能否正确处理；
5)        删除记录时是否有提示；
6)        记录中包含的缺省系统信息能否删除和修改；
7)        记录列表能否及时反应记录的变化；
8)        记录变化之后系统相关信息能否及时更新；

13. 统计、查询
1)        对非法的时间范围系统能否正确处理；
2)        统计查询语句包含多个与或非条件时，系统能否正确处理；
3)        条件逻辑混乱，系统能否正确处理；
4)        多表查询统计及单表查询统计功能是否正确实现；
5)        分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录；
6)        能否按系统默认的条件进行查询；
7)        当统计时间段为当日、跨日、跨月、跨季、跨年度时，统计查询结果是否正确；
8)        当某些操作被别人取消后，设置条件段为取消前、取消后、包含取消操作的一段时间；
9)        以不同的权限登录时，统计、查询是否正确；
10)        在查询或统计大数据量时，系统是否允许终止操作；
11)        查询、统计按钮是否允许双击或更多的点击，系统做何反映；
12)        查询出的数据是否允许修改。

14. 文件操作
a）保存
        1) 文件是否能够正确保存在在缺省位置或指定位置（本地、网络）；
        2) 系统能否正确处理长文件名、特殊字符文件名保存；
3) 文件能否保存为其它扩展名；
        4) 如应用程序对文件名区分大小写，当这些文件在导出到介质中时，系统能否正确处理；
        5) 介质空间已满时，系统是否给出提示。
b）打开
1) 打开文件是否正确显示上一次保存的内容；
        2) 系统能否正确处理非系统默认扩展名的文件；
        3) 文件能否被其他程序正确打开；
        4) 打开对话框中，是否有默认扩展名的文件类型；
        5) 打开对话框时，是否有默认的路径。
c）打印输出
1)        是否按所设置的格式打印；
2)        是否有打印预览，能否设置打印字体，打印效果是否合乎客户要求；
3)        打印预览的内容是否正确，内容是否能够进行拖拽操作，是否影响实际的打印；
4)        安装或不安装打印功能模块，对其它模块是否有影响；
5)        打印机未安装系统有无提示；
6)        打印中途能否进行正常的打印中断，是否可以选择打印的内容。
7)        能否进行本地或网络打印。
d) 导入、导出功能
1)        导入的文件格式非要求时，系统如何处理；
2)        导入、导出的有效文件能否完整正确地显示并被使用；
3)        导出后的文件是否允许修改，如果允许，导入后能否使用；如不允许，系统有何限制；
4)        导入，导出是否可以选择路径；
5)        在客户端和服务器端进行导入，导出；
6)        在客户端和客户端之间进行导入，导出；
7)        在本地进行导入，导出；
8)        不同文件格式的导入，导出。
e) 检入与检出
        1) 单文件、多文件检入与检出；
        2) 能否多次检入与检出；
        3) 文件检出后其它人能对其做何操作。

15. 界面上对象的功能（文本框，下拉框，按钮，热键等等）
a) 工具条
                1) 工具条能否正常显示/隐藏；
2)        工具条按钮在不可用时是否置灰，例如在不置灰情况下，重复点击工具条上的按钮，看系统是否能够正常进行操作；
3)        可移动工具条在窗口中间位置其形状是否正确；
4)        工具条船坞状与非船坞状时其上按钮是否相同；
5)        工具栏上工具按钮功能是否能正常实现；
6)        工具按钮显示是否正确、友好、醒目易懂；
7)        工具栏上的工具按钮是否有鼠标悬停提示；
8)        工具栏上的工具按钮是否可以任意定制。
b) 下拉列表       
          1) 列表记录的每一行是否显示完整；
          2) 列表记录不能在一页中显示时，是否有纵向滚动栏；
          3) 列表滚动栏上滑块能否自由滑动，对应内容显示是否正确；
          4) 列表中内容能否自动排序。
c) 窗口       
          1) 打开的窗口不确认关掉，能否再调其它窗口，且连续开窗口系统能否正确处理；
          2) 窗口尺寸变化时窗口中控件能否自适应；
          3) MDI中，子窗口的平铺、重叠、排列图标功能是否正确；
          4) 窗口的标题、图标是否和菜单命令、按钮一致；
          5) 子窗口和主窗口的属性是否正确；
          6) 窗口中的上下左右滚动条是否能达到预览全部界面的效果。
d) 文本框
          1) 对输入域的必添项处理是否正确；
          2) 输入域是否有长度限制；
          3) 输入域如对某些字符禁止输入时，限制是否成功；
          4) 中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合；
          5) 口令域
        口令为空格或包含空格、特殊字符（所有特殊字符的测试）时系统能否正常处理；
        口令位数是否有限制；
        口令与帐号相同，系统是否有提示；
        口令为字典单词系统能否正确处理；
特殊的对系统安全性要求较高应该注意：
        口令应有最少位数限制；
        口令应为数值、大小写字母、特殊字符的组合；
        口令禁止设为空，不能和要被修改的口令一致；
        口令区分大小写；
6) 时间域
        年度超过4位；
        月份输入0或大于12；
        日期输入0或大于当前月份的天数；
        年度，月份，日期输入负数；
        时间输入大于或小于边缘值的数据；
        进行字符及汉字的输入，看程序能否正确处理；
        系统中所涉及时间是否取服务器时间；
        有范围的输入域，开始时间大于、小于、等于结束时间，系统能否正确处理；
        时间范围同当前时间的关系是否正确；
        是否包含缺省时间且缺省时间意义是否正确；
        系统对闰年，闰月的处理；
        对不同的时间格式（yyyy-dd-mm,yy-dd-mm,yyyy/dd/mm,yy/dd/mm等）是否允许输入；
        输入的时间在与之有关的模块中是否能正确的起到作用及对其他模块的影响；
        对时间点的测试。
                    7) 货币域
        输入负值、零、特大数、小数系统能否正确处理；
        系统对小数点后数位的控制是否正确；
        系统能否正确处理数值计算；
        输入非数值型数据（包括特殊字符），系统能否正确处理；
        系统能处理货币的种类。
8) 身份证（18或15位）：
        身份证中输入非法的年月日信息（包括超界数字及字符，汉字），程序能否进行检验并正确处理；
        由身份证号码计算年龄，系统对出生年份末两位数是00的身份证号码能否正常处理；
        在年龄和身份证均作为用户信息输入时，是否具有关联；
        在身份证的输入中，是否允许输入字符”x”。
9) 电话号码
        输入特殊的电话号码，如119，110，800等看程序是否能正确处理；
        验证－，（，） *  # 是否有真正含义；
        电话号码长度是否有限制；
        电话号码是否允许输入汉字，英文。
  10) 关于时间的其它操作
        时间的跨月份、年度操作；
        12小时、24小时制的操作；
        客户机与服务器时间不同的操作（包括客户机与服务器两地时差不同）；
  11) 数据字段一致性
不同窗口中同一类数据输入域的数据接口是否一致(如添加用户及用户登录窗口对用户标识和口令的长度是否一致)。
e) 图表曲线
    首先，在一定的时间段观察曲线走势，如果有类似的软件可对比的话可以进行对比大体趋势，然后，再找关键点，对比关键点的数据。测试中，需要找到曲线的计算公式，找关键点进行计算。（进行对比是必要的，第一，可以节省一些不必要的工作量；第二，也有可能是编码人员所用的公式本身就有问题，而你所有测试所做的计算都是徒劳了。）
f) 列表       
1)        列表记录不能在一页中显示时，是否有纵向滚动栏；记录长度超过列表宽度时，是否有横向滚动栏；
2)        列表滚动栏上滑块能否自由滑动，滑块滑动时，对应内容显示是否正确；
3)        列表内容是否可直接输入；
4)        列表中每列数据能否按升序、降序排列；

16. 备份与恢复
1) 备份T日的数据，进行操作，然后恢复，查看恢复的数据是否正确；
2) 备份到不同介质上，并考虑介质空间已满的情况；
3) 用系统提供的恢复功能进行恢复：
        用数据库进行恢复；
        在备份和恢复还没有结束的时候，终止（掉电，网络不通等）备份和恢复；
        有操作的时候，进行备份和恢复；
        没有任何操作的时候，进行备份，恢复；
        部分备份，全部备份，部分恢复，全部恢复有选择的备份和恢复；
4) 进行备份，恢复操作是否有权限限制 A 有: 分别用有权限的用户和没有权限的用户进行操作 B 没有：单个用户进行备份，恢复；多个用户同时进行备份和恢复。

17．系统日志的处理
1) 系统能否正确记录日志信息；
2)        系统是否有清空日志的功能；
3)        系统是否有导出日志的功能；
4)        当日志数据超过容量时，系统如何处理。


二．性能测试
具体用例不好设计，下面列出了一些有性能要求的测试点：
1) 查询
2) 保存
3) 统计
4) 刷新
5) 显示
6) 传输
7) 响应
8) 下载
打开网络上其它介质上的文件时，可制造网络拥挤情况下的文件打开操作。主要测试点，集中在几个点上。一是数据量小的时候主要的查询统计刷新等功能点；二是数据量积累到一定程度时的查询统计刷新时间，这里的一定程度是根据实际的项目和客户需求来定的。


三．极限压力测试
1）接收大数据量的数据文件时间；
2) 大数据恢复时间；
3) 大数据导入导出时间；
4) 大批量录入数据时间；
5)        大数据量的计算时间；
6)        多客户机同时进行某一个提交操作；
7)        采用测试工具软件；
8)        编写测试脚本程序；
9)        大数据量的查询统计时间。


四. 容错测试       
1)        通过断开网线的强制性停止数据传输以及重新将网线接上，查看提示信息及对系统的影响；
2)        系统断电，恢复后查看对系统的影响程度；
3)        死机后，看程序如何处理；
4)        服务器DOWN掉，客户端程序如何处理。


五．并发测试
1) 登录的并发操作：多人同时登录系统，使用不同或相同账号；
2)        提交的并发操作：多人同时提交相同的工作项、不同的工作项；
3)        对数据库操作的并发操作：多人同时从数据库中读出（或向数据库导入） 相同文件、不同文件。


************************
附：一些容易出错的地方
************************
一.        有关新建和修改
1.        创建或修改的内容为已经存在的内容，系统是否有提示；
2.        修改正在使用的数据。

二.        删除
1.        应有确认提示；
2.        若删除的内容在文件或数据库中，应作实际校验；
3.        删除正在使用的数据；
4.        考虑删除数据的相关数据是否同时被删除；
5.        重新使用已删除的数据。

三．关于提示信息的验证
有些操作系统会给出成功（有时没有成功提示）或失败的提示，一定要验证提示的正确性（尤其是一些重要操作，如修改口令），即用其它方法检查所作的操作是否真正成功或失败。

四．关于考虑硬盘空间已满的情况
1.        数据存储和备份；
2.        生成文件；
3.        拷贝文件

五．关于修改系统时间
对于和时间有关的业务，测试时考虑修改系统时间对系统的影响。

六．对于响应速度慢的按钮进行连续点击；或中途取消，再继续…

七．凡是支持并发过程的功能，一定要做并发测试（手工进行或利用工具）；

八．打印功能（能否正确打印，打印效果与预览是否一致）

九．系统初始化
1) 如果系统安装后需要进行初始化，初始化过程是否正确；
2) 如果系统安装后不需要进行初始化，安装后的默认设置是否正确、适当。

十．版权声明是否符合标准，如果有公司的logo，图标是否正确（最容易测试的地方，也是最容易被忽略的地方）

十一．如果捆绑硬件，如果可能的话，在测试我们的软件产品前要对硬件的性能、稳定性进行严格测试。（包括大数据量的传输入等）

十二．备份与恢复
1) 备份与恢复过程本身的正确性；
2) 备份内容的正确性（通过事先准备的测试数据在恢复后验证）；
3) 备份与恢复过程中对异常情况的处理（掉电、网络不通等）；
4) 在原始机上的恢复；
5) 在非原始机上的恢复；
6) 在裸机（只有操作系统和必要的数据库或第三方产品）上的恢复；
7) 在一台机器上进行若干次的备份与恢复；
8) 如果是支持多数据库的软件，备份与恢复是容易出错的地方。

需要严格把握的错误类别：
在整个测试过程中对每条问题都制定有错误归类，现按照问题的严重程度，把问题主要分为四类：
    A：严重影响系统运行：导致系统出现不可预料的严重错误的问题，例如：运行过程中出现页
面或页面无法显示、死机等。
        B：影响系统运行：系统中重要的功能出现运行错误，例如：导致用户必须重新登录的问题，        
导致个别用户不可用的问题；
        C：不影响系统运行但必须修改：系统中基本的操作或功能没有实现或实现有误的问题，以及
不符合常规的操作界面的问题。
        D：所提建议：不影响系统运行，对系统的可用性等提示的建议性的问题


界面测试
文章出处：bbs.51testing.com 作者：51testing会员 发布时间：2006-08-29
界 面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如 同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功 能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良 好的界面由于需要具有艺术美的天赋而遭拒绝。
　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
1：易用性：
　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。
5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可寫控制項檢測到非法輸入後應給出說明並能自動獲得焦點。
10):Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
11):核取方塊和選項框按選擇幾率的高底而先後排列。
12):核取方塊和選項框要有默認選項，並支援Tab選擇。
13):選項數相同時多用選項框而不用下拉清單框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数較少时使用选项框，相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词语。
2： 规范性：
通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具箱。
12):工具箱要具有可增减性，由用户自己根据需求定制。
13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
14): 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19): 右键快捷菜单采用与菜单相同的准则。
3：帮助设施：
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则：
1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3)：操作时要提供及时调用系统帮助的功能。常用F1。
4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
4：合理性：
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
合理性细则：
1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
2)：子窗体位置应该在主窗体的左上角或正中。
3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。
6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8)：非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10): 提示、警告、或错误说明应该清楚、明了、恰当。
5：美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
美观与协调性细则：
1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6)：放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
9): 如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
14): 通常父窗体支持缩放时，子窗体没有必要缩放。
15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
6：菜单位置：
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
菜单测试细则：
1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。
3): 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式，组合原则见8。
9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
10): 菜单前的图标不宜太大，与字高保持一直最好。
11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12): 主菜单数目不应太多，最好为单排布置。
13):菜单条是否显示在合适的语境中？
14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
15):下拉式操作能正确工作吗？
16):菜单、调色板和工具条是否工作正确？
17):是否适当地列出了所有的菜单功能和下拉式子功能？
18):是否可能通过鼠标访问所有的菜单功能？
19):相同功能按钮的图标和文字是否一致？
20):是否能够用其他的文本命令激活每个菜单功能？
21):菜单功能是否随当前的窗口操作加亮或变灰？
22):菜单功能是否正确执行？
23):菜单功能的名字是否具有自解释性？
24):菜单项是否有帮助，是否语境相关？
25):在整个交互式语境中，是否可以识别鼠标操作？
26):如果要求多次点击鼠标，是否能够在语境正确识别？
27):如果鼠标有多个按钮，是否能够在语境中正确识别？
28):光标、处理指示器和识别指针是否随操作恰当地改变？         
7:独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
测试细则：
1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):　主界面，最好是大多数界面上要有公司图标。
3):　登录界面上要有本产品的标志，同时包含公司图标。
4):　帮助菜单的“关于”中应有版权和产品信息。
5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中：
1):面向事务的组合有:
Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl –H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。
2)：列表:
Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
3):编辑:
Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
4)文件操作:
Ctrl-P 打印；Ctrl-W 关闭。
5):系统菜单
Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
6):MS Windows保留键:
Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作；Shift-F1 上下文相关帮助。
按钮中：
可以根据系统需要而调节，以下只是常用的组合。
Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
9:安全性考虑：
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
安全性细则：
1)：最重要的是排除可能会使应用非正常中止的错误。
2)：应当注意尽可能避免用户无意录入无效的数据。
3)：采用相关控件限制用户输入值的种类。
4)：当用户作出选择的可能性只有两个时,可以采用单选框。
5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6)：当选项特别多时，可以采用列表框，下拉式列表框。
7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11)：对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!
,.。?/还有空格。
15)：与系统采用的保留字符冲突的要加以限制。
16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
10:多窗口的应用与系统资源：
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4)：尽量防止对系统的独占使用。
5)：窗口能否基于相关的输入或菜单命令适当地打开？
6)：窗口能否改变大小、移动和滚动？
7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？
8)：当被覆盖并重调用后，窗口能否正确地再生？
9)：需要时能否使用所有窗口相关的功能？
10)：所有窗口相关的功能是可操作的吗？
11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？
12)：显示多个窗口时，窗口的名称是否被适当地表示？
13)：活动窗口是否被适当地加亮？
14)：如果使用多任务，是否所有的窗口被实时更新？
15)：多次或不正确按鼠标是否会导致无法预料的副作用？
16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
17)：窗口是否正确地关闭？

月上百合

测试用例的设计等价划分法里的例子，在我曾经面试的过程中，遇到过，大家可以看一下

月上百合

好了，暂时就到这吧，这是我认为比较好的，可能很多人都看过了，因为这些也是从论坛里收集的，大家不要感谢我，感谢原创及贡献者吧。从事web测试的朋友可以用心看一下，对你们会有帮助的。

yu8023yan

呵呵。先谢谢了。。总结了太多了。。

hueslife

很强大~::xixill:::

jill820

很好。谢谢

wjflive

hugh851115

谢谢版主分享

Ade_Huang

月上百合真的很强的，我喜欢的版主之一哦
谢谢分享和整理，辛苦了！

foxman_xx

D你

月上百合

原帖由 Ade_Huang 于 2010-6-24 13:28 发表
月上百合真的很强的，我喜欢的版主之一哦
谢谢分享和整理，辛苦了！

呵呵，不是我强，说了，要感谢资料的贡献者及原创

asfu

强大
学习的榜样

626953621

百合大姐，顶一下