软件测试复习

发表于 更新于 分类于 阅读次数： Disqus： 本文字数： 17k 阅读时长 ≈ 1:01

软件测试

第一章 概述及基础

对软件测试的理解

  • 正向思维：以功能验证为导向，证明软件是正确的

  • 逆向思维：以破坏性检测为导向，为了找到软件中的错误（发现错误）

  • 软件 = 程序 + 文档

  • 软件测试 ≠ 程序测试

软件测试标准定义：

  • 使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别
  • 软件测试是以检验是否满足需求为目标

对缺陷的理解

Bug：Bug是软件中（包括程序和文档）不符合用户需求的问题

  • 完全没有实现的功能

  • 功能或性能问题或差异

  • 多余的功能

  • 差错Error：计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。

    • 可由系统或组件的内部缺陷（fault）引起。

  • 失效Failure：由于缺陷而导致要素（element）或相关项(item)预期功能的终止。

  • 缺陷Fault：可引起要素（element）或相关项(item) 失效（fail）的异常情况。

    • 当一个子系统处于差错（error）状态时，可能导致系统缺陷（fault）。
      缺陷（fault）可能导致差错（error），差错（error）可能导致缺陷（fault）。

软件质量保证

软件质量保证（Software Quality Assurance，SQA）: 为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。

  • SQA：管理工作，预防问题，侧重对流程的评审和监控
  • ST：技术工作，发现问题，侧重对产品进行评估和验证
  • ST是SQA重要手段之一
  • 充分的测试不能保障软件产品质量，是高质量的必要非充分条件

软件测试的基本原则

软件测试工程的目标：尽可能早地找出软件缺陷，确保其得以修复

  1. 测试应该尽早启动，尽早介入
  2. 测试应该追溯需求
  3. 不可能进行穷尽测试
  4. Zero Bug与Good Enough
  5. 缺陷存在群集现象
  6. 缺陷具有免疫性（杀虫剂悖论）
  7. 不存在缺陷的理论（测试无法显示潜伏的软件缺陷）

软件测试的分类

  • 黑盒测试

    • 功能测试
    • 数据驱动测试

  • 白盒测试

    • 结构测试
    • 逻辑驱动测试

  • 静态测试：不实际运行被测软件，只是静态地检查程序代码、界面或文档中可能存在错误的过程。

  • 动态测试：通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。

不同测试级别的任务：

  1. 实现（编码）：调试
  2. 组件测试：组件功能、健壮性、效率
  3. 集成测试：组件之间的接口
  4. 系统测试：系统功能、安全性、健壮性、效率
  5. 验收测试：功能及用户界面、安全性、效率、用户的可接受性
  • 系统非功能性测试：系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。包括恢复测试、安全测试、强度测试、性能测试。
  • 系统功能测试：功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用。

软件测试的过程模型

软件生命周期（Systems Development Life Cycle, SDLC）：软件开始研制到最终被废弃不用的整个过程。整个生命周期包括问题定义及规划、需求分析、系统设计、软件编程、软件测试、软件维护等阶段。

V模型

与软件开发瀑布模型相对应

局限性：测试是设计及编码之后的一个阶段，需求分析阶段隐藏的问题一直到后期的验收测试才被发现

  • 验证 (Verification)：Are we building the product right？
    • 是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性
  • 确认（Validation）： Are we building the right product?
    • 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求

W模型

  • 两个V：开发过程/测试过程
  • 测试过程：静态测试/动态测试
  • 局限性：与V模型一样，软件开发和测试之间保持一种线性的前后关系，需要严格的质量，无法支持代、自发性以及变更调整。对于很多文档事后补充、或者根本没有文档的做法下，令人困惑。

H模型

  • 软件测试是一个独立的流程，贯穿于产品的整个生命周期，与其他流程并发地进行
  • 软件测试原则“尽早准备，尽早执行”

X模型

  • 左边描述的是针对单独程序片段所进行的相互分离的编码和测试单独程序片段再进行频繁交接，通过集成最终合成可执行的程序已通过集成测试的成品可以进行封版并提交给用户
  • 探索性测试：未计划的特殊测试

实体产品的测试实例——作业

矿泉水瓶测试实例:

  1. 外观界面
  • 视觉检查：检查矿泉水瓶的外观是否有明显缺陷，如裂痕、变色或异物。
  • 标签信息验证：检查生产日期、有效期、容积标记是否清晰、准确。
  1. 功能测试
  • 泄漏测试：对瓶子进行倒置、侧放、挤压等动作，观察是否有水滴漏出。
  • 容积验证：用已知容积的容器倒入水进行比对，或者使用测量工具测量瓶身尺寸后计算理论容积。
  1. 性能测试
  • 耐压测试：使用专业设备或方法对瓶子施加压力，记录变形和破裂点。
  • 耐温测试：将瓶子置于不同温度环境中，观察其物理性能和外观变化。
  1. 安全性测试
  • 材质检测：送检实验室进行有害物质溶出测试。
  • 边缘处理测试：用手指沿瓶口、瓶盖边缘滑动，感受是否有刮手感。
  1. 易用性测试
  • 开启闭合测试：多次开启和关闭瓶盖，检查顺畅度和密封性。
  • 手持感测试：不同用户握持瓶子，收集手感反馈。
  1. 兼容性测试
  • 条码扫描测试：使用不同品牌和型号的扫描器扫描条码，验证识别率。
  • 环境兼容性测试：将瓶子置于高温、低温、高海拔等环境，检查其物理和功能性能。

