当系统引入新的代码时，增加新功能 ，升级，修改系统的BUG时进行回归测试，
回归测试的策略：自动化测试
冒烟测试
对系统的主要功能和核心流程就行测试，在进行系统测试之前，测试人员是否接受此次迭代正式测试的依据
目的：快速验证软件基本功能是否有缺陷
准入原则：如果对冒烟测试的测试用例不能通过，则不必做进一步的测试
1.1.4验收测试
测试对象：验收测试不仅是对系统进行全面测试，也要验收文档（开发文档，软件设计文档，需求分析文档，功能使用文档，用户使用手册）
测试阶段：系统测试之后
测试依据：用户需求
测试人员：用户
测试方法：黑盒
1.2测试实施组织
1.2.1 α测试
将用户或者非测试和非开发人员请到开发现场进行测试
1.2.2 β测试
用户在实际使用环境下进行测试（在新产品发布之前，会邀请活跃用户进行测试，即实际用户）
优点：参与测试的活跃用户测试出的结果更加接近于大部分用户实际使用情况的反馈
α测试和β测试的区别：
测试人员
α测试是除了开发和测试人员以外的任何人
β测试是实际用户
测试环境
α测试是在开发环境下
β测试是实际使用环境下
β测试之气要进行很长时间的α测试，产品在面向用户正式发布之前会进行β测试
1.2.3 第三方测试
第三方测试机构进行测试的
1.3测试执行方式
1.3.1 静态测试
不运行代码，通过静态分析代码的语法，编写规范，逻辑，结构，实现的功能等，来判断软件是否满足用户的需求
静态测试通过静态测试的标准（功能，性能，兼容性，易用性，可靠性，安全性，可维护性，可移植性）来约束
1.3.2 动态测试
运行软件，进行测试
1.4是否查看代码
1.4.1黑盒测试
黑盒测试又称为功能测试或数据驱动测试，是用来检测每个功能是否正常适用，黑盒测试主要意味着测试要在软件的接口处进行，这种测试方法是将测试对象看成一个盒子，测试人员不考虑内部的结构、逻辑、功能的集体代码实现，只关心输入和输出是否满足用户的需求，直接按照需求规则说明书来直接检查他的功能是否符合要求
黑盒测试的优点：
1.不需要了解程序内部的代码及实现，操作简单；
2.与软件的内部实现无关，不用考虑内部逻辑结构及内部特性；
3.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
4. 适用于功能测试、可用性测试及可接受性测试
黑盒测试的缺点：
1.不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；有些bug检测不出来。
2.自动化测试的复用性较低
3.直接依赖于需求规格说明书，如果需求规格说明书不全面，得到的测试结果也不会很完善。
几种常见黑盒测试用例设计方法：
**1.等价类法
2.边界值法
3.因果图法
4.场景图法
5.正交法
6.错误推测法**
详情请见上一篇文章，有详细的介绍几种方法，
1.4.2白盒测试
白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，白盒指的是程序的内部结构和运作机制是可见的。
白盒测试的目的：
通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设置检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试的方法：分为静态方法和动态方法两大类。
静态分析：
是一种不运行程序而进行测试的技术。静态分析的主要目的是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
动态分析：
当软件系统在模拟或真实的环境中执行前、过程中和执行后,对其行为分析。它显示了一个系统在检查状态下是否正确。在动态分析技术中,最重要的技术是路径和分支测试。
下面要介绍的六种覆盖测试方法，都属于动态分析方法。
符号介绍
^ 代表逻辑运算符 && 或者 ||
T 代表 True F 代表 False
A / B 代表条件表达式
（1）语句覆盖
使程序中的每个可执行语句都能执行一次的测试用例
（2）判定覆盖（分支覆盖）
对于判断语句，在设计用例的时候，要设计判断语句结果为True和False的两种情况
（3）条件覆盖
设计用例时针对判断语句里面每个条件表达式true 和 false各取值一次，不考判断语句的计算结果
（4）判定条件覆盖（分支条件覆盖）
设计测试用例时，使得判断语句中每个条件表达式的所有可能结果至少出现一次，每个判断语句本身所有可能结果也至少出现一次。
（5）条件组合覆盖
设计测试用例时，使得每个判断语句中条件结果的所有可能组合至少出现一次
（6）路径覆盖
设计测试用例时，覆盖程序中所有可能的执行路径
优点：这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。
缺点：于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。路径覆盖虽然是一种比较强的覆盖，但未必考虑判断语句中条件表达式结果的组合，并不能代替条件覆盖和条件组合覆盖。
1.4.3灰盒测试
介于白盒和黑盒测试之间的测试
1.5是否手工执行
1.5.1手工测试
手工测试——（黑盒测试）设计人员先写测试用例，运行系统，执行测试用例，分析结果
缺点： 量大容易出错，花费大量时间
优点：可以进行探索性测试和发散性测试，因为是人主导的，可以改变的
1.5.2自动化测试
通过书写自动化脚本来实现，将手工测试的测试用例转换成脚本
做自动化测试的条件：系统稳定之后
自动化的价值：脚本的重复使用率（利用率）越高，自动化越有价值
1.6测试对象划分
1.6.1性能测试
系统是否可以很快响应用户的请求
超过系统用户负载的情况下，系统是否可以稳定运行，
系统要在预期和非预期的情况下，用户有良好的体验
问题：资源泄漏、资源瓶颈、线程阻塞、数据库查询效率慢效率低…
测试指标
资源利用率（CPU、带宽、硬盘）、点击率、响应时间、每秒事务处理量…
1.6.2业务测试
把一个个孤立的功能点按照一定的策略组合在一起，形成一个业务，对这个业务进行测试
1.6.3界面测试
界面是软件的使用者和软件进行交互的平台，
界面测试通过UI设计稿来测试：
布局（图片的位置，文字的展示，各种控件的展示）
文字： 标题，字好，格式 字体
图片：是否遮挡，是否清洗，是否合理
控件：按钮，滚动条是否可以正常使用，
页面元素有效无效的状态，有效 高亮显示，无效，灰色
弹出框，提醒框位置是否合理
响应式页面的测试：
1.页面大小进行切换时，切换过程页面元素表示无缝衔接，丝滑，不会出现空白页面，图片或功能丢失
2.页面大小进行切换时，页面图片，文字，不会丢失
3.页面大小进行切换时，页面功能不丢失，并且可以正常使用
4.页面大小进行切换时，都遵循UI界面设计需求
1.6.4容错测试
当系统由于外部环境或用户操作不当引起的一些问题的时候，系统可以自我消化掉这些错误，不直接展示给用户
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数软件测试工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上软件测试开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
IGx-1712782626342)]
[外链图片转存中…(img-Z8EVze6X-1712782626343)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上软件测试开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-hMzxTZ5p-1712782626343)]