part Ⅰ
测试基础
三种质量模型-“产品质量模型”分析
产品质量模型如图所示：
一级指标“功能性”
“功能性”指标是指：当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。
- 适合性。软件产品为指定的任务和用户目标提供一组合适的功能的能力
- 准确性。软件产品提供具有所需精度的正确或相符的结果或效果的能力
- 互操作性。软件产品与一个或更多的规定系统进行交互的能力
- 安全保密性。软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问。
一级指标“可靠性”
“可靠性”指标是指：在指定条件下使用时，软件产品维持规定的性能级别的能力。
- 成熟性。软件产品为避免由软件中故障而导致失效的能力。
- 容错性。在软件出现故障或者违反其指定接口的情况下，软件产品维持规定的性能级别的能力。
- 易恢复性。在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。
一级指标“易用性”
在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
- 易理解性。软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务和使用条件的能力。
- 易学性。软件产品使用户能学会其应用的能力。
- 易操作性。软件产品使用户能操作和控制它的能力。
- 吸引性。软件产品吸引用户的能力。
一级指标“效率”
在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
- 时间特性。在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。
- 资源利用性。在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。
一级指标“可维护性”
软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应。
- 易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
- 易改变性。软件产品使指定的修改可以被实现的能力。
- 稳定性。软件产品避免由于软件修改而造成意外结果的能力。
- 易测试性。软件产品使已修改软件能被确认的能力。
一级指标“可移植性”
软件产品从一种环境迁移到另外一种环境的能力。
- 适应性。软件产品毋需采用额外的活动或手段就可适应不同指定环境的能力。
- 易安装性。软件产品在指定环境中被安装的能力。
- 共存性。软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
- 易替换性。软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力。
产品质量模型各指标间相关性
三种质量模型-“使用质量模型”分析
使用质量模型如图所示：
- 有效性。软件产品在指定的使用周境下，使用户能正确和完全地达到规定目标的能力。
- 生产率。软件产品在指定的使用周境下，使用户为达到有效性而消耗适当数量的资源的能力。
- 安全性。软件产品在指定使用周境下，达到对人类、业务、软件、财产或环境造成损害的可接受的风险级别的能力。
- 满意度。软件产品在使用环境中，让用户感到满意的程度。
五种软件测试的分类-按软件的“不同阶段”分类
五种分类方式
- 按软件的“不同状态”分类
- 按软件的“不同阶段”分类
- 按软件的“不同特性”分类
- 按软件的“不同开发方式”分类（业界）
- 按测试的“不同方法”分类（学界）
按不同阶段分类
- 单元测试：对程序员编写完成的某个程序单元测试；
- 集成测试（组装测试）：将所有程序单元（模块）进行有序的、递增的组装并测试。
发现模块间接口以及全局数据结构等问题。
- 确认测试：通过检验和提供客观证据，证明软件是否满足《软件需求说明书》中规定的需求。
- 系统测试：为确认是否达到原始目标，对集成的硬件和软件系统进行的测试。检查完整的程序系统能否和系统（硬件、外设、网络和系统软件、支持平台等）正确配置、连接、并满足用户需求。
- 验收测试：按照项目任务书或合同、供需双方约定的验收依据文件进行的对整个系统的测试与评审，决定是否接收或拒收系统。
回归测试
回归测试：重复以前的全部或部分的相同测试。
- 目的：软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。回归测试就是为确定修改和检查修改是否损害了原有的正常功能。
- 重要性：回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在极端编程方法中，更是要求每天都进行若干次回归测试。
附：简述“验证”与“确认”的区别？
- 验证：过程正确，符合设计规范
- 确认：结果正确，符合客户要求
软件测试的一组重要观点-软件错误的四种现象
- 软件未达到产品说明书标明的功能
- 软件不能正常运行
- 软件未达到产品说明书虽未指出但应达到的目标
- 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
软件测试的一组重要观点-软件测试的成本
- 测试在软件开发中占有重要地位
- 测试成本占有开发成本的近一半
如：
附：软件测试的七条基本原则
- 初心原则。所有软件测试，都应追溯到用户需求
- 从速原则。尽早地和不断地进行软件测试
- 折衷原则。完全测试是不可能的，测试需要终止条件（原因：输入量太大；输出结果太多；路径组合太多）
- 不完备原则。测试无法显示软件潜在的缺陷
- 正比原则。测试后程序中残存的错误数目与该程序中已经发现的错误数目成正比
- 回避原则。程序员应避免检查自己的程序
- 设计原则。遵循PDCA规律，避免测试的随意性
软件测试的一组重要观点-软件测试的一组“重要论断”
- “零缺陷软件”是不可能的，只是一个可望不可及的目标；
- 完全测试程序是不可能的
- 测试只能证明错误存在，不能证明错误不存在
- 测试应当循序渐进，不应企图一次性测完
- 80-20原则：80％的错误聚集在20％的模块中，经常出错的模块改错后还会经常出错
- 找到的软件缺陷越多，说明软件缺陷越多
- 并非所有软件缺陷都能修复
- 需求说明书总是在不断变化
- 测试资源是很有限的
- 软件测试人员通常在项目组中不受欢迎
黑盒测试
黑盒测试（功能测试），又被称为数据驱动测试、基于规格说明的测试或用户测试
边界值分析-基础定义
三个点的定义
- 内点：在域范围内的任意一个点；
- 上点：边界上的点（无论开区间、闭区间）。
- 离点：离上点最近的一个点，且满足：
1）如边界封闭，则域范围外离上点最近的点；
2）如边界开放，则域范围内离上点最近的点。
“边界值”定义
边界上的一组“上点”和“离点”分别构成了这个边界域范围的“内/外”边界值。域的边界被“夹”在上点与离点之间。
常见的几类边界
- 报表的第一行和最后一行
- 数组元素的第一个和最后一个；
- 循环的第0次、第1次、倒数第2次、最后1次等
- 2字节的正整数边界：65535；65536
常见边界的边界值
四种黑盒测试技术
- 等价类划分法
关键1：如何划分等价类
关键2：设计测试用例，覆盖等价类
- 边界值分析法
关键1：用“单故障假设”逐一分解要素
关键2：对每个要素，寻找到它独特的“边界”
关键3：用“上点”、“离点”覆盖“边界”
- 错误推测法
关键1：根据“经验”，从“时间、人、技术”等 ，对错误进行“聚类”
关键2：根据所聚类型，增加一组测试用例
- 判定表驱动法
关键1：识别所有条件、动作，画“判定表”
关键2：根据需求，填“判定表”，并规约
关键3：根据规约后的“判定表”设计测试用例
白盒测试
白盒测试（结构测试），又被称为逻辑驱动测试、基于程序本身的测试或程序员测试
逻辑覆盖的6种方法-一组实例
