51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4722|回复: 3
打印 上一主题 下一主题

[讨论] 用例规约

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-8-19 11:17:23 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
那位大侠可以解释一下用例规约及用例规约的相关知识,能附上详细资料那是最好了
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2009-9-24 11:16:00 | 只看该作者
或许我问的问题太过简单,以至大家都不想回答此类简单的问题;问题出来了,总是要去解决的嘛;没人顶的话,我自己顶好了~!
用例规约:测试用例应当遵守的规则即用例规约
用例规约一词经常用于对业务测试用例的编写,这个词在很多地方都可以看到UML、系统分析等相关书籍都可以看到
下面我转载一个网上的用例规约
<项目名称>
用例规约:<用例名称>
版本 <1.0>

目录

1. 用例名称

1.1 简要说明     

2. 事件流

2.1 基本流     

2.2 备选流     

2.2.1 < 第一备选流 >

2.2.2 < 第二备选流 >

3. 特殊需求

3.1 < 第一特殊需求 >

4. 前置条件   

4.1 < 前置条件一 >

5. 后置条件   

5.1 < 后置条件一 >     

6. 扩展点

6.1 <扩展点名称>     


用例规约: <用例名称>
1.                  用例名称

[以下提供的模板用于用例规约,它包含以文本表示的用例特征。此文档可以和需求管理工具(如 Rational RequisitePro)结合使用,用来指定和标记用例特征中的需求。

[用例图可以借助可视化建模工具(如 Rational Rose)来开发。用例报告(带有所有特征)可以用 Rational SoDA 来生成。有关详细信息,请参见 Rational Unified Process 中的工具向导。]  
1.1               简要说明

[说明中应简要表述用例的作用和目的。一个段落即足以作此说明。]
2.                  事件流
2.1               基本流

[当主角有所行动时,此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。

用例应说明的是系统内发生的事件,而不是事件发生的方式和原因。如果进行了信息交换,则需指出来回传递的具体信息。例如,只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内-您最好在词汇表中定义客户信息等内容,使用例不至于陷入过多的细节。

简单的备选流可以在用例文本中提供。如果只需几句话就可说明存在备选流时将发生的事件,则可以直接在事件流一节中说明。如果备选流较为复杂,则需要用另外一节来单独说明。例如,备选流小节解释如何说明较复杂的备选流。

虽然清晰明了的叙述性文字是无可替代的,但有时一幅图要比千言短文更具说明性。只要表达得简洁明了,您就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其他图形。如果流程图有助于描述复杂的决策流程,那么一定要充分利用它!同样,对于与状态相关的行为,状态转移图通常比数页文字更能清晰地描述系统的行为。根据问题来选用妥当的表示方法,但应慎用您的读者可能不太明了的术语、符号或图形。请切记,您的目的是要阐明问题,而不是混淆问题。]
2.2               备选流
2.2.1          < 第一备选流>

[较复杂的备选流应单独说明,这已在事件流一节的基本流小节中提及。将备选流小节当作备选行为- 在许多情况下,由于主事件流中发生异常事件,这时每个备选流都可代表备选行为。这些备选流的长度可以是说明与备选行为相关的事件所需的长度。当备选流结束时,除非另外说明,主事件流的事件将重新开始。]
2.2.1.1     < 备选支流>

[如果能使表达更明确,备选流又可再分为多个支流。]
2.2.2          < 第二备选流>

[在一个用例中很可能会有多个备选流。为了使表达更清晰,应将各个备选流分开说明。使用备选流可以提高用例的可读性,并防止将用例分解为过多的层次。应切记,用例只是文本说明,其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。]
3.                  特殊需求

[特殊需求通常是非功能性需求,它为一个用例所专有,但很难或很自然的在用例的事件流文本中表述。特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性(包括可用性、可靠性、性能或支持性需求)。此外,其他需求—如操作系统及环境、兼容性需求和设计约束—也应在此节中记录。]
3.1               < 第一特殊需求>
4.                  前置条件

[用例的前置条件是执行用例之前必须存在的系统状态。]
4.1               < 前置条件一>
5.                  后置条件

[用例的后置条件是用例一执行完毕系统可能处于的一组状态。]
5.1               < 后置条件一>
6.                  扩展点

[此用例的扩展点。]
6.1               <扩展点名称>

[扩展点在事件流中所处位置的定义。]
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2009-9-24 11:16:51 | 只看该作者
说的不足或漏说之处,希望各位朋友能予以指出~谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-9-24 11:38:19 | 只看该作者
已经很清楚了
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-8 22:51 , Processed in 0.068833 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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