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