51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 12770|回复: 11
打印 上一主题 下一主题

[求助] 请教一个测试工作中的查询模块测试用例设计的问题!

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-2-24 17:23:31 | 只看该作者 回帖奖励 |正序浏览 |阅读模式

针对查询条件比较多的查询模块,如何设计测试用例更好的覆盖测试呢?期待大家的解答~

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏2
回复

使用道具 举报

该用户从未签到

12#
 楼主| 发表于 2011-3-25 09:48:16 | 只看该作者
回复 9# Jackc


   jackc,这个系统是用java语言开发的,拜读您的解读,非常感谢您提供的帮助~
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2011-3-8 15:11:53 | 只看该作者
回复 10# Jackc

至10L,搜索引擎输入部分的用例组设计完成。之后开始着手输出部分的设计(退出/取消功能就不再讨论了)

1.输出部分主要有两个功能“导出”/ “查询列表”

  先说说查询列表

   a.分析列表常规需求(即任何列表都存在的需求点)
      列表中的数据量:通过等价可得:空(Null)/ 常规 / 越界(存储/内存空间不足)
      根据上面的3种输出结果,用场景法反向推导其输入数据。(可直接合并到10L的用例组中,不需要再增加新的用例)

    b.特殊功能点分解,如模糊查询、排序...等
       模糊查询(假设查询规则为包含查询字符串中的任意字符 的 数据 均为合法)
       可以根据查询关键字符在查询字符串的位置,等价到3个测试元素:字符串首 / 字符串中 /  字符串尾
       每种测试元素有2个状态: 合法 / 非法 (合法即查询关键字符与数据库字符串存在对应关系)
       构建正交表L4(32)
字符串首字符串中字符串尾
111
122
212
221


       其中1为合法,2为非法
       PS:全“非”字符串在a.常规分析中已有体现,故不需要额外增加

       将此用例组合并到10L中的输入用例组中,建议通过调整输入用例组的测试数据实现,不再增加新的用例。
——————
       列表排序(假设按字母排序)
       同模糊查询,先分析出需测试元素:首字母/ 第二字母
       设置元素状态: 相同 / 不同
       生成预期结果用例4条,合并到10L用例组
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2011-3-3 17:27:05 | 只看该作者
回复 9# Jackc

1.设计好所有的公共用例后,接下来就可以将它们逐一分布到适合各自的位置。
如,来文标题可使用字符编辑框用例,批示件来源分类可使用下拉框用例等等

在涉及各个测试项相互组合时,不再建议使用正交表。如此复杂的组合条件,设计正交表将是一个痛苦的过程。推荐两种方法:
1)结对筛选,可以参考MS的一个小工具PICT
此工具可以快速根据结对理论组合出用例所需的测试数据列表。LZ可在网上先搜索结对测试和PICT的资料,若有问题再提出讨论。

2)传统方法,即国内较常使用的方法
a.先将测试元素分为两类:数据导入类(如来文标题、来源等编辑框),动作执行类(如界面底部的3个butto)
B.设计导入数据最少的用例组,即不考虑数据导入类元素之间的组合,只使用“1个数据导入元素+设计用例组。(这里与LZ实际需求环境相关,经常搜索引擎都会限制输入条件,如必填项的设置)
C.设计导入数据最复杂的用例组,即全部导入数据元素均取最复杂的值。
如字符编辑框,选择的输入数据至少包括其支持的所有字符类型。
D.筛选动作执行类,本用例中存在2个执行动作测试对象:导出、查询。
显然,与数据导入类直接相关的“查询”元素需要完成B/C所有用例
而间接相关的“导出”则只针对一部分B用例(大多选择没有数据导出的用例) 和 所有C用例。
而功能优先级最低的“取消”则可任意选择1~2个用例做简单测试即可。(建议考虑有弹出界面的用例)

——————————————————————
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2011-2-28 17:33:57 | 只看该作者
本帖最后由 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无效项
11111
12222
21122
22211
31212
32121
41221
42112


PS:
大部分常用表都可通过L8(27),L16(211)...这类最基础的表转换,建议LZ抽空学习一下,这部分其实不太难。
若字符类型超过4,而又不希望增加用例数量,可以考虑对各个类型进行二次分类。
如,字符类型为:数字、英文、汉字、特殊字符、法语、日语,一共5个。参考产品面向大陆市场,可以重新定义为:汉字、数字、特殊字符、外语。也可以继续用此表,只需将法语与英语平均分配到8个用例中即可。

题外话,等价确实是最强大的测试方法,当然,缺陷泄漏很大程度也是因为它导致的......

b.若只讨论方法,我觉得剩下的几种类型公共用例也都大同小异了,就不再列举了。LZ在实际设计时遇到问题再讨论。

————————————————————————————————————————

又下班了,下次继续“公共用例的实际使用”的问题。

另,开心果提到了查询的一个难点“模糊查询”,也可以用广义等价处理,以后再说。如果LZ有所体会,也希望能拿出来大家分享:)
毕竟实际执行环境在你那边,我只能提供理论参考,实际使用还是得你自己微调和领悟。

测试中没有绝对正确的理论,只有实用的方法。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2011-2-28 13:49:23 | 只看该作者
回复 4# Jackc
非常感谢~
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2011-2-28 13:46:32 | 只看该作者
回复 5# 楠族开心果
楠,对于这类的查询是否有相关的测试工具?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2011-2-28 13:45:49 | 只看该作者
回复 3# wjx86916
非常感谢wjx86916的回答~我也是按照这个测试进行的~不过对于这种查询,有没有什么测试工具进行一些自动化测试~我感觉手动测试所耗费的时间和精力很大~
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    6 天前
  • 签到天数: 547 天

    连续签到: 1 天

    [LV.9]测试副司令

    5#
    发表于 2011-2-25 19:13:55 | 只看该作者
    模糊查询,还有临界值什么都要判断的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2011-2-25 17:35:39 | 只看该作者
    回复 1# 丢了朵朵

    这个页面稍微复杂一些,我们分段讨论吧。

    1.之前的文章相信你已经看过了
    http://bbs.51testing.com/thread-375139-1-1.html
    [讨论] “新增订单”的功能测试用例设计方法请教

    我们先搞定公共用例部分。

    统计输入测试元素:
    编辑框(字符):4
    编辑框(数字):3
    下拉框:15
    日期框:4
    button:3

    编辑框与数字框需使用正交表(考察点包括长度/字符类型 与 字符长度的组合),日期框用等价/边界/容错(起始日期<=终止日期)
    下拉框应该没有需要特别注意的。
    button在以后的输出元素中再讨论。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2011-2-24 18:01:44 | 只看该作者
    ① 首先是查询条件的格式和长度做限制没有,比如比较特殊的"_"和“%”,根据这些要写一些用例,如果是做了限制的话就所有的输入框都要测试的;
    ② 其次就是查询用例的设计,每个条件都要单独的输入进行查询,还有就是组合查询,看能不能正确的查询出来数据(数据正确且和输入的条件符合),组合的时候由于情况比较多,就选择一些进行测试;
    ③ 最后最好能够通过增加、修改、删除有关的数据,然后再查询页面进行有关的测试,如果有分页的话最好能测试下分页的功能,比如点击下一页是否将查询条件带入、在最后一页输入查询条件能否正确的查询到数据灯。
        暂时就想到这么多了,请大家多多指点,我也是才转入到测试,还有很多东西要向大家学习。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    2#
     楼主| 发表于 2011-2-24 17:24:02 | 只看该作者
    帖子顶起来~
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-14 17:55 , Processed in 0.087648 second(s), 29 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表