第一天 测试用例以及软件测试分类
软件测试分类
软件测试定义
黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
灰盒测试是结合了白盒测试和黑盒测试的要素，能够用于黑盒测试以增强测试效率，灰盒测试关注输出对于输入的正确性，同时也关注内部表现
白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。
静态测试：是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。
动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。
单元测试：编译运行程序——静态测试——动态测试
集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。
系统测试：指的是将整个软件系统看作1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
验收测试：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序.验收测试又分为α测试和β测试，其实α测试指的是由用户、测试人员、开发人员等共同参与的内部测试，而β测试指的是内侧后的公测，即完全交给最终用户测试。
功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。功能测试又可以细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。
性能测试：软件的性能包括很多方面，主要有时间性能和空间性能两种。
时间性能：主要指软件的一个具体事务的响应时间。
空间性能：主要指软件运行时所消耗的系统资源。
软件性能测试分为一般性能测试、稳定性测试、负载测试和压力测试。
一般性能测试指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试，也叫可靠性测试，是指连续运行内测系统，检查系统运行时的稳定程度。我们通常用MTBF（错误发生的平均时间间隔）来衡量系统的稳定性，越大稳定性越强。
负载测试是性能测试的一种，通常是指让被测系统在其能忍受的极限范围之内连续运行，来测试系统的稳定性。
压力测试是性能测试的一种，通常是指连续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
假设一个人很轻松的就能背一袋米，背两袋米很吃力，最多就能背三袋米，那么：一般性能测试：我就让他背一袋米稳定性测试：我让他背一袋米，但是让他去操场上跑圈，看多久累倒。
负载测试：我让他背两袋米去操场上跑圈，看多久累倒。
压力测试：我让他背两袋米，三袋米，四袋米......发现他最多就能背三袋米。
回归测试：是指对软件的新的版本测试时，重复执行上一个版本测试时的用例冒烟测试：是指在对一个新版本进行西戎大规模的测试之前，先验证一下软件的基本功能是否可以实现，是否具备可测性
随机测试：是指测试中所有的输入数据都是都是随机生成的，其目的是模拟用户的真是操作，并发现一些边缘的错误。
朋友圈点赞以及评论测试用例
功能测试
1 是否可以点赞成功
2 点赞成功后是否可以去取消
3 没有网络情况下是否可以点赞
4 点赞成功后是否可以评论
5 是否按照点赞顺序，按时间进行排序
6 点赞一排可以显示多少人头像
7 是否有点赞人数限制
8 是否可以多次点赞
9 点赞完成后对手机是否有影响
10 点赞是手机是否有会出现故障
11 是否可以点赞刚删除的朋友圈
12 同一个朋友圈，是否能有多人观看及点赞
13 朋友圈是否有限制不可观看
14 朋友圈是否有设置三天后不可见
15 朋友圈是否对你开放
16 好友是否将你拉黑
17 是否可以点赞1天前朋友圈
18 是否可以点赞7天前朋友圈
19 是否可以点赞30天前朋友圈
20 是否可以点赞1年前朋友圈
21 是否可以点赞半年前朋友圈
22 是否可以点击自己发送的朋友圈
23 是否可以点击刚加好友的朋友圈
24 朋友点赞是否有提示本人收到朋友圈被朋友点赞信息
25 朋友评论是否有提示本人收到朋友圈被朋友评论信息
26 是否能接收朋友圈发的纯文字
27 是否能接收受朋友圈发的表情
28 是否能接受朋友圈发的图片
29 是否能接受朋友圈发的视频
30 是否能接收朋友圈发的音频
性能测试
1 点赞完成后下放点赞的头像显示速度
2 网速对点赞是否有影响
3 能否及时刷新点赞人数
4 能否及时刷新评论人数
5 网速对评论是否有影响
界面测试
1 界面与ui设计的效果图是否一致
2 图片位置显示是否正确
3 下拉朋友圈是否刷新
4 是否是中午简体
5 是否有错别字
易用性测试
1 操作是否简单
2 是否适合于不同年龄段人使用
兼容性测试
1 不同操作系统是否好用
2 不同微信版本
3 不同手机型号
安全测试
1 朋友圈内容涉嫌不良信息
2 看是否为好友，不是好友不可以进行看别朋友圈
3 微信必须要登录
弱网测试
1 2g网络点赞需要时间/是否可以点赞/是否可以评论
2 3g网络点赞需要多长时间/是否可以点赞/是否可以评论
3 4g网络点赞时间多长时间/是否可以点赞/是否可以评论
4 5g网络点赞时间多长时间/是否可以点赞/是否可以评论
5 公共网络点赞多长时间/是否可以点赞/是否可以评论
电梯功能的测试用例和测试方案
1.功能：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等；
2.性能：速度、反应时间、关门时间等；
3.压力：超载、尖锐物碰撞电梯壁等；
4.安全：停电、报警装置、轿箱停靠位置、有人扒门时的情况等；
5.可用性：按键高度、操作是否方便、舒适程度等；
6.UI：美观程度、光滑程度、形状、质感等；
7.稳定性：长时间运行情况等；
8.兼容性：不同电压是否可工作、不同类型电话是否可安装等
微信发红包-测试用例
功能
1.在红包钱数，和红包个数的输入框中只能输入数字
2.红包里最多和最少可以输入的钱数 200 0.01
3.拼手气红包最多可以发多少个红包 100
3.1超过最大拼手气红包的个数是否有提醒
4.当红包钱数超过最大范围是不是有对应的提示
5.当发送的红包个数超过最大范围是不是有提示
6.当余额不足时，红包发送失败
7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，
7.1是否可以输入它们的混合搭配
8.输入红包钱数是不是只能输入数字
9.红包描述里许多能有多少个字符 10个
10.红包描述，金额，红包个数框里是否支持复制粘贴操作
12.红包描述里的表情可以删除
13.发送的红包别人是否可以领取
13.1发的红包自己可不可以领取 2人
14. 24小时内没有领取的红包是否可以退回到原来的账户
14.1 超过24小时没有领取的红包，是否还可以领取
15.用户是否可以多次抢一个红包
16.发红包的人是否还可以抢红包 多人
17.红包的金额里的小数位数是否有限制
18.可以按返回键，取消发红包
19. 断网时，无法抢红包
20.可不可以自己选择支付方式
21.余额不足时，会不会自动匹配支付方式
22.在发红包界面能否看到以前的收发红包的记录
23.红包记录里的信息与实际收发红包记录是否匹配
24.支付时可以密码支付也可以指纹支付
25.如果直接输入小数点，那么小数点之前应该有个0
26.支付成功后，退回聊天界面
27.发红包金额和收到的红包金额应该匹配
28.是否可以连续多次发红包
29.输入钱数为0，"塞钱进红包"置灰
性能
1.弱网时抢红包，发红包时间
2.不同网速时抢红包，发红包的时间
3.发红包和收红包成功后的跳转时间
4.收发红包的耗电量
5.退款到账的时间
兼容
1.苹果，安卓是否都可以发送红包
2.电脑端可以抢微信红包
界面
1.发红包界面没有错别字
2.抢完红包界面没有错别字
3.发红包和收红包界面排版合理，
4.发红包和收到红包界面颜色搭配合理
安全
1.对方微信号异地登录，是否会有提醒 2人
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知
易用性(有点重复)
1.红包描述，可以通过语音输入
2.可以指纹支付也可以密码支付
支付测试用例
一、在支付金额上
1、金额的最小值 ：如0.01
2、无实际支付意义的金额：如0元订单
3、支付金额错误：格式错误 、数字错误（支付金额为负数）
3、超大金额 ：设置的最高金额上限。（如微信红包单个最大值为200等）
4、余额小于实际需要支付的金额
5、银行卡或其他设置当日消费金额或者是单笔消费金额超限
二、支付接口上
关于支付会设计到很多第三方接口的相关的事件。比如：支付宝、微信、网银系统、手机银行、POS机的终端服务 甚至是 扫码枪 等硬件设备也是有关系的。
三、支付的操作问题上
1、指纹支付
2、免密支付
3、账号+密码支付
4、动态获取支付验证码支付
5、银行卡号+密码绑定支付
6、信用卡可能会设计到支付码等
如今的支付方式多样化、快捷支付和银行卡支付之间的差异性。信用卡和普通储蓄卡之间的差异处。等都是需要考虑的。
四、产品的容错性上（异常处理）
1、如何处理退款
2、支付时出现断网
3、支付失败之后 如何补单和退单
4、支付金额不足的情况下 ，充值后 是否可以继续支付
5、持续点击 是否会出现多次扣款
6、如果发生多次扣款，如何退款到支付账号
[面试题1]测试发现bug开发不认为是bug的时候你怎么办？
首先明确不是bug的理由
如果是需求变更，那就找产品经理确认是否是需求变更
1.测试人员在根据需求文档或者是规格说明书/原型图来进行匹配
2.测试人员根据不同的测试环境来进行多测尝试来确认bug 并将bug的复现步骤进行记录
3.如果开发仍旧认为不是bug 需要的测试主管来进行讨论 确认是否bug
4.需要找产品经理和项目经理进行讨论是否bug
5.如果认为是bug测试人员将bug进行记录并提交测试总结中