软件测试基础
Posted HuJisheng000
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试基础相关的知识，希望对你有一定的参考价值。
软件测试的定义
- 在IEEE国际标准中，对软件测试进行了详细的定义：“软件测试是在规定的条件下，使用人工或自动化手段来运行或测试某个系统的过程,其主要的目的是对其是否满足设计要求进行评估的过程”。
- 在这个定义中详细的描述三个维度的内容：软件测试需要在规定条件下进行、软件测试是一过程、目的是验证系统是否满足客户需求。
软件测试的·分类
(1)从被测试对象的角度分类，测试可以分为黑盒测试、白盒测试和灰盒测试
(2)从被测试对象是否运行的角度进行分类。从被测试对象是否运行的进行分类，测试可以被分为动态测试和静态测试。
(3)从测试执行时使用的工具角度分类。从测试执行时使用的工具角度分类测试可以分为手工测试和自动化测试。
| 被测对象 | 被测对象是否运行 |
|---|---|
| 黑盒测试 | 动态测试 |
| 白盒测试 | 静态测试 |
| 灰盒测试 | > |
静态测试是指不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、程序分析等都是静态测试的范畴。
动态测试是指按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。如果按阶段来分，单元测试中常见的动态测试方法就是逻辑覆盖的方法，而在系统测试阶段，我们做的测试都属于动态测试，因为我们要运行系统才能验证系统功能是否正确。
手工测试是指软件测试的整个活动过程（如评审、测试设计、测试执行等）都是由软件测试工程师手工执行来完成，不使用任何测试工具，狭义上是指测试执行由人工完成，这是最基本的测试形式。
自动化测试是使用软件来控制测试执行过程，比较实际结果和预期结果是否一致，设置测试前置条件和其他测试控制条件并输出测试报告。通常，自动化测试需要在适当的时间使已经形式的手工测试过程自动化
软件测试模型
瀑布模型
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护六项基本活动，其过程是将上一项活动接收的工作对象作为输入，当该项活动完成后会输出该项活动的工作成果，并将该项成果作为下一项活动的输入。该模型规定这六项基本活动自上而下、固定相互衔接的次序，如同瀑布流水，逐级下落。
从本质上讲，它是一个软件开发架构，开发过程通过一系列阶段顺序展开的，从需求分析直到产品发布和维护。如果在其中某个阶段有信息未被覆盖或有问题，那么就得返回到上一个阶段，并对这些阶段进行适当的修改才能进入下一个阶段，这样每个阶段都会产生循环反馈，开发过程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来
瀑布模型的优点：
- 为项目提供了按阶段划分的检查点；
- 当前一阶段完成后，只需要关注后续阶段；
- 可在迭代模型中应用瀑布模型
瀑布模型的缺点：
- 项目中各个阶段之间极少有反馈；
- 只有在项目生命周期的后期才能看到结果；
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
W模型
由于V模型存在一些明显的缺陷，人们就在实际测试过程中对V模型进行了改进，将演变为W模型。W模型由两个V字型模型组成，相对于V模型，增加了软件各开发阶段中应同步进行的验证和确认活动。
W模型也称之为双V模型，一个V是开发的生命同期，另一个V是测试的生命周期型与V模型有一个很大的不同，就是W模型是一个并行的模型，V模型是一个串行的模垄型开始是从需求分析开始就开始了，而不是等到编码完成后才开始。并且测试阶段的划分: 而不仅仅是单元测试、集成测试、系统测试，还包括前期的测试计划、测试方案等内容，这更符合现在企业测试的流程。
w模型的特征：
- (1)测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试；
- (2)测试与开发是并行的，从需求测试就应该开始介入；
- (3)提出尽早测试的概念，这样可以降低缺陷修复成本；
- (4)测试对象不仅仅是程序，还包括需求或其他的相关文档。
H模型
H模型将测试活动分离出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
特征：
- (1)测试是一个独立的过程；
- (2)测试达到准入条件，才可以执行；
- (3)测试对象是整个产品包，而不仅仅是程度、需求或相关说明书。
系统生命周期的测试策略
软件测试策略是指在软件测试标准、测试规范的指导下，依据测试项目的特定环境约束制定的软件测试原则、策略和方法的集合。
开发阶段的测试策略
开发阶段是指在整个产品开发过程中我们使用的测试方法,在开发阶段的测试策略和方法主要是白盒测试，当然有一些公司也会开展灰盒测试，但并不多，通常灰盒测试也就是我们说的集成测试。
白盒测试也称结构测试或逻辑驱动测试，主要是测试源程序内部的结构，通过测试来检查程序内部动作是否满足设计规格说明书的要求，检查源程序中路径覆盖情况。白盒测试将被测程序看作一个打开的盒子，即程序内部的逻辑结构可以看的很清楚
白盒测试通常的程序结构覆盖测试的方法有
语句覆盖
判定覆盖
条件覆盖
判定|条件覆盖
路径覆盖
基本路径覆盖
产品阶段的测试策略
产品阶段主要采取黑盒测试策略进行测试。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用，是否符合规格说明书。在测试过程中，把程序看作一个不能打开的黑盒子。在完全不考虑程序内部结构和内部特性的情况下，对程序接口进行测试，它只检查程序功能是否能按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度、从输入数据与输出数据的对应关系出发进行测试的，黑盒测试主要发现以下几类错误：
- 验证是否有不正确或遗漏的功能？
- 接口测试方面，验证输入能否正确地接受？输出的结果是否正确？
- 是否有数据结构错误或外部信息访问错误？
- 性能是否能够满足要求？
- 是否有初始化或终止性错误
常见的黑盒测试设计方法
等价类划分法
边界值划分法
错误推断法
因果图法
场景法
判定表法
正交实验法
测试基础之06 测试基础理论
软件测试的目的和原则
软测的目的
直白点来说软件测试的目的就是：提前发现软件的问题并修复，减少公司层面的损失。
软件测试原则
软件测试只能证明软件存在缺陷，不能证明不存在问题
不能进行穷举测试，应该分类别进行测试
测试应该要尽快的介入，越早发现问题，修复成本越低
坚信二八原则：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要素
测试用例
测试用例：是为了特定的目的而设计的一组测试输入、执行条件和预期结果的文档。
测试用例八大要素
软件测试用例的基本要素包括用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、
预期结果。
以上是关于软件测试基础的主要内容，如果未能解决你的问题，请参考以下文章