【软件测试】学习笔记（四）

一、软件测试分类

1、按照开发阶段划分

① 单元测试

一般要读程序和代码。大多数时候，单元测试都是由开发人员自己去完成（交叉）（但是一般不认为是在做测试）。测试人员为什么不做单元测试？（大家不懂代码和算法）

• 又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作
• 其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误
• 单元测试需要从程序的内部结构出发设计测试用例
• 多个模块可以平行地独立进行单元测试

② 集成测试

比较多的设计到接口测试（接口测试工具和方法专门学习），企业非常需要接口测试工程师。它是一个持续不断的过程

• 也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试
• 集成测试时检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统

③ 确认测试

一般都是正向的测试（功能是否实现），有时也称为冒烟测试，一般不作为正式的测试环节

• 也叫有效性测试。是在模拟的环境下，验证软件的所有功能和性能及其特性是否与用户的预期要求一致
• 通过了确认测试之后的软件，才具备进入系统测试阶段的资质

④ 系统测试

全面的：对系统所有功能的测试；模拟所有的软件用户的操作；全方位的：和硬件系统的联系，和系统软件的联系，和其他软件的关系

• 是在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并最终满足用户的所有需求

⑤ 验收测试

一般供求双方。有三种验收测试的主体：α测试（软件开发商自己进行的交付前的测试）、β测试（软件的需求方自己进行的测试）、γ测试（第三方的软件测试）

• 是软件产品检验的最后一个环节
• 按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试和评审，决定是否接收或者拒收系统

2、按照测试技术划分

① 黑盒测试

• 通过软件的外部表现来发现其他缺陷和错误
• 把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程
• 在程序界面处进行测试，只是检查程序是否按照需求规格说明书的规定正常实现

② 白盒测试

• 通过对程序内部结构分析、检测来寻找问题
• 把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行
• 又称为结构测试

③ 灰盒测试

• 介于白盒和黑盒测试之间的测试
• 关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、时间、标志来判断内部的运行状态

3、按照代码运行划分

① 静态测试

• 不实际运行被测对象，知识静态的检查程序代码、界面或文档中可能存在错误的过程
• 代码测试：主要测试代码是否符合相应的标准和规范
• 界面测试：主要测试软件的实际界面与需求中的说明是否相符
• 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求

② 动态测试

• 实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程
• 判断一个测试时动态/静态测试，唯一的标准就是看是否运行程序

4、按照软件特性分类

① 功能测试

• 是黑盒测试的一方面，检查实际软件的功能是否符合用户的需求
  • 逻辑功能测试
  • 界面测试
  • 易用性测试
  • 安装/卸载测试
  • 兼容性测试

② 性能测试

• 功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常
• 软件的性能包括很多方面，主要有时间和空间性能两种

③ 安全性测试

• 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰

5、其他测试类型

① 回归测试

• 指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
• 目的：1.验证之前版本产生的所有缺陷已全部被修复；2.确认修复这些缺陷没有引发新缺陷

② 冒烟测试

• 在对一个新版本进行系统大规模的测试之前，先验证一下软件基本功能是否实现，是否具备可测性
• 也叫可测性测试

③ 随机测试

• 测试人员基于经验和直觉的测试，发现一些边缘性的错误

④ 猴子测试

• 把自己当成不懂产品的笨蛋或小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果

6、按照测试运行主体划分

① 手工测试

• 功能测试，点点点

② 自动化测试

• 利用工具软件，或者编写代码的方式，测试被测的软件系统（游戏外挂）

7、总结

图1 软件测试分类总结

二、软件测试的原则

1、遇到的问题

• 测试时间不够的情况下，还有大量的内容没有测试，软件能不能发布/上线/发版？
• 有的严重bug没修复，但是赶着上线，能不能通融/放任？
• 需求重要么？错误的需求对测试有什么样的影响？
• 你觉得软件测试在什么阶段介入比较好？为什么？
• 软件发布了，但是有缺陷，是测试人员的错么？
• 你写过测试计划么？包含什么内容？测试计划可以被修改么？
• 设计和编写测试用例有什么区别？设计是一项脑力活动，编写是一项体力活动，将设计好的内容通过文字的形式表现出来
• 针对已经发现了缺陷的模块，如何进行深入测试？对发现缺陷模块使劲测，另外关联的模块也要进行测试（缺陷有一种集群效应）
• 软件项目上线了/发布了，还要进行测试么？
• 你觉得你有什么样的缺点？（不能说的：粗心、耐心不够、不善与人沟通、语言表达能力不行）（斤斤计较、穷追不舍、轴...、认死理、说话声音大、性格急）

2、测试的原则

• 所有的测试标准都是建立在用户需求上
• 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量
• 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估
• 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试
• 穷举测试是不可能的
• 第三方进行测试会更客观，更有效
• 软件测试计划是做好软件测试工作的前提
• 测试用例是设计出来，不是写出来的，所有要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性
• 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大
• 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
• 应该把“尽早和不断地测试”，作为测试人员的座右铭
• 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
• 测试应从“小规模”开始，逐步转向“大规模”
• 不可将测试用例置之度外，排除随意性
• 必须彻底检查每一个测试结果
• 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
• 对测试错误结果一定要有一个确认的过程