Web产品的常见问题：

1.分辨率兼容性：
1.产品的网页通常保证在1024768的分辨率下显示正常，但是常常忽略800600分辨率下的显示情况，还有其他特殊要求的分辨率
1.如果页面设计明确只考虑1024768的需求，则只在1024768下验证各个产品页面的显示正确无误
预防方法：
1.产品：需要明确产品需要兼容的常见屏幕分辨率
2.开发：网页页面的设计需要针对多种屏幕分辨率指定设计规范，并依据设计规范进行开发
3.测试：在不同分辨率下验证页面显示的兼容正确性
2.浏览器兼容性：
目前市场上的主流浏览器如下：
1.IE6.0-11、edge
2.360浏览器
3.猎豹浏览器
4.QQ浏览器
5.Chrome浏览器
6.Firefox浏览器
7.搜狗浏览器
通常情况下要保证IE6-11和360浏览器下的兼容性、需要保证页面不变形，JS执行均正确
预防方法：
1.产品：依据主流的浏览器市场占比，评估你需要兼容的浏览器
2.开发：针对需求兼容的浏览器类型和版本，指定浏览器兼容设计开发规范（CSS和JS为主），并不断总结兼容性的经验教训
3.测试：在产品要求兼容的浏览器类型和版本下，进行兼容性测试
3.F12：开发者工具
Network：抓包
Headers: 头信息（汇总信息、响应信息、请求头信息（User-Agent用户代理））
4.Link问题：
1.所有连接是否按指示那样确实连接到了该连接的页面
2.所连接的页面是否存在
3.保证WEB应用系统上没有孤立的页面，所谓孤立页面是指没有连接指向该页面
4.链接的打开方式是否合理（在当前窗口中打开、打开新窗口）
5.有死链（死链检测工具senu）
预防方法：
1.产品：提供的需求中明确是否需要链接以及链接的位置以及链接的打开方式
2.检测工具的链接如下：
http://www.csdn.net/article/2013-12-13/2817805-online-tools-for-managing-broken-liks
5.快捷键和焦点：
Tab键和焦点的切换：
在测试的页面中使用Tab键可以在全页面的所有元素进行焦点切换，并且要将相邻元素的Tab键切换顺序做到关联
例如：
1.用户打开登录首页，则焦点应该默认显示在用户名输入框中
2.在用户输入框输入用户名之后，按下Tab键后，焦点应该切换到密码输入框中，而不是切换到其他元素上
3.输入密码后，按下Tab键可以将焦点切换到“保存密码”的复选框或者登录按钮
以上操作，均对使用快捷键的用户给与更友好的支持
预防方法：
1.产品：考虑页面的默认焦点设定位置，设定tab键在页面上切换焦点的顺序
2.开发：依据产品人员的要求实现默认焦点位置，和Tab键的切换顺序
3.测试：验证默认焦点位置和Tab切换的顺序
6.前进、后退和刷新问题
IE有一个特性：就是允许前进、后退到某一个页面或在当前页面刷新，在某些特殊业务场景的要求下，用户进行前进、后退和刷新当前页面的操作，会造成数据不完整、教研失败或者重复提交的情况。
预防方法：
1.产品：明确哪些敏感页面不允许前进、后退和刷新，一般情况下充值和支付等相关页面或者其他数据提交页面禁止后退和刷新后提交。
2.开发：从技术层面考虑后退和前进操作是否会造成系统漏洞，让用户重复充值或者支付。如果用户尝试后退，则让页面强制失效或者禁止后退
3.测试：和产品确认禁止后退的操作限制页面，进行针对性测试
7.页面提示语言、JS提示语言，程序提示语言：
通常情况下，产品人员并不会将产品需求细化到某句话应该如何提示用户，所以不同的程序员会根据自己的语言特点来提示用户，这就造成了不同程度提示语言风格完全不一样，造成产品友好度下降。
预防方法：
1.产品：产品人员和开发人员一起制定尽可能大而全的产品提示语言规范，并且作为规范说明提供给开发人员进行使用
2.开发：遵守语言说明规范，并且针对各种系统的要求不断补充和规范提示语
3.测试：测试过程中，验证语言是否符合指定的语言规范
8.语言文字提示（微软的标准）：
1，全角字符和半角字符都要使用一个空格分开
2，英文和数字之间要有空格分开
3，汉子和英文、数字要有空格分开
4，带有汉字的话要使用全角字符
5，语言中不要混用全角和半角标点
6，在语言中，永远不要用“你”这个字，要做一些操作步骤描述的时候，要多用“请”字
9.文字缩略和折行：
1.输入框提交很长的纯英文字母或者数字（不带任何全角字符和中文），并且不换行，则提交数据后，页面可能被此相关字符拉伸的特别长。
2.如果要将文字后面的一些文字处理为省略号的时候，需要注意不要将中文截成半个字符
预防方法：
➢ 开发：提交公共处理字符的程序，解决上述问题，在所有输入框中增加相关处理
➢ 测试：所有输入框需要进行此输入测试，保证页面不会被用户的恶意输入拉长
网站：w3cschool
10.图片的显示和链接：
图片是否增加链接通常会被开发人员忽略掉
图片的显示位置通常会显示不同像素大小和比例的图，所以需要明确定义大图片如何缩减成为小图片的策略，以及小图片如何拉伸显示为大的图片
预防方法：
➢ 产品：提供的需求中明确图片是否需要链接以及链接的url地址以及点击后实在当前页打开，还是弹出新页面打开。明确用户上传图片的显示方法，采用等比缩放，还是原大小显示，还是自适应显示
➢ 开发： 按照产品要求进行开发，针对图像的显示开发统一显示模块
➢ 测试：点击图片链接，验证图片链接的正确性和打开方式是否符合产品设计要求。传不同格式的图片（长方形图、正方形的图、原型图、超大图和超小图)，验证图片显示策略符合产品设计要求
11.重复提交：
用户提交数据页面，用户有可能连续多次点击提交按钮，造成数据的重复提交。
黑客或者不良用户通过抓包可以获取提交的url ，进行尝试重复提交。
预防方法：
➢ 开发：点击“提交”后，将按钮变为Disable状态，禁止用户再次点击。针对每条提交的数据需要增加校验参数，方式不良用户通过其他工具恶意提交。
➢ 测试：通过页面验证按钮点击后的状态，通过工具发送重复提交的请求，验证系统
是否可以处理重复提交的问题（金融系统需重点测试）
12.输入判断问题（1）：
1.所有键盘输入的特殊字符，均可以正常保存
2.需要特别处理英文单引号、英文双引号等引起程序错误的问题
3.需要处理“<”、“/”和“\”等容易保存出错的字符
4.数字框只能输入数字的内容
5.日期框需要判断日期是否合法
6.文本框需要判断字段长是否限制了
7.对于空格的处理，如果系统想trim掉字符串最开头和最后的空格，则需要整个儿系统都使用此策略，否则会造成数据传递不一致的问题
8.需要前台页面使用js来判断输入的合法性，同时后台逻辑也要添加判断输入合法性的判断。
预防方法：
➢ 开发：开发公共处理特殊字符的模块，在系统中进行规范应用
➢ 测试：对所有输入字段，进行输入判断测试，超长、空、特殊字符、utf8字符等，并验证其他页面输入有效性，验证前台和后台均加有输入判断逻辑
13.多个IE同时访问的情况：
 用户可能打开不同的IE使用相同的用户登录后进行操作，程序处理的时候要考虑到数据的一致性和同步问题
 多个IE使用不同用户，则cookie操作不会出现用户信息混乱的问题
