软件测试-测试分类/用例/报告/框架概述

序言

文章内容如下：测试分类 + 测试用例设计原则 + 测试报告的格式 + 测试框架概况

• 1. 软件测试按项目流程分类

  • 一般来说，测试分为5个阶段： 单元测试 + 集成测试 + 确认测试 + 系统测试 + 验收测试 。在测试过程中如果有需要还要进行回归测试

    • [1] 单元测试：单元就是最小的被测功能模块， 模块测试
    • [2] 集成测试：模块组装成完整的软件系统，排除 接口错误 等
    • [3] 确认测试： 软件 的功能和性能是否如 用户所合理期待 的那样
    • [4] 系统测试：将已确认的 软件、硬件、网络等结合起来 进行 组装和确认测试
    • [5] 验收测试：由用户或者独立的测试人员根据 测试计划和结果 进行 测试和验收

  • 单元测试 的测试对象，目的，测试依据，测试方法

    • 测试对象：模块内部的 程序 ，可能是一个C语言的函数或过程，C++的一个类等
    • 目的：消除模块的 逻辑 和 功能 缺陷
    • 测试依据：模块的详细设计（比如模块设计文档）
    • 测试方法： 白盒测试

  • 集成测试 的测试对象，目的，测试依据，测试方法

    • 测试对象：模块间的 组装 和 调用 关系
    • 目的：找出模块 调用 和模块 接口 方面的问题
    • 测试依据：概要设计（如模块间的通信要求等）
    • 测试方法： 灰盒测试

  • 系统测试 的测试对象，目的，测试依据，测试方法

    • 测试对象： 整个系统
    • 目的：找出 系统与需求不符合 的地方
    • 测试依据： 需求规格说明书
    • 测试方法： 黑盒测试

  • 验收测试 的分类

    • [1] 非正式验收测试

      • α测试： 内测 。由用户、测试人员、开发人员共同参与的内部测试
      • β测试：内测后的 公测 。即完全交给最终用户测试

    • [2] 正式验收测试

• 2. 按测试工作对代码的可见程度分类

  上面讲的单元测试、集成测试、确认测试、系统测试和验收测试，是从 项目开发流程 来进行划分的，如果从 测试工作对代码的可见程度 来划分，可将软件测试划分为：

  • [1] 黑盒测试

    • 黑盒测试，指的是把被测的软件看作是一个黑盒子，我们 不去关心盒子里面的结构 是什么样子的，只关心软件的输入数据和输出结果

    • 黑盒测试也称为 功能测试 、 数据驱动测试 、或 基于规格说明书的测试 ，是一种从用户观点出发的测试

    • 主要检测的错误类型有：

      • 不正确或遗漏的功能 + 接口界面错误 (能否正确输入正确输出) + 性能错误 (性能能否满足要求) + 数据结构或外部数据访问错误 + 初始化或终止条件错误

    • 常用的黑盒测试方法：

      • 等价类划分法 + 边界值分析法 + 因果图法 + 场景法 + 正交实验设计法 + 判定表驱动分析法 + 错误推测法 + 功能图分析法 。

  • [2] 白盒测试

    • 白盒测试，指的是把盒子盖子打开，去研究 里面的源代码和程序结果 。按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作

    • 白盒测试也称为 结构测试 、 透明盒测试 、 逻辑驱动测试 或 基于代码的测试

    • 白盒测试需要遵循的原则：

      • (1) 保证一个模块中的所有独立路径至少被测试一次 ；
      • (2) 所有逻辑值均需要测试真（true）和假（false）两种情况 ；
      • (3) 检查程序的内部数据结构，保证其结构的有效性 ；
      • (4) 在上下边界及可操作范围内运行所有循环 。

    • 白盒测试的主要方法有：

      • 静态测试&动态测试 + 单元测试 + 代码检查 + 同行评审 + 技术评审
      • 静态测试和动态测试 ：静态测试是不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。动态测试则需要执行代码，也是我们用的最多的一种测试，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

  • [3] 灰盒测试

    • 灰盒测试更像是白盒测试和黑盒测试的 混合测试 。更多时候测试做的就是灰盒测试，既有白盒测试也有黑盒测试
    • 灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取灰盒的方法。

