Day_01软件测试基础
1.软件测试背景
引言：软件测试在软件生命周期中占据重要的地位，软件测试慢慢的独立发展成为一个行业，并且在迅猛发展。
1.1软件缺陷与软件故障
对于软件缺陷的精确定义，通常有下列5条描述：
1.软件未达到产品说明书的功能 《需求文档》
2.软件出现了产品说明书指明不会出现的错误
3.软件功能超出产品说明书指明范围
4.软件未达到产品说明书虽未指出但应达到的目标
5.软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好
1.2软件缺陷产生的原因
软件缺陷从哪来？第一大原因就是软件产品规格说明书，很多情况下，说明书没有写，或写的不够全面，经常更改，或者开发小组没有很好的沟通，造成对说明书理解的不一致。第二大原因是软件设计，没有做设计或设计不好，经常变动等和产品规格说明书一样的问题，第三个原因才是编写代码和其它原因；前两个原因至少占了80%以上。
通过大量的测试理论研究及测试实践经验的积累，典型的软件缺陷产生的原因被归纳为以下几种类型：
(1)需求解释有错误；
(2)用户需求定义错误；
(3)需求记录错误；
(4)设计说明有误；
(5)编码说明有误；
(6)程序代码有误；
(7)数据输入有误；
(8)测试错误；
(9)问题修改不正确；
(10)不正确的结果是由于其他的缺陷而产生。
2.软件测试基础理论
引言：软件测试是保证软件质量的一种手段，那么，什么叫软件测试？
2.1软件测试定义
狭义：测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。
广义：为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。延伸后的软件测试，被认为是一种软件测试的广义概念。
软件测试的定义：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
2.2测试环境
测试环境=硬件+软件+网络
硬件环境：pc机还是笔记本
软件环境：不同的操作系统windows10 windows8 windows7 Linux Mac，
不同浏览器firefox chrom
网络:局域网还是互联网
2.3测试流程
3.软件测试分类
3.1黑盒测试和白盒测试
黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。
“望”：观察软件的行为是否正常。
“闻”：检查输出的结果是否正确。
“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。
“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”
白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。
3.2静态测试和动态测试
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
4. 软件测试的常识知识
4.1测试部门的组织结构
5个开发（java） 1个测试 2个移动（AND IOS） 1 个前端 1个产品/项目
按需求来分类：1个组长： 制定测试计划 和 对测试用例的评审 编写测试报告和测试总结
1个功能测试： 按照测试用例进行点点的人
1个性能测试/接口测试： 满足需求文档上的性能指标
1个自动化测试 python uI自动化 接口自动化 单元自动化
Java
按项目模块划分：pc移动
具体一级菜单栏按底部导航栏
5.SQA与测试
测试工具的种类：
文档工具：word excel
Bug管理工具： 禅道jira
抓包工具： charles fiddler wineshark
[if !supportLists]a. [endif]抓包b.模拟弱网测试c.断点替换 d.过滤 e：压力测试
性能工具：jmeter Loadrunner（对业务场景测试）
命令：Linux adbMonkey
编程语言：python
自动化; selenium appnium（ui自动化） pytest (测试用例 单元测试) innerHtml （发送测试报告） alluer
数据库mysql
6.软件测试工具
软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示，使测试人员更好的找出软件错误所在。
软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。
软件测试工具存在的价值是为了提高测试效率，用软件来代替一些人工输入。
测试管理工具是为了复用测试用例，提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。
Bug管理工具： 禅道 Jary
自动化selenium appnium（ui自动化） pytest (测试用例 单元测试) innerHtml （发送测试报告）
性能测试工具jmeter Loadrunner、
抓包工具Fiddler charles (弱网测试的)
接口工具postman
录制脚本bodyboy jmeter
云测腾讯云模拟不同的移动端或者是web浏览器
命令Linux adb monkey
数据库myql
语言python
7.测试用例
①朋友圈点赞：
功能测试
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.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
9.是否有手机信号
可靠性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层号码
4.多次点击同一楼层号码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时报警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：
看电梯在最大负载下平稳运行的最长时间
③微信发红包
功能
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.可以指纹支付也可以密码支付
8.常遇问题
Ⅰ.测试发现bug 而开发不认为是bug的时候：
1.测试人员在根据需求文档或者是规格说明书/原型图来进行匹配
2.测试人员根据不同的测试环境来进行多测尝试来确认bug 并将bug的复现步骤进行记录
3.如果开发仍旧认为不是bug 需要的测试主管来进行讨论 确认是否bug
4.需要找产品经理和项目经理进行讨论是否bug
5.如果认为是bug测试人员将bug进行记录并提交测试总结中
Ⅱ.黑白灰盒子区别：
黑盒测试 ：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试 ：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法
Ⅲ.支付的测试用例：
一、在支付金额上
1、金额的最小值 ：如0.01
2、无实际支付意义的金额：如0元订单
3、支付金额错误：格式错误 、数字错误（支付金额为负数）
3、超大金额 ：设置的最高金额上限。（如微信红包单个最大值为200等）
4、余额小于实际需要支付的金额
5、银行卡或其他设置当日消费金额或者是单笔消费金额超限
二、支付接口上
关于支付会设计到很多第三方接口的相关的事件。比如：支付宝 、微信、网银系统 、手机银行、POS机的终端服务 甚至是 扫码枪 等硬件设备也是有关系的。
三、支付的操作问题上
1、指纹支付
2、免密支付
3、账号+密码支付
4、动态获取支付验证码支付
5、银行卡号+密码绑定支付
6、信用卡可能会设计到支付码等
如今的支付方式多样化、快捷支付和银行卡支付之间的差异性。信用卡和普通储蓄卡之间的差异处。等都是需要考虑的。
四、产品的容错性上（异常处理）
1、如何处理退款
2、支付时出现断网
3、支付失败之后 如何补单和退单
4、支付金额不足的情况下 ，充值后 是否可以继续支付
5、持续点击 是否会出现多次扣款
6、如果发生多次扣款，如何退款到支付账号
五、产品后台处理上
成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
9.熟悉
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。
V模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
Day_02测试计划和测试用例
1.测试用例的概念和作用
1.1引言:对一个测试工程师来说,测试用例的设计编写是一项必须掌握的能力，但有效的设计和熟练的编写测试用例却是一个十分复杂的技术，测试用例编写者不仅要掌握软件测试技术和流程，而且要对整个软件不管从业务，还是对软件的设计、程序模块的结构、功能规格说明等都要有透彻的理解。
测试的设计方法不是单独存在的，具体到每个测试项目里都有很多种方法，每种类型都有各自的特点。
1.1.1什么是测试用例？
A.80**100 有效的测试用例
B.测试用例的覆盖度 80%左右
任意的测试用例都含有用例编号（项目名字—模块名字_用例编号）
所属模块
执行条件
测试输入（具体的执行步骤）
预期结果
实际结果
用例是否通过
测试人（执行测试用例的人）
版本
备注
测试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来
（1）测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误，而精心设计的少量测试数据，包括测试输入、执行条件和预期的结果，实际结果
（2）测试用例是执行的最小实体。
（3）测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障
1.1.2测试用例的特征：
1、正确性：测试用例最好是要求输入用户实际数据已验证系统是否满足需求规格说明书的需求，并且测试用例中的测试的应保证至少覆盖需求规格说明书中的各项功能。
2、完整性：一些基本功能，如有遗漏，那是不可原谅的。
3、准确：按测试用例输入实施测试后，要能根据测试用例描述的输出得出正确的结论，不能出现模糊不清的语言。
4、清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
5、可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。
6、适应性：测试用例应该适合特定的测试环境以及符合整个团队的测试水平。
7、可重复性：要求不同测试者在同样的测试环境下使用同样测试用例都能得出相应结论。
8、可追溯性、可移植性
1.1.3测试用例的作用：
在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路
功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。