软件测试 | 知识理论大纲

什么是软件测试

在规定的条件下，对程序进行操作，从而发现错误，对软件质量进行评估的过程。

软件测试的目的

以最少的人力、物力、时间找到软件的缺陷，并修改从而规避商业风险。

软件测试的定义

使用人工和自动手段来运行和测试某个系统的过程，目的在于检验是否满足了需求。

软件测试的原则

• 所有的测试都应该追朔到用户需求
• 尽早和不断的测试
• 测试工作都应该由独立的专业的软件测试机构来完成
• pareto 原则，测试发现的错误中 80% 很可能起源于 20% 的模块中（20% 指的是应用中出现的新模块，开发人员第一次开发，故会出现较多错误）
• 设计测试用例时，应该考虑各种情况
  • 测试用例： 测什么？怎么测？
• 对测试出的错误结果一定要有一个确认的过程（描述缺陷报告）
  • 书写错误文档
• 指定严格的测试计划
• 完全测试是不可能的，测试需要终止
• 注意回归测试的的关联性
  • 回归测试：指开发人员修改了旧代码后，我们需要重新进行测试，以确认修改没有有引入新的错误，或导致其他代码产生错误。
• 妥善保存一切测试过程文档

软件产品质量模型（ISO / IEC 9126）

• 功能性：提供满足明确和隐含要求的功能的能力
• 可靠性：在特定条件下使用时，软件产品呢维持规定的性能级别能力
  • 设备最好不要出故障
  • 社保出故障了，不要影响主要的功能和业务
  • 如果影响了主要功能和业务，系统可以尽快定位并恢复
• 易用性：易懂、易学、易用、漂亮好看（用户体验好）
• 效率：软件产品可提供适当的性能的能力，也就是产品的性能（单选、多选、全选）
• 可维持性：产品可以被修改的能力。可以增加功能，可以更新。
• 可移植性：跨越不同系统平台

软件质量模型保证（SQA）

[ 目的 ]

使软件制作的过程对于领导层是可见的。

[ 目标 ]

• 保证工作是有计划进行的
• 客观的验证软件项目产品和工作是否遵循恰当的标准，步骤和需求。
• 保证工作及结果及时通知给相关人员
• 高管可以接触到项目内部
• 软件质量需要测试工作来保证

[ QC（检验产品的质量）]

找出产品存在的问题，进行质量控制，向管理层反馈质量信息。

[ QA（审计产品过程的质量）]

来确认项目按照要求进行，审计的内容主要是过程； QA 则确保 QC 按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。

软件测试的基本流程

• 需求分析
• 编写测试用例（测什么？怎么测？）
• 评审测试用例
• 搭建测试环境
• 等待开发提供测试包
• 部署测试包
• 冒烟测试（对软件主体的基本功能进行基本测试）
• 执行测试用例
• BUG 跟踪处理（提交及回归 BUG）
• N 轮之后符合需求
• 测试结束

测试用例编写

