软件测试基础理论

1.基础概念

检查软件产品是否符合设计的要求。

目的：以最小的人力、物力和时间找出软件中潜在的错误和缺陷。

原则：

• 证明软件中存在缺陷
• 不能穷尽测试
• 测试应该尽早介入
• 28原则：80%的错误是由20%的模块引起的；80%的测试成本、测试时间花在20%的软件模块中；
• 不存在缺陷谬论
• 妥善保存一切文档

标准：国际：ISO 25010；国内：GBT 20438、GBT 18905

基本要求：

• 外观界面测试
• 易用测试
• 兼容性测试
• 安全性测试
• 性能测试
• 功能测试

2.测试流程与开发模型、测试模型

测试流程

1. 需求分析：阅读需求文档、产品文档、产品详细设计说明书，分析需求，参与需求评审；快速熟悉项目
2. 测试计划和测试方案：（5W 1H）测试计划指测试整个项目的总体的规划，包括测试范围、进度安排、人力物力安排、整体测试策略、风险评估、风险的规避等；测试方案决定被测试的目标、选取测试工具、测试方法、测试重点等。
3. 测试用例设计：边界值、等价类……
4. 测试用例执行
5. 评估阶段 测试报告

开发模型

1.瀑布模型

文档驱动型

特点：

• 阶段间具有顺序性和依赖性
• 推迟实现
• 质量保证观点

优点：

• 提供按阶段划分的检查点
• 当前阶段完成后，只需要关注后续阶段
• 在迭代模型中可应用瀑布模型

缺点：

• 不适合需求模糊或需求经常变动的系统
• 不希望存在早期阶段的反馈
• 在系统完成前，无法预测一个新系统引入一个机构的影响
• 用户可能需要等待较长时间来获得可供使用的系统，可能对用户信任程度带来影响

2.快速原型

快速分析 -> 构造 -> 运行 -> 评价

即快速建立起来的可以在计算机上运行的程序。

优点：减少由于软件需求不明确带来的开发风险，适合预先不能确切定义需求的软件系统的开发

缺点：

• 所选用的开发技术和工具不一定符合主流的发展
• 快速建立起来的系统架构和连续修改可能会导致产品质量低下
• 使用前提是有一个展示性的产品原型，一定程序上会限制开发人员的创新

3.增量模型

把瀑布模型的顺序特征和快速原型法的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

4.其他开发模型

螺旋开发模型：制定计划 -> 风险分析 -> 实施工程 -> 客户评估

迭代开发模型：迭代不能并行

敏捷开发模型：简单设计、快速实现

3.测试模型

1. V模型

优点：每个阶段都清晰明了，便于控制开发的每个过程，既包含单元测试又包含系统测试。

缺点：测试介入较晚，对于前期的一些缺陷无从发现和修改，测试和开发串行，总用时较长。

2. W模型

优点：测试伴随软件的整个生命周期。

缺点：对需求和测试技术要求高。

3.软件测试分类

4.测试用例

1.定义

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

2.特性

• 有效性：测试用例能够被使用，且被不同人员使用时测试结果一致。
• 可重复性：良好的测试用例具有重复使用的功能，如回归测试。
• 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用。
• 可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准。
• 可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准。

3.测试用例的八大要素

• 测试用例编号：具有唯一性、容易识别。
• 测试项目/模块：测试项目属于哪个项目或被测试的需求、被测的模块、被测的单元等。
• 预置条件：执行当前测试用例需要的前提条件。
• 测试输入：测试用例执行过程中需要加工的外部信息。
• 预期输出：测试用例的预期输出结果，包括返回值内容、界面响应结果等。
• 操作步骤：执行当前测试用例需要经过的操作步骤，需明确地给出步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行。
• 测试用例标题：对测试用例的简单描述，用概括的语言描述该测试用例的测试点，每个测试用例的标题不能够重复，因为每个测试用例的测试点是不同的。
• 级别：高级别（保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例）、中级别（介于高和低之间）、低级别（实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例）。
• 其他要素：用例的设计者、用例设计日期、对应的开发人员、测试结果、测试类型等。

4.设计原则

• 明确性：测试过程中，测试用例的测试结果是唯一的。
• 代表性：合并功能相似的用例。
• 简洁性：测试用例简洁，可读性好，测试过程目的明确，测试结果唯一。

5.力度

• 简单：测试的纲要。
• 复杂：包含具体的输入项、步骤、预期结果。
• 中庸：介于两者之间。

6.总结

测试用例的本质是理解需求、反映需求、忠于需求。

方法的选取：

