题型

题型 数量 分值 说明
单选题 一个选项正确
多选题 正确选项的个数从 2 个到 4 个不等
填空题
判断题
简答题 设计测试用例

复习提纲

  1. 第 1 部分：绪论

    • 本部分旨在为大家介绍软件测试和质量相关的几个核心概念：绪论。
    • 请围绕软件测试的目的和意义、软件缺陷的定义、测试用例的定义、软件质量的定义这几方面着重了解。

  2. 第 2 部分：测试技术

    • 本部分旨在为大家介绍软件测试领域两类核心的测试方法，分别是黑盒测试技术和白盒测试技术，
    1. 黑盒测试技术
      • 黑盒测试技术分别讨论了：边界值测试、等价类测试、场景法、决策表测试、组合测试这几种测试方法。请大家从两方面进行复习：
      • （1）注重每种方法本身。请大家基于黑盒测试用例评价原则，对照所讨论的案例，重点理解每种测试方法的原理图、测试用例设计。
      • （2）注重方法之间的关联和区别。例如，从应用角度而言，边界值测试、等价类测试、决策表测试、组合测试主要围绕数据的优选设计测试用例，而场景法主要围绕业务流程的优选设计测试用例。例如，从约束条件而言，边界值测试、等价类测试不考虑到输入条件之间的关联，而决策表测试则能考虑到输入条件之间的关联。更多比较，请大家自行分析。
    2. 白盒测试技术
      • 白盒测试技术分别讨论了：对判定的测试、对路径的测试、静态白盒测试这几方面内容，请大家从如下方面展开复习：
      • （1）注重每种方法本身。请大家基于覆盖标准的角度，对照所讨论的案例，重点理解每种测试方法的原理图、测试用例设计。核心是：每种方法都有对应的一组覆盖标准。
      • （2）注重方法之间的关联和区别。例如，从是否执行程序的角度而言，对判定的测试、对路径的测试是从动态测试的角度设计测试用例，而静态表盒测试是从静态测试的角度设计测试用例。例如，对路径的测试与场景法都是针对动态执行流程来测试，只不过侧重点不同，前者侧重程序代码，后者侧重业务流程。更多比较，请大家自行分析。

  3. 第 3 部分：测试管理及工具

    • 本部分旨在为大家介绍测试管理的基本思想，以及与测试流程相关的几种典型的测试工具。

    1. 测试管理及其工具

      • 该节分别讨论了测试用例管理、缺陷管理及测试管理工具 TC。

      • 请大家重点理解如下内容：

        （1）测试用例管理要解决什么问题，如何记录测试用例；

        （2）缺陷管理要解决什么问题，如何记录和管理缺陷；

        （3）对整个测试进行管理要解决哪些问题。

        请大家无需刻意去记的内容是：有关 TC 工具的具体操作细节。

    2. 功能测试及性能测试

      • 从测试流程来说，测试一般按照单元测试->功能测试->性能测试的流程展开对软件产品的测试工作。本节分别以 AR 功能测试工具和 PR 性能测试工具为例，讨论了功能测试基本思想关键问题。

      • 请大家重点理解如下内容：

        （1）为什么需要功能测试工具；

        （2）自动化功能测试有哪些典型的技术；

        （3）自动化功能测试有哪些方面的需求。

        请大家无需刻意去记的内容是：有关 AR 和 PR 工具的具体操作细节。

    3. 单元测试及其工具

      • 本节分别以 Junit 和 CA 工具为例，讨论了单元测试中动态测试和静态测试两方面内容。
        请大家重点理解如下内容：

        （1）单元测试的目的是什么；

        （2）单元测试脚本的需求是什么；

        （3）基于 JUnit 可以实现哪些测试需求；

        （4）如何基于 JUnit 编写单元测试脚本，以满足对脚本的基本需求。

        请大家无需刻意去记的内容是：有关 CA 工具的具体操作细节。

  4. 第 4 部分：软件质量模型及度量

    • 本部分旨在为大家介绍软件质量模型的基本思想，以及常见的度量指标和工具。
      请大家重点理解如下内容：

（1）McCall 质量模型的基本思想；

（2）McCall 质量模型的 11 个质量因素；

（3）其他典型质量模型的基本特点。

复习

绪论

==测试的目的和意义==

1
软件测试的首要目的不是要发现缺陷，而是要确保被测系统满足需求。

==软件缺陷的定义==

1
2
3
4
5
软件未达到需求规格说明书中指明的功能，则是缺陷。
软件未达到需求规格说明书中指明的功能，则是缺陷。
软件出现了需求规格说明书中指明不会出现的错误，则是缺陷。
软件功能超出需求规格说明书中指明的范围，则是缺陷。
软件未达到需求规格说明书中虽未指出但应达到的目标，则是缺陷。

==测试用例的定义==

