1 基本名词解释及分类

基本名词解释：

Bug：软件的缺陷；
Test Case：测试用例，描述了一个完整的测试过程，包括测试环境、输入、期望的结果等；
Test Suite：测试用例集，即一组相关的测试用例。

Bug可以分解为：

症状（Symptom）：即从用户的角度看，软件出了什么问题；
程序错误（Fault）：即从代码的角度看，代码的什么错误导致了软件的问题；
根本原因（Root Cause）：错误根源，即导致代码错误的根本原因。

一个关于Bug的完整例子：

症状：用户报告，一个Windows应用程序有时会在启动时报错，继而不能运行；
程序错误：有时候一个子窗口的handle为空，导致程序访问了非法内存地址，此为代码错误；
根本原因：代码并没有确保创建子窗口（在CreateSubWindow()内部才做）发生在调用子窗口之前（在OnDraw()时调用），因此子窗口的handle变量有时会在访问时处于未赋值状态（为空），导致出现上面提到的代码错误。

1.1 按测试设计的方法分类

分类	说明
黑箱	指的是在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法时行为测试设计（Behavioral Test Design），即从软件的行为，而不是从内部结构出发来设计测试。
白箱	指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据即具体的测试方法。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

注意：所谓的黑箱/白象，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

1.2 按测试的目的分类

1.2.1 功能测试

下表所示的测试类别中，测试的范围由小到大，测试者也由内到外 - 从程序开发人员（单元测试）到测试人员，到一般用户（Alpha/Beta测试）。

测试名称	测试内容
单元测试（Unit Test）	在最基本的功能/参数上验证程序的正确性
功能测试（Functional Test）	验证模块的功能
集成测试（Integration Test）	验证几个互相有依赖关系的模块的功能
场景测试（Scenario Test）	验证几个模块能否完成一个用户场景
系统测试（System Test）	对于整个系统功能的测试
Alpha/Beta Test	外部软件测试人员（Alpha/Beta测试员）在实际用户环境中对软件进行全面的测试

1.2.2 非功能测试

一个软件除了基本功能之外，还有很多功能之外的特性，这些叫非功能需求（Non-functional Requirement），或者服务质量需求（Quality of Service Requrement）。这一般在软件的基本功能开发完成后来做这些非功能测试。

测试名称	测试内容
压力测试（Stress/Load Test）	测试软件在负载情况下能否正常工作
效能测试（Performance Test）	测试软件的效能
可访问性测试（Accessibility Test）	测试软件是否向残疾用户提供了足够的辅助功能
本地化/全球化测试（Localization/Globalization Test）	/
兼容性测试（Compatibility Test）	/
配置测试（Configuration Test）	测试软件在各种配置下能否正常功能
易用性测试（Usability Test）	测试软件是否好用
软件安全性测试（Security Test）	/

1.2.3 按测试的时机和作用分类

在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否顺畅。

测试“烽火台”：

测试名称	测试内容
冒烟测试（Smoke Test）	测试不通过，则不能进行下一步工作
构建验证测试（Build Verification Test）	验证构建是否通过基本测试
验收测试（Acceptance Test）	全面考核某方面的功能/特性

另一些测试名称，则是说明不同的测试方法。

不同的测试方法：

测试名称	测试内容
“回归”测试（Regression Test）	对一个新的版本，重新运行以往的测试用例，确认新版本相比已知版本有无“退化”（Regression）
“探索式”的测试（Ad hoc/Exploratory Test）	随机进行的、探索性的测试
Bug大扫荡（Bug Bash）	全体成员参加的找“小强”活动
伙伴测试（Buddy Test）	开发人员（伙伴）作为测试人员测试特定模块

2 各种测试方法

3 实战中的测试

实战中的测试是在项目的稳定阶段执行的。团队在这一阶段的核心任务是：在满足最低接受条件的前提下，提高各个部分的质量。

3.1 似是而非的测试概念

测试在项目的最后进行就可以了；
测试就得根据规格说明书（Spec）来测，所以是很机械的；
测试人员当然也写代码，但是质量不一定要很高；
测试的时候尽量用Debug版本，便于发现Bug；
如果所有的人都关心质量，就没有必要有独立的测试团队。

3.2 测试工作中的文档

在计划阶段，我们就要制定测试计划（Test Plan），特别是测试总纲。

然后还要写测试设计说明书（TDS）、测试用例（Test Case）、程序错误报告（Bug Report）和测试报告（Test Report）。它们之间的关系如下图所示：
【构建之法】第13章-软件测试
测试计划和测试总纲主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责什么方面，各种资源在哪里，等等。

注意：我们不是为了写文档而写文档，写文档的目的是要解决问题。然而，到底这些文档会解决什么问题呢？

文档	作用
测试设计说明书（TDS）	正如开发人员有功能设计说明书，测试人员也要有测试设计说明书，告诉测试人员要如何设计测试。
测试用例（Test Case）	有了TDS，我们就可以按照TDS的描述，对每一个功能点进行实际的测试了。具体地说，测试用例描述了如何设置测试前的环境、如何操作、预期结果是什么。一个功能的所有测试用例合称为这个功能的测试用例集（Test Suite）。
错误报告（Bug Report）	一份好的错误报告，至少要满足：标题、描述、补充材料、严重程度及功能区域等
测试修复，关闭缺陷报告（Resolve，Test and Close a Bug）	/
测试报告（Test Report）	用于报告各个功能测试的结果，这就是测试报告；对于某一功能，我们要收集下列数据： -有多少测试用例通过？ -有多少测试用例失败？ -有多少测试用例未完成？ -发现多少测试用例之外的Bug？

【构建之法】第13章-软件测试