走马观花之bug预防

说明：本文内容为小强老师在卓望139公司任职期间做的内部培训分享，版权属于小强老师，我们欢迎大家拿来做免费分享，但鄙视拿来做商业培训！

页面分辨率

产品的网页通常保证在1024*768的分辨率下显示正常，但是常常忽略在其他分辨率下的显示情况（如： 800*600 ）。
如果页面设计明确只考虑1024*768的需求，则只在1024*768下验证各个产品页面的显示正确无误。
预防方法：
集成程序后的页面需要分别在两种显示分别率下验证显示的正确性。

页面提示语与提示框

通常情况下，产品人员并不会将产品需求细化到某句话应该如何提示用户，所以不同的程序员会根据自己的语言特点来提示用户，这就造成了不同程序员提示的语言风格完全不一样，造成产品友好度下降。
对于提示框的大小以及样式比较混乱，有的是windows的弹框提示，有的则是浮层提示（如：139说客上有的浮层太大）。
平台接口返回的错误码有时没有转化成前端用户语言
预防方法：
 产品人员和开发人员一起制定尽可能大而全的提示语言规范，并且作为规范说明提供给开发人员进行使用。

页面链接

链接的有效性及正确性。
图片的链接，这个会被开发人员忽略掉。
图片的显示位置通常会显示不同像素大小和比例的图，所以需要明确定义大图片如何缩减成为小图片的策略，以及小图片如何拉伸显示为大的图片。（如：139说客中的发图片后的展开以及头像的缩率图等）

预防方法：
提供的需求中明确图片是否需要链接以及链接的位置。
需求中明确图片显示策略，是等比缩放显示，还是原大小显示，还是自适应显示，并且制定相应策略的统一处理模块。
可以利用辅助工具，如Xenu来检查链接有效性。(简单演示)

页面title

开发过程中关注点集中在功能，造成细节的忽视或遗漏，Web Title 经常忘记设置。
由于需求的频繁变更，在页面内容作出变动后，一定要记得Web  Title作出相应的改动。
预防方法：
不要将title写死在html中，多用setTitle()方法设置Web Title或写在配置文件中。

页面简单的性能测试

可能由于网页要下载带有大量图片或其他东东导致整个页面下载变慢。
有时候由于超时会造成的白页现象。
预防方法：
减少大东东的下载，尤其是在主页或一些重要页面。
在做前端测试时，如果发现页面下载缓慢可以用HttpWatch等工具辅助看下到底是哪些东西影响了页面的展现速度。
尽量少使用图片，或者使用优化处理过的图片。
超时的处理：设置合理的等待时间，或者给一个友好的界面提示；另外，读取不到平台数据时的提示信息是否也考虑加入？如金豆未读取到的提示信息是NAN

兼容性测试——浏览器

由于现在浏览器的泛滥，需要对主流的浏览器进行测试，如360，ie6、7，FF，google浏览器、TT等。
开发的同学可能在ff下开发的比较多，往往在ie上会出现一些问题。
预防方法：
设计组需要制定页面设计规范和Js设计规范，保证主流浏览器的页面显示兼容性和Js设计兼容性。
通常情况下要保证IE 6/IE 7和FireFox 3浏览器下的兼容性，需要保证页面不变型，Js执行均正确。

快捷键与焦点

页面中支持tab按键切换的要检验使用的正确性和合理性

对类似表单提交处按钮的回车键支持

打开首页后焦点的初始位置（如，当打开sina mail后焦点不会自动落入email的输入框，用户体验不好；而网易的邮箱则会自动将焦点落入到email的输入框）

预防方法：
需求设计过程中需要考虑tab和回车键的使用合理性。
程序设计或者页面设计出一个tab键使用的通用设计或者规范。
设计前期就考虑到初始焦点的落入位置，提高用户体验性

浏览器操作

同一个用户使用多个浏览器进行登陆操作给出相应的提示。

表单——字符

原来测试的时候，有这样的规定1个汉字=1个英文字符，和通常的1个汉字=2个英文字符不同
注册页面在设置密码的时候支持右键菜单，能够将中文字符复制到输入框中并设置成功，之前测试客户端注册的时候遇到过类似这样的问题，导致登陆的时候无法登陆；
预防方法：
统一下英文字符、汉字、数字、标点等的长度，形成一个统一设计与开发的规范
应该避免将中文字符复制到输入框中并设置成功。

表单——长字符

输入框输入很长连续的数字或英文，并且不折行，则提交数据后，有可能会把页面拉的很长。
如果要将文字后面的一些文字处理为省略号的时候，需要注意不要将中文截成半个字符。
预防方法：
提交公共处理字符的程序，解决上述问题，来进行公用

表单——重复提交

用户提交数据页面，用户有可能连续多次点击提交按钮，造成数据的重复提交。
预防方法：

