第一部分 软件测试综述

2019.05.17 – 2019.05.18

序

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

第1章 软件测试的背景

1.软件错误用例

• 美国航天局火星基地登陆者 探测器，1999
  当单元测试成功后，必须结合进行完整的系统测试，才能检测出各部分之间可能产生的的错误传递。
• 爱国者导弹防御系统，1991
  不能放过任何小的、当下看似不重要的缺陷，因为这些缺陷很有可能在日积月累下导致系统的重大错误。

2.软件失败的术语

• 缺点（defect）故障（fault）失败（failure）：指的是严重情况，甚至危险情况。
• 异常（anomaly）事件（incident）偏差（variance）：主要是未按预料的运行，而不是全部失败。
• 问题（problem）错误（error）缺陷（bug）：最常用的术语。

但总体来说，只要与开发小组达成共识即可，不需要过多计较用词。

3.软件缺陷的官方定义

• 产品说明书（product specification）
  对开发的产品进行定义，给出产品细节、如何做、做什么、不能做什么。
• 判断软件缺陷的五个规则（满足1个即可）：

1. 软件未实现产品说明书要求的功能。
2. 软件出现了产品说明书指明不应该出现的错误。
3. 软件实现了产品说明书未提到的功能。
   ——预料不到的操作，虽然有了可能更好，但会增加测试的工作，甚至带来更多缺陷。
4. 软件未实现产品说明书虽未明确提及但应该实现的目标。
   ——例如：极端条件下，软件对可能产生的错误的正确反馈。
5. 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。

4.软件测试员的目标
尽可能早地找出软件缺陷，并确保其得以修复。
——“修复”缺陷并非指一定要改正软件，可以是指在用户手册中增加一段注释或为用户提供特殊的培训。

第2章 软件开发过程

1.测试文档
是完整的软件产品的一部分。

比较重要的测试提交清单：

• 测试计划（test plan）：描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。
• 测试用例（test cases）：列举测试的项目，描述验证软件的详细步骤。
• 缺陷 告（bug reports）：描述执行测试用例找出的问题。通常记录在数据库中。
• 测试工具和自动测试（test tools and automation）：如果测试小组使用自动化工具测试软件，必须有文档记录。
• 度量、统计和总结（metrics，statistic，summaries）：测试过程的汇总。采用图形、表格和 告等形式。

2.软件产品的组成部分
产品不仅仅包括代码，也包括许多支持（非软件部分），这些也都需要测试。

• 非软件部分：
  帮助文档、用户手册、样本和示例、产品支持信息、错误信息、安装等。

3.软件开发生命周期模式
作为测试人员，可能会遇到不同模式，需要根据当前项目采取的模式来定制测试和方法（应用不同的测试技术）。

• 大爆炸模式
  • 背景：产品需求无需很好理解，最终发布日期可以随意修改。
  • 优点（对于开发）：简单，没有计划、进度安排和正规开发过程。
  • 缺点（对于测试）：从项目管理的角度，产品已经完工。准备交付，此时测试人员实际上妨碍了产品的交付。测试工作越深入，软件缺陷发现得越多，争吵就越多。
  • 实际情况：避免在此模式下进行测试。
• 边写边改模式
  • 背景：最初的粗略想法（没有计划和文档的编制）?一些简单的设计?漫长的来回编写、测试和修改缺陷的过程?发布产品
  • 优点（对于开发）：极其适合意在快速制作而且用完就扔的小项目。
  • 缺点（对于测试）：测试人员会和程序员一样陷入无休止的循环往复，不断拿到新的软件版本，此时可能旧版本的功能还未测试完成。
  • 实际情况：这种模式是最可能碰到的，它是软件开发的入门。
• 瀑布模式
  • 思想：从最初的构思到最终产品要经过一系列步骤（无法回溯）。每一个步骤结束时，项目小组审查并决定是否进入下一步。如果项目为准备好进入下一步，就停滞下来，直到准备好。
  • 优点（对于开发）：对于拥有明确清晰的目标的产品定义和训练有素的开发人员的项目而言，效果很好。
  • 缺点（对于测试）：测试在最后进行，一些根本性的问题如果出现在早期，会导致软件缺陷修复成本剧增。
  • 实际情况：需要改进成一个能够在早期就进行测试的模式。
