51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2886|回复: 2
打印 上一主题 下一主题

[讨论] 如何设计用例使其尽可能多的覆盖系统

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-6-2 21:55:49 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
就目前市面上一般的CRM或是ERP系统中,都有权限的概念。一般像新增、删除、修改等的权限有分为:全部、部门及部门以下、部门、个人等。而这些功能在分配上又是相对独立的,这使得对系统中的某一模块的测试也变的更为复杂。
我目前有接触一个模块的测试,模块类似于XP中的回收站,可进行查看、还原和删除操作。这三个操作的权限分别为全公司、部门及部门以下、部门和个人;三者间权限的分配都是相互独立的。如果要将这三个操作完全覆盖,基本属于不可能。所以不知道该如何从中挑选合适的组合来安排用例。我是按下面的方法进行考虑的:
1、首先将三个操作的权限都设为全部和个人,算作两个用例;
2、对查看、还原、删除三个操作进行排列组合,排序过程中不再考虑两者权限范围一致的情况,这样就有六种排列方式,分别如下所示
    查看>删除>还原;查看>还原>删除;还原>查看>删除;还原>删除>查看;删除>查看>还原;删除>还原>查看
3、在对这六种组合进行分析的时候,我考虑到可以将还原和删除划为一类操作,只要查看操作的权限范围高于删除和还原,就可划为一类,所以就去除了[查看>还原>删除]和[删除>还原>查看]这两个关系,用剩下的四个组合做了四人用例,正好这三个操作的权限范围也是四个级别,就保证在这四个关系中,每个操作的权限范围出现且仅出现一次
我之前也没有什么写用例的经验,不知道这样的考虑会不会有什么不全面或是重复的地方,希望大家讨论,也多多的给出意见。先谢了!

[ 本帖最后由 sxyu 于 2008-6-3 09:26 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2008-6-3 13:28:48 | 只看该作者
有没有谁,给指点一下啊?
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-8-20 19:42:33 | 只看该作者
不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

随着中国软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之,并有向第三方专业测试公司发展的趋势。

要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。

既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-16 04:50 , Processed in 0.072050 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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