第二章 基础测试过程

  1. 制定测试的目标和依据
  2. 测试需求分析
  3. 制定测试计划
  4. 设计测试用例、开发测试工具或脚本
  5. 执行测试
  6. 测试结果分析
  7. 提交测试报告

测试需求分析（软件需求评审）

测试进入的准则：

  • 清楚了解项目的整体计划框架
  • 完成需求规格说明书评审
    • 消除歧义、完善细节、达成共识
  • 技术知识或业务知识的储备
  • 标准环境技术设计文档
  • 足够的资源
  • 人员组织结构及其责任已确定

  • 产品人员：需求文档
  • 开发人员：概要/详细设计文档，编码
  • 测试人员：测试计划、测试用例

静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的审查以及静态分析等。将需求和设计的评审纳入测试的范畴，可看作是广义测试。

  • 代码测试：测试代码是否符合相应的标准和规范
  • 界面测试：测试软件的实际界面与需求中的说明是否相符合
  • 文档测试：测试用户手册和需求说明是否真正符合用户的实际需求

评审的形式/方法：代码检查与走查、互为评审、会议评审

测试人员参与产品需求分析和系统设计，认真阅读有关文档，真正理解客户的需求和技术上的设计，检查需求说明书对产品描述的准确性、一致性等，检查系统设计的合理性和可测试性等。

需求文档测试原则：

  • 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
  • 正确性
  • 一致性
  • 可行性
  • 无二义性
  • 健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
  • 必要性：“必要性”可以理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
  • 可测试性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
  • 可修改性：每一项需求都必须准确地陈述其要开发的功能。
  • 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好 (fine-grained)的方式编写并单独标明，而不是大段大段的叙述。

测试需求分析是测试设计和开发测试用例的基础：

  • 确定测试范围
  • 测试项和测试子项
  • 测试优先级
  • 测试风险
  1. 测试需求主要解决“测什么”的问题，应全部覆盖已定义的业务流程
  2. 软件测试需求是设计测试用例的依据，有助于保证测试的质量和进度，是衡量测试覆盖率的重要指标
  3. 测试需求分析的主要目的：依据需求文档提取测试点，根据测试点来编写测试用例
    • 单独功能测试：通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容
    • 功能交互测试：通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容
    • 界面、易用性、安全性、性能压力

测试需求分析项：

  • 项目背景
  • 业务（流程、用户角色）：观察、分析用户的心理、行为和预期
  • 用例、场景
  • 支撑业务的功能
  • 功能优先级
  • 非功能特性：性能需求（清楚而量化），充分的安全性测试、容错性测试和负载测试

软件需求的层次：

  • 业务需求反映组织机构或客户对系统、产品的概括性要求，包括所要达到的业务目标，由项目视图与范围文档说明
  • 用户角色需求描述用户使用系统而要完成的各种任务，由用例（use case）文档或方案脚本说明。用户角色需求可以扩展到涉众（干系人）需求
  • 功能需求定义开发人员必须实现的软件功能，它源于用户需求，是软件需求说明书中重要的组成部分

编写测试用例：

  • 测试用例编号：Input_001
  • 测试优先级：中
  • 测试目的：验证业务单据数据的查询正确性
  • 标题：业务单据查询
  • 步骤：
    1. 打开查询界面
    2. 输入查询条件
    3. 确定并提交查询
    4. 查看并验证返回的信息

测试计划

软件测试计划的重点工作：

  • 明确测试目标
  • 分析与确定测试范围
  • 识别测试项及其优先级
    • 以上为测试需求分析阶段
  • 测试阶段出入准则
  • 测试工作量估算
  • 测试资源、进度等安排
  • 识别测试风险，采取相应对策

测试目标和准则：确测试目标是测试需求分析和测试计划的前提

  • 提供哪些质量风险信息
  • 新改动的业务是否正确实现，对已有业务是否有负面影响
  • 是否满足功能性要求和非功能性要求
  • 在测试覆盖率、测试效率上的具体要求

测试资源安排：

  • 人力资源、系统资源（硬件和软件资源）以及环境资源
  • 由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试

测试计划内容：软件测试计划是指导测试过程的纲领性文件，描述测试活动的范围、方法、策略、资源、任务安排和进度等，并确定测试项、哪些功能特性将被测试、哪些功能特性将无需测试，识别测试过程中的风险。

测试范围：

  • 新功能
  • 升级测试（兼容性）
  • 已解决的故障再次验证
  • 基本功能（加入新功能之后）
  • 可靠性、性能是否达标
  • 文档的测试验证

软件测试每个阶段需要控制进入/退出标准以保障测试的质量

  • 进入准则：对软件测试切入点的确立，即满足什么条件，才启动测试
  • 退出标准：满足某个阶段结束/里程碑达到的事先定义的要求

测试工作量是根据测试范围、策划任务和开发阶段来确定的，测试范围和测试任务是测试工作量估算的主要依据。
测试工作量的估算依赖于测试任务的细化，对每项测试任务进行分解，然后根据分解的子任务进行估算。通常分解粒度越小，估算精度越高。

软件测试总是存在较高的风险，测试风险管理就是设法降低或缓解测试过程中的风险

  • 项目计划变更、测试资源不能到位可能产生风险
  • 实际操作时的建议：建立后备机制，让后备测试人员参与项目例会，评审，培训，交流等活动

测试计划是一个过程

  • 确认测试目标、范围和需求
  • 识别测试风险，制订相应的测试策略
  • 对测试任务和工作量进行估算
  • 确定所需的时间和资源
  • 进度安排和资源分派，包括团队角色、责任和培训
  • 测试阶段划分，包括阶段性任务和成果
  • 计划评审与批准
  • 跟踪和控制机制

