51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 882|回复: 2

[转贴] 做了几年设计,关于用例你了解吗?

[复制链接]
  • TA的每日心情
    无聊
    12 小时前
  • 签到天数: 919 天

    连续签到: 1 天

    [LV.10]测试总司令

    发表于 2021-11-30 13:31:13 | 显示全部楼层 |阅读模式
     用例(需求用例)概念:使用案例、用况
      以明确需求为目的,描述用户使用产品(系统)的典型情节。用例简单通俗,能让用户也能参与;强调了用户的目标和观点:谁使用系统?典型场景?目的?强调以用户为中心。
      用例是系统提供的功能块,换句话来说用例演示了人们如何使用系统。通过用例观察系统,能够将系统实现与系统目标分开,有助于了解最重要的部分(满足用户要求和期望),而不会沉浸于实现细节。
      通过用例用户可以看到系统提供的功能,先确定系统范围再深入开展项目工作。
      用例特点
      1.站在用户角度、而不是实现角度;
      2.无须披露系统特征和实现细节;
      3.一个用例只代表了系统的一个单一的目标;
      4.描述使用,而不是罗列规则。
      Jacobson(雅各布森)给出的需求用例编写10大建议
      1.用例是短文
      2.用例可以是一个情节,包含动作和交互
      3.用例可以是一组情节,描述不同情节下的行为(这种书写格式可以在任何时候描述有变体的行为,例如黑盒需求,业务流程,系统设计说明)
      4.用例里不要有系统设计
      5.用例里不要有界面设计
      6.用例里不要有特性列表
      7.用例里不要有测试
      8.用例应该描述行为需求
      9.用例的主情节不要超过九步(可以在适当的层次上得到子目标和移除设计说明)
      10.用例的最大价值不在于主情节,而是在于备选行为(主情节可能只占用例长度的四分之一到十分之一)
      用例由设计者和用户共同完成
      1.浅显易懂(用户能够理解的语言)
      2.不包含系统特征(不要扼杀设计可能性)
      3.描述理想情况(无须考虑异常情况)
      用户故事(User Story)和用例的区别
      User story定义:
      从用户或客户的角度来描述其希望得到的有价值功能,只是需求描述,而不是详细的需求规范。
      User story格式:
      英文:As a <Role>, I want to <Activity>, so that <Business Value>
      中文:作为一个<角色>,我想要<活动>,以便于<商业价值>
      1.从顺序上,我们是先有User story,然后有各个场景下的User case;
      2.从内容上,User story 关心在什么场景下完成了什么, User case 关心通过什么样的步骤如何完成了一个具体目标;
      3.从价值上,用户故事是基于用户目标根本需求的挖掘,用例则是基于系统功能范围分解成许多小的系统功能陈述。
      需求用例与测试用例的区别
      1.需求用例:面向需求,明确需求
      2.测试用例:面向实现,保证实现
      用例一般包含哪些内容

    输入垃圾、输出垃
      交互设计师最讨厌的事情,就是猜测别人原型的逻辑;
      若输入的需求是垃圾,那么输出的产品形态一定有问题。
      目前,互联网产品设计≈界面交互设计。产品在给出需求时,往往是粗略的产品原型+需求文档。这样的需求对于设计师是有害的,本质上设计师的作用就是给出多样化的解决方案,但是面对产品原型,更多时间交互或UI都在美化界面样式及细节问题。而忽略了用户任务路径,其实用户完成一项任务时,我们可以提供多种方案。
      什么是好的需求?

    来自交互设计师的 仰望
      1.用例应该是文字(使用文字描述用例即可)
      2.规则/逻辑应该是表格(例如:数据字典、权限表、规则等)
      3.抽象关系才能用图(例如:流程图一定是抽象的)
      但真实情况是:设计师往往要反推需求

    用例,对交互设计的意义
      1.UI设计基于用户任务展开;
      2.优秀的用例,本身就是一份用户任务清单;
      3.所谓优秀用例,就是颗粒度合适。
      面对需求,我们要学会拆分
      分子项目:对实体的增、删、改、查
      特殊原子项目:与规则相关的数据项目(属性/权限配置等)
      例子:
      老板一句话(故事)要抽象分解为这三部分:
      老板:我要一只鸡
      产品:我要替老板把毛拔了
      设计:我要把鸡拆解为鸡翅
      用户:最终需要的是鸡米花(拆散为颗粒)
      总结
      1.用例是站在用户角度描述需求的一种形式;
      2.产品/交互设计师,希望得到抽象输入,并不一定需要原型;
      3.要学会区分用户故事(User story)和用例(User case);
      4.用例的输出建议:分子项目+特殊的原子项目;
      5.用例最大的作用,就是让需求易于理解、便于回顾。


    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    回复

    使用道具 举报

  • TA的每日心情
    奋斗
    2019-12-31 08:59
  • 签到天数: 975 天

    连续签到: 1 天

    [LV.10]测试总司令

    发表于 2021-12-1 09:43:30 | 显示全部楼层
    了解的还不够 学习一下
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2021-12-8 16:10:03 | 显示全部楼层
    用例是个基础技能,很值得深入研究
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-3-29 21:43 , Processed in 0.067549 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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