很多人不知道写测试用例有什么用，而仅仅是像工具人一样，在每次提测之前，把测试用例照着需求文档抄一遍，仿佛像是走个过场。

开发提测之后，就照着测试用例点点点，可能一天就走完用例了，开发代码写得真好，测试用例执行完毕都没有测出bug，然后美其名曰：测试完了，达到上线标准。

测完之后，测试用例毫无价值，像随手扔垃圾一样，随地保存，终于无迹可寻。

在他们眼里，从事测试工作，和去东莞进厂打工没什么区别。

反正测试用例写久了，都能成为人人爱戴的熟练工，想着到了35岁，光荣下岗，回老家享受荣华富贵。

最后上线之后，bug一大堆，反而还怪写测试用例浪费时间，且没有用。

1#用例设计：根据下面需求，进行测试用例设计，请注意对测试点的表达。

（网页端）需求描述：

某项目的营养素配置页面，供用户用来配置营养素的相关信息，其中：

l 项目可供用户选择一种或多种营养素；

l 点击每行尾部的“+”可以增加一行输入框，点击每行尾部的“-”会删除当前行；

l 每种营养素都包括默认推荐量；

l 推荐量分为单值和范围两种形式，其中，单值为单一输入框，范围则填写推荐量的推荐范围；

l 点击确认按钮保存配置中信息。

答案参考：

用例1：配置1种营养素。营养素名称选择第1个，单位选择第1个，默认推荐量选择单值，自动显示默认推荐量；点击确认，查看营养素配置信息:正确显示

用例2：配置2种营养素。营养素名称分别选择中间1个、最后1个；营养素单位分别选择中间1个、最后1个；默认推荐量分别选择单值(输入数值-整数)、选择范围(输入小数)；点击确认，查看营养素配置信息:正确显示

用例3：点击+，配置多种营养素，多种营养素有无上限；超过上限有无提示

用例4：点击+，配置多种营养素；然后点击-，正常删除当行；点击确认后，正常显示营养素配置

用例5：配置多种营养素后，点击-，减的下限验证

用例6：配置多种营养素，营养素名称重复，点击确定，给予不予重复提示

用例7：配置营养素，默认推荐量输入超出范围、非数字；点击确定，给予异常提示

用例8：配置营养素，必填信息为空，点击确定，给予不能为空提示

用例9：配置营养素，营养配比失调，是否给予提醒

2#用例设计：根据下面的需求，进行测试用例设计，请注意对测试点的表达。

（APP端）

需求描述：

APP心率显示页显示当前用户的心率信息（数据来源不需要考虑），具体包括：

l 心率信息按日、周、月、年形式下的心率数据，默认展示日的形式，点击周、日、年可切换到其他展示形式；

l 日的形式下，显示单日0-24时以每半小时为单位的心率数据；

l 显示各半小时的最大、最小值，以柱状图形式展示；

l 点击任意半小时的柱状图，显示该柱状图对应的时间和心率信息，并在图下方的表格中显示对应数据；

l 左右滑动可查看其它日期的相关信息。

答案参考：

用例1：当前系统时间0:10分，进入心率页面-默认日形式。查看心率数据，是否实时显示1条柱状形；若无显示，是否给予用户友好提示

用例2：当前系统时间x点，例9:10点，进入心率页面-默认日形式。心率数据是否每半小时显示1个柱状形（假设心率数据从0-x小时是完整的，显示若不完整，需对比查看系统数据库存储的心率数据）；选择第1个柱状形、中间选择1个、最后1个柱状形：时间区间是否正确、心率最小值-最大值是否正确（与查询的数据库心率数据一致）

用例3：当前系统时间23:59分，进入心率数据-日形式，查看当日心率数据，是否每半小时总共显示24条柱状形(假设心率数据从0-24小时是完整的，显示若不完整，需对比查看系统数据库存储的心率数据)；点击第1个、最后1个柱状形：时间区间是否正确、心率最小值-最大值是否正确（与查询的数据库心率数据一致）

用例4：左右滑动，查看上一日、下一日心率数据，正常显示当天心率数据，包括柱状形数量、选择第1个/最后1个单个柱状形日期、心率范围正确性（对比数据库验证一致性）

用例5：切换周形式(当前周/上一周/下一周)，查看心率柱状形数量、第1个/最后1个单一柱状形的日期、心率范围是否正确（对比数据库验证一致性）

用例6：切换月形式(当前月/上一月/下一月)，查看心率柱状形数量、第1个/最后1个单一柱状形的日期、心率范围是否正确（对比数据库验证一致性）

用例7：切换年形式(当前年/上一年/下一年)，查看心率柱状形数量、第1个/最后1个单一柱状形的日期、心率范围是否正确（对比数据库验证一致性）

用例8：切换日/周/月/年，点击右上角”i“，正常显示心率查看帮助说明

用例9：点击左上角”←“，正常返回上一级

3#场景法用例设计

请阅读以下说明，并回答问题1、问题2、问题3和问题4

软件系统几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。场景法就是通过用例场景描述业务操作流程，从用例开始到结束遍历应用流程上所有基本流(基本事件)和备选流(分支事件)。

下面是对某IC卡加油机应用系统的基本流和备选流的描述。

基本流A：

备选流：

[问题1] 使用场景法设计测试案例，指出场景涉及到的基本流和备选流，基本流用字母A表示，备选流用题干中描述的相应字母表示。

[问题2]

场景中的每一个场景都需要确定测试用例，一般采用矩阵来确定和管理测试用例。

如下表所示是一种通用格式，其中行代表各个测试用例，列代表测试用例的信息。本例中的测试用例包含测试用例、ID、场景/条件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素(本例中包括账号、是否黑名单卡、输入油量、账面金额、加油机油量)，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中，V表示有效数据元素，I表示无效数据元素，n/a表示不适用，例如C01表示“成功加油”基本流。请按上述规定为其它应用场景设计用例矩阵。

[问题3]

假如每升油4元人民币，用户的账户金额为1000元，加油机内油量足够，那么在A4输入油量的过程中，请运用边界值分析方法为A4选取合适的输入数据(即油量，单位；升)。

[问题4]

假设本系统开发人员在开发过程中通过测试发现了20个错误，独立的测试组通过上述测试用例发现了100个软件错误，系统在上线后，用户反馈了30个错误，请计算缺陷探测率(DDP)。

参考答案：

[问题1]

场景1：A

场景2: A、B

场景3: A、C

场景4: A、D

场景5: A、E

[问题2]