51Testing软件测试论坛
标题:
请教一个测试工作中的查询模块测试用例设计的问题!
[打印本页]
作者:
丢了朵朵
时间:
2011-2-24 17:23
标题:
请教一个测试工作中的查询模块测试用例设计的问题!
[attach]71597[/attach]
针对查询条件比较多的查询模块,如何设计测试用例更好的覆盖测试呢?期待大家的解答~
作者:
丢了朵朵
时间:
2011-2-24 17:24
帖子顶起来~
作者:
wjx86916
时间:
2011-2-24 18:01
① 首先是查询条件的格式和长度做限制没有,比如比较特殊的"_"和“%”,根据这些要写一些用例,如果是做了限制的话就所有的输入框都要测试的;
② 其次就是查询用例的设计,每个条件都要单独的输入进行查询,还有就是组合查询,看能不能正确的查询出来数据(数据正确且和输入的条件符合),组合的时候由于情况比较多,就选择一些进行测试;
③ 最后最好能够通过增加、修改、删除有关的数据,然后再查询页面进行有关的测试,如果有分页的话最好能测试下分页的功能,比如点击下一页是否将查询条件带入、在最后一页输入查询条件能否正确的查询到数据灯。
暂时就想到这么多了,请大家多多指点,我也是才转入到测试,还有很多东西要向大家学习。
作者:
Jackc
时间:
2011-2-25 17:35
回复
1#
丢了朵朵
这个页面稍微复杂一些,我们分段讨论吧。
1.之前的文章相信你已经看过了
http://bbs.51testing.com/thread-375139-1-1.html
[讨论] “新增订单”的功能测试用例设计方法请教
我们先搞定公共用例部分。
统计输入测试元素:
编辑框(字符):4
编辑框(数字):3
下拉框:15
日期框:4
button:3
编辑框与数字框需使用正交表(考察点包括长度/字符类型 与 字符长度的组合),日期框用等价/边界/容错(起始日期<=终止日期)
下拉框应该没有需要特别注意的。
button在以后的输出元素中再讨论。
作者:
楠族开心果
时间:
2011-2-25 19:13
模糊查询,还有临界值什么都要判断的
作者:
丢了朵朵
时间:
2011-2-28 13:45
回复
3#
wjx86916
非常感谢wjx86916的回答~我也是按照这个测试进行的~不过对于这种查询,有没有什么测试工具进行一些自动化测试~我感觉手动测试所耗费的时间和精力很大~
作者:
丢了朵朵
时间:
2011-2-28 13:46
回复
5#
楠族开心果
楠,对于这类的查询是否有相关的测试工具?
作者:
丢了朵朵
时间:
2011-2-28 13:49
回复
4#
Jackc
非常感谢~
作者:
Jackc
时间:
2011-2-28 17:33
本帖最后由 Jackc 于 2011-2-28 17:37 编辑
回复 丢了朵朵
这个页面稍微复杂一些,我们分段讨论吧。
[讨论] ...
Jackc 发表于 2011-2-25 17:35
题外话,LZ这个是什么语言开发的? C/C++ 、java、.net这些都可以用QTP来做自动化(java/.net可能需要添加QTP插件才能完全识别)。
其实,如果这玩意是在PC上跑的,无论它是什么语言,都可以用QTP来做自动化。不识别的时候直接上位图验证就行了。少量界面的位图验证还是能忍受的。(个人认为VBs优点在于上手快,利于封装)
————————————————————————————————
接着上次的说
公共用例分类完后,需对每类用例单独设计用例。
a.文字编辑框(假设支持3种字符,并且有最大长度限制)
3种字符可以看作都具有2种状态,出现/不出现
1个最大长度限制则对应产生4~5个用例,最小/一般/次大/最大/超大 。(偷懒的时候,可以将“一般”和“次大”抛弃一个或进行整合,因为他俩是可以等价化简的)
介于LZ的测试单元较多,建议针对最大长度限制只选4个用例,同时可以将“一般”/“次大”混合使用,但是计算时他俩看作一个测试元素。
最后将上面两个测试点取正交,3水平2因素+1水平4因素的混合表。如果不会手动拼表,可以在常用表中的选L8(4x24),去掉“无效项”一列即可。
长度限制
字符类型1
字符类型2
字符类型3
无效项
1
1
1
1
1
1
2
2
2
2
2
1
1
2
2
2
2
2
1
1
3
1
2
1
2
3
2
1
2
1
4
1
2
2
1
4
2
1
1
2
PS:
大部分常用表都可通过L8(27),L16(211)...这类最基础的表转换,建议LZ抽空学习一下,这部分其实不太难。
若字符类型超过4,而又不希望增加用例数量,可以考虑对各个类型进行二次分类。
如,字符类型为:数字、英文、汉字、特殊字符、法语、日语,一共5个。参考产品面向大陆市场,可以重新定义为:汉字、数字、特殊字符、外语。也可以继续用此表,只需将法语与英语平均分配到8个用例中即可。
题外话,等价确实是最强大的测试方法,当然,缺陷泄漏很大程度也是因为它导致的......
b.若只讨论方法,我觉得剩下的几种类型公共用例也都大同小异了,就不再列举了。LZ在实际设计时遇到问题再讨论。
————————————————————————————————————————
又下班了,下次继续“公共用例的实际使用”的问题。
另,开心果提到了查询的一个难点“模糊查询”,也可以用广义等价处理,以后再说。如果LZ有所体会,也希望能拿出来大家分享:)
毕竟实际执行环境在你那边,我只能提供理论参考,实际使用还是得你自己微调和领悟。
测试中没有绝对正确的理论,只有实用的方法。
作者:
Jackc
时间:
2011-3-3 17:27
回复
9#
Jackc
1.设计好所有的公共用例后,接下来就可以将它们逐一分布到适合各自的位置。
如,来文标题可使用字符编辑框用例,批示件来源分类可使用下拉框用例等等
在涉及各个测试项相互组合时,不再建议使用正交表。如此复杂的组合条件,设计正交表将是一个痛苦的过程。推荐两种方法:
1)结对筛选,可以参考MS的一个小工具PICT
此工具可以快速根据结对理论组合出用例所需的测试数据列表。LZ可在网上先搜索结对测试和PICT的资料,若有问题再提出讨论。
2)传统方法,即国内较常使用的方法
a.先将测试元素分为两类:数据导入类(如来文标题、来源等编辑框),动作执行类(如界面底部的3个butto)
B.设计导入数据最少的用例组,即不考虑数据导入类元素之间的组合,只使用“1个数据导入元素+设计用例组。(这里与LZ实际需求环境相关,经常搜索引擎都会限制输入条件,如必填项的设置)
C.设计导入数据最复杂的用例组,即全部导入数据元素均取最复杂的值。
如字符编辑框,选择的输入数据至少包括其支持的所有字符类型。
D.筛选动作执行类,本用例中存在2个执行动作测试对象:导出、查询。
显然,与数据导入类直接相关的“查询”元素需要完成B/C所有用例
而间接相关的“导出”则只针对一部分B用例(大多选择没有数据导出的用例) 和 所有C用例。
而功能优先级最低的“取消”则可任意选择1~2个用例做简单测试即可。(建议考虑有弹出界面的用例)
——————————————————————
作者:
Jackc
时间:
2011-3-8 15:11
回复
10#
Jackc
至10L,搜索引擎输入部分的用例组设计完成。之后开始着手输出部分的设计(退出/取消功能就不再讨论了)
1.输出部分主要有两个功能“导出”/ “查询列表”
先说说查询列表
a.分析列表常规需求(即任何列表都存在的需求点)
列表中的数据量:通过等价可得:空(Null)/ 常规 / 越界(存储/内存空间不足)
根据上面的3种输出结果,用场景法反向推导其输入数据。(可直接合并到10L的用例组中,不需要再增加新的用例)
b.特殊功能点分解,如模糊查询、排序...等
模糊查询(假设查询规则为包含查询字符串中的任意字符 的 数据 均为合法)
可以根据查询关键字符在查询字符串的位置,等价到3个测试元素:字符串首 / 字符串中 / 字符串尾
每种测试元素有2个状态: 合法 / 非法 (合法即查询关键字符与数据库字符串存在对应关系)
构建正交表L4(32)
字符串首
字符串中
字符串尾
1
1
1
1
2
2
2
1
2
2
2
1
其中1为合法,2为非法
PS:全“非”字符串在a.常规分析中已有体现,故不需要额外增加
将此用例组合并到10L中的输入用例组中,建议通过调整输入用例组的测试数据实现,不再增加新的用例。
——————
列表排序(假设按字母排序)
同模糊查询,先分析出需测试元素:首字母/ 第二字母
设置元素状态: 相同 / 不同
生成预期结果用例4条,合并到10L用例组
作者:
丢了朵朵
时间:
2011-3-25 09:48
回复
9#
Jackc
jackc,这个系统是用java语言开发的,拜读您的解读,非常感谢您提供的帮助~
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2