软件测试定义：
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试的作用：
①通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品使用信心。
②测试可以记录软件运行过程中产生的一些数据，从而决策提供数据支持。
③测试可以降低同类型产品开发遇到的风险。
软件测试生命周期：
- 需求分析
- 测试计划
- 测试用例设计与开发
- 测试执行
- 测试评估
测试原则：
①测试证明软件存在缺陷：无论执行什么样的测试操作都不能证明当前软件是有缺陷的。
②不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻列出，所以任何的测试操作都是有结束的时间。
③缺陷存在群集现象：对于软件功能说，核心功能占20%，非核心功能占80%，在实际工作中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%，因此我们就会遇到缺陷都集中20%功能模块里的现象。
④某些测试需要依赖特殊环境
⑤测试应尽早介入：为了更多的发现和更好的解决软件中缺陷，我们追求测试工作尽早展开。
⑥杀虫剂现象：同样的一个测试用例不能重复的执行多次，因为软件会对它产生免疫。
⑦不存在缺陷谬论：任何软件不可能是完美。
测试级别：
①单元测试：UT
②集中测试:IT
③系统测试:ST
④验收测试
α测试——内测
β测试——公测
UAT测试——由客户派专业团队进行测试，一般这种测试购买软件方
常见的系统测试方法：
1、按测试对象进行分类
①白盒测试：这种测试的主体就是软件的底层代码，不会在意，外在界面是否OK，只要求底层功能实现，同时逻辑正确。
②黑盒测试：这种测试就是指测试软件外在主体功能是否可用。
③灰盒测试：介于二者之间接口测试。
④上述三种方法当中的“盒”指的就是被测对象。
2、按测试对象是否执行分类
①静态测试：指的就是测试不执行。
②动态测试：将软降运行在真实的使用环境中进行测试。
按测试手段分类：
①手动测试：由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作及环境
②自动化测试：所谓自动化主要有二种形式：一种是自己写脚本，另外一种就是通过第三方的工具对被测对象进行测试，优点就是可以高效的去执行一些人工无法实现的操作。
系统测试分类：
①功能测试：验证当前的软件主体功能是否可用
②兼容测试：验证当前软件在不同的环境下是否还可以使用
③安全测试：验证软件是否是能授权用户提供功能使用
④性能测试：相对当前软件消耗的资源它的产出能力
测试对象介绍：
对于当前的测试行业来说我们最经常测试的主体就是软件（主体功能）但是需要我们明白是一个软件也不仅仅只有功能需要测试。我们可以将软件分为三个部分组成：功能结合+使用说明书+配置数
对于一款软件从无到有需要不同的过程，我们可以将这个过程分为不同阶段，然后每个阶段都会相应有测试对象：
①需求分析阶段：各种需求规格说明书；
②软件架构设计：APL接口文档（接口测试）；
③编码实现阶段：源码测试（白盒测试、单元测试）
④系统功能使用：软件功能主体（当前行业做的最多的一种测试）
软件测试流程：
1.需求分析
①当前阶段的核心目的就是梳理清楚我们需求设计的点是什么。
②需求的来源：需求规格说明书、API文档、竞价分析、个人经验
2.设计用例
①用例就是用户为了测试软件宽度某个功能而执行的操作过程。
②设计用例就是（等价类、边界值、判定表、场景法）
3.评审用例：对当前的用例进行添加或者删除
4.配置环境
①环境：指的就是当前被测对象运行所需要的执行环境，做为测试人员需要具备配置环境能力。
②环境分类：操作系统+服务器软件+数据库+软件底层代码的执行环境
5.执行用例
①一般执行用例之前我们会做一个【冒烟测试】这种测试的核心功能或主体执行流程进行验证。如果冒烟测试阶段有问题，则可以将版本回退给研发。
②如果冒烟测试通过那么才会开展全面的测试
6.回归测试及缺陷跟踪
①回归测试指的是当前我们将某个缺陷提交给开发之后，由他们进行修复，修复完毕之后需要测试人员再次对进行测试。
②缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。
7.输出测试报告：将当前的测试过程中产生的数据进行可视化的输出，方面其他人员去查看。
8.测试结束：当整个测试过程中产生的一些文档进行整理归档，方面后续版本使用。
9.软件质量的六大特性
①功能性：软件需要满足用户显示或者稳定功能；
②易用性：软件易用学习和上手使用；
③可靠性：指的就是软件必须实现需求当中指明的具体功能；
④效率性：类似软件的性能；
⑤可维护性：要求软件具有将某个功能修复之后继续使用的能力；
⑥可移植性：当前软件可以从一个平台移植到另一个平台上去使用的能力；
出现bug的地方以及找到bug的方式有：
（1）肉眼可见【界面ui】
（2）系统资源使用率 cpu 内存 网络 电量......
（3）服务器端
（4）访问的方式
判定bug的依据：
（1）需求文档 原型图
（2）不相符合的错误类型
（3）难以理解 不易使用 运行缓慢
bug出现的原因：
20%来源于代码80%需求不明确 产品需求经常变更
产生bug的原因归纳为：
(1)需求解释有误
(2) 用户需求定义错误
(3) 需求记录错误
(4) 设计说明有误
(5) 编码说明有误
(6) 程序代码有误
(7) 数据输入有误
(8) 测试错误
(9) 问题修改不正确
测试流程：(面试题)
我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与，讨论需求并提出建议，在立项会中制定需求文档，有UI设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写 测试计划，根据模块（的颗粒度）划分并编写测试用例以及对用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug开发进行修改，修改成功后关闭bug，进行回归测试，在上线前进行测试总结。
《需求文档》/《规格说明使用书》
《测试计划》一般由于测试组长或者是测试经理编写（参与）
《测试用例》根据模块划分/根据测试功能、性能、自动化进行划分
《用例评审会》分两种：
（1）组内评审【测试人员 测试组长/项目经理 产品经理】
（2）组外评审【测试人员 测试组长/项目经理 产品经理 客户
《冒烟测试》对软件的主要功能进行测试
《回归测试》
《测试总结》一般由于测试组长或者是测试经理编写（参与）
日常工作：
1、参与需求讨论，制定测试计划，确保测试能顺利执行并完成
2、负责项目的功能性测试，用户体验测试，兼容性测试以及性能测试
3、负责测试用例的编写，编写测试报告和对测试结果分析
4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行
5、负责软件开发团队项目进度管理工作
6、熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句
7、熟练使用Loadrunner，lmeter等至少一种性能测试工具
8、熟练掌握java/python/shell等编程语言的一种
9、熟练使用python+selenium/appnium pytest untest innerHtml
10、持续性能监控
测试分类：
测试分类：按阶段划分 代码是否执行 程序运行划分 其他
- 阶段划分：
单元测试：单个功能的测试（增删改查 分页 上传 下载）
集成测试：功能模块的测试（多个功能点进行总结在一起）
系统测试：多个模块合成测试（整个软件的整体测试）
验收测试：客户以及产品经理进行验收（交付前的测试）
- 程序是否执行：
静态测试：UI界面 业务逻辑
动态测试：链接数据之后
- 代码是否执行：
黑：纯功能测试（手动测试 点点点）
功能测试
安装/卸载测试
界面测试
易用测试
兼容性测试
逻辑功能测试
性能测试
稳定性测试 monkey命令
压力测试
负载测试
一般性能测试 系统资源使用率
白：使用编程脚本进行测试，实现自动化
灰：介于黑和白之间
- 其他测试：
冒烟测试
回归测试
随机测试
暴力测试
测试原则：
1.应当把“尽早和不断地测试”作为开发者的座右铭
2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下制造极端状态和意外状态，一如网络异常中断、电源断电等情况
3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析
5.制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试
6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重要性往往要靠测试文档
测试发现bug而开发不认为是bug怎么办？（面试题）
1.找到需求文档或者是原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为bug
3.整理bug的复现的步骤和出现的频率
4.开发坚持不认为是bug的时候找项目经理、测试经理进行沟通来确认是否为bug
5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug
6.测试人员需要将bug整理并写入测试总结中
开发流程：
原文链接： https://www.cnblogs.com/liyasheng666/p/13877265.html https://blog.csdn.net/weixin_52740633/article/details/109852895
