Web程序中常见的测试项目（*转*）

Web程序中常见的测试项目（*转*） Web测试元素 1．页面部分 （1）页面清单是否完整（是否已经将所需要的页面全部都列出来了） （2）页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示） （3）页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确） （4）页面所采用的显示风格是否与项目中其它类似页面一致 （5）页面特殊效果（如特殊字体效果、动画效果）是否显示 （6）页面特殊效果显示是否正确 （7）如果本模块有多页，相互跳转时，是否有抖动现象（如各页面间标题不一样高） 2．页面元素部分 （1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等） （2）页面元素是否显示正确（主要针对文字(如是否有错误字)、图形、签章） （3）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等） （4）页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接） （5）页面元素的容错性列表（如输入框、时间列表或日历） （6）页面元素的容错性是否存在 （7）页面元素的容错性是否正确 （8）列表时，过长的字段会折行，折行处是否合理？显示的字数不过多，也不过少？ 3．功能部分 （1） 数据初始化是否执行，执行得是否正确 （2） 数据处理功能是否执行，执行得是否正确 （3） 数据保存是否执行，执行得是否正确 （4） 数据操作是否对其他功能有影响，如果影响其他功能，系统能否作出正确的反应 （5） 其他错误 （6） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况 如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试 单项功能测试（增加、修改、查询、删除） 增加——>增加——>增加 （连续增加测试） 增加——>删除 增加——>删除——>增加 （新增加的内容与删除内容一致） 增加——>修改——>删除 修改——>修改——>修改 （连续修改测试） 修改——>增加 （新增加的内容与修改前内容一致） 修改——>删除 修改——>删除——>增加 （新增加的内容与删除内容一致） 删除——>删除——>删除 （连续删除测试） 其中 注意事项： 1）修改时，所显示的明细页是否是在列表中所对应的行 2）删除前是否提示是否确定删除或提示不能删除，删除后是否提示删除成功 3）新增时，新增的内容是否在页面中已存在 （7）查询功能分为两种情况，验证操作结果。 一、打开页面时 自动显示结果，则不特别强调； 二、需要手工操作进行查询，则每次在其他功能完成后进行。 其中注意事项： 查询时，输入不同的条件组合，结果是否都是正确的？尤其是一对日期中（开始日期，结束日期）只给出一个时，查询是否正常工作？ 4．提示信息 （1） 成功、失败提示 （2） 操作结果提示 （3） 确认提示 （4） 危险操作、重要操作提示 （5） 返回页面 提示后显示的页面 5．容错性 注意以下几种情况 （1） 为空、非空 （2） 唯一性 （3）字长、格式 （4） 数字、邮政 编码、金额、电话、电子 邮件、ID号、密码 （5） 日期、时间 （6） 特殊字符 （对数据库）英文单、双引号，&符号 6．有效性校验 1.字符 1）显示长度检查：所显示的长度是否它所能保存的长度大致一致？ 2）字符串长度检查： 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会提示出错？并明确指出它允许输入的最大字数? 3) 字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. 4）中文字符处理：在可以输入中文的系统输入中文,看会否出现乱码或出错. 2.数值 1）是否允许输入非数字型字符？如果输入了，保存时是否有不允许输入的提示？ 2）界面是否提示了单位（元或是万元）？ 3）小数点后的位数，是否与需求或详细设计一致？ 4）当输入的数值大于所允许的最大范围时，是否有提示，提示是否明确指出了所允许的最大范围？ 3.大文本 1）界面上是否提示了大文本所能输入的字数？（按英文或按中文，一个项目中应该是一致的） 2）提示所能输入的字数是否是与实际能输入的字数是一致的？ 建议：页面中每一个输入框都要测到。 4.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理. 7．权限部分 功能权限： 指定用户可以使用那些功能，不能使用那些功能 数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可以合并到功能测试 操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合并到功能测试权限变化： 可以合并到功能测试 （1） 功能权限是否存在，是否正确 （2） 数据权限是否存在，是否正确 （3）操作权限是否存在，是否正确 （4） 引起权限变化的功能列表 （5） 功能权限变化还是数据权限变化，或两者兼有 （6） 权限变化是否正确 注意事项： 当一个没有权限的用户做删除或保存操作时，是否提示用户没有权限，而不是给出一个通用的错误提示？ 8．键盘操作 （1） Tab键的使用 （2） 上下方向键的使用 （3） Enter键的使用 （4） 系统 设定快捷键的使用（如果 设置有快捷键） 9．测试中还应注意的其他事项 （1） 完整性：是否是一个整体，没有功能缺损 （2） 易用性：使用是否方便 （3） 一致性：类似的问题用类似的方法处理 （4） 提示信息：提示信息是否完整、正确、详细 （5） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细 （6） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容 （7） 可扩展性：是否由升级的余地，是否保留了接口 （8） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护 （9） 运行速度：运行的快慢，带宽占用情况 [ 本帖最后由 chrisphone 于 2009-5-12 19:04 编辑 ]

引用 使用道具 报告 回复 TOP

chrisphone 该用户已被删除

2# 大 中 小 发表于 2009-5-12 18:57  只看该作者 Web程序测试总结(*转*) Web 测试的经验 1. 功能测试 1.1.链接测试 　　 链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样 确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL 地址才能访问。 　　 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web 应用系统的所有页面开发完成之后进行链接测试。 1.2. 表单测试 　　 当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信 息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接 受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。 1.3.Cookies测试 　　Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies 访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 　　 如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。 1.4.设计语言测试 　　Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的 HTML 等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 JavaScript 、 ActiveX 、 VBScript 或 Perl 等也要进行验证。 1.5.数据库测试 　　 在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。 　　在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。 2. 性能测试 2.1.连接速度测试 　　 用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这 样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。 　　 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。 2.2.负载测试 　　 负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？ 2.3.压力测试 　　负载测试应该安排在 Web 系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个 Web 系统能同时处理的请求数量将远远超出这个限度，所以，只有放在 Internet 上，接受负载测试，其结果才是正确可信的。 　　进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。 　　 压力测试的区域包括表单、登陆和其他信息传输页面等。 3. 可用性测试 3.1.导航测试 　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可 以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？ 　　 在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构，因此， Web 应用系统导航帮助要尽可能地准确。 　　 导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。 Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 3.2.图形测试 　　 在 Web 应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： 　　 （1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。 　　 （2）验证所有页面字体的风格是否一致。 　　 （3) 背景颜色应该与字体颜色和前景颜色相搭配。 　　 （4）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。 3.3.内容测试 　　 内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。 　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写 错误。这种测试通常使用一些文字处理软件来进行，例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般 Web 站点中的所谓 " 相关文章列表 " 。 3.4.整体界面测试 　　 整体界面是指整个 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 的设置也不一样。 　　 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。 5. 安全性测试 Web 应用系统的安全性测试区域主要有： 　　 （ 1 ）现在的 Web 应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 　　 （ 2 ） Web 应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。 　　 （ 3 ）为了保证 Web 应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。 　　 （ 4 ）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 　　 （ 5 ）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 6. 总结 　　 本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。 　　基于 Web 的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性 和可用性测试。