《中国软件测试中心的培训资料》由会员分享，可在线阅读，更多相关《中国软件测试中心的培训资料（145页珍藏版）》请在金锄头文库上搜索。
1、软件测试培训中国软件测试中心培训列表软件测试的目的和策略测试方法学测试的技巧测试工具的选择软件开发中的测试过程实例讲解测试活动在软件工程中的应用软件测试的目的和策略典型测试步骤1.计划： 定义目标 确定策略 确定方法 2.执行： 建立环境 执行计划 3.检查：一步步验证 执行完毕？ 4.循环：没有改正 继续执行谁参与测试？w用户方代表w软件最终使用者w软件开发人员w软件测试人员w高层经理的支持w过程保证人员（SQA）什么试缺陷？w缺陷：最终产品同用户的期望不一致 w缺陷的分类 错误 遗漏 超出需求的部分 w缺陷（未触发）VS.错误（应首先解决）测试的商业意义w降低风险（风险：就是不希望发生的事
2、情的 可能性）w测试计划中必须标明商业上的风险。w测试人员职责：评估商业上的风险 如实的向管理层汇报项目情况目前公司内测试组织的等级w测试是一件艺术品，很难掌握。w测试是一门手艺，精通很困难。w测试使用的是已定义好的测试流程，有规则 可寻。w测试有较高级的组织形式。w世界级的测试组织。测试的职责验证在整个软件开发周期中，各个阶段的软件质 量是否合格。 验证最终交付给用户的系统是否满足用户的需要 ，是否符合需求。 通过样本测试数据，检查系统在运行过程中的情 况。对待可能产生的风险的策略w我们无法消除风险，但是我们可以降低在风 险发生时的损失。w降低系统风险的最有效的办法就是对其进行 有针对性的测
3、试。系统风险列举w如果某部分产生了错误会导致的结果？w未被验证的数据交换如果被接受w如果文件的完整性被破坏w系统是否能被安全恢复（完全恢复成备份时的状态 ）w是否能暂停系统的运行w进行维护工作时，系统性能是否会下降到不能接受 的水平。w系统的安全性是否有保证系统风险列举（继续）w系统的操作流程是否符合用户的组织策略和 长远规划w系统是否可靠，稳定w系统是否易于使用w系统是否便于维护w是否易于与其它系统相连测试工作量w太少的测试是不负责任，过多的测试是一种 犯罪。w100的测试是不可能的，不同的用户采用的 测试策略是不同的。缺陷产生的原因w测试原因导致的缺陷：测试目标定义错误 在开发生命周期中，
4、错误的选择了测试介入时期 选择了低效的测试技术 测试人员专业知识培训不够，工作低效 计划不够详细，测试的随意性很大 测试人员同开发人员沟通困难续w软件方面使用了不完全的或者不正确的判定标准来设计软 件。 错误的处理了用户的非法操作 忽略了对关键数据的输出检查w数据问题出现了不完整的数据，不正确的数据，过期的数 据测试效果的好坏是组织级的问题w有效的测试最好由一个独立的团队来实施。便于确定工作目标 便于人员的培养与升迁 利于团队建设 对质量的忠诚度高 利于新技术，新方法的产生和推广 工作职责明确测试规划w好的测试不是碰巧发生的，而是规划出来的 。 时间上 人员上 环境上 技术上 关系上 组织能力
5、上 资金上结构化测试方法w传统的软件开发生命周期：需求，设计，编码，测试，系统维护经验：测试不应该被局限在单一的阶段 大量的系统问题产生在软件开发前期 越早进行测试越有效，投入产出比越高开发生命周期中的验证活动开发阶发阶 段验证验证 活动动 需求.确定验证 步骤 .对需求进行评审 .产生功能测试 用例 .确定需求一致性 设计.确定设计 信息是否足够 .准备结 构和功能的测试 用例 .确定设计 的一致性 编码.为单 元测试产 生了结构和功能测试 的测试 用例 .进行了足够的单元测试 测试.测试应 用系统，着重在功能上安装.为测试过 的系统进 行产品化的工作维护.修改缺陷并重新测试测试策略w在测试
6、策略中必须标明可能存在的风险，这 样在测试后的系统中可以有效的降低被标明 的风险发生的可能性。测试要素：需要被标明的风险也是我们测试的重 点。 测试阶段：在整个开发生命周期中，测试工作介 入的时期。测试要素w正确性：数据输入，过程处理和输出的正确性（IPO）。 w文件完整性：文件被正确使用，恢复和存储的数据正确。 w授权：特殊的授权可以执行一个特殊的操作。 w进程追踪：当进程运行中，程序有能力证实进程在正常工作 。 w系统运行的连续性：当有非致命性问题发生后，系统有能力 继续运行关键的任务。 w服务水平：系统有紧急情况发生时，要求程序的输出结果不 经或进行简单的处理后就可以直接使用。 w权限控
7、制：防止系统被误用（意外或者有意的）测试要素(续)w一致性：确保最终设计和用户需求完全一致 w可靠性：在规定的时间内都可以正常运转。 w易于使用：多数人均感觉易于使用。 w可维护性：可以很容易的定位问题，并且进行修改 。 w可移植性：数据或者程序易于移至到其它系统上。 w耦合性：系统中的组件可以很容易的联接。 w性能：系统资源的占用率，响应时间，并发处理 w操作性：易于操作（Operator）确定测试策略w选择并确定测试要素的等级 多数情况下选择37个w确定开发阶段w明确商业风险开发人员，重要用户和测试人员通过评审的方式 对这些风险达成一致的意见。w把风险列表存放在需求矩阵中矩阵中可以将风险同
8、测试用例对应起来。测试方法学测试方法w测试策略测试要素 测试阶段w测试战略简要描述如何在以后的测试活动中实现测试策略确定测试战略w流水线的概念输入：标准的入口或者是个可执行的程序 执行过程：按照工作分配执行 检查过程：确定输出符合预定义的标准 输出：符合现存的标准或者是认可的可交付的版 本QC和QAw质量控制验证产品的正确性，当发现与设计不一致的时候 进行纠正。w质量保证充当支持执行全面质量管理的角色测试涉及的定义和概念w缺陷与需求规格说明书不一致的地方。w静态检查确保系统按照组织的标准和过程运行，主要依赖 于评审和非运行的手段来检查。w动态检查在生命周期中进行测试（运行）续w静态测试 在不运
9、行程序的情况下检查程序的运行情况。 w动态测试 运行程序代码 w测试分类 单元测试 集成测试（组装测试） 系统测试 验收测试 回归测试续w功能测试 测试功能需求 w结构测试 验证系统架构 w黑盒测试 在不了解系统结构的情况下以说明书作为基础进 行测试。 w白盒测试 以系统内部结构和相关知识为基础进行测试。为什么缺陷很难被找出？w看不到 w看到但是抓不到 w典型的缺陷类型 需求解释有错误 用户定义错了需求 需求记录错误 设计说明有误 编码说明有误 程序代码有误 数据输入有误 测试错误 问题修改不正确 正确的结果是由于其它的缺陷产生的静态测试w需求评审w设计评审w代码走查w代码检查动态测试w单元测
10、试w集成测试w系统测试w用户的验收测试w回归测试使用静态和动态测试来进行结构和功能测 试测试阶测试阶 段执执行人静态态校验验动态动态 校验验 可行性评审开发人员，用户 需求评审开发人员，用户 设计评审开发人员单元测试开发人员集成测试开发人员，用户系统测试开发人员在用户 的协助下完成验收测试用户确定测试战术的八个步骤w确定并且学习测试策略 w确定项目开发类型 w确定软件系统类型 w确定项目范围 w鉴别战术风险 w确定开始测试时会遇到的问题 w建立系统测试计划 w建立单元测试计划确定并学习测试策略w在众多的测试策略中那些是重要的w那些风险是最重要的w如果软件不能正常运行时，商业上会有什么 损失w如
11、果软件不能及时完成，商业上会有什么损 失w谁是最清楚风险影响的人确定项目开发类型w传统的系统开发w交互式开发/原型法w系统维护w购买/签约/合同软件项目确定软件系统类型模拟 数据采集 数据显示 流程控制 决策&辅助协助 图形&图象处理 数据库管理 诊断软件 计算机操作系统 传感器和信号处理 软件开发工具确定项目范围w新系统的开发 会影响那一个商业领域 与现有系统的接口 w在现有的系统上开发 只是修正Bug？ 重新设计维护？ 增加新的功能？ 对其它系统有无影响？ 为了减小商业上的风险？识别在战术上的风险w将策略风险分解成战术风险建立测试计划，定位这些风险 将风险分布于各个阶段的测试计划中w战术风
12、险的种类结构风险 技术风险 工作量的风险测试开始时应确定的工作w需求阶段 确定测试策略 确定收集了足够的需求 产生功能性的测试用例 w设计阶段 确定设计和需求之间的联系 确定进行了足够的设计 产生结构和功能的测试用例 w编码阶段 确定和设计之间的联系 确定拥有执行的足够条件 产生结构和功能的测试用例续w测试阶段确定设计了足够的测试用例 测试应用系统已经完成 关键资源已经到位w安装阶段将测试完成的系统变为产品w维护阶段修改和重新测试建立计划w建立系统测试计划w建立单元测试计划w在测试战术上我们要花多长时间？ “如果计划作失败了，那就在计划失败”时间花在计划上要比花在重复的测试上有效测试的技巧测试
13、技巧分类w结构测试相对于功能测试w动态测试相对于静态测试w手工测试相对于自动测试结构测试技巧w压力测试w执行测试w恢复测试w操作测试w复合性测试（与过程的复合性)w安全测试压力测试w目标模拟出实际用户环境w怎么用产生测试数据测试组模拟用户处理被创建的数据w例子确定是否分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况w什么时间使用当关于容量的信息不确定的时候性能测试技巧l目标确定系统达到了希望达到的性能水平l如何使用使用软件和硬件的监视器使用模拟的监控模型，对关心的性能指标进行监控创建一个小程序l例子计算通信的时间单位时间处理的信息量l什么时候使用 在程序开发的早期进行恢复测试w目标 当
14、在进行安装或组装操作过程中，文件丢失时或发生意 外后系统有能力重新进行操作 w如何使用 程序的安装，运行方式，工具的使用和关键技术经过足 够的评估 系统开发完毕后，介绍一下发生失败后的处理过程 w例子 人为的使一个系统在安装或者组装过程中产生错误 w什么时间去使用 当操作的连续性是个重点的时候操作测试w目标 确定计算机的操作文档已经完整 w如何使用 作为计算机正常操作的一部分来执行测试 w例子 操作的介绍被文档化，操作者被培训 w什么时候使用 预先将程序进行产品化。操作性是系统的一个重 要指标的时候。复合性测试w目标 校验程序的开发是否依照已定义的标准，流程和操作方 式进行的。 w如何去使用
15、将文档/程序同标准相比较 比较有效的方法是检查过程 w例子 代码互查（一行一行） w什么时候使用 依赖于管理的需要安全性测试w目标 安全性的缺陷很难被发现。 大多数的情况下组织能够防止一般性的破坏者。 w如何使用 对安全性的需求进行评审 分析与安全性有关的处理流程 转包给专业的人员 w例子 定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可 用的。 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什么时候使用 最佳时机是在安装测试的时候，但是