预防方法：
➢ 开发：提前考虑到多个IE操作和多用户操作的使用场景，在使用cookie本地信息时需要做好针对性的程序处理，依据以往出现的问题设计开发
规范
➢ 测试：按照多浏览器和多用户的使用情况，进行更多场景的测试
14.安全考虑：
 在URL中不要带有明文的用户信息写代码的时候，不要把密码等敏感的用户信息明文的显示在url中
 即使要传递密码参数也不要使用pwd、passpord这样的参数名称来进行传递，防止被截获
 要在传递参数的操作中使用NoCache参数，防止将url参数进行缓存
预防方法：
➢ 开发： 建立数据传输技术规范和参数命名规范标准，严格参照执行，防止信息被拦截，造成应用系统的信息泄露
➢ 测试：在缓存目录验证缓存信息是否有敏感信息，通过抓包方式验证是否暴露了敏感信息

15.安全考虑：
直接URL链接检查：在Web系统中，匿名在地址栏直接输入各个功能页面的URL地址，检查系统是否处理了权限控制
预防方法：
➢开发：代码走查的方式确认所有页面的具有权限验证逻辑
➢测试：获取所有系统url，在非登录情况下进行遍历截图，或关键字判断，验证非登录状态下无法访问具有访问权限限定的

16.防止Sql注入(将非授权的SQL注入)和跨站（同域名的只能执行同域名的js,A网站不能执行B网站的JS，否则会有风险，如用户权限的盗用）攻击：
 不要把数据库或者程序的任何报错信息显示在页面上。
 数据库中设计到操作权限的表名和字段名不要使用过于通俗易懂的命名，尤其是用户和密码之类的信息，禁止使用明文存储密码
 页面回显的input text, input hidden中的文本内容需过滤 “<、>、”、’等字符（半角转换为全角或者删除掉），防止 Javascript的跨站攻击
