黑盒测试与白盒测试

关于黑盒测试和白盒测试的有关概念可以参考 软件测试类型

检查产品说明书——静态黑盒测试

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

测试产品说明书的第一步不是马上钻进去找缺陷，而是站在一个高度上进行审查。审查产品说明书是为了找出根本性的问题、疏忽或遗漏之处。

1.假设自己是客户
当软件测试员第一次接到需要审查的产品说明书时，最容易做的事是把自己当作客户。了解客户所想的是很重要的。质量的定义是“满足客户的需求”。
2.研究现有的标准和规范
下面是可以作为标准和规范的一些例子。但这并不是明确规定的，对具体软件是否适用需经研究。
公司惯用语和约定、行业要求、政府标准、图形用户界面（GUI）、安全标准。
3.审查和测试类似软件
了解软件最终结果的最佳方法是研究类似软件，例如竞争对手的产品或者小组开发的类似产品。
在审查竞争产品时要注意的问题包括：
规模、复杂性、测试性、质量和可靠性、安全性。

产品说明书的低层次技术

1.产品说明书的属性检查清单
经过深思熟虑，可称为“一字不漏”的优秀产品说明书应具有8个重要的属性：
完整，准确，精确、不含糊、清晰，一致，贴切，合理，代码无关，可测试性。
2.产品说明书用语检查清单
在审查产品说明书时，作为前一个清单的补充，还有一个问题用语检查清单。问题用语通常表明功能没有仔细考虑——可能归结于前文所述的某一属性。从产品说明书中找出这样的用语，仔细审查他们在上下文中是怎样使用的。产品说明书后面可能会阐明或掩饰，也可能含糊其词——无论是哪一种情况，都可视为软件缺陷。
总是、每一种、所有、没有、从不，当然、因此、明显、显然、必然，某些、有时、常常、通常、惯常、经常、大多、几乎，等等、诸如此类、以此类推、例如，良好、迅速、廉价、高效、小、稳定，处理、进行、拒绝、跳过、排除，如果…那么…。

带上眼罩测试软件 ——动态黑盒测试

不深入代码细节测试软件的方法称为动态黑盒测试。它是动态的，因为陈程序在运行——软件测试员像用户一样使用它。测试员输入数据、接受输出、检验结果、动态黑盒测试常常被称为行为测试。

通过性测试和失效性测试

测试软件有两种基本方法：通过性测试和失效性测试。
在进行通过性测试时，实际上是确认软件至少能做什么，而不会考验其能力。软件测试员并不需要想尽办法让软件崩溃，仅仅运用最简单，最直观的测试用即可。
确信软件在普通情况下能正确运行之后，就可以采取各种手段搞垮软件来找出软件缺陷了。纯粹为了破坏软件而设计和执行的测试用例称为失效性测试或错误强制测试。

等价类划分

关于测试用例的设计方法，可以查看这篇文章测试用例设计方法

数据测试

对软件最简单的认识就是将其分成两个部分：数据（或其范围）和程序。数据包括键盘输入、鼠标单击、磁盘文件、打印输出等。程序是指可执行的流程、转换、逻辑和运算。软件测试常用的一个方法是把测试工作按同样的形式划分。
这些关键的原则是：边界条件、次边界条件、空值和无效数据。

状态测试

测试软件的逻辑流程

1.建立状态换图
状态转换图应该表示出以下目录：

• 软件可能进入的每一种状态
• 从一种状态转入另一种状态所需的输入和条件
• 进入或退出某种状态时的设置条件及输出结果
  2.减少要测试的状态以及转换的数量
  正如对数据进行等价划分一样，需要将大量的可能性减少到可以操作的测试用例集合。有以下5种实现方法：
• 每种状态至少访问一次
• 测试看起来是最常见和最普遍的状态转换
• 测试状态之间最不常用的分支
• 测试所有错误状态及其返回值
• 测试随机状态转换
  3.怎样进行具体测试
  确定要测试的状态及其转换之后，就可以定义测试用例了。
  测试状态及其转换包括检查所有的状态变量。

失败状态测试

1.竞争条件和时序错乱
以下是可能会面临竞争条件的例子情形：