• 3. 按使用的测试方法分类

  • [1] 手工测试

    • 由人去执行测试用例，观察返回结果是否符合预期

  • [2] 自动化测试

    • 把人为驱动的测试行为转换为机器执行。
    • 自动化测试又可分为： 功能自动化测试 + 性能自动化测试
    • (1) 功能自动化测试 ：一般所说的自动化测试就是指功能自动化测试。用一段程序来测试软件功能，重复执行进行重复测试，如果软件发生小部分改动，只需要改动小部分测试代码，就可继续对软件进行功能测试
    • (2) 性能自动化测试 ：现在的性能测试工作都是通过 性能测试工具 辅助完成的。测试工具可以模拟成千上万的用户向系统发送请求，用来验证系统的处理能力。

• 4. 性能测试的分类

  • [1] 性能测试
  • [2] 负载测试：在 一定的工作负荷 下，系统的负荷及响应时间
  • [3] 容量测试：系统在其 极限值状态 下没有出现任何软件故障或还能保持主要功能正常运行
  • [4] 压力测试：确定系统瓶颈的测试
  • [5] 强度测试：对异常情况的抵抗能力

  压力和强度测试通常与性能测试结合进行。

  针对一个网站进行测试，模拟10到50个用户就是在进行常规 性能测试 ，用户增加到1000乃至上万就变成了 压力/负载测试 。如果同时对系统进行大量的数据查询操作，就包含了 强度测试 。

• 5. 设计测试用例最重要的原则

  • 准确性 ：准确对应需求来设计测试用例
  • 完整性 ：完整覆盖应有的功能需求
  • 可重复性 ：测试用例应该是可重复的，排除测试情形的特殊性
  • 独立性 ：一个测试用例最好能独立运行，不依赖于其他测试用例的输出结果

  除了上述原则，还有其他一些原则比如：

  • 经济性：测试没有冗余步骤
  • 可追踪：测试用例应该追溯到具体需求
  • 自我清理：测试结束后，恢复到原有干净的状态，不应该对原有系统造成影响
  • 结构化和可测试性：测试用例应该是结构化。一般可以根据一个横向维度，对测试用例进行 功能模块 的划分；同时纵向维度上可以根据 测试类别 对测试用例进行纵向结构的划分。测试同时应该是可测试性的。对于无法执行的测试用例是没有意义的。
  • 规范性：包含测试用例的说明-命名、环境、步骤、结果等必要说明
  • 简洁性：尽量简洁，精悍，执行时间不要过长，粒度不要太大（大型系统不太适用）
  • 有效性：测试用例是否符合商业用例

• 6. 测试报告包括哪些内容

  测试报告的通常阅读者：开发人员、测试经理、产品经理、项目负责人

  不同人员有不同的阅读需求：

  开发人员往往希望能从报告中了解缺陷的情况

  测试经理还关心用例的执行情况及覆盖率

  项目责任人则最关心还有多少问题、此次版本是否测试通过

  测试报告有：功能测试报告，性能测试报告，兼容性测试报告等

  功能测试报告 根据内容的侧重点，分为 版本测试报告 和 总结测试报告

  • [1] 版本测试报告 的主要内容

    • 测试简介：测试目的，测试消耗的资源
    • 测试环境：软硬件环境，系统拓扑图等
    • 测试方法
    • 测试用例：用例分析，用例执行情况
    • 测试过程：缺陷统计，问题摘要
    • 测试结果：资源占用，测试结论(详细数据支持)
    • 备注：用例执行记录，资源监控记录等

  • [2] 总结测试报告 的主要内容

    • 测试简介：条目同上
    • 测试环境：条目同上
    • 测试过程：各版本测试状况，各版本bug统计
    • 测试分析：缺陷分析，遗留问题
    • 测试小结：资源占用，风险分析等

