1、 用例设计:根据下面需求,进行测试用例设计,请注意对测试点的表达。
(网页端)需求描述:
某项目的营养素配置页面,供用户用来配置营养素的相关信息,其中:
- l 项目可供用户选择一种或多种营养素;
- l 点击每行尾部的“+”可以增加一行输入框,点击每行尾部的“-”会删除当前行;
- l 每种营养素都包括默认推荐量;
- l 推荐量分为单值和范围两种形式,其中,单值为单一输入框,范围则填写推荐量的推荐范围;
- l 点击确认按钮保存配置中信息。
答案参考:
用例1:配置1种营养素。营养素名称选择第1个,单位选择第1个,默认推荐量选择单值,自动显示默认推荐量;点击确认,查看营养素配置信息:正确显示
用例2:配置2种营养素。营养素名称分别选择中间1个、最后1个;营养素单位分别选择中间1个、最后1个;默认推荐量分别选择单值(输入数值-整数)、选择范围(输入小数);点击确认,查看营养素配置信息:正确显示
用例3:点击+,配置多种营养素,多种营养素有无上限;超过上限有无提示
用例4:点击+,配置多种营养素;然后点击-,正常删除当行;点击确认后,正常显示营养素配置
用例5:配置多种营养素后,点击-,减的下限验证
用例6:配置多种营养素,营养素名称重复,点击确定,给予不予重复提示
用例7:配置营养素,默认推荐量输入超出范围、非数字;点击确定,给予异常提示
用例8:配置营养素,必填信息为空,点击确定,给予不能为空提示
用例9:配置营养素,营养配比失调,是否给予提醒
Python自动化测试:手把手教你做60个实战项目,从入门到大师。
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的初始状态是否为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状态是否切换正常
最后,绵薄之力
感谢每一个认真阅读我文章的人,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!
资料获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,关注公众号:一个心态巨好的朋友 扣 ‘1’ 即可自行领取。