软件测试的基础知识

测试基础测试基础 软件测试定义 使用人工和自动手段来运行或测试某个系统的过程 其目的在于检验它是否满足规 定的需求或是弄清预期结果与实际结果之间的差别 软件生命周期 软件生命周期包括几个阶段 1 计划 planning 1 确定软件开发总目标 2 给出软件的功能 性能 可靠性以及接口等方面的设想 3 研究完成该项目的可行性 探讨问题解决方案 4 对可供开发使用的资源 成本 可取得的效益和开发进度做出估计 5 制定完成开发任务的实施计划 2 需求分析 requirement analysis 对开发的软件进行详细的定义 由需求分析人员和用户共同讨论决定并给予 确切的描述 写出软件需求规格说明书 SRS Software Requirement Specification 3 设计 design 设计是软件工程的技术核心 这个阶段需要完成设计说明书 概要设计 HLD 详细设计 LLD 4 程序编码 coding 把软件设计转换成计算机可以接受的程序 即写在以某个程序设计语言表示 的源程序清单 使用 RDBMS 工具建立数据库 5 测试 testing 单元测试 UT 参照 LLD 对每一个函数进行测试 集成测试 IT 参照 HLD 对函数与函数的集成 模块与模块的集成进行测试 系统测试 ST 参照 SRS 对每个功能需求 性能需求等进行测试 6 运行和维护 run and maintenance 本阶段将软件交付用户投入正式使用 以后便进入维护阶段 可能有多种原 因需要对它进行修改 如软件错误 系统软件升级 增强软件功能 提高性 能等 缺陷的类型 缺陷 Defect 以静态的形式存在于软件内部 可被激活 相当于 Bug 故障 Fault 当缺陷被激活后 软件运行中出现的状态 可引起意外情况 不处理会产 生失效 是动态行为 失效 Failure 软件运行时产生的外部异常行为结果 表现与用户需求不一致 功能能 力终止 用户无法完成所需要的应用 测试用例 Test Case 包括 测试用例编号 测试项目 测试标题 重要级别 预置条件 输入 执行步骤 预期输出 测试工程师的主要工作 1 检视代码 评审开发文档 2 进行测试设计 写作测试文档 测试计划 测试方案 测试用例 3 执行测试 发现软件缺陷 提交缺陷报告 并确认缺陷最终得到了修正 4 通过测试度量软件的质量 测试过程测试过程 单元测试 UT 是针对软件基本组成单元 软件设计的最小单位 来进行正确性检验的测试工作 单元 测试的目的是检测软件模块对 详细设计说明书 LLD 的符合度 Unit Testing 集成测试 IT 是在单元测试的基础上 将所有模块按照概要设计要求组装成为子系统或系统 验证 组装后功能以及模块间接口是否正确的测试工作 其目的是检测软件模块对 概要设 计说明书 HLD 的符合度 Integration Testing 系统测试 ST 是将已集成好的软件系统 作为整个基于计算机系统的一个元素 与计算机硬件 外 设 某些支持软件 数据和人员等其他系统元素结合在一起 在实际运行 使用 环境 下 对计算机系统进行一系列的测试工作 其目的在于通过与 需求规格说明书 SRS 作 比 较 发现软件与系统需求定义不符合或与之矛盾的地方 System Testing UT IT ST 比较区别 1 测试方法不同 UT 属于白盒测试范畴 IT 属于灰盒测试范畴 ST 属于黑盒测试范畴 2 考察范围不同 UT 主要测试单元内部的数据结构 逻辑控制 异常 处理等 IT 主要测试模块之间的接口和接口数据传递关系 以及模块组合后的整体功能 ST 主要测试整个系统相对于需求的符合度 3 评估基准不同 UT 评估基准主要是逻辑覆盖率 IT 评估基准主要是接口覆盖率 ST 评估基准主要是测试用例对需求规格的覆盖率 回归测试 Regression Testing 软件在测试或其他活动中发现的缺陷经过修改后 应该进行回归测试 目的是 验证错误是否修复 并检测对代码的修改是否引入了新的错 误 回归测试可以发生在任何一个阶段 包括 UT IT ST 回归测试策略包括 完全重复测试和选择性重复测试 验收测试 Acceptance Testing 是根据合同 需求规格说明书 SRS 验收测试计划 对产品进行 验 收和测试 一般采用 测试和 测试 测试 是由用户在开发环境下进行的测试 也可以是开发机构内部的用户在模拟实际操作环境下 进 行的测试 开发者坐在用户旁边 随时记下错误情况和使用中的问题 这是在受控制的环 境 下进行的测试 其目的主要是评价软件产品的 FLURPS 功能 局域化 可用性 可靠性 性 能等 尤其注重产品的界面和特色 测试 由软件的多个用户在一个或多个用户的实际使用环境下进行的测试 测试时开发者通常 不 在现场 因而 测试是在开发者无法控制的环境下进行的软件现场应用 测试中由用户记 录下遇到的所有问题 包括真的和主观认定的 定期向开发者报告 开发者在综合用户的 报 告后作出修改 再将软件交付给全体用户使用 测试过程模型 V CODE 阶段生产率 KLOC 人天 UT IT ST 用例设计阶段生产率 用例 人天 测试执行效率测试执行效率 执行用例数 人天 按测试阶段进行度量 用例密度 用例密度 用例数 KLOC 按测试阶段进行度量 用例密度说明用例设计的充分性 需求稳定性 需求稳定性 变更过的需求数 总需求数 测试方法测试方法 白盒测试白盒测试 White Box Testing 白盒测试又称 玻璃盒测试 Glass Box Testing 透明盒测试 Clear Box Testing 开放盒测试 Open Box Testing 结构化测试 Structured Testing 基于代码的测试 Code Based Testing 逻辑驱动测试 Logisc Driven Testing 白盒测试技术一般可分为以下两类技术 静态分析 控制流分析技术 数据流分析技术 信息流分析技术 动态分析 逻辑覆盖率测试 分支测试 路径测试等 程序插装等 逻辑覆盖率 语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 路径覆盖 黑盒测试黑盒测试 Black Box Testing 又称 功能测试 Functional Testing 最常见的黑盒测试有 功能性测试 容量测试 安全性测试 负载测试 恢复性测试 标杆测试 稳定性测试 可靠性测试 外场测试 必须有用户参加 类似 Beta 测试 实验室测试 必须有用户参加 类似 Alpha 测试 白盒测试只考虑测试软件代码 它不保证完整的需求规格是否被满足 黑盒测试只考虑测试需求规格 它不保证实现的所有部分是否被测试 到 黑盒测试会发现遗漏的缺陷 指出规格的部分没有被完成 白盒测试会发现代码方面缺陷 指出实现部分是错误的 灰盒测试灰盒测试 Grey Box Testing 是界于白盒测试和黑盒测试之间的测试 常见的灰盒测试是 集成测试 按被测对象是否被运行起来 可分为 静态测试静态测试和动态测试动态测试 自动化静态分析工具 语法分析器和符号执行器 静态分析中的手工技术 软件检视和走读 配置管理配置管理 配置管理 配置管理就是通过对在软件生命周期的不同的时间点上所产生的文件进行标识 并对这 些被标识的文件的更改进行系统控制 从而达到保证软件产品的完整性和可溯性的过程 基线化 在配置管理系统中 基线就是配置项在其生命周期的不同时间点上通过 Review 而进入正式 受控的一种状态 而这个过程被称为 基线化 每一个基线都是其下一步开发的基准 常用的配置管理工具 商用 IBM Rational ClearCase VSS Microsoft Visual Sourcesafe Borland StarTeam 开源 CVS Concurrent Version System SVN TortoiseSVN 软件配置管理的过程 配置计划 配置标识 配置控制 配置状态发布 配置审计 配置管理 SCM Software Configuration Management 项目经理 PM Project Manager 变更控制委员会 CCB Change Control Board or Configuration Control Board 配置管理员 CMO Configuration Management Officer 配置项 CI Configuration Item 变更申请 CR Change Request 基线 Baseline 需求管理需求管理 同行评审的类型 正规检视 技术评审 走读 变更控制流程 需求跟踪表 RTM 前景和范围 vision and scope 业务需求 Business requirement 粒度好 fine grained 市场需求 Project charter 或 market requirement 待确定 TBD 用户需求 user requirement 需求工程 requirement engineering RE 系统需求 system requirement 需求获取 requirement elicitation 功能需求 functional requirement 可扩充 open ended 行为需求 behavioral requirement 关键过程域 key process areas KPA 软件需求规格说明 software requirement specification SRS 工作任务书 SOW Statement of Work 建模的定时和目的 timing and intent of the modeling 审核 Certification 总体会议 overview meeting 准备 Preparation 评审会议 inspection meeting 重写 rework 重审 follow up 工作流 workflow 制定配置管理计划配置库操作 配置审计 版本控制 产品发布 变更操作 对已经基线化 的 SRS 的 CRs PM 将修改意见 方案 影响范围 工作量估 计等提交给 CCB CCB 裁决 结束 更新的 SRS评审 签发 SRS 修改 SRS RTM 更新的 RTM 结束 NO YES 需求管理活动 需求分配 需求跟踪 需求评审 需求基线 变更控制 软件开发过程 分析阶段 需求分析 计划 设计阶段 概要设计 详细设计 测试设计 需求已设计 实现阶段 编码 项目开始 需求分配 需求分析 需求跟踪 建立需求基线 需求跟踪 项目结束 变更控制 软件需求评审 需求变更 需求变更 需求变更 需求变更 需求跟踪 需求跟踪 需求跟踪 需求已开发 测试阶段 单元测试 集成测试 系统测试 需求已测试 需求已验证 通用用例写作通用用例写作 通用用例八要素 用例编号 用例编号 产品编号 ST IT UT 测试项名 测试子项名 XXX 测试项目 测试项目 ST 功能点 功能测试 性能指标 性能测试 界面中控件 GUI 测试 等 IT 集成后的模块功能或者内部接口 UT 对应函数名 测试标题 测试标题 测试目的 重要级别 重要级别 高 中 低 预置条件 预置条件 环境的设置 先要运行的其它用例等 测试输入 测试输入 手工输入 文件 数据库存记录等需要加工的外部信息 操作步骤 操作步骤 明确写出每一步骤的描述 预期输出 预期输出 可从三个方面考虑 界面显示 数据库的变化 相关信息的变化 缺陷管理缺陷管理 软件缺陷相关属性 缺陷发现人 缺陷发现时间 缺陷状态 缺陷严重程度 缺陷所属版本 缺陷修改日期 软件缺陷的状态 New Open Fixed Closed Reopen Postpone Rejected Duplicate Abandon 缺陷的严重程度 Critical 致命 Major 严重性 General 一般 Suggest 提示 缺陷报告的写作要点 标题 状态 严重级别 优先级 详细步骤 版本 环境 发现人 发现时间 修复人 修复时间 附件 缺陷记录的写作要点 序号 缺陷 ID 测试者 缺陷描述及重现缺陷操作 等级 出现频率 状态 解决方法 解决人 解决日期 验证人 验证日期 软件缺陷管理工具 商用 Mercury Quality Center Rational ClearQuest 开源 Bugzilla Mantis Jira 测试覆盖率测试覆盖率 白盒测试覆盖率 逻辑覆盖 语句覆盖 指令块覆盖 判定路径覆盖 灰盒测试覆盖率 函数覆盖 接口覆盖 黑盒测试覆盖率 功能覆盖率 最常见的是需求覆盖 面向对象的覆盖率 继承上下文覆盖 基于状态的上下文覆盖 基于线程的上下文覆盖 单元测试单元测试 单元测试 目的是在于发现各模块内部可能存在的各种错误 主要是基于白盒测试 有三方面 1 验证单元代码和详细设计文档的一致性 2 跟踪详细设计文档中设计的实现 发现详细设计文档中存在的错误 3 发现在编码过程中引入的错误 单元测试关注的错误重点 单元接口 被测单元的输入输出参数在个数 属性 顺序上和 LLD 中的 描述不一致 修改了只做输入用的形式参数 可能会导致数据的错误修 改 约束条件通过形式参数来传送 导致函数间的控制耦合增 大 局部数据结构 不正确或不一致的数据类型说明 使用尚未赋值或尚未初始化的变量 错误的初始值或错误的缺省值 变量名拼写错误或书写错误 不一致的数据类型 独立路径 运算的优先次序不正确或误解了运算的优先次序 运算的方式错误 不同数据类型的比较 关系表达式中不正确的变量和比较符 差 1 错 即不正确的多循环或少循环一次 错误的或不可能的循环终止条件 不适当地修改了循环变量等 出错处理 出错的描述难以理解 出错的描述不足以对错误定位和确定出错的原因 显示的错误与实际的错误不符 对错误条件的处理不正确 在对错误进行处理之前 错误条件已经引起系统的干预等 边界条件 在 n 次循环的第 n 次 取最大最小值时容易发生错误 特别要注意数据流 控制流中刚好等于 大于 小于确定 的比较值时出现错误的可能性 无论是 UT 还是 IT 都涉及到以下三个函数 主控函数主控函数 int ctrl int x int y 加法函数加法函数 intadd int x int y 减法函数减法函数 intsub int x int y 辅助测试单元 驱动单元 Driver 和桩单元 Stub 单元测试策略 孤立的单元测试策略 Isolation Unit Testing 自顶向下的单元测试策略 Top Down Unit Testing 自底向上的单元测试策略 Bottom Up Unit Testing 混和测试 单元测试过程 UT 计划阶段 完成 UT 计划 UT 设计阶段 完成 UT 方案 UT 实现阶段 完成 UT 用例 UT 规程 UT 脚本 数据文件的编写工作 UT 执行阶段 执行 UT 用例 修改发现的问题并进行回归测试 提交 UT 报告 集成测试集成测试 集成测试目的 确保各组件组合在一起后能够按既定意图协作运行并确保增量的行为正确 集成测试关注的重点 接口和功能 集成测试划为三个级别 1 模块内 IT 2 子系统内 IT 3 子系统间 IT 集成测试策略 自底向上 Bottom Up Integration 自顶向下集成 Top Down Integration 大爆炸集成 Big Bang Integration 三明治集成 Sandwich Integration 基干集成 Backbone Integration 其他 分层集成 Layers Integration 基于功能的集成 Function Based Integration 高频集成 High frequency Integration 基于进度的集成 Schedule Based Integration 基于风险的集成 Risk Based Integration 基于事件 消息 的集成 Message Based Event Based Thread Based Integration 基于使用的集成 Used Based Integration 客户 服务器的集成 Client Server Integration 分布式集成