用户点击“提交”后，将按钮变为Disable状态

表单——特殊字符

所有键盘输入的特殊字符，均可以正常保存。
需要特别处理英文单引号、双引号等引起程序错误的问题。
需要处理“<”、“/”和“”等容易保存出错的字符。
对特殊代码的处理，如<iframe src=www.baidu.com></iframe>
<script>alert(“deba”)</script>（见下图）
预防方法：
开发公共处理特殊字符的模块，在系统中进行规范应用

表单——判断

数字框只能输入数字的内容。
日期框需要判断日期是否合以及考虑闰年的情况和每个月30、31天不一样的情况。
文本框需要判断字段长是否限制了。
对于空格的处理，如果系统想trim掉字符串最开头和最后的空格，则需要整个儿系统都使用此策略，否则会造成数据传递不一致的问题。（如，搜索时前后加空格的处理）
需要前台页面使用js来判断输入的合法性，同时后台逻辑也要添加判断输入合法性的判断。（有时候虽然前端做了限制，但垃圾数据还是会进入后台，所以两端都要做限制）

安全方面——url

在URL中不要把密码等敏感的用户信息明文的显示在url中
即使要传递密码参数也不要使用pwd、passpord这样的参数名称来进行传递，防止被截获
要在传递参数的操作中使用NoCache参数，防止将url参数进行缓存
预防方法：

建立标准的数据传输和命名规范，并制作一些网页开发模板或者规范供参考

安全方面——sql注入

不要把数据库或者程序的任何报错信息显示在页面上。
最好程序能够将select update delete 这些关键字都过滤掉，不让用户提交包含这些数据的信息。
数据库中设计到操作权限的表名和字段名用很通俗易懂的名字
输入框尽量过滤掉“<>”这样的字符，防止javascript攻击
预防方法：
出错的时候使用错误处理页面，建立标准的过滤关键字程序，统一数据库设计命名规范，建立防js攻击的标准函数
PS：之前凡客vancl就出现过这样的情况，报错页把server的信息全部显示了出来，可惜当时没截下图

cookies

Cookie没有设定过期时间。
IE不支持Cookie的时候没有任何提示信息。
Cookie中的敏感信息没有进行加密。
预防方法：
明确cookie生存期，并对生成的cookie进行检查，建立标准的检查浏览器对cookie支持的程序函数

数据库测试

Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。
数据一致性错误主要是由于用户提交的表单信息不正确而造成的。
输出错误主要是由于网络速度或程序设计问题等引起的。（如，web聊天室，可能因为网络不好，当与server断开后程序会自动重连几次，无效后会给用户一个提示信息）
预防方法：
对表单的提交进行统一严格的处理，遵循一定的规范
对于一些异常或未知的错误给出有好的提示信息，并能进行快速处理

简单的并发测试

比如同一台测试机打开2个IE，前后定位在同一页面，然后执行特定操作，比如删除已删除的数据，系统是给出找不到对象呢？还是友好提示或者直接报错呢 ？

各种资源的链接释放

有的时候，系统莫名访问不了，则有可能是数据库连接没有释放
压力测试的时候，连接释放如果效率不高，则有可能出现大量连接超时失败
预防方法：
系统资源的释放过程，最好通过代码review的方式来互相监督

系统上线的log配置

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

server配置

如果需要在一个连接同时获取多个资源，则需要打开apache或者resin的Keepalive参数为On，来提高系统的处理能力，减少多次建立连接所消耗的资源。如果大量的处理只是一次性连接，则不要打开Keepalive设置。
在实际工作中，需要将keepalive分别设置On或者Off来验证哪个设置的性能更好。
PS：像一些中间价什么的可能小小的参数配置不合理就会引发大大的问题

其他

短信的下发一定要有数量的限制，防止对人造成骚扰和不安全的因素。
针对域名的使用，最好使用配置文件的方式来指定域名，不要在程序或者数据库中写死域名。
未登录用户的访问问题：未登录情况下访问页面时，如果不能被访问，应该提示登录，并在url中带上backurl，以便登录后能直接跳转到该页面

memcache

1、为什么 memcached 没有我的数据库快？这是我们测试的时候经常会遇到的问题。看看下面的解释吧。 
在一对一的比较中， memcached 可能没有你的 SQL 查询快。然而，这并不是它的目标。 memcached 的目标是可伸缩性。随着连接和请求的增加， memcached 将会表现出比单独的数据库解决方案更好的性能。在决定 memcached 不适合你的应用之前，请将你的代码放在高并发的环境中测试。 
注：的确，数据量不够大的时候体现不出memcache的性能。例如你获取大量回复数超过10条的notes，get from db和get from memcache就会差很多很多~~~~；如果是小于10条的notes则不会差太多。