黑盒测试

测试用例：

  • 定义：在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
    • 测试用例=输入（测试步骤和操作步骤）+输出（期望结果）+ 测试环境（系统环境设置）
  • 时机：通常在测试设计阶段来写，即在《需求规格说明书》和《测试计划》都已完成之后。
  • 唯一标准：用户的需求，具体参考资料就是《系统需求规格规格说明书》和软件原型。
  • 作用：在已知软件产品功能的基础上：
    • 便于团队交流
    • 便于重复测试
    • 便于跟踪统计
    • 便于用户自测

现代黑盒测试是从一种从软件外部对软件实施的测试，也称基于规格说明的测试。

  • 任何程序都可以看作是从输入定义域到输出值域的映射，将被测程序看作一个打不开的黑盒，黑盒里面的内容(实现)是完全不知道的，只知道软件要做什么。

黑盒测试是从用户观点出发的测试，其目的是尽可能发现软件的外部行为错误。
在已知软件产品功能的基础上，

  • 检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏；
  • 检测是否有人机交互错误，是否有数据结构和外部数据库访问错误，是否能恰当地接收数据并保持外部信息（如数据库或文件）等的完整性；
  • 检测行为、性能等特性是否满足要求等；
  • 检测程序初始化和终止方面的错误等。

显著优点：

  • 黑盒测试与软件具体实现无关，所以如果软件实现发生了变化，测试用例仍然可以使用；
  • 设计黑盒测试用例可以和软件实现同时进行，因此可以压缩项目总的开发时间。

黑盒测试用例设计方法：

  • 等价类划分法
  • 边界值分析法
  • 因果图法
  • 判定表法
  • 正交分解法
  • 基本路径分析法
  • 场景设计法
  • 错误推测法

等价类划分法

定义：

  • 等价类划分法是一种典型的黑盒测试方法，它完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分。

  • 把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试

  • 在分析需求规格说明的基础上划分等价类，列出等价类表。

  • 等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的。

  • 分为有效等价类和无效等价类

    • 对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明中所规定的功能和性能。
    • 反之为无效等价类
    • 设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受异常数据的考验。经过正反的测试才能确保软件具有更高的可靠性。

确定等价类的原则：

  1. 输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
  2. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价
    类和一个无效等价类。
  3. 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
  4. 在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。（多输入的或关系）
  5. 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。（多输入的且关系）
  6. 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。（细分等价类）

根据等价类创建测试用例的步骤

  1. 建立等价类表，列出所有划分出的等价类
  2. 为每个等价类规定一个唯一的编号
  3. 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类
  4. 重复3，最后使得所有有效等价类均被测试用例所覆盖
  5. 设计一个新的测试用例，使其只覆盖一个无效等价类
  6. 重复5使所有无效等价类均被覆盖。

规格说明往往没有定义无效测试用例的期望输出应该是什么样的。因此，测试人员需要花费大量时间来定义这些测试用例的期望输出。

  • 边界值和等价类密切相关，输入等价类和输出等价类的边界是要着重测试的边界情况。在等价类的划分过程中就产生了许多等价类边界。边界是最容易出错的地方，所以，从等价类中选取测试数据时应该关注边界值。
  • 在等价类划分基础上进行边界值分析测试的基本思想是，选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。

边界值分析法

大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部。为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果。

  • 边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力。
  • 很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷。
  • 边界条件就是软件计划的操作界限所在的边缘条件。

边界是指相当于输入等价类和输出等价类而言，稍高于边界值及稍低于其边界值的一些特定情况。

1
2
3
4
- 任意的正常值: 随机选择几个选项
- 边界值: 选择所有选项
- 边界值: 一个都不选
- 边界值: 选择一个选项

次边界条件：

  • 普通边界条件最容易找到，在产品说明书中有定义，或者在使用软件的过程中确定。
  • 有些边界在软件的内部，最终用户几乎看不到，但是软件测试仍有必要检查。这种边界条件称为次边界条件或者内部边界条件。

确定边界值的原则：

  1. 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
  2. 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少、比最大个数多1的数作为测试数据。
  3. 很多如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
  4. 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
  • 加法器边界测试用例（等价类）
  • 加法器边界测试用例（边界值）

健壮性边界测试：变量除了取min，min＋，nom，max－，max五个边界值外，还要考虑采用一个略超过最大值（max+）以及一个略小于最小值 (min-) 的取值。健壮性测试最有意义的部分不是输入，而是预期的输出，观察例外情况如何处理。

  • 对于一个n变量的程序，边界值分析测试会产生4n+1个测试用例。
  • 对于一个n变量的程序，健壮性边界值测试将产生6n+1个测试用例

等价类、边界值分析法习题

【例】某商店的货品价格（P）都不大于20元（且为整数），假设顾客每次付款为20元且每次限购一件商品，现有一个软件能在每位顾客购物后给出找零钱的最佳组合（找给顾客货币张数最少）。
假定此商店的找零货币面值只包括：10元（N10）、5元（N5）、1元（N1）3种。请采用等价类划分法为该软件设计测试用例（不考虑P 为非整数的情况）并填入到下表中。（<<N1,2>>表示2 张1 元，若无输出或输出非法，则填入N/A）

答案：