• 螺旋模式
  • 思想：一开始不必详细定义所有细节。从小开始，定义重要的功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。
  • 优点（对于开发）：包含了瀑布模式（分析、设计、开发和测试的步骤）、边写边改模式（每一次的螺旋）、大爆炸模式（从外界观察）。
  • 优点（对于测试）：发现问题早，成本低。
  • 实际情况：测试人员最喜欢的模式，可以尽早影响到产品，弄清楚产品的来龙去脉。

第3章 软件测试的实质

1.承上：
现实生活中，几乎看不到任何纯粹采用某种模式进行的项目，看不到完全符合客户要求的详细产品说明书，也没有足够的时间去做所有需要做的测试。
启下：
但这个理想的过程正是追求的目标。

2.测试的原则

1. 完全测试程序是不可能的
   剔除重复的、无必要的测试条件。
2. 软件测试是有风险的行为
   把数量巨大的数量的可能测试减少到可控制的范围，以及针对风险做出明智的选择（哪些测试重要，那些测试不重要）。
3. 测试无法显示潜伏的软件缺陷
   可以 告缺陷的存在，但不能在任何情况下保证软件缺陷没有了。只有通过继续的测试，不断找到缺陷。
4. 找到的软件缺陷越多，就说明软件缺陷越多
   同样的错误可能出现多次；某个缺陷附近常会有很多其他缺陷；多个软件缺陷可能是由同一个严重错误引起的。
5. 杀虫剂怪事
   测试人员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试。
6. 并非所有软件缺陷都要修复
   项目小组要对缺陷进行取舍，根据风险决定哪些缺陷要修复，哪些不需要修复。
7. 何时一个问题才叫缺陷
   参照第1章 判断软件缺陷的五个规则。
8. 产品说明书从没有最终版本
   产品更新换代速度快，测试人员必须要想到未曾计划测试的功能可能会增加，经过测试并 告软件缺陷的功能可能发生变化甚至删除。
9. 软件测试人员在产品小组中最不受欢迎
   早点找出缺陷；控制情绪；不要总是 告坏消息。
10. 软件测试是一项讲究条理的技术专业

3.软件测试的术语和定义

• 精准（precision）&准确（accuracy）
  • 精准：稳定性
  • 准确：正确性
• 确认（verification）&验证（validation）
  • 确认：保证软件符合产品说明书。
  • 验证：保证软件满足用户要求（有时产品说明书并不能完全满足用户要求）。
• 质量（quality）&可靠性（reliability）
  • 质量：软件产品能够满足用户需求，并且用户会感到该产品的性能优越，优于其他产品。
  • 可靠性：表示程序的稳定程度，仅仅是质量的一个方面。
• 测试（testing）&质量保证（quality assurance，QA）
  • 测试：尽早找到软件缺陷，并确保其修复。
  • 质量保证：创建和执行一些标准和方法，改进软件开发过程，防止软件缺陷发生。

第二部分 测试基础

2019.05.20 – 2019.05.22
第4章：静态黑盒——检查产品说明书，并在软件编写之前找出问题；
第5章：动态黑盒——在不了解软件如何工作的前提下进行测试；
第6章：静态白盒——通过正式审查和检验检查代码的细节；
第7章：动态白盒——在看到软件的工作方式时，根据获得的信息对软件进行测试。

第四章 检查产品说明书

1.为何要测试产品说明书strong>
除了大爆炸模式，其余三种开发模式（边写边改、瀑布、螺旋模式）都要求开发小组根据需求文档编写产品说明书，用意定义软件是什么样的。

1. 在产品说明书中完善描述产品，可以确保最终产品符合客户要求以及正确计划测试投入。
2. 测试人员可以将产品说明书作为测试项目的书面材料，据此可以在编写代码之前找出软件缺陷。

2.测试产品说明书的方法

• 黑盒测试（black-box testing）&白盒测试（white-box testing）
  黑盒测试：又称功能性测试（functional testing）或行为测试（behavioral testing）。无法看到软件究竟如何运行，只知道程序进行一些输入，就能得到某种输出结果。
  白盒测试：又称透明盒测试（clear-box testing）。测试人员可以访问具体代码，可以根据代码检查结果判断可能产生的缺陷，并据此定制测试。
  ——因为要适应代码操作而进行定制测试，所以很容易形成偏见而无法进行客观测试。

3.产品说明书测试流程

1. 高级审查
   ——更好的了解产品以及影响其设计的外部因素，找出根本性问题或遗漏之处。

