软件测试技术 教学课件 作者 徐芳 第二章测试计划.pptVIP

软 件 测 试 技 术 第二章 测试计划 2.1 测试计划要点和制订过程 2.2 测试软件需求 2.3 测试策略 2.4 测试环境 2.5 测试管理 2.6 测试计划编写 2.1 测试计划要点和制订过程 收集并组织测试计划信息 将软件细化为可检验的测试需求 建立测试计划 测试活动进度综述，可供项目经理产生项目进度时参考； 测试方法，包括测试工具的使用； 测试工具，包括如何和何时获取工具； 实施测试和报告结果的过程； 系统测试进入和结束准则； 设计、开发和执行测试所需的人员； 设备资源：需要什么样的机器和测试基准； 恰当的测试覆盖率目标； 测试所需的特殊软件和硬件配置； 测试应用程序策略； 测试哪些特性，不测试哪些特性； 风险和意外情况计划。 2.2 测试软件需求 需求分析过程 收集用户需求 编写需求定义文档 编写软件功能说明 编写软件需求跟踪矩阵 审核软件需求文档 需求分析中测试人员工作 理解需求，参与审核需求文档 理解项目的目标、限制，了解用户应用背景 编写测试计划 准备资源 软件需求文档 需求文档是进行设计、编码、测试的基础文件，软件需求文档中，需要描述下列内容： 说明 一般描述 各种限制条件、假定和以来 功能需求 非功能需求 参考 需求跟踪矩阵 对于需求文档中的每项需求，要确保以下问题： 是否完成了相应的设计？ 是否编写完成了相应的代码？在哪里可以找到这些代码？ 是否编写完成了相应的单元测试用例？是否进行了单元测试？ 是否完成了相应的集成测试用例？是否进行了集成测试？ 需求跟踪矩阵即描述上述问题。 什么是好的需求文档？ 具有清晰的格式和文档结构 需求的内容正确 需求的内容完整 需求具有可行性 必要性 对不同的需求的优先等级进行定义 描述明确，无歧义、二义，上下文一致 可证实和可测试性 可修改性 可追踪 需求文档被及时更新 从以下几个方面来评价需求文档： 需求文档是否符合公司的格式要求？ 需求是否正确？ 要保证需求文档中所描述的内容是真实可靠的 这是“真正的”需求吗？描述的产品是否就是要开发的产品？ 需求是否完备？列出的需求是否能减去 一部分？ 需求是否兼容？需求有可能是矛盾的。 需求是否可实现？ 需求是否合理？ 需求是否可测？ 需求测试的方法： 复查 (Review) 复查一般是让工作中合作者检查产品并提出意见。同级互查可以面对面进行，也可以通过E-Mail实现，并没有统一标准。发现文档缺陷同级互查的能力是三种方法中最弱的。 走查 (Walkthrough) 相比较审查走查较为宽松，其事先需要收集数据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查通过会议进行，会前每个与会者需要进行准备，会议必须按规定的程序进行，缺陷被记录并形成会议报告。审查被证明是非常有效的发现缺陷的方法。 2.3 测试策略 测试过度，则在测试覆盖中存在大量冗余；测试范围过小，则存在遗漏错误的风险。 定义测试范围是一个在测试时间、费用和质量风险之间寻找平衡的过程。 通过分析产品的需求文档识别哪些需要被测试。 测试范围不能仅仅由测试人员来确定。 在不同的开发阶段，需要选择不同的测试方法。 在瀑布生命期模型中不同的阶段可以选择的不同的测试方法： 2.4 测试环境 从软件的编码、测试到用户实际使用，存在着：开发环境、测试环境和用户环境。 “环境”，指的是被测试软件所运行的软件环境和硬件环境。 测试环境是测试人员为进行软件测试而搭建的环境，一般情况下，将包括多种典型的用户环境。 测试环境的环境项 计算机平台 操作系统 浏览器 软件支持平台 外部设备 网络环境 其它专用设备 在配置测试环境方面，同样面临着在测试范围中的平衡问题。 　 在搭建测试环境的时候，要排列配置的优先级，主要考虑： 使用的频度或者范围 失效的可能性 能最大限度模拟真实环境 2.5 测试管理 在测试管理方面，需要考虑的主要问题包括： 选择缺陷管理工具和测试管理工具 定义工作进度 建立风险管理计划 在测试计划阶段，需要确定用什么工具进行测试管理和缺陷管理。如TestDirector或 Bugzilla等。 在执行测试的过程中，缺陷管理工具和测试管理工具并不是必须的。但多数公司都会使用缺陷管理工具。 定义工作进度的过程 确认工作任务 工作任务可以分为两类，一类是可以直接和需求文档对应起来的，另外一类和需求文档没有直接的关联。 在需求文档中，描述了软件的功能性需求和非功能性需求，对需求中的每一个条目，都应该有相应的测试工作与之对应起来。 确认好测试任务后，还应该排列这些任务的优先级。 与需求文档没