第一单元 测试理论
1.1 软件的分类
1.1.1 软件的定义
一系列按照特定顺序组织的计算机数据和指令的集合。
软件 = 数据 + 指令 + 文档
问题：常见软件有哪些？
1.1.2 根据应用场景分类
工具类软件、游戏型软件、媒体型软件、电商型软件等
1.1.3 根据软件架构分类
单机版软件、分布式软件
单机版软件：office、红警等
分布式软件：
C/S架构软件：客户端需安装专门软件，如QQ 微信等
B/S架构软件：客户端为浏览器 ，如百度、hao123等
1.2 软件测试的定义与原则
1.2.1 为什么需要软件测试
阿丽亚娜5号火箭.jpg
事故：阿丽亚娜5号火箭爆炸，造成重大经济损失。
原因：程序中试图将64位浮点数转换成16位整数时发生溢出-----缺少错误程序对数据溢出进行管理
事故：拼多多2019年用户可以领取100元无门槛券。
原因：程序中试图将64位浮点数转换成16位整数时发生溢出-----缺少错误程序对数据溢出进行管理
1.2.2 软件测试的定义
通过人工或自动化的方式来验证软件的实际结果与用户需求是否一致的过程
1.2.3 软件测试的原则
原则一：测试显示软件存在缺陷
测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
原则二：穷尽测试是不可能的
现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。
原则三：测试尽早介入
为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。
原则四：缺陷集群性（2/8原则）
缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。
一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。
原则五：杀虫剂悖论
反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。
原则六：测试活动依赖于测试内容
根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
原则七：没有错误是好是谬论
有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。
原则八：程序员应避免检查自己的程序
原则九：严格执行测试计划，排除测试的随意性
原则十：应当对每一个测试结果做全面的检查
原则十一：妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
原则十二：设计测试用例时，应当包括合理的输入数据和不合理的输入数据
原则十三：测试用例应由测试数据和与之对应的预期输出结果这两部分组成
1.3 开发与测试模型的介绍
1.3.1 开发模型
瀑布模型：
引入：做饭最终不能返回
定义：将软件生命周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品的项目。
优点：
为项目提供了按阶段划分的检查点
当前一阶段完成后，只需要去关注后续阶段。
缺点：
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
瀑布模型的突出缺点是不适应用户需求的变化。
快速原型模型：在需求分析阶段对软件的需求进行初步而非完全的分析和定义，用户与开发者在过程中加强反馈，快速设计开发出软件系统可以运行的模型；
增量模型：把待开发的软件系统模块化，第1个增量往往是产品的核心，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件；
敏捷开发：先选择产品，再进行开会、对产品计划，然后对任务进行分工，分工后开始按照计划执行，然后就做出了新的功能模块，然后再进行演示、回顾，最后再领取新的任务，依次循环。
1.3.2 测试模型
V模型：
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
W模型：
相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
1.4 软件测试的流程
阶段名工作内容产出物
测试准备阶段项目立项、需求分析、需求评审需求文档、产品PRD
测试计划阶段编写测试计划、计划评审测试计划
测试设计阶段提取测试点、编写测试用例、用例评审测试用例
测试执行阶段冒烟测试、执行测试用例、提bug、回归测试缺陷报告
测试完成阶段验收测试、编写测试报告、项目上线测试报告
1.5 软件测试的分类
1.5.1 按技术划分
黑盒测试、白盒测试、灰盒测试
黑盒测试(Black Box -Test)：把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。
“望”：观察软件的行为是否正常。
“闻”：检查输出的结果是否正确。
“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。
“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”
白盒测试：是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法
灰盒测试：一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法
1.5.2 按阶段划分
单元测试、集成测试、系统测试、验收测试
单元测试：对一个模块、一个函数或者一个类来进行正确性检验的测试方法
集成测试：单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的测试方法
系统测试：集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试
验收测试：系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法
1.5.3 按内容划分
功能测试、性能测试、兼容性测试
1.5.3.1 功能测试：
界面测试、冒烟测试、回归测试、业务逻辑测试、易用性测试
功能测试：根据产品操作描述和需求文档，测试一个产品的特性和可操作行为是否满足用户需求的测试方法
界面测试：测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试
冒烟测试：验证系统的核心功能是否能够正常运行的测试方法
回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的测试方法
业务逻辑测试：在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试
易用性测试：指用户使用软件时是否感觉方便的测试
1.5.3.2 性能测试：
性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行校验的测试方法
压力测试：通过逐步增加系统负载，测试系统性能的变化，并确定在什么条件下系统性能处于失效状态
负载测试：通过逐步增加系统负载，测试系统性能的变化，在满足性能指标的情况下，系统所能承受的最大负载量的测试
并发测试：是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能
1.5.3.3 兼容性测试：
冒烟测试、随机测试、安全性测试、探索性测试、回归测试、Alpha测试、Beta测试
随机测试：随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法
安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法
探索性测试：碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法
Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场
Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场
1.5.4 按其他划分
冒烟测试、随机测试、安全性测试、探索性测试、回归测试、Alpha测试、Beta测试
随机测试：随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法
安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法
探索性测试：碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法
Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场
Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场
