总结，总结，新的一年开始总结下以前
1.关于web登录的操作
快捷键的使用是否正常：
1. TAB 键的使用是否正确
2.上下左右键是否正确
3.界面如果支持 ESC键 看是否正常的工作
3.ENTER 键的使用是否正确切换时是否正常。
布局美感
界面的布局是否符合人的审美的标准
输入框的功能：
输入合法的用户名和密码可以成功进入
输入合法的用户名和不合法密码不可以进入，并给出合理的提示
输入不合法的用户名和正确密码不可以进入，并给出合理的提示
输入不合法的用户名和不正确的密码不可以进入，并给出合理的提示
不合法的用户名有：不正确的用户名，，使用了字符大于用户名的限制
正常用户名不允许的特殊字符 空的用户名，系统（操作系统和应用系统）的保留字符
不合法的密码有：空密码（除有特殊规定的），错误的密码，字符大于密码的限制
正常密码不允许的特殊字符，系统（操作系统和应用系统）的保留字符
界面的链接：
对于界面有链接的界面，要测试界面上的所有的链接都正常或者给出合理的提示
补充
输入框是否支持 复制和黏贴 和移动
密码框显示的不要是具体的字符，要是一些密码的字符
验证用户名前有空格是否可以进入，一般情况可以。
验证用户名是否区分大小写。（有的软件是区分大小写的）
验证必填项为空，是否允许进入。
验证登录的次数是否有限制。从安全角度考虑，有些安全级别高的软件会考虑这方面的限制
2.搜索功能测试用例设计
对被测试点进行分解，把测试用例分解为多个测试场景
| 场景编号 |
场景描述 |
预期结果 |
| 场景一 |
页面检查 |
正确 |
| 场景二 |
默认条件搜索 |
查询结果正确 |
| 场景三 |
修改可选条件搜索 |
查询结果正确 |
| 场景四 |
修改输入条件搜索 |
查询结果正确 |
| 场景五 |
修改区间条件搜索 |
查询结果正确 |
| 场景六 |
组合可选、输入条件搜索 |
查询结果正确 |
| 场景七 |
操作后检查搜索条件及查询结果 |
查询结果正确 |
| 场景八 |
错误、空记录搜索 |
查询结果为空 |
测试步骤描述
按照已经分解的测试场景顺序，逐个描述测试场景的测试步骤
测试场景一：
| 步骤编号 |
具体描述 |
| 1 |
进入搜索（高级搜索）页面 |
| 2 |
界面共性测试 |
| 3 |
退出 |
测试场景二：
| 步骤编号 |
具体描述 |
| 1 |
进入搜索（高级搜索）页面 |
| 2 |
点击“搜索”按钮，显示查询结果列表 |
| 3 |
检查查询结果列表，每页显示记录条数正确、文字折行显示正确、页面布局美观 |
| 4 |
检查查询结果列表，列标题项、列显示内容、排序方式符合需求定义 |
| 5 |
检查查询结果列表，符合默认查询条件结果集 |
| 6 |
点击查询结果列表链接、复选框、全选框响应正确 |
| 7 |
退出 |
测试场景三：
| 步骤编号 |
具体描述 |
| 1 |
进入搜索（高级搜索）页面 |
| 2 |
逐一选择各个查询条件可选项，如：“全部”、“类别1”等，点击“搜索”，查询结果正确 |
| 3 |
组合各个查询条件可选项，如：价格＋产品，点击“搜索”，查询结果正确 |
| 4 |
退出 |
测试场景四：
| 步骤编号 |
具体描述 |
| 1 |
进入搜索（高级搜索）页面 |
| 2 |
逐一输入文本域条件，模糊查询值，点击“搜索”，查询结果正确 |
| 3 |
逐一输入文本域条件，完全匹配值，点击“搜索”，查询结果正确 |
| 4 |
逐一输入文本域条件，中文值，点击“搜索”，查询结果正确 |
| 5 |
逐一输入文本域条件，字母大、小写值，点击“搜索”，查询结果正确 |
| 6 |
逐一输入文本域条件，数字类型值，点击“搜索”，查询结果正确 |
| 7 |
逐一输入文本域条件，全角、半角值，点击“搜索”，查询结果正确 |
| 8 |
组合各个文本域查询条件，点击“搜索”，查询结果正确 |
| 9 |
退出 |
3.翻页功能测试用例
翻页功能我们常碰到的一般有以下几个功能：
1、首页、上一页、下一页、尾页。
2、总页数，当前页数
3、指定跳转页
4、指定每页显示条数
当然，有一些是少于多少页，全部以数字的形式显示，多于多少页后，才出现下一页的控件。
对于1翻页链接或按钮的测试，主要要检查的测试点有：
1、有无数据时控件的显示情况
2、在首页时，首页和上一页是否能点击
3、在尾页时，下一页和尾页是否能点击
4、在非首页和非尾页时，四个按钮功能是否正确
5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序
对于2总页数，当前页数，主要要检查的测试点有：
1、总页数是否等于总的记录数/指定每页条数
2、当前页数是否正确
对于3指定跳转页，主要要检查的测试点有：
1、是否能正常跳转到指定的页数
2、输入的跳转页数非法时的处理
对于4指定每页显示条数，主要要检查的测试点有：
1、是否有默认的指定每页显示条数
2、指定每页的条数后，列表显示的记录数，页数是否正确
3、输入的每页条数非法时的处理
分析完上面的测试点，应该可以进行用例的设计了。
step 1: 列表无记录
expect: 1、四个翻页控件变灰不可点击
2、列表有相应的无数据信息提示
3、不可指定页数
4、不可指定跳转页
5、总页数显示为0
6、当前页数显示为0
step 2: 列表的记录数<=指定的每页显示条数
expect: 1、四个翻页控件变灰不可点击
2、总页数显示为1
3、当前页数显示为1
step 3: 列表的记录数>指定的每页显示条数
expect: 1、默认在首页，当前页数为1
2、列表的数据按照指定的排序列正确排序
3、记录数与数据库相符
4、总页数＝记录数/指定的每页显示条数
step 4: 列表的记录数>指定的每页显示条数，在首页
expect: 1、首页变灰不可点击
2、上一页变灰不可点击
3、下一页可点击，从（每页指定条数＋1）条记录开始显示，当前页数+1
4、尾页可点击，显示最后页的记录
step 5: 列表的记录数>指定的每页显示条数，在中间的某页
expect: 1、首页可点击，显示1到每页指定条数的记录
2、上一页可点击，显示上一页的记录
3、下一页可点击，从后一页的记录
4、尾页可点击，显示最后页的记录
5、列表的数据按照指定的排序列正确排序
6、当前页数为所在页
step 6:列表的记录数>指定的每页显示条数，在尾页
expect: 1、首页可点击，显示1到每页指定条数的记录
2、上一页可点击，显示上一页的记录
3、下一页变灰不可点击
4、尾页变灰不可点击
5、列表的数据按照指定的排序列正确排序
6、当前页数为最后一页的页数
step 7:输入每页显示条数为正整数
expect: 1、每页显示条数更新成指定的条数
2、超过指定的条数的记录分页显示
3、总页数更新成列表的记录数/每页显示条数
step 8:输入每页显示条数为0
expect: 1、提示“每页显示条数必须为大于1的整数”
2、提示后每页显示条数恢复为上次生效的条数
step 9:输入每页显示条数为负数
expect: 1、提示每页显示条数必须为大于1的整数
2、提示后每页显示条数恢复为上次生效的条数
step 10:输入每页显示条数长度超过数据库指定的长度<<<maxlen>>>
expect: 1、提示每页显示条数不能超过<<<maxlen>>>位
2、提示后每页显示条数恢复为上次生效的条数
step 11:输入每页显示条数为字符串，如中文翻页数
expect: 1、提示每页显示条数必须为大于1的整数
2、提示后每页显示条数恢复为上次生效的条数
step 12:输入每页显示条数为特殊字符，如％
expect: 1、提示每页显示条数必须为大于1的整数
2、提示后每页显示条数恢复为上次生效的条数
step 13:输入每页显示条数为html字符串，如<br>
expect: 1、提示每页显示条数必须为大于1的整数
2、提示后每页显示条数恢复为上次生效的条数
step 14:输入跳转的页数为存在的页数
expect: 1、正确跳转到指定的页数
step 15:输入跳转的页数不存在或非法值
expect: 1、跳转的页数值置为1，显示第一页的数据
以上的用例是将总页数，当前页数都揉进了翻页控件的测试用例中了
4.输入框的测试
最近在测试Web的输入框的时候，老是不知道从何处下手，去网上搜罗了一些资料，当然网上对输入框的测试资料少之又少，所以我作了一个简单的总结，总的情况有一下几个方面：
1.验证输入与输出的是否信息一致；
2.输入框之前的标题是否正确；
3.对特殊字符的处理，尤其是输入信息徐需要发送到数据库的。特殊字符包括：'（单引号）、"（双引号）、[]（中括号）、（）（小括号）、{}（大括号）、；（分号）、<>（大于小于号）……
4.对输入框输入超过限制的字符的处理，一般非特殊的没有作出限制的在255byte左右；
5.输入框本身的大小、长度；
6.不同内码的字符的输入；
7.对空格、TAB字符的处理机制；
8.字符本身显示的颜色；
9.密码输入窗口转换成星号或其它符号；
10.密码输入框对其中的信息进行加密，防止采用破解星号的方法破解；
11.按下ctrl和alt键对输入框的影响；
12.对于新增、修改、注册时用的输入框，有限制的，应该输入时作出提示，指出不允许的或者标出允许的；
13.对于有约束条件要求的输入框应当在条件满足时输入框的状态发生相应的改变，比如选了湖南就应该列出湖南下面的市，或者选了某些条件之后，一些输入框会关闭或转为只读状态；
14.输入类型；根据前面的栏位标题判断该输入框应该输入哪些内容算是合理的。例如，是否允许输入数字或字母，不允许输入其他字符等。
15.输入长度；数据库字段有长度定义，当输入过长时，提交数据是否会出错。
16.输入状态；当处于某种状态下，输入框是否处于可写或非可写状态。例如，系统自动给予的编号等栏位作为唯一标识，当再次处于编辑状态下，输入框栏位应处于不可写状态，如果可写对其编辑的话，可能会造成数据重复引起冲突等。
暂时，就能想这么多，看大家谁还有观点，互相学习下！
17.如果是会进行数据库操作的输入框，还可以考虑输入SQL中的一些特殊符号如单引号等，有时会有意想不到的错误出现
18.输入类型 输入长度 是否允许复制粘贴 为空的情况 空格的考虑 半角全角测试 对于密码输入框要考虑显示的内容是* 输入错误时的提示信息及提示信息是否准确
19.可以先了解你要测试的输入框在软件系统的某个功能中所扮演的角色，然后了解其具体的输入条件，在将输入条件按照有效等价类，无效等价类，边界值等方法进行测试用例的设计。
20.关键字有大小写混合的情况；
21.关键字中含有一个或多个空格的情况，包括前空格，中间空格（多个关键字），和后空格；
22.关键字中是否支持通配符的情况（视功能而定）；
23.关键字的长度分别为9、10、11个字符时的情况；
24.关键字是valid，但是没有匹配搜索结果的情况；
25.输入html的标签会出现哪些问题？输入<；html>； 会出现什么问题呢？
安全测试方面：
给出一些特别的关键字，比如 or 1=1， 这样的关键字如果不被处理就直接用到数据库查询中去，后果可想而知。
5.Web测试的常用的检查点
1，页面连接检查每一个连接是否都有对应的页面，并且页面之间切换正确。（这里也可以用Xune工具）
2，相关性检查删除/增加一项是否会对其他项产生影响，如果产生影响，这些影响是否都正确。
3，检查按扭的功能是否正确如update，cancel，delete，save等功能是否正确。
4，字符串长度检查输入超过需求说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。
5，字符类型检查在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整形的地方输入其他字符类型），看系统是否检查字符类型，是否报错。
6，标点符号检查输入内容包括各种标点符号，特别是空格，各种引号，回车健，看系统是否处理正确。
7，中文字符处理在可以输入中文的系统输入中文（简体或繁体），看是否会出现乱码或出错。
8，检查带出信息的完整性在查看信息和update信息时，查看所填写的信息是否全部带出，带出信息和添加的是否一致。
9，信息重复检查在一些需要命名，且名字应该唯一的信息输入重复的名字或id，看系统有没有处理，是否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
10，检查删除功能在一些可以一次删除多个信息的地方，不选择任何信息，按‘delete’，看系统如何处理，是否报错，然后选择一个或多个信息，进行删除，看是否做正确处理。
11，检查添加和修改的一致，检查添加和修改信息的要求是否一致，例如添加要求必添的项，修改也应该必填，添加规定的整形的项，修改也必须为整形。
12，检查修改重名，修改时把不能重名的项改为已存在的内容看是否会处理，同时，也要注意，会不会报和自己重名的错。
13，重复提交表单一条已经成功提交的记录，back后再提交，看系统会如何处理。
14，检查多次使用back健的情况在有back的地方，back，回到原来的页面，再back，重复几次，看是否会报错。
15，search检查在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确，如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。
16，输入信息位置注意在光标停留的地方输入信息时，光标和所输入信息是否会跳到别的地方。
17，上传和下载文件检查上传和下载文件的功能是否实现，上传是否能打开。对上传文件的格式有什么规定，系统是否有解释信息，并检查系统是否能够做到。
18，必填项检查应该填写的项没有填写的时候系统是否都做了处理，对必填项是否提示信息，如在必填项前面加*. 19，快捷键检查是否支持常用快捷，如Ctrl+C，Ctrl+V，BackSpace等，对一些不允许的输入信息的字段，如选人，选日期对快捷方式是否做了限制。
20，回车检查在输入结束后直接按回车键，看系统如何处理，是否会报错。
性能测试：
1.连接速度测试用户连接到Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web 系统响应时间太长（例如超过5 秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.负载测试负载测试是为了测量Web 系统在某一负载级别上的性能，以保证Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web 系统的用户数量，也可以是在线数据处理的数量。例如：Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web 应用系统能否处理大量用户对同一个页面的请求？
6.用户及权限管理功能常规测试方法：
1) 赋予一个人员相应的权限后，在界面上看此人员是否具有此权限，并以此人员身份登陆，验证权限设置是否正确（能否超出所给予的权限）；
2) 删除或修改已经登陆系统并正在进行操作的人员的权限，程序能否正确处理；
3) 重新注册系统变更登陆身份后再登录，看程序是否能正确执行，具有权限是否正确；
4) 在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；
5) 不同权限用户登录同一个系统，权限范围是否正确；
6) 覆盖系统所有权限设定；
7) 能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令) ；
8) 能否添加长用户名及长口令，如果允许，新用户能否正确登录；
9) 系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；
10) 登录用户能否修改自己的权限；
11) 添加用户（有标识或编号）:标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；
12) 登录用户能否修改本人（或其他人）的信息，删除本人（或其他人）；
13) 修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；
14) 修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；
15) 不给用户授权，是否允许登录；
15) 改某些设置时，是否会影响具有上级权限及相同权限人员的设置；
16) 系统管理员修改了某些数据，以其他人员身份登录时数据是否改变；
17) 用户能否同时属于多个组，各个组的权限能否交叉；删除后重新添加的用户是否具有以前的权限；更改用户各项属性（包括权限）看对权限是否有影响；
7. Web测试之兼容性测试：
1. 软件兼容性测试
兼容性测试是指待测试项目在特定的硬件平台上，不同的应用软件之间，不同的操作系统平台上，在不同的网络等环境中能正常的运行的测试。
兼容性测试的目的：待测试项目在不同的操作系统平台上正常运行，包括待测试项目能在同一操作系统平台的不同版本上正常运行；待测试项目能与相关的其他软件或系统的“和平共处”；待测试项目能在指定的硬件环境中正常运行；待测试项目能在不同的网络环境中正常运行。
兼容性测试无法做到完全的质量保证，但对于一个项目来讲，兼容性测试是必不可少的一个步骤。
2. Web兼容性测试的主要类型
Web兼容性测试主要是针对不同的操作系统平台，浏览器，以及分辨率进行的测试。
2.1. 操作系统兼容性测试
常见的操作系统有Windows，Unix，Linux等，对于普通用户来讲，最常用的是Windows操作系统。Windows操作系统包括Windows XP，windows 2003，vista，Win2000/NT，Windows9x等等。用户使用操作系统的类型，直接决定了我们操作系统平台兼容性测试的操作系统平台数量，进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常运行。
对于一些特殊项目（比如定制项目），可以指定某一类型的操作系统版本，这些都应该在需求规格说明书中指明，针对这些指明的操作系统版本必须进行兼容性测试。
大部分的其他项目，是不指定操作系统版本的，针对这样的项目，我们应当针对当前的主流操作系统版本进行兼容性测试，在确保主流操作系统版本兼容性测试的前提下在对非主流操作系统版本进行测试，尽量保证项目的操作系统版本的兼容性测试的完整性。
2.2. 浏览器兼容性测试
浏览器是Web系统中对核心的组成构件，来自不同厂家的浏览器对Javascrīpt、 ActiveX或不同的HTML规格有不同的支持，即使是同一厂家的浏览器，也存在不同的版本的问题。不同的浏览器对安全性和JAVA的设置也不一样。
目前最为常用的浏览器为：IE 6.0 IE 7.0.但由于操作习惯的问题，还有相当一部分用户喜欢使用腾讯的TT，以及firefox浏览器，这些浏览器同样也存在各个版本的问题。这个对于Web系统来讲是一个相当大的挑战。
对于一些特殊项目（比如定制项目），可以指定某一类型的浏览器（包括版本），这些都必须在需求规格说明书中指明。针对这些指明的浏览器必须进行兼容性测试。但大部分的项目，是不能指定浏览器的，针对这样的项目，那么我们必须针对当前的主流浏览器（含版本），在确保主流浏览器的兼容性测试通过的前提下，再对非主流浏览器（含版本）进行测试，尽量保证项目的浏览器的兼容性测试的完整性。
2.3. 分辨率兼容性测试
分辨率的测试是为了页面版式在不同的分辨率模式下能正常显示，字体符合要求而进行的测试。
用户使用什么模式的分辨率，对于我们来讲是未知的。通常情况下，在我们的需求规格说明书中会建议某些分辨率。对于测试来讲，必须针对需求规格说明书中建议的分辨率进行专门的测试。现在常见的分辨率是1024×768，800×600。对于需求规格说明书中规定的分辨率，测试必须保证测试通过，但对于其他分辨率，原则上也应该尽量保证，但由于这个在需求规格说明书中没有加以约束，所以在一定程度上，开发往往会拒绝进行调整。对于需求规格说明书中没有规定分辨率的项目，测试应该在完成主流分辨率的兼容性测试的前提下，尽可能进行一些非主流分辨率的兼容性测试，在一定程度上保证大部分。
8.Web测试-sql注入：
因为要对网站安全性进行测试，所以，学习了一些sql注入的知识。
在网上看一些sql注入的东东，于是想到了对网站的输入框进行一些测试，本来是想在输入框中输入<script>alter("abc")<script>,但是输入框有字符限制，只好输入<script>,结果网站出大问题了，呵呵，终于又出现了个bug。
下面把今天看到的有关SQL注入方面的知识整理如下：
SQL注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，然后将该字符串传递到SQL Server的实例以进行分析和执行。任何构成SQL语句的过程都应进行注入漏洞检查，因为SQL Server将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。
SQL注入的主要形式包括直接将代码插入到与SQL命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态SQL命令中时，将执行该恶意代码。
注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“--”来终止注入的字符串。执行时，此后的文本将被忽略。
以下脚本显示了一个简单的SQL注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个SQL查询：
var Shipcity;
ShipCity = Request.form. ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";
用户将被提示输入一个市县名称。如果用户输入Redmond，则查询将由与下面内容相似的脚本组成：
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'
但是，假定用户输入以下内容：
Redmond'; drop table OrdersTable--
此时，脚本将组成以下查询：
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'
分号(;)表示一个查询的结束和另一个查询的开始。双连字符(--)指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。SQL Server处理该语句时，SQL Server将首先选择OrdersTable中的所有记录（其中ShipCity为Redmond）。然后，SQL Server将删除OrdersTable。
只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。
验证所有输入:
始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：
如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个10 MB的MPEG文件，应用程序会做出什么反应？
如果在文本字段中嵌入了一个DROP TABLE语句，应用程序会做出什么反应？
测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。
输入字符 在Transact-SQL中的含义
; 查询分隔符。
' 字符数据字符串分隔符。
-- 注释分隔符。
/* ... */ 注释分隔符。服务器不对/*和*/之间的注释进行处理。
xp_ 用于目录扩展存储过程的名称的开头，如xp_cmdshell。
9.Web测试中书写用例时要考虑的检查点
通常书写Test Case时需要考虑的检查点.
对于屏幕显示来说包括：
检查显示的布局；
检查域和按钮的顺序；
检查域的尺寸；
检查字体的大小和风格；
检查文本的含义；
检查拼写错误；
检查屏蔽域；
检查只读域；
检查图片；
检查按钮的状态；
检查按钮的尺寸；
检查按钮的图标和名字；
检查是否有重复的图标；
检查指针是否在第一个可输入域；
检查TAB键的次序；
对于域来说包括：
检查可编辑性；
检查域间的移动；
检查分界条件；
检查有效分界符；
检查无效分界符；
检查连续多个有效分界符；
检查仅一个分界符输入；
检查多余空格的截取；
检查只读域和屏蔽域在TAB时的状态；
对于数字域来说包括：
检查正数值；
检查负数值；
检查零值；
检查小数点；
检查特殊字符加数字；
检查字母加数字；
检查ASCII值；
检查重复值；
检查空值；
对于字符域来说包括：
检查仅有字母；
检查仅有数字；
检查字母数字；
检查允许的特殊字符；
检查禁止的特殊字符；
检查包含特殊字符的字母数字；
检查ASCII值；
对于字母域来说包括：
检查字母；
检查数字值；
检查字母数字值；
检查特殊字符；
检查ASCII值；
对于时间域来说包括：
检查字符?和/；
检查其他特殊字符；
检查字母数字值；
检查正确的格式；
检查错误的格式；
检查错误的日期数字；
检查正确的日期数字；
检查日历表；
10.让web站点崩溃最常见的七大原因
磁盘已满
导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中（例如磁带）。
日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与操作系统不同的文件系统中。日志文件系统空间已满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。
C指针错误
用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引用指针（即，访问指向的内存）中出现一个错误，就会导致操作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量（analog）将访问一个空的对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但使用 Java对可靠性进行额外的度量则会对性能产生一些负面影响。
内存泄漏
C/C++程序还可能产生另一个指针问题：丢失对已分配内存的引用。当内存是在子程序中被分配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要操作系统还在运行中，则进程就会一直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。
解决方案之一是使用代码分析工具（如Purify）对代码进行仔细分析，以找出可能出现的泄漏问题。但这种方法无法找到由其他原因引起的库中的泄漏，因为库的源代码是不可用的。另一种方法是每隔一段时间，就清除并重启进程。Apache的Web服务器就会因这个原因创建和清除子进程。
虽然Java本身并无指针，但总的说来，与C程序相比， Java程序使用内存的情况更加糟糕。在Java中，对象被频繁创建，而直到所有到对象的引用都消失时，垃圾回收程序才会释放内存。即使运行了垃圾回收程序，也只会将内存还给虚拟机VM，而不是还给操作系统。结果是：Java程序会用光给它们的所有堆，从不释放。由于要保存实时（Just In Time，JIT）编译器产生的代码，Java程序的大小有时可能会膨胀为最大堆的数倍之巨。
还有一个问题，情况与此类似。从连接池分配一个数据库连接，而无法将已分配的连接还回给连接池。一些连接池有活动计时器，在维持一段时间的静止状态之后，计时器会释放掉数据库连接，但这不足以缓解糟糕的代码快速泄漏数据库连接所造成的资源浪费。
进程缺乏文件描述符
如果已为一台Web服务器或其他关键进程分配了文件描述符，但它却需要更多的文件描述符，则服务器或进程会被挂起或报错，直至得到了所需的文件描述符为止。文件描述符用来保持对开放文件和开放套接字的跟踪记录，开放文件和开放套接字是Web服务器很关键的组成部分，其任务是将文件复制到网络连接。默认时，大多数shell有64个文件描述符，这意味着每个从shell启动的进程可以同时打开64个文件和网络连接。大多数shell都有一个内嵌的 ulimit命令可以增加文件描述符的数目。
线程死锁
由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形：在人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去，这样就不难理解为何会发生死锁现象了。
解决死锁没有简单的方法，这是因为使线程产生这种问题是很具体的情况，而且往往有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易，所以 Java程序员中使用线程的人数更多，线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。
如果程序使用了永久锁，比如锁文件，而且程序结束时没有解除锁状态，则其他进程可能无法使用这种类型的锁，既不能上锁，也不能解除锁。这会进一步导致系统不能正常工作。这时必须手动地解锁。
服务器超载
Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其它的 Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。操作系统级别可能还在不断地接收新的连接，而应用程序（Web服务器）却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected（已连接）的提示消息，但这以后什么也不会发生。
解决问题的一种方法是将obj.conf参数RqThrottle的值设置为线程数目之下的某个数值，这样如果越过 RqThrottle的值，就不会接收新的连接。那些不能连接的服务器将会停止工作，而连接上的服务器的响应速度则会变慢，但至少已连接的服务器不会被挂起。这时，文件描述符至少应当被设置为与线程的数目相同的数值，否则，文件描述符将成为一个瓶颈。
数据库中的临时表不够用
许多数据库的临时表（cursor）数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。
这是一个不容易被程序员发觉的问题，但会在负载测试时显露出来。但可能对于数据库管理员（DataBase Administrator，DBA）来说，这个问题十分明显。
此外，还存在一些其他问题：设置的表空间不够用、序号限制太低，这些都会导致表溢出错误。这些问题表明了一个好的DBA对用于生产的数据库设置和性能进行定期检查的重要性。而且，大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。
另外，还有许多因素也极有可能导致Web站点无法工作。如：相关性、子网流量超载、糟糕的设备驱动程序、硬件故障、包括错误文件的通配符、无意间锁住了关键的表。