关于软件测试的一些笔记

Charpter1

等价类划分

边界值划分

显式功能性需求（Functional requirement）的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能

非功能性需求（Non-functional requirement），从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。

测试的不可穷尽性，即绝大多数情况下，是不可能进行穷尽测试的。

在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

Charpter2

整体思路

1. 整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

2. 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

3. 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。

测试方法：

对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。

　　错误推测方法：这个方法过于依赖个人能力

　　+ 错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。

  + 为了降低对个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表（checklist），去帮助优化补充测试用例的设计。

  + 对于测试基础架构比较成熟的中大型软件企业，通常会以该缺陷知识库作为数据驱动测试的输入来自动生成部分的测试数据

  + 在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。

在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。

也就是  “用户的业务——组成业务的软件功能——针对功能1对1的测试需求点——针对测试需求点设计测试用例”