【Alpha测试】
- Alpha测试是由用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试
- 测试环境受开发方控制
- 用户数量相对较少
- 时间比较集中
- 先于Beta测试
【Beta测试】
- Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。
- 测试环境不受开发方控制
- 用户数量较多
- 测试时间比较长
【验收测试】
- 验收测试是以用户为主的测试,软件开发和QA人员也应该参加,测试一般在用户所在地进行,由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作
- 验收测试的目的是为了以发现”未实现的需求”为目的,以评估”适合使用”为目标,该类测试的不是以发现缺陷为主要目的。
【灰度测试】
- 灰度测试,也叫灰度发布或金丝雀发布,就是在某项产品或应用正式发布前,选择特定人群试用,逐步扩大其试用者数量,以便及时发现和纠正其中的问题。
- 灰度发布能及早获得用户的意见反馈,完善产品功能,提升产品质量,让用户参与产品测试,加强与用户互动,降低产品升级所影响的用户范围。
- 在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来
- 灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。 灰度发布步骤:
- 定义目标
- 选定策略:包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
- 筛选用户:包括用户特征、用户数量、用户常用功能、用户范围等
- 部署系统:部署新系统、部署用户行为分析系统(web analytics)、设定分流规则、运营数据分析、分流规则微调
- 发布总结:用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
- 产品完善
- 新一轮灰度发布或完整发布
【静态测试】
静态测试是指不运行被测程序本身,通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。其被测对象是各种与软件相关的有必要进行测试的产物,是对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态测试可以手工进行,充分发挥人的思维的优势,并且不需要特别的条件,容易展开,但是静态测试对测试人员的要求较高,至少测试人员需要具有编程经验。 静态测试包括各阶段的评审、代码检查、程序分析、软件质量度量等,用于对被测程序进行特性分析。其中评审通常有人来执行;代码检查程序分析、软件质量度量等即可人工完成,也可用工具来完成,但工具的作用和效果相对更大更好一些。
【动态测试】
通过运行被测程序来检查运行结果与预期结果的差异,并分析运行效率和健壮性等指标。 动态测试分类:可从不同角度进行分类。
- 从是否关心软件内部结构和具体实现的角度划分,可分为白盒测试、黑盒测试、灰盒测试
- 从软件开发过程的角度划分,可分为:单元测试、集成测试、确认测试、系统测试、验收测试、回归测试
- 从测试执行是否需要人工干预的角度划分,可分为:人工测试、自动化测试
- 从测试实施组织的角度划分,可分为开发方测试、用户测试(β测试)、第三方测试。
【白盒测试】
白盒测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。
【黑盒测试】
又称功能测试或数据驱动测试。把测试对象当作看不见内部的黑盒,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性.
【灰盒测试】
是一种综合测试法,它将黑盒测试、白盒测试、回归测试和变异测试结合在一起,构成一种无缝测试技术。既基于程序运行时的外部表现又结合程序内部逻辑结构来设计测试用例,执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
【冒烟测试】
冒烟测试是自由测试的一种。主要关注以下两方面的测试:
- 开发人员会来修复这个bug后,要确定问题是否修复以及对其他模块的影响,就需要针对此问题进行专门测试。
- 指测试人员在正规测试一个新版本之前,先投入较少的人力和时间验证一个软件的主要功能,如果主要功能都没有实现,则打回开发组重新开发。 冒烟测试优点是节省测试时间缺点是测试覆盖率比较低。
【回归测试】
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 回归测试一般是在进行软件的第二轮测试开始的,验证第一轮中发现的问题是否得到修复。当然回归也是一个循环的过程,穿插在软件测试整个生命周期里面。如果回归的问题不通过,则需要开发人员修改后再次回归,直到通过为止。 回归测试在冒烟测试之后执行
【A/B测试】
所谓 A/B 测试,简单来说,就是为同一个目标制定两个方案(比如两个页面),让一部分用户使用 A 方案,另一部分用户使用 B 方案,记录下用户的使用情况,看哪个方案更符合设计目标。 A/B 测试最核心的思想,即:
- 多个方案并行测试
- 每个方案只有一个变量不同
- 以某种规则优胜劣汰 需要特别留意的是第 2 点,它暗示了 A/B 测试的应用范围,必须是单变量。
要实现 A/B 测试,我们需要做以下几个工作:
- 开发两个(或多个)不同的版本并部署
- 收集数据
- 分析数据,得出结果