1
2
3
4
基于风险最低、效率最高、分而治之的测试设计原则
能代表需求的小的测试单元
描述用户预期输出
反映系统实际执行结果

==软件质量的定义==

1
2
3
4
软件产品中能满足给定需要的性质和特性的总体。
软件具有所期望的各种属性的组合程度。
顾客和用户觉得软件满足其综合期望的程度。
确定软件在使用中将满足顾客预期要求的程度。

黑盒测试技术

边界值测试

等价类测试

场景法

决策表测试

组合测试

白盒测试技术

对判定的测试

对路径的测试

环复杂度的确定

  1. 直观观察法

    V=5

    • 流图中的区域数等于环形复杂度。

  2. 公式计算法

    V(G) = e-n+1

    • E是流图中边的条数，N是结点数。

    • 程序图中无孤立节点

    • 程序图是强连通图

  3. 判定节点法

    V=P+1

    • P是流图中判定结点的数目。

    • 仅计算两分支的判定节点

静态白盒测试

测试管理及其工具

==测试用例管理要解决什么问题，如何记录测试用例；==

1
2
3
4
5
6
谁
在什么条件下
对什么进行测试
如何进行测试
依据的需求是什么
与其他测试用例有何关联
1
2
3
4
5
6
7
8
9
10
ID
责任人
被测对象
测试需求
预置条件
参考文档
测试环境
输入和预期输出
优先级
与其他测试用例的关联

==缺陷管理要解决什么问题，如何记录和管理缺陷；==

1
是在软件生命周期中识别和管理缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。
  1. 测试人员负责的内容（新建）
    • 第1部分：基本信息
      • 描述：被测对象、责任人、测试用例
    • 第2部分：核心信息
      • 描述：怎样的条件下，如何操作，出现什么缺陷，基本属性如何
    • 常见的缺陷类型
      • 功能性缺陷、性能缺陷、设计缺陷、接口缺陷、逻辑缺陷、计算缺陷、数据缺陷、用户界面缺陷、文档缺陷、配置缺陷、环境缺陷、兼容性缺陷等等
  2. 测试经理/项目经理负责的内容
    • 指定缺陷处理优先级和分配缺陷处理责任人
  3. 程序员负责的内容
    • 描述：解决方案
    • 常见的缺陷处理方式
      • 已修复(Fixed)
      • 暂缓(Postponed或Later)
      • 外部原因(External或Onhold)
      • 不修复(Don’tfix)
      • 重复的(Duplicate)
      • 不可重现(Notrepro)
      • 符合设计(Bydesign或Notabug)
    • 描述：修复详情
  4. 测试员负责的内容（复审）
    • 描述：缺陷是否正确的修复

==对整个测试进行管理要解决哪些问题。==

功能测试及性能测试

==为什么需要功能测试工具；==

==自动化功能测试有哪些典型的技术；==

  • 录制/回放技术
    • 测试过程：
      • 自动录制手工操作，转化为测试脚本；
      • 通过在脚本中插入指令来设置校验点；
      • 测试工具通过读取脚本，执行插入的指令，并根据脚本的设置重复执行指定的测试用例
    • 优势
      • 快速得到可回放的测试比较结果
      • 自动生成可直接使用的测试脚本
      • 自动准备测试数据
      • 回归测试中可准确重复执行指定测试用例
  • 脚本技术
    • 具有与一般编程语言非常类似的语法结构，
    • 多为解释型语言，可以方便地在IDE中对脚本进行编辑和修改。
    • 脚本技术提供的常见功能
      • 支持多种常用变量和数据类型。
      • 支持数组、列表、结构和其他混合数据类型。
      • 支持各种条件逻辑和循环结构。
      • 支持函数的创建和调用。
      • 支持文件读写和数据源连接。

==自动化功能测试有哪些方面的需求。==

单元测试及其工具

==单元测试的目的是什么；==

1
发现设计或实现中的逻辑错误，及早暴露代码中的缺陷，便于问题的定位和解决。

==单元测试脚本的需求是什么；==

==基于 JUnit 可以实现哪些测试需求；==

==如何基于 JUnit 编写单元测试脚本，以满足对脚本的基本需求。==

软件质量模型及度量

==McCall 质量模型的基本思想；==

  • 用户不了解软件内部实现细节，但用户了解自己的需求
  • 用户从外部视角定义和描述软件（Specify）
  • 开发人员从内部视角构建软件属性（Build）

