第1-4章 测试基础部分.ppt

常规测试点 输入/输出的测试要点 局部数据结构的测试要点 计算中的常见错误 测试方案中的错误 评价出错处理时的常见错误 为什么缺陷很难找 需求解释有错误； 用户定义错了需求； 需求记录错误； 设计说明有误； 编码说明有误； 程序代码有误； 数据输入有误； 测试错误； 问题修改不正确； 正确的结果是由于其它的缺陷产生的。 缺陷的提交艺术 10 条技巧可以帮助你的小组提高编写 bug report 的质量 组织（Structure） 重现（Reproduce） 隔离（Isolate） 归纳（Generalize） 对比（Compare） 总结（Summarize） 精简（Condense） 消除歧义（Disambiguate） 中立（Neutralize） 检查（Review） 缺陷的生命周期 new-? open-? fixed-? close 缺陷生命周期内，注意事项 测试人员只需要接收 fixed 和 rejected 状态的缺陷,其他缺陷无论任何原因流转到测试人员,都可以直接驳回(并描述驳回原因)。 每个状态发生变化时,相关处理人员必须填写缺陷修改的相关说明.如果发现上一状态没有完整填写说明或描述不清,可以直接驳回(并描述驳回原因)。 开发人员要配合测试人员的工作 QA（质量保证）人员应定期的检查开发人员和测试人员是否遵守测试管理规范的流程 缺陷类型定义 A 类——致命错误 B 类——严重错误 C 类——一般性错误 D 类——轻微错误 E 类——测试建议 国标中有关缺陷的数量的描述 第四章 软件测试流程 本章目标 掌握测试流程 软件测试流程 1、需求分析 2、制定测试计划 3、设计测试用例 4、测试用例评审 5、搭建测试环境 6、开始测试，提交bug 7、bug验证 8、测试结束 9、写测试报告 需求分析 要求：能够清晰明白的确定要得到的东西，可在头脑中形成框架。 难点：人的需求很难定义，分显性需求和隐性需求，所以需求总是不完整，不明确的。 办法：与项目经理、开发人员沟通，了解他们关注的重要质量和特性；参照权威或竞争对手的产品；本行业经验积累。 目的：使得模糊的需求尽可能细化，明晰，具有可测试性。 制定测试计划 要求：确定测试的时间，测试的内容、策略、人员要求、工具。 测试策略是测试用例编写的依据，包括测试重点、测试方法、测试停止准则、测试风险、覆盖率及其他要求。 难点：测试策略的制定应和项目要求、开发进度、需求相一致。超前测试或测试力度不够都不能很好得满足要求。 办法：测试策略请项目参与人员审查，看测试策略是否与项目进度一致。 目的：为测试工作制定遵循的规则，测试任务更加明确，保证测试有效进行。 设计测试用例 要求：能够满足测试策略中的规定，达到覆盖率，具有可执行性。设计测试用例要突出重点，测试用例的数量要和模块的重要程度、难易程度成比例。及时补充测试用例。要有正反两方面测试用例。 难点：要运用发散思维从多个角度审查测试内容，设计测试用例。正确准备测试数据。 办法：多学习各种测试方法和测试技术。 测试用例评审 要求：由项目经理和主要成员参与，对测试用例的构建、内容、数量、使用数据、覆盖率使用测试工具等进行审查，确定用例正确可执行且满足测试策略的要求。 难点：对于测试用例较多的情况，测试内容评审会有难度。 办法：请项目经理及其他人员尽早阅读测试用例，对用例中不明确的地方提前准备，提高评审效率。 搭建测试环境 严格按照测试计划要求搭建测试环境。对测试要求的系统，平台，网络等软硬件要求均要满足。 保证测试环境不受其他干扰，保证测试环境中的系统和配置都是干净的系统。每次测试前都应重新恢复一个新的测试环境。 开始测试，提交bug 前提：根据测试用例编写好测试脚本，确定测试工具、测试环境、测试方法，准备好测试数据。可开始测试。 提交bug：正确填写bug的严重等级，测试环境，出现bug的操作步骤，每一步出现的结果。保留测试数据和bug的场景。Bug应可重现。 难点：判断bug的严重等级。判断不可重现的异常是否是bug。 方法：对于不可重现的bug要反复测试，对于出现的异常要有记录。 Bug验证 方法：首先验证修复的bug，按照测试步骤验证。同时验证与其功能相似的方面看有没有受到干扰。同时验证与其功能相关的模块，看有没有出现耦合错误。 通过验证后，对于等级较高的bug应重新设计同类测试数据，使用新数据再次验证，保证完全修复。 测试结束 对于测试情况和测试进度，测试人员应向项目经理和开发人员汇报。根据测试策略中定义的测试停止准则对测试进行评审，确定测试是否可以结束。 评审测试结束的角度：软件功能、bug的修改情况、重点模块的测试力度