• 关注主要功能和业务流程、业务逻辑是否正确实现，考虑场景法。
• 需要输入数据，考虑等价类划分法。
• 任何情况都使用边界值法。
• 如果程序功能包含输入条件的组合情况，选取因果图和判定表法。
• 配置类软件需要考虑参数的组合情况，考虑正交排列法。
• 对照程序逻辑，若发现没有达到要求的覆盖标准，适当补充测试用例。
• 采用错误推断法，追加其他测试用例。

7.评审

1.同行评审：个体和交互比过程和工具更有价值。

2.用户评审：顾客的协作比合同谈判更有价值。

5.测试用例设计方法

1.等价类划分法

1.定义：把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。

使用该方法设计测试用例要经历划分等价类和选取测试用例两步。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

2.有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：指对于程序的规格说明来说是不合理的、无意义的输入数据构成的集合。利用有效等价类可检验程序对于无效数据的处理能力，检测程序的健壮性、容错能力。

2.边界值法

1.定义：对输入或输出边界值进行测试。通常作为等价类划分法的补充，其测试用例来自等价类的边界。

上点、离点、内点。

3.因果图法

1.定义：利用图解法分析输入的各种组合情况，从而设计测试用例的方法，适合于检查程序输入条件的各种组合情况。

2.特点：考虑输入条件的相互制约及组合关系；考虑输出条件对输入条件的依赖关系。

恒等、非（～）、或（V）、与（^）

• E：约束（互斥），最多有一个成立
• I：包含，至少有一个成立
• M：强制（屏蔽），a成立，b一定不成立
• O：唯一，有且仅有一个成立
• R：要求，a成立，b也一定成立

3.步骤：

• 找出所有原因（输入条件/输入条件的等价类）
• 找出所有结果（输出条件）
• 明确所有输入条件之间的制约关系及组合关系
• 明确所有输出条件之间的制约关系及组合关系
• 找出哪种输入条件的组合会产生哪种输出结果
• 把因果图转换成判定表/决策表
• 为每列表示的情况设计测试用例

4.判定表法

1.定义：又称决策表。针对不同逻辑条件的组合值，分别执行不同的操作。适合有个多个输入和多个输出，输入和输出有相互的组合关系，输入输出之间有相互的制约和依赖关系。

2.组成：

• 条件桩：列出问题的所有条件。
• 条件项：列出所有可能情况下的真假值。
• 动作桩：列出问题规定可能采取的操作。
• 动作项：列出在条件项的各种取值情况下采取的动作。

规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。

化简：规则合并。有多条规则具有相同动作，并且其条件项之间存在着极为相似的关系。

5.正交表法

1.定义：又叫正交实验法、正交排列法，通过少数的试验替代全面试验。在一项试验中，把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。

allpairs工具

6.场景法

1.定义：从起点，通过一系列操作步骤（事件），达成某一结果，到终点的过程测试。适用于冒烟测试。

现在软件几乎都是由事件触发来控制流程的，事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果形成了事件流。

7.流程分析法

1.定义：针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，借鉴白盒测试设计方法中的路径覆盖分析法。

8.错误推断法

1.定义：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

6.缺陷

1.定义：从内部看，软件缺陷是产品开发或维护过程中存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要表现的某种功能的失效或者违背。最终表现为所需要的功能没有完全实现，没有满足用户的需求。

2.具体包括：未达到需求规格说明书中的功能；出现了需求规格说明书中指名不会出现的错误；功能超出了需求规格说明书的范围；未达到需求规格说明书中虽没有指名，但应该达到的目标；测试人员或用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好。

3.表现形式：功能、特性没有实现或者部分实现；设计不合理，功能特性不明显，逻辑不清楚或者存在矛盾；产品实际结果和所期望的结果不一致；没有达到需求规格说明书所规定的性能指标；运行出错、中断、奔溃、界面混乱；数据不正确，精度不够、不完整，格式不统一；用户不能接受的其他问题，超时，界面丑陋；硬件或者系统软件上存在的其他问题。

4.原因：需求解释或者记录错误；用户需求定义错误；需求说明存在错误；编码说明、程序代码有误；硬件或者系统存在错误；文档错误、内容不正确、拼写错误。

5.根源：交流不充分；软件的复杂性；开发任务的错误；需求的变化；进度压力。

1.缺陷报告

1.5C原则：

• 准确
• 简洁
• 清晰
• 完整
• 一致

一个缺陷一个报告。

2.缺陷统计

1.作用：

• 风险评估
• 缺陷原因
• 员工技能提升
• 团队配置

2.缺陷密度：单位 缺陷数量/kloc

计算：总缺陷数量/（总代码行数/1000）

3.缺陷的管理

CMM 软件能力成熟度模型

• 初始级
• 可重复级
• 已定义级
• 已管理级
• 优化级