测试之旅Ⅰ-测试基础

测试基础

本篇博文将对静态黑盒测试、动态黑盒测试、静态白盒测试以及动态白盒测试进行简单描述，这部分是学习测试的基础，并对后面的测试技术来说非常重要。
假如有幸在项目早期介入，并有权修改初期的产品说明书，在此阶段找出软件缺陷极有可能为项目节省大笔开销和时间。

一、检查产品说明书

几个名词

产品说明书：通常是利用文字和图形描述产品的书面文档。除了大爆炸模式之外，每一种模式中开发小组都要根据需求文档编写一份产品说明书，用以定义软件是什么样的。
黑盒测试：在黑盒测试中，软件测试员只需知道软件要做什么——而无法看到盒子里的软件是如何运行的。只要进行一些输入，就能得到某种输出结果。他不知道软件如何让运行，为什么会这样，只知道程序做了什么。
白盒测试：（透明盒测试）软件测试员可以访问程序员的代码，并通过检查代码的线索来协助测试——可以看到盒子里面。测试员根据代码检查结果判断或多或少可能出错的数目，并据此定制测试。
静态测试：是指测试不运行的部分——只是检查和审核。
动态测试：是指通常意义上的测试——使用和运行软件。
综上，对于产品说明书的测试属于静态黑盒测试。

对产品说明书进行高级审查

测试产品说明书的第一步不是马上钻进去找缺陷，而是站在一个高度上进行审查。审查产品说明书是为了找出根本性的问题、疏忽或遗漏之处。也许这更像是研究而不是测试，但是研究的根本是为了更好地了解软件该做什么。如果能够很好地理解产品说明书后的诸多为什么和怎么做，就可以更好地进行细节检查。

假设自己是客户

质量的定义是“满足客户要求”，软件测试员必须了解并测试软件是否符合那些要求。熟悉软件应用领域的相关知识有很大的帮助。如果审查产品说明书的某一部分时不理解，不要假定它是对的而把它放掉。在使用时，客户也许会假设软件是安全的，但软件测试员不能假定程序员会正确处理安全问题。

研究现有的标准和规范

下面是可以考虑作为标准和规范的一些例子。

• 公司惯用语和约定 如果软件是为某公司定制的，就应该采用该公司职员常用的术语和约定。
• 行业要求 医药、工业和金融行业的应用软件有其必须严格遵守的标准。
• 政府标准 政府——特别是军队系统有严格的标准。
• 图形用户界面 如果软件运行在Microsoft Windows或Apple Macintosh操作系统下，关于软件外观和用户的感受具有公开的标准。
• 安全标准 软件及其界面和协议可能需要满足一定的安全标准或级别。也许还需要进行独立的认证，以确保其满足必要的标准

软件测试员的任务不是定义软件要符合何种标准和规范，这是项目经理或者编写产品说明书的人的任务。软件测试员要做的是观察，“检查”采用的标准是否正确、有无遗漏。在对软件进行确认和验收时，还要注意是否与标准和规范相抵触，把标准和规范视为产品说明书的一部分。

审查和测试类似软件

了解软件最终结果的最佳方法是研究类似软件，例如竞争对手的产品或者小组开发的类似产品。
在审查竞争产品时要注意的问题包括：

• 规模 软件的功能强大还是单一？代码多还是少？这些差别与测试有关吗？
• 复杂性 软件简单还是复杂？这会影响测试吗？
• 测试性 是否有足够的资源、时间和经验来测试软件？
• 质量和可靠性 软件是否完全满足质量要求？可靠性高还是低？
• 安全性 竞争对手软件的安全性（不管是宣称还是实际的）和自身的比较起来如何？

产品说明书的低层次测试技术

产品说明书属性检查清单

• 完整 是否有遗漏和丢失？完全吗？单独使用时是否包含所有内容？
• 准确 既定解决方案正确吗？目标定义明确吗？有没有错误？
• 精确、不含糊、清晰 描述是否一清二楚？是否有单独的解释？容易看懂和理解吗？
• 一致 产品功能描述是否自相矛盾，或与其他功能有无冲突？
• 贴切 描述功能的陈述是否必要？有没有多余信息？功能是否符合原来的客户要求？
• 合理 在规定的预算和进度下，以现有人力、工具和资源能否实现？
• 代码无关 产品说明书是否坚持定义产品，而不是定义其软件设计、架构和代码？
• 可测试性 功能能否测试？给测试员提供的建立验证操作的信息是否足够？

产品说明书术语检查清单

问题用语通常表明功能没有仔细考虑——可能归结于前文所述的某一属性。从产品说明书中找出这样的用语，仔细审查它们在上下文中是怎样使用的。产品说明书后面可能会阐释或掩饰，也可能含糊其辞——无论是哪一种情况，都可视为软件缺陷。

