用例的解释

用例[yòng lì] 用例 （UML重要概念）用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。 在1986年，Ivar Jacobson，UML和瑞理统一过程的重要贡献者，提出了用例的概念。Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。 用例迅速成为获取功能需求最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。 由于不少测试工程师将测试用例简称为用例，为便于区分两者，将原来的Use case用例称为需求用例。 测试用例（对应英文Test case）已经广为人知，没有歧义，但就文字表面而言，测试用例类似是属于用例，就像红富士苹果属于苹果一样，所以为了更容易区分，需求用例是个更清晰的称呼。 用例 （汉语词汇）用例是一个汉语词汇，拼音yòng lì，意思是援用成例。

用“用例”造句 第1组

  • 1、另一个任务可能包括需求的详细说明，并附有编写用例，定义性能基准点的个人行为，等等。

  • 2、用例分析第七步：描述属性和关系。

  • 3、如果有大量配置测试用例，手动脚本以及测试日志的话，那么迁移过程可能会耗费大量的时间。

  • 4、排课管理系统是管理信息系统的一个典型用例。

  • 5、一个可组合性技术的成功SOA部署的用例、经验教训和最佳实践。

  • 6、我发现领域建模适合于数据分析用例。因为它们是以数据为中心的。

  • 7、图1是“参加研习班”用例的基本行动过程的模型。

  • 8、记事板由这些用例中的框架组成，如图12组成。

  • 9、用可分类的属性，文档和可追踪性，集成用例管理不仅提供了一系列的框图，而在很大程度上扩展了用例，有效地帮助你管理团队中的大量用例。

  • 10、因此，用例是关于以下内容的文本描述：希望系统如何工作、将涉及到哪些人以及他们之间如何交互、系统在正常运行时如何工作，以及出现错误时应该如何处理。

用“用例”造句 第2组

  • 11、例如，“招收研习班的学生”用例描述的是学生如何与系统交互来参加研习班。

  • 12、第三行EE显示测试的结果。如果测试用例通过，会得到“.”。

  • 13、业务人员将不会显示在一个为了业务用例本身所绘制的活动图里，但是他会作为业务用例实现的一部分被显示出来。

  • 14、这个用例描述审查员如何显示指示板，以及指示板显示的信息。

  • 15、测试用例通常存在于开发人员的脑子里，但实现起来有不同的方式，如打印语句、调试器表达式、测试脚本。

  • 16、在此情况下，需要记录所有测试用例步骤的时间可能不能实行。

  • 17、您可以通过使用状态表来定义测试用例。

  • 18、该问题也表现出需要一个新用例：存储狗吠声。

  • 19、在这种情况下，用例可以用来创建可测试场景，但是隐藏信息所包含的内容44与维持测试用例穿越任何设计变更的能力相冲突。

  • 20、在某些用例中，这种时间延迟是不可接受的。

用“用例”造句 第3组

  • 21、用例和用例请求上有小箭头的标识，表明它们是相连接的。

  • 22、在重新创建本文所介绍的所有测试用例时，需要20GB的磁盘空间用于存储数据和日志文件。

  • 23、在采用ODC之前，我们每个阶段的退出标准仅仅是根据测试用例的通过率来决定的。

  • 24、在此例中，你将会在你的图表中为此前建模的每个工具类创建一个用例，以后它们就代表我们系统的主要功能。

  • 25、我们继续会要求的是，下载最新的预览，在体验站点上使用例子，然后试用自己的网站。

  • 26、如果查看整个迭代，将看到更多内容：您捕获了一个重要需求并编写测试用例实现需求。

  • 27、Rhapsody是个双向的模型驱动解决方案，可以通过需求图、用例图、序列图、活动图以及状态图捕获项目需求。

  • 28、参与者焦点很重要，你可以指定系统为参与者做什么，而不必担心用例按序排列的问题。

  • 29、本文初步解决了非线性系统的分区域线性化控制律的连续性和系统的稳定性问题，简要介绍了一个应用例子。

  • 30、他定义出架构蓝图，用用例、逻辑、流程、实现和部署视图进行描述。

用“用例”造句 第4组

  • 31、没有这些技能，他们就不能足够深入地去思考开发中的产品，他们也就有可能无法识别出足够多的各类测试用例。

  • 32、您可以创建一个基于序列图、代码、流程图或者状态图的测试用例，它会自动映射到测试结构的实例上。

  • 33、传统的调试程序在执行特定用例时不能帮助您了解GUI的状态。

  • 34、这些工具是被设计用于检查已有代码块的，它将以分支、循环等为基础，综合生成一套针对代码的观测报告，开发者可以通过审查这些报告，选择为自己关心的部分生成整套的测试用例。

  • 35、为了说明会话虚包模式，我们来考虑这样一个用例，用户能将贷款支付的帐目记入她的支票帐户的借方。

  • 36、最后，我提供一个示例用例的检查清单，一旦私有云设置完成之后便可通过自助服务GUI执行它。

  • 37、例如，数据维护用例可以很好地通过领域建模来描述，还可能有用户体验建模。

  • 38、一旦定义了用例文档，就可以选择用例文本、创建case类型的需求，从而用用例细节填充需求数据库了。

  • 39、您可以创建一些直接的联系，像测试用例与需求之间的关系，以及测试用例与测试日志之间的关系。

  • 40、由于我们不能用所有可能的输入值运行用例，所以我们必须只局限于系统用户所建议的典型值。

用“用例”造句 第5组

  • 41、因此，它们通常是在单独的工件中被捕获，或者是作为用例规格的附加物。

  • 42、根据这个用例的目标，在测试用例的前置条件或者设置中还需要一些数据输入。

  • 43、至少就这个开发循环的分析阶段而言，当我们添加方案时，我们将完成这个用例。

  • 44、之后我用了简单的语法分析技术来确定用例中的候选实体，并用四个问题来考察它们。

  • 45、当使用手机时，日常的多路复用例子就发生了。

  • 46、覆盖率分析也可以帮您找到测试用例是否有冗余：测试在代码的同一路径下反复运行，导致了不必要的时间延迟。

  • 47、阐述了软件测试，特别是软件可靠性测试的概念，论述了软件运行剖面和测试用例的生成方法。

  • 48、可以通过用例，略述系统行为就可以开展软件开发，并帮你创建高质量的应用程序体系结构与设计。

  • 49、测试日志仅仅能够同一个测试用例相关联。

  • 50、例如，可以使用“参加研习班”用例作为基础来编写系统用户文档的“如何参加研习班”一节。