软件测试定义

• 什么是软件测试
  • 使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
  • 软件测试就是“验证”和“确认”活动构成的整体。
• 软件测试的作用
  • 验证软件需求和功能是否得到完整实现
  • 验证软件是否可以发布
  • 使用发现软件系统的缺陷、错误及不足
  • 获取软件产品的质量信息
  • 预防下一版本可能出现的问题
  • 发现开发过程中存在的问题和风险
  • 提供可以用以分析的测试结果数据

软件质量保证

• 软件质量评价标准（从哪些方面评价）

  • 功能性
  • 性能
  • 兼容性
  • 配置性
  • 安全性
  • 健壮性
  • 界面

• McCall 模型中产品运行（作业中的测试需求题目中列举的）

  • 给生活中任意的东西（生活用品 或软件）的功能描述，写出可以从哪些方面对软件质量进行测试

• 测试不能保证软件质量（背）

  • 无法执行所有测试

  • 测试是有风险的工作

  • 测试这只能证明程序有错，不能证明程序正确

    软件测试只是质量保证活动中的一个重要环节，而不是唯一环节，提高软件质量不是依靠更多的测试，而是更好的开发

  考察方式：

  1. 软件测试能保证软件质量吗？
  2. xxx保证他测过的软件一定质量很高，不会有问题，这话对不对？

软件测试流程

• 软件开发的每一阶段都要进行测试
  • 为什么要尽早地进行测试（掌握）
    • 降低项目后期发现严重甚至致命缺陷导致项目失败的风险
    • 降低由于发现缺陷的时间点推迟而导致缺陷修改所增加的项目成本
• 软件测试有几个阶段（软件测试的流程）（背）
  • 计划阶段
  • 设计阶段
  • 开发阶段
  • 执行阶段
  • 评估阶段
• 软件测试的级别（背）
  • 单元测试
  • 集成测试
  • 系统测试
  • 验收测试

软件测试的原则

• 完全测试程序是不可能的

• 软件测试是有风险的行为

  • good enough原则：权衡投入产出比

• 软件测试无法显示潜伏的软件bug（只能证明有错，不能证明没错）

• 并非所有bug都能修复（掌握）

  • 没有足够的时间
  • 不算真正的bug
  • 修复风险太大，可能导致其他bug
  • 不值得修复，不常用的功能，不常出现的bug。

  考察方式：

  1. 给定缺陷描述，问这个缺陷是否值得修改？（一般回答不值得）

  2. 某个企业的软件经常有很多缺陷没有修改，这种做法对不对？

     • good enough原则：满足用户需求

     • 并非所有bug都能修复

• 什么时候停止测试（掌握）

  非技术：

  • 市场压力
  • 客户要求
  • 质量目标
  • 费用约束
  • 时间约束

  技术：

  • 执行了所有测试用例，没有发现缺陷
  • 利用缺陷发现率曲线判断

黑盒测试

• 等价类法

  • 有效等价类
  • 无效等价类

• 边界值法

• 决策表法

  • 等价类和边界值分析法适合输入变量或输入条件相互独立的情况，但是当输入变量或输入条件相互依赖，相互制约的时候，采用等价类划分法和边界值分析方法是难以描述的，测试效果也很难保障

  • 例题：

    设计决策表

    
    

    优化决策表

    

• 例题：先从健壮性角度（边界值，等价类）。再从功能性角度（等价类）

白盒测试

• 设计测试用例的依据
  • 程序内部结构
  • 一定的覆盖要求
• 逻辑覆盖法（从弱到强）
  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 判定/条件覆盖
  • 条件组合覆盖
  • 路径覆盖

静态测试

• 例题：给出测试检查点，指出下列代码存在什么隐患。

• 常用的静态测试方法:

  评审方法：

  • 走查
  • 审查
  • 技术评审

  优点：

  • 达到尽早测试
  • 可以用来测文档
  • 效率最高,发现错误,当场修改

• 数据流分析（掌握）：在程序代码经过的路径上检查数据的用法。

单元测试

• 单元测试的目标

  • 功能性测试
  • 健壮性测试
  • 检查对组件质量重大影响和不能在更高级别测试的非功能特性

• 单元测试的主要任务（背）

  • 模块接口
  • 局部数据结构
    • 数据类型是否合适
    • 变量有无初始化
  • 路径测试
  • 边界条件
    • 检查对数组使用，是否下标越界
  • 出错处理
    • 文件打开：检查文件打开句柄是否为空
    • 申请内存：检查返回值对不对

• 单元测试模型（掌握）

  考察方法：

  1. 语言描述整个模型
  2. 给定一个被测模块（一个函数），设计测试驱动的架构（被测模块中调用的函数用桩模块代替）

  

  • 驱动模块：驱动模块是模拟被测单元的上级模块，用于接收测试数据、启动被测模块和输出结果。
  • 桩模块：对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。

集成测试

• 集成测试的目标
  • 发现被集成单元间接口和相互之间的协作问题
• 集成测试策略
  • 大爆炸集成（一次性集合）
    • 优点：节省时间
    • 缺点：桩和测试驱动器都需要
  • 自顶向下
    • 优点：不需要测试驱动，或者只需要简单的测试驱动
    • 缺点：没有集成的低级别的组件必须用桩代替，成泵较高
  • 自底向上
    • 优点：不需要桩
    • 缺点：必须用测试驱动器模拟更高级别的组件
  • 三明治集成（2和3合起来）
    • 优点：组件可以用任意的顺序集成
    • 缺点：需要一个详细分析的主干和中枢
• 例题：给一个模块的结构图，从上往下用深度优先和广度优先方法写出集成测试过程。

系统测试—测试需求