• 7. 对测试框架的了解

四种常用的测试框架： 数据驱动测试框架 + 测试脚本模块化框架 + 测试库架构框架 + 关键字驱动测试框架

• [1] 数据驱动测试框架：

  • 所有测试框架中最简单的一种。

  • 数据驱动测试是测试从数据文件（数据池，ODBC源，cvs文件，Excel文件，DAO对象等）中读取输入和输出数值并载入到捕获的或手工编码的脚本中变量里的一种框架。将测试数据从测试脚本中分离出来。

  • 优点 ：

    • 至少测试数据可以单独维护了
    • 可以快速增加相似测试，测试者增加新的测试不必掌握测试工具语言

  • 缺点 ：

    • 维护成本非常高。任何测试程序的变更所导致的工作量是所有测试框架中最多的

• [2] 测试脚本模块化框架

  • 测试脚本模块化框架应用了抽象或封装的原则。

  • 测试脚本模块化框架需要创建能够代表测试下应用程序（application-under-test）的模块，零件（section）和函数的小的、独立的 脚本 。然后用一种 分级 的方式将这些小脚本组成更大的测试，实现一个特定的测试用例。

  • (1) 测试数据由测试工程师负责

  • (2) 测试脚本由自动化工程师负责维护，必须懂业务逻辑

  • 优点 ：

    • 控件和业务逻辑一旦发生变化，要进行修改和维护的是底层的 测试脚本 （比无任何抽象封装的自动化测试程序稍好一些）

  • 缺点 ：

    • 控件识别和业务逻辑本身属于不同的领域，没有很好进行抽象封装
    • 几乎所有大的变更引起的工作量都由自动化测试开发工程师完成

• [3] 测试库架构框架

  • 测试库构架框架和测试脚本模块化框架非常相似，有着同样的优势，但是它把测试下的应用程序分成过程和函数，而不是脚本。

  • 这种框架要求创建代表测试下应用程序模块，零件和函数的库文件（SQABasic libraries, APIs, DLLs等等）。然后这些库文件被测试用例脚本直接调用。

  • (1) 测试数据由测试工程师负责

  • (2) 测试脚本由自动化工程师负责，必须懂业务逻辑

  • (3) 测试库由自动化工程师负责，无须懂业务，负责控件的维护

  • 优点 ：

    • 完成了 控件识别操作 和 业务逻辑 的抽象分离
    • 被测试系统无论是哪层发生变化，只需要相应的人员进行变更维护即可

  • 缺点 ：

    • 变更引起的工作量还是附加在自动化测试开发工程师身上

• [4] 关键字驱动测试框架/表格驱动测试

  • 关键字驱动和表格驱动测试是一种独立于应用程序的自动化框架，它们是可以互相替换的术语。这种框架要求开发于用来运行的自动化工具，驱动测试下应用程序和数据的测试脚本代码相独立的数据表和关键字。关键字驱动测试看上去非常象手工测试。在关键字测试里，应用程序的功能特性被写在表格和每个测试的详细指引里了。

  • 控件和业务逻辑以关键字的形式在EXCEL里面进行调用，普通的测试工程师不需要了解 框架 和 工具 的知识就能维护好控件和业务逻辑

  • 优点 ：

    • 极大的减少了自动化开发工程师维护量，毕竟在测试团队中，自动化开发工程师占的比较少
    • 普通测试工程师，可以很好的维护自身负责的模块中涉及的测试case和测试数据

  • 缺点 ：

    • 框架的抽象程度比较高，对自动化测试工程师的开发能力比较高

以上测试框架图可参考博客：

除了上述四种测试框架，可能还有 混合的测试自动化框架

• [5] 混合的测试自动化框架

  • 最常见的已实现的框架是上述技术的组合，抽取它们的优点，剔除其弱点。这种混合的测试自动化框架是发展时间较长且应用项目最多的框架

Acknowledgements :

2017.09.26