测试需求

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D3loX8S8-1597574201554)(https://ftp.bmp.ovh/imgs/2020/04/44d5789a21365530.png)]

测试要点和测试点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C6qcre0j-1597574201561)(https://ftp.bmp.ovh/imgs/2020/04/4a83c3b61ceeafa8.png)]

开发模型

瀑布模型

快速原型模型

V 模型

开发和测试阶段划分比较清晰

• 需求分析
• 概要设计
• 详细设计
• 编码
• 单元测试（独立的模块测试）
• 集成测试（模块联调）
• 系统测试（整体流程）
• 验收测试（验证是否满足需求）

[ 优点 ]

• 包含底层测试（单元测试）和高层测试（系统测试）
• 阶段划分清晰，方便工作的整体把控

[ 缺点 ]

• 测试阶段比较靠后，之前的问题已经产生，修改不方便
• V 模型就是瀑布模型的变种，如果需求发生变化必然返工

W 模型（双 V 模型）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KoSE49GK-1597574201574)(https://ftp.bmp.ovh/imgs/2020/05/7d4ee17a2197ece6.png)]

开发一个 V, 测试一个 V，开发和测试并行

• 开发 V (需求分析、概要设计、详细设计、编码、集成、实施、交付)
• 测试 V (系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试)

[ 优点 ]

• 开发伴随着测试并行，需求和设计一样要进行测试
• 尽早的介入测试，会更早的发现问题，降低修复成本
• 阶段依然明显，方便整体流程把控

[ 缺点 ]

• 代码依然在测试之前，不方便代码的测试工作
• 如果没有文档，根本无法进行 W 模型，对人员要求较高

软件测试分类

系统测试

什么是系统测试

系统测试是一个全面的测试，包括单元、集成测试，

系统测试的方法是什么

• 功能测试
  • 概念：根据产品的需求说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格
  • 考察特性： 功能是否有遗漏，功能是否准确
  • 测试思路/步骤：
    1. 确定功能需求列表
    2. 分析功能测试得出测试子项
    3. 根据测试子项分析
    4. 采用测试用例方法设计用例
  • 测试点： 根据产品的需求说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格，满足用户显性和隐形的需求
• 性能测试
  • 概念：验证系统在不同的业务场景下的响应时间和资源利用率等性能指标是否符合预期的标准
  • 测试思路：
    1. 压力测试：调查系统在其资源超负荷的情况下的表现，尤其是这些对系统的处理时间有什么影响
    2. 容量测试：面向与数据。使系统承受超额的数据容量来发现它是否可以处理数据容量
    3. 负载测试：在一定负载的情况下系统的性能表现（不关注稳定性，也就是说不关注长时间运行，只是得到不同负载相关性能指标即可）
• 安全性测试:
  • 概念：用来验证集成在系统内的保护机制是否能够在实际的情况中不受到非法的侵入
  • 测试点：
    1. 权限管理（注册登录才可以查看、注册信息符合要求、密码后台加密）
    2. 信息保存（log、日志、cookie）
    3. 数据库（默认的用户名和密码）
    4. 协议(http协议)
  • 安全性测试策略：层层剥离法
  • 工具：
  • 书籍：白帽子讲 web 安全
• 异常测试：
  • 概念：又叫系统容错和可恢复性测试
  • 可靠性：指标
  • 可靠性设计方法：
    1. 避开错误（主动避开错误，针对可以预见的错误进行主动处理。试点：故意构测造无效数据、边界条件、压力测试）
    2. 容错技术（主动断电强制进入新的设备、构造数据库瘫痪、构造数据死锁、构造数据的不完整事物、构造出错的时间点：断网、短信号）
• GUI 测试内容
  • 界面实现与界面设计的吻合情况
  • 确认界面处理的正确性
• 易用性测试
• 安装测试
• 配置测试
• 兼容测试

测试用例设计方法

等价类划分法

把无法穷举的数据分类书写

• 按需求写出有效等价类
• 按需求取反无效等价类
• 找到特殊情况的无效等价类（中文、英文、空格、空、符号等）

[ 细节 ]

• 输入长度
• 组成规则
• 输入类型
• 是否为空
• 是否去除空格
• 是否区分大小写

边界值测试

• 找到测试数据的边界点进行测试，也就是有效等价类和无效等价类的边界点
• 一般情况下需要对边界值以及边界值两边的的值分别进行测试（如：0-100，需要测试 0， 100， -1，1，99，101）

因果图制作判定表

• 找到所有的输入条件和预期结果，把所有的输入条件和输出条件填写进去
• 得到初始表格，根据实际需求进行简化

场景法

• 基本流：正确的业务流程
• 备选流：有问题的业务流程

测试用例书写：需求文档的每一个需求

流程法

测试用例必须包含所有的分支条件，每一个分支条件就是一条测试用例。

错误推测法

• 时间急，任务紧，测试时间少，考虑使用错误推断法，根据测试人员以往的项目经验进行设计
• 已经经过几轮测试后，可以使用错误推测法进行测试用例的补充

正交排列法

当要测试的内容，需要排列组合的情况非常多的时候，我们考虑使用科学的方法来减少测试用例的个数，即正交表。

特点：均匀分散，齐整可比，所有的情况都应该被均匀的测试过一次

• 因素：控件的个数
• 水平：控件里面的可选项个数

[ 步骤 ]

• 先确定几因素，几水平
• 在“常用正交表”中找到合适的表格
• 复制找到的表格到自己的表格中
• 写一个对照表（所有的控件和对应的选项列出来）
• 把复制过来的表格和对照表实现映射关系

如果没有找到合适的正交表，选用多一些的正交表，把多余的内容删除

混合正交表

步骤：

• 制作取值表

• 复制取值表的数据，放到文本文档中保存

• 把文本文档放在 allpairs.文件夹中

• WIN+R 键进入 cmd 控制台

• 进入 allpairs 文件夹

• 在制台中入 allpairs 的文件路径如 F:allpairs/allpairs.exe test1.txt>test2.txt(其中 test1 是你放进 allpairs 文件夹中的文件，test2 填你要生成的文件名)

[ 获取方式 ]

• 下载地址：https://pan.baidu.com/s/1PkTq-wG0SwgNpZ4djscTUw
• 提取码：efe5

测试用例的设计

测试用例设计综合策略

1. 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

2. 必要时用等价类划分方法补充一些测试用例。

3. 用错误推测法再追加一些测试用例。

4. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

5. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

测试用例的设计步骤

1. 构造根据设计规格得出的基本功能测试用例。

2. 边界值测试用例

3. 状态转换测试用例。

4. 错误猜测测试用例。

5. 异常测试用例。

软件缺陷

缺陷状态

编号	缺陷状态	描述
1	提交	已提交的缺陷
2	打开	确认提交的缺陷，等待处理
3	拒绝	拒绝提交的缺陷，不需要修复或不是缺陷、重复缺陷、无法重现
4	修复	缺陷被修复（开发人员自认为修改对了）
5	关闭	确认修复的缺陷，将其关闭（测试人员进行回归复测，确认已经没问题）
6	推迟	可在以后解决，但要确定修复日期和版本

[ 禅道 ]

• **
• 已解决
• 已关闭

缺陷程度划分

1. 表面错误
2. 影响独立模块、断断续续的问题、特定条件下发生、与产品要求不一致。
3. 功能点没有实现、数据丢失
4. 影响了系统或者出现了严重的计算错误

缺陷的优先级

优先级别	描述
5-urgent	最高优先级 在这个错误影响下，系统几乎不可用
4-veryHigh	高优先级 错误对系统的功能产生严重的影响
3-high	中优先级 错误会制约开发和测试的活动进行，如果先前没有修复他，那么需要在发布前修复他
2-medium	低优先级 不会延迟发布，但是会在以后修正这个错误
1-low	最低优先级 时间和资源允许时修正

优先级和严重程度不是绝对的正比关系

缺陷类型

• 系统缺陷
• 数据缺陷
• 数据库缺陷
• 接口缺陷
• 功能缺陷
• 安全性缺陷
• 兼容性缺陷
• 性能缺陷
• 界面缺陷（删除操作未给出提示）
• 建议（功能建议、操作建议）

缺陷报告注意事项

• 尽量确保缺陷可以重现
• 简洁、准确、完整
• 一个缺陷一个报告
• 复现缺陷的步骤清晰（一个编号一个步骤）
• 描述结果和期望结果（结果就是 BUG 出现结果）
• 使用术语描述问题

缺陷统计

• 对软件问题的功能域分布进行分析，找出系统的薄弱环节
  • 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类
  • 二八定理：80% 的软件问题总发生在大约 20% 的功能模块中
• 对缺陷的注入阶段进行分析，并于历史数据相比较
• 应对软件缺陷类型进行分析，以便针对各自特点，先修复严重缺陷
• 动态采集每个测试周期中发现的缺陷数，并有效的控制缺陷的修复率
• 密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况

SVN 使用

• 创建版本库
• 检出 （获取版本库最新版本，只有检出操作后才能提交更新操作）
• 提交（把此文件夹中的内容提交到版本库）
• 更新（把最新的版本库中的内容，更新到此文件夹中）