Web端测试总结
1、数值型输入框：
（3）特殊字符："~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能导致系统错误的字符 —— 禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交
（4）存在的数据：输入存在的搜索内容
（5）不存在的数据：输入不存在的搜索内容
2、在输入框单击鼠标左键,是否有光标出现
3、在输入框单击鼠标左键,是否有光标出现，光标出现后使用"Tab"键后,"搜索"按钮是否出现选定TIP
4、在输入框点击鼠标右键是否出现Menu,Menu内容依次为"撤消"、"复制"、"粘贴"、"删除"、"全选"(具体情况视实际情况而定)
5、检查以上Menu出现的选择模块是否可正常使用
6、在输入框输入任意长度字母、数字、汉字,双击鼠标左键,观察输入项目能否被全部选中
7、输入正则表达式
2）当前页面不在最后一页且当前的页数大于1页时，下一页和最后一页的按钮能否正常显示，可否点击
2）当前页面不在最后一页且当前数据的页数大于1页时，下一页和最后一页的按钮能否正常显示，可否点击
5）文件命名长度的名称过长。
6）文件命名长度的名称达到最大长度（中文，英文或混在一起）上传后名称显示，页面排版-----------页面显示正常
7）文件名称中包含特殊字符-------------根据需求而定
8）文件名称全为中文--------------------根据需求而定
9）文件名称全为英文--------------------根据需求而定
10）文件名称为中、英混合-----------------根据需求而定
6）文件类型大小都合适视频，文件内容相同，名称相同，上传
7）文件类型大小都合适，文件内容不同，名称不同，上传
1）一条已经成功提交的记录，返回后再提交，是否做了处理
2）检查多次使用返回键的情况，在有返回键的地方，返回到原来的页面多次，查看是否会出错
网站测试的主要方面
1 功能测试（包含基本功能测试和数据准确性校验）
对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。
B/S结构实现的功能可能主要的就在于提交数据，处理数据等，如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
- 链接测试（根据需求是否需要指导用户使用）
- 表单测试
1）当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。
例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。
如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
2）要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
3）B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
4）我们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。
- cookie测试（如果web应用系统使用cookie）
- 设计语言测试
1）Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。
2）当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。
3）除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
- 数据库测试
1）在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。
在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
2）在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。
数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
主要包括以下几个方面的内容：
（1）站点地图和导航条： 位置是否合理、是否可以导航等内容布局--布局是否合理；简介说明--说明文字是否合理，位置是否正确
（2）背景/色调： 是否正确、美观，是否符合用户需求
（3）页面：在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）；表单样式--大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等
（4）连接： 连接的形式、位置是否易于理解等
web测试的主要页面元素：
（1）页面元素的容错性列表（如输入框、时间列表或日历）
（2）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
（3）页面元素的容错性是否存在
（4）页面元素的容错性是否正确
（5）页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
（6）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
（7）页面元素是否显示正确（主要针对文字、图形、签章）
（8）元素是否显示（元素是否存在）
（9）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
测试技术
1、通过页面走查，浏览确定使用的页面是否符合需求，可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案。
2、可以结合数据定义文档查看表单项的内容，长度等信息。
3、对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用XM，封装要做的工作会多一点等。
易用性测试七大要素：符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性
1、风格、样式、颜色是否协调
2、界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条）
3、界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）
4、操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）
5、提示界面是否符合规范，有无中英文混合（不应该显示英文的cancel、ok，应该显示中文的确定、取消等）
6、界面中各个控件是否对齐，是否显示完整，间隔是否一致，是否有重叠区域
7、日期控件是否可编辑
8、日期控件的长度是否合理，以修改时可以把时间全部显示出来为准
9、查询结果列表列宽是否合理、标签描述是否合理
10、查询结果列表太宽没有横向滚动提示
11、对于信息比较长的文本，文本框有没有提供自动竖直滚动条
12、数据录入控件是否方便
13、有没有支持Tab键，键的顺序要有条理，不乱跳
14、有没有提供相关的热键
15、控件的提示语描述是否正确
16、模块调用是否统一，相同的模块是否调用同一个界面
17、用滚动条移动页面时，页面的控件是否显示正常
18、日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
19、页面是否有多余按钮或标签
20、窗口标题或图标是否与菜单栏的统一
21、窗口的最大化、最小化是否能正确切换
22、对于正常的功能，用户可以不必阅读用户手册就能使用【控件名称易懂，用词准确，与同一界面上的其他按钮易于区分】
23、执行风险操作时，有确认、删除等提示吗
24、操作顺序是否合理
25、正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确
26、系统应该在用户执行错误的操作之前提出警告，提示信息
27、页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性
28、合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理
29、检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业
30、控件字体和大小是否一致，有无错别字
5 性能测试（转）
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。
当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。
而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试(负荷测试指的是进行一些边界数据的测试）——基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。
负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试。
因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
压力测试是指实际破坏一个Web应用系统，测试系统的反应。
压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。
如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况
如果有必要可以模拟大量数据输入,对硬盘的影响等等信息
如果有必要的话必须进行性能优化(软硬件都可以).这里的压力测试针对的是某几项功能
黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存储权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
1、负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。
可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。
系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。
出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。
负载测试工具能够模拟X个用户同时访问测试站点。
3）长时间的使用
采用的测试工具：
性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具：
Apache自带的ab测试工具
OpenSTA—开发系统测试架构
Loadrunner—强大的性能测试工具
e-test、webload等
6 接口测试（转）
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
7 回归测试
过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。
回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试，是对以前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的Bug不会再出现。
实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug是否已经更正了。
值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。
所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。
web端测试中应该注意的其他情况：
存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：
1）软硬件的测试环境提供上也对测试结果有很大的影响
2）测试团队的水平，经验，合作效果等
3）整个开发流程对测试的重视程度，测试的进入时间等
4）由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同，这是需要经验以及对测试环境的保护等方面下一些功夫
【参考链接】http://www.cnblogs.com/Jessy/p/3539638.html
（如有不足，请指点。后续更新）