• 两个不同的程序同时保存和打开同一个文档
• 共享同一台打印机、通信端口或其他外围设备
• 当软件处于读取或者改变状态时按键或者单击鼠标
• 同时关闭或者启动软件的多个实例
• 同时使用不同的程序访问一个共同的数据库
  2.重复、压迫和重负
  另外三个失效性状态测试是重复、压迫和重负，这些测试的目标是处于那些程序员没考虑到但在极端恶劣条件下可能发生问题的状态。
  重复性测试（repetition testing）是不断执行同样的操作。进行重复性测试的主要原因是检查是否存在内存泄漏。
  压迫测试（stress testing）是使软件在不够理想的条件下运行——内存小、磁盘空间小、CPU速度慢、调制解调器速率低等。
  重负测试（load testing）与压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥，让软件处理尽可能大的数据文件。

其他黑盒测试技术

1.像笨拙的用户那样做
2.在已经找到软件缺陷的地方再找找
3.像黑客一样思考问题
4.凭借经验、直觉和预感

检查代码——静态白盒测试

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

正式审查

正式审查（formal review）就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查，均属于此过程。
正式审查有4个基本要素：

• 确定问题：审查的目的是找出软件的问题——不仅是出错的项目，还包括遗漏项目。
• 遵守规则：审查要遵守一套固定的规则，规则可能设定要审查的代码量（通常有数百行），花费多少小时（数小时），哪些内容要做评价等。
• 准备：每一个参与者都为审查做准备，并尽自己的力量
• 编写报告：审查小组必须做出审查结果的书面总结报告

编码标准和规范

有一些问题是代码虽然可以正常运行，但是编写不符合某种标准和规范。这相当于写的东西可以被人理解和表述观点，但是不符合语言的语法和文法规则。
要坚持标准和规范的三个重要原因：可靠性、可读性/维护性、移植性。

通用代码审查清单

1.数据引用错误
数据引用错误是指未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。
2.数据声明错误
数据声明错误产生的原因是不正确地声明或使用变量和常量。
3.计算错误
计算或者运算错误实质上是糟糕地数学问题——计算无法得到预期结果。
4.比较错误
5.控制流程错误
控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作。
6.子程序参数错误
子程序参数错误的来源是软件子程序不正确地数据匹配。
7.输入/输出错误
输入/输出错误包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。
8.其他检查

带上X光眼睛测试软件——动态白盒测试

动态白盒测试是指利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确定哪些需要测试、哪些不需要测试、如何开展测试。动态白盒测试的另一个常用名称是结构化测试。因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。
动态白盒测试包括以下4个部分：

• 直接测试底层函数、过程、子程序和库。
• 以完整程序的方式从顶层测试软件
• 从软件获得读取变量和状态信息的访问权
• 估算执行测试时“命中”的代码量和具体代码，然后调整测试。

动态白盒测试和调试

动态白盒测试的目的是寻找软件缺陷，调试的目的是修复缺陷。然后它们在隔离软件缺陷的位置和原因上确实存在交叉现象。

分段测试

1.单元测试和集成测试

在底层进行的测试称为单元测试（unit testing）或者模块测试（module testing）。单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试（integration testing）。这个不断增加的测试过程继续进行，加入越来越多的软件片段，直至整个产品——至少是产品的主要部分——在称为系统测试（system testing）的过程中一起测试。

数据覆盖

1.数据流
数据流（data flow）覆盖主要是指在软件中完全跟踪一批数据。在单元测试级，数据仅仅通过了一个模块或函数。
2.次边界
如果进行白盒测试，就需要仔细检查代码，找到边界条件，并建立能测试它们的测试用例。询问编写代码的程序眼是否知道这些条件，并对内部数据表给予特别的注意，因为这里聚集了大量次边界条件。
3.公式和等式
4.错误强制

代码覆盖

与黑盒测试一样，测试数据只是一般工作。为了全面地覆盖，还必须测试程序的状态以及程序流程，必须设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支。这种类型的测试叫做代码覆盖（code coverage）测试。
1.程序语句和代码行覆盖
代码覆盖最直接的形式称为语句覆盖（statement coverage）或者代码行覆盖（line coverage）。如果在测试软件的同时监视语句覆盖，目标就是保证程序中每一条语句最少执行一次。
2.分支覆盖
试图覆盖软件中的所有路径称为路径覆盖。路径测试最简单的形式称为分支覆盖测试。
3.条件覆盖
条件覆盖（condition coverage）测试将分支语句的条件考虑在内。

参考文献
[1].软件测试（原书第二版）.[美] 罗恩佩腾著.张小松 王钰 曹跃等译.机械工业出版社