第一章:软件测试概述
软件工程
软件生存周期
- 一般软件生存周期包括软件定义、软件开发、软件测试、软件使用与维护等几个部分。
软件定义
- 可行性分析的任务是了解用户的要求及实现环境，从技术、经济和社会等几个方面研究并论证软件系统的可行性。
- 需求分析的任务是确定所要开发软件的功能需求、性能需求和运行环境约束，编制软件需求规格说明、软件系统的确认测试准则。软件的性能需求包括软件的适应性、安全性、可靠性、可维护性错误处理等。
软件开发
- 软件开发是按照需求规格说明的要求，由抽象到具体，逐步生成软件的过程。软件开发一般由设计、实现和测试等阶段组成。
软件测试
- 软件需经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
- 整个测试过程分单元测试、集成测试、系统测试以及验收测试四个阶段进行。
- 测试的方法主要有白盒测试和黑盒测试。
软件使用和维护
- 软件的使用是在软件通过测试后，将软件安装在用户确定的运行环境中移交给用户使用。软件的维护是对软件系统进行修改或对软件需求变化做出反应的过程。
软件过程模型（重点）
瀑布模型
- 瀑布过程模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性，是一种严格线性的、按阶段顺序的、逐步细化的开发模式。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1rubGXNk-1609834854031)(C:\Users\Mt\Desktop\从0开始\图片\image-20210103224317093.png)]
螺旋模型
- 螺旋过程模型的基本思路是，依据前一个版本的结果构造新的版本，这个不断重复迭代的过程形成了一个螺旋上升的路径。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m4Di8GlR-1609834854036)(C:\Users\Mt\Desktop\从0开始\图片\image-20210103230423485.png)]
增量过程模型
- 有些时候可能会用一种几乎连续的过程小幅度地推进项目，这就是增量过程模型。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gvmfi7jJ-1609834854040)(C:\Users\Mt\Desktop\从0开始\图片\image-20210103230612207.png)]
快速原型模型
- 快速原型过程模型首先是快速进行系统分析， 在设计人员和用户的紧密配合下，快速确定软件系统的基本要求，尽快实现一个可运行的、功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统。
敏捷过程模型
- 敏捷软件过程模型是一种迭代式增量软件开发过程。敏捷开发方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
软件缺陷与软件故障（重点）
软件缺陷
- 软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。
软件故障
- 软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态，此时若无适当措施(容错)加以及时处理，便产生软件失效。
发生原因
- 软件复杂性
- 交流不够,交流上有误解或者根本不交流
- 程序设计错误
- 需求变化
- 时间压力
- 代码文档贫乏
- 软件开发工具
软件质量
- 软件质量是软件的生命，它直接影响软件的使用与维护。
- 软件需求是衡量软件质量的基础。
- 面对众多的质量因素如何取折衷，这实际上就是区分质量因素对软件质量影响程度轻重的问题，这个问题已经有了解决方案，即软件质量模型。
软件测试
- 软件测试就是为了发现错误而执行程序的过程。
- 软件测试是为了保证软件质量。
- 软件测试的过程亦是程序运行的过程。程序运行需要数据，为测试设计的数据称为测试用例。
- 测试用例的设计原则是尽可能暴露程序中的错误。一个成功的测试用例在于发现了至今尚未发现的缺陷。
软件测试模型
- 软件测试过程模型是对测试过程一种抽象，用于定义软件测试的流程和方法。
V模型
- V模型是最具有代表意义的测试模型 ，反映出了测试活动与分析设计活动的关系。
- V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T0el64N1-1609834854047)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104095650069.png)]
W模型
- W模型由两个V字型模型组成，分别代表测试与开发过程。
- W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kzBFqO0K-1609834854050)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104100136642.png)]
H模型
- H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
- H模型揭示了软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fDtIXWrY-1609834854052)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104100300958.png)]
软件测试的分类
- 按测试方式分类
- 静态测试
- 动态测试
- 按测试方法分类
- 白盒测试
- 黑盒测试
- 按测试过程分类
- 单元测试
- 集成测试
- 系统测试
- 验收测试
测试流程
- 测试计划
- 测试设计
- 测试准备和测试环境的建立
- 执行测试
- 测试评估
- 测试总结
第二章：软件测试计划
软件测试计划的作用
- 使软件测试工作进行更顺利
- 增进项目参加人员之间的沟通
- 及早发现和修正软件规格说明书的问题
- 使软件测试工作更易于管理
软件测试计划的组成部分
- 测试计划标识符
- 简要介绍
- 测试项目
- 测试对象
- 不需要测试的对象
- 测试方法（策略）
- 测试项通过/失败的标准
- 中断测试和恢复测试的判断准则
- 测试完成所提交的材料
- 测试任务
- 测试所需的资源
- 测试人员的工作职责
- 人员安排和培训要求
- 测试进度表
- 风险及应急措施
- 审批
第三章：软件测试基本技术
- 通常分为白盒测试和黑盒测试。
- 白盒测试又可分为静态测试和动态测试。
- 黑盒测试一般可分为功能测试和非功能测试。
黑盒测试
- 已知产品的功能设计规格和用户手册，可以进行测试证明每个功能是否实现、每个实现了的功能是否符合要求，以及产品的性能是否满足用户的要求。
- 黑盒测试又叫做功能测试或数据驱动测试。
- 软件的黑盒测试意味着测试要在软件的接口处进行，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书和用户手册，检查程序的功能是否符合它的功能说明，以及性能是否满足用户的要求。
白盒测试
- 已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
- 软件的白盒测试是对软件的过程性细节做细致的检查。
- 因此白盒测试又称为结构测试或逻辑驱动测试。
黑盒测试技术
功能测试
等价类划分法
- 所谓等价类是指某个输入域的子集，使用这一方法时，是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
- 等价类可分为有效等价类和无效等价类。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jxnrv6jT-1609834854054)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104153608518.png)]
边界值分析法
- 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
- 边界值分析法与等价类划分法的区别是边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
- 另外，边界值分析不仅考虑输入条件边界，还要考虑输出域边界产生的测试情况。
- 应当选取正好等于，刚刚大于，或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
错误推测法
- 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法，这就是错误推测法。
因果图法
- 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0uxvbWPo-1609834854059)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104154749836.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BBM08KFO-1609834854061)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104154755639.png)]
场景法
- 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8dfoBpwc-1609834854062)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104161530235.png)]
判定表驱动法
- 判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZINls2Ks-1609834854064)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104161714404.png)]
正交试验法
- 正交实验设计方法:是依据Galois理论，从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。
功能图法
功能图法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例，功能图方法是一种黑盒白盒混合用例设计方法。
非功能测试
- 强度测试
- 性能测试
- 安全测试
- 安装与卸载测试
- 配置测试
- 兼容性测试
- 故障修复测试
- 使用性能测试
- 帮助菜单及用户说明测试
黑盒测试例题
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BEVoEqnX-1609834854067)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104165038042.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qx2UxrJW-1609834854069)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104165048011.png)]
白盒测试技术
- 白盒测试对象基本上是源程序，是以程序的内部逻辑为基础的一种测试方法。
- 白盒测试方法又可分为静态测试和动态测试。
静态测试
- 静态测试是一种不通过执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。
- 最常见的静态测试是找出源代码的语法错误，这类测试可由编译器来完成，因为编译器可以逐行分析检验程序的语法，找出错误并报告。
代码检查法
代码检查法主要是通过桌面检查，代码审查和走查方式，对以下内容进行检查：
(1) 检查代码和设计的一致性；
(2) 代码的可读性以及对软件设计标准的遵循情况；
(3) 代码逻辑表达的正确性；
(4) 代码结构的合理性；
(5) 程序中不安全、不明确和模糊的部分；
(6) 编程风格方面的问题等。
静态结构分析法
- 在静态结构分析中，测试人员通常通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形、图表，清晰地标识整个软件的组成结构。
- 通过分析这些图表，包括控制流分析、数据据流分析、接口分析、表达式分析等，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。
动态测试
- 动态测试需要软件的执行，当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析是动态测试的主要特点。它显示了一个系统在检查状态下是正确还是不正确。
程序插桩技术
- 程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法，即向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pI7F2WHy-1609834854070)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104191539065.png)]
逻辑覆盖
- 是以程序内部的逻辑结构为基础，是通过对程序逻辑结构的遍历实现程序的覆盖。
- 语句覆盖：使程序中每个语句至少都能被执行一次。
- 判定覆盖：使得程序中每个判断的取真分支和取假分支至少经历一次。
- 条件覆盖：使得每一判定语句中每个逻辑条件的可能值至少满足一次。
- 条件判定组合覆盖
- 多条件覆盖：使得每个判定中条件的各种可能组合都至少出现一次。
多条件 >= 条件判定组合覆盖 >= 条件覆盖 >= 判定覆盖 >= 语句覆盖
基本路径测试法
- 基本路径测试法是在是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。
- 环路复杂性计算：
- 设E为控制流图的边数，N为图的结点数，则定义环路的复杂性为V(G)=E−N+2。
- 若设P为控制流图中的判定结点数，则有V(G)=P+1。
灰盒测试
- 灰盒与黑盒的区别：使用黑盒测试时，关心的是整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，就需要关心模块与模块之间的交互。
- 灰盒与白盒的区别：在灰盒测试中，还是无需关心模块内部的实现细节。对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试则不同，还需要再深入地了解内部模块的实现细节。
第四章：软件测试过程
- 单元测试 -> 集成测试 -> 系统测试 -> 验收测试，可能会有回归测试。
- 单元测试：目的是保证每个模块单独运行正确，多采用白盒技术。
- 集成测试：主要测试软件结构问题，因测试建立在模块间的接口上，所以多为黑盒测试，适当辅以白盒测试技术，以便能对主要控制路径进行测试。
- 系统测试：主要是检验软件是否满足功能、行为和性能方面的要求，这一步完全采用黑盒测试技术。
- 验收测试：与前面各种测试过程的不同之处主要在于它突出了客户的作用，同时软件开发人员也要参与。
单元测试
- 单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。
单元测试主要任务
- 模块接口测试
- 模块局部数据结构测试
- 模块中所有独立执行路径测试
- 各种错误处理测试
- 模块边界条件测试
单元测试环境
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nsSeA4dj-1609834854073)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104202649690.png)]
单元测试主要技术
- 静态测试
- 动态执行测试
- 状态转换测试
单元测试人员
- 单元测试一般由开发设计人员本身完成，一般由开发组在组长的监督下进行，由编写该单元的开发设计者设计所需的测试用例和测试数据，来测试该单元并修改缺陷。
集成测试
- 集成测试是组装软件的系统测试技术之一，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试的主要任务是要求软件系统符合实际软件结构，发现与接口有关的各种错误。
集成测试主要任务
- 将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。
- 将各个子功能组合起来，检查能否达到预期要求的各项功能。
- 一个模块的功能是否会对另一个模块的功能产生不利的影响。
- 全局数据结构是否有问题，会不会被异常修改。
- 单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。
集成测试实施方案
非增式测试方法
- 非增式测试方法是采用一步到位的方法来进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。
增量式测试方法
自顶向下增式测试
- 自顶向下增式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vOvLzHOJ-1609834854074)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104204802778.png)]
- 集成测试的整个过程由下列3个步骤完成：
① 主控模块作为测试驱动器，把对主控模块进行单元测试时引入的被调用模拟子模块用实际模块替代。
② 依照所选用的模块集成策略（深度优先和广度优先），下层的被调用模拟子模块一次一个地被替换为真正的模块。
③ 在每个模块被集成时，都必须立即进行测试一遍。
自底向上增式测试
- 自底向上增式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。图4中表示了采用自底向上增式测试实现同一实例的过程。
集成测试人员
- 集成测试所需人员一般从开发组中选出，在开发组长的监督下进行。
系统测试
- 完全采用黑盒测试，主要测试系统的功能。
- 测试人员：由独立的测试小组在测试组长的监督下进行。
验收测试
- 验收测试是软件开发结束后，用户对软件产品投入实际应用前，进行的最后一次质量检验活动。
- 验收测试主要是验证软件功能的正确性和需求的符合性。
验收测试的主要工作内容
- 配置复审
- 合法性检查
- 软件文档检查
- 软件代码测试
- 软件功能和性能测试
- 测试结果交付内容
α和β测试
α测试
- α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试，即软件开发公司组织内部人员，模拟各类用户行为对即将面市的软件产品（称为α版本）进行测试，试图发现并修改错误。
β测试
- 紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见。
验收测试人员
- 验收测试一般在测试组的协助下，由用户代表执行。
回归测试
- 回归测试是指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
- 回归测试一般多在系统测试和验收测试环境下进行。
- 回归测试一般采用黑盒测试技术。
第五章：测试用例设计
测试用例的基本概念
- 测试用例是测试用例是执行的最小实体，是为特定的目的而设计的一组测试输入、执行条件和预期的结果。
- 简单地说，测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作，并且达到程序所设计的结果。
测试用例的分类
- 白盒测试用例
- 软件各项功能的测试用例
- 用户界面测试用例
- 软件的各项非功能测试用例
- 对软件缺陷修正所确认的测试用例
测试用例管理
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4v1enkbE-1609834854077)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104220325822.png)]
第六章：测试报告与测试评测
- 测试报告主要是报告发现的软件缺陷。
- 测试评价主要包括覆盖评价以及质量和性能评价。
- 覆盖评价是对测试完全程度的评测；质量和性能评价是对测试的软件对象的性能、稳定性以及可靠性的评测。
软件缺陷
软件缺陷定义
- 软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。
- 符合下面5个规则中的一个，就叫做软件缺陷：
- 软件未达到软件规格说明书中规定的功能；
- 软件超出软件规格说明书中指明的范围；
- 软件未达到软件规格说明书中指出的应达到的目标；
- 软件运行出现错误；
- 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
软件缺陷分类
- 功能不正常
- 软件在使用上不方便
- 软件的结构未做良好规划
- 功能不充分
- 与软件操作者的互动不良
- 使用性能不佳
- 未做好错误处理
- 边界错误
- 计算错误
- 使用一段时间所产生的错误
- 控制流程的错误
- 在大数据量压力之下所产生的错误
- 在不同硬件环境下产生的错误
- 版本控制不良所产生的错误
- 软件文档的错误
软件缺陷复杂生命周期
- 软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。
- 符合下面5个规则中的一个，就叫做软件缺陷：
- 软件未达到软件规格说明书中规定的功能；
- 软件超出软件规格说明书中指明的范围；
- 软件未达到软件规格说明书中指出的应达到的目标；
- 软件运行出现错误；
- 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
软件缺陷分类
- 功能不正常
- 软件在使用上不方便
- 软件的结构未做良好规划
- 功能不充分
- 与软件操作者的互动不良
- 使用性能不佳
- 未做好错误处理
- 边界错误
- 计算错误
- 使用一段时间所产生的错误
- 控制流程的错误
- 在大数据量压力之下所产生的错误
- 在不同硬件环境下产生的错误
- 版本控制不良所产生的错误
- 软件文档的错误
软件缺陷复杂生命周期
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eh34YmYy-1609834854079)(C:\Users\Mt\Desktop\从0开始\图片\image-20210104221143734.png)]
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
