软件测试计划与管理概要.ppt

软件测试与管理 测试原则测试计划过程测试目标及策略测试范围分析测试风险的控制测试管理工具 测试原则 做事应该讲原则 在一些不利的场合更要坚持原则 才能确保成功 软件测试也不例外 其基本原则就是为了保证软件产品质量而进行充分的 全面的测试 并尽早 尽可能多地发现缺陷 以下是软件测试的几大原则 软件开发人员即程序员应当避免测试自己的程序 不管是程序员还是开发小组都应当避免测试自己的程序或者本组开发的功能模块 应尽早地和不断地进行软件测试应当把软件测试贯穿到整个软件开发的过程中 而不应该把软件测试看作是其过程中的一个独立阶段 对测试用例要有正确的态度 第一 测试用例应当由测试输入数据和预期输出结果这两部分组成 第二 在设计测试用例时 不仅要考虑合理的输入条件 更要注意不合理的输入条件 测试原则 人以群分 物以类聚 软件测试也不例外 一定要充分注意软件测试中的群集现象 也可以认为是 80 20原则 不要以为发现几个错误并且解决这些问题之后 就不需要测试了 反而这里是错误群集的地方 对这段程序要重点测试 以提高测试投资的效益 严格执行测试计划 排除测试的随意性 以避免发生疏漏或者重复无效的工作 应当对每一个测试结果进行全面检查 一定要全面地 仔细地检查测试结果 但常常被人们忽略 导致许多错误被遗漏 妥善保存测试用例 测试计划 测试报告和最终分析报告 以备回归测试及维护之用 在遵守以上原则的基础上进行软件测试 可以以最少的时间和人力找出软件中的各种缺陷 从而达到保证软件质量的目的 测试计划过程 测试是一项风险比较大的工作 在测试过程中有许多不确定性 包括测试范围 代码质量和人为因素等 这种不确定性的存在 就是一种风险 测试计划的过程就是政府间消除风险的过程 一般来说 在制定计划过程中 首先需要对项目全面了解 如产品开发和运行平台 应用领域 产品特点及其主要的功能特性等 也就是掌握软件测试输入的所有信息 然后根据测试计划模版的要求 准备计划书中的各项内容 测试计划不可能一气呵成 而是经过计划初期 起草 讨论 审查等不同阶段 最终完成测试计划 计划初期 是收集整体项目计划 需求分析 功能设计 系统原型 用户用例等信息 理解用户的真正需求理解新技术或者技术难点 计划起草 根据计划初期所掌握的各种信息 知识 确定测试策略 选择测试方法 完成测试计划的框架 内部审查 在提供给其他部门讨论之前 先在测试小组部门内部内进行审查 计划讨论和修改 召开有需求分析 设计 开发等人员参加的计划讨论会议听取大家对测试计划中各个部分的一件 进行讨论交流 测试计划的多方审查 项目中的每个人都应当参与审查 测试计划的定稿和批准 在计划讨论 审查的基础上 综合各方面的一件 就可以完成测试计划书 然后上报上级 得到批准 方可执行 计划执行跟踪和修改 在实际计划执行过程中 由于测试需求 测试环境等因素发生变化 这就有必要对计划进行调整 满足测试的需要 测试计划过程 测试目标及策略 对不同的测试项目 软件测试的基本目标是相同的即在开发周期内 尽可能早的发现最严重的缺陷 测试目标也分为整体目标和阶段性目标 特定的任务目标 以下是软件测试目标的分解和层次 用户需求 测试策略 软件测试的策略 方法和技术是多种多样的 对于软件测试技术 从是否需要执行被测软件的角度 可分为静态测试和动态测试 所谓静态方法是指不运行被测程序本身 仅通过分析或检查源程序的文法 结构 过程 接口等来检查程序的正确性 静态方法通过程序静态特性的分析 找出欠缺和可疑之处 例如不匹配的参数 不适当的循环嵌套和分支嵌套 不允许的递归 未使用过的变量 空指针的引用和可疑的计算等 静态测试结果可用于进一步的查错 并为测试用例选取提供指导 动态方法是指通过运行被测程序 检查运行结果与预期结果的差异 并分析运行效率和健壮性等性能 这种方法由三部分组成 构造测试实例 执行程序 分析程序的输出结果 测试策略 为了更好地确定软件测试策略 也可以试着问一些如下的问题 在寻找这些答案的过程中 也就找到了最佳的测试策略 如何确定回归测试的范围 如何利用可重复性的测试 测试缺乏可预见性 如何收集能衡量测试结果的指标 如何建立稳定的 模拟系统实际运行的测试环境 如何从无穷的输入数据中选择合理的 有效的测试数据集 如何加强静态测试 规格说明书 设计文档和程序代码等的审查 如何处理单元测试和集成测试的关系 如何处理手工测试和自动化测试之间的平衡 使它们的互补性得到发挥 测试的效率和质量到达最佳状态 如何衡量这份测试策略的有效性 测试范围分析 测试范围一般分为三类 单元测试 集成测试和系统测试 单元测试 纯代码的测试 白盒测试 主要测试代码语句的正确性 如所有的代码是否都可以跑到 是否有冗余的代码等等 集成测试 接口测试 灰盒测试 结合白盒和黑盒测试 主要测试代码块之间的接口 看看数据的传输是否有问题 系统测试 黑盒测试 不接触代码 只对整个系统做功能的测试和性能的测试 以上的三中测试是在项目组中测试的 确认测试 是客户做的测试 也可以叫做验收测试 客户对他提出的需求 对应要交付的软件看看是否达到其要求 测试风险的控制 在软件测试中 测试风险是不可避免的 总是存在的 所以对测试风险的管理非常重要 必须尽力降低测试中所存在的风险 最大程度地保证质量和满足客户的需求 在测试工作中 主要的风险有 质量需求或产品的特性理解不准确 造成测试范围分析的误差 结果某些地方始终测试不到或验证的标准不对 测试用例没有得到百分之百的执行 如有些测试用例被有意或无意的遗漏 需求的临时 突然变化 导致设计的修改和代码的重写 测试时间不够 质量标准不都是很清晰的 如适用性的测试 仁者见仁 智者见智 测试用例设计不到位 忽视了一些边界条件 深层次的逻辑 用户场景等 测试环境 一般不可能和实际运行环境完全一致 造成测试结果的误差 有些缺陷出现频率不是百分之百 不容易被发现 如果代码质量差 软件缺陷很多 被漏检的缺陷可能性就大 回归测试一般不运行全部测试用例 是有选择性的执行 必然带来风险 测试风险控制 前面三种风险是可以避免的 而四至七的四种风险是不能避免的 可以降到最低 最后一种回归测试风险是可以避免 但出于时间或成本的考虑 一般也是存在的 针对上述软件测试的风险 有一些有效的测试风险控制方法 如 测试环境不对可以通过事先列出要检查的所有条目 在测试环境设置好后 由其他人员按已列出条目逐条检查 有些测试风险可能带来的后果非常严重 能否将它转化为其他一些不会引起严重后果的低风险 如产品发布前夕 在某个不是很重要的新功能上发现一个严重的缺陷 如果修正这个缺陷 很有可能引起某个原有功能上的缺陷 这时处理这个缺陷所带来的风险就很大 对策是去掉 Diasble 那个新功能 转移这种风险 有些风险不可避免 就设法降低风险 如 程序中未发现的缺陷 这种风险总是存在 我们就要通过提高测试用例的覆盖率 如达到99 9 来降低这种风险 为了避免 转移或降低风险 事先要做好风险管理计划和控制风险的策略 并对风险的处理还要制定一些应急的 有效的处理方案 如 在做资源 时间 成本等估算时 要留有余地 不要用到100 在项目开始前 把一些环节或边界上的可能会有变化 难以控制的因素列入风险管理计划中 对每个关键性技术人员培养后备人员 作好人员流动的准备 采取一些措施确保人员一旦离开公司 项目不会受到严重影响 仍能可以继续下去 制定文档标准 并建立一种机制 保证文档及时产生 对所有工作多进行互相审查 及时发现问题 包括对不同的测试人员在不同的测试模块上相互调换 对所有过程进行日常跟踪 及时发现风险出现的征兆 避免风险 要想真正回避风险 就必须彻底改变测试项目的管理方式 针对测试的各种风险 建立一种 防患于未然 或 以预防为主 的管理意识 与传统的软件测试相比 全过程测试管理方式不仅可以有效降低产品的质量风险 而且还可以提前对软件产品缺陷进行规避 缩短对缺陷的反馈周期和整个项目的测试周期 测试管理工具 要管理好测试过程 测试管理工具系统是必不可少的 测试管理工具 是指用工具对软件的整个测试输入 执行过程和测试结果进行管理的过程 可以提高回归测试的效率 大幅提升测试时间 测试质量 用例复用 需求覆盖等 目前市场上主流的软件测试管理工具 嵌入式软件测试工具 LOGISCOPE白盒工具 NuMegaDevPartnerStudioBoundsChecker TrueCoverage TrueTime黑盒工具 QACenter功能测试工具QARun 性能测试工具QALoad 应用可用性管理工具 EcoTools 应用性能优化工具EcoScope数据库测试数据自动生成工具 T