软件测试理论

曾经在B站看过一系列软件测试的基础理论，在这里记录下，共同学习

---

计算机软件分类

• 按照层次划分
  • 系统软件
  • 支持软件
  • 应用软件
• 按结构划分
  • 单机软件
  • 分布式软件 C/S B/S

  C/S: 客户端--服务器，B/S: 浏览器--服务端

• 按照组织划分
  • 开源软件
  • 商业软件

计算方式: 网格计算(地图)、云计算

软件缺陷由来

• bug: 一只虫子的由来
• defect(缺陷)

软件缺陷：

• 软件未能实现产品说明书的功能
• 软件出现了产品说明书指名的不应该实现的功能
• 产品软件实现了产品说明书未能提到的功能
• 软件未实现产品说明书虽未明确提及但应该实现的目标
• 软件难以理解、不易使用、运行缓慢或者(从测试角度看)用户体验不佳

所有不满足需求或者超出需求的都是缺陷
没有不存在缺陷的产品，只有没有发现的缺陷

概述 源于上世纪70th

• 《测试数据选择的原理》
• 《软件测试的艺术》
• 软件质量保证部门： QA(质量保证)、QC(质量控制)、SQA

软件测试国内外现状

正向思维(开发思维)

确信自己产品不存在问题

逆向思维

• Glenford.j.Myers
• 测试是为了发现错误而执行一个程序或者系统的过程
  • 测试时证明程序有错，而不是证明程序无措
  • 一个好的测试用例在于它发现以前未发现的错误
  • 一个成功的测试是发现了以前未发现的错误的测试

IEEE定义的测试

• 在规定条件下运行系统或构建的过程：观察和记录结果，并对系统或者构建的某些方便给予评价
• 分析软件项目的过程： 检测现有状况和所需状况之间的不同，并且评估软件项目的特征

广义软件测试

• 软件测试是对软件形成过程中的所有工作产品(包括程序以及相关文档)进行的测试
  而不仅仅是对程序的运行进行测试
  • 验证
    通过检查和提供客观证据来证实指定的需求是否满足
  • 确认
    通过检查和提供客观证据来证实特定目的的功能或者应用是否实现

软件测试的目的

• 以最少的人力、物力和时间找出软件中存在的各种错误缺陷，
  通过修正各种错误和缺陷保证软件质量，避免软件发布后由于潜在各种软件错误和缺陷造成的隐患所带来的
  商业风险。同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入
  避免在将来的项目开发和测试中重复同样的错误；采用更高效的测试管理手段，提高软件测试的效率和软件产品的质量
• 测试需要保证以下两点: 程序做了它应该做的事以及没做它不应该做的事。

• 软件测试的目的是尽可能早的找出软件产品中潜藏的缺陷，并确保其得以修复
• 软件测试仅仅只是软件质量保证的重要手段之一，而真正提高软件产品质量，需要持续不断的过程改进。(开发的事)

测试和调试的区别

• 目标、方法、思路都不同
• 测试是从已知的条件开始的，使用预先定义的过程，并且有预期结果；调试是从未知的的条件开始结束过程可能无法预计
• 测试可以计划，可以预先制定测试用例和过程，工作进度可以度量；描述调试的过程或者持续时间相对比较困难
• 测试对象包括软件开发过程中的文档、数据以及代码、而调试的对象一般来说只是代码。

软件的定义

• 程序
• 数据
• 结构

软件工程

软件工程包括两个方面： 软件开发技术和软件项目管理。其中，软件开发技术包括软件开发方法学、软件工具盒软件工程环境。

软件项目管理包括软件质量、项目评估、进度控制、人员组织、配置管理、项目计划等。

• 引起软件危机的主要问题是软件质量问题。软件工程主要解决的就是软件质量问题。而软件测试是软件质量管理体系中一个非常重要的手段。
• 类比: 在软件生产过程中，项目经理、软件开发工程师、软件测试工程师师最基本的三个角色。就像建筑工程里的项目经理、建筑师(含建筑工人)
  、项目监理之间的关系。

软件生命周期

1、立项--需求分析--设计、编码、测试--发布--运行维护--淘汰

2、详细：软件立项--可行性研究--需求分析--概要设计--详细设计--编码实现--单元测试--集成测试--系统测试--验收测试--运行维护

3、软件开发过程：需求分析--系统设计--编码&测试--用户验收--上线维护

• 瀑布模型: 上一个阶段的工作输出是下一个阶段的工作输入，缺点是测试介入时间太短，不支持迭代
• 快速原型模型：迅速建造一个可运行的软件模型，便于理解和澄清，使得开发与客户达成共识。
• 增量模型 (常用)：
  • 增量模型是把待开发的软件模块化，将每个模块作为一个增量组件，从而分批次的分析、设计、编码和测试这些增量组件
  • 开放不需要一次性把整个软件产品交给用户，而是可以分批次进行提交
  • 优点
    • 模块化
    • 降低开发风险
    • 开发顺序灵活
  • 限制：
    • 要求管理人员把握全局水平较高
