蜻蜓点水之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，ie六、7，FF，google浏览器、TT等。
开发的同窗可能在ff下开发的比较多，每每在ie上会出现一些问题。
预防方法：
设计组须要制定页面设计规范和Js设计规范，保证主流浏览器的页面显示兼容性和Js设计兼容性。
一般状况下要保证IE 6/IE 7和FireFox 3浏览器下的兼容性，须要保证页面不变型，Js执行均正确。

快捷键与焦点

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

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

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

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

浏览器操做

IE 有一个特性：就是容许前进和后退到某一个页面，在某些特殊状况下，用户进行前进和后退，有可能形成数据不完整的提交，或者其余的显示问题（如，当你正在进行一笔交易时）
用户可能打开不一样的IE使用相同的用户登陆后进行操做，程序处理的时候要考虑到数据的一致性和同步问题。
多个IE使用不一样用户，则cookie操做不会出现用户信息混乱的问题。
预防方法：
 制定一些标准的策略来处理IE的前进和后退操做，做为整个儿项目的共享，防止用户返回特定的数据提交页面和浏览页面，并进行重复操做。

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

表单——字符

原来测试的时候，有这样的规定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

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