序号 输入（商品价格P） 输出
1 20（P=20） N/A
2 18（任意15<P<20） <<N1, 2>>
3 15（P=15） <<N5, 1>>
4 10（P=10） <<N10, 1>>
5 5（P=5） <<N5, 3>>
6 1（P=1） <<N1, 19>>
7 0（P=0） N/A
8 19（任意15<P<20） <<N1, 1>>
9 14（任意10<P<15） <<N5, 1>, <N1, 1>>
10 9（任意5<P<10） <<N10, 1>, <N1, 1>>
11 4（任意0<P<5） <<N5, 1>, <N1, 16>>

判定表/决策表方法

判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。

  • 条件桩：列出问题的所有条件。通常认为列出的条件的次序无关紧要。
  • 条件项：针对所列条件的具体取值，在所有可能情况下的真假值。
  • 动作桩：列出可能针对问题所采取的操作。这些操作的排列顺序没有约束。
  • 动作项：列出在条件项（各种取值）组合情况下应该采取的动作。
    在所有的黑盒测试方法中，基于判定表的测试是最严格，最具有逻辑性的测试方法。

适合使用判定表设计测试用例的条件：

  • 规则说明以判定表的形式给出，或很容易转换成判定表
  • 条件的顺序无关：条件（C）的排列顺序不影响执行哪些操作（A）
  • 操作/活动的顺序无关：如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
  • 规则之间的无关联：规则（R）的排列顺序不影响执行哪些操作；当某一条规则（R）的条件（C）已经满足，并确定要执行的操作（A）后，不必检验别的规则

步骤：

  1. 列出条件桩
  2. 列出动作桩
  3. 填入条件项及其组合
  4. 填入动作项，制定初始判定表
  5. 简化、合并相似规则或者相同动作

示例：

因果图法

组合之间有关系：多种输入条件的组合，输入之间有关系，例如，约束关系、组合关系，需要进行因果分析，不可直接采用判定表方法。因果图不擅长处理较大的规格说明。

因果图基本符号：

步骤：

  1. 分析软件规格说明文档描述的哪些是原因（输入条件），哪些是结果（输出条件）。原因常是输入条件或输入条件的等价类，结果是输出条件；
  2. 分析程序规格说明的描述中的语义内容，将其表示成连接各个原因与各个结果的“因果图”；
  3. 标明约束条件。在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件；
  4. 根据因果图，创建判定表，将复杂的逻辑关系和多种条件组合很具体明确的表示出来；
  5. 把判定表的每一列作为依据设计测试用例。

示例：



建立有限项的判定表：跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。

  • 选择一个果作为当前状态
  • 对因果图进行回溯，查找导致该果为1的所有因的组合
  • 在判定表中为每个因的组合生成一列
  • 对于每种“因”的组合，判断所有其他“果”的状态，并放置在每一列中。

回溯：



  • 因果图没有考虑边界条件。测试用例将边界条件一并考虑；
  • 难点在将因果图转化为判定表，有相关的算法实现及商业软件。

两两组合测试

  • 假如一个软件系统由N个构件组成（或者说由N个因素决定），大部分的软件错误是由一个构件的错误所导致，或者由2个构件之间的交互错误导致。
  • 大部分缺陷是在两个变量取值冲突的测试时被发现的
  • 构造测试用例需要涵盖每个因素的所有状态，并且涵盖每2个因素之间的所有交互。
  • 不仅仅是在所有的组合情况下才会发现所有的测试缺陷
  • 没有必要构造覆盖所有因素的所有组合的测试用例集合，只需要构造覆盖每个因素的所有状态，覆盖任意2个因素所有状态的测试用例集合。
正交试验法（Orthogonal Test Design Method, OTDM）

正交表法（Orthogonal Array Testing Strategy, OATS ）：正交表的两大优越性，即“均匀分散，整齐可比”。特性中有任意一条不满足，就不是正交表。

  • 每列中不同数字出现的次数相等
  • 任意两列，其横向组成的数字对，每种数字对出现的次数相等

  • m: 因子
  • n : 水平
  • 试验次数 ：m*(n-1)+1
  • eg: 4*（3-1）+1=9
正交表法练习

【例】考察5个3水平因子、以及一个2水平因子，选择合适的正交表。

考察5个3水平因子和一个2水平因子时，选择合适的正交表需要考虑因子的水平数和实验的总次数。正交表通常用符号“L[实验次数]([水平数]^[因子数])”来表示。

在您的案例中，有5个因子各有3个水平，一个因子有2个水平。首先，我们需要一个能容纳3水平因子的正交表。由于最高水平数是3，我们选择以3为基础的正交表。接下来，需要考虑总的实验次数，它应该足够容纳所有因子的组合。

比较
  • 在因子水平数比较少的情况下，采用配对测试方法。因为测试组合数更加全面一些，当然在某些因子水平数时，两者最后筛选出的结果可能是一致的。
  • 在因子水平数比较多的情况下，采用正交表测试，因为可以得到更加精炼的测试组合，从而使测试效率得到提升
组合分析方法作业

某一在线购物网站，有多种条件影响操作界面或操作功能，主要有以下几个方面：

  • 登录方式（LOGIN）：未登录、第一次登录、正常登录；
  • 会员状态（MEMBERSHIP）：非会员、会员、VIP、雇员；
  • 折扣（DISCOUNT）：没有、假日95折、会员9折、VIP会员8折
  • 物流方式（SHIP）：标准、快递、加急。
    设计测试组合。可以考虑增加一些约束条件，进一步优化或减少组合。
    IF [LOGIN]=’未登录’ THEN [MEMBERSHIP]=’非会员’
    IF [LOGIN]=’第一次登录’ THEN [MEMBERSHIP]<>’ VIP会员’
    IF [MEMBERSHIP]=’会员’ THEN [DISCOUNT]=’会员9折’
    IF [MEMBERSHIP]=’VIP会员’ THEN [DISCOUNT]=’会员8折’
    采用微软PICT和正交表构造法生成测试用例，比较两种方法的结果。

