应聘软件测试,差点栽在了... 这 5 道 S 级的测试用例设计题上... ...

本贴最后更新于 388 天前,其中的信息可能已经时异事殊

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

(网页端)需求描述:

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

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

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

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

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

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

图片.png


答案参考:

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

(APP端)

图片.png

需求描述:

APP心率显示页显示当前用户的心率信息(数据来源不需要考虑),具体包括:

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

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

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

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

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


答案参考:


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种分享方式

请描述出测试以上需求测试用例设计思路,评论测试工作量,进而评估出测试完成时间点?

图片.png


答案参考:

分享场景:10个分享场景

分享文案:15种分享文案

分享渠道:10个分享渠道

分享方式:5种分享方式

依据以上,有4种选项,每种选项下面存在多个选择,需要进行组合测试,进行全组合测试的情况太多,可以采用正交实验法来筛选测试案例,通过allpairs工具自动提炼出要测试的组合情况

测试工作量要综合开发提测时间点来评估,如果只针对分享模块的用例,可以一天内时间完成用例编写,测试时间若要覆盖到比较多组合情况的测试且各种异常情况,还是人工测试的话,需要的测试时间比较长,先评估一周时间,具体完成时间节点要根据测试进度和发现的问题进行调整。


5、测试设计题目

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

图片.png


参考答案:

1、所有容器未启动,确认Pod的初始状态是否为Pending

2、1个/多个/全部容器启动,确认Pod状态是否Running

3、1个/多个/全部容器成功结束,确认Pod状态是否successed

4、1个/多个/全部容器失败结束,确认Pod状态是否Failed

5、当前Pod状态为Pending/Running/successed/Failed,Pod所在节点出现通信失败,确认Pod状态是否Unknown

6、当前Pod状态为Pending/Running/successed/Failed,Pod所在节点出现通信失败,继而又恢复,确认Pod是否恢复到之前状态

7、频繁操作容器启动成功结束,Pod状态是否切换正常

8、频繁操作容器启动失败结束,Pod状态是否切换正常

9、频繁操作节点通信失败又恢复,Pod状态是否切换正常

回帖
请输入回帖内容 ...