02软件测试基础知识2.pptVIP

软件测试基础知识2 柴晓华 August 2011 课程安排 软件测试过程模型 软件测试流程 软件测试的误区 软件测试过程模型 V模型1 V模型2 V模型3 V模型4 W模型1 W模型2 W模型3 W模型4 X模型1 X模型2 H模型1 H模型2 H模型2 小组练习 你们公司用哪种软件测试过程模型？使用后有什么感触？ 软件测试流程 测试计划 测试设计 测试开发 测试执行 缺陷管理 测试报告 测试计划的作用 测试计划的主要任务 了解测试对象 确定被测系统的基本需求 模块 优先级 界面要求 接口需求 确定测试策略 测试类别 功能测试 接口测试 性能测试 可靠性测试 易使用性测试 兼容性测试 等 确定测试完成目标 案例数 覆盖率 执行次数 缺陷个数 安排测试任务和日程 确定测试提交物 测试计划 测试计划 测试用例说明 测试过程说明 软件风险 定义 是不确定因素、元素或趋势。是发生某种事件以及后果的可能性。 和问题的区别 影响 时间 成本 效率 可能的风险举例 风险管理 定义 对风险因素进行识别、评估、控制的过程 风险管理活动 计划 控制 风险评估矩阵 资源 测试组织 测试组织独立性 客观性 专业性 权威性 资源有保证 说明测试的交付物及其格式要求 测试计划 测试计划 测试用例说明 测试过程说明 测试执行 工具和输出 模拟器/静态和动态发生器 测试报告 测试登记/日志 缺陷登记表 测试总结报告 测试方法、技术和工具 测试环境 权衡 在技术、日程、人员及测试目标方面发生冲突时，如何权衡 例如： 在任何情况下都要满足指定的测试目标 保证按期交付为首要关键因素 首先考虑关键应用领域的测试 测试估计及日程计划 估计应该基于 可定量化的需求 测试范围 在前面的发布或项目中的bugs 合同 开发工作量的%多少 组织标准 以前的经验 测试者的生产率 测试计划评审 对测试计划举行正式的技术评审，保证其是完整的、正确的、并对应了所有的软件需求 评审人 项目经理 需求团队/设计团队/开发团队 测试团队 SQA/SCM 用户代表 分别让不同的人分别评审计划的片段 缩减不必要的正文，提高可评审性 参考 测试计划模板 项目估计 小组练习 列出自己项目中通常遇到的风险 项目估计方法 Where Are Were？ 测试计划 测试设计 测试开发 测试执行 缺陷管理 测试报告 什么是好的测试用例 一个好的测试用例能够在第一时间发现程序中存在的错误 一个好的测试用例是发现了至今尚未发现的错误的测试。 发现错误的可能性很高。 没有必要构造一个与其他测试用途完全相同的测试 “最佳品种”：使用最可能找到所有错误的测试 既不会太简单，也不会太复杂 如何决定测试度 测试的心理学考虑 程序员应避免测试自己的程序 程序设计机构不应测试自己的程序 测试设计 设计测试用例 设计测试用例的测试步骤 确定测试用例所需的测试环境 确定测试用例的通过/失败准则 确定测试所需要的测试工具 确定测试所需要的数据包和其他支持软件 测试准备 获得足够的项目背景知识 获得技术培训 理解和验证测试需求 测试需求验证目的 验证需求的可测性 捕捉需求中的缺陷 如何验证需求 好的测试需求应当具有 完整性 一致性 无歧义 无复合语句 可量化 需求和实现 测试需求分解 基于业务需求 根据业务单元和逻辑实现 更加具体化，系统化，可管理 通过以下渠道： 业务需求 程序流 数据流 实体－关系图 用户界面 测试需求例子 功能特性 建立新定单 取消定单 操作限制 等级7以下的操作员不能修改定单信息 等价类/边界条件 最多的定单数目为1000 性能特性 定单查询时间不超过3秒 易学习特性 操作员第一次操作，完成一个新定单输入的时间不超过半小时。 测试用例 说明测试的输入、预期输出、测试环境和评判标准等信息 测试用例内容： 测试用例标识 测试类型、目标和用途 所涉及的软件需求/测试条件 环境要求/先决条件 硬件需求 软件需求 数据库状态 单用户/多用户 前面的执行步骤 测试过程 描述测试用例的具体步骤 组合若干个测试用例为一个可连续执行的过程 测试过程包括若干个测试步骤 各步骤之间不需要重新设置测试环境和先决条件 测试过程所包含信息包括 测试环境 先决条件（及其设置方式） 测试步骤 每个步骤的测试数据输入/输出/评价准则 逻辑测试用例和物理测试用例 逻辑测试用例 描述输入数据和预期结果所要满足的规则，不要求具体的数字 物理测试用例 具体说明测试数据和预期输出 一个逻辑测试用例可对应多个物理测试用例 物理测试用例可方便自动化。 RTM 定义 将测试案例映射到测试需求的一个矩阵 用于保证每个系统需求被正确实现和测试 维护RTM