- 1、小猪外链里发表的文章仅代表作者本人的观点,与本网站立场无关。
2、小猪外链网资源分享仅为个人学习、交流之用,同时向原著作者表达敬意。
3、小猪外链网仅提供信息存储空间服务,小猪外链网信息均来源于用户自行发布,不承担任何法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,可以按照《小猪外链网文章侵权处理流程》进行处理,同时向原著作者表达敬意。
4、内容由网友自主上传,如有侵权、违规请联系邮箱616859395@qq.com进行处理。


用例(Use case)已经成为被广泛使用的需求开发技术。围绕着用户和他们的目标,而不是产品的功能,这大大提高了开发出能真正满足客户需求的软件产品的可能性。然而,由于对用例所知甚少,造成用例的神秘感与日俱增,很多开发团队也在试图成功地运用用例技术。本文将针对已经开始应用用例技术的分析师,特别指出五处应避免的用例应用陷阱。
陷阱1:连用户都不理解的用例
用例是一种表述用户需求的方法,它描述了用户需要的产品所能完成的具体功能。用例应着重于那些用户所需借助产品系统来完成的任务,所以用例和用户的业务流程密切相关。用例应该能让用户方便阅读和检查,以寻找可能存在的问题,例如被遗漏的可替代流程,或者不正确的异常处理等。如果用户不能参与用例,将带来很多问题。或许是因为这些用例太过注重技术,而不是业务性、前瞻性的。
陷阱2:用例太多啦
分析人员正忙于建立数十或数百个用例,他们没有意识到这也许是错误的。用例数量过多通常意味着用例的抽象水平太低。每个用例都应当具备一定的抽象性,以涵盖某个共同主题的多个相关场景。这些用例的部分将成功,而其他的在某些特例条件下则不会成功。如果你正处于这样一种用例爆炸的情形,请试着提高抽象层次,将相似的用例合并成组,把它们作为一个单一的、更加抽象的用例的分支流程。
陷阱3:过于复杂的用例
用例应用的总体思路是,一个正常的用例流程所包含的步骤应该不超过12个。而事实上,曾经有用例在一个正常流程中包括近50个步骤。问题就在于,所谓“正常流程”也包含了许多可能的分支,包括错误的异常流向,以及随之而来的如何处理它们等问题。所以,事实上,正常的流程也包括了备选流程和异常情况。更好的方法是选择一个简单的、在默认情况下能够顺利走完整个用例流程的路径,这才是真正的正常流程。然后再写出其他的分支流程用例,以囊括该流程的其他分支和异常情况,特别是描述流程发生错误的那些用例情况。通过这种方法,提供一套包括多个小分支流程的用例包,相比提供给用户一个试图在单一流程描述中处理好每一种可能性的庞大用例,无疑将容易理解和管理得多。
陷阱4:描述特定用户界面元素和行为的用例
我们所需要的是撰写“必要”的用例,在一个抽象的层面来描述用户和系统的互动,而不要加入用户界面的细节。用例描述不应包括界面设计,虽然简单的用户界面原型有利于方便地检查用例。笔者甚至不喜欢听到在用例中暗指特定用户界面控制的那些术语。我们说“用户点击确定”,这意味着GUI界面使用到鼠标和按钮。但是,是不是还可以使用触摸屏或语音识别界面呢?在用例中强行加入不成熟的设计局限,可能导致产生一个糟糕的设计,除非你喜欢在已有界面的现有应用程序中不断增添新功能。
陷阱5:不再使用其他需求模型
分析人员在采用用例方法后,似乎忘记了他们所知道的需求模型和获取方法。对于交互式系统、网站等,用例对于捕获用户需求相当有帮助。然而,对于事件驱动的实时系统、数据仓库或批处理过程,用例的方法却并不适合。
我们要避免受到用例方法好处的诱惑,将用例方法强加于所有的功能需求工作。我们完全可以用一份详细的包括功能需求、非功能需求、图形分析模型、原型、数据字典和其他相关需求信息的列表来补充用例说明。在很多情况下,用例是有用的,但请将它添加到您的需求分析工具箱,而不是用它取代您当前的所有工具。
如需了解更多测试技术信息请关注:https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司
网站公告
近期本站被人为恶意注册及发布垃圾帖,每一个发帖都会经过审核,一经发现违法或垃圾帖的用户,帖子将被删除或封号,请大家共同维护互联网环境,共创美好互联网未来。
详细的发帖规则请阅读:
《小猪外链网发帖规则》
《小猪外链网最新金币规则》
注:本站严禁发布灰色违禁违法内容,如发现立刻永久封号,如开通会员的概不退款。
免责申明:本网站内容由平台入驻会员撰写,除创始人账号外,其他观点仅代表作者本人,不代表小猪外链网立场。如果内容涉及侵犯其他公司、团体的利益、请联系小猪SEO外链网客服举证删除
您的IP:18.97.14.80,2025-02-13 05:48:44,Processed in 0.31953 second(s).