软件测试培训—中国软件测试中心的培训资料.pptVIP

桌面调试 语法上的 结构上的 功能上的 代码互查 建立基本的互查规则 选择互查的team 对成员进行培训 选择互查的方法 提供互查的材料 流程图，源程序，典型的处理流程 对互查进行必要的管理 给出互查结论 提供最终的报告 系统是可维护的吗？ 系统说明是否已经完成了？ 编码是否按照既有的标准进行，过程是否易于实践？ 是否有足够的测试计划用来评估可执行的程序？ 是否编制了足够的文档。 在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。 文档 测试阶段的测试计划 测试用例 前期测试的测试结果 第三方测试反馈，例如：计算机操作人员 正式的测试总结报告 手册，回归，功能点测试 一致性测试（授权） 功能点测试（完整性） 功能点测试（审计，追踪） 覆盖性的测试（测试的连续性） 压力测试（服务水平） 一致性测试（安全性） 依照预先定义的测试方法 功能点测试（正确性） 支持手册的测试（易用性） 检查（可维护性） 灾难性的测试（可携带性） 功能和回归测试（耦合性） 一致性的测试（性能） 操作性的测试（易用性） 测试方法 测试用例的概念是简单的 建立有效的测试用例是复杂的 设计测试文件 测试用例应当包含合法的和非法的输入 每一个动作只进行一次关键操作 输入测试数据 分析结果 尝试将测试文件违反程序的规则进行输入 容量测试的测试工具 以大信息量的数据进行输入 这是一个昂贵的测试，应根据需要来选择 在线系统需要做压力测试 目标 表示出目前项目的实际状况 明确什么是测试做的工作，什么是不作的工作。 给出系统的操作性能的评价 明确什么时候系统可以进行产品化的工作 关注点 测试报告只有真正需要的时候才有用，需要配合市场和管理 测试的信息是不充分的（对于评价一个项目来说） 测试状况并不能真实的反应个人的状况 有关测试结果的积累数据 测试任务，测试集合和测试事件的描述 缺陷分析 由于计划的问题，导致没有发现的缺陷的数据 严重的缺陷 缺陷类型 为什么缺陷没有发现 效果 报告目前的软件状态 功能/测试矩阵 功能测试的状态报告，侧重点分析 关于功能的工作时间轴 期望发现 VS 实际发现的缺陷比 没有发现的缺陷和改正的缺陷的差距 按照类型分类，没有改正的缺陷的平均值 缺陷分类报告 测试活动报告 各个阶段的项目测试总结报告 继承性测试报告 系统测试报告 确认测试报告 安装计划 安装流程图 安装文件和程序清单 测试安装程序给出测试结果 将程序运行的软硬件要求放入产品说明中 对于新操作人员的使用说明书 对于新使用者的操作说明和操作流程 安装过程中的各项可能发生的结果的说明 对程序安装的正确性和完整性进行核对 校验产品文件的完整性 安装的审查，追踪被记录 安装之前，该系统已经被证实没有问题 如果安装失败，系统有相应的解决方案 安装过程，进行了权限控制（安全性） 安装遵循一定的方法，步骤 需要的配套程序和数据已经放进了产品中 已交付使用说明 相关文件已经完整(可维护性） 接口已经被合理调整（耦合性） 综合的性能达到了用户要求 测试工具检查表 选择测试的范围 选择检查表 明白这些问题的用意 提前测试用户的检查表 使用该检查表模拟运行一遍 自己向自己汇报一次 将有用的信息记录下来 评估检查表和检查流程 测试标准 数据的正确性 将程序产品化 向操作者和用户进行讲解 校验检查表和产品的正确性 使用测试标准去检验发生的问题 定义用户角色 定义验收标准 编制验收计划 执行验收计划 填写验收结论 确定最终用户的范围 确认临时的和最终产品的验收标准 计划每一个验收过程由谁和如何执行 计划资源分配 计划时间分配 准备验收计划 为每一项验收工作给出结论 功能上 性能上 接口质量上 过载后的软件质量 安全性 软件的稳定性 项目描述 用户职责 行政上的流程 验收活动描述 每一个验收项的评审 最终的验收测试步骤 执行验收计划 验收测试和评审进行管理 验收的结果 典型的验收结果 在进入下一个活动之前问题或者变更必须被接受 工作可以继续，但是下次评审之前必须更正 没有任何的更改 两个重要的工作：测试和培训 目标： 开发一些测试用例，预先发现一些问题 在运行情况发生变化后，预先的修正一些错误 编写必要的培训材料 对有关的人员进行培训 同用户进行接触 测试计划要简短，必须在短时间内完成。 只测试变化的部分 两点：测试什么，如何测试 测试要素 变化的数据交换 变化的程序 操作流程 用户的操作习惯 不同系统之间的互联 语言版本 安全性 备份/恢复 对系统进行概览 对系统假定一些错误，给出处理方法 培训材料 对项目内容的陈述 用户使用方法 对错误列表上的问题给出解释 对报告进行解释，并且说明如何使用他们（图标，数据等） 对输入数据进行解释 反馈包括：用户反馈和测试反馈，又分成错误和