功能图法

  • 每个程序的功能通常由静态说明和动态说明组成

  • 静态说明描述了输入条件和输出条件之间的对应关系

  • 动态说明描述了输入数据的次序或者转移的次序

  • 功能图法就是为了解决动态说明问题的一种测试用例的设计方法

  • 功能图由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model，LFM）构成

  • 状态迁移图

    • 表示输入数据序列以及相应的输出数据。
    • 由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变。
    • 在STD中，输入数据和当前状态决定输出数据和后续状态。

  • 状态逻辑功能模型

    • 表示状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。

功能图生成测试用例的过程：

  • 测试用例是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。
  • 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试库由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成
  • 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径；
  • 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初状态到最后一个状态的一个状态序列，以及每个状态中输入数据与对应输出数据组合。

场景设计法

黑盒测试中重要的测试用例设计方法。目前，多数软件系统都是用事件触发来控制业务流程，事件触发时的情景便形成了场景，场景的不同触发顺序构成了用例。同一事件的不同触发顺序和处理结果就形成事件流。

  • 基本流（基本流程）
  • 备选流（分支流程）

  • 采用矩阵或决策表来确定和管理测试用例
  • 确定执行用例场景所需要的数据元素，构建矩阵



  • 根椐UML覆盖系统用例中的主场景和扩展场景，并且适当补充各种正、反面的测试用例和考虑出现的异常情形
  • 测试人员要充分发挥对用户实际业务场景的想象
  • 关心用户做什么，而不是关心产品做什么
  • 优点：实用性强，有效，设计出来的用例有价值
  • 缺点：可能使用的场景不一定能对事件系列进行全面的分析，设计出来的用例不完整。

场景法例题

错误推测法

错误推测法是测试者根据经验、知识和直觉来发现软件的错误，来推测程序中可能存在的各种错误，从而有针对性地进行测试。例举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

方便实用，特别在软件测试基础较差的情况下，是一种有效的测试方法。但不是一个系统的测试方法，只能用作辅助手段。没有别的办法可用时用推测法补充一些测试用例。

  • 优点：快速切入体会到程序易用与否；
  • 缺点：难以准确知道测试覆盖率。

方法比较与选择

  • 静态

    • 单因素：等价类划分、边界值分析
    • 多因素：因果分析法、决策表、组合覆盖、正交实验法

  • 动态：功能图、场景法

  • 其他：错误推测法

  • 如果变量引用的是物理量，可采用等价类测试和边界值测试。

  • 如果变量引用的是逻辑量，可采用等价类测试用例和决策表测试。

小结

  • 进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。
  • 在任何情况下都必须使用边界值分析方法，经验表明，用这种方法设计出的测试用例发现错误的能力强。
  • 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表法。
  • 对于配置参数类软件，用正交试验法选择较好的组合方式达到最佳效果
  • 功能图法也是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据
  • 对于业务清晰的系统，可以利用场景法贯穿整个测试案例过程在案例中综合使用各种测试方法
  • 可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验

测试执行

测试用例

Test Case，在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
测试用例=输入（测试步骤和操作步骤）+输出（期望结果）+ 测试环境（系统环境设置）

  • 用例名称
  • 测试路径
  • 前提条件
  • 详细步骤

软件缺陷的生命周期

软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程
发现——打开——修复——关闭

  • 激活或打开（Active or Open）：问题还没有解决 ，存在源代码中，确认“提交地缺陷”，等待处理已
  • 修正或修复（Fixed or Resolved）：已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证
  • 关闭或非激活（Close or Inactive）：测试人员验证后，确认缺陷不存在之后的状态
  • 重新打开：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
  • 推迟：这个软件缺陷可以再下一个版本中解决
  • 保留：由于技术原因或第三种软件的缺陷，开发人员不能修复的缺陷
  • 不能重现：开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤
  • 需要更多信息：开发能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件、图片等

完整缺陷描述的重要因素

  • 步骤：提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导
  • 期望结果：与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。是验证缺陷的依据。
  • 实际结果：实际执行测试的结果，不同于期望结果，从而确认缺陷的存在

测试进度管理：

  • S曲线法：法通过对计划中、尝试的与实际的进度三者对比来实现
  • NOB（Number of Open Bug）：收集当前所有打开的（激活的）缺陷数

软件缺陷的处理和跟踪

  • 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段
  • 通过缺陷趋势曲线来确定测试过程是否结束是常用且较为有效的一种方式
  1. 缺陷趋势分析：监控（打开/关闭/已修正的）缺陷随时间的变化
  2. 缺陷分布分析：缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等
  3. 缺陷报告：缺陷分布/趋势/年龄报告、测试结果进度报告
  4. 缺陷跟踪方法

测试执行

实践经验

  • 抽查性质的探索式测试，验证高风险区域的测试质量
  • 交叉互换测试人员所测试的模块，可以发挥互补作用

测试管理

缺陷探测率（DDP Defect Detection Percentage）：衡量测试工作效率的软件质量成本的指标

第三章 开发人员测试

