经常有这样的经验：想要学一样东西，有一本关于它的厚厚的书摆在我面前。快速的翻了翻之后，又将它合上。然后无奈的叹了口气。是啊，到底该怎么下手呢？可当得知明天就要考这本书的时候，再打开，发现它们突然变得简单了。只是自己想学的太多，时间有点不够用……
软件测试
定义：测试是为了发现错误而执行程序的过程。

目的：

• 为了寻找错误，并尽可能地为修正错误提供更多的信息。
• 为了证明软件有错误，而不是证明软件没有错误。

作用：

• 发现并管理缺陷
• 度量质量
  • 评价工作效率和效果
  • 与其项目风险

原则：

• 座右铭：“尽早地和不断地进行软件测试”。
• 测试用例应由测试输入数据和对应的语句输入结果这两部分组成。
• 程序员应避免检查自己的程序。
• 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
• 充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
• 严格执行测试计划，排除测试的随意性。
• 应当对每一个测试结果作全面检查。
• 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
• 所有的测试都应可追溯到客户的需求。
• 应该在测试工作开始之前的较长时间就进行测试计划。
• pareto原则：测试发现的错误中80%很可能起源于20%的模块中。
• 测试从“小模块”开始，逐步转向“大规模”。
• 穷举测试是不可能的。

对象：

• 软件包括程序、数据和文档，软件测试并不等于程序测试。
• 软件测试应贯穿于软件定义与开发的整个其间。
• 开发过程所得到的文档，都应成为软件测试的对象。
• 验证与确认都属于软件测试，它 包括对软件分析、设计以及程序的验证和确认。
  • 验证：是保证软件符合产品描述的过程。
  • 是保证软件满足用户要求的过程。

缺陷：

• 软件未达到产品描述表明的功能。
• 软件出现了产品描述指明不会出现的错误。
• 软件功能超出产品描述指明范围。
• 软件未达到产品描述虽未指出但应达到的目标。
• 软件测试人员认为软件难以理解、不易使用、运行速度缓慢、或者最终用户认为不好。

缺陷产生的原因：

• 编写代码
• 设计
• 编写产品描述
• 其他

特征：

• 软件测试具有一定的风险：完全测试是不可能的，如果决定不去测试所有的情况，那就是选择了风险。
• 软件缺陷的寄生虫性：找到的软件缺陷越多，就说明软件缺陷越多。
• 软件测试的杀虫剂现象：软件测试越多，其免疫力越强的现象。
• 软件测试的不修复原则 ：并非所有软件缺陷都能修复。有些缺陷不需要修复：*没有足够的时间*不算真正的软件缺陷* 修复的风险太大*不值得修复。

软件测试方法、技术和策略
框架：

1. 静态测试方法
   1. 人工测试方法
   2. 计算机辅助静态分析方法
2. 动态测试方法
   1. 白盒测试方法
   2. 黑盒测试方法

静态测试：
基本特征

• 对软件进行分析、检查和审阅，不实际运行被测试的软件。
• 静态测试约可找出30-70% 的逻辑设计错误 。

比如说：对需求规格说明书、软件设计说明书、原程序作检查和审阅。



动态测试：
基本特征：
通过运行软件来检验软件的动态行为和运行结果的正确性。
两个基本要素：

• 被测试程序
• 测试数据（测试用例）

动态测试方法流程

• 选取定义域有效值，或定义域外无效值
• 对已选取值决定预期的结果
• 用选取值执行程序
• 执行结果与对已选取值决定预期的结果相比，不吻合程序有错。

白盒测试：

• 结构测试（玻璃盒测试）
• 对软件的过程性细节做细致的检查
• 可利用程序内的逻辑结构，设计或选择测试用例，对程序的逻辑罗景警醒测试。

 白盒测试方法：

• 逻辑覆盖
  • 语句覆盖：被测程序中每个语句至少执行一次
  • 判定覆盖:使每个判定的真假分支都至少执行一次
  • 条件覆盖：每个语句至少执行一次，切实判定表达式中的每个条件都取到各种可能的结果
  • 判定/条件覆盖：判定每个条件的所有可能条件至少执行一次，同时每个判定的所有的可能判定结果至少执行一次。
  • 条件组合覆盖：所有可能的条件去之组合至少执行一次
• 控制结构测试
  • 基本路径测试：通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次
  • 条件测试：是检查程序模块中包含的逻辑条件。
  • 循环测试：专注于测试循环结构的有效性
    • 简单循环
    • 嵌套循环
    • 串接循环

黑盒测试：

• 功能测试（行为测试）
• 数据驱动测试
• 注重测试软件的功能性需求
• 在程序借口进行测试，只检查程序功能是否按规格说明书的规定
• 不深入代码细节的测试

测试方法：

• 等价划分
• 边界值分析
• 错误推测
• 其他方法

等价划分：
基本思想：
将所有可能的输入数据（有效的和无效的）划分成若干个等价类，从每个等价类中只取一组数据作为测试数据。
基本步骤：

• 划分输入数据的等价类（有效和无效）
  • 等价类：指某个输入域的子集合，在该子集合中，个个输入数据对于揭露程序中的错误是等效的。
• 涉及测试方案
  • 不断地覆盖所有的有效等价类
  • 不断地覆盖所有的无效等价类

