搜索功能测试用例设计
搜索功能点进行分解，把测试用例分解为多个测试场景
|
场景编号 |
场景描述 |
预期结果 |
|
场景一 |
页面检查 |
正确 |
|
场景二 |
默认条件搜索 |
查询结果正确 |
|
场景三 |
修改可选条件搜索 |
查询结果正确 |
|
场景四 |
修改输入条件搜索 |
查询结果正确 |
|
场景五 |
修改区间条件搜索 |
查询结果正确 |
|
场景六 |
组合可选、输入条件搜索 |
查询结果正确 |
|
场景七 |
操作后检查搜索条件及查询结果 |
查询结果正确 |
|
场景八 |
错误、空记录搜索 |
查询结果为空 |
测试步骤描述
按照已经分解的测试场景顺序，逐个描述测试场景的测试步骤
测试场景一：
|
步骤编号 |
具体描述 |
|
1 |
进入搜索（高级搜索）页面 |
|
2 |
界面共性测试 |
|
3 |
退出 |
测试场景二：
|
步骤编号 |
具体描述 |
|
1 |
进入搜索（高级搜索）页面 |
|
2 |
点击“搜索”按钮，显示查询结果列表 |
|
3 |
检查查询结果列表，每页显示记录条数正确、文字折行显示正确、页面布局美观 |
|
4 |
检查查询结果列表，列标题项、列显示内容、排序方式符合需求定义 |
|
5 |
检查查询结果列表，符合默认查询条件结果集 |
|
6 |
点击查询结果列表链接、复选框、全选框响应正确 |
|
7 |
退出 |
测试场景三：
|
步骤编号 |
具体描述 |
|
1 |
进入搜索（高级搜索）页面 |
|
2 |
逐一选择各个查询条件可选项，如：“全部”、“类别1”等，点击“搜索”，查询结果正确 |
|
3 |
组合各个查询条件可选项，如：价格＋产品，点击“搜索”，查询结果正确 |
|
4 |
退出 |
测试场景四：
|
步骤编号 |
具体描述 |
|
1 |
进入搜索（高级搜索）页面 |
|
2 |
逐一输入文本域条件，模糊查询值，点击“搜索”，查询结果正确 |
|
3 |
逐一输入文本域条件，完全匹配值，点击“搜索”，查询结果正确 |
|
4 |
逐一输入文本域条件，中文值，点击“搜索”，查询结果正确 |
|
5 |
逐一输入文本域条件，字母大、小写值，点击“搜索”，查询结果正确 |
|
6 |
逐一输入文本域条件，数字类型值，点击“搜索”，查询结果正确 |
|
7 |
逐一输入文本域条件，全角、半角值，点击“搜索”，查询结果正确 |
|
8 |
组合各个文本域查询条件，点击“搜索”，查询结果正确 |
|
9 |
退出 |
翻页功能测试用例
翻页功能我们常碰到的一般有以下几个功能：
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，显示第一页的数据
以上的用例是将总页数，当前页数都揉进了翻页控件的测试用例中了
- 1. 输入框的测试
最近在测试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， 这样的关键字如果不被处理就直接用到数据库查询中去，后果可想而知。