• 站在客户的角度思考需求
  当审查到某部分的专业知识不理解时，不要放掉，因为正式设计测试时一定会再次遇到这个问题。
• 研究现有的标准和规范
  比如：公司惯用语和约定、行业要求、政府标准、GUI、安全标准等。
• 审查和测试类似软件
  有助于设计测试条件和测试方法，还可能暴露意想不到的潜在问题。

2. 低层次测试
   ——确保所有细节都被定义。

• 产品说明书属性检查清单：
  a. 完整（是否有遗漏和丢失br> b. 准确（既定方案正确吗br> c. 精确（描述是否清楚br> d. 一致（功能描述是否自相矛盾br> e. 贴切（陈述是否简洁br> f. 合理（以现有的资源能否实现目标br> g. 代码无关（是否专注于定义产品，而非软件架构、代码br> h. 可测试性（功能能否测试/li>
• 产品说明书用词检查清单：
  a. 总是、每一种、所有、从不——绝对肯定的描述
  需要考虑违反这些情况的用例。
  b. 当然、因此、明显、必然——意图说服你接受假定情况
  考虑违反前提条件的用例。
  c. 某些、有时、常常、大多、几乎——描述过于模糊
  “有时”发生的功能无法测试。
  d. 等等、诸如此类、以此类推、例如——没有明确定义功能
  无法测试，需要对功能进行明确解释。
  e. 良好、迅速、高效、稳定——无法量化
  必须进一步准确定义其含义。
  f. 处理、进行、拒绝、跳过、排除——隐藏大量需要说明的功能
  细化功能操作步骤。
  g. 如果……那么……（没有否则）——缺少否则句
  需要明确定义当条件没有发生时，会产生什么结果。

第5章 带上眼罩测试软件

1.动态黑盒测试
有效的动态测试需要关于软件行为的一些定义（需求文档或产品说明书）。
根据产品说明书了解被测试软件的输入和输出，定义合适的测试用例。
——选择测试用例是测试人员最重要的一项任务，不正确的选择可能导致测试量过大或过小，甚至测试目标不正确。

2.通过性测试（test-to-pass）&失效性测试（test-to-fail）

• 通过性测试：确认软件至少能做什么，而不考验其能力。
  ——仅仅运用最简单、最直观的测试用例，不需要想尽办法让程序崩溃。
• 失效性测试：在确定软件在普通情况下能够正常运行后，有意共计软件的薄弱环节。
  ——设法迫使指定的错误信息出现，或迫使未考虑到的错误暴露出来。

3.等价类划分（equivalence partitioning）
把软件具有相似输入、相似输出、相似操作的分在同一个等价组，不对同组的用例进行过多重复的测试，有效的把无限测试用例集缩小。
由于这是不完全测试，所以是有风险的，如果为了减少测试用例的数量过度划分等价类，就有可能漏掉那些可能暴露软件缺陷的测试用例。

4.数据测试
对数据（如：键盘输入、鼠标单击、打印输出等）进行软件测试，就是在检查用户的输入信息、返回结果以及中间计算结果是否正确。
根据原则对大量的数据进行等价划分，以合理的减少测试用例。

• 边界条件（boundary condition）
  数据等价划分为有效数据和无效数据
  ——测试最后一两个合法的数据点，和第一两个非法的数据点。

• 次边界条件（sub-boundary conditions）：有一些边界在软件内部，最终用户看不到（如：2的幂、ASCⅡ码表）。

  • 默认、空白、空值、零值和无：不是输入不正确，而是根本没有输入。
    ——设置默认值或提示错误信息。
  • 非法、错误、不正确和垃圾数据：失效性测试对象，输入不合法的数据。

• 状态测试
  软件状态（software state）是指软件当前所处的条件或者模式。
  ——软件通过代码执行了某个分支，触发一些数据位，设置某些变量，读取某些数据，转入一个新的状态。

  • 状态转换图三要素
    a. 软件可能进入的每一种独立状态
    b. 从一种状态转入另一种状态所需的输入和条件
    c. 进入或退出某种状态时的设置条件即输出结果

  • 描述状态
    定义完备的状态变量（state variable）——与进入和退出状态相关的静态条件、信息、值、功能等。

  • 失败状态测试
    竞争条件&时序错乱：大多数操作系统都具备多任务执行的能力，所以软件执行过程中随时有可能被中断。
    ——首先仔细查看状态转换图中的每一个状态，找出那些外部影响会中断该状态。如果此时数据未准备好，或使用时发生了变化，状态会怎么改变。（如：共享同一台打印机，同时启动软件的多个实例等）
    重复、压迫和重负：测试极端恶劣的条件下可能发生问题的状态。