• 迭代模型：
  • 迭代包括产生产品发布(稳定、可执行的版本)的全部开发活动和要使用该发布必须的所有其他外围元素
  • 某种程度上，开发迭代是一次完整经过所有工作流程的过程: 需求分析、程序设计、实施、测试
  • 优点
    • 降低在一个增量上的开支风险
    • 降低了产品无法按照既定进度进入市场的风险
    • 加快整个开发进度
    • 适应需求变化容易
• 敏捷模型
  • 轻文档
  • 无界限
• 螺旋模型

软件测试概述

标准的测试过程至少包括以下：需求分析--测试计划--测试设计--测试执行--测试总结

1、V模型

• 揭示了开发过程与测试过程中各阶段的对应关系，通过开发和测试同时进行的方式来缩短周期，提高开发效率
  • 缺点与不足
    • 仅仅把测试过程作为在需求分析、系统设计以及编码后的一个阶段，忽略了测试对需求分析，系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
    • 没有体现 尽早的和不断地进行软件测试 的原则
    • 不支持迭代

V模型

上图左右对应

2、W模型

• 由两个V组成，分别代表测试与开发过程，明确的表示了测试与开发的并行关系

• 测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试

  
  
  W模型

3、H模型

• 相对于V和W模型，H模型将测试活动完全独立出来了，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰的体现出来
• 途中标记的其他流程可以是任意开发流程，只要测试条件成熟了，测试准备活动完成了，测试活动就可以进行了。
• 支持迭代(好的模型)
• 早准备早执行

• 为了能够对开发过程进行测试，应当采用的测试过程模型为 W+H

  
  
  H模型

4、X模型

X模型

软件测试管理理念

• 尽早测试
  • 测试人员早起参加软件项目，及时开展测试的准备工作，包括编写测试计划、制定测试方案以及准备测试用例
  • 尽早的开展测试执行工作，一旦代码模块完成就应该及时开展单元测试，一旦代码模块被集成成相对独立的子系统，便可以开展集成测试
  • 旦有BUILD提交，便可以看展系统测试工作
• 全面测试
  • 对软件的所有产品进行全面的测试，包括需求、设计文档、代码，用户文档等。
  • 软件开发及测试人员(有时包括用户)全面的参与到测试工作中。
• 全过程测试
  • 测试人员要充分关注开发过程，对开发过程的各种变化做出响应。
  • 测试人员要对测试的全过程进行跟踪。
• 独立、迭代测试
  • 测试活动是迭代的
  • 应当将测试过程从开发过程中适当的抽象出来，作为一个独立的过程进行管理

测试方法

单元测试

• 说明：单元测试又称模块测试，是针对软件设计的最小单位--程序模块进行正确性验证的测试过程，其目的在于检查每个程序单元是否能够正确实现设计模块中的
  模块功能、性能、接口和设计约束等要求，发现各模块可能存在的各种错误。单元测试需要从程序内部结构出发设计用例。多个模块可以平行的
  进行单元测试。
• 逻辑结构和代码功能

集成测试

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

确认测试

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

系统测试

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

验收测试

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

黑盒测试

• 说明：通过软件表现来发现缺陷和错误，不关注程序内部结构和处理过程。程序界面处进行测试，他只是检查样序是否按照规格说明书来。只关注输入输出。

白盒测试

• 通过对程序内部结构分析、检测来寻找问题。也称结构测试

灰盒测试

• 介于黑盒白盒之间的测试。关注输出对于输入的正确性；同时也关注内部表现，但是不会很详细，只是通过表象、事件、标志来判断内部运行状态。
• 同时考虑了用户端、特定的系统知识和操作系统。它在系统组件的协同性环境中评价应用软件设计

静态测试

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

动态测试

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

功能测试

• 是黑盒测试的一方面，检查实际软件功能是否满足客户需求
  • 逻辑功能测试
  • 界面测试
  • 易用性测试
  • 安装测试
  • 兼容性测试
  • 。。。

性能测试

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

回归测试

• 指新版本测试前，重复执行之前某一个重要版本的所有测试用例
• 目的：
  • 验证之前版本的缺陷是否全部被修复
  • 确认修复缺陷没有引发新的缺陷

冒烟测试

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

随机测试

• 随意性测试，指测试人员基于经验和直觉的探索性测试，目的是模拟用户的真实操作，并发现一些边缘性错误

测试原则

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

测试计划编写(5W1H)

• what、why、who、where、when、how

制定测试目标从以下几个方面着手

• 理解系统
• 及早介入
• 理解企业文化和过程
• 测试期望
• 吸取教训
• 工作量大小
• 解决方案的类型
• 技术选择
• 预算
• 时间表
• 分阶段解决方案