社区
研发管理
帖子详情
请问有谁能讲讲功能点和用例的区别??望大家能都说两句
gaosl11
2004-05-12 09:50:04
在用功能点评估项目的时候发觉无法搞清用例和功能点的区别,是不是每个功能点都属于一个用例的?能否通过对用例的分析来找到功能点?
...全文
748
5
打赏
收藏
请问有谁能讲讲功能点和用例的区别??望大家能都说两句
在用功能点评估项目的时候发觉无法搞清用例和功能点的区别,是不是每个功能点都属于一个用例的?能否通过对用例的分析来找到功能点?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
5 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
stonespace
2004-05-12
打赏
举报
回复
2
用例和功能点是完全不同的概念,use case是actor和系统发生在系统边界上的动作序列,也就是用户使用系统的过程,而功能点是系统提供的一个功能。功能点不对应use case,因为功能点是静态的,use case是动态的动作,只能说use case使用了或者访问到某个功能点。
use case是actor对系统的操作的动作序列,所以use case必须访问功能点,可以说use case的每个动作都在访问某个功能点,这样一般use case就会访问多个功能点。
可以通过对用例的分析来找到功能点,检查use case的每个动作是否对应一个或者多个功能点,如果没有对应,则创建一个新的功能点,和这个动作对应。最后你可以得到一个use case访问功能点的交叉引用表,一个功能点通常也会被多个use case使用。
w_rose
2004-05-12
打赏
举报
回复
特别是,传统的功能方法没有突出良好的、可扩展的“结构”对系统的决定的地位,往往在结构必须改变时,流程就无法继续很好地维持了。
好的结构不仅仅是非常符号唯一(严格),而且非常自然,抽象得起到好处既不过细也而不过粗,特别是非常容易利用编程环境和运行环境已经具有的控制(组件调度)方式进行扩展。
w_rose
2004-05-12
打赏
举报
回复
传统的“功能”视角(描述方法)狭隘,层次不高,是一种“竖井式”的思维,搞出的系统仅仅能应付僵化的和单一的应用需求。
w_rose
2004-05-12
打赏
举报
回复
use case就是“系统功能”,是从系统“外部”研究系统的目标的。
如果你写一个数学计算函数,那么它的“功能”很单一,可以使用分解(包括递归)方式定义。但是,你写一个notepad.exe(记事本)程序,你能这样定义功能吗?用户根据画面,随时可能作出一个操作(对系统的刺激),这当中的重点完全不是计算类的函数,二是非常全面的基于用户交互的复杂的、集成了成千上万独立功能的系统。
因此,use case和核心是从“系统外部”去罗列这些成千上万的功能(抓住主要的几十个往往就行)。而传统的功能分解是后边才需要研究的,仅仅针对某一个功能的分解(调用层次)。
青润
2004-05-12
打赏
举报
回复
简单说,功能点就是系统的功能要求。通常来说,一个功能要求对应一个功能点。它经常用在系统规模估算方面。
对应的有一个叫用例点,也就是use case point。这是按照Use case的方式对系统进行划分所得到的估算法。
功能点和用例之间没有必然的联系,他们可以是一对一,也可以是多对多的关系。
测试
用例
颗粒度
说
明
2、颗粒度的大小还取决与客户对“产品”的要求。明确测试
用例
编写的颗粒度,大家都有这种感觉,你写测试
用例
,你测试这个产品的时候,你十条测试
用例
就测试完了,有人写三十条,你就觉得奇怪,我觉得十条已经是局限了,怎么你能写到三十条,你去看他的
用例
,发现这也能算一条,这是组织内部测试
用例
颗粒度没有达成一致。对于进行工作量的统计还可以,不过
用例
还是不能简单的以数量来看,设计一个很简单的
功能
点
的
用例
可能很容易,可能一天能设计十个这样的
用例
,但是对于一个相对复杂的
功能
,可能一天才能准备两个
用例
,光靠数量是
说
明不了问题的。
测试 -
用例
篇 - 细节狂魔
简单来
说
:这篇博客就开始教大家怎么去写一个测试案例! PS:讲解顺序不是按照上米南的顺序来的。 有的人可能觉得有
点
糊,你确定是在讲 “基于需求设计测试
用例
”嘛? 需要注意的是:上面提到这些非
功能
性的测试(易用性,兼容性,性能,安全性,可移植性,可维护性),不是所有的,都要测试! 不同的应用软件 对于 以上 非
功能
性的要求 是 不一样的!!! 比如: 1、面向客户端的软件:【画图板,office,Word,xmind】2、面向企业内部的软件 比如:飞Q,飞书(字节跳动)。。。。这种用于企业内部员
功能
测试
用例
设计方法大全
设计的测试
用例
保证至少覆盖需求规格
说
明书内容、计划任务书内容、或测试文档内容。不要没有任何文档依据,简单测测。
如何做好测试
用例
设计
1、必须有完整的需求文档2、需求已经组织评审和澄清3、必须有完整的
功能
列表1、遵循“边界值”全覆盖原则2、遵循”等价类划分场景“全覆盖原则3、遵循”测试
用例
路径唯一“原则当出现多个路径时,需要新建
用例
去覆盖。一条
用例
仅覆盖一个测试
点
。降低漏测风险。4、遵循“单条
用例
覆盖最小化”原则假如要测试一个
功能
A,它有三个子
功能
点
A1,A2 和 A3,下面两种方法来设计测试
用例
:方法1:用一个测试
用例
覆盖三个子
功能
- TestA1A2A3方法2:用三个单独的
用例
分别来覆盖三个子
功能
- TestA1,TestA2
如何写出优秀的测试
用例
?
虽然我们在分析测试
点
时,会使用各种测试方法,但这些方法在思路和操作上都是不同的,一些方法得到的测试
点
要细一些、具体一些,一些方法得到的测试
点
粗一些、泛一些是非常正常的。显然,随机测试也能发现缺陷,有时候甚至比测试
用例
更能发现产品缺陷,而且“突然一个灵感来了,然后去测试,并且真的发现了产品缺陷”的过程,会让人很有成就感。相反,如果开发需要多次修复,最后才能使得测试
用例
执行通过,
说
明版本质量可能不高,产品在设计、编码方面可能存在一些问题,即便是修复bug,在修复时引入新bug的风险也会更大一些。
研发管理
1,268
社区成员
28,284
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章