《软件测试培训.ppt》由会员分享，可在线阅读，更多相关《软件测试培训.ppt（145页珍藏版）》请在三一文库上搜索。
1、软件测试培训 火龙果软件（） 北京： 上海： 深圳： 培训列表 软件测试的目的和策略 测试方法学 测试的技巧 测试工具的选择 软件开发中的测试过程 实例讲解测试活动在软件工程中的应用 软件测试的目的和策略 典型测试步骤 1.计划： 定义目标 确定策略 确定方法 2.执行： 建立环境 执行计划 3.检查：一步步验证 执行完毕？ 4.循环：没有改正 继续执行 谁参与测试？ w用户方代表 w软件最终使用者 w软件开发人员 w软件测试人员 w高层经理的支持 w过程保证人员（SQA） 什么试缺陷？ w缺陷：最终产品同用户的期望不一致 w缺陷的分类 错误 遗漏 超出需求的部分 w缺陷（未触发）VS.错误（
2、应首先解决） 测试的商业意义 w降低风险（风险：就是不希望发生的事情的 可能性） w测试计划中必须标明商业上的风险。 w测试人员职责： 评估商业上的风险 如实的向管理层汇报项目情况 目前公司内测试组织的等级 w测试是一件艺术品，很难掌握。 w测试是一门手艺，精通很困难。 w测试使用的是已定义好的测试流程，有规则 可寻。 w测试有较高级的组织形式。 w世界级的测试组织。 测试的职责 验证在整个软件开发周期中，各个阶段的软件质 量是否合格。 验证最终交付给用户的系统是否满足用户的需要 ，是否符合需求。 通过样本测试数据，检查系统在运行过程中的情 况。 对待可能产生的风险的策略 w我们无法消除风险，
3、但是我们可以降低在风 险发生时的损失。 w降低系统风险的最有效的办法就是对其进行 有针对性的测试。 系统风险列举 w如果某部分产生了错误会导致的结果？ w未被验证的数据交换如果被接受 w如果文件的完整性被破坏 w系统是否能被安全恢复（完全恢复成备份时的状态 ） w是否能暂停系统的运行 w进行维护工作时，系统性能是否会下降到不能接受 的水平。 w系统的安全性是否有保证 系统风险列举（继续） w系统的操作流程是否符合用户的组织策略和 长远规划 w系统是否可靠，稳定 w系统是否易于使用 w系统是否便于维护 w是否易于与其它系统相连 测试工作量 w太少的测试是不负责任，过多的测试是一种 犯罪。 w10
4、0的测试是不可能的，不同的用户采用的 测试策略是不同的。 缺陷产生的原因 w测试原因导致的缺陷： 测试目标定义错误 在开发生命周期中，错误的选择了测试介入时期 选择了低效的测试技术 测试人员专业知识培训不够，工作低效 计划不够详细，测试的随意性很大 测试人员同开发人员沟通困难 续 w软件方面 使用了不完全的或者不正确的判定标准来设计软 件。 错误的处理了用户的非法操作 忽略了对关键数据的输出检查 w数据问题 出现了不完整的数据，不正确的数据，过期的数 据 测试效果的好坏是组织级的问题 w有效的测试最好由一个独立的团队来实施。 便于确定工作目标 便于人员的培养与升迁 利于团队建设 对质量的忠诚度
5、高 利于新技术，新方法的产生和推广 工作职责明确 测试规划 w好的测试不是碰巧发生的，而是规划出来的 。 时间上 人员上 环境上 技术上 关系上 组织能力上 资金上 结构化测试方法 w传统的软件开发生命周期： 需求，设计，编码，测试，系统维护 经验： 测试不应该被局限在单一的阶段 大量的系统问题产生在软件开发前期 越早进行测试越有效，投入产出比越高 开发生命周期中的验证活动 开发阶发阶 段验证验证 活动动 需求 .确定验证 步骤 .对需求进行评审 .产生功能测试 用例 .确定需求一致性 设计 .确定设计 信息是否足够 .准备结 构和功能的测试 用例 .确定设计 的一致性 编码 .为单 元测试产
6、 生了结构和功能测试 的测试 用例 .进行了足够的单元测试 测试 .测试应 用系统，着重在功能上 安装 .为测试过 的系统进 行产品化的工作 维护 .修改缺陷并重新测试 测试策略 w在测试策略中必须标明可能存在的风险，这 样在测试后的系统中可以有效的降低被标明 的风险发生的可能性。 测试要素：需要被标明的风险也是我们测试的重 点。 测试阶段：在整个开发生命周期中，测试工作介 入的时期。 测试要素 w正确性：数据输入，过程处理和输出的正确性（IPO）。 w文件完整性：文件被正确使用，恢复和存储的数据正确。 w授权：特殊的授权可以执行一个特殊的操作。 w进程追踪：当进程运行中，程序有能力证实进程在
7、正常工作 。 w系统运行的连续性：当有非致命性问题发生后，系统有能力 继续运行关键的任务。 w服务水平：系统有紧急情况发生时，要求程序的输出结果不 经或进行简单的处理后就可以直接使用。 w权限控制：防止系统被误用（意外或者有意的） 测试要素(续) w一致性：确保最终设计和用户需求完全一致 w可靠性：在规定的时间内都可以正常运转。 w易于使用：多数人均感觉易于使用。 w可维护性：可以很容易的定位问题，并且进行修改 。 w可移植性：数据或者程序易于移至到其它系统上。 w耦合性：系统中的组件可以很容易的联接。 w性能：系统资源的占用率，响应时间，并发处理 w操作性：易于操作（Operator） 确定
8、测试策略 w选择并确定测试要素的等级 多数情况下选择37个 w确定开发阶段 w明确商业风险 开发人员，重要用户和测试人员通过评审的方式 对这些风险达成一致的意见。 w把风险列表存放在需求矩阵中 矩阵中可以将风险同测试用例对应起来。 测试方法学 测试方法 w测试策略 测试要素 测试阶段 w测试战略 简要描述如何在以后的测试活动中实现测试策略 确定测试战略 w流水线的概念 输入：标准的入口或者是个可执行的程序 执行过程：按照工作分配执行 检查过程：确定输出符合预定义的标准 输出：符合现存的标准或者是认可的可交付的版 本 QC和QA w质量控制 验证产品的正确性，当发现与设计不一致的时候 进行纠正。
9、 w质量保证 充当支持执行全面质量管理的角色 测试涉及的定义和概念 w缺陷 与需求规格说明书不一致的地方。 w静态检查 确保系统按照组织的标准和过程运行，主要依赖 于评审和非运行的手段来检查。 w动态检查 在生命周期中进行测试（运行） 续 w静态测试 在不运行程序的情况下检查程序的运行情况。 w动态测试 运行程序代码 w测试分类 单元测试 集成测试（组装测试） 系统测试 验收测试 回归测试 续 w功能测试 测试功能需求 w结构测试 验证系统架构 w黑盒测试 在不了解系统结构的情况下以说明书作为基础进 行测试。 w白盒测试 以系统内部结构和相关知识为基础进行测试。 为什么缺陷很难被找出？ w看不
10、到 w看到但是抓不到 w典型的缺陷类型 需求解释有错误 用户定义错了需求 需求记录错误 设计说明有误 编码说明有误 程序代码有误 数据输入有误 测试错误 问题修改不正确 正确的结果是由于其它的缺陷产生的 静态测试 w需求评审 w设计评审 w代码走查 w代码检查 动态测试 w单元测试 w集成测试 w系统测试 w用户的验收测试 w回归测试 使用静态和动态测试来进行结构和功能测 试 测试阶测试阶 段执执行人静态态校验验动态动态 校验验 可行性评审开发人员，用户 需求评审开发人员，用户 设计评审开发人员 单元测试开发人员 集成测试开发人员，用户 系统测试开发人员在用户 的协助下完成 验收测试用户 确定
11、测试战术的八个步骤 w确定并且学习测试策略 w确定项目开发类型 w确定软件系统类型 w确定项目范围 w鉴别战术风险 w确定开始测试时会遇到的问题 w建立系统测试计划 w建立单元测试计划 确定并学习测试策略 w在众多的测试策略中那些是重要的 w那些风险是最重要的 w如果软件不能正常运行时，商业上会有什么 损失 w如果软件不能及时完成，商业上会有什么损 失 w谁是最清楚风险影响的人 确定项目开发类型 w传统的系统开发 w交互式开发/原型法 w系统维护 w购买/签约/合同软件项目 确定软件系统类型 模拟 数据采集 数据显示 流程控制 决策&辅助协助 图形&图象处理 数据库管理 诊断软件 计算机操作系
12、统 传感器和信号处理 软件开发工具 确定项目范围 w新系统的开发 会影响那一个商业领域 与现有系统的接口 w在现有的系统上开发 只是修正Bug？ 重新设计维护？ 增加新的功能？ 对其它系统有无影响？ 为了减小商业上的风险？ 识别在战术上的风险 w将策略风险分解成战术风险 建立测试计划，定位这些风险 将风险分布于各个阶段的测试计划中 w战术风险的种类 结构风险 技术风险 工作量的风险 测试开始时应确定的工作 w需求阶段 确定测试策略 确定收集了足够的需求 产生功能性的测试用例 w设计阶段 确定设计和需求之间的联系 确定进行了足够的设计 产生结构和功能的测试用例 w编码阶段 确定和设计之间的联系
13、确定拥有执行的足够条件 产生结构和功能的测试用例 续 w测试阶段 确定设计了足够的测试用例 测试应用系统已经完成 关键资源已经到位 w安装阶段 将测试完成的系统变为产品 w维护阶段 修改和重新测试 建立计划 w建立系统测试计划 w建立单元测试计划 w在测试战术上我们要花多长时间？ “如果计划作失败了，那就在计划失败” 时间花在计划上要比花在重复的测试上有效 测试的技巧 测试技巧分类 w结构测试相对于功能测试 w动态测试相对于静态测试 w手工测试相对于自动测试 结构测试技巧 w压力测试 w执行测试 w恢复测试 w操作测试 w复合性测试（与过程的复合性) w安全测试 压力测试 w目标 模拟出实际用
14、户环境 w怎么用 产生测试数据 测试组模拟用户处理被创建的数据 w例子 确定是否分配了足够的磁盘空间 通讯的容量是否足够 测试系统过载的情况 w什么时间使用 当关于容量的信息不确定的时候 性能测试技巧 l目标 确定系统达到了希望达到的性能水平 l如何使用 使用软件和硬件的监视器 使用模拟的监控模型，对关心的性能指标进行监控 创建一个小程序 l例子 计算通信的时间 单位时间处理的信息量 l什么时候使用 在程序开发的早期进行 恢复测试 w目标 当在进行安装或组装操作过程中，文件丢失时或发生意 外后系统有能力重新进行操作 w如何使用 程序的安装，运行方式，工具的使用和关键技术经过足 够的评估 系统开
15、发完毕后，介绍一下发生失败后的处理过程 w例子 人为的使一个系统在安装或者组装过程中产生错误 w什么时间去使用 当操作的连续性是个重点的时候 操作测试 w目标 确定计算机的操作文档已经完整 w如何使用 作为计算机正常操作的一部分来执行测试 w例子 操作的介绍被文档化，操作者被培训 w什么时候使用 预先将程序进行产品化。操作性是系统的一个重 要指标的时候。 复合性测试 w目标 校验程序的开发是否依照已定义的标准，流程和操作方 式进行的。 w如何去使用 将文档/程序同标准相比较 比较有效的方法是检查过程 w例子 代码互查（一行一行） w什么时候使用 依赖于管理的需要 安全性测试 w目标 安全性的缺
16、陷很难被发现。 大多数的情况下组织能够防止一般性的破坏者。 w如何使用 对安全性的需求进行评审 分析与安全性有关的处理流程 转包给专业的人员 w例子 定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可 用的。 w什么时间使用 当被保护的资源对于组织具有重要的价值的时候 功能测试技巧 w需求测试 w回归测试 w错误处理测试 w支持手册的测试 w系统兼容测试 w控制性测试 w并行测试 需求测试 w目标 用户的需求可以被实现 w如何使用 创建测试用例和功能检查列表 w例子 建立测试矩阵去证实系统需求均被文档化 w什么时候使用 每一个应用程序都要进行需求测试 回归测试 w目标 程序修改后，确保
17、功能的正确性 w如何使用 重新测试应用程序中没有改变的部分 w例子 重新执行以前的测试用例 w什么时间使用 当新的程序有可能影响老的功能的时候 错误处理测试 w目标 所有可能的错误条件均经过了验证 w如何使用 一组有经验的人员预测在那里会出现问题 w例子 建立一个错误处理的列表 w什么时候使用 贯穿整个开发生命周期 支持手册测试 w目标 检验操作过程被文档化了，并且完整了。 w如何使用 对过程有足够的介绍 可以协助用户正常使用 w例子 系统在一定的条件下产生一个提示，用户被告知如何采 取必要的操作。 w什么时候使用 最佳时机是在安装测试的时候，但是应该在开发全过程 中。 兼容性测试 w目标 检
18、验当使用适当的参数和数据时，需要的信息可以在两 个系统中正确的交换 w如何使用 文件和数据被用来在多系统之间传递。 w例子 典型的由一个系统到另一个系统的数据交换程序。 w什么时候使用 当两个应用程序之间的参数有可能发生变化的时候 管理能力测试 w目标 验证数据交换时有足够的审计追踪能力 w如何使用 关键数据或者有价值的数据 w例子 从负面来看程序，是否确保了会出错的条件都被 保护了。 w什么时候使用 系统测试的一部分 并行测试 w目的 新版本和老版本同时运行，用以确保新版本的程 序运行正确。 w如何使用 需要对两个系统输入相同的数据来运行 w例子 运行新旧两个工资支付系统 w什么时间使用 当
19、对新系统的的运行情况不确定的时候 单元测试 w关注单元一级 w代码分析和测试 w功能分析和测试 w结构分析和测试 w以错误为导向的分析和测试 测试要素/测试技巧矩阵 测试 要素 压力 执行 恢复 操作 复合性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 并行 单元 可靠性 授权 文件完整性 审查 追踪 过程连续 性 继续 测试 要素 压力 执行 恢复 操作 完整性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 平行 单元 服务水平 权限控制 一致性 正确性 易用性 可维护 性 兼容性 耦合性 性能 可操作性 测试工具的选择 测试工具 w测试标准 w边界值分析 w因果图
20、 w检查表 w代码比较对照 w以编译为基础的分析 w确认/检查 w控制流分析 测试工具(继续) w能证明正确性的数据 w以覆盖为基础的测试 w数据字典 w数据流分析 w以设计为基础的功能测试 w设计评审 w桌面检查 w灾难性测试 测试工具(继续) w错误猜测 w执行的规则 w全面的测试 w实况调查 w流程图 w检查,视察 w使用仪器设备 w综合测试设备 w映射图 测试工具(继续) w建模 w并行操作 w并行模拟 w代码互查 w风险矩阵 w系统控制的评审 w得分 w快照(把系统一个时刻的情况保存下来) 测试工具(继续) w完成特征 w系统日志 w测试用例 w测试用例的产生形式 w跟踪 w工具程序
21、 w容量的测试 w走查(讲解开发思路) 选择和使用测试工具 w按照用途选择匹配的工具 w在适当的生命周期选择工具 w按照测试人员的实际技能选择匹配的工具 w选择一个可提供的工具 测试工具/测试技巧矩阵 测试工具 压力 执行 恢复 操作 完整性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 平行 单元 确认测试标 准 边界值分析 因果图 检查 表 代码比较 编译 分析 确认/检查 控制流 证明正确性的数据 测试工具/测试技巧矩阵(继续) 测试工具 压力 执行 恢复 操作 完整性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 平行 单元 以覆盖为基础的测试 数据字典 数据流
22、分析 以设计为 基础的功能测 试 设计评审 桌面检查 灾难性测试 错误 猜测 执行规则 全面的测试 测试工具/测试技巧矩阵(继续) 测试工具 压力 执行 恢复 操作 完整性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 平行 单元 实况调查 流程图 检查 使用仪器 综合测试设备 映射图 建模 并行操作 并行模拟 代码互查 测试工具/测试技巧矩阵(继续) 测试工具 压力 执行 恢复 操作 完整性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 平行 单元 风险对 照表 系统控制审计评审 打分 系统快照 特征执行 系统日志 测试 数据 产生测试 数据 跟踪 工具程序 测试工具
23、/测试技巧矩阵(继续) 测试工具 压力 执行 恢复 操作 完整性 安全性 需求 回归 错误处 理 手工支持 系统兼容 管理 平行 单元 容量测试 走查 软件开发生命周期/测试工具对照表 测试 工具需求设计编码测试安装维护 确认测试标 准 边界值分析 因果图 检查 表 代码比较 编译 分析 基础复杂度量测试 控制流分析 验证 、检查 正确性数据 覆盖测试对 照表 数据字典 软件开发生命周期/测试工具对照表( 继续 ） 测试 工具需求设计编码测试安装维护 数据流分析 设计为 基础的功能测试 设计评审 桌面检查 灾难性测试 错误 猜测 执行规范 全面的测试 实况调查 流程图 检查 使用仪器 软件开发
24、生命周期/测试工具对照表( 继续） 测试 工具需求设计编码测试安装维护 综合测试 工具 映射图 模型 并行操作 并行模拟 代码互查 风险 列表 系统控制审计评审 打分 系统快照 完成特征 系统日志 软件开发生命周期/测试工具对照表( 继续） 测试 工具需求设计编码测试安装维护 测试 用例 测试 用例得产生形式 跟踪 工具程序 容量测试 走查 测试工具管理 w工具管理者的职责 对工具负责 帮助同事使用这些工具 培训工具得使用方法 负责同工具的厂家联系 每年给出有关工具使用和购买得计划 工具得升级 工具情况报告 w工具管理者得任期不易太长 软件的测试过程 软件的测试过程 w估算 w测试计划 w需求
25、 w设计 w编码 w测试总结 w安装，交付 w维护 估算 估算什么 w测试对软件工作量的估算的准确性 w测试评估软件系统的状况的准确性 w关注点： 不准确的估算 不适当的开发过程 不真实的状态报告 对工作量的估算 w如何知道对工作量的估算是正确的 估算工作量的工具很容易出错 对软件工作量的估算需要策略 五个一般的方法 w猜 w加入一些约束条件 w以一些数据为基础 w模拟进行工作 w将一些参数模型化 参数模型法 w回归模型：将现有的参数与已有的历史数据 相拟和。 w启发式模型：对历史数据进行观察和解释 w现象模型：假设软件开发过程可以依据一些 更广泛的可适用的过程解释。 模型遵循的共同模式 w估
26、算软件的大小 w将大小转化成人力的估算，并且作出可能的 成本的估算 w依据项目的特性进行估算的调整 w将整体的估算划分到不同的项目阶段中 w估算不包括技巧上面的人力和计算机的运行 时间 w将以上内容相加 对估算进行检验 w检验估算模型的合理性 w检验模型是否包含了必须的测试要素 w检验模型的正确性 校验估算模型的正确性 w重新进行估算 校验输入是否正确 校验输入是否合理 校验对数据的计算是否合理有效 w比较延期的估算是否符合项目实际情况 w让谨慎的人来作测试验证工作 w对软件中的冗余价值估算 影响估算正确与否的因素 w软件规模 w新设计新代码的比例 w复杂程度 w设计和编码的困难 w使用什么语
27、言 w安全性 w需求的挥发性 续 w组织因素 项目计划 人员 开发环境 计算机资源 人员利用率 膨胀因素 w估算就是估算，不是保证书 软件进展测试 w追踪系统的瓶颈 工作完成点 同配置管理系统紧密的结合 如何使用 w模块列表 w里程碑 w工作完成点 用计算所有工作的完成度来检查系统工作过程。 测试计划 开发测试计划 w目标 详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和 实施计划。 w可能的不利因素： 没有得到足够的培训 心里准备不足 缺乏测试工具 缺乏管理的标准和支持 缺乏客户和最终使用者的参与 没有足够的时间进行测试 对于独立的测试人员过度信任 版本改变的太快 测试人员处于不受
28、重视的情况中 不能说不 实施过程 w听取各方面的意见和建议 w标明项目风险 测试要素 联系测试矩阵 w建立测试计划 w对计划进行评审 建立测试计划 w定义测试目标 w开发测试矩阵 软件模型 结构特性 批量测试的阶段和用例 为在线系统作概念上的测试脚本 软件测试矩阵 w定义测试管理 测试计划的一般性信息 定义测试里程碑 定义管理上的检查点 w书写测试计划 评审测试计划 w涉及评审的问题 评审测试的开始时间是否会延期 有没有抵触评审的角色 一段时间内是否很难得到工作的检查信息。 更换工具有可能导致他们反感评审工作 评审结果可能会影响对个人的工作评价 w对于最终成品的检查 项目的需求规格说明书 软件
29、返工/维护的文档 升级后的技术文档 被更改的源程序 测试计划 用户手册（包括在线帮助） 续 w正式评审中的角色 缓和剂（SQA） 读者 记录者 作者 检测员 w正式评审发现的缺陷应包含的信息 起因 类型 分类 级别 评审流程 w计划和组织 w通篇的讲解（可选） w个人准备 w评审会议 w修订和反复 需求阶段的测试 测试成本 w在软件开发的所有阶段进行测试 被设计用来减少测试成本 wIBM的数据 大约 60个缺陷/千行 2/3的缺陷产生在需求和设计阶段 w在需求和设计阶段发现的缺陷修正的花费最小 w修正系统测试阶段发现的缺陷，花费是以上的10倍 w发布产品以后，修正缺陷的花费是原来的100倍 生
30、命周期的测试概念 w在软件开发过程中持续的进行测试 w在尽可能早的阶段点去修正缺陷 w需要正式的开发流程来支持 w组建测试团队 w当开发开始进行的时候，测试就开始进行了 需求阶段的测试 w准备风险列表 确定风险组 确定风险 w风险分析 w风险检查表 建立控制目标 确定有足够的控制力度 分析测试要素 w需求的设计是否遵循了已定义的方法 w提交了已定义的功能说明 w定义了系统界面 w已经估计了性能标准 w容忍度被预先估计 w预先定义了权限规则 w需求中预先定义了文件完整性 w预先定义了需求的变更流程 w预先定义了失败的影响 w权限定义 需求走查 w建立基本规则 w选择小组/通报参与者 w项目介绍
31、w问题/建议 w形成最终报告 需求阶段测试 w所有的花费都是值得的 w大部分缺陷将不会进入到设计&编码阶段 w目标 需求正确的表现出了用户的需要 需求已经被定义和文档化了 花费和收益成正比 需求的控制被明确 有合理的流程可遵循 有合理的方法可供选择 设计阶段的测试 设计阶段的测试 w交付的产品 输入说明 过程说明 文件说明 输出说明 控制说明 系统流程图 硬件和软件的需求 操作手册说明书 数据保留的策略 设计阶段测试任务 w给测试要素打分 w分析测试要素 w对设计进行评审 w检查修改的部分 分析测试要素 w测试涉及的内容： 设计了对数据完整性的控制 设计了权限规则 设计了对文件完整性的控制 设
32、计了审计追踪 设计了发生意外情况时的计划 设计了如何达到服务水平的方法 定义了权限流程 定义了完整的方法学 设计了保证需求一致性的方法 进行了易用性的设计 设计是可维护的 设计是简单的 交互界面设计完毕 定义了成功的标准 需要同实际操作者沟通 对设计进行评审 w选择评审组成员 w对评审组进行培训 w通报项目组 w分配足够的时间 w只对文档化的事实进行评审 w和项目组一起进行评审 w对评审形成建议 w和项目组对建议一起进行评审 w准备正式的报告 编码阶段的测试 形成的输出 w编码说明书 w程序文档 w计算机程序列表 w可执行的程序 w程序流程图 w操作介绍 w单元测试结果 测试活动的关注点 完成
33、对数据完整性的控制 定义完毕授权的规则 完成对文件完整性的控制 实现审计追踪 规划出意外情况发生后的处理计划 对系统如何达到预定义的服务水平做了计划 完成了对安全问题的处理流程 编码工作是依据规定的方法完成的 编码与设计相一致（正确性） 编码与设计相一致（易用性） 代码是可维护的 编码与设计相一致（简洁性） 编码与设计相一致（耦合性） 已开发了操作流程 定义出程序成功的标准（性能上） 测试的职责 w编码是一个纯技术的工作，几乎不需要用户 的参与 w项目领导者有参与测试的责任 w监督过程的有效性 建议的测试方式 w桌面调试 语法上的 结构上的 功能上的 w代码互查 建立基本的互查规则 选择互查的
34、team 对成员进行培训 选择互查的方法 提供互查的材料 w 流程图，源程序，典型的处理流程 对互查进行必要的管理 给出互查结论 提供最终的报告 编码阶段的测试需解决的问题 w系统是可维护的吗？ w系统说明是否已经完成了？ w编码是否按照既有的标准进行，过程是否易 于实践？ w是否有足够的测试计划用来评估可执行的程 序？ w是否编制了足够的文档。 测试关注点 w在需求，设计，编码阶段多进行一些测试， 在系统测试阶段就会少一些问题。 w文档 测试阶段的测试计划 测试用例 前期测试的测试结果 第三方测试反馈，例如：计算机操作人员 正式的测试总结报告 典型测试类型 w手册，回归，功能点测试 w一致性
35、测试（授权） w功能点测试（完整性） w功能点测试（审计，追踪） w覆盖性的测试（测试的连续性） w压力测试（服务水平） w一致性测试（安全性） w依照预先定义的测试方法 w功能点测试（正确性） w支持手册的测试（易用性） w检查（可维护性） w灾难性的测试（可携带性） w功能和回归测试（耦合性） w一致性的测试（性能） w操作性的测试（易用性） 建议测试方法 w测试方法 测试用例的概念是简单的 建立有效的测试用例是复杂的 设计测试文件 w 测试用例应当包含合法的和非法的输入 w 每一个动作只进行一次关键操作 输入测试数据 分析结果 尝试将测试文件违反程序的规则进行输入 w容量测试的测试工具
36、以大信息量的数据进行输入 这是一个昂贵的测试，应根据需要来选择 在线系统需要做压力测试 测试总结 测试报告 w目标 表示出目前项目的实际状况 明确什么是测试做的工作，什么是不作的工作。 给出系统的操作性能的评价 明确什么时候系统可以进行产品化的工作 w关注点 测试报告只有真正需要的时候才有用，需要配合市场和 管理 测试的信息是不充分的（对于评价一个项目来说） 测试状况并不能真实的反应个人的状况 测试期间数据的收集 w有关测试结果的积累数据 w测试任务，测试集合和测试事件的描述 w缺陷分析 由于计划的问题，导致没有发现的缺陷的数据 严重的缺陷 缺陷类型 为什么缺陷没有发现 w效果 测试报告 w报
37、告目前的软件状态 功能/测试矩阵 功能测试的状态报告，侧重点分析 关于功能的工作时间轴 期望发现 VS 实际发现的缺陷比 没有发现的缺陷和改正的缺陷的差距 按照类型分类，没有改正的缺陷的平均值 缺陷分类报告 测试活动报告 最终的报告汇总 w各个阶段的项目测试总结报告 w继承性测试报告 w系统测试报告 w确认测试报告 安装测试 安装阶段的测试准备 w安装计划 w安装流程图 w安装文件和程序清单 w测试安装程序给出测试结果 w将程序运行的软硬件要求放入产品说明中 w对于新操作人员的使用说明书 w对于新使用者的操作说明和操作流程 w安装过程中的各项可能发生的结果的说明 测试关注点 w对程序安装的正确
38、性和完整性进行核对 w校验产品文件的完整性 w安装的审查，追踪被记录 w安装之前，该系统已经被证实没有问题 w如果安装失败，系统有相应的解决方案 w安装过程，进行了权限控制（安全性） w安装遵循一定的方法，步骤 w需要的配套程序和数据已经放进了产品中 w已交付使用说明 w相关文件已经完整(可维护性） w接口已经被合理调整（耦合性） w综合的性能达到了用户要求 建议测试工具 w测试工具检查表 选择测试的范围 选择检查表 明白这些问题的用意 提前测试用户的检查表 使用该检查表模拟运行一遍 自己向自己汇报一次 将有用的信息记录下来 评估检查表和检查流程 续 w测试标准 数据的正确性 w将程序产品化
39、w向操作者和用户进行讲解 w校验检查表和产品的正确性 w使用测试标准去检验发生的问题 验收测试 软件验收流程 w定义用户角色 w定义验收标准 w编制验收计划 w执行验收计划 w填写验收结论 定义用户角色 w确定最终用户的范围 w确认临时的和最终产品的验收标准 w计划每一个验收过程由谁和如何执行 w计划资源分配 w计划时间分配 w准备验收计划 w为每一项验收工作给出结论 确定验收标准 w功能上 w性能上 w接口质量上 w过载后的软件质量 w安全性 w软件的稳定性 编写验收计划 w项目描述 w用户职责 w行政上的流程 w验收活动描述 w每一个验收项的评审 w最终的验收测试步骤 执行和结论 w执行验
40、收计划 验收测试和评审进行管理 w验收的结果 典型的验收结果 w在进入下一个活动之前问题或者变更必须被接受 w工作可以继续，但是下次评审之前必须更正 w没有任何的更改 维护阶段 工作重点和目标 w两个重要的工作：测试和培训 w目标： 开发一些测试用例，预先发现一些问题 在运行情况发生变化后，预先的修正一些错误 编写必要的培训材料 对有关的人员进行培训 同用户进行接触 开发更新测试计划 w测试计划要简短，必须在短时间内完成。 w只测试变化的部分 w两点：测试什么，如何测试 w测试要素 变化的数据交换 变化的程序 操作流程 用户的操作习惯 不同系统之间的互联 语言版本 安全性 备份/恢复 编制培训
41、计划 w对系统进行概览 w对系统假定一些错误，给出处理方法 w培训材料 对项目内容的陈述 用户使用方法 对错误列表上的问题给出解释 对报告进行解释，并且说明如何使用他们（图标 ，数据等） 对输入数据进行解释 反馈 w反馈包括：用户反馈和测试反馈，又分成错 误和建议。 w没有反馈意见，程序很难提高 w反馈的类型 测试的数量和内容 发现的问题数量和分类 区分是技术上的还是应用上的问题 w将反馈信息重新整理，加入到相关的测试数 据中 实例讲解测试活动在软件工程中的应 用 活动阶段分类 w需求阶段 w设计阶段 w编码阶段 w集成测试阶段 w系统测试阶段 w验收测试阶段 w产品化发货阶段 阶段流程图 w总体流程图 w需求阶段测试工作流程 w设计&编码阶段测试工作流程 w集成，系统，验收测试阶段 谢谢