测试入门

测试入门

测试项目流程有：项目发布立项会的时候测试人员进行参与需求讨论并生成《需求文档》测试会在根据需求文档编写测试计划，然后UI会根据需求文档进行设计原型图，后台开发对数据库的设计，然后后台开发通过需求文档和原型图进行编码，同时，测试人员进行编写测试用例，开发编码结束后测试对主要功能进行冒烟测试，如果冒烟测试执行通过，根据编写好的测试用例进行执行，发现bug后进行提交bug,开发进行修改bug，上线后需要对项目进行

项目测试用例有：水杯、发红包、朋友圈、电梯等
举个例子吧，比如水杯：
功能测试：能否装水、除了装水能否装其他液体、能装多少ML的水、杯子是否有刻度表、杯子能否泡茶、咖啡、杯子材质是什么
界面测试：外观好不好看、杯子的形状是什么样的、杯子的重量是多少、杯子的图案是否合理
性能测试：能否装100度的水、能否装0度冰水、装满水放几天后是否会漏水、杯子内壁上的涂料是否容易脱落、风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏
安全性测试：制作杯子的材料，是否有毒、放微波炉里转的时候，是否会熔化、从桌子上掉到水泥地上是否会摔碎、杯子是否容易长细菌、杯子内壁上的材料，是否会溶解到水中、装进不同液体，是否会有化学反应
易用性测试：杯子是否容易烫手、杯子是否好端，好拿、杯子的水是否容易喝到、杯子是否有防滑措施、是否能接受杯子的广告内容与图案
支付的测试用例：一、在支付金额上
1、金额的最小值 ：如0.01
2、无实际支付意义的金额：如0元订单
3、支付金额错误：格式错误 、数字错误（支付金额为负数）
3、超大金额 ：设置的最高金额上限。（如微信红包单个最大值为200等）
4、余额小于实际需要支付的金额
5、银行卡或其他设置当日消费金额或者是单笔消费金额超限
二、支付接口上
关于支付会设计到很多第三方接口的相关的事件。比如：支付宝 、微信、 银系统 、手机银行、POS机的终端服务 甚至是 扫码枪 等硬件设备也是有关系的。
三、支付的操作问题上
1、指纹支付
2、免密支付
3、账 +密码支付
4、动态获取支付验证码支付
5、银行卡 +密码绑定支付
6、信用卡可能会设计到支付码等
如今的支付方式多样化、快捷支付和银行卡支付之间的差异性。信用卡和普通储蓄卡之间的差异处。等都是需要考虑的。
四、产品的容错性上（异常处理）
1、如何处理退款
2、支付时出现断
3、支付失败之后 如何补单和退单
4、支付金额不足的情况下 ，充值后 是否可以继续支付
5、持续点击 是否会出现多次扣款
6、如果发生多次扣款，如何退款到支付账
五、产品后台处理上
成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
微信发红包：功能
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.功能：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等；2.性能：速度、反应时间、关门时间等；3.压力：超载、尖锐物碰撞电梯壁等；4.安全：停电、 警装置、轿箱停靠位置、有人扒门时的情况等；5.可用性：按键高度、操作是否方便、舒适程度等；6.UI：美观程度、光滑程度、形状、质感等；7.稳定性：长时间运行情况等；8.兼容性：不同电压是否可工作、不同类型电话是否可安装等。其实在简单分析的过程中，发现许多东西根本测试不全，比如电话、灯光、材质、调度程序、可维修性等，当发现在一个用例中无法说清楚时，这些应该拆分开来分别测试。可以告诉主考官，你需要模块化地测试电话、灯光等。再有在一起的组装测试。
二、下面是详细的测试点：需求测试： 查看电梯使用说明书、安全说明书等界面测试： 查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4. 警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。 9.是否有手机信 可靠性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层 码
4.多次点击同一楼层 码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时 警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：
看电梯在最大负载下平稳运行的最长时间

朋友圈点赞：
功能测试
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、测试发现bug 开发不认为是bug的时候你怎么办p>

首先要找需求文档，看有没有对预期结果进行具体说明，从而提高说服力度。其次要确保自己的bug能够重现。
再次，分析一下自己bug的级别，如果只是建议性的bug可以保留，但是也要在bugzilla等工具上记录；
如果bug级别比较高，就要跟开发人员有效沟通，耐心讲明这个bug的危害以及重现步骤等，不行就要跟测试经理或者开发经理联系，说过bug的严重性，进行问题评估，一起讨论解决这个问题。

2、黑盒、灰盒、白盒的区别：

黑盒测试 ：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试 ：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解

灰盒测试 ：关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法

第二天主要讲了模型
瀑布模型
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架