软件测试的目的和原则
软测的目的
直白点来说软件测试的目的就是：提前发现软件的问题并修复，减少公司层面的损失。
软件测试原则
软件测试只能证明软件存在缺陷，不能证明不存在问题
不能进行穷举测试，应该分类别进行测试
测试应该要尽快的介入，越早发现问题，修复成本越低
坚信二八原则：20%模块中存在80%缺陷，bug存在集群现象
测试依赖测试环境（公司一般有测试环境，生产环境，开发环境，每个公司可能有些区别）
杀虫剂现象：讲的是同一个人测试同一个模块，有可能测试不出来，进行轮测的时候有可能会发现不一样的问题
软件开发模型
在软件测试行业，人们总结了很多软件开发模型用来描述一个软件开发的过程，如：
软件测试与软件的开发有着很重要的关系，作为测试人员，应该理解软件开发的模式，以便自己找准自己的定位。
瀑布模型
瀑布模型的特点
按流程直接，执行完一个阶段，才去执行下个阶段，且只执行一次。
瀑布模型的优缺点
优点：
开发流程每个阶段都区分开，流程清晰，方便管理
缺点：
需求改变，流程也需要重新进行，不适合现在的大部分开发流程
测试在最后阶段，发现风险修改成本较高
快速原型模型和螺旋模型
快速模型
快速模型特点
快速构建软件原型
支持用户参与
快速模型优缺点
优点：
完善瀑布模型的缺点，减少由于软件需求不明确带来的项目开发风险。
缺点：
不适合作为一个大型项目开发，适用于小项目，灵活度高的项目（小程序）
螺旋模型
螺旋模型的特点
引进了风险分析活动
螺旋模型的优缺点
优点：
螺旋模型很大程度上是一种风险驱动方法体系。
缺点：
需要丰富的风险评估经验和相当高的专业知识。
V模型
RAD（Rapid Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。
V模型示意图：
V模型优缺点
优点：
测试V模型包含了底层测试也包含了高层测试
缺点:
需求变更会导致重新返工的工作量巨大，灵活性比较低
W(双V)模型
W模型，由Evolutif公司提出，相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。
由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
W模型示意图：
W模型的优缺点
优点：
强调测试早期介入，测试需要介入全面的流程，不只是测试代码，包括需求跟设计。
缺点：
测试要求技术高，实现比较困难。
软件质量模型的分类
软件质量模型
软件质量，就是软件与明确地和隐含地定义的需求相一致的程度。
ISO 9126软件质量模型是评价软件质量的国际标准，这个模型是软件质量标准的核心，对于大部分的软件，都可以考虑从这这6个特性和27个子特性去测试、评价一个软件。
软件测试分类
按测试阶段划分
单元测试
单元测试又称模块测试，是指对软件设计开发中最小程序模块，进行正确性检查的测试工作。单元测试需要从程序内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试
又叫组装，通常在单元测试的基础上，将所有程序模块进行有序的，递增的测试。
系统测试
将整个软件系统作为一个整体来进行测试，测试依据是需求说明书。
验收测试
检验软件是否满足用户需求的测试。
α测试
Alpha是内测版本
通常只在软件开发者内部交流
这个版本的bug相对较多
β测试
beta是公测版本，是对所有用户开放的测试版本
通过一些专业爱好者的测试，将结果反馈给开发者，开发者再进行针对性的修改
γ测试
- Gamma版本，是指软件版本正式发现的候选版，该版本已经相当成熟了，与即将发行的正式版相差无几，成为正式发布的候选版本。
按是否覆盖代码划分
黑盒测试
又称数据驱动测试，不考虑程序内部结构跟内部特性，注重于软件的功能需求，只看软件的输入数据和输出数据。
白盒测试
简单来说就是进行程序内部的代码测试和程序结构
灰盒测试
介于黑盒跟白盒测试之间的一种测试，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
按是否运行分类
静态测试
不运行被测试的程序软件，静态检查代码，界面或者文档可能存在的错误。
动态测试
实际运行被测软件，输入相对应的测试数据，检查实际输出结果是否跟预期符合。
是否自动化划分
点点点测试
测试人员手动去执行测试
自动化测试
利用代码或者工具帮助人工进行测试
软件测试更多分类
冒烟测试
是对系统进行最基本功能的测试，保证基本的功能和流程能走通。
回归测试
修复一个bug之后，把之前的测试用例在新的代码下进行测试
随机测试
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分
探索性测试
探索性测试意味着同时设计测试和执行测试。测试人员通过测试来不断学习被测系统。
软件缺陷的定义与判定标准
软件缺陷（bug）的定义
是指软件或者程序中存在的各种问题及错误
软件缺陷的判定标准
软件未达到需求规格说明书中标明的功能
软件出现了需求规格说明书指明不会出现错误的地方
软件的功能超出了需求规格说明书指明的范围
软件未达到需求规格说明书虽未指明但应该达到的目标
软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好。
软件缺陷产生的原因
软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：
需求解释、记录或者定义错误
设计文档说明存在错误或者拼写错误
编码说明、程序代码有误
硬件或者软件系统上存在错误
软件缺陷产生的根源
需求的变更
交流不充分
软件的复杂性
进度压力
软件缺陷的类型
功能错误
界面错误
兼容性错误
易用性问题
改进建议
测试用例定义和8要素
测试用例
测试用例：是为了特定的目的而设计的一组测试输入、执行条件和预期结果的文档。
测试用例八大要素
软件测试用例的基本要素包括用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、
预期结果。
版权归原作者 凉生爱喝奶茶 所有， 如有侵权，请联系我们删除。