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

开发提测之后，就照着测试用例点点点，可能一天就走完用例了，开发代码写得真好，测试用例执行完毕都没有测出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]

[问题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状态是否切换正常

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取