软件测试（普遍认同）：

• 软件测试是为了发现错误而执行程序的过程；
• 测试是为了证明程序有错，而不是证明程序无错误；
• 一个好的测试用例是在于它能发现至今未发现的错误；
• 一个成功的测试是发现了至今未发现的错误的测试。

zero-bug vs. good-enough

防止过少和过量的测试。

木桶原则

不能有短板。测试仅作为重要的一环，不能仅依赖测试来保证质量；

80-20原则

能被发现的Bug仅占全部Bug的80%，还有20%只有在大范围、长时间使用下才能暴露。

测试用例（Test Case）

是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试和调试

• 调试：目的比较明确，是为了解决某一个特定问题，调试可以看作测试的一部分。
• 测试：比较完整的检查软件是否满足用户需求的一种有计划的行为。

软件和硬件

• 表现形式：硬件有形⇔ 软件无形、软件运行时才能看出优劣、管理困难；
• 生产方式：软件是逻辑产品、通信的误差；
• 质量要求：精度⇔有的软件是误差零容忍；
• 维护：硬件更换⇔软件升级。

软件缺陷/Defect/Bug

存在于软件（文档、数据、程序）中那些不希望、或不可接受的偏差，而导致软件产生的质量问题。

常见缺陷

• 未实现要求功能；
• 出现说明书中指明的不能出现的错误；
• 实现未提到功能；
• 未实现说明书未提及但应该实现的目标；
• 软件难以理解、不易使用、运行缓慢。

缺陷分类

按表现形式

• Function
• Interface
• Algorithm
• Documentation
  ...

按严重程度

• critical（关键的）
• cosmetic
• minor
• major

按优先级

• high
• middle
• low

按在生命周期的出现阶段

• Requirement
• Design
• Architecture
• Test
• Code

按根源

• 测试策略
• 工具和方法
• 团队和人
• 缺乏通信
  ...

按缺陷的生命周期

• new/unconfirmed
• confirmed
• fixed
• closed
• reopen

报告缺陷的原则

• 早原则：初期的错误vs.后期错误
• 有效原则：简短、单一、术语、明确
• 中立原则：缺陷不可避免、允许缺陷产生
• 重现原则：确保错误能重现。

缺陷管理工具

一个网络应用程序，提供多用户操作、管理缺陷，分析缺陷报告等功能。

举例子：

• Bugzilla：一款开源、免费、全球许多组织喜爱的缺陷管理工具。Mozilla项目组开发和使用。
• Mantis
• Trac

使用的两种模式

• 服务端模式：组件服务器，为其他用户提供缺陷管理平台。一般需安装：数据库、网页服务器、工具软件。
• 客户端模式：访问已有服务器。所需软件：浏览器或者客户端软件。

软件质量

ISO关于质量的定义：一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。而质量就是实体基于这些特性满足需求的程度。

质量层次

• 符合需求规格：符合开发者明确定义的目标。
• 符合用户显式需求：符合用户所明确说明的目标。
• 符合用户实际需求：包括用户明确说明的和隐含的需求。

影响软件质量的因素

• 流程
• 技术
• 组织

动态测试工作分类

组织内部进行：

• 单元测试
• 集成测试
• 系统测试

用户参与进行：

• 验收测试
• α（ALPHA)测试
• β（BETA)测试

单元测试

针对：软件基本组成单元（设计的最小单位）
目的：与《详细设计说明书》的符合程度
测试方法：白盒测试
评估基准：逻辑覆盖率

集成测试

基础：在单元测试基础上，将所有模块按照概要设计要求组装成为子系统或系统。
针对：组装后功能以及模块间接口
目的：与《概要设计说明书》的符合程度
测试方法：灰盒测试
评估基准：接口覆盖率

系统测试

针对：已集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起
目的：与《需求规格说明书》的符合程度
测试方法：黑盒测试
评估基准：测试用例对需求规格的覆盖率

穿插：回归测试（Regression Testing）

目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。
发生阶段：任何阶段，包括单元测试、集成测试和系统测试

【拓展】捕捉回放工具
对系统测试功能比较简单、测试界面相对稳定并且测试用例良好组织的测试来说，采用捕捉回放工具是比较合适的：

• QTP
• Robot
• SilkTest

回归测试分类

完全重复测试

重新执行所有在前期测试阶段建立的测试用例。

选择性重复测试

选择地重新执行部分在前期测试阶段建立的测试用例

它又可以分为：

• 覆盖修改法：针对被修改的部分，验证没有错误发生。
• 周边影响法：要包含覆盖修改法确定的用例，还需要分析修改的扩散影响。
• 指标达成方法：类似于单元测试的方法。在重新执行测试前，先确定一个要达成的指标，基于这种要求选择一个最小的测试用例集合。

验收测试

基础：通过内部系统测试及软件配置审查之后
组成：项目组成员、用户代表等组成
基准：验收测试根据合同、《需求规格说明书》/《验收测试计划》

