前言
软件测试面试中，测试用例是非常容被问到的一个点，今天小编就给大家把最常见的20道测试用例方面的问题给大家整理出来，希望对大家的面试提供帮助。
之前给大家整理了一套软件测试的学习资料以及各大厂的面试题，因文章的篇幅有限，所以图上的文件我都放在公众号【IT互联网二狗子】中了，关注之后回复777即可获取了。
测试用例10道面试题
1、什么是测试用例
答：测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。
2、设计用例的好处？
答：设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点。也便于用例评审。
3、用例必备4个方面？
答：预置条件、执行步骤、预期结果、测试结果；用例要点：需包括与其他模块耦合关系、用例的级别，考虑哪些需求必须完成，哪些需求可以后续完成。
4、测试用例的设计理念？
答：首先要保证产品的质量，测试用例的数量并不能决定质量的好坏，要做到覆盖全面，提倡高质量的自动化测试。
5、测试用例有哪些设计方法？
答：等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。
6、何时开始设计测试用例？
答：需求文档定版后，即可开始陈列测试点和编写测试用例。
7、用例写完，我们要先做什么？
答：先自检，自检完毕，列出有疑惑的点，评审之前，把用例提前发给相关的开发、产品，预留时间告诉他们先看，再统一时间进行评审。
8、什么时候写测试点，什么时候写用例？
答：
如果公司只有你一个测试员，就没必要写测试用例了，写测试点，提取关键要素；
如果需求老是频繁变化，写测试点吧；你的测试用例的更新速度永远跟不上需求的变化速度，每天都在改用例。太详细的用例，无太多的意义和价值；
如果你们的节奏控制的非常紧凑，完全没时间严格按照测试用例执行，写测试点吧，提取关键要素；
如果团队的整体测试员技能均衡，测试点已经能够充分覆盖了，写测试点吧，测试用例的意义不大；
如果这块的逻辑非常复杂，你未曾接触，尽量写详细点的测试用例，通过用例的梳理过程，是一个很好的梳理理解需求和产品的过程；
如何用更少的测试点，尽可能的充分考虑各种可能性呢?跟什么因素有关呢？与用例设计方法、经验、需求理解等等有关。我们要综合运用等价类、边界值、错误推测、场景法、因果图等测试用例的设计方法；
不要总找刁钻的用例，要把客户常用的流程弄好。产品上线之前无论经过多少轮测试，一定要把主体业务流程进行回归测试。
9、测试用例的更新？
答、评审后需要更新、测试过程中需要更新、测试结束后根据线上反馈情况进行更新。
10、如何保证用例的覆盖度？
答：首先一定要熟悉需求，需求分析，拆解非常重要，需求熟悉过程中，不理解的地方，一定要找产品进行及时沟通，确定结果。其次项目开发过程中，每期的用例都要不断总结，学会总结，尽可能的保证少漏。其实这个与测试思维关系密切，工作经验的积累，以及测试思维的形成，都有助于你设计一份较完整的测试用例。
5道思维面试题
1、创建坐席组的功能模块，如何进行测试用例设计？
解答：
功能测试，使用等价类划分法去分析创建坐席的每个输入项的有效及无效类，同步考虑边界值去设计对应的测试用例：
- 先进行冒烟测试，正常创建坐席（坐席组编号自动生成且确认6位数字唯一，名称输入 10 个汉字，类型选 A，抵押坐席组复选框全选，选择第一个现场经理-名下第一个团队长-第一个坐席），点击确认
- 正常创建坐席（坐席组编号自动生成且确认 6 位数字唯一，名称输入 1 个汉字，类型选 B，抵押坐席组复选框部分勾选，选择最后一个现场经理-名下最后一个团队长-最后一个坐席），点击确认
- 坐席编号可否支持手动输入，系统统一生成 6 位后，手动修改少一位/多一位/非数字/不唯一，为空验证，系统是否提示异常
- 坐席组名称输入超过 11 个汉字/11 位包含非汉字/已存在名称/为空，系统是否提示异常
- 坐席组类型不填，系统是否提示异常
- 是否有抵押坐席组不选，可正常进行创建坐席操作
- 现场经理-团队长-坐席，三级级联功能是否正常，关注下拉框选项的完整正确性验证；坐席为空，系统是否有合理提示
UI 测试： 关于界面排版布局颜色风格等是否正常合理，是否跟原型需求一致
2、抽奖的活动页面，抽奖按钮，抽奖成功后获得奖励扣除抽奖资格怎么写用例？
解答：
Ui： 抽奖页面(转盘/跑马等)，且显示抽奖剩余次数
功能：
- 抽奖活动入口是否正确，例如通过首页 banner、推荐分享链接等
- 基本抽奖功能验证，中奖：中奖次数-1，奖品发放正常，且可进行奖品兑换
- 基本抽奖功能验证，未中奖：中奖次数-1
- 同一用户抽奖次数测试，每抽奖 1 次，次数减 1；抽奖次数为 0，不允许抽奖；退出重登/刷新页面/隔天登录都无抽奖资格
- 抽奖中奖概率，可通过 Jmeter 大并发调用抽奖接口，计算中奖概率是否正确
- 未登录/session 过期/未到抽奖时间，是否可抽奖
兼容：
不同浏览器、不同手机的兼容，查看抽奖页面操作是否正常
性能：
同一时间，大并发抽奖，服务器处理是否正常
3、给你一个微信上一个聊天的窗口你是怎么测试的？
微信聊天框的主要功能就是发消息和接收别人的消息。
消息的分类：纯文字，图片，文件，表情，语音、视频，文字 + 表情
聊天的其他功能：@符号，撤回功能，加好友功能，消息重发，发红包，转账，发送位置信息、发送名片、群聊等功能
功能测试：
正常网络下，发送纯文字，图片，文件，表情，语音、视频，文字 + 表情消息，发送及接收功能是否正常
正常网络下，测试图片，文件，语音，视频，文字的上限值测试
正常网络下，连续发消息消息统计数量功能正常
正常网络下，是否支持群发文件/群聊文件，是否支持语音转文字
正常网络下，消息发送后，在一定时间范围内是否支持撤回，超出指定时间，是否不支持撤回功能
正常网络下，发送失败后，是否支持消息重发
正常网络下，消息较多时，是否支持一键回到之前浏览位置
正常网络下，语音聊天、视频聊天相互转换功能是否正常，发送语音聊天、视频聊天时，是否有声音提示
正常网络下，发送语音聊天、视频聊天时，长时间未接听，是否有提示
正常网络下，发送名片、发送位置信息功能是否正常
正常网络下，发送红包、转账功能是否正常
正常网络下，未加好友情况下，加好友功能是否正常
正常网络下，群聊：@单个人，多个人，全部人时，对象是否会收到提醒
正常网络下，群聊：发起群视频，群语音时，所有被邀请的成员是否能加入群聊
正常网络下，群聊：群聊数量统计是否正确
网络测试： 在弱网或无网络的情况下各类功能是否正常，视频聊天、语音聊天是否有提示
中断测试： 发送消息/语音聊天/视频聊天场景中，断网重连/低电量/打电话/切换 app，处理是否正常
界面测试： 聊天消息界面，提示框等是否正常
兼容性测试： 不同手机系统，不同手机型号，分辨率屏幕尺寸下，发送消息功能是否正常
性能测试： 发送图片、文字、视频、语音等消息，对方收到的时间，是否在需求时间之内
4、举一个电商项目的模块你是怎么做的？
举例自己熟悉的，比如电商项目中的购物车，
功能：
- 分为已登录和未登录的场景；如果是未登录的话，添加购物车就提示登录页面先登录；已经登录的话，可以正常跳转至购物车；
- 进入购物车的入口验证：比如淘宝商品页点击“加入购物车”切入，或从导航栏顶部去往购物车；
- 购物车空页面验证：当购物车商品添加为 0 时，页面是否正常提示
- 购物车的商品清单验证： 一件/多件/多个商家多件商品的图片、名称、单价金额等是否正常显示，并且点击可跳转到商品详情页；
- 商品数量的增减和输入验证：测试 1/最大库存/限购数量的正常情况 ，测试 0/负数/超过库存/超过限购数量 /非数字的异常情况；
- 选择全选和部分勾选商品， 确认单件商品的小计金额、 结算里的数量和总价金额的正确性
- 购物车已添加的商品下架，是否正常显示失效
- 删除购物车商品，购物车不再显示，重新添加可正常显示
- 点击结算，可正常跳转到订单页面，并与优惠活动存在交互功能验证。
非功能：
界面： 页面的美观，没有错别字 和 页面排版等
兼容性： Web 端的能兼容主流浏览器，APP 端能兼容手机和系统版本
性能：多次访问，长时间访问 考虑稳定性等
安全：敏感信息的传输，漏洞扫描等
5、涉及到了库存方面的测试吗？
- 前台商品详情页、购物车商品存库量是否与后台管理员添加商品库存量一致
- 后台管理员对商品库存量进行增、改，前台商品详情页、购物车中库存显示是否正常
- 商品完成购买支付发货流程后，前后台库存量是否及时减少
- 商品完成购买并取消订单，查看前后台库存量变化情况
- 商品完成购买发货，并进行退货，查看前后台库存量变化情况
- 库存量与购买数量的约束测试
- 后台设置库存量报警阈值，验证低于该阈值是否有报警，及时添加存库
- 库存量为 0，查看前后台商品库存量是否正常显示
以上这些面试题都是非常容易被面试官问到的，建议保存，面试之前反复观看，最后祝愿所有的面试者都能够找到自己满意的工作。