软件测试基础知识2（续）

Roseanne_Park0

已于 2022-07-09 13:01:11 修改

阅读量305

点赞数

文章标签：单元测试

于 2022-07-09 12:59:47 首次发布

本文链接：https://blog.csdn.net/Roseanne_Park0/article/details/125692233

版权

软件测试定义和目的

软件缺陷的定义

软件未实现产品说明书要求的功能
软件出现了产品说明书指明不应该出现的功能
软件实现了产品说明未提到的功能软件未实现产品说明书未明确提及但应该实现的目标
软件难以理解、不宜使用、运行缓慢或者（从测试的角度看）最终用户会认为不好
所有不满足需求或者超出需求的都是缺陷
没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷

软件测试的定义和目的

定义
正向思维的定义
出发点：使自己确信产品能够正常工作的评价一个程序和系统的特性或能力，并确定它是否达到期望的结果，软件测试就是以此为目的的任何行为
反向思维的定义
出发点：

测试是为了发现错误而执行的一个程序或者系统的过程。
测试是为了证明程序有错，而不是证明程序无错。
一个好的测试用例在于他发现以前未发现的错误
一个成功的测试是发现了以前未发现的错误的测试
IEEE定义的软件测试
在规定条件下运行系统或构建的过程：观察和记录结果，并对戏通或构建的某些方面给出评价
分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性。
广义的软件测试定义
软件测试是对软件行程过程中所有工作产品（包括程序以及相关文档）进行的测试，而不仅仅是对程序的运行进行测试。

确认：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现
验证：通过检查和提供客观证据来证实指定的需求是否满足
####目的
软件测试的目的
以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险
同时利用测试过程中得到的测试结果和测试信息，作为后续开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。

测试和调试的区别
1. 测试是从已知的条件开始，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始，结束的过程可能不可预计
2. 测试是可以计划，可以先制定测试用例和过程，工作进度可以度量；描述调试的过程或持续时间相对比较困难
3. 测试的对象包括软件开发过程中的文档、数据以及代码，而调试的对象一般来说只是代码
测试调试
主体测试人员开发人员
目标找bug 将错误修改正确
方法等家类、边界值等程序和逻辑算法
思路反向思维正向思维
软件测试的对象
缺陷的由来
软件缺陷的由来
Bug
Defect

生命周期和模型

软件危机和软件工程

软件危机

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
软件工程包括两方面的内容：
软件开发技术：软件开发方法学、软件工具和软件工程环境
软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划。
软件工程：
引起软件危机的主要问题是软件质量问题
软件工程主要解决的就是软件质量问题
软件测试是软件质量管理体系中的一个非常重要的手段 ### 软件生命周期 ![软件生命周期](https://img-blog.csdnimg.cn/8b6d9292160241a19cb72f2ba376e5c1.jpeg#pic_center)

	测试	调试
主体	测试人员	开发人员
目标	找bug	将错误修改正确
方法	等家类、边界值等	程序和逻辑算法
思路	反向思维	正向思维

需求分析-概要设计-详细设计-编码-测试-验收

软件开发模型

瀑布模型

瀑布模型： 最早提出的软件开发的过程模型

存在的问题：

（1）强调时间顺序严格执行。前阶段不完成，后阶段不开始；
（2）将测试放在编码之后，没有体现出测试贯穿软件生命周期的原则。可以避免需求的问题一直延续到代码完成才暴露或者被发现；
（3）瀑布模型不适应用户需求的变化；
（4）线性开发，用户等到整个过程的末期才能看见开发成果，从而增加了开发风险。

优点：

（1）为项目提供了按阶段划分的检查点；
（2）当前一阶段完成后，只需要去关注后续阶段。

螺旋模型

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。
螺旋模型更适合大型的昂贵的系统级的软件应用。
螺旋模型更适合大型的昂贵的系统及软件应用。

迭代模型

迭代模型

迭代包括生产产品发布（稳定、可执行的产品版本）的全部卡法活动和要使用该发布必须的所有其他元素，强调开发深入；
在某种程度上,开发迭代式一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。
迭代过程具有以下优点：
1. 降低了在一个增量上的开支风险；
2. 降低了产品无法按照既定进度进入市场的风险；
3. 加快了整个开发工作的进度
4. 迭代过程这种模式适合适应于求的变化会更容易些。

敏捷宣言（敏捷模型）

敏捷宣言也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。

敏捷宣言强调的敏捷软件开发的四个核心价值是

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

12原则包括：

最高优先级的是：通过尽早和持续交付有高价值的软件，满足客户;
欣然面对需求变化，即使是在开发阶段的后期，敏捷流程就是用变化来为客户获得竞争优势
频繁交付可工作的软件，从数周到数月，交付周期越短越好
在项目过程中，业务人员、开发人员必须每天在一起工作
以受到激励的个体为核心构造项目，为他们提供所需的环境和支持，信任他们可以把工作做好
最有效的、最高效的沟通方法是面对面的交谈
可工作的软件是衡量进度的首要标准
敏捷流程倡导可持续开发。客户、开发人员、用户要能够共同、长期维持步调（节奏）、稳定向前
持续地追求技术卓越和良好的设计，以此增强敏捷的能力
简单 – 尽最大可能减少不必要的工作，简单是敏捷流程的根本
最佳架构、需求和设计，来自自组织型的团队
团队定期反思如何提升效率，并调节和调整自己的工作方式

增量模型

增量模型 是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
缺点：打破原有的软件结构和框架，可能会带来一定的风险。

