|
|
Web应用程序的测试方法
Web应用程序的测试方法
注意：测试方法的选择取决你的测试策略。
1、一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
2、当然，圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。
3、有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立，要有所取舍。
一、界面测试
现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面，对不懂技术的客户来说那相当关键。
（一）设计方法
可以根据设计文档，专业美工人员，确定整体风格页面风格，然后根据这个页面人员可以生成静态的HTML，CSS等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面/框架。
主要包括以下几个方面的内容：
1、站点地图和导航条位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确；
2、背景/色调 是否正确、美观，是否符合用户需求；
3、页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 ；大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等；
4、链接的形式，位置，是否易于理解等。
（二）web测试的主要页面元素
1、页面元素的容错性列表（如输入框、时间列表或日历）；
2、页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超链接、输入框等等）；
3、页面元素的容错性是否存在；
4、页面元素的容错性是否正确；
5、页面元素基本功能是否实现（如文字特效、动画特效、按钮、超链接）；
6、页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超链接等）；
7、页面元素是否显示正确（主要针对文字、图形、签章）；
8、元素是否显示（元素是否存在）；
（三）测试技术
1、通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案。
2、可以结合数据定义文档查看表单项的内容，长度等信息。
3、对于动态生成的页面也要进行浏览查看。
（四）界面测试要素
符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性
1、直观性
1）、用户界面是否洁净,不唐突,不拥挤。界面不应该为用户制造障碍。所需功能或者期待的响应应该明显,并在预期出现的地方。
2）、界面组织和布局合理吗?是否允许用户轻松地从一个功能转到另一个功能?下一步做什么明显吗?任何时刻都可以决定放弃或者退回,退出吗?输入得到承认了吗?菜单或者窗口是否深藏不露?
3）、有多余功能吗?软件整体抑或局部是否做得太多?是否有太多特性把工作复杂化了?是否感到信息太庞杂?
4）、如果其他所有努力失败,帮助系统真能帮忙吗?
2、一致性
1）、快速键和菜单选项。在Windows 中按F1键总是得到帮助信息
2）、术语和命令。整个软件使用同样的术语吗?特性命名一致吗?例如,Find是否一直叫Find,而不是有时叫Search?
3）、软件是否一直面向同一级别用户?带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息。
4）、按钮位置和等价的按键。大家是否注意到对话框有OK按钮和Cancel按钮时,OK按钮总是在上方或者左方,而Cancel按钮总是在下方或右方?同样原因,Cancel按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter。保持一致。
3、灵活性
1）、状态跳转。灵活的软件实现同一任务有多种选择方式。
2）、状态终止和跳过,具有容错处理能力。
3）、数据输入和输出。用户希望有多种方法输入数据和查看结果。例如,在写字板插入文字可用键盘输入,粘贴,从6种文件格式读入,作为对象插入,或者用鼠标从其他程序拖动。
4、舒适性
1）、恰当。软件外观和感觉应该与所做的工作和使用者相符。
2）、错误处理。程序应该在用户执行严重错误的操作之前提出警告,并允许用户恢复由于错误操作导致丢失的数据。如大家认为undo /redo是当然的。
3）、性能。快不见得是好事。要让用户看得清程序在做什么,它是有反应的。
二、功能测试
（一）测试内容
功能测试是测试中的重点，主要包括一下几个方面的内容：
1、链接：这个链接和界面测试中的链接不同那里注重的是链接方式和位置，如是图像还是文字放置的位置等，还是其他的方式。这里的链接注重功能。如是否有链接，链接的是否是说明的位置等。
2、表单提交：应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
3、Cookies 验证：如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使 cookie 来统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多。
4、功能易用性测试 ：完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
（二）测试技术
功能测试的测试技术可是很多的，我们可以结合实际环境选择使用
1、白盒测试技术(White Box Testing) 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试
2、黑盒测试技术（Black Box Testing）黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部需求阶段确定的功能点，可以结合兼容，性能测试等方面进行。根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面 ：
a.正确性 (Correctness)：计算结果，命名等方面。
b.可用性 (Usability)：是否可以满足软件的需求说明。
c.边界条件 (Boundary Condition)输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等。
d.性能 (Performance) 、 压力测试 (Stress)、 错误恢复 (Error Recovery)、安全性测试(Security)、兼容性 (Compatibility) 。
三、负载/压力测试
该测试用来验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可使用WEB测试工具对WEB站点的性能进行测试。
从以下几个方面分析应用程序性能：
Number of hits vs. Users：随着虚拟用户的增加，服务器在规定时间内所能处理的总点击数
Requests per second vs. Users：随着虚拟用户的增加，服务器在规定时间内所能处理的每秒请求数
Errors vs. Time：随着模拟访问时间的延续，出现错误的数量
Errors vs. Users：随着虚拟用户的增加，出现错误的数量
Performance Distribution vs. Users：针对虚拟用户数的应用性能分布情况，包括服务器的内存、CPU使用情况等
Performance vs. Users：随着虚拟用户的变化，应用性能的变化
（一）性能 (Performance)
正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了。 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题。
（二）压力测试 (Stress)
多用户情况 可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息。如果有必要的话必须进行性能优化(软硬件都可以)。这里的压力测试针对的是某几项功能。
四、安全性测试
WEB站点的安全问题很重要。
Web 安全的第一步就是正确设置目录。需要查看每个目录是否直接显示所有内容，因为那样可能会造成信息泄露。
当站点需要用户进行登录，以验证他们的身份时，测试人员需要验证系统是否能够阻止非法的用户名/口令登录，通过有效登录。根据系统对登录的限制、要求，测试人员进行测试。
在后台，测试人员还要注意验证服务器日志工作是否正常，日志是否记录所有的事务处理等等。
五、文档测试
（一） 文档属性检查清单
1、完整：是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
2、准确：既定解决方案正确吗?目标明确吗?有没有错误?
3、精确：不含糊,清晰，描述是否一清二楚?还是自说自话?容易看懂和理解吗?
4、一致：产品功能描述是否自相矛盾,与其他功能有没有冲突?
5、贴切：描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
6、合理：在特定的预算和进度下,以现有资源能否实现?
7、代码无关：是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
8、可测试性：特性能否测试? 是否能为测试员建立验证操作的测试程序提供足够的信息?
（二）文档用语检查清单
说明：对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从文档上找出这样的用语,仔细审视它们在文中是怎样使用的。文档可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷。
1、总是,每一种,所有,没有,从不，如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
2、当然,因此,明显,显然,必然。这些话意图诱使接受假定情况，不要中了圈套。
3、某些,有时,常常,通常,惯常,经常,大多,几乎。这些话太过模糊，"有时"发生作用的功能无法测试。
4、等等,诸如此类,依此类推。以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论。
5、良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义。
6、已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能。
7、如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述，想一想"如果"没有发生会怎样。 |
|
/2 
关于我们
发表于 2005-4-21 09:29:29
楼主
