2水倒在规定的量度
3水倒满流出来
4水杯的容量刻度和其他水杯是否一致
5水杯能承受的最高温度和最低温度
6杯盖拧紧之后水会不会倒出来
性能：1能使用最长的时间
2掉在地上不会损坏
3盖子拧紧水不会倒出来
4保温时间长
5杯子的耐热性
6杯子的耐寒性
7长时间放置水不会漏
8杯子的承重力
安全：1杯子使用的材质的毒或者细菌验证
2高温时释放毒性
3低温时释放毒性
4高温时烫手
易用性：1杯盖是否容易打开拧紧
2倒水是否会漏
3喝水是否会漏
4清洗
界面：1内部完整
2外部完整
3大小设计一样（高、宽、容量、直径、厚度）
4材质设计一样
功能：1红包钱数和红包个数的输入框中只能输入数字
2红包最多和最少可以发多少红包
3当红包钱数超过最大范围是否会提示
4当发送的红包个数超过最大范围是否有提示
5当余额不足时是否会有提示
6输入红包钱数是不是只能输入数字
7红包描述里最多能有多少个字符
8发送的红包别人是否可以领取
9自己发的红包自己能否领取
1024小时未领取的红包是否可以退回自己原来的账户
11超过24小时的红包能否领取
12用户能否多次领取同一个红包
13余额不足时是否自动匹配支付方式
14支付时可以密码支付也可以指纹支付
15输入钱数为0，‘塞钱进红包’是否呈灰色
安全：1对方微信号异地登录时是否会有提醒
2红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3发送红包失败，余额和yhk里的钱数不会少
4红包发送成功，是否会收到微信支付的通知
弱网：1弱网时抢红包，发红包时间
2不同网速时抢红包，发红包的时间
3发红包和收红包成功后的跳转时间
4收发红包的耗电量
5退款到账的时间
易用性：可以指纹支付和密码支付或刷脸支付
ui页面：1发红包界面没有错别字
2抢完红包界面没有错别字
3发红包和收红包界面排版合理，
4发红包和收到红包界面颜色搭配合理
功能：1点赞成功
2点赞后取消
3没网的情况下点赞
4点赞后共同好友可以看到
5点赞后评论
6点赞后的显示
7同一个朋友圈两个好友同时点赞
8点赞自己的朋友圈
9点赞后显示行头像的显示
10点赞显示行的排列
11点赞人数限制
12点赞刚删除的朋友圈
性能：点赞之后好友消息的更新速度
安全：点赞是否会泄露用户隐私
弱网：1弱网的时候点赞会怎样
2网络断开能否点赞
3多人给我点赞时我能否全部接收到提示消息
易用性： *** 作简单
ui页面：界面简洁美观
功能：1点击视频时正常播放，再次点击暂停播放
2视频播放时切换到后台后暂停播放，再次进去应该是暂停状态
3视频播放结束后不保留观看进度，再次进入应该从头播放
4视频最大化、最小化
弱网：1弱网情况下，视频播放是否会卡顿、黑屏、闪退
2没有网络的情况下进入是否有提示
3移动网络进入时是否有非WIFI提示
4播放过程中断网时，播放完已加载的部分后停止播放并且有相应的提示
5播放过程中切换网络有提示
易用性：1图像是否清楚
2拖拽滚动条是否流利
3播放进度是否有记录
4能否自动保存浏览过的视频
ui页面：界面流畅
功能：1是否可以夹食物
2材质是否是不锈钢或木筷
3除了夹食物还能干什么
性能：1是否可以在高温环境下使用
2是否可以在低温环境下使用
3能否放置在微波炉中
4筷子外部涂料是否容易脱落
5长时间放置是否会发霉
安全：1咬坏后是否对人体有害
2涂料是否会溶解到食物里
3是否会滋生病菌
4是否光滑，会不会割到手或者嘴巴
易用性：1一头粗一头细，能一眼看出来哪头是夹东西的
2是否好拿
3是否有绝热措施
4能否摔坏
5能否咬坏
6夹食物是否方便
外观：1形状是否好看
2颜色是否不掉色
3长度是否一样
4是否有异味
5图案或文字是否合理
1界面是否符合设计
2提现输入框中最多能提现金额
3能否输入其他符号
4提现失败资金能否退回
5能否不输入金额直接点击提交
6无网络是能否提交
7弱网时提交能否成功，如果不成功是否能退回账户
8提现金额超过余额是否有提示
9提现成功是否有提示
10提现到账时间有延迟
11提交时连续点击多次重复提交
12用户未登录能否提交
13yhk信息有误能否提交
1运行中按开门键不开门
2电梯按键按下时是否点亮，按错楼层是否可以取消
3上升下降过程中每一层申请是否有效，是否可以正常停靠
4超载时是否有提示
5反应时间、关门时间、速度是否会造成人体不适
6进入电梯喊话外面是否可以听到
7拨打手机是否有信号
8停电是否会坠落、报警装置、通风状态
9长时间运行情况按照 *** 作步骤来写，是否有第三方登陆（如QQ,微信）？以淘宝为例，用户可以通过“我的淘宝”、“购物车”等进行账户登录，这里以通过“我的淘宝”进行简单示例：
用例1 ：点击“我的淘宝”，输入“账户”和“密码”，点击“登录”
用例2 ：点击“我的淘宝”，点击“支付宝账户登录“，输入“账户”和“密码”，点击“登录”
个人觉得测试用例是要根据产品设计开发文档来做的，要充分考虑到用户可以从哪些地方可以登录APP，然后来编写。编写完以后，可以用TestBird的云手机来自助功能测试和自动回归测试。
测试用例可以以Word或者Excel的方式呈现，主要用到的工具有禅道、testlink等等
用例编号：唯一标识用例的序号。一般是数字或者模块字母+数字组合。如：L001，L表示登录，001表示用例序号
所属模块：所测功能模块的名称，如：登录模块
用例名称：就是这个用例是什么意思。如：输入账号
前置条件：前置条件可以保障后面的测试步骤正常进行，可以理解为执行当前用例的前提条件。比如：只有注册过的用户才能登录
测试输入：用例执行期间输入的外部信息。根据用例的种类不同，测试输入也有所不同。包括数据、、手工 *** 作、文件、数据库记录等类型
测试步骤：详细完整的把你测试的过程描述出来
预期结果：对当前用例的输出做一个预期值。预期结果是根据软件需求所得出的，相当于一个衡量标准。在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
实际结果：实际测出来的结果（可能会和预期结果不符）
另外，有些公司可能会要求在用例后面添加优先级、用例人员姓名、测试日期、用例修改日期、测试结果（Pass、Fail、Block）等等，这个得根据公司的会实际情况来看
设置金额为50000，可以设置成功。设置金额为50001，不可以设置成功。（如果允许以001元为单位，则测试5000001元）
设置金额为49999（或4999999），可以设置成功（如果50000设置可以成功，这一条可以不测）
没有更多的需求的话，这几条可以了。
用例（Use Case）是一种描述系统需求的方法。运用用例这种方法来描述系统需求称之为用例建模。用例也是UML规范中的一种标准化的需求表达方式，其中比较有名的RUP（Rational Unified Process）就是以用例来驱动的。
值得一提的是，虽然RUP被认为是一种重量级的软件管理过程，而越来越多的软件开发开始采用敏捷方法来响应瞬息万变的需求变化。但是用例作为一种描述需求的方式，其理念和方法论对我们分析需求还是有一定的帮助。
从表达方式上看，用例相对时序图、流程图等需求表达方式，更加面向对象和面向设计。通常情况下，用例比较容易让没有受过专业培训的人员接受。用例可以作为一种跟用户或者行外人员陈述需求的方式。
用例是一种描述需求的方法，用例描述了在不同的条件下，系统对参与者的请求做出的响应。用例通常通过一个参与者（Actor）（ 谁？ ）向系统做出请求，系统根据参与者的请求（ 要做什么？ ），在不同的条件下，执行某一行为序列（ 系统怎么满足？ ）。每一个行为序列可以称之为一个场景（Scenario），一个用例包含多个场景。场景也可以称之为用例的一个实例（Instance）。
正式的用例应该包括：用例名、概述、范围、级别、主参与者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等等。
各个组成部分的意义如下：
用例可以用于不同的目的，如：
不同的编写目的导致了用例在编写过程中有可能出现不同的侧重点。
在不同的团队情况也可能导致用例书写的不一样。比如在一个大型的开发项目组里，就需要严格的按照用例范例进行描述，而在一个小型的沟通频繁的项目组里，则可以采用一种比较简单的描述方式。
上文提到的是比较常见的组成部分。事实上，用例的格式并没有硬性规定，在必要时可以增减里面的信息。具体用例需要包括哪些信息，有不同的流派。有兴趣可以查看相关资料，这里不展开讲。
一句话概括： 你的用例不是我的用例，只有适合的用例才是最好的 。
本文主要观点均来自于《编写有效用例》（Writing Effective Use Cases ）作者是 Alistair Cockburn。有兴趣的可以读一下原著。
用例用于表述需求，但是有两点要注意的：
用例名用于标识一个用例，便于汇总和阅读。
规则：使用主动语态的动宾短语来描述。
一般情况下，建议使用主动语态的动宾短语来描述用例的目标。如： “查找商品” 、 “加入购物车” 。在某些情况下，如需要更准确的表示出一个用例，可以加入定语进行修饰，如： “用户清除购物车” 、 “管理员清除购物车” 。
规则：以主参与者为对象进行描述。
用例的描述需要以主参与者为对象进行描述，如可以使用 “支付订单” （以主参与者为对象），而不是 “收取订单费用” (以系统为对象)。
用例的范围能让我们对系统的边界和讨论的需求有一个基础的语境，不同的设计范围可能会导致我们需要讨论的参与者、场景都会不一样。简单来讲，就是为我们讨论的系统划定一个范围确定我们讨论的界线。
例如我们要讨论一个用户的下单行为。如果以整个企业为范围，其项目的相关人员为用户、第三方服务者（如快递等）。但如果以系统为范围，其项目相关人员还应该包括企业内部的系统管理员、客服等。
所以，在编写用例时需要搞清楚，我们的用例的范围是什么，这样可以对用例讨论的问题达成一个共识。
在讨论用例的设计范围时，需要先确定系统的功能范围。Cockburn在《编写有效用例》里面推荐了一个确定功能范围的方式 “内/外列表” 。
确定功能范围的好处是显而易见。如，系统外部已经有了一个打印订单的系统，如果不明确区分系统的功能范围，部分开发人员有可能会对打印订单功能进行设计和实现。而事实上，这些功能是不需要设计的。
明确了功能范围后，还可以确认系统的执行人员。如上面的例子，打印订单系统将作为 “打印订单” 用例的辅助执行者。
设计范围是在功能范围确定了之后做的。设计范围指的是我们在编写用例时讨论问题的边界和对象。我们在用例里面说的范围（Scope）如果没有特殊说明指的就是设计范围（而不是功能范围）。
下面来看一个例子，ECom公司打算做一个ESys的系统，系统里面包括了ESubSys等多个子系统。
如果以ECom为设计范围来讨论用例，我们关心的是用户对公司的需求是什么，公司以什么样的形式满足用户的请求。如果有外部公司，则还要考虑外部公司与公司之间往来的业务是什么。
如果以ESys为设计范围来讨论用例，我们更关心用户向系统发起的请求和系统对请求的响应。同时，如果以ESys做范围的时候，企业内部的员工也成了用例的执行者，我们还应该考虑员工对系统的请求。
确定用例范围，能很好的对其我们要讨论的问题是什么，界定我们讨论问题的范围，给用例一个语言环境。
规则：设计范围是一个简单的专有名称。
用例的范围应该是一个简单的专用名词，简单说明一下用例讨论的范围界线。如，上面的例子中范围可以直接用 “ECom” 、 “ESys” 、 “ESubSys” 来表示。
主执行者是系统相关人员中，请求系统做出响应的人或物。主执行者是对系统请求的发起者，可是 主执行者可以不是直接 *** 作系统的相关人员 。
其中一种情况下是主执行者通过另一个系统 *** 作相关人员对系统进行 *** 作。如，客户致电客服查询异常订单的场景。客户并没有直接通过系统进行查询。
另一种情况是定时触发任务。如客户希望系统定时执行一个任务，那么最终执行系统的相关人员是系统本身。
虽然识别出主执行者很重要，可是在有些时候 主执行者也没那么重要 。
在编写用例时，识别出主执行者，可以从执行者角度出发，充分梳理系统需求。我们还可以主执行者的特点来设计系统的交互。如下表，主执行者概括表：
在多数情况下，我们开始编写用例开始后，主执行者就变得没那么重要了。例如，当我们在设计查询订单用例时，无论是管理员、经理、客服甚至是其他的公司职位，在查询订单这个用例上并没有特别的差异。这个时候，主执行者具体是谁已经不重要了。
规则：用例的主执行者可以是执行者或者执行者角色。
在上述情况下，我们会将部分主执行者一般化的方式，创建一个 “角色-执行者对应表” 。在上述用例里，我们将管理员、经理等一般化为一个 *** 作角色——订单管理者。我们在描写用例时，以角色作为主执行者即可。
概述主要用于描述用例的目标，也就是用户需要完成的目标。
规则：使用自然语言描述。
尽量使用自然的语言阐述用户要完成目标时，用户会做什么事情。
规则：描述用例实现什么，而不描述系统步骤。
只需要讲清楚用例需要完成的事情即可，这里不需要描述系统步骤或者用户的具体 *** 作流程。
如： “用户选择一件需要购买的商品后，可以将商品加入购物车，然后在购物车里面提交订单。用户也可以不需要加入购物车，直接购买选中的商品。” 概述并不需要描述具体的系统 *** 作，在这里并没有描述 “点击加入购物车按钮” 等系统的 *** 作细节。
项目的相关人员是指对系统有特定利益的参与者。相关人员不一定是人，也可以是一个外部系统、一个组织等。
所以能成为项目相关人员的有可能是：
主执行者
主执行者是发起执行用例的相关人员。
辅助执行者
辅助执行者是为被设计的系统执行服务的的外部执行人员。辅助执行者可以是另外一个系统、也可以是一个人或组织。如，一台打印机，为系统打印各种票据。再如，快递公司，为系统提供快递服务，并提供物流信息。
内部执行者
内部执行者是在系统内部关注系统利益的相关人员。
被设计的系统
被设计的系统本身有时候对自己也是有特定利益的。
对于相关人员，有几点需要说明：
规则：相关人员和利益用以对应列表的方式书写。
使用" <相关人员>：<利益> "的方式，描写相关人员和其关注的利益。
在编写用例过程中，我们有时会具体描述一个用户的需求（如用户购买商品），有时候会描述一个系统的具体功能（如用户登陆），有时候会描述一个流程（如购买商品并获得商品的流程）。在编写用例的时候，知道用例所处的位置，对我们编写和理解用例有很大的帮助。
我们将用例级别从总到分划分成了三个层次：概要、用户目标、子功能。
用户目标是指主执行者使用系统期望获得的目标。用户目标是我们编写用例的重点。用户目标描述了主执行者通过系统 “做一件什么事” ，以及做完这件事后 “用户能获取什么利益” 。
用户目标应该是主执行者一次执行系统获取利益的过程。所以，不是一次执行所能完成的目标，或者用户不能获得利益的需求不能称为用户目标。
如，购买一个商品的流程，这个从下订单到快递需要几天的过程，所以不能称为一个用户目标。再如，用户登陆，用户登陆并不能获取什么利益，所以也不能称为一个用户目标。用户下单这个 *** 作，可以作为一个用户目标。
概要层次可以包含多个用户目标，概要目标执行周期比用户目标更长，可以是一个几天、几个月甚至更长的过程。概要目标有三个目的：
子功能层次是用户目标在执行过程中会执行到的目标。如，一次登陆，一次订单打印等。也有可能存在多个用户目标共用一个子功能，如查找商品、查找订单等。
子功能用例的存在是为了用户目标用例增加可读性而存在的。在实际编写过程中， 不到迫不得已，不要设计子功能层出用例 。
规则：层次只有三个选项：概要、用户目标、子功能。
用例的层次只能是概要、用户目标、子功能三个之中的一个层次。
前置条件是我们在用例执行之前期望必须成功的条件。在用例编写过程中，可以不对该条件进行检查和讨论。如， “下订单” 必须依赖于 “用户已经登陆” 这个前置条件。
规则：前置条件必须是用例执行前我们期望一定成功的条件。
要预防将那些并不是必须条件的条件写入前置条件。如，取消订单并不依赖于用户下单成功，事实上，用户可以将下单不成功（例如支付失败）的订单取消掉。而订单下单是否成功这个条件是需要在用例里面对这个条件进行检查并执行不通过动作的。
最小保证是用例执行无论是否成功都会被执行的保证。虽然，用例无论执行成功与否，最小保证总会被执行。但是，最小保证更多的是为用例执行失败情况下，为用例相关人员提供的利益保证。最小保证可以有多个。
一个常见的最小保证例子是 “系统将用户执行记录日志” ，就算用例执行失败，用户的 *** 作也将会被记录到日志里面。
成功保证是指用例执行成功后，用户所能得到的利益保证。相关人员的利益能否得到保证，是用例执行成功的判定条件。成功保证可以有多个。
例如，在下订单用例中，用户下单成功后，必须保证 “订单被创建，并提交到后台处理。”
触发事件是指用例启动的事件，用例将通过触发事件，开始一步一步执行。
规则：触发事件是跟系统交互的第一个 *** 作。
以用户下单用例为例子，用户决定要购买商品后，在系统中查找商品并下单。那么 “用户决定要购买商品” 并不能作为用例的触发事件，事实上，用户更系统的交互是从 “查找商品” 开始的，所以 “用户查找商品” 才是用例的触发事件。
我们讨论用户跟系统交互时，还应该注意我们讨论的系统的范围。特别是当主执行者不是直接 *** 作软件系统的场景时，更应该明确系统范围。如， “用户致电客户经理下单” 这样的场景下，我们的系统范围并不能限定在软件系统范围内，这是系统范围是公司。所以， “用户致电客户经理” 跟我们系统交互的第一步，所以可以成为 “触发事件” 。
主成功场景是用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合。
主成功场景应该包括以下信息：
执行步骤应该有一些简单的规则：
规则：使用简单语法。
使用简单语法结构：
例如：
规则：准确描述执行者之间的切换。
执行步骤需要准确描述步骤执行过程中，执行者之间的切换。如， “用户致电客户代表” ，我们可以知道步骤已经从用户切换到了客户代表。
但是，有时候在执行者明确的情况下，也有可能不会出现在句子中。如， “用户输入密码” ，我们也可以知道这个步骤的执行者已经从用户切换到了系统。我们不必使用 “用户向系统输入密码” 这种冗余的描述方式。
规则：从系统外去描述步骤。
不应该从系统内部，或者全部以系统角度去考虑而已。而应该从系统外去描述步骤。
如果从系统内部去描述步骤，可能会写成：
如果在系统外部去描述步骤，则表述成：
规则：显示过程向前推移。
一些小的步骤只能完成少数工作，有时候这些工作并不能很好的描述过程在向前推移。如， “用户点击了确定按钮” 。这个步骤并不能很好的描述过程在向前推移，用户的真实目的是登陆系统，随着用户登陆系统，用例步骤可以继续往下执行。
规则：显示执行者的意图，而不是动作。
执行者通常是通过 *** 作系统执行一个动作的，在描写用例时，容易将用户动作和执行者的意图搞混。
例如：
1 系统要求用户输入身份信息
2 用户输入用户名密码
3 用户点击确定按钮
4 系统确认用户身份信息
……
用例过多描述了系统 *** 作界面和用户的动作，如 “要求用户输入身份信息” ，这个并执行者的意图，而只是一个交互动作。
我们可以缩减描述用户动作的步骤，将用例改成：
规则：包含合理的活动集。
描述步骤的时候，并不一定要求每个步骤之包括一个活动。根据需要可以将部分活动集合在一个步骤里面。
如:
这个步骤也可以描述成两个步骤：
用例的描述方式以简单，有效为主，有时候并不拘泥于具体的方式。事实上很多开发团队都形成了自己的用例编写规范。
规则：步骤描述成功的场景，而不要体现可能的失败。
主成功场景的步骤描述的是成功的步骤。例如:
如果这样编写步骤，我们将要继续考虑 “如果判断正确……” ， “如果判断失败……” 。但是在主成功场景的步骤中，是不体现失败的步骤的。所以，需要将步骤改成
如果如果系统验证失败怎么办？这部分信息放到扩展里面描述。下文会详细说明，这里不展开。
规则：当步骤不连续执行是，可以加入时间限制。
多数情况下，步骤是一步接一步执行的。可在某些时候，可以这样描述：
规则：一个步骤可以涉及多个相关人员。
我们有时候需要通过一个系统向另一个系统发起一个执行动作，可以写成：
规则：可以反复执行一个或多个步骤。
有时用户会反复执行其中一个或多个步骤，这时候需要在步骤中增加一定的描述。如：
扩展是主成功场景的分支，是指主成功场景在一些其他条件下会完成的不同动作。 请注意，使用“扩展”而非“异常”或“错误”，事实上扩展包括了成功和失败两种可能的条件 。其基本的逻辑是，在执行主成功场景时，如果系统……（检测到意外），那么，……（做一些事情）。
常见的有可能出现扩展的场景如下：
在这些场景出现后，我们应该在扩展中描述这些场景处理方式，然后回到主成功场景或者退出用例。
扩展是针对主成功场景的，所以我们写编写扩展的时候，需要用编号来表明扩展的对应关系：
主成功场景如下：
扩展如下：
如果是每个步骤都可能会触发的扩展，可以用”“号来表示，如：
或者如果是某些步骤触发的共有条件，可以加上步骤来表示，如：
规则：从系统检测到的角度去描述扩展条件。
扩展条件应该是系统能检测到的条件，而不是发生了什么。如，用户忘记密码了，系统不可能检测到用户是否密码或者是其他的什么原因。从系统检测到的角度去描述，系统只能检测到用户输入错误的密码或者用户输入超时。
规则：合理化合并扩展条件。
扩展条件事实上无需枚举出所有的可能出现的场景，和合理的范围内，我们可以将一些扩展条件合并成等价项。判断等价项，有两个标准：
例如，用户输入密码的步骤里面，用户可以忘记密码输入错误，也可以手误输入错误或者其他的可能性，这些条件都是系统不可以检测的条件。首先，将这些条件转换成系统可以测试的条件：密码输入错误。转换后，所有条件就可以合并成一个了。
在来看一下系统可以完成的条件，如，密码输入错误、用户名错误、用户名不存在等，我们系统的处理都是 “提示用户名或密码错误或不存在” 。这时候可以将条件合并成 “系统检测到用户名或密码输入错误” 。
还有一种情况，如果在低层级（如子功能级别）用例已经完整描述了扩展，那么在其高级别（如用户目标级别）用例，可以不用重复冗余描述。比如，在子功能级别用例 “保存数据” 里面已经完整描述了保存过程中可能出现的各种扩展条件，那么在其上级用例里就可以不用描述了。
--
用例还能以用例图的方式来表示。本文主要是通过用例的关注点和用例的组成来探讨一下一种需求的描述方式，所以就不对用例图召开介绍了。有兴趣的读者可以自行参考其他资料了解。
在敏捷开发越来越受到推崇的今天，用例这种相对较“重”的需求分析和表达模式越来越少的被人使用。当是我们通过研究用例的关注点和分析方式，其很多思想还是可以借鉴到我们日常的需求分析当中的。
通常来讲，测试工程师会从以下四个方面考虑来设计测试用例：1覆盖需求，既依据需求文档或原型来设计功能模块级测试用例；
2相关业务，既着眼于业务的相关性来设计测试用例如：订单模块与支付模块等；
3特殊角度，既从一些异常处理、极端情况等来设计用例，如苹果手机在极寒天气下的死机问题；
4补充完善，基于一些内外部经验或行业规范来设计用例，如金融行业的合规性测试用例等。
测试用例的设计思路，每一条思路的详解去黑马程序员的论坛去看！文字看不懂也有课程，自己去官网找，或者对话框问问。哥们在黑马学出来的，但是我说的这些都是免费的。都是我哥们在我当初找工作的时候推荐我看的。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）