增量模型一般会和迭代模型一起运用。

软件增加新功能；
优化某些功能
修复了某些未知或者已知的BUG

快速原型模型

原型：就是一个模型，可以模拟操作、简单运行。
典型应用和工具：Axure ,制作原型。

测试过程模型和流程

软件测试流程

测试流程

获取测试需求–>编写测试计划–>制定测试方案–>开发与设计测试用例–>执行测试–>提交缺陷报告–>测试分析与评审–>提交测试总结–>准备下一版测试

软件测试过程模型

V模型

V模型： 揭示了开发过程与测试过程中各阶段的对应关系
v模型

缺点与不足：

v模型仅仅把测试过程作为在需求分析、系统设计；
及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证;
需求的满足情况一直到后期的验收测试才被验证;
没有体现出“尽早地和不断地进行软件测试”的
原则。

W模型（重点）

测试过程和开发并行；单一过程是串行。
w模型

W模型： 由两个V字模型组成，分别代表测试与开发过程，明确表明出了测试与开发的并行关系。

优点：

测试的活动与软件开发同步进行
测试对象不仅仅是程序
今早发现软件缺陷可降低软件开发的成本

局限性：
在W模型中，需求、设计、编码等活动被视为串行的，这样就无法支持灵活的迭代。

H模型

H模型：

H模型将测试活动完全独立出来，形成了完全独立的流程，将测试准备过活动和测试执行果冻清晰地体现出来。
H模型揭示了一个原理：软件测试是一个独立的流程。
H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到准备的绪点，测试执行活动就可以开展，并且不同的测试活动可以按照某个次序先后进行，也可以反复进行。

X模型

x模型

X模型：

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。
X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

软件测试过程理念

尽早测试
- 测试人员早期参与软件项目
- 尽早地开展测试执行工作
全面测试
- 对软件的所有产品进行全面的测试
- 软件开发及测试人员（有时包括用户），全面的参与到测试工作中。
过程测试
- 测试人员要充分关注开发过程。
- 测试人员要对测试的全过程进行全程的跟踪
独立的、迭代的测试
- 测试活动是独立的
- 测试活动应该是循环往复、不断进行的。

通用测试技术

软件测试的分类

按照开发阶段划分

单元测试（一般要读程序和代码。大多数时候，单元测试都是由于开发人员自己去完成）
- 单元测试又称模块测试，是针对软件设计的最小单位–程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块动能、性能、接口和设计约束等要求，发现模块内可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试
集成测试（比较多的涉及到接口测试，它是一个持续不断地过程）
- 集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序地、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
确认测试（功能是否实现，一般都是正向测试，有时也会把确认测试称为冒烟测试。一般不作为正式的测试环节）
- 确认测试也叫有效性测试。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质。
系统测试（全面的：系统所有功能的测试；模拟所有的软件用户的操作；全方位的：和硬件系统的联系；和其他软件的关系）
- 系统测试是在真实的系统运行的环境下，检查完整的程序能否和系统正确配置、链接，并最终满足用户的所有需求。
验收测试（一般由供求双方。一般有三种验收测试的主体。
α测试：软件的开发商自己进行的交付前的测试；β测试：软件的需求方自己进行的测试；γ测试：第三方的软件测试。）
- 验收测试是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方也定的验收依据文档进行对整个系统的测试与评审，决定是否接受或拒收系统。

按照测试技术划分

黑盒测试
- 通过软件的外部表现来发现其缺陷和错误。黑盒测试法吧测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
白盒测试
- 通过程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都正确，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。
灰盒测试
- 介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只通过一些表征性的现象、事件、标志来判断内部运行状态。

按照代码运行划分

静态测试
- 指不实际运行被测对象，而只静态的检查程序代码、界面或文档中可能存在错误的过程；
- 代码测试：主要测试代码是否符合相应的标准和规范；
- 界面测试：主要测试软件的实际界面与需求中的说明是否相符；
- 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求。
动态测试
- 指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。

按照软件特性划分

功能测试：是黑盒测试的一方面，他检查实际软件的功能是否符合用户的需求
- 逻辑功能测试
- 界面测试
- 易用性测试
- 安装/卸载测试
- 兼容性测试
性能测试
- 功能的另一个指标，主要关注软件中的某一功能在指定的实践、空间条件下，是否使用正常
- 软件的性能包括很多方面，主要有时间性能和空间性能两种
安全性测试
- 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。

其他测试类型

回归测试
- 是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
- 目的：
  1. 验证之前版本产生的所有缺陷已经全部被修复；
  2. 确认修复这些缺陷没有引发心得缺陷
冒烟测试
- 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测试性。
随机测试
- 是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
猴子测试
- 把自己当作不懂产品的笨蛋或动物，随便乱点，没有任何主观意识和想法参与进来，让一些一样不到的操作造成错误的结果。

按照测试运行主体划分

手工测试（功能测试）
自动化测试：利用工具软件或者编写代码的方式，测试被测的软件系统。（例：游戏外挂）

小结

	单元测试	集成测试	确认测试	系统测试	验收测试
测试技术	黑盒/白盒	黑盒/白盒/灰盒	黑盒/白盒	黑盒/白盒	黑盒/白盒
代码运行	动态/静态	动态/静态	动态/静态	动态/静态	动态 /静态
软件特性	功能/性能/安全	功能/性能/安全	功能/性能/安全	功能/性能/安全	功能/性能/安全
其他测试			冒烟测试	回归测试	随机测试/猴子测试
测试手段	手工自动化测试