• 总是、每一种、所有、没有、从不 如果看到此类绝对或肯定的描述，需要确认是这样的。软件测试员要考虑违反这些情况的用例。
• 当然、因此、明显、显然、必然 这些话试图说服你接受假定情况，不要中了圈套。
• 某些、有时、常常、通常、惯常、经常、大多、几乎 这些话太过模糊。“有时”发生作用的功能无法测试。
• 等等、诸如此类、以此类推、例如 以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确，以免让人对功能清单内容产生迷惑。
• 良好、迅速、廉价、高效、小、稳定 这些是无法量化的术语，它们无法测试。如果说明书中出现这些用语，必须进一步准确定义其含义。
• 处理、进行、拒绝、跳过、排除 这些用语可能会隐藏大量需要说明的功能。
• 如果······那么······（没有否则） 找出有“如果······那么······”而缺少配套的“否则”结构的陈述。想一想“如果”没有发生回怎样。

高级审查技术可以查出遗漏和缺失之处，低层次测试技术确保所有细节都被定义。

二、戴上眼罩测试软件

不深入代码细节测试软件的方法称为动态黑盒测试。
测试员输入数据、接受输出、检验结果。动态黑盒测试常被称为行为测试，因为测试的软件是在使用过程中的实际行为。
有效的动态测试需要关于软件行为的一些定义——也即需求文档或者产品说明书。清楚了被测试软件的输入和输出之后，接下来要开始定义测试用例，测试用例是指进行测试时使用的特定输入，以及测试软件的过程步骤。
在没有产品说明书时，尽管这对于软件测试员不是理想的状况，但是此时可以采取称为探索测试的解决方案——了解软件、设计测试、执行测试同时进行。这就需要把软件当做产品说明书来对待。系统地逐项了解软件的功能、记录软件的执行情况、详细描述功能。

通过性测试和失效性测试

• 通过性测试 实际上是确认软件至少能做什么，而不会考验其能力。
• 失效性测试 纯粹为了破坏软件而设计和执行的测试用例。蓄意攻击软件的薄弱环节。

等价类划分

等价类划分是指分步骤地把海量（无限）的测试用例集减的很小，但过程同样有效。
一个等价类或者等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试。

数据测试

对软件最简单的认识就是将其分成两部分：数据（或其范围）和程序。
对数据进行测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。
数据的例子如下：

• 在文字处理程序中输入的文字
• 电子表格中输入的数字
• 太空游戏中余下的射击次数
• 图像处理软件打印的图片
• 存放在软盘中的备份文件
• 通过调制解调器在电话线上发送的数据

边界条件

如果软件能在其边界运行，那么在正常情况下就应该不会有什么问题。
边界条件是指软件运行在计划操作界限的边界的情况。
如果要选择在等价划分中包含哪些数据，可以根据边界来选择。
越界测试的做法通常是简单地对于最大值加1或者很小的数，以及对于最小值减1或者很小的数。
在软件的每一个部分不断寻找边界是极为重要的，寻找做的越多，边界就会发现的越多，可能找出的软件缺陷就越多。
缓冲区溢出是由边界条件缺陷引起的，它是造成软件安全问题的头号原因。

次边界条件

例如：2的幂和ASCII表

默认、空白、空值、零值和无

一种看起来很明显的软件缺陷来源于当软件要求输入时，根本没有输入任何内容。这种情况在产品说明书中常常忽视，程序员也经常遗忘，但是在实际使用中却时有发生。
好的软件会处理这种情况。它通常将输入内容默认为边界内的最小合法值，或者在合法划分中间的某个合理值；或者返回错误提示信息。

非法、错误、不正确和垃圾数据

数据测试的最后一种数据类型是垃圾数据。这是失效性测试的对象。此类测试没有实际的规则，只是设法破坏软件。要发挥创造力，要会走偏门。

状态测试

软件状态是指软件当前所处的条件或模式。软件测试员必须测试程序的状态及其转换。

测试软件的逻辑流程

访问所有状态通常是可以实现的。困难在于除了极其简单的程序之外，基本上不可能走遍所有分支，达到所有状态。软件的日益复杂化，尤其是为了迎合日益丰富的用户界面，提供了太多选择和选项，致使程序分支数量呈指数式增长。
对于软件测试，解决方法是运用等价划分技术选择状态和分支。因为选择不做完全测试，所以要承担一定的风险，但是通过合理选择减少风险。

状态转换图应该表示出以下项目：

• 软件可能进入的每一种独立状态
• 从一种状态转入另一种状态所需的输入和条件
• 进入或者退出某种状态时的设置条件及输出结果
  正如对数据进行等价划分一样，需要将大量的可能性减少到可以操作的测试用例集合。
  有以下5种实现方法：
• 每种状态至少访问一次。如何到达的没有关系，但是每一种状态都必须测试。
• 测试看起来是最常见和最普遍的状态转换。
• 测试状态之间最不常用的分支。
• 测试所有错误状态及其返回值。
• 测试随机状态转换。
  确定要测试的状态及其转换之后，就可以定义测试用例了。
  状态变量 与进入和退出状态相关的静态条件、信息、值、功能等。

失败状态测试

竞争条件和时序错乱

