• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

软件测试之探究用例以改善测试质量

发布: 2009-3-06 09:51 | 作者: 不详 | 来源: 测试时代采编 | 查看: 41次 | 进入软件测试论坛讨论

领测软件测试网

        尽管这些用例的概念自从二十多年前就已经生成,实际上许多软件从业者从没使用过它们或者甚至从来没有了解过他们。业务转型方法论越来越普遍,这很大程度上取决于过程规则,其实正在改变这个状况。普遍的工具比如 IBM Rational RequisitePro®(用来支持 RUP) 结合用例的生成作为需求定义过程的一部分。UML 的引入为软件描述设定了标准,已经进一步促进了用例的采用。

        用例主要强调涉众需要这个系统交付什么,而不是描述如何实现最终的结果。用例采用“黑盒”接近这个系统。 2 它应该陈述将要发生什么行为,但是并不陷入关于行为如何被实现的具体细节中。将一个用例看作是来自参与者观点导向的结果。只要结果被实现,这个参与者实际上并不真正在意这个行为是怎样执行的。因此,一个用例必须代表支持对参与者有重要价值的结果。

        UML 将一个用例定义为“一个系统执行的一系列行为的描述,包括变量,它将生成特殊参与者所得值的可观测结果。” 3 当决定一个用例的构成时,这个“价值”的概念十分重要。如果您不想识别这个将由参与者识别的具体值,那么这个行为可能对一个用例来说就不是一个很好的候选。 4

        一个用例可以是图形的,也可以是文本的,但理论上两者都是用例。 5 用例可以创建为只读文本的格式,但是最初都储存在像 Microsoft Word 这样的工具中。长期以来,在用例图中以图形的格式表示就变得越来越普遍。使用 UML 和支持 RUP 的工具来构建用例模型是最为常见的方法。这样的工具支持文本描述和支持图的多样性,从而更好地图解化此系统是如何被使用的。

        用例图经常被分组来显示涉众们的需求集合(请看图 1中的例子)。在这个图中,任何一个直接与系统联系的单位通常都被看作是一个“参与者”。一个参与者可以是一个人或者代表一个或者多个人的角色。它还可以是另一个计算机系统。一个参与者通常由一个“人性图标”代表,即使当这个参与者是另一个计算机系统时也是这样。每个用例都由一个椭圆形代表,用描述这个用例将要执行什么样的行为的说明型陈述进行标注。这个陈述作为这个用例的名称。它应该简洁,但是描述的行为应该被执行。还可以绘制沟通连线来显示参与者与用例之间的关系。

         典型的用例图

           图 1:用例图


延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

22/2<12

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网