工具：APPscn
预防方法：
➢ 开发：出错的时候使用错误处理页面，建立标准的过滤关键字程序，统一数据库设计命名规范将敏感的表名做特殊命名处理，密码使用Md5或其他加密方式保存
➢ 测试：验证所有页面不会暴露系统的任何出错信息使用安全工具appscan 或其他工具扫描系统的sql注入漏洞和跨站攻击漏洞

17.关于Cookie：
Cookie没有设定过期时间
IE不支持Cookie的时候没有任何提示信息
Cookie中的敏感信息没有进行加密
预防方法：
➢ 开发：明确cookie生存期，并对生成的cookie进行检查，建立标准的检查浏览器对 cookie支持的程序函数
➢ 测试：检查cookie的生存周期，以及是否存在敏感内容
cookie 和 session 的区别，如果cookie功能关闭了，对于session 是否有影响？

18.各种资源连接的释放：
有的时候，系统莫名访问不了，有可能是数据库连接没有释放，压力测试的时候，连接释放如果效率不高，则有可能出现大量连接超时失败内存泄露，长时间工作内存被占满了。
预防方法：
➢ 开发：系统资源的释放过程，最好通过代码review的方式来互相监督
➢ 测试：进行稳定性测试，验证长时间工作情况下的资源是否可以释放

关于Keepalive的设置：
如果需要在一个连接同时获取多个资源，则需要打开apache或者resin的Keepalive参数为On，来提高系统的处理能力，减少多次建立连接所消耗的资源。如果大量的处理只是一次性连接，则不要打开Keepalive设置。在实际工作中，需要将keepalive分别设置On或者Off来验证哪个设置的性能更好

19.系统上线的log配置：
上线以后，要关闭无用大量调试log信息
不要打开过多的log
预防方法：
➢ 运维和开发：系统管理员对所有打开log级别进行确认，并群发相关人确认

20.用户易用性：
用户删除某个数据前，要明确提示用户是否要删除，默认把焦点选择为
“否”。
预防方法：
➢ 开发：按照上述要求进行焦点设定
➢ 测试：进行测试确认

21.文档：
• 程序实现和接口文档描述不一致
预防方法：
➢ 开发：团队中专人定期对接口文档进行审核和更新，保证文档、需求
变更和程序实现保持一致
➢ 测试：仅参照文档进行测试
多表操作：
详细设计文档缺失，接口对多表进行操作时候，经常会发生有些表的数据没有被更
新的情况
预防方法：
➢ 开发：审核设计文档是否覆盖必要的逻辑，加强代码审查
➢ 测试：通过查询接口判断所有插入接口的数据库操作是否正确

22.参数的容错处理：
接口没有对参数进行必要的容错，参数出现错误的时候，接口也没有做相应的错误处理，文档也没有
描述容错机制和返回代码
预防方法：
➢ 开发：明确每个接口对哪些情况进行必要的容错，并写到设计文档中，由Leader 进行文档审核
➢ 测试：严格按照接口文档的容错描述进行测试，并且可以结合参数类型和非法参数进行结合测试
思考：如果接口加入了非常多的严格判断，这个是好事儿？还是不好的事儿？
假设测试的产品是开放平台或者公司内部服务的平台层。
不好，只对关键的数进行判断不然性能会受影响。