多任务 是指操作系统设计用来同时执行多个独立的进程。
在真正的多任务环境中，软件设计绝对不能想当然，必须处理随时被终端的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信以及其他硬件资源。
时序发生错乱 几个事件恰巧挤在一起，由于软件未预料到运行过程会被中断，以致造成混乱。
竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。
以下是可能会面临竞争条件的例子情形：

• 两个不同的程序同时保存和打开同一个文档
• 共享同一台打印机、通信端口或者其他外围设备
• 当软件处于读取或者改变状态时按键或者单击鼠标
• 同时关闭或者启动软件的多个实例
• 同时使用不同的程序访问一个共同的数据库

重复、压迫和重负

• 重复测试是不断执行同样的操作。最简单的是不停地启动、关闭程序。还可以反复读写数据或者反复选择同一个操作。进行这种反复测试的主要原因是检查是否存在内存泄漏。
• 压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度，目的在于尽可能地限制软件的必要条件。
• 重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度地发掘软件的能力，让它不堪重负。

重复、压迫和重负测试应联合使用，同时进行，这是找出以其他方式难以发现的严重缺陷的一个可靠的方法。

其他黑盒测试技术

• 像笨拙的用户那样做
• 在已经找到的软件缺陷的地方再找找
• 像黑客一样考虑问题 想想软件里面有哪些有价值的东西，为什么有人想要获得其访问权限，黑客进入的方法有哪些
• 凭借经验、直觉和预感

三、检查代码

静态白盒测试：检查设计和代码

静态白盒测试 是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析。

正式审查

正式审查就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查均属于此过程。正式审查的方法包括：同事审查、走查、检验等。

4个基本要素

• 确定问题 审查的目的是找出软件的问题——不仅是出错的项目，还包括遗漏项目。
• 遵守规则 审查要遵守一套固定的规则，规则可能设定要审查的代码量，花费多少时间，哪些内容要做评价等。
• 准备 每一个参与者了解自己的责任和义务，并尽自己的力量积极参与审查。
• 编写报告 审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组的成员使用。

除了发现问题，坚持正式审查还有一些间接效果：

• 交流 正式报告中未包含的信息得以交流。
• 质量 程序员的代码经过逐个功能、逐行代码仔细复查，常常会使程序员变得更加仔细。
• 小组同志化 如果审查正确进行，就会建立软件测试员和程序员对双方技艺的相互尊重，并且更好地了解相互的工作及需求。
• 解决方案 尽管是否讨论解决方案取决于审查的规则，但是解决方案应该用语处理严重问题。在审查的范围之外讨论解决方案也许更有效。

编码标准和规范

坚持标准或规范的三个原因：

• 可靠性
• 可读性/维护性
• 移植性

编程标准的组成：

• 标题 描述标准包含的主题。
• 标准 描述标准或规范内容，解释哪些允许哪些不允许。
• 解释说明 给出标准背后的原因。
• 示例 给出如何使用标准的简单程序示例。

通用代码审查清单

• 数据引用错误
• 数据声明错误
• 计算错误
• 比较错误
• 控制流程错误
• 子程序参数错误
• 输入/输出错误
• 其他检查

四、戴上X光眼镜测试软件

动态白盒测试 是指利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确定哪些需要测试、哪些不需要测试、如何开展测试。动态白盒测试的另一个常用名称是结构化测试。
动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件。动态白盒测试包括以下4个部分：

• 直接测试底层函数、过程、子程序和库。
• 以完整程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例。
• 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
• 估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例。

动态白盒测试和调试这两项技术表面上很相似，因为它们都包括处理软件缺陷和查看代码的过程，但是它们的目标大不相同。动态白盒测试的目标是寻找软件缺陷，调试的目标是修复缺陷。然而，它们在隔离软件缺陷的位置和原因上确实存在交叉现象。

分段测试

单元测试和集成测试

在底层进行的测试称为单元测试或者模块测试。单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试。这个不断增加的测试过程继续执行，加入越来越多的软件片段，直至整个产品——至少是产品的主要部分——在称为系统测试的过程中一起测试。
这种递增测试有两条途径：自底向上和自顶向上。

• 在自底向上测试中，要编写称为测试驱动的模块调用正在测试的模块。测试驱动模块以和将来真正模块同样的方式挂接，向处于测试的模块发送测试用例数据，接受返回结果，验证结果是否正确。
• 在自顶向上测试中，编写一小段称为桩的代码充当接口模块，有了这个测试桩配置，就可以快速从头到尾试验各种测试值，验证显示模块的操作。

数据覆盖

• 数据流 数据流覆盖主要是指在软件中完全跟踪一批数据。
• 次边界
• 公式和等式 可以撇开代码中的公式和等式，查看它们使用的变量，在程序正常输入和输出之外，为其建立测试用例和等价划分。
• 错误强制

代码覆盖

• 程序语句和代码行覆盖
• 分支覆盖
• 条件覆盖

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

从某种意义上说，以上就是软件测试的全部内容。