软件测试流程及规范V1.1

软件测试流程及规范软件测试流程及规范 一 软件生命周期中测试工作流程一 软件生命周期中测试工作流程 测试工作流程 软件部业务部测试组 验验收收测测试试阶阶段段需求分析阶段概要设计阶段详细设计阶段编码阶段系统测试阶段 提交最终版SRS编写 测试计划 测试方案 设计测试用例 编写测试用例 执行单元测试 执行系统测试 执行验收测试 编写验收相关文档 冒烟测试 单元测试方案 用例评审 记录缺陷 分析 修改缺陷 记录缺陷 分析缺陷 修改缺陷 系统测试方案 用例评审 回归测试 提交系统测试报告 回归测试 提交系统测试报告 编辑单元测试方案 用例 编辑单元测试方案 用例 根据SRS 评审验收测试方案 用例 记录缺陷分析缺陷 修改缺陷回归测试 提交验收测试报告 二 各阶段具体流程二 各阶段具体流程 1 需求分析阶段 立项 需求调研 编写 修改SRS提交SRSSRS审核 审核是否通过 达到要求 提交最终版SRS 审核是否通过 审核通过 依据SRS 项目整体计划 设计 编写 测试计划 和 测试设计 测试计划 根据SRS定义相应的测试需求报 告 即制订测试的标准 以后所 有的测试工作都将围绕着测试需 求来进行 符合测试需求的应用 程序即是合格的 反之即是不合 格的 同时 还要适当选择测试 内容 合理安排测试人员 测试 时间及测试资源等 测试设计 将测试计划阶段制订的测试需求 分解 细化为若干个可执行的测 试过程 并为每个测试过程选择 适当的测试用例 进入概要设计阶段 评审测试计划 和测试设计 优化测试计划 测试设计 1 1 步骤说明 1 需求定义基本完成 SRS 编写完成 2 开评审会 由需求调研人员 开发组 设计组 测试组等人员对需求中不清楚 不 完整 存在疑义的地方提出问题 相关人员解答并确认 3 当评审未通过 直接打回 重新修改 SRS 问题解决后 重新提交评审 4 当评审通过后 依据SRS 项目整体计划 设计 编写 测试计划 和 测试设计 具体模板见附件 5 开评审会 由开发组 设计组 测试组等人员对计划和设计中不清楚 不完整 存 在疑义的地方提出问题 6 当审批未通过 直接打回 优化测试计划 测试设计 问题解决后 重新提交评审 7 审核通过后 进入下一阶段 1 2 测试通过打回标准 1 3 阶段的输出 输入 最新 SRS 项目计划 输出 测试计划 测试设计 2 单元及集成测试流程 测试设计文档 编写 修改测试用例 测试用例审核 审核是否通过 编写 修改单元测 试方案 单元测试方案评审 审核是否通过 编写 修改测试代码 编码审核 审核是否通过执行单元测试 提交BUG报告修改代码 回归测试 是否达到要求 提交单元测试报告 进入下一阶段 依据需求和设计描述作为指南 对重要的 控制路径进行测试以发现模块内的错误 测试过程中优先考虑耦合度比较高的模块 功能 重点测试 使用缺陷管理工具 如QC 对软件的 缺陷进行管理 在BUG出现的曲线图逐 渐收敛并且得到控制的 情况下进入下一阶段 如果是集成测试 依据需求和设计描述作 为指南 在单元测试的基础上 将所有模 块按照设计要求组装成为子系统或系统 检查其接口是否存在问题 以及组装后的 整体功能 性能表现 进行测试 2 1 步骤说明 1 理解需求和设计 理解设计是很重要的 特别是要搞清楚被测试模块在整个软件中所处的位置 这对测 试的内容将会有很大的影响 需要记住的一个原则就是 好的设计 各模块只负责完成自 己的事情 层次与分工是很明确的 在单元测试的时候 可以不用测试不属于被测试模块 所负责的功能 以减少测试用例的冗余 集成测试的时候会有机会测试到的 所以 单元测试主要是关注本单元的内部逻辑 而不用关注整个业务的逻辑 因为会 有别的模块去完成相关的功能 2 概览源代码 浏览一下源代码 主要任务 1 初步检查源代码的编码风格与规范 2 大致估算测试工作量 比如 需要多少的测试用例 需要写多少的驱动模块和装模 块等 3 确定模块的复杂程度 初步制定测试的优先级等 3 精读源代码 认真阅读和分析代码 主要任务 1 理解代码的业务逻辑 2 检查代码与设计是否相符 如果详细设计没有该模块的流程图的话 先去画出流程 图 3 仔细研究逻辑复杂的模块 4 可以采用一些检查列表来检查程序可能会出现的问题 4 设计测试用例 综合运用白盒测试方法 和结合黑盒测试方法 来设计测试用例 包括功能测试 性 能测试等 要达到一定的测试覆盖率 在设计测试用例的过程中 流程图或控制流图是分 析的好帮手 5 搭建单元测试环境 使用工具或自己写的框架将有助于单元测试的实施 在这个阶段主要就是写桩模块和 驱动模块 第 4 步所设计的测试用例是通过驱动模块传递给被测试模块的 然后驱动模块 想办法获取被测试模块对数据的处理结果 并判定返回的实际结果与测试用例的预期结果 是否一致 通过测试框架来记录执行的结果 对于出现的错误 还需要统计错误的信息 供执行完之后分析 6 执行测试 运行写好的驱动模块完成对被测试模块的测试 7 补充和完善测试用例 单元测试也是个循序渐进的过程 可能一开始考虑的不够全面 或预期的覆盖标准太 低 需要在测试过程中不断补充测试用例 直到满足要求为止 8 分析结果 给出评价 根据测试的结果分析 查找错误的原因 并找到解决的办法 测试结束之后 根据测 试过程的数据统计 给出被测试对象评价 2 2 测试通过打回标准 1 通过标准 2 打回标准 2 3 阶段的输出 输入 最新 SRS 项目计划 详细设计 输出 单元测试计划 单元测试用例 单元测试总结分析 3 系统测试流程 系统测试是将已经确认的软件 计算机硬件 外设 网络等其他元素结合在一起 进 行信息系统的各种组装测试和确认测试 系统测试是针对整个产品系统进行的测试 目的 是验证系统是否满足了需求规格的定义 找出与需求规格不符或与之矛盾的地方 从而提 出更加完善的方案 系统测试发现问题之后要经过调试找出错误原因和位置 然后进行改 正 是基于系统整体需求说明书的黑盒类测试 应覆盖系统所有联合的部件 对象不仅仅 包括需测试的软件 还要包含软件所依赖的硬件 外设甚至包括某些数据 某些支持软件 及其接口等 接上一阶段 发测试任务书通知 编写 修改系统测试方案 测试方案评审 评审是否通过 编写 补充测试用例 用例评审 是否通过执行系统测试 提交BUG报告 修改代码 回归测试 是否达到需求标准 提交系统测试报告 进入下一阶段 使用缺陷管理工具 如QC 对软件的 缺陷进行管理 在BUG出现的曲线图逐 渐收敛并且得到控制的 情况下进入下一阶段 将已经确认的软件 计算机硬件 外设 网 络等其他元素结合在一起 针对整个产品系 统进行的测试 目的是验证系统是否满足了 需求规格的定义 找出与需求规格不符或与 之矛盾的地方 从而提出更加完善的方案 冒烟测试 是否通过 退回或挂起 系统测试 审核 汇总bug 总结测 试报告 3 1 步骤说明 1 测试组收到测试任务通知书 告知较为确切的测试内容 日期 2 根据最新 SRS 和各设计文档 将已经确认的软件 计算机硬件 外设 网络等其他 元素结合在一起 针对整个产品系统进行的测试 3 编写此阶段系统测试方案 通过评审 优化系统测试方案 4 然后编写或补充系统测试用例 用例完成后 需要通过评审 优化系统测试用例 5 执行冒烟测试用例 测试版本仅少量严重程度低的 bug 未修改引起的不通过 反馈 项目组 通知延长冒烟测试时间 测试版本符合冒烟测试打回标准 冒烟测试不通过 直 接打回或挂起 结束测试 测试完成度满足冒烟测试开始条件 重新发起测试申请 6 当不通过时 退回或挂起 7 当完成冒烟测试后 进行系统测试 提交 bug 报告 审核 bug 当审核未通过时 补充测试用例 当审核通过汇总 bug 总结报告 8 当开发人员完成缺陷的修改后 提交新的版本 测试人员继续开始做回归测试 当测试版本仅少量 bug 未修改引起的不通过 反馈项目组 通知延长系统测试时间 测试版本符合系统测试打回标准 系统测试不通过 直接打回 结束测试 待测试完 成度满足系统测试开始条件 重新发起测试申请 9 当缺陷的统计曲线出现的逐渐收敛 并且得到控制 10 分析缺陷的原因 11 提交测试报告 12 进入下一阶段 3 2 测试通过打回标准 1 通过标准 2 打回标准 3 3 阶段的输出 输入 最新 SRS 项目计划 详细设计 输出 系统测试计划 系统测试用例 测试总结分析 4 验收测试 软件产品测试组对经过内部单元测试 集成测试和系统测试后的软件所进行的测试 测试用例采用业务流程测试用例 4 1 步骤说明 1 验收测试进入准则 1 软件产品通过单元测试 集成测试和系统测试 2 项目组提交以下测试文档 测试计划 测试用例 测试日志 测试通知单 测试分 析报告 3 待验收的软件安装程序 2 测试错误类型 参考软件测试停止标准 doc 3 对用户手册和帮助的验收规定 1 用户手册和帮助的编制要使用非专门术语的语言 充分地描述该软件系统所具有的 功能及基本的使用方法 2 使用户 或潜在用户 通过用户手册能够了解该软件的用途 并且能够确定在什么 情况下 如何使用它 3 语句通顺 简洁 语义明确 错别字小于 0 1 4 对相关名词解释应易于被用户理解 5 对相关界面的说明要符合操作流程并将每一项功能解释完整 清楚 6 保证用户手册 帮助能够正确指导用户使用软件 4 软件验收测试合格通过准则 1 软件需求分析说明书中定义的所有功能已全部实现 性能指标全部达到要求 2 所有测试项必须符合以下标准 以下比例为错误占总测试模块的比例 一级错误二级错误三级错误四级错误五级错误 无无 2 3 暂不做要求 3 需求分析文档 设计文档和编码实现一致 4 用户手册及帮助符合对用户手册及帮助的验收规定 编写人在责任认定书上签字时 对于软件产品的各项功能描述 名词解释 结构 语句表达等方面均要保证其正确性并加 以说明 5 验收测试文档齐全 见验收测试进入准则 6 以上五条其中之一不满足要求 视为不合格 三 缺陷管理三 缺陷管理 3 1 缺陷定义 软件缺陷 Defect 常常又被叫做 Bug 所谓软件缺陷 即为计算机软件或程序中存 在的某种破坏正常运行能力的问题 错误 或者隐藏的功能缺陷 具体归纳为以下这些问 题 1 软件没有达到需求规格说明书中表明的功能 2 软件出现了需求规格说明书中不一致的表现 3 软件功能超出需求规格说明书的范围 4 软件没有达到用户期望的目标 虽然需求规格说明书中没有要求 5 测试员或用户认为软件的易用性差 3 2 缺陷的修复 在实际项目中不是所有的缺陷都会修改 具体见以下情况 1 市场的压力使得产品最终发行有时间限制 2 测试员错误理解或者不正确操作引出的缺陷 3 错误的修改影响的模块较多 带来的风险较大 4 缺陷报告中提出的问题很难重现 5 修改性价比太低 3 3 缺陷的分类标准 一旦发现软件缺陷 就要设法找到引起这个缺陷的原因 分析对产品质量的影响 然 后确定软件缺陷的严重性和处理这个缺陷的优先级 各种缺陷所造成的后果是不一样的 有的仅仅是不方便 有的可能是灾难性的 一般问题越严重 其处理优先级就越高 可以 概括为以下五种级别 缺陷标示缺陷严重等级描述 5 严重缺陷不能执行正常工作功能或重要功能 使系统崩溃或资源严重 不足 1 由于程序所引起的死机 非法退出 2 死循环 3 数据库发生死锁 4 错误操作导致的程序中断 5 严重的计算错误 6 与数据库连接错误 7 数据通讯错误 4 较严重缺陷严重地影响系统要求或基本功能的实现 且没有办法更正 1 功能不符 2 程序接口错误 3 数据流错误 4 轻微数据计算错误 3 一般性缺陷严重地影响系统要求或基本功能的实现 但存在合理的更正 办法 1 界面错误 附详细说明 2 打印内容 格式错误 3 简单的输入限制未放在前台进行控制 4 删除操作未给出提示 5 数据输入没有边界值限定或不合理 2 较小缺陷使操作者不方便或遇到麻烦 但它不影响执行工作或功能实 现 1 辅助说明描述不清楚 2 显示格式不规范 3 系统处理未优化 4 长时间操作未给用户进度提示 5 提示窗口文字未采用行业术语 1 其它缺陷1 建议 2 其它错误 3 3 缺陷的流程 目前分公司的缺陷管理使用的是 Quality Center9 0 具体安装和使用细节 见使用手 册 在使用时遵循以下的流程 即缺陷的生命周期 流程中缺陷存在以下 6 种状态 提交 bug 状态 New 开发人员或测试人员发现 bug 记录在系统里 激活状态 Open 当项目经理或负责人觉得这个 bug 是问题 将 bug 置为此状态 驳回状态 Rejected 当项目经理或负责人觉得这个 bug 不是问题 则可以驳回 将 bug 置为此状态 已修正状态 Fixed 开发人员针对缺陷 修正软件后已解决问题或通过单元测试 关闭状态 Close 测试人员经过验证后 确认缺陷不存在之后的状态 重新激活状态 Reopen 测试人员经过验证后 确认此缺陷存在 之后将其置为此 状态 四 关于单元测试四 关于单元测试 1 首先应该明确单元的含义 单元在面向对象的程序中指的是一个类 在结构化的方 法中指的是一个函数 2 其次应该明确单元测试的方法 单元测试的常用方法包括 1 静态检查 即采用静态代码检查的工具对程序进行内部逻辑的分析 以分析程序 中可能的错误 2 动态测试 通过编写单元测试程序 设计单元测试用例 测试每个函数或每个类 的逻辑正确性 3 如果一个类或一个函数对其他的类或环境依赖性很强 需要编写大量的桩程序或驱 动程序 那恰恰说明了这个类或这个函数的设计有问题 违背了 低耦合 的基本设计原 则 这也正式敏捷方法中提倡的 测试驱动开发 的作用之一 4 质量的投入产出也是一种平衡 需要在单元测试上投入到什么程度首先是公司的一 个管理方针 如果每个单元都进行单元测试则测试代码的规模和产品代码的规模能够达到 1 1 也就是说编写测试代码的工作量还是比较大的 但是也要看到单元测试的产出 在 单元测试 集成测试 系统测试中 单元测试是投入产出比最大的测试种类 即单元测试 在单位时间内发现的缺陷个数大于集成与系统测试 原则上单元测试的投入最大 找到的 缺陷最多 集成测试与系统测试依次递减 5 在实践中推广单元测试时可以采用如下的方法 1 加大静态检查的力度 通过静态检查的工具快速地识别程序中的错误 警告 公 司可以规定对检查出的哪些警告 错误必须进行修改 注意如果修改所有的警告 错误可 能工作量比较大 静态检查是一种投入产出比很高的单元测试方法 在 JAVA 下可以采用 check Style Source monitor PMD Find Bugs Jslink 等 2 通过测试策略的选择减少测试程序的工作量 单元测试一般有三种策略 策略一 自底向上的策略 先测底层的函数或类 再测上层的函数或类 此时只需要 编写驱动程序 不需要编写桩程序 策略二 自顶向下的策略 先测上层的函数或类 再测试底层的函数类 此时只需要 编写桩程序 不需要或很少需要编写驱动程序 策略三 混合策略 综合上述的 2 种策略 需要综合编写桩程序与驱动程序 如果被测的单元需要调用很多其他的单元 则可以采用自底向上的策略减少驱动程序 的编写量 如果被测的单元需要很多外围的环境准备则可以采用自顶向下的策略 3 在组织级可以规定执行单元测试的时机 比如 a 系统中最核心的 最关键的功能模块 b 算法复杂的功能模块 c 出错最多的功能模块 d 客户最常使用的功能模块 e 复用的底层代码 根据 Pareto 定律 我们可以选择少部分代码执行单元测试 6 单元测试的技术 1 JUnit 的工具 2 生成测试用例时可以采用如下的方法 a 单元功能分析 b 入口参数等价类分析 c 入口参数边界分析 d 全程变量 共享数据的等价类与边界分析 e 调用函数返回值的等价类与边界分析 f 覆盖率分析 上述的方法要求的严格程度可以循序渐进 不能的严格程度需要投入的工作量不同 7 单元测试完成后 编写软件评定书 五 通用检查点五 通用检查点 见附件 公共测试用例 xlsx 六 常见缺陷分类六 常见缺陷分类 见附件 缺陷分类 xlsx 七 评审工作七 评审工作 一 审批过程一 审批过程 评审的通用过程由如下 6 个阶段组成 1 计划阶段 选择评审员并分配角色 为正式的评审类型 如审查 规定评审的入口和出 口准则 以及选择需要评审的文档或文档章节等 2 预备会阶段 分发文档 向评审参与者解释本次评审的目标 过程和文档 以及核对入 口准则 针对正式的评审类型 3 个人准备阶段 在评审会议之前每位评审参与者准备各自的评审工作 标注评审对象中 可能的缺陷 问题和建议等 4 评审会议阶段 讨论评审员提交的问题列表 并形成会议纪要 针对正式的评审类型 会议参与者可以标识缺陷并提出处理建议 5 返工阶段 修复评审过程中发现的缺陷 通常由作者完成 6 跟踪结果阶段 检查缺陷是否已经解决 收集度量数据并评估出口准则 针对正式的评 审类型 二 审批中涉及的主要角色二 审批中涉及的主要角色 经理 主持人或组长 作者 评审员和记录员 其他可能涉及包括决策者或者其他利 益相关者 如用户代表 另外一个可选的角色有时会出现在审查中 即宣读员 在评审会 议中宣读产品的某些部分 三 审批遵循原则三 审批遵循原则 评审遵循原则 1 尽早的开展评审 2 控制评审会议的时间 3 评审的是软件产品而不是作者 4 每个评审员都必须有机会充分地表达各自的观点 并且评审会议纪要必须完整地记 录每个评审员的意见和建议 5 发现缺陷 而不是修复缺陷 评审会议关注的是发现被评审对象中的缺陷 而尽量 避免讨论针对缺陷的可能解决方案和方法 提出解决方案及其对应的讨论不应该是评审会 议的关注点 6 评审过程中发现的缺陷和问题 应该划分为不同的严重程度级别 1 严重缺陷 评审对象不能满足其目标 在批准评审对象之前必须修复相关缺陷 2 重要缺陷 影响评审对象的可用性 批准评审对象之前应该修复相关缺陷 3 一般缺陷 小的偏差 基本不影响使用 4 好的 没有缺陷 返工时无须修改 7 评审团队最后应该对评审对象给出如下评审意见 1 接受 文档 软件产品不需要修改或者只要微小的修改 2 有条件接受 文档 软件产品需要修改 但是不需要进一步评审 3 不接受 文档 软件产品需要深入修改 并且需要重新评审或者其他检查措施 四 审批类型四 审批类型 评审可以是正式或非正式的 基于 IEEEStd1028 2008 软件评审和审计标准 分为审 查 技术评审 走查 非正式评审 管理评审和审计等评审类型 1 审查 目的 这是一种系统的同行检查方法 检查并发现软件产品中的缺陷 主要关注软件 产品是否满足规格说明及其是否体现了特定的质量特性 以及是否满足了规范 标准 指 南 计划 规格说明和规程等要求 并识别其中存在的差异 参与人员 审查一般由 2 至 6 个人参与 包括作者 角色主要有主持人 记录员 宣读员 作者和审查员 度量数据 检查表 结果输出 确定补救措施或调查活动 注 审查会议上并不讨论解决方案 收集相关数据并定期分析 数据包括被审查的软件产品 审查召开的日期 审查参与 的成员 审查员准备的时间 审查会议的时间 审查对象规模和审查结果等 通过分析优 化审核本身的过程 并改进生成软件产品的过程 2 技术评审 目的 为了评估软件产品是否满足预期的使用要求 识别软件产品和规格说明与标准 之间不一致的地方 方式 同行间小组讨论活动 主要为了对测试对象所采用的技术实现方法达成共识 参与人员 包括决策者 评审主持人 记录员和技术评审员 也可以包括项目的其他 利益相关者 如客户代表 输入 相关的规范 标准 计划和规格说明之外 评审检查表与缺陷分类等也是重要 的内容 输出 其中主要包括技术评审的对象 参与技术评审的成员名单 技术评审的目标 技术评审的相关输入 评审得到的软件产品缺陷列表 管理问题列表 应对活动列表 应 对活动的状态 负责人 完成的目标时间与完成的实际时间等 和评审团队得到的建议列 表 并且判断软件产品是否满足了规范和标准等的要求 3 走查 目的 1 发现缺陷 2 改善软件工作产品 3 讨论软件工作产品的替换方案 4 评估和标准及规格说明等的一致性 5 评估软件产品的可用性 6 培训参与者 参与人员 包括走查主持人 记录员 作者与走查员等 度量数据 检查表 收集相关数据并定期分析 数据包括被走查的软件产品 走查开始的日期 走查参与 的成员 走查员准备的时间 走查会议的时间 走查对象规模和走查对象的走查结果等 通过分析优化走查本身的过程 并改进生成软件产品的过程 4 非正式评审 非正式评审是一种不基于正式 文档化 过程的评审 它是评审的精简版 在某种程 度上遵循通用的评审过程 通常情况下 由作者发起非正式评审 评审计划限定于选择评 审员和要求他们在指定时间点提交意见和建议 非正式评审通常不召开会议和相互交换意 见 只是作者和评审员之间的交互 非正式评审可以是一种由一个或多个同事完成的交叉 阅读 其结果不需要明确的文档化 有时一个评审清单或修订文档就足够了 结对编程 结对测试和代码交换等都是非正式评审的方式 非正式评审非常普遍 并且由于工作量小 而被广泛接受 五 如何开展审批活动五 如何开展审批活动 被评审的产品应当符合相应条件 如审查需要满足一定的评审入口准则 同时不同的 评审对象需要不同的评审员参与 如下表 文档名称作者评审员 需求规格说明书系统人员项目经理 架构师 测试组人员 测试计划测试组人员开发经理 架构师 测试组 测试设计规格说明书测试组人员开发经理 架构师 测试组 测试用例测试组人员开发经理 测试组 测试报告测试组人员项目经理 开发经理 测试组 其中的评审员 如功能开发经理 可以指定符合要求的开发人员代替其参与评审活动 评审对象的 作者 一栏中列出了该文档的主要责任人 有的文档可能需要多个项目人员 共同完成 作者可能有多人 为了成功地将评审引入到项目和组织中 需要采取以下措施 1 获得管理层支持 评审需要时间和资源 如评审员的时间计划 工作量计划 评审 需要的基础设施和设备等 这些都需要组织管理层的支持 2 管理人员培训 早期发现和修复缺陷可以节约时间和降低成本 管理人员必须意识 到学习新的评审技术是一项投资 其收益不是立即可见的 随着时间的推移会越来越明显 地显现出来 管理人员需要在评审成本 利益和执行方面进行有效的平衡 3 正规的评审过程 组织内定义并文档化评审步骤 定义不同的评审类型和评审过程 中不同的角色和职责 并对评审过程定义合适的监控手段和形式 通过评审过程的监控和 改进提供评审的度量数据 如评审的效率和发现缺陷的分布等 4 开展评审技术和规程的培训 根据项目特点和评审类型开展评审技术和规程的培训 更好地让评审参与人员了解评审的目的 评审的过程及评审的作用和意义 从而更加有效 地开展评审 而不是作为过程的一部分流于形式 5 获得评审员和评审对象作者的支持 评审要求评审对象的作者提供合适的评审资料 以满足评审的入口准则 并且需要评审员具备合适的专业技能和知识 拥有足够的能力完 成评审工作 6 评审最重要的文档 由于软件开发的时间和资源有限 因此需要将评审用于