• （必考）给一个功能描述，从各个角度描述对该软件有哪些测试检查点,对该需求要做哪些系统测试方法。

  • 功能测试

  • 界面测试

    • 文字排列错误
    • 布局错误
    • 链接错误

  • 性能测试（广义）

    • 性能测试（响应速度）
    • 负载测试（并发）
    • 大数据量测试（大容量）

  • 兼容性测试

  • 健壮性测试

  • 安全性测试（是否sql注入，url重放）

  • 配置测试（程序运行的软硬件平台）

• 测试组织架构（掌握）

  • 开发团队开发人员负责测试（只需要知道优点）
    • 优点：开发人员对代码更熟悉，测试效率最高，适合开发节奏快，迭代快的项目
    • 缺点：开发人员测试经验不足
  • 开发团队中有专门测试人员
    • 优点：测试周期短，测试快，开发与测试不存在时间差，开发人员与测试人员沟通方便
    • 缺点：测试人员容易受打击
  • 独立的测试团队
    • 优点：测试很专业，测试经验丰富，开发人员专职开发，开发效率高
    • 缺点：测试人员和开发人员的沟通不方便，开发与测试之间存在时间差，错误反馈不便

  考察方式：

  1. 选择题
  2. 给一个开发现状，对这种开发现状选择哪种模式合适 （根据开发现状 结合 各种架构的优缺点选择一个合适的方法，并给出一两句话的解释说明为什么选这种方法）

• 测试优先级（掌握）

  • 为什么要划分测试优先级

    • 测试时间和资源有限，可能无法执行所有测试用例
    • 首先执行最重要的测试用例，尽可能早的发现重要的和尽量多的缺陷
    • 即视测试过早结束，仍然能够保证在该时刻的测试能达到最佳效果

    考察方式：

    ​ 1. 按测试优先级排列各个功能模块的测试顺序

缺陷管理

• 什么是缺陷

  • 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
  • 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

• 严重性与优先级

  • 严重性：缺陷对软件产品使用的影响程度

    • 致命

    • 严重

    • 一般

    • 较小

  • 优先级：缺陷必须被修复的紧急程度

    • 立即解决

    • 高优先级

    • 正常排队

    • 低优先级

  • 缺陷越严重，越要优先得到修正，缺陷严重等级和缺陷优先级相关性很强

  • 缺陷的严重性和优先级的关系 （掌握）

    • 一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。 但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，例如：有些缺陷比较严重，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

• 缺陷报告（掌握）

  • 组织结构

    • 缺陷的标题
    • 缺陷的基本信息
      • 测试的软件和硬件环境
      • 测试的软件版本缺陷的类型
      • 缺陷的严重程度
      • 缺陷的处理优先级
    • 复现缺陷的操作步骤（测试步骤，测试数据，测试对象要明确）
    • 缺陷的实际结果描述
    • 期望的正确结果描述
    • 注释文字和截取的缺陷图像

  • 考察方式：

    例：
    
    

    • 给一份缺陷报告，描述缺陷报告存在哪些问题
    • 给一段缺陷描述，写一份缺陷报告

缺陷度量

1. 收敛趋势分析（掌握）

   无休止的情况 ：

原因：

• 测试方面：

  • 测试人员测试报告不明确，导致开发人员难以重现缺陷
  • 测试人员对测试的严重性优先级把握不准确。

• 开发方面：

  • 开发人员无法重现错误

  • 开发人员忙于开发，顾不上修改错误

理想状态：

• 当前发现数和关闭数两条曲线已经汇集，并且持续了一段时间，此时的产品质量较稳定，可以批准对外发布

2. 缺陷分布图（掌握）

• 缺陷分布统计的作用：（掌握）
  • 通过缺陷分布图可以了解哪一类缺陷缺陷率高，容易犯哪一类错误
  • 对开发人员：以后做类似开发加强质量控制，避免同类错误发生
  • 对测试人员：下次测同类的时候，知道哪些地方多投入，测试更全面

作业

• 软件测试的目的和被测对象

  • 目的
    • 降低风险
    • 发现缺陷
    • 合同或法律要求，行业标准
    • 为相关干系人的合理决定提供信息
    • 缺陷预防
    • 提高信心
  • 对象
    • 软件开发所涉及的各个阶段文档
    • 源程序

• 程序运行错误一定是代码有问题？如何找到错误？

  • 不一定是代码问题，可能是配置问题 或者兼容性的问题，使用配置测试和兼容性测试，程序代码不变，改变程序运行的软硬件环境进行测试，然后再看程序代码是否还有问题。

• 当测试用例与测试用例中的描述有所不同时，有哪些可能的原因呢？

  • 被测对象运行失效（程序出错）
  • 错误或不精确的测试规格说明（测试操作流程出错）
  • 测试基础设施或测试用例的问题（测试环境与测试软件要求不一致）
  • 不正确的执行过程（操作错误）

• ”越严重的错误越要先修改“ 是否正确？

  • 错误的，错误的严重性并不等同于修复的优先级，先修改的错误应该是优先级高的错误，不一定是最严重的错误，要综合考虑错误的严重性，使用风险，修复成本等因素来确定修改错误的优先级。

• 为了考核测试人员的绩效，某企业测试人员的缺陷数量来衡量该测试人员的工作能力，这样考评是否合理？会造成什么样的后果？

  • 这样的考评是片面的，衡量测试人员的能力不仅仅要看发现的缺陷数量，还要看发现缺陷的严重性，缺陷带来的后果，所测模块的复杂性，质量，所执行的测试类型等来衡量。
  • 会导致测试人员只将关注点放在容易发现的表面的，界面方面的缺陷，不愿意去测不容易重现，深层次的缺陷。还会导致测试工作不好分配。