自学软件测试day2

软件测试对象包括文档、数据和程序，提倡全生命周期测试理念。

测试分类多样：按阶段分为单元、集成、系统和验收测试；按代码可见度分为白盒、灰盒和黑盒测试；按执行方式分为静态测试（评审文档）和动态测试（手工/自动化执行）。

系统测试涵盖功能、性能、健壮性（容错与恢复）、安全性、压力、可靠性等类型。

其中功能测试验证需求实现，性能测试评估处理速度，健壮性测试异常处理能力，安全性测试防入侵能力。此外还包括回归测试（验证旧功能）和冒烟测试（基础功能验证）。测试方法需根据项目特点灵活选择。

1、软件测试的对象

  • 软件是由文档、数据以及程序组成的

  • 测试应该是对文档、数据以及程序进行的测试

  • 60%以上的软件错误并不是程序错误，而是分心和设计错误

  • 测试概念扩大化，提倡软件全生命周期测试的理念

2、软件测试分类

2.1 按测试阶段划分

  1. 单元测试（白盒）：对程序源代码进行测试
  2. 集成测试（灰盒）：又称接口测试，针对模块之间访问地址进行测试
  3. 系统测试（黑盒）：对整个系统进行测试，包括功能、兼容、文档等测试
  4. 验收测试（黑盒）：主要分为内测、公测，使用不同人群来发掘项目缺陷

2.2 按代码可见度划分

  1. 白盒测试：全部代码可见，针对程序源代码进行测试
  2. 灰盒测试：部分源代码可见，针对程序部分代码进行测试（接口）
  3. 黑盒测试：不关注源代码，针对程序UI功能进行测试

黑盒测试

  • 黑盒测试通过软件的外部表现来发现其缺陷和错误。把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程

  • 黑盒测试是在程序界面处进行测试，他只是检查程序是否按照需求规格说明书的规定正确实现

  • 如果软件需求本身有问题或规格说明有误，用黑盒测试方法是很难发现的

2.3  静态测试、动态测试

①静态测试——评审需求文档\测试用例

  • 静态测试指不运行程序，对程序和文档进行分析和检查、

  • 静态测试技术又称为静态分析技术

  • 静态测试包括对软件中的需求规格说明书、设计文档、测试文档（测试计划、测试用例、报告）以及程序源代码等进行审查

  • 特点：
  • 通过人工审查或工具分析发现潜在问题。
  • 适用于早期开发阶段，如需求分析和设计阶段。
  • 典型方法包括代码审查、走查、静态分析工具（如SonarQube、Checkstyle）。

②动态测试：手工、自动化

  • 动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的输出

  • 白盒测试、灰盒测试、黑盒测试都属于动态测试

3、系统测试类型

3.1 功能测试

功能测试是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户对于各方面功能的要求，确保软件以用户期望的方试运行。 依据是《需求规格说明书》

  1. 构造正常/异常输入检查输出是否与期望的相同。如果两者不一致，即表明功能有误
  2. 功能测试难点在于正确的理解用户需求和如何构造有效的测试数据

3.2 性能测试

测试软件处理业务的速度，检查性能是否符合需求，得到某些性能数据供人们参考（例如用于宣传）

3.3 健壮性测试

指软件在异常情况下，软件还能正常运行的能力；在异常输入、极端条件或意外环境下的容错能力和稳定性。其核心目标是验证系统能否正确处理错误或无效输入，而非崩溃或产生不可控行为。

两层含义：一是容错能力，二是恢复能力

①容错测试通常构造一些不合理的输入来引发软件出错，验证系统是否能正确处理并给出适当的错误提示或恢复机制。例如：        

  1. 异常输入处理：测试系统对无效、不完整或超出范围的输入数据的响应能力。
  2. 硬件或软件故障模拟：模拟磁盘故障、网络中断、内存泄漏等场景，观察系统行为。
  3. 资源限制测试：验证系统在资源耗尽（如CPU、内存、磁盘空间）时的表现。
  4. 错误恢复机制：检查系统是否能够自动恢复或提供明确的错误提示。

常见方法

  • 注入错误（如强制终止进程、断网、修改配置文件）。
  • 使用模糊测试（Fuzz Testing）生成随机或异常输入。
  • 监控系统日志和告警机制是否有效。

②恢复能力测试恢复能力测试侧重于评估系统从故障中恢复的速度和有效性，确保其能够快速回到正常状态。重点考察一下几项：

  • 故障恢复时间：测量系统从崩溃、断电或其他故障中恢复所需的时间。
  • 数据完整性：验证系统恢复后数据是否完整，是否存在丢失或损坏。
  • 服务可用性：检查关键功能是否在恢复后立即可用。
  • 自动化恢复：测试系统是否具备自动重启、故障转移或冗余切换能力。

