(资料图片仅供参考)

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：切换日/周/月/年，点击右上角，正常显示心率查看帮助说明用例9：点击左上角，正常返回上一级

3、场景法用例设计

请阅读以下说明，并回答问题1、问题2、问题3和问题4软件系统几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。场景法就是通过用例场景描述业务操作流程，从用例开始到结束遍历应用流程上所有基本流(基本事件)和备选流(分支事件)。下面是对某IC卡加油机应用系统的基本流和备选流的描述。基本流A：

序号	用例名称	用例描述
1	准备加油	客户将IC加油卡插入加油机
2	验证加油卡	加油机从加油卡的磁条中读取账户代码，并检查它是否属于可以接收的加油卡
3	验证黑名单	加油机验证卡账户是否存在于黑名单中，如果属于黑名单，加油机吞卡
4	输入购油量	客户输入需要购买的汽油数量
5	加油	加油机完成加油操作，从加油卡中扣除相应金额
6	返回加油卡	退还加油卡

备选流：

序号	用例名称	用例描述
B	加油卡无效	在基本流A2过程中，该卡不能够识别或是非本机可以使用的IC 卡，加油机退卡，并退出基本流
C	卡账户属于黑名单	在基本流A3过程中，判断该卡账产属于黑名单，例如：已经挂 失，加油机吞卡退出基本流
D	加油卡账面现金不足	系统判断加油卡内现金不足，重新加入基本流A4，或选择退卡
E	加油机油量不足	系统判断加油机内油量不足，重新加入基本流A4，或选择退卡

[问题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]测试用例表

测试用例ID号	场景	账号	是否黑名单卡	输入油量	账面金额	加油机油量	预期结果
C01．	场景1；成功加油	V	I	V	V	V	成功加油
C02．	场景2：加油卡无效	I	n/a	n/a	n/a	n/a	退卡
C03．	场景3：黑名单卡	V	V	n/a	n/a	n/a	吞卡
C04．	场景4：金额不足	V	I	V	I	n/a	提示错误，重新输入加油量或退卡
C05．	场景5：油量不足	V	I	V	V	I	提示错误，重新输入油量或退卡

[问题3]0升、1升、250升、251升[问题4]计算公式DDP=Bugs(tester) / (Bugs(tester)+Bugs(customer))。因此本题DDP = （20+100）/（20+100+30）*100%= 80%

4、APP分享功能，分享包括以下信息：

1）分享场景：如对于电商类APP来说，包括首页、详情页、晒单等，待测试APP有10个分享场景2）分享文案：也就是分享后显示给用户的信息，每种分享场景都有多个不同的分享文案，分享文采用最近最少使用算法选择文案，待测试APP每种场景至少有15种分享文案3）分享渠道：APP可以通过不同的渠道分享给用户，如微信群、朋友圈、QQ群、QQ空间、微博等，待测试APP有10个分享渠道4）分享方式：分享的信息以什么方式发送给用户，如微信中可以通过文本、图文链接、海报、小程序等，待测试APP每个渠道约有5种分享方式请描述出测试以上需求测试用例设计思路，评论测试工作量，进而评估出测试完成时间点？答案参考：分享场景：10个分享场景分享文案：15种分享文案分享渠道：10个分享渠道分享方式：5种分享方式依据以上，有4种选项，每种选项下面存在多个选择，需要进行组合测试，进行全组合测试的情况太多，可以采用正交实验法来筛选测试案例，通过allpairs工具自动提炼出要测试的组合情况测试工作量要综合开发提测时间点来评估，如果只针对分享模块的用例，可以一天内时间完成用例编写，测试时间若要覆盖到比较多组合情况的测试且各种异常情况，还是人工测试的话，需要的测试时间比较长，先评估一周时间，具体完成时间节点要根据测试进度和发现的问题进行调整。

5、测试设计题目

Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。Pod就像豌豆荚，包含一个或多个容器。如下图所示：

参考答案：1、所有容器未启动，确认Pod的初始状态是否为Pending2、1个/多个/全部容器启动，确认Pod状态是否Running3、1个/多个/全部容器成功结束，确认Pod状态是否successed4、1个/多个/全部容器失败结束，确认Pod状态是否Failed5、当前Pod状态为Pending/Running/successed/Failed，Pod所在节点出现通信失败，确认Pod状态是否Unknown6、当前Pod状态为Pending/Running/successed/Failed，Pod所在节点出现通信失败，继而又恢复，确认Pod是否恢复到之前状态7、频繁操作容器启动成功结束，Pod状态是否切换正常8、频繁操作容器启动失败结束，Pod状态是否切换正常9、频繁操作节点通信失败又恢复，Pod状态是否切换正常

关键词：