什么是测试用例
测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
1. 编写测试方法都有哪些 等价类划分法 边界值分析法 错误推测法 因果图法 场景设计法
2. 介绍一下每种测试方法（定义）并举例说明
等价类划分法
定义：输入有效的等价类和无效的等价类的数据进行测试， 有效等价类：是指合理的、有意义的数据。 如：测试手机号码输入框 正常格式输入 无效等价类：与有效等价类的定义相反。指不合理的或无意义的数据。对于具体问题，无效等价类至少应有一个，也可以有多个。 如：测试手机号码输入框 输入错误格式 （2.5.6开头等）
边界值分析法
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类边界。 如：测试手机号码输入框 输入10.11.12位手机号其中11位是正确的10.12位为边界值
错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。 如：测试返回按钮，根据经验设计用例，测试其功能是否可用，与物理返回键点击后结果是否一致，返回的界面是否是需求要求的上个网页等等一切可能出现的错误
因果图法
是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。 如：测试自助售卖机
场景设计法
| 场景1. 成功提款 | 基本流 | |
|---|---|---|
| 场景2. ATM内没现金 | 基本流 | 备选流2 |
| 场景3. ATM内现金不足 | 基本流 | 备选流3 |
| 场景4. PIN密码有误（还有输入机会） | 基本流 | 备选流4 |
| 场景5. PIN密码有误（不再有输出机会） | 基本流 | 备选流4 |
| 场景6. 账户不存在/账户类型有误 | 基本流 | 备选流5 |
| 场景7. 账户余额不足 | 基本流 | 备选流6 |
3. 登录框的测试用例
页面展示 设置按钮 最小化按钮 关闭按钮 QQ头像 在线状态 多账号登录 账号输入框 账号输入框右击 账号输入框右击 历史记录框 密码输入框 打开软键盘 小键盘 安全登录 回车按钮 自动登录 记住密码 找回密码 注册账号 二维码 不同系统 异地登录 多设备同时登录 关联登录 互传文件 退出客户端
4. 水杯的测试用例
功能方面： 是否能盛水 性能： 能盛多少水 能盛多少度的热水和冰水 是否容易变形 是否有隔热性能 杯底设计是否稳固不易倾斜 能够叠加多少个杯子 是否能重复使用，能够使用多少次 杯子的厚度和重量是否符合需求 是否容易被风吹倒 能够存放多少时间 安全： 杯口是否光滑 是否易渗透/腐蚀 材质是否材质环保 是否易燃 长时间放置是否会漏水/破损 兼容性： 是否可以盛放固体，以及其他液体（硫酸） 易用性： 是否方便携带 是否易于老人孩子使用 杯口杯底大小是否设计合理 是否方便握持 界面： 纸面是否易晕染 界面图片是否与需求保持一致
5. 二维码的测试用例
二维码是否可以正常识别
扫码登录后信息是否正确
可以识别的极限距离
每次刷新是否会更新
二维码清晰度
二维码的时效
使用不同的设备去扫描（ipda，跨平台，跨系统，前置摄像头）
使用不同的应用去扫描产品
在最阴暗，强光下去扫描
页面尺寸、形状、颜色与UI保持一致
二维码局部扫描是否可以扫描
是否能多人同时去扫描
失效的二维码是否能被识别
是否有扫描的次数上限
是否有扫描登录要求的相关提示
扫描方向、角度
截图或者拍照的二维码是否可以正常被扫描
被转发的二维码是否可以被识别
修改二维码是否能够正常使用
OCR同时扫描多个二维码
6. 优惠券的测试用例
优惠券是否可以正常使用
外观是否与UI保持一致
部分商品是否能正常使用
购买商品的时候会不会提示使用优惠券
优惠券是否能分享
分享后能否正常使用
优惠券是否有有效期
优惠券时间的边界值
特殊事件是否会延期
使用优惠券支付期间，如果长时间未支付，优惠券是否会失效
过期的优惠卷是否可以使用（是否会自动销毁）
是否能随商品赠送
优惠券是否可以跨店铺使用
进入商家优惠券是否会自动弹出
优惠券是否可以叠加使用，最多叠加几张
不同店铺的优惠券是否可以一起使用
优惠券立即使用按钮到产品列表
优惠券最多可以叠加几张
商家满减后与优惠券一起使用
特价商品是否可以使用优惠券
优惠券即将过期是否会有相关提示
使用优惠券后是否减免相应的金额
不满足条件优惠券是否能正常使用
不同等级的用户是否使用相同的优惠券
使用优惠券购买商品后退款优惠券是否退还
使用优惠券支付失败优惠券是否还在
取消支付之后优惠券是否退还
退款中优惠券是否可以再次使用
退还的优惠券是否还可以再次使用
订单信息里边会不会显示我使用了优惠券
使用优惠券的时候断网优惠券还有没有
是否支持跨平台、跨系统、跨商家、跨应用版本使用
7. 取款机的测试用例
卡： 是否是本行卡 是否是银行卡（会员卡，超市卡） 是否是挂失卡，消磁，破损，锁卡，冻结 （借记卡，贷记卡） 本行卡是否能正常显示余额 插入银行卡不操作，是否会退卡或吞卡 密码：6位 输入正确的密码 输入错误的密码 密码长度测试 输入密码错误三次是否会锁卡 输入密码错误2次看错误是否会积累 密码为空校验 输入旧密码检验 取款： 1. ATM机余额不足 2. 取款时是否会出现假币 3. 取款时机器的执行时间 4. 取款金额是否可以低于100，取款金额为0 5. 出款金额是否正确 6. 跨行扣款手续费是否正确 7. 扣款余额不正确 8. 是否可以带小数点 9. 取款金额超出上限是否还能取款 10. 单笔取款上限最高 11. 取款金额超出卡余额 12. 取钱后不拿出来，是否会吞币 13. 取款次数是否有上限 14. 余额为0去正常取款 15. 取款金额的提示时间 打印凭条，退卡： 1. 是否可以正常打印凭条 2. 打印凭条是否有时间提示 3. 凭条里面的内容是否正确 4. 是否可以正常退卡 5. 退卡后不取卡是否会吞卡 6. 是否提示退卡成功 7. 是否会提示请取卡提示 8. 退卡是否有延迟
8. 三角形的测试用例
一、输入条件判断
三角形三边的输入条件： 1. 整数2.三个数3.正数4.非零数5.两边之和大于第三边6.两边相等7.三边相等
二、根据输出条件出现的结果
不构成三角形 条件1-5有任意一个或多个不满足
构成普通三角形 条件1-5都满足，但不满足条件6,7
构成等腰三角形 条件1-5都满足，并且满足条件6
构成等边三角形 条件1-5都满足，并且满足条件7
三、设计测试用例
有效等价类 无效等价类 整数 非正数 三个数 只有一个数或两个数 正数 有负数 非零数 有边为零 两边之和大于第三边 两边之和小于或等于第三边 两边相等 三边相等
9. 发红包的测试用例
输入200 个数增加 个数减少 数据展示 页面展示 输入框点击 字符边界值 弹框展示 页面跳转 小数点保留 按钮展示 按钮展示 输入密码框展示
选择支付方式
10. 添加购物车的测试用例
页面是否与需求UI保持一致
能否正常加入购物车
账号未登录能否添加
账号已登录能否添加
没有库存的商品是否可以加入购物车
单个商品的数量上限
购物车总商品的数量上限
购物车是否能正常删除/增加商品
收藏列表是否能正常增加
购物车列表中光标放在收藏按钮上是否展示收藏字段
数量是否可以手动修改
购物车数量是否与购物车数量保持一致
商品的跳转
添加商品入购物车是否有添加成功的提示
添加商品的有效期
购物车的全选按钮是否正常操作
勾选特价商品是否展示特价商品名称
光标放在购物车上是否展示已选商品的详细信息
同一家店的商品是否会全部结算
进入购物车是否会默认全选
点击全选金额统计是否正确
是否可以一次性全部删除商品
结算时是否会提示优惠券
购物车按钮的跳转是否正常
购物车能否展示详细信息
预售商品是否能正常加入购物车，信息是否正确
同款不同尺码商品是否分开展示
商品数量改变，金额是否正确
购物车商品价格是否根据商家定价进行金额变化
购物车是否会推荐相似产品的介绍
不同系统登录同一个账户，购物车信息是否一致
点击结算按钮是否能够正常跳转
结算失败后，购物车商品是否还展示
购物车商品是否支持分享
购物车商品列表是否根据最新商品排列
购物车按钮 页面展示 图标放在购物车上弹出购物车内容展示框 点击购物车按钮，是否可以跳转到购物车页面 购物车按钮后去购物车结算的数量是否与用户选择的商品数量一致 我的购物车 全选按钮 进入购物车是否为默认全选 点击全选是否可以实现全选或取消全选 特价商品标识 如果有选中特价商品，是否在左上角显示特价标识 1.商品的展示顺序（特价商品是否会有限展示） 2.商品展示数据与用户选择的商品是否一致 3.选择一件的价格与全选的商品总价是否有出入 4.是否可以在购物车删除商品 5.是否可以在购物车增减商品数量 6.是否可以在购物车页面将某商品收藏 7.商品前的选择框是否可以实现选中商品 8.商品单价与数量和单商品总价是否一致 9.点击购物车中某商品图片或名称是否可以跳转到该商品界面 10.特价商品是否显示特价优惠时间 11.购物车特价商品是否会因为活动到期而恢复原价 下方全选按钮 全选按钮是否可以正常实现功能 商品数量、商品金额、活动优惠是否与实际商品一致 合计金额是否与选中商品金额一致 去结算按钮 点击去结算按钮是否可以正常跳转到付款界面
11. 你们公司进行交叉测试吗？并说明一下什么是交叉测试
在上线前我们会进行交叉测试 交叉测试是指为了防止遗漏，保证产品质量，上线前进行模块互查。（一般在第三轮）
12. 项目写了多少条测试
看项目大小，大的几千条，小的七八百
13. 在项目中发现多少bug，一天能发现多少bug
一个项目100多个 一天能发现7-8个
14. 一天能写多少测试用例
50-60条 太少：我们编写测试用例是按照流程走的，一个流程一个测试用例 挺多：我们写的 比较仔细。如页面的字体，颜色，样式等都会编写用例。
15. 一天能执行多少测试用例
20-30条（开发质量）
16. 公司的人员得分配分别是怎么进行分工的（说出人员配备比例）
一般一个20人左右的项目由2-3 个人测试
17. 迭代周期是多久以及迭代的时候的时间规划
一般一周迭代一次，功能多的话，两周迭代一次
第一天：需求评审 2-3天：编写测试用例以及代码开发 4-5天：测试回归上线
18. 测试用例都包含哪些元素
用例ID 所属模块 功能/功能点 前提条件 操作步骤 预期结果 实际结果 备注 用例设计人员 测试时间
19. 你们公司采用什么编写case（测试用例）
采用Excel编写
20. 你们的依据什么编写测试用例
根据prd、产品模型等工作中所有可以接触到的文件。
21. 你们的测试用例在哪里维护（SVN或者Git）
在SVN或者git维护 SVN与GIT的区别（选择了解） 区别1：GIT是分布式的SVN不是。 这是GIT与其他非分布式的版本控制系统最核心的区别；GIT和SVN一样有自己的集中式版本库或服务器。但是，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上的chectout代码后会在自己的机器上克隆一个自己的版本库。 区别2：GIT直接记录快照，而非差异比较 GIT和其他本版本控制系统的主要差别在于，GIT只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。GIT并不保存这些前后变化的差异数据。实际上，GIT更像是把变化后的文件做快照后，记录在一个微型的文件系统中。每次提交更新时，都会浏览一遍所有文件的指纹信息并对文件做一个快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，GIT不会再次保存，而只对上次保存的快照做一个链接。 区别3：GIT中近乎所有的操作的是本地执行 在GIT中的绝大多数操作都只需要访问本地文件和资源，不用联网。但如果用SVN的话，差不多所有操作都需要连接网络。因为GIT在本地磁盘上就保存着所有当地项目的历史更新，所以处理起来速度飞快。
22. 公司分为几个环境？
三个环境： 测试环境：用来执行测试，上线前需要在测试环境中进行测试 预发布环境：把即将发布的版本放在预发布环境进行回归 生产环境（线上环境）：把预发布环境回归完毕的版本放在生产环境
23. 你们一般进行几轮测试
三轮： 第一轮：冒烟测试 第二轮：对系统进行全面性覆盖性的测试 第三轮：回归测试
24. 说测试用例的时候应该注意的点
首先先进行冒烟，将主功能流程测一遍，然后再说详细的测试点，从上到下，从左到右