• 重复测试（repetition testing）：重复执行相同的操作。
  ——主要检查内存泄漏（memory leaks）问题。（如：反复读写数据，重复启动关闭程序）

• 压迫测试（stress testing）：使软件在内存小、磁盘空间少、CPU速度慢、调制解调速率低等不够理想的条件下运行。
  ——观察软件对外部资源的要求和依赖程度。
  – 重负测试（load testing）：让软件处理尽可能大的数据文件。
  ——最大限度发掘软件的能力。（如：高并发，长时间运行）

第6章 检查代码

1.静态白盒测试
在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时成为结构化分析。
在开发过程初期，让测试小组集中精力进行软件设计的审查非常有价值，可以尽早发现软件缺陷，也可以为黑盒测试员提供设计和应用测试用例的思路。

2.编码标准问题
注意：在对软件进行正式审查时，测试和注解的对象仅限于错误和缺漏，不同的编写风格不是缺陷！

3.通用代码审查清单

1. 数据引用错误
   使用未经正确声明和初始化的变量、常量、数组、字符串或记录。
2. 数据声明错误
   不正确的声明或使用变量和常量。
3. 计算错误
   糟糕的数学问题，使计算无法得到预期结果。
4. 比较错误
   边界条件问题，小于、大于、等于、不等于、真、假。
5. 控制流程错误
   计算或比较错误直接或间接导致，循环等控制结构未按预期方式工作。
6. 子程序参数错误
   子程序不正确地传递数据。
7. 输入/输出错误
   文件读取、接收键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。
8. 其他检查
   是否统一编码、是否需要移植、是否兼容、是否有错误提示。

在测试代码时应该考虑这些标准，但应该在研读其他公开的标准之后采用符合自己小组的自定义标准。

第7章 带上X光眼镜测试软件

1.动态白盒测试
利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确定哪些需要测试、哪些不要测试、如何开展测试。

2.分段测试

• 为什么r> 不分段类似于大爆炸的开发模式，难以找出出现问题的原因和导致问题的部分，并且某些软件缺陷掩盖了其他软件缺陷，核心问题很难弄清。

• 单元测试（unit testing）和集成测试（module testing）
  递增测试的两条途径：

  1. 自底向上：编写测试驱动模块调用正在测试的模块
     ——向处于测试的模块发送测试用例数据，接受返回结果。
  2. 自顶向下：编写桩（stub）代码充当接口模块
     ——将上层模块需要的数据直接由文件输入，只需要配置桩就能快速实验测试用例。

注意：在进行白盒测试之前，一定要根据说明书建立黑盒测试用例，这样才能真正测试到用户在实际使用情况中可能会进行的操作。

3.数据覆盖

• 数据流覆盖
  ——在软件中完全跟踪一批数据，在程序运行期间检查变量的中间值。
  可以根据观察结果决定更改某些测试用例，保证变量取得感兴趣的、甚至具有风险的中间值。
• 次边界覆盖
  询问编写代码的程序员是否知道这些次边界条件，并对内部数据表给予特别的注意，因为这里聚集了大量次边界条件。
• 公式和等式
  ——公式中会出现某些变量取值不合法而导致崩溃，这在黑盒测试中是不能看出来的。
  技巧：不关心公式和等式是如何实现的，仅查看它们使用的变量，在程序正常输入输出之外，为其建立测试用例和等价划分。
• 错误强制（error forcing）
  ——如果在调试器中调试，可以强制改变变量的值，以达到测试错误提示的目的。

注意：不要设置现实世界中不可能出现的情况，可以和程序员一起反复检查错误强制情况是否合法。

4.代码覆盖（code coverage）
为了全面覆盖，必须测试程序的状态以及程序流程，设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支

• 程序语句和代码行覆盖
  语句覆盖实际上是一种误导，即使全部语句都被执行了，但也不能说走遍了软件所有路径（如：不进入循环）。
  • 分支覆盖
  • 条件覆盖
    复杂判断（如：两条件的IF），用例保证覆盖IF语句中每一种可能（如：A对B对、A错B对、A对B错、A错B错）。
    如果测试了条件覆盖，那么就也达到了分支覆盖和语句覆盖。