吴老的《selenium webdriver 实战宝典》出版了！
测试人员在每次版本迭代中，会对项目的整体质量有一个把控，对于项目常见的问题，开发经常犯的错误都会有所了解，为了避免或者减少这样的错误或不规范的事情在发生，测试人员可以整理构建属于产品的bug预防体系，总结项目经常出现bug的种类、位置、以及可以提出针对性的规避措施，提高产品质量。
Ø 产品的网页通常保证在1024*768的分辨率下显示正常，但是常常忽略
Ø 如果页面设计明确只考虑1024*768的需求，则只在1024*768下验证各个
Ø 开发：网页页面的设计需要针对多种屏幕分辨率制定设计规范，并依据设计规范进行开发
通常情况下要保证IE6-11和360 浏览器下的兼容性，需要保证页面不变型，
Ø 开发：针对需要兼容的浏览器类型和版本，指定浏览器兼容设计开发规（ CSS和Js 为主），并不断总结兼容性的经验教训
Ø 测试：在产品要求兼容的浏览器类型和版本下，进行兼容性测试
Ø 保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面
Ø 产品：提供的需求中明确是否需要链接以及链接的位置以及链接的打
Tab键和焦点的切换：在测试的页面中使用Tab键可以在全页面的所有元素进行焦点切换、并且要将相邻元素的 tab键切换顺序做到关联。
b. 在用户名输入框输入用户名之后，按下tab 键后，焦点应该切换到密码输入框中，而不是切换到其他元素上。
c. 输入密码后，按下tab键可将焦点切换到“保存密码”的复选框或者登录按钮以上操作，均对偏好使用快捷键的用户给于更友好的支持。
Ø 产品：考虑页面的默认焦点设定位置，设定tab键在界面上切换焦点的顺序
Ø 开发：依据产品人员的要求实现默认焦点位置，和tab 键的切换顺序
IE 有一个特性：就是允许前进、后退到某一个页面或在当前页面刷新，在某些特殊业务场景的要求下，用户进行前进、后退和刷新当前页面的操作，会造成数据不完整、校验失败或者重复提交的情况。
Ø 产品：明确哪些敏感页面不允许前进、后退和刷新，一般情况下充值和支付等相关的页面或者其他数据提交页面禁止后退和刷新后提交。
Ø 开发：从技术层面考虑后退和前进操作是否会造成系统漏洞，让用户重复充值或者支付。如果用户尝试后退，则让页面强制失效或者禁止后退。
通常情况下，产品人员并不会将产品需求细化到某句话应该如何提示用户，所以不同的程序员会根据自己的语言特点来提示用户，这就造成了不同程序员提示的语言风格完全不一样，造成产品友好度下降。
Ø 产品：产品人员和开发人员一起制定尽可能大而全的产品提示语言规范，并且作为规范说明提供给开发人员进行使用。
Ø 开发：遵守语言说明规范，并且针对各种系统的要求不断补充和规范提示
f. 在语言中，永远不要用“你”这个字，要做一些操作步骤描述的时候，要多用“请”字
输入框提交很长的纯英文字母或者数字（不带任何全角字符和中文），并且不换行，则提交数据后，页面可能被此相关字符拉伸的特别长。
Ø 开发：提交公共处理字符的程序，解决上述问题，在所有输入框中增加相关处理
Ø 测试：所有输入框需要进行此输入测试，保证页面不会被用户的恶意输入拉长
图片是否增加链接通常会被开发人员忽略掉图片的显示位置通常会显示不同像素大小和比例的图，所以需要明确定义大图片如何缩减成为小图片的策略，以及小图片如何拉伸显示为大的图片。
Ø 产品：提供的需求中明确图片是否需要链接以及链接的url地址以及点击后实在当前页打开，还是弹出新页面打开。明确用户上传图片的显示方法，采用等比缩放，还是原大小显示，还是自适应显示
Ø 开发： 按照产品要求进行开发，针对图像的显示开发统一显示模块
Ø 测试：点击图片链接，验证图片链接的正确性和打开方式是否符合产品设计要求。传不同格式的图片（长方形图、正方形的图、原型图、超大图和超小图)，验证图片显示策略符合产品
用户提交数据页面，用户有可能连续多次点击提交按钮，造成数据的重复提交。
黑客或者不良用户通过抓包可以获取提交的url ，进行尝试重复提交。
Ø 开发：点击“提交”后，将按钮变为Disable状态，禁止用户再次点击。针对每条提交的数据需要增加校验参数，方式不良用户通过其他工具恶意提交。
Ø 测试：通过页面验证按钮点击后的状态，通过工具发送重复提交的请求，验证系统是否可以处理重复提交的问题（金融系统需重点测试）
Ø 需要处理“ <”、“ /”和“ \”等容易保存出错的字符
Ø 对于空格的处理，如果系统想trim掉字符串最开头和最后的空格，则需要整个儿系统都使用此策略，否则会造成数据传递不一致的问题
Ø 需要前台页面使用js来判断输入的合法性，同时后台逻辑也要添加判断输入合
Ø 测试：对所有输入字段，进行输入判断测试，超长、空、特殊字符、 utf8字符等，并验证其他页面输入有效性，验证前台和后台均加有输入判断逻辑。
Ø 用户可能打开不同的IE使用相同的用户登录后进行操作，程序处理的时候要考虑到数据的一致性和同步问题
Ø 多个IE使用不同用户，则cookie操作不会出现用户信息混乱的问题
Ø 开发：提前考虑到多个IE操作和多用户操作的使用场景，在使用cookie本地信息时需要做好针对性的程序处理，依据以往出现的问题设计开发规范
Ø 测试：按照多浏览器和多用户的使用情况，进行更多场景的测试
Ø 在URL中不要带有明文的用户信息写代码的时候，不要把密码等敏感的用户信息明文的显示在url中
Ø 即使要传递密码参数也不要使用pwd、 passpord这样的参数名称来进行传递，防止被截获
Ø 要在传递参数的操作中使用NoCache参数，防止将url参数进行缓存
Ø 开发： 建立数据传输技术规范和参数命名规范标准，严格参照执行，防止信息被拦截，造成应用系统的信息泄露
Ø 测试：在缓存目录验证缓存信息是否有敏感信息，通过抓包方式验证是否暴露了敏感信息
在Web系统中，匿名在地址栏直接输入各个功能页面的URL地址，检查
Ø 测试：获取所有系统url，在非登录情况下进行遍历截图，或关键字判断，验证非登录状态下无法访问具有访问权限限定的
Ø 数据库中设计到操作权限的表名和字段名不要使用过于通俗易懂的命名，尤其是用户和密码之类的信息，禁止使用明文存储密码
Ø 页面回显的input text, input hidden中的文本内容需过滤 “ <、 >、 ”、’等字符（半角转换为全角或者删除掉），防止 javascript 的跨站攻击
Ø 开发：出错的时候使用错误处理页面，建立标准的过滤关键字程序，统一数据库设计命名规范将敏感的表名做特殊命名处理，密码使用Md5或其他加密方式保存
Ø 测试：验证所有页面不会暴露系统的任何出错信息使用安全工具appscan 或其他工具扫描系统的sql注入漏洞和跨站攻击漏洞
Cookie没有设定过期时间IE不支持Cookie的时候没有任何提示信息Cookie中的敏感信息没有进行加密
Ø 开发：明确cookie生存期，并对生成的cookie进行检查，建立标准的检查浏览器对cookie支持的程序函数
有的时候，系统莫名访问不了，有可能是数据库连接没有释放压力测试的时候，连接释放如果效率不高，则有可能出现大量连接超时失败内存泄露，长时间工作内存被占满了。
Ø 开发：系统资源的释放过程，最好通过代码review的方式来互相监督
Ø 测试：进行稳定性测试，验证长时间工作情况下的资源是否可以释放
如果需要在一个连接同时获取多个资源，则需要打开apache或者resin的Keepalive参数为On，来提高系统的处理能力，减少多次建立连接所消耗的资源。如果大量的处理只是一次性连接，则不要打开Keepalive设置。在实际工作中，需要将keepalive分别设置On或者Off来验证哪个设置的性能更好。
运维和开发：系统管理员对所有打开log级别进行确认，并群发相关人确认
用户删除某个数据前，要明确提示用户是否要删除，默认把焦点选择为“否”。
Ø 开发：团队中专人定期对接口文档进行审核和更新，保证文档、需求变更和程序实现保持一致
详细设计文档缺失，接口对多表进行操作时候，经常会发生有些表的数据没有被更新的情况
等等，这些我们完全可以在不断测试过程中进行总结和积累，可以给开发进行培训，让他们了解这些常见的问题，在自测时注意这些问题，提高送测产品的质量。