α测试

组成：用户、开发者
过程： 软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题
目的：评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持

β测试

组成：用户
过程：由软件的多个用户在一个或多个用户的实际使用环境下进行的测试
过程：开发者通常不在测试现场，情况不可控。

测试过程

阶段划分

• 计划 – 测试计划
• 设计 – 测试方案
• 实现 – 测试用例、测试规程
• 执行 – 测试报告

常见过程模型

• 瀑布模型
• H模型
• V&V模型

验证(Verification)

• 保证软件正确地实现特定功能的一系列活动
• 检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致

确认(Validation)

• 保证所生产的软件可追溯到用户需求的一系列活动
• 检测每一阶段的工作产品是否与最初定义的软件需求、规格相一致

软件静态测试

在不运行程序的情况下，对程序进行检查和审核

主要包括：

• 各阶段评审
• 代码检查
• 程序结构分析
• 代码质量度量

软件复杂性

Halstead复杂度

根据可执行代码的操作符和操作数的数量来计算程序的复杂性。
程序的实际长度与其预测长度非常接近：

• 实际长度= N1 + N2；
• 预测长度= n1∗log(2∗n1)+n2∗log(2∗n2)

其中各个变量的意思：

• n1 =不同运算符的个数；
• n2 =不同操作数的个数；
• N1 =实际运算符的个数；
• N2 =实际操作数的个数。

静态测试工具

FindBugs：一个免费的Java静态分析工具，可以直接加载到Eclipse中运行。
配置Eclipse中的FindBugs；
使用FindBugs对Sudoku进行静态测试；
查看FindBugs查出的错误，并进行相应修改。

白盒测试

插桩法

在被测程序中插入操作（探测器），实现探查和监控的功能。
通过运行被测试程序，检查运行结果，分析其性能。
组成部分；
构造测试用例；
运行程序；
分析结果。

覆盖

• 判断覆盖
• 条件覆盖
• 条件组合覆盖
• 路径覆盖
• 语句覆盖
  判断覆盖关心判定表达式的结果，而条件覆盖关心每个表达式的取值，不关心整个判定表达式的最终值。

路径测试

基于路径覆盖的思想，考虑各分支的覆盖情况，压缩串行部分。
McCabe圈复杂度V (G)
V (G) = m − n + 2，其中
m：弧数
n：节点数

覆盖测试工具EclEmma

• 绿色表示该行代码被完整的执行；
• 红色表示该行代码根本没有被执行；
• 黄色表示该行代码部分被执行。

黑盒测试

边界值

导致程序失效极少是有两个或多个缺陷同时作用引起的，而大部分是由单个变量在边界值附近取值引起的。

• 基本边界值分析
  当考虑一个变量的边界值附近取值时，其他变量取正常值。
  因此边界值分析中：
  对于 n 变量的被测程序，需要测试用例为多少个？
  4n + 1个

• 健壮性边界值分析
  简单扩展，增加 max+ 和 min- 两个非正常值
  含非正常值的测试用例关心的不是输入本身，而是程序的输出。

等价划分

每一类中的代表数据与其他数据对揭示程序的缺陷有相等的作用，一损俱损，一荣俱荣；

• 强一般等价类测试：基于“多缺陷”假设，变量的有效等价类的任意组合。
• 弱健壮等价类测试：在弱一般等价类基础上增加无效等价类的情形。
• 强健壮等价类测试：在强一般等价类基础上增加无效等价类的情形。

因果图

直观的表达输入条件和输出动作之间的关系，帮助测试人员把注意力集中到与程序功能有关的输入组合上。

决策表

比因果图法更加严谨，需考虑各种条件的组合情况。
一般因果图和决策表的设计过程比较麻烦，仅在复杂的核心算法中才考虑采用。

正交试验法

研究和处理多因素实验的一种科学方法
帮助选择最佳的或满意的实验条件
构造正交表，相当于前面的方法设计的用例，但实验点更加均匀，又能减少实验次数。

正交表：
每一列各种数字出现的次数一样多；
任何两列所构成的有序数对出现的次数一样多。

正交表记为L4（2^3 ）
其中
3 表示因子的数量；
2 表示每个因子可以取得值（称为水平，等价类）；
4 为【查表的】正交表的行数（即测试用例个数）。

最少实验次数 = 求和(水平数-1)+1

Use case 场景法

基于以事件触发来控制流程的一种方法，测试用例就是描述事件触发时的事件流。

• 基本流： 按一定事件正确实现软件功能的基本流程；
• 备选流： 其他出现故障或缺陷、例外的流程。

状态迁移图法

许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上面。

• 画出有限状态自动机
• 从自动机推导出测试路径
• 根据测试路径编写合法测试用例
• 编写非法测试用例

JUnit

引入JUnit架包；
自动生成测试框架；
组织 AAA 设计测试用例；
用@Before标记初始化函数；
用@After标记结束清理函数。