动静态测试
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
功能测试
1 是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。
2 功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。
3 逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
4 界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容...
5 易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
6 兼容性测试:硬件兼容性测试和软件兼容性测试
7 硬件兼容性:比如一款软件在pc机，笔记本上是否兼容
8 软件兼容性测试:比如一款软件在windows8和windows10上是否兼容
9 安装测试
性能测试
1 时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
2 空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗
3 一般性能测试:软件正常运行，不向其施加任何压力的测试
4 稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定成都。
5 负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
6 压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
回归测试
是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug。
简单来说就是测试找到bug提交，开发修改完成后，测试在测试一遍。
冒烟测试
指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。
随机测试
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
也就是说自己随便测试，只要自己能想到的就可以测试。
单元测试
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
总的来说，单元就是人为规定的最小的被测功能模块。
单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试。
例如：
模块接口测试
1 应对通过所测模块的数据流进行测试
2 调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
3 所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。
4 输出给标准函数的参数的个数、属性和顺序是否正确。
5 全局变量的定义在各个模块中是否一致。
6 当模块通过外部设备进行输入/输出操作，文件属性是否正确、open和close语句是否正确，规定的I/O格式说明与I/O语句是否匹配；缓冲区容量是否与记录长度匹配，在读写之前是否打开了文件，读写之后是否关闭了文件，对I/O错误是否做了处理。
驱动模块：相当于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际结果
桩模块：用以代替所测模块调用的子模块。
集成测试
集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
1 在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失
2 一个模块的功能是否会对另一个模块的功能产生不利的影响
3 各个子功能组装完成后，能否达到预期的父功能
4 全局数据结构是否有问题
5 单个模块产生的误差累计起来是否会放大
系统和验收测试
集成测试完成之后，就是系统测试和验收测试。
系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。
收测试：以用户为主的测试，软件开发人员和质量保证人员参加。
单元，集成，系统和验收测试的区别
软件测试的原则
1.应当把“尽早和不断地测试”作为开发者的座右铭。
2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
软件生命周期模型
软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1] 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
边做边改模型
许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模型
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。
瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题
优点：
1 为项目提供了按阶段划分的检查点。
2 当前一阶段完成后，只需要去关注后续阶段。
缺点：
1 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4 瀑布模型的突出缺点是不适应用户需求的变化。
原型化模型
原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。
如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。
V型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能与非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主；
2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要看模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等；
3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第一个测试阶段，是对开发出来的单独模块进行测试，以确保每一个功能模块的功能正常，可以构建桩模块和驱动模块来回调用，方法也是以白盒为主。
4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等一些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。
缺陷
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
缺陷解决思路
当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
W模型
相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
敏捷开发和测试
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
由于版本节奏比较快，开发与测试几乎并行，一个版本周期内会有两版在推动，也就是上图中提到的波次发布，波次发布用于尝试新加入的功能，做小范围快速的开发，验证和发布，为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应，敏捷测试模式适应项目需求。
模型优势：
工作任务划分清晰，工作效率较高
与开发和产品沟通紧密，团队协作性强
测试介入到整个项目的所有会议中，对整体版本信息情况把控全面
迅速占有市场，添加新的功能，吸引更多用户使用，提升用户体验度
模型的缺陷：
模块提交较快，测试时较有压迫感
项目规划要合理，不然测试时会出现复测的现象，加大工作量
软件质量模型
软件的功能性
适用性
所提供的功能是用户所需要的。
用户所需要的功能软件系统是否已提供。
准确性
软件系统提供给用户的功能是否满足用户对该功能的精确度要求。
相互操作性
软件系统和一个或多个周边系统进行信息交互的能力。
例如：
保密安全性
软件系统保护信息和数据的能力。
1、防止未得到授权的人或系统访问相关的信息或数据
2、保证得到授权的人或系统能正常访问相关的信息或数据。
3、不同的系统对于安全性的需求差别很大
测试例子
常见的安全性测试：
⑴用户验证：登录密码验证、IP地址访问限制等 sql注入 用户超时:登录超过30分钟，重新登录(安全设置，cookie过期时间30分钟)
⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。
⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。
加密、解密
在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全
Cookie 与session的区别：
1.cookie是明文传输 session的是隐藏专属
2.Cookie是存在与本机 session是存在与服务器
3.Cookie的大小是限制在4K session大小限制在5M
吸引性
美观：GUI界面、手机外观等
新颖：如夏新手机来电跳舞功能
软件测试工具
Bug管理工具： 禅道 Jary
自动化 selenium appnium （ui自动化） pytest (测试用例 单元测试) innerHtml （发送测试报告）
性能测试工具 jmeter Loadrunner、
抓包工具 Fiddler charles (弱网测试的)
接口工具 postman
录制脚本 bodyboy jmeter
云测 腾讯云 模拟不同的移动端或者是web浏览器
命令 Linux adb monkey
数据库 myql
语言 python
测试用例
支付的测试用例
1、金额的最小值 ：如0.01
2、无实际支付意义的金额：如0元订单
3、支付金额错误：格式错误 、数字错误（支付金额为负数）
3、超大金额 ：设置的最高金额上限。（如微信红包单个最大值为200等）
4、余额小于实际需要支付的金额
5、银行卡或其他设置当日消费金额或者是单笔消费金额超限
6、指纹支付
7、免密支付
8、账号+密码支付
9、动态获取支付验证码支付
10、银行卡号+密码绑定支付
11、信用卡可能会设计到支付码等
12、如何处理退款
13、支付时出现断网
14、支付失败之后 如何补单和退单
15、支付金额不足的情况下 ，充值后 是否可以继续支付
16、持续点击 是否会出现多次扣款
17、如果发生多次扣款，如何退款到支付账号
18、成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
红包支付
1.在红包钱数，和红包个数只能输入数字
2.红包里最多和最少可以限制的钱数
3.群发红包最多可以发多少个红包 超过群发红包的最大个数是否有提醒
4.红包钱数超过最大范围是否有提示
5.发送的红包个数超过最大范围时是否有提示
6.余额不足时，红包发送失败
7.在红包描述里是否可以随机输入（如：图片表情（包括混合））
8.输入红包钱数只能输入数字
9.红包描述里最大多少个字符
10.红包描述，金额，个数框里是否是否可以CV
12.红包描述里的表情是否可以删除
13.发送的红包别人/自己是否可以领取
14.一天内没有领取的红包是否可以退回到原来的账户、是否还可以领取
15.用户是否可以多次抢一个红包
16.自己发的红包自己是否可以抢
17.红包的金额里的小数位数是否有限制
18.按返回键时，是否可以取消发红包。
20.是否可以自己选择支付方式
21.余额不足时，自动匹配支付方式
22.在发红包界面能否看到以前的收发红包的记录
23.红包记录里的信息与实际收发红包记录是否匹配
24.支付时可以密码支付也可以指纹支付
25.支付成功后，退回聊天界面
26.发红包金额和收到的红包金额应该匹配
27.弱网时抢红包，发红包时间
28.不同网速时抢红包，发红包的时间
29.发红包和收红包成功后的跳转时间
30.收发红包的耗电量
31.退款到账的时间
32.苹果，安卓是否都可以发送红包
33.电脑端可以抢微信红包
34.发红包界面没有错别字
35.抢完红包界面没有错别字
36.发红包和收红包界面排版合理，
37.发红包和收到红包界面颜色搭配合理
38.对方微信号异地登录，是否会有提醒 2人
39.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
40.发送红包失败，余额和银行卡里的钱数不会少
41.红包发送成功，是否会收到微信支付的通知
42.红包描述，可以通过语音输入