常见方法

  • 模拟崩溃后重启，检查服务状态和数据一致性。
  • 测试备份与还原流程的有效性。
  • 验证高可用架构（如集群、主备切换）的可靠性。

3.4 安全性测试：

是指防止系统被非法入侵的能力，既属于技术问题（该加密地方加密等）又属于管理问题（给予恰当的权限）

3.5 压力测试（负荷测试）：

通过模拟极端条件或高负载场景，评估系统、软件或硬件在极限状态下的性能、稳定性和可靠性的测试方法。其核心目标是发现系统瓶颈、潜在故障点及性能阈值。

3.6 可靠性测试：

是指在一定的环境下，在给定的时间内、系统不发生故障的概率。用于验证产品或系统在特定条件下持续稳定运行的能力。

3.7 扩展

①回归测试：加入新功能或者修改完bug后，老功能（无改动部分）也要重新测试

    回归测试是有计划的，领导会把回归测试计划列在正常的测试计划里面，是有计划的、有目的的（进行2—3轮）

②冒烟测试的目的是防止开发出来的版本质量太差，影响测试团队，公司会安排1—2个测试人员对新开发出来的版本进行最基础的功能的测试（验证），如果结果没问题冒烟通过，否则冒烟不通过让开发重新出版本。（进行1—2天）

4 软件测试质量模型

软件测试质量模型是评估软件产品质量的框架，衡量一个优秀软件的维度

  1. 功能性：软件是否满足需求规格说明中定义的功能。
  2. 性能效率：系统在特定条件下的响应时间、资源利用率等。
  3. 兼容性：与其他系统或环境的协同能力。
  4. 易用性：用户界面的友好性和学习成本。
  5. 可靠性：在特定条件下维持预期性能的能力。
  6. 安全性：防止未授权访问和数据泄露的能力。
  7. 可维护性：代码易于修改和扩展的程度。
  8. 可移植性：在不同环境中部署和运行的适应性。

5、示例：花瓶设计测试用例

提示：参考质量模型

用例编号用例标题项目/模块优先级前置条件操作步骤测试数据预期结果
flower_001花瓶装水功能花瓶功能P0花瓶完整无损，无明显裂纹1、向花瓶中注入500ml清水；2、观察花瓶是否漏水500ml清水花瓶无漏水现象，盛水后保持稳定
flower_002花瓶插画功能花瓶功能P0花瓶已盛水、花枝已修翦1、将10枝玫瑰花插入花瓶；2、察花瓶稳定性及花枝固定情况10枝玫瑰花花枝能稳定插入，花瓶不倾倒
flower_003花瓶容量测试花瓶性能P1花瓶完整，无破损情况1、用标准量杯测量花瓶的最大盛水量；2、产品标称容量对比标准量杯实际盛水量与标称容量误差在±5%以内
flower_004花瓶与花材兼容性花瓶兼容性P2花瓶已盛水1、将不同材质花材（塑料花、真花、干花）插入花瓶；2、观察花材固定情况塑料hua、真花、干花各5枝所有花材均能稳定插入，不导致花瓶倾斜
flower_005花瓶清洗便利性花瓶易用性P2花瓶内有花泥残留1、使用标准清洗工具清洗花瓶；2、记录清洗所需时间和难度标准清洗工具 套装清洗过程顺畅，5分钟内可完成彻底清洗
flower_006花瓶日常使用稳定性花瓶可靠性P0花瓶已盛水并插花1、模拟日常使用 场景（如轻触花瓶；2、观察花瓶稳定性模拟日常使用场景花瓶在轻触下不倾倒，保持稳定
flower_007花瓶边缘安全性花瓶安全性P0花瓶完整无损用标准安全测试工具测量花瓶边缘锐度；2、评估是否可能划伤安全测试工具花瓶边缘钝化处理，无明显锋利点
flower_008花瓶抗摔性测试花瓶可靠性P1花瓶完整无损从70cm高度（模拟桌面高度）自由落体至硬质地板（如木地板）70cm高度桌子花瓶无明显破损或裂纹，可继续使用
flower_009花瓶清洁难度花瓶可维护性P2花瓶内有花泥残留1、标准清洗流程清洗花瓶；2、评估清洗难度标准清洗流程花瓶内壁无残留，清洗难度低
flowe_010花瓶环境适应性花瓶可移植性P2花瓶已盛水并插花1、将花瓶从客厅移动到卧室；2、观察花瓶稳定性及花材情况客厅——>卧室移动路径花瓶在移动过程中不倾倒，花材不掉落
posted @ 2026-04-18 20:55  Freya·Rowena  阅读(0)  评论(0)    收藏  举报  来源