划分等价类的规则：

1. 如果输入条件规定了取值范围，可定义一个有效等价类和两个无效等价类。
2. 如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。
3. 如规定了输入数据的一组值， 且程序对不同输入值作不同处理，则每个允许的输入值是一个有效等价类，并有一个无效等价类（所有不允许的输入值的集合）。
4. 如果规定了输入数据必须组遵循的规则，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
5. 如已划分的等价类各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。

 边界值分析：
通过关注于在某等价类的“边缘”的数据而扩展了等价划分。
与等价划分的区别：

• 边界值分析不是从某等价类中随便挑一个作为代表， 而是使这个等价类的每个边界都要作为测试条件。
• 边界值分析不仅考虑输入条件，还要考虑输入空间产生的测试情况。

边界值分析的步骤：
确定边界情况：

• 输入等价类和输出等价类的边界，就应该着重测试的程序边界的情况。
• 选取的测试数据应刚好等于，刚好小于鹤岗好大于边界值。
• 联合使用等价划分和边界值分析两技术。

因果图：

• 描述对于多种条件的组合，相应产生多个动作的形式。适合于检查程序输入条件的各种组合情况。

使用因果图设计测试用例：

• 考虑了多个输入之间的相互组合，相互制约关系。
• 能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出， 程序规格说明描述中存在着什么问题

利用因果图导出测试用例的一般步骤

• 分析程序规格说明的描述中，哪些是原因，哪些是结果。
• 分析程序规格说明的描述中语义的内容，并将其表示城连接各个原因与各个结果的因果图
• 在因果图上使用若干个特殊的符号表明特定的约束条件
• 把因果图转换成判定表
• 把判定表中每一列表示的情况写成测试用例

错误推测：
基本思想：

• 列举程序中可能有的错误和容易发生的特殊情况，并且根据他们选择测试方案

软件测试模型：

• v模型：按时间顺序进行：用户需求，需求分析与系统设计，概要设计，详细设计，编码，单元测试，集成测试，确认测试与系统测试，验收测试
  • 它是最具具有代表意义的测试模型
  • 它是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。
  • 从左到右，描述了基本的开发过程和测试行为，非常明确的表明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
  • 箭头代表了时间方向 ，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即个测试过程的各个阶段。
• w模型
  • v模型存在一定的局限性，它仅仅把测试过程作为在需求分析，概要设计，详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试徐兆错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。
  • 在v模型中曾家软件各开发阶段应同步进行的测试，被演化为一种w模型。
  • 开发是v，测试也是与此相重叠的v。
  • 相比于v模型，w模型更科学。w模型可以说是前者自然而然的发展，它强调:测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求，功能和设计同样要测试。
  • 测试与开发是同步进行的，从而有利于仅在地发现问题。与需求为例，而不是等到最后才进行针对需求的验收测试。
  • 测试不仅仅是评定软件的质量，测试还可以尽可能早的找出缺陷所在，从而帮助改进项目内部的质量。
• x模型

 软件测试技术：
静态测试的技术主要有：代码走查，技术评审，代码审查。
黑盒测试的技术主要有：功能测试，性能测试，攻击测试。
回归测试：程序修改或者版本更新以后，为了确保以前正确的能能和其他指标仍旧正确，而重新进行的测试。
测试过程分为：

• 单元测试：
  • 检验程序最小单元有无错误。接口、数据结构、边界、覆盖、逻辑。检验单元编码与设计是否吻合。
  • 时机：编码完成后，首先要实施的测试。
  • 方法：静态测试，白盒测试
  • 责任：开发工程师
• 集成测试：
  • 目标：检验组成系统的模块节后有无错误。代码实现的系统设计与需求定义是否吻合。
  • 时机：主要的单元测试完成后，经常与单元测试同步进行。
  • 方法：黑盒测试
  • 责任：开发工程师，测试工程师
• 系统测试：
• 目标：检验组成整个系统的代码、以及系统的软硬件配合有无错误
• 代码实现的系统与用户需求是否吻合
• 检验系统的文档等各种是否完整、有效
• 模拟验收测试的要求，检察系统是否符合用户的验收标准
• 时机：多数集成测试完成后
• 方法：黑盒测试
• 责任：测试工程师
• 系统测试----稳定期测试
• 目标：度量是否可以结束测试
• 时机：传统的系统测试完成后
• 方法：黑盒测试
• 责任：测试工程师
• 验收测试：
• 目标：使客户验收签字，系统是否符合事先约定的验收标准。
• 时机：系统测试完成后，在项目组开来开发和测试工作已经全部完成，可以交付使用。
• 方法：黑盒测试
• 责任：产品经理或其他高级经理，开发工程师，测试工程师，用户。
• 回归测试：
• 目标:验证程序修改或者版本更新以后，以前正确的功能和其他指标仍旧正确。
• 时机：每次错误修改之后，或者版本更新之后。
• 方法：白盒测试，黑盒测试
• 责任：开发工程师，测试工程师
• 缺陷跟踪：
• 目标：确保所有发现的错误被正确记录、分发、评估、关闭、统计
• 时机：从错误发现开始到错误关闭为止，每次错误装袋修改之后。
• 方法：缺陷跟踪系统
• 责任：开发工程师，测试工程师,测试经理，用户