一、软件测试定义
软件测试的定义：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
二、软件测试的现状
现状：初期、不成熟、浮躁
公司越来越注重，开发与测试比例越来越接近
越来越紧缺-跳槽，待遇
毕业生、想转行
导致浮躁、但真正静下心来学习的不多
基础知识不扎实：知道基本方法但不深入理解
专业技术不够精通：写着精通某某工具，实际上只会皮毛
没有建立器相对完整的测试体系概念：对自己的工作职责理解不到位
在中国必然会经过一个不成熟的阶段，但最终会趋于平静，平稳的发展阶段。
三、软件测试的前景
四、优秀的测试人员的基本素质
1、参与需求讨论，制订测试计划，确保测试能顺利执行并完成。
2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试
3、负责测试用例的编写；编写测试报告和对测试结果分析，
4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行；
5、负责软件开发团队项目进度管理工作，
6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句； 7.熟练使用Loadrunner，Jmeter等至少一种性能测试工具
五、测试环境
测试环境=硬件+软件+网络
硬件环境：pc机还是笔记本
软件环境：不同的操作系统windows10 windows8 windows7 Linux Mac，
不同浏览器firefox chrom
网络:局域网还是互联网
六、软件测试分类
6.1、黑盒测试和白盒测试、灰盒测试
黑盒测试 ：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试 ：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
灰盒测试：是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法
6.2、静态测试和动态测试
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
6.3、功能测试和性能测试
6.31、功能测试
是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。
功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。
逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容...
易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
安装测试:
兼容性测试:硬件兼容性测试和软件兼容性测试
硬件兼容性:比如一款软件在pc机，笔记本上是否兼容
软件兼容性测试:比如一款软件在windows8和windows10上是否兼容
6.32、性能测试
时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗
一般性能测试:软件正常运行，不向其施加任何压力的测试
稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定成都。
负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
6.4、回归测试、冒烟测试、随机测试
6.41、回归测试
是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug
6.42、冒烟测试
指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。
6.43、随机测试
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
七、测试流程
项目发布立项会的时候测试人员进行参与需求讨论并生成<需求文档》测试回在根据需求文档编写
测试计划，然后uI回根据需求文档进行设计原型图，后台开发对数据库的设计,然后后台开发通过需求
文档和原型图进行编码，同时测试人员进行编写测试用例,开发编码结束后测试对主要功能进行冒烟测
试，如果冒烟测试执行通过，根据编写好的测试用例进行执行，发现bug后进行提交bug;开发进行修改
bug,开发修改后的bug进行回归测试上线后需要对项目的进行<测试总结>
八、测试发现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、如果发生多次扣款，如何退款到支付账号
五、产品后台处理上
成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
朋友圈点赞的测试用例
1 是否可以点赞成功
2 点赞成功后是否可以去取消
3 没有网络情况下是否可以点赞
4 点赞成功后是否可以评论
5 是否按照点赞顺序，按时间进行排序
6 点赞一排可以显示多少人头像
7 是否有点赞人数限制
8 是否可以多次点赞
9 点赞完成后对手机是否有影响
10 点赞是手机是否有会出现故障
11 是否可以点赞刚删除的朋友圈
12 同一个朋友圈，是否能有多人观看及点赞
13 朋友圈是否有限制不可观看
14 朋友圈是否有设置三天后不可见
15 朋友圈是否对你开放
16 好友是否将你拉黑
17 是否可以点赞1/7/30天前朋友圈
18 是否可以点赞1/半年前朋友圈
19 是否可以点赞半年前朋友圈
20 是否可以点击自己发送的朋友圈
21 是否可以点击刚加好友的朋友圈
22 朋友点赞是否有提示本人收到朋友圈被朋友点赞/评论信息
23 是否能接收朋友圈发的纯文字/表情/图片/视频/音频
性能测试
1 点赞完成后下放点赞的头像显示速度
2 网速对点赞是否有影响
3 能否及时刷新点赞人数
4 能否及时刷新评论人数
5 网速对评论是否有影响
界面测试
1 界面与ui设计的效果图是否一致
2 图片位置显示是否正确
3 下拉朋友圈是否刷新
4 是否是中文简体
5 是否有错别字
易用性测试
1 操作是否简单
2 是否适合于不同年龄段人使用
兼容性测试
1 不同操作系统是否好用
2 不同微信版本
3 不同手机型号
安全测试
1 朋友圈内容涉嫌不良信息
2 看是否为好友，不是好友不可以进行看别朋友圈
3 微信必须要登录
弱网测试
2g/3g/4g/公共网络点赞需要时间/是否可以点赞/是否可以评论
电梯的测试用例
需求测试： 查看电梯使用说明书、安全说明书等
界面测试： 查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4.报警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
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.红包描述，金额，红包个数框里是否支持复制粘贴操作
11.红包描述里的表情可以删除
12.发送的红包别人是否可以领取
12.1发的红包自己可不可以领取 2人
13. 24小时内没有领取的红包是否可以退回到原来的账户
13.1 超过24小时没有领取的红包，是否还可以领取
14.用户是否可以多次抢一个红包
15.发红包的人是否还可以抢红包 多人
16.红包的金额里的小数位数是否有限制
17.可以按返回键，取消发红包
18. 断网时，无法抢红包
29.可不可以自己选择支付方式
20.余额不足时，会不会自动匹配支付方式
22.在发红包界面能否看到以前的收发红包的记录
23.红包记录里的信息与实际收发红包记录是否匹配
24.支付时可以密码支付也可以指纹支付
25.如果直接输入小数点，那么小数点之前应该有个0
26.支付成功后，退回聊天界面
27.发红包金额和收到的红包金额应该匹配
28.是否可以连续多次发红包
性能
1.弱网时抢红包，发红包时间
2.不同网速时抢红包，发红包的时间
3.发红包和收红包成功后的跳转时间
4.收发红包的耗电量
5.退款到账的时间
兼容
1.苹果，安卓是否都可以发送红包
2.电脑端可以抢微信红包
界面
1.发红包界面没有错别字
2.抢完红包界面没有错别字
3.发红包和收红包界面排版合理，
4.发红包和收到红包界面颜色搭配合理
安全
1.对方微信号异地登录，是否会有提醒 2人
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知
易用性(有点重复)
1.红包描述，可以通过语音输入
2.可以指纹支付也可以密码支付
十、测试分类占比
十一、软件生命周期模型
软件生命周期同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰
亡等阶段，一般称为软件生命周期（软件生存周期）。软件生命周期模型是指人们为开发更好的软
件而归纳总结的软件生命周期的典型实践参考。
11.1、边做边改模型
许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
11.2、瀑布模型
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本
框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成
的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，
则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价
值。
11.3、原型化模型
原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。