==McCall 质量模型的 11 个质量因素；==

  • 产品修改（Product revision）

    • 可维护性 Maintainability

      为修复软件在运行中出现的新错误或缺陷，以及为满足环境发生变化或用户提出新需求而对已投入运行的软件系统进行相应的诊断、修改、理解和完善所需要的工作量的大小。

      • 简单性 Simplicity
      • 简洁性 Conciseness
      • 自描述性 Self-descriptiveness
      • 模块性 Modularity

    • 灵活性 Flexibility

      修改或改进一个已投入运行的软件所需工作量的大小。

      • 可扩展性 Expandability
      • 通用性 Generality
      • 自描述性 Self-descriptiveness

    • 可测试性 Testability

      为了确保一个软件系统能够执行预定功能而对其进行测试所需工作量的大小。

      • 简单性 Simplicity
      • 工具性 Instrumentation
      • 自描述性 Self-descriptiveness
      • 模块性 Modularity

  • 产品移植（Product transition）

    • 可移植性 Portability

      将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需工作量的大小。

      • 机器独立性 Machine independence
      • 软件系统独立性 Software-system independence
      • 自描述性 Self-descriptiveness

    • 可重用性 Reusability

      一个软件（或软件的部件）能再次用于其他应用（该应用的功能与此软件或软件部件的所完成的功能有关）的程度。

      • 通用性 Generality
      • 模块性 Modularity
      • 机器独立性 Machine independence
      • 软件系统独立性 Software-system independence
      • 自描述性 Self-descriptiveness

    • 可互操作性 Interoperability

      连接一个软件和其他系统所需工作量的大小。

      • 模块性Modularity
      • 通信通用性 Communication commonality
      • 数据通用性 Data commonality

  • 产品运行（Product operation）

    • 正确性 Correctness

      在预定环境下，软件满足需求规格说明及用户预期目标的程度，要求软件本身没有错误。

      • 可追溯性 Traceability
      • 完备性 Completeness
      • 一致性 Consistency

    • 完整性 Integrity

      为某一目的而保护数据，避免它受到偶然的或有意的破坏、改动或遗失的能力。

      • 访问控制 Access control
      • 访问审查 Access audit

    • 可靠性 Reliability

      软件按照设计要求，在规定时间和条件下不出故障，持续运行的程度。

      • 精度 Accuracy
      • 容错性 Error tolerance
      • 一致性 Consistency

    • 效率 Efficiency

      为了完成预定功能，软件系统所需的计算机资源的多少。

      • 运行效率 Execution efficiency
      • 存储效率 Storage efficiency

    • 可用性 Usability

      对于一个软件系统，用户学习、使用软件以及为程序准备输入和解释输出所需工作量的大小。

      • 可操作性 Operability
      • 训练性 Training
      • 通信性 Communicativeness

==其他典型质量模型的基本特点。==

Boehm质量模型

  • 软件总体实用性
    • 可移植性
      • 设备独立性
      • 自包含性
    • 可使用性
      • 可靠性
        • 自包含性
        • 准确性
        • 完备性
        • 完整性
        • 一致性
      • 效率
        • 可说明性
        • 设备效率
        • 可访问性
      • 人机界面
        • 完整性
        • 通信性
        • 自描述性
    • 可维护性
      • 可测试性
        • 可说明性
        • 可访问性
        • 通信性
        • 自描述性
        • 结构化性
      • 可理解性
        • 一致性
        • 自描述性
        • 结构化性
        • 易读性
      • 可修改性
        • 结构化性
        • 可扩充性

ISO9126质量模型

  • 使用质量模型
    • 有效性
    • 生产率
    • 安全性
    • 满意度
  • 外部和内部质量模型
    • 功能性
      • 适合性
      • 准确性
      • 互操作性
      • 安全保密性
    • 可靠性
      • 成熟性
      • 容错性
      • 易恢复性
    • 易用性
      • 易理解性
      • 易学性
      • 易操作性
      • 吸引性
    • 效率
      • 时间特性
      • 资源利用性
    • 维护性
      • 易分析性
      • 易改变性
      • 稳定性
      • 易测试性
    • 可移植性
      • 适应性
      • 易安装性
      • 共存性
      • 易替换性

ISO25010质量模型

  • 外部和内部质量模型

    • 功能适用性
      • 完备性
      • 正确性
      • 适合性
    • 性能效率
      • 时间特性
      • 资源利用性
      • 容量
    • 兼容性
      • 共存
      • 互操作性
    • 易用性
      • 易认知性
      • 易学习
      • 易操作
      • 用户错误保护
      • 用户界面
      • 易掌握
    • 可靠性
      • 成熟性
      • 可用性
      • 容错性
      • 可恢复性
    • 安全性
      • 保密性
      • 完整性
      • 不可否认
      • 责任性
      • 认证
    • 可维护性
      • 模块化
      • 可重用性
      • 易分析性
      • 易修改性
      • 易测试性
    • 可移植性
      • 适应性
      • 易安装性
      • 易替换性

  • 使用中质量模型

    • 有效性
      • 有效性
    • 效率
      • 效率
    • 满意度
      • 有用
      • 可信
      • 有趣
      • 舒适
    • 免于风险
      • 降低经济风险
      • 降低健康和安全风险
      • 降低环境风险
    • 特定环境覆盖
      • 周围环境完备性
      • 灵活性