白盒测试

  • 黑盒测试：外部逻辑功能错误，界面错误，安装、卸载时的错误，兼容性错误，性能问题
  • 白盒测试
    • 程序的源代码有多个分支，，尽可能覆盖所有分支，提高测试覆盖率，黑盒无法做到
    • 代码中的内存泄漏问题，白盒（eg: C/C++）可以很快找到黑盒需要长时间运行才能发现的内存泄漏问题
    • 极端情况出现，(eg:卫星中的电磁辐射等）难以进行功能测试，一般只对源代码进行静态分析

程序静态分析（结构分析）

方法：

  • 程序流程分析：控制流分析、数据流分析
  • 符号执行

控制流分析（缺陷——影响）：

  • 转向并不存在的符号——程序运行意外终止
  • 存在无用的语句标号——占用额外管理资源
  • 存在不可达语句标号——相应功能无法调用
  • 不可能到达停机语句——程序运行难以终止

数据流分析：

  • 变量被定义，但从未被使用
  • 变量被使用，但从未被定义
  • 变量在使用之前被定义多次

符号执行：得到运行特定区域代码的输入

  • 检查程序的执行结果是否符合预期
  • 通过符号执行产生程序的执行路径，为进一步自动生成测试数据提供约束条件

静态符号执行：

  • 以符号值作为输入，不使用一般程序运行时使用的具体值，通过符号执行模拟代码运行的过程
  • 任何执行点，符号化执行的程序状态包括：
    • 程序变量在该点的符号值
    • 路径条件的符号值
    • 一个程序计数器
      示例：

动态符号执行：传统符号执行技术无法精确求解路径，也无法获得满足路径条件约束的测试用例

  • 结合符号输入和具体数据对程序进行分析
  • 遇到复杂路径或大规模路径时使用具体输入值代替符号输入，驱使符号执行继续向后开展，获得可解的约束路径
  • 优于使用具体值代替了部分符号输入，使得路径约束包含的复杂数据结构和表达式简化，减小符号执行代价
    具体执行：
  • 运行工具跟踪记录符号状态以及当前路径的运行条件
  • 一条路径运行结束后，运行工具将路径中未覆盖分支的最后一个路径条件约束取反，再将新路径条件传递给约束求解器求解
  • 如果约束求解器可以给出一个满足新路径条件的解，运行工具运行该路径重复上述过程
  • 直到所有路径被覆盖，或覆盖特定目标，或满足时间需求
    示例：

动态白盒测试：
利用查看代码（做什么）和实现方法(怎么做)得到的信息来确定哪些需要测试、哪些不要测试、如何开展测试。又称为结构化测试(structral testing)
用尽量少的测试用例完成尽量高的逻辑覆盖。

逻辑覆盖测试法

逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖。

  • 语句覆盖（SC）：设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次。盖能发现一般语句的错误，但不能发现其中的逻辑错误。
  • 判定覆盖（DC）：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。较语句覆盖测试强度更高
    • 满足判定覆盖 -> 满足语句覆盖
  • 条件覆盖（CC）：设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。虽然条件覆盖分析了更小的条件粒度，与分支覆盖相比，并不具有更高测试强度
  • 判定-条件覆盖（CDC）：是判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次
  • 条件组合覆盖（MCC）：设计足够的测试用例，使得判断中每个条件的所有可能组合至少出现一次，并且每个判断本身的判定结果也至少出现一次。
    • 它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。
    • 满足条件组合覆盖，一定满足判定覆盖、条件覆盖、条件判定组合覆盖

修正条件/判定覆盖（MCDC）：

  • 每个程序模块的入口和出口至少执行一次
  • 每个判定的所有可能结果至少能取值一次
  • 判定中的每个条件的所有可能结果至少取值一次
  • 一个判定中的每个条件曾经独立地对判定的结果产生影响
    比条件/判定覆盖测试强度更高的逻辑覆盖标准，应用更广泛、测试效果更佳的逻辑覆盖标准。

白盒测试逻辑覆盖习题

基本路径测试法

对程序中的可运行路径进行穷举测试是不可行的，只能选择部分可运行路径作为测试目标。基本路径覆盖就是以程序控制流图中的独立路径作为覆盖目标的测试方法。基本路径测试并不是测试所有路径的组合，仅仅保证每条基本路径被执行一次。

  1. 依据代码绘制流程图（控制流图）
  2. 确定控制流图的圈/环复杂度（cyclomatic complexity）
  3. 确定线性独立路径的基本集合（basis set）
  4. 设计测试用例覆盖每条基本路径

如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符（or, and, nor）连接的逻辑表达式，则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断。

控制流图：

圈复杂度（Cyclomatic complexity）: 环复杂度。确定了程序基本路径集合中独立路径条数的上界。复杂度越高，出错的概率越大。

  • V(G) = 区域数量(由节点、连线包围的区域，包括图形外部区域)

  • V(G) = 简单可预测节点数量 + 1 = 判断节点数目 + 1

  • V(G) = 连线数量 - 节点数量 + 2

    • (包括起点和终点；所有终点只计算一次，多个return和throw算作一个节点)

  • 独立路径：至少引入一系列新的处理语句或条件的任何路径。程序中的每条语句至少会包含在一个独立路径中，满足独立路径覆盖需求也必定满足语句覆盖需求。

  • 基本集：由独立路径构成的集合。由基本集导出的测试用例，保证每行代码语句至少被执行一次。基本集合不一定唯一。

  • 逻辑覆盖：以程序或系统的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等

  • 基本路径测试：在程序或业务控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。

循环测试

目标 : 在循环内部及边界上执行测试

简单循环（迭代次数n）

嵌套（Nested）循环

串行连接的循环

循环化简：有时无法实现路径覆盖。考虑循环化简，限制循环次数。

  • 对循环机制进行简化，舍掉一些次要因素，极大地减少路径数量，使得覆盖有限的路径成为可能。
  • 循环化简，即限制循环的次数。无论循环的形式和实际执行循环体的次数多少，只考虑循环1次和0次两种情况，即进入循环和跳过循环两种情况。

测试用例数估算

为简化问题，避免出现测试用例极多的组合爆炸，把构成循环操作的重复型结构用选择结构代替。即不指望测试循环体所有的重复执行，而是只对循环体检验一次。

  • 顺序型——构成串行操作
  • 选择型——构成分支操作
  • 重复型——构成循环操作

白盒测试路径覆盖习题

程序插桩和变异测试

两类主要的程序修改方法

  • 程序插桩: 获得程序执行过程中的内部状态信息
  • 程序变异: 度量测试用例的缺陷检测能力

程序插桩原则：用尽可能少的插桩点完成尽量多的信息收集工作。

变异程序：一般用与源程序差异极小的简单变体模拟程序中可能存在的各种缺陷。
两个重要假设：

  • 熟练程序员假设：开发人员编程水平高，编写的代码即使包含缺陷，也仅需微小修改
  • 变异偶尔效应假设：测试用例能够杀死简单变异体，也容易杀死复杂变异体

变异体杀死：

  • 源程序与变异程序存在运行差异时，测试用例检测到变异程序中缺陷，变异程序被杀死
  • 两个程序不存在运行差异时，测试用例没有检测到变异程序的缺陷，变异程序存活

变异算子：

  • 模拟典型软件缺陷，度量测试用例对常见缺陷的检测能力
  • 引入特殊值，度量测试用例在特殊环境下的缺陷检测能力

面向过程程序的变异算子：

  • 运算符变异
    • 对关系运算符<、<=, >, >= 进行替换，将< 替换为 <=
    • 对自增运算符++或—运算符进行替换，如将++替换为–
    • 对与数值运算有关的二元算数运算符进行替换，如将+替换为-
    • 将程序中的条件运算符替换为相反运算符，如将 == 替换为 !=
  • 数值变异：对程序中的整数类型、浮点数类型的变量取反数，如将i 替换为 -i
  • 方法返回值变异
    • 删除程序中返回值类型为void的方法
    • 对程序中方法的返回值进行修改，如将true修改为false

面向对象程序的变异算子：

  • 继承变异
    • 增加或删除子类中的重写变量
    • 增加、修改或重命名子类中的重写方法
    • 删除子类中的关键字super，如将return asuper.b 修改为return ab
  • 多态变异
    • 将变量实例化为子类型
    • 将变量声明、形参类型改为父类型，如将 Integer i 修改为Object I
    • 赋值时将使用的变量替换为其他可用类型
  • 重载变异
    • 修改重载方法的内容，或删除重载方法
    • 修改方法参数的顺序或数量

变异程序运行结束后，仍存活，为等价变异程序。
变异得分 = 被杀死的变异程序 / （变异程序总数 - 等价变异程序数）

变异测试习题

单元测试

  • 定义：单元测试是对软件基本的组成单元进行独立的测试
  • 时机：单元测试和编码是同步进行，但在测试驱动开发（Test driven development, TDD）中，强调测试在先，编码在后
  • 人员：单元测试一般由开发人员完成, QA人员辅助
  • 概念：模块、组件、单元
  • 目标：单元模块被正确编码
    • 信息正确地流入和流出单元
    • 在单元工作过程中，其内部数据保持其完整性
    • 为限制数据加工而设置的边界处正确工作
    • 单元的运行做到满足特定的逻辑覆盖
  • 任务：
    • 模块独立执行路径测试
    • 局部数据结构测试
    • 模块接口测试
    • 单元边界条件测试
    • 单元容错测试/错误处理
    • 表达式与SQL语句

单元测试最重要的手段——静态测试：不运行被测试程序，对代码通过检查、阅读进行分析。

运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。

  • 驱动模块（drive）： 对底层或子层模块进行测试所编写的调用这些模块的程序

  • 桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序

  • 传统单元测试：针对程序的函数、过程或完成某一特定功能的程序块。

  • 面向对象软件的单元测试：测试类成员函数。数据成员是否满足数据封装的要求？类是否实现了要求的功能？

父类中已经测试过的成员函数，两种情况需要在子类中重新测试:

  • 继承的成员函数在子类中做了改动
  • 成员函数调用了改动过的成员函数的部分

对包含多态的成员函数进行测试时，只在原有测试分析和基础上增加对测试用例中输入数据类型的考虑

面向对象的单元测试习题

集成测试

  • 定义：根据实际情况将程序模块采用适当的集成测试策略组装起来，对模块之间的接口以及集成后的功能等进行正确性检验的测试工作。
  • 时机：确保测试对象所包含的程序模块全部通过单元测试
  • 缺陷类型：接口缺陷、数据丢失、误差放大、规格问题、并发问题

组件之间存在显式/隐形相依性，需通过结构分析、接口分析、模块分析获取相依性关系。

集成测试模式：

  • 非渐增式测试模式先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
    • 很难确定出错的真正位置、所在的模块、错误的原因，并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。
    • 可以并行测试
  • 渐增式测试模式把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试，如自顶向下和自底向上
    • 测试更彻底
    • 需要较多的机器时间

自顶向下法（Top-down Integration）步骤：

  1. 对主控模块进行测试，测试时用桩程序代替所有直接附属于主控模块的模块
  2. 根据选定的结合策略（深度优先/宽度优先），每次用一个实际模块代替一个桩程序（新结合进来的模块往往又需要桩程序）
  3. 在结合下一个模块的同时进行测试
  4. 为了保证加入模块没有引进新的错误，可能需要进行回归测试。

自底向上法步骤：

  1. 把底层模块组合成实现某个特定的软件子功能的族
  2. 写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出
  3. 对由模块组成的子功能进行测试
  4. 去掉驱动程序，沿软件结构自下向上移动，把子功能族结合起来形成更大的子功能族（Cluster）

三明治集成方法(Sandwich Integration)：

  • 优点：将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序。因为在测试初自底向上集成已经验证了底层模块的正确性。
  • 缺点：在真正集成之前（中层）每一个独立的模块没有完全测试过。
  • 改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底 。

基于调用图的集成：较少所需的驱动模块和测试桩模块，有效地减少集成测试的工作量。
构建程序调用图 → 识别各个模块间的程序调用关系

持续集成：通常系统集成都会采用持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现Bug，避免集成中大量Bug涌现

  • 传统集成测试：自顶向下和自底向上
  • 面向对象软件的集成测试
    • 没有层次的控制结构
    • OO程序相互调用的功能在程序的不同类中，类之间相互依赖紧密
    • 集成测试在整个程序编译完成后进行
    • 基于使用的测试：先测试独立类构造系统，完成后测试下一层，测试使用了独立类的类（依赖类）

系统测试

功能测试

  • 单元功能测试：保证所测试的每个独立的模块的功能正确，从输入条件和输出结果来判断是否满足程序的设计要求
  • 系统功能测试：
    • 考虑模块间的相互作用，考虑系统的应用环境
    • 衡量标准是实现产品规格说明书上所要求的功能
    • 特别地，模拟用户从头到尾（End-to-End,端到端）的业务测试，确保系统可以完成实现设计的功能，满足用户实际业务需求
      功能测试的整体思路：需求 -> 测试用例。客户需求为导向，全面理解功能特性。

回归测试

  • 一旦程序某些区域被修改了，就可能影响其它区域，导致受影响的区域出现新的缺陷（回归缺陷）。
  • 回归测试是为了发现回归缺陷而进行的测试。
  • 定义：对软件的新版本测试时，重复执行上一个版本测试时的用例。
  • 回归测试可以在任何测试阶段进行。既有黑盒测试的回归，也有白盒测试的回归。

性能测试

性能测试：是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载（正常或峰值）条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。
性能测试用来保证产品发布后系统的性能能够满足用户需求

性能测试目标：

  • 获取系统性能某些指标数据
  • 为了验证系统是否达到用户提出的性能指标
  • 发现系统中存在的性能瓶颈，优化系统的性能

性能测试类型：

  • 性能规划测试
  • 性能基准测试
  • 容量测试
  • 性能验证测试

产品生命周期中的性能要点：

  • 需求分析中充分关注负载压力性能
  • 在设计中得到负载压力性能指标
  • 开发阶段创建负载压力性能测试环境
  • 验收阶段在多等级范围内测试并调优
  • 运行阶段持续监控系统负载压力性能

不同角度的关注点：

  • 响应时间是用户的关注点；
  • 容量和数据吞吐量是（产品市场团队）业务处理方面的关注点；
  • 而系统资源占用率是开发团队的技术关注点。

性能的具体指标：

  • 数据传输的吞吐量（Transactions）
  • 数据处理效率（Transactions per second）
  • 数据请求的响应时间（Response time）
  • 内存和CPU使用率

80～20原理：每个工作日80％的业务在20％的时间内完成。

负载压力测试：在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统能承受的最大负载压力。
在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈或其它不稳定性问题。

并发性能测试：逐渐增加并发用户数负载，直到系统出现性能瓶颈或者崩溃（不能接受的性能点）为止。通过综合分析交易执行指标、资源监控指标来确定系统并发性能的过程。并发性能是负载压力测试的重要内容。

  • 负载测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统能承受的最大负载量的测试。
  • 压力测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。压力测试是为了发现在什么条件下系统的性能会变得不可接受。

其他非功能性测试

安全性测试

安全性：使伤害或损害的风险限制在可接受的水平内
软件安全性测试：检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出各种安全性漏洞
系统安全设计的准则：使非法侵入的代价超过被保护信息的价值

安全性测试：

  • 软件不做它不应该做的事, 应用输入验证, 没有不安全的事情发生
  • 在测试软件系统中对危险防止和危险处理设施进行的测试，以验证其是否有效
  • 安全性缺陷常常由软件的副作用引起，即软件应当做A，它做了A的同时，又做了B

安全性测试方法：

  • 基于漏洞的方法，从软件内部考虑其安全性，识别软件的安全漏洞。如借助于特定的漏洞扫描器。
  • 基于威胁的方法，从软件外部考察其安全性，识别软件面临的安全威胁并测试其是否能够发生
  • 模拟攻击测试是一组特殊的 、极端的测试方法，如Fuzzing，使用大量半有效的数据作为应用程序的输入，以程序是否出现异常为标志，来发现应用程序中可能存在的安全漏洞
可靠性和容错性测试

可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。

成熟性度量可以通过错误发现率DDP（Defect Detection Percentage）来表现。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。

容错性测试（Fault-tolrent test）是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。

  • 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
  • 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。
兼容性测试

兼容性测试: 验证软件之间是否正确地交互和共享信息
需要对所有可能的软件组合等价分配，验证软件之间正确交互的最小有效集合。