软件测试培训课件（PPT 精品）.ppt

ISTQB基础级培训讲义 北京昱达环球科技有限公司版权所有 北京昱达环球科技有限公司 目录 一 国际软件测试认证委员会 ISTQB 简介二 软件测试基础三 软件测试与软件生命周期四 软件静态测试技术五 软件测试设计技术六 软件测试管理七 软件测试工具 昱达公司简介 昱达环球科技有限公司 IGS 是中国首家专注于全球化 国际化和本地化新兴产业 开展全球化咨询 技术开发和人才培训 为中外企业提供信息全球化解决方案的供应商 是国际软件测试认证委员会 ISTQB 中国分会在北京唯一授权培训和认证机构 公司地址 北京市朝阳区北苑路68号星河写字楼204室邮政编码 100012公司网站 培训邮箱 CSTQB 联系电话 010 84935334移动电话一 ISTQBCTFL简介 CSTQB软件测试基础级培训教程 ISTQB与CSTQB简介 ISTQB简介国际软件测试认证委员会ISTQB InternationalSoftwareTestingQualificationBoard 于2002年在英国成立 ISTQB是国际唯一权威的软件测试资质认证机构 现有包括美国 德国 英国 法国 日本等47个成员国 中国软件测试认证委员会 CSTQB 在2006年成为ISTQB的正式成员 ISTQB培训与认证体系ISTQB CertifiedTester培训及认证体系分为三个级别 基础级 FoundationLevel高级 AdvancedLevel 3年以上测试工作经验专家级 ExpertLevel 5年以上测试工作经验培训者获得基础级证书后 可申请参加更高级别的培训和认证考试 并获得相应证书 CSTQBFL培训内容 ISTQBCTFL认证考试 考试形式闭卷笔试考试卷包含40道单选选择题 给定的答案中只有一项是正确的 考试时间为1小时分数达到65 以上 26题以上含26题 通过考试考试内容与比例 二 软件测试基础 CSTQB软件测试基础级培训教程 目录 为什么需要软件测试软件测试与软件质量软件测试的目的与原则软件测试过程 软件测试术语 1 术语错误Error Mistake缺陷Defect Bug Fault失效Failure说明程序员可能会犯错误 由此在程序或文档中产生缺陷 如果执行了代码中的缺陷 软件将可能无法实现应该实现的功能或者产生了不应该实现的结果 由此产生失效 软件 系统或者文档中的缺陷可能导致失效 但是并不是所有的缺陷都会导致失效 缺陷的产生是因为程序员容易犯错误 可能是因为时间压力 复杂的代码 架构复杂 技术变更 或者系统交互等引起的 失效也可能是环境条件引起的 例如 辐射 磁场 电场 污染导致硬件故障 或者由于改变了硬件的条件 对软件的执行产生影响 软件系统的失效不可能是老化或磨损引起的 软件测试术语 2 错误error是广义的概念 错误是人为的原因导致一个不正确的结果 它可以是程序内的内部错误 也可能是文档内的错误 缺陷是错误的具体表现 可以是不正确的文档 程序段 指令或数据定义 它们可能会引起一个外部的失效 failure bug defect和fault同义 因为存在的缺陷 defect 而导致软件的运行失败叫失效 失效是缺陷在执行测试软件时的外部反映 失效是 规范说明 期望的值与实际 观察到 的值存在偏差 例如系统的不正确的反应 崩溃 死机等 当缺陷引起了运行错误或对用户产生了消极影响时 它就被称为失效 对缺陷最大的担心就是它会转变为失效 而失效将会对用户产生损害 有一些缺陷可能永远也不会转变为失效 但有时一个缺陷又可能会引起上百万的失效 缺陷可以通过静态测试发现 而失效只能通过动态测试发现 软件测试的总体目标 总体目标发现缺陷获取对产品质量的信心提供用于决策的信息预防缺陷 早期测试 开发阶段的测试 运行阶段的测试 静态测试 组件测试 集成测试 系统测试 验收测试 非功能测试 维护测试 预防缺陷 发现缺陷 建立信心 提供信息 不同测试阶段的测试目的 软件需求阶段对文档的静态测试是为了预防缺陷在开发阶段执行的测试 组件测试 集成测试和系统测试 测试的主要目的可能是尽可能的使软件失效 从而发现和修改尽可能多缺陷 在验收测试中 主要目的可能是用来确认系统是否按照预期工作的 从而在系统是否满足系统需求方面得到信心 在有的情况 测试的主要目的可能是对软件的质量进行评估 不是为了修改缺陷 从而为利益相关人提供这样的信息 在给定时间内发布系统版本是否存在风险 在运行测试阶段 测试的主要目标可能是为了评估系统的特征 比如可靠性或可用性等 维护测试通常是为了验证在变更开发过程中是否有新的错误引入 测试和调试的区别 调试 Debug 和测试 Test 是两个不同的概念 测试测试可以发现由于软件缺陷引起的失效 测试员执行测试 调试调试是一种开发活动 用来识别引起缺陷的原因 修改代码以及验证是否正确的修改了软件的缺陷 开发人员执行调试 关系开发人员调试后的软件需要测试员进行确认测试 确认修改的代码已经解决了失效问题 开发人员除了调试 也执行某些类型的测试 测试在软件开发 维护和运行中的角色 测试是软件质量保证的关键活动和方式对软件系统和文档进行严格的测试 可以减少软件系统在运行环境中的风险 假如在软件正式发布之前发现和修正了缺陷 就可以提高软件系统的质量 测试对象包括软件产品 软件程序 手册和联机帮助 和开发过程产生的文档测试也可能需要满足合同和法律法规的需求 或者是为了满足特定的行业标准认证测试 微软认证CertificationGB18030测试ISTQB测试认证测试的工作产品 WorkProduct 测试的工作产品指的测试依据 Testingbasis 例如 业务场景 用例 需求规格说明 设计文档和代码 测试与软件质量 借助软件测试 可以通过发现的缺陷度量软件的质量 包括功能和非功能软件需求和特性 例如 可靠性 易用性 有效性 可维护性以及可移植性 测试如果发现较少或者没有发现缺陷 可以增强对软件质量的信心 正确设计的测试执行通过后减少了系统的整体风险级别 测试发现的缺陷修正 Fixed 后提高了软件系统的质量 应该从以前项目中吸取教训 理解其它项目中发现的缺陷的根本产生原因后 改进流程 这样可以避免再次产生同样的缺陷 相应地改进了未来软件系统的质量 这是质量保证的体现 测试应该集成为质量保证活动的一个组成部分 与开发标准 培训和缺陷分析并列 软件测试心理学 软件测试需要独立性测试机构的独立有利于关注开发过程中工作产品中可能存在的缺陷 可以避免开发人员 作者 的偏见独立并不等于完全代替开发人员 开发人员能有效的找到自己工作产品中存在的缺陷软件测试独立的优点独立的测试员可以做到没有偏见 可以发现一些其他不同的缺陷 一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设 软件测试独立的缺点与开发小组脱离 如果完全独立 开发人员可能失去对软件质量的责任感 独立的测试员可能是项目的瓶颈或者要为软件发布延时负责 软件测试独立的方式 软件测试独立的方式测试的设计由开发人员自己完成 测试由开发队伍的其他开发人员完成 测试独立于本项目的开发队伍 测试独立于本开发企业 来自于独立的第三方测试机构 软件测试与开发如何相处 合作 沟通 交流 中立 目标一致测试人员发现软件工作产品的缺陷某种程度上是对工作产品和其作者的批评 所以软件测试常常被看成一种消极的活动 尽管软件测试对软件开发的风险具有很强的规避作用 如果测试人员与分析 设计和代码开发人员能很好的沟通 那么他们对测试人员的不好感将避免 软件工作产品的缺陷信息有助于提高开发者的技能 也为开发过程节约成本和时间 降低软件开发风险 测试人员和测试管理者之间也应该具有好的沟通 通过规则的交流途径交流测试中的缺陷信息 进展情况和风险 如果测试人员把自己发现缺陷作为一个新闻来传播 那么会给沟通带来麻烦 软件质量保证 软件质量保证 SQA 的对象是过程 质量保证的重要工作通过预防 检查与改进来保证软件质量 QA采用 全面质量管理 和 过程改进 的原理开展质量保证工作 软件测试与软件质量保证的关系SQA侧重对流程中过程的管理与控制 是一项管理工作 侧重于流程和方法 软件质量保证的职能是向管理层提供正确的可视化的信息 从而促进与协助流程改进 SQA还充当测试工作的指导者和监督者 帮助软件测试建立质量标准 测试过程评审方法和测试流程 同时通过跟踪 审计和评审 及时发现软件测试过程中的问题 从而帮助改进测试或整个开发的流程等有了SQA 测试工作就可以被客观的检查与评价 同时也可以协助测试流程的改进 测试是对软件产品的检验 是一项技术性的工作 软件测试的对象是产品 测试人员要 执行 软件 对过程中的产物 开发文档和源代码进行走查 运行软件 以找出问题 报告缺陷 软件测试是寻找缺陷的策略 SQA是规避缺陷的策略 软件质量保证与软件测试的比较 软件测试的充分性 为什么考虑测试的充分性 测试需要给利益相关者提供足够的信息 帮助他们决定是否发布被测软件或系统 软件可以发布表示可以进入下一个开发过程 或将系统交付给用户 测试的特征测试是高风险的质量保证活动 测试是不能穷尽的在有限的预算 时间 资源下 尽可能多的发现和报告缺陷判断测试是否充分的考虑因素风险 包括技术风险 商业产品风险和项目的风险等 项目在时间和预算上的限制等 软件测试的目的 GrenfordJ Myers测试是程序的执行过程 目的在于发现错误一个好的测试用例在于能发现至今未发现的错误一个成功的测试是发现了至今未发现的错误的测试BillHetzel提出了测试目的不仅仅是为了发现软件缺陷与错误 而且也是对软件质量进行度量和评估 以提高软件的质量 当前业内普遍接受的测试目的以最少的人力 物力和时间找出软件中潜在的各种错误和缺陷 通过修正各种错误和缺陷提高软件质量 避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险 简而言之 软件测试的目的是降低软件风险 保证软件质量测试是以评价一个程序或者系统属性为目标的活动 测试是对软件质量的度量与评估 以验证软件的质量满足用户的需求的程度 为用户选择与接受软件提供有力的依据 通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷 以便进行软件过程改进 同时 通过对测试结果的分析整理 还可以修正软件开发规则 并为软件可靠性分析提供依据 软件测试的原则 所有的软件测试都应追溯到用户需求应当把 尽早地和不断地进行软件测试 作为软件测试者的座右铭完全测试是不可能的 测试需要适可而止测试只能证明软件存在错误而不能证明软件没有错误充分注意测试中的缺陷群集现象程序员应避免检查自己的程序 测试独立性 测试的 杀虫剂 效应 所有的软件测试都应追溯到用户需求 从根本上讲 判断软件现象是否是缺陷的依据是是否满足用户需求显性需求隐性需求软件的目的是使用户完成预定的任务 并满足用户的需求软件测试所揭示的缺陷和错误使软件达不到用户的目标 满足不了用户需求 尽早地和不断地进行软件测试 在软件或系统开发生命周期中 测试活动应该尽可能早的介入 并且应该将关注点放在已经定义的测试目标 testobjective 上早期发现和修改缺陷成本最小每个软件Build都应该被测试 而不是等到最后一个Build才进行测试经验数据示例 穷尽测试是不可能的 测试是有计划的 产品要发布 市场不允许无限期测试被测试软件复杂 需要测试的内容很多测试预算和资源有限 测试需要适可而止除了小型项目 进行完全 各种输入和前提条件的组合 的测试是不现实的 通过运用风险管理 Riskmanagement 和不同系统功能的测试优先级 来确定测试的关注点 从而替代穷尽测试 测试显示缺陷的存在 测试只能表明软件存在缺陷 不能说明软件不存在缺陷测试可以减少软件中存在缺陷的可能性 但即使测试没有发现任何缺陷 也不能证明软件或系统是完全正确的由于软件测试不能穷尽测试 因此 经过测试的软件仍然含有未知的缺陷 缺陷的群集现象 版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的如果发现某一程序模块似乎比其他程序模块有更多的错误倾向 则应当花费较多的时间和代价测试这个程序模块 测试的独立性 人为心理因素 人们认为揭露自己程序中的问题总不是一件愉快的事 不愿否认自己的工作由于思维定势 人们难于发现自己的错误程序员应该避免全部测试自己的程序和文档为达到测试目的 应由客观 公正 严格的独立的测试部门或者独立的第三方测试机构进行测试 测试的 杀虫剂 效应 同样的测试用例一遍一遍重复进行测试 最后将不再能够发现新的缺陷为了克服这种杀虫剂悖论 测试用例需要经常性的评审和修改需要不断增加新的不同的测试用例来测试软件或系统的不同部分 从而发现潜在的更多的缺陷重复测试 不间断测试 更新测试内容和测试用例 软件测试的基本过程 软件测试计划和控制测试分析和设计测试实施和执行退出测试的标准测试报告测试结束活动 开始 结束 测试计划 跟踪控制 分析与设计 实现与执行 评估与报告 完成测试 测试计划测试进度表 测试方法逻辑测试用例 测试规格说明物理测试用例测试环境 测试日志缺陷报告测试总结报告 软件测试计划和控制 定义 ANSI IEEE软件测试文档标准829 1983 将测试计划定义为 一个叙述了预定的测试活动的范围 途径 资源及进度安排的文档 它确认了测试项 被测特征 测试任务 人员安排 以及任何偶发事件的风险 作用借助软件测试计划 参与测试的项目成员 尤其是测试管理人员 可以明确测试任务和测试方法 保持测试实施过程的顺畅沟通 跟踪和控制测试进度 应对测试过程中的各种变更 内容指明测试范围 方法 资源 以及相应测试活动的时间进度安排表 包含测试目标 项目概述 组织形式 角色及职责 测试对象 测试通过和失败的标准 测试何时结束 度量的尺度如何 度量的评价标准等 测试挂起的标准及恢复的必要条件 测试任务的安排 应交付的测试工作产品 工作量估计等 特点一般开始于软件需求分析结束阶段 软件测试计划内容与实例 计划内容测试项目概述需要测试的功能不需要测试的功能测试策略测试中断与恢复的规定测试完成后需要提交的内容测试环境的设置测试人员的工作分配测试人员的能力与培训测试进度表测试风险计划实例简单的测试计划复杂测试计划附录A 测试计划模板 软件测试控制 利用事先定义的度量评估和分析测试结果监督和记录 测试进度测试的覆盖状况测试的结束条件是否偏离计划确定是否需要采取纠正措施确定是否需要更改原计划对测试计划的执行进行反馈 软件测试分析和设计 不同阶段的分析和设计依据不同在组件 单元 测试阶段分析的依据是详细设计规约在集成测试阶段分析的依据是概要设计规约在系统测试阶段分析的依据是需求分析规约在分析过程中规约不是惟一的依据 由于软件开发过程中的文档可能不是十分的完整 这就要求测试分析人员从其他方面进行分析作为补充 软件测试分析和设计 对测试依据 需求 结构 设计 接口 进行评审 分析 为对所有测试点设计测试用例做好准备以测试分析为基础并结合软件测试方法和技术进行测试设计从产品原型分析角度出发 与当事人交流和沟通 开发者和用户等 对需求和测试对象的可测试性进行评价在分析测试对象 规约说明 测试对象间的关系和结构的基础上 确定测试条件 例如验证需求 以及所需的测试数据使用测试策略内规定的测试方法设计逻辑测试用例 测试用例的架构 测试用例的设计应该从逻辑测试用例到实际测试用例的设计过程 设计用例的多少应该充分考虑测试子系统或模块在整个系统中的重要性 用例的设计同时要考虑用例执行应该具备的前提条件设计测试环境 包括必要的基本设施和工具测试设计包括测试用例设计 测试工具设计或选择 测试脚本设计 测试缺陷管理工具设计或选择 测试管理模板设计测试用例设计是测试设计的重要内容 黑盒 白盒 灰盒测试用例设计从软件的流程图 功能点 状态图 use case图等方面进行测试用例的设计细化测试进度表 测试的实现与执行 测试的实现 Implementation 从测试条件具体到可执行的测试用例 即从逻辑测试用例到实际的测试用例 以及必要的测试件 文档和工具 借助于测试准则 确定测试期望结果根据风险判定测试用例的优先级生成测试数据测试对象的输入值和状态值以及期望值 或在运行有关的测试用例后的期望结果建立和检查测试环境 以确保配置的正确性构建测试台 Testbed 和编写测试自动化脚本组合成测试套件 Testsuites 测试序列 多个单个测试用例形成的逻辑集 并完成测试规程 Testprocedure 测试套件是用于被测组件 系统的一组测试用例 在这些测试用例中 一个测试用例的后置条件 Postcondition 常作为下一个测试的前置条件 Precondition 测试的实施与执行 测试的准备测试环境的准备 软件 硬件 网络 测试对象是否按照规定构建并准备完毕 测试程序 测试脚本是否准备完毕缺陷管理系统和测试文档是否准备完毕测试辅助件的准备 测试驱动器和测试桩 测试模拟器及测试工具等 测试的实施与执行 测试的执行测试某个软件组合或系统并产生实际结果的过程按照测试计划和测试规约说明执行手动测试的测试用例和自动测试的测试用例比较实际的和期望的结构 分析期望和实际结果偏差的原因 测试对象和测试件的错误等 提交事件 Incidents 即在测试过程中出现的 并且在此后还需要检查或者关注的事件记录测试结果 测试日期 时间 测试人员 输入的测试数据和期望值 测试对象的ID标识 版本号 测试工具和测试方法 测试结果和后续动作包括测试缺陷报告和修改测试用例 如果可能给出错误的原因 记录特殊情况 如有必要 补充新的测试用例执行确认测试和回归测试 用于确认错误更改是否有效 或者执行已经更改的测试用例测试日志即关于测试执行的按时间顺序的详细记录 测试退出的标准 测试退出的标准计划中的测试用例是否执行完毕是否达到功能 语句等计划的覆盖指标继续测试发现缺陷的数量减少低于度量标准等满足测试计划中的测试退出标准测试评估对每个测试阶段都要进行评估是否达到测试退出的标准对测试记录评估 判断测试是否达到了测试计划规定的测试退出准则达到测试退出准则后 才进入下一个测试阶段评价是否需要继续执行进一步的测试或者需要更改已经定义好的测试退出准则 例如 准则无法执行或者资源有限 费用 时间和人员 无法达到每个测试阶段结束后提供对被测系统和测试过程当前状况的评价给相关决策人员提交测试报告 包括测试活动和测试结果的文档 在规定的测试退出准则下的测试运行的评估 测试结束活动 测试结束的条件当一个软件产品正式上线应用后当开发 或测试 达到一个里程碑 Milestone 一个维护版本结束时测试结束活动的内容检查是否所有计划的交付物都产生并交付了 或者产生交付了哪些事件报告的完成 缺陷报告 偏差报告 为仍然存在的错误 偏差提供变更需求系统验收的文档测试结果分析 测试总结 测试信息和数据备份 测试规约说明书 数据 测试日志等 对测试发现的缺陷进行统计分类并分析原因制定的测试计划和实际的计划执行的差距并分析原因 哪些事件或风险没预料到 总结好的经验等分析每个测试活动的计划和实施之间的偏差 并判断原因统计测试结果与测试开销的关系软件 硬件 文档和邮件的备份 销毁和退还 总结 失效是缺陷在执行测试软件时的外部反映 当缺陷被执行时产生软件失效软件测试独立有4种方式软件测试和软件开发是合作和交流的关系软件测试关注的是产品 软件质量保证关注的是过程实施软件测试需要理解和遵守 条基本原则 追溯到用户需求尽早和不间断测试不可能穷尽测试测试不能表明软件没有缺陷缺陷的群集现象开发人员避免检查自己的程序避免杀虫剂效应 总结 软件测试的内容计划和控制分析和设计实施和执行退出测试的标准测试报告测试结束活动 练习作业 什么是软件测试 软件测试的目的是什么 软件测试的内容有哪些 什么是软件缺陷 软件失效 软件缺陷和软件失效之间有什么关系 引起软件失效的因素有哪些 软件为什么会存在缺陷 软件测试在软件开发 维护和使用中扮演什么角色 软件测试独立有什么好处 软件测试独立有哪些形式 软件测试和软件开发人员应该如何相处 什么是软件质量 什么是软件质量保证 练习作业 软件测试和软件质量保证之间有什么相同和不同 确定软件测试的充分性的因素有哪些 软件测试的一般规则有哪些 软件测试的基本过程包括哪些内容 在软件测试的基本过程内 各个过程包括哪些内容 三 软件测试与软件生命周期 CSTQB软件测试基础级培训教程 北京昱达环球科技有限公司版权所有 目录 软件开发模型软件测试级别软件测试类型维护性测试 软件开发模型 软件开发模型简介 软件生命周期软件需求 分析 设计 实现 测试 部署Deploy Release 维护和退出的过程 称为 软件生命周期 SoftwareLifeCycle 概述软件开发模型是指软件开发所依据的方式和过程从事软件测试为什么要熟悉开发模型 测试不是孤立存在的 测试活动与开发活动是息息相关的每个开发活动都有相对应的测试活动不同的开发生命周期模型需要不同的测试方法每个测试级别都有其特有的测试目标对于每个测试级别 需要在相应的开发活动过程中进行相应的测试分析和设计在开发生命周期中 测试人员在文档初稿阶段就应该参与文档的评审如何选择开发模型 根据项目的内容根据产品的特征 软件开发V模型图 验证与确认 V V 验证Verification翻译为 验证 也可以译为 检验 即验证或检验软件是否已正确地实现了产品规格书所定义的系统功能和特性 验证 强调的是 规定规格要求 验证过程提供证据表明 软件相关产品与所有生命周期活动 需求分析 设计 编程 测试等 的要求 如正确性 完整性 一致性 准确性等 相一致 验证是否满足生命周期过程中的标准 实践和约定 验证为判断每一个生命周期活动是否已经完成 以及是否可以启动其他生命周期活动建立一个新的基准 可以用英文描述 Arewebuildingtheproductright 是否正确地构造了软件 即是否正确地做事 验证开发过程是否遵守已定义好的内容 测试结果要和相应的开发需求定义的结果比较而进行功能准确性测试软件生命周期中的每一个阶段的成果是否满足上一个阶段所设定的目标 验证与确认 V V 确认Validation翻译为 确认 但更准确地翻译 应该是 有效性确认 保证所生产的软件可追溯到用户需求的一系列活动 确认过程提供证据 表明软件是否满足客户需求 指分配给软件的系统需求 并解决了相应问题 确认 检验软件是否满足用户需求 保证软件的功能和性能符合用户的实际需要 可以用英文描述 Arewebuildingtherightproduct 是否构造了正确的软件 即是否正在做用户真正所需要的事 被测试内容的正确性及完整性与相应的用户需求进行比较 即针对测试设计内容本身的准确性进行确认问题与思考既然软件测试的目标是满足用户的要求 而测试中的 确认 方法是检验软件是否满足用户需求 那么为什么还要使用 验证 呢 V模型分析 概述最早由PualRook于80年代末提出 其左右分支形成了V字型 因此称作V模型 含义V模型指出软件测试不仅仅是软件开发的一个独立阶段 而应贯穿于整个软件生命周期中V模型中的右分支列出的软件测试任务和相应的左分支列出的软件开发任务在整个软件项目中有着同等的重要性该模型描述了基本的开发过程和测试行为 非常明确地标明了测试过程中存在的不同级别 并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 V模型的缺点仅仅把测试过程作为在需求分析 系统功能设计 系统架构设计及编码之后的一个阶段容易使人理解为测试是软件开发的最后的一个阶段 主要是针对程序进行测试寻找错误 而需求分析阶段的隐藏的问题一直到后期的系统测试和验收测试才被发现 说明在测试实践中 V模型中的各个开发及测试阶段可往往会根据具体情况有所增减甚至组合或重新排列 W模型图 W模型分析 概述Evolutif公司在1999年提出W模型由两个V字型模型组成 分别代表测试与开发过程表示了测试与开发的并行关系含义W模型体现了 尽早地和不断地进行软件测试 的原则W模型有利于尽早地全面的发现问题 例如 需求分析完成后 测试人员就应该参与到对需求的验证和确认活动中 以尽早地找出缺陷所在对需求的测试也有利于及时了解项目难度和测试风险 及早制定应对措施 这将显著减少总体测试时间 加快项目进度模型缺点需求 设计 编码等活动被视为串行的 测试和开发活动也保持着一种线性的前后关系 上一阶段完全结束 才可正式开始下一个阶段工作对于软件开发复杂多变的情况 W模型并不能完全解除测试管理面临的困惑 迭代 增量模型图 原型开发模型快速开发模型RUP RationalUnifiedProcess 统一软件开发过程AgileDevelopment敏捷开发 迭代 增量模型分析 在每次迭代过程中 对迭代产生的系统可能需要在不同的测试级别上进行测试 通过将增量模块加入到以前开发的模块中 形成一个逐渐增大的系统 这个系统同样需要进行测试 在完成第一次迭代后 对所有的迭代进行回归测试会变得越来越重要 验证和确认可以在每个增量模块中进行 H模型图 H模型分析 概述将软件测试看着一个独立的流程贯穿于软件产品的开发周期 当某个测试条件就绪时 软件测试工作就可以开始含义将测试活动完全独立出来 形成了一个完全独立的流程 将测试准备活动和测试执行活动清晰地体现出来软件测试是一个独立的流程 贯穿产品整个生命周期 与其他流程并发地进行模型指出软件测试要尽早准备 尽早执行不同的测试活动可以是按照某个次序先后进行的 但也可能是反复的 只要某个测试达到准备就绪点 测试执行活动就可以开展 其它模型 X模型提出针对单独的程序片段进行相互分离的编码和测试 此后通过频繁的交接 通过集成最终合成为可执行的程序前置测试模型体现了开发与测试的结合 要求对每一个交付内容进行测试 软件测试级别 测试级别概述 软件开发的不同阶段对应不同级别 Level 的测试组件测试 单元测试 在软件编码结束后 对编写的每一个程序模块进行测试集成测试 组装测试 联合测试 在模块集成后 对集成在一起的模块组件 有时也可称为 部件 进行测试系统测试将整个程序模块集成为软件系统安装在运行环境下 对于硬件 网络 操作系统及支撑平台构成的整体系统进行测试验收测试 交付测试 确认测试 在上述测试后 需要检测与证实软件是否满足软件需求说明书中规定的要求 良好的测试所具有的特征 特征每个开发活动都有相对应的测试活动每个测试级别都有其特有的测试目标对于每个测试级别 需要在相应的开发活动过程中进行相应的测试分析和设计在开发生命周期中 测试员在文档初稿阶段就应该参与文档的评审注意 根据项目的特征或系统的架构 可以对测试级别进行合并或重新进行组合 比如 对于商业现货软件 COTS 产品集成到某个系统 购买者可以在系统级别 例如 与基础设施集成 与其他系统的集成或与系统应用的集成 进行集成测试和验收测试 功能的和 或非功能的测试 用户和 或运行测试等 各个测试级别需要明确的内容 测试的总体目标测试用例设计需要参考的工作产品 即测试的依据 测试的对象 即测试什么 发现的典型缺陷和失效对测试用具的需求测试工具的支持专门的方法和职责等注意 如果某些数据属于系统的一部分 那么在测试计划时就应当考虑是否对系统配置数据进行测试 组件测试概述 概述组件测试是对软件基本组成单元进行的测试 一般在代码完成后由开发人员完成 测试人员辅助 组件测试的目的是检查代码是否符合设计和规范 测试依据组件需求说明详细设计文档代码测试对象组件程序数据转换 移植程序 组件测试的特征和测试内容 特征组件测试可能包括功能测试和特定的非功能特征测试 比如资源行为测试 如内存泄漏 或健壮性测试和结构测试 比如分支覆盖 根据工作产品 例如组件规格说明 软件设计或数据模型等设计测试用例 测试内容模块接口测试检查局部数据结构能否保持完整性模块边界条件测试模块执行路径测试检查模块内部错误处理是否有效 组件测试的测试方法 测试框架和调试工具通过开发环境的支持 比如组件测试框架或调试工具 debuggingtool 组件测试会深入到代码中 而且实际上设计代码的开发人员通常也会参与其中 在这种情况下 一旦发现缺陷 就可以立即进行修改 而不需要正式的缺陷管理过程 测试优先的方法或测试驱动开发在编写代码之前就完成编写和自动化测试用例这是高度迭代的方法 并且取决于如下的循环周期 测试用例的开发构建和集成小块的代码执行组件测试修正任何问题并反复循环 直到它们全部通过测试 理解驱动程序与桩 includevoidmain void inta 1 b 2 c c fun1 a b intfun1 intx inty returnx y 问题 假设这两个函数是两个人分别开发的 二者开发进度不同 则如何测试 驱动模块和桩驱动模块 driver 对底层或子层模块进行测试所编写的调用这些模块的程序 桩模块 stub 对顶层或上层模块进行测试时所编写的替代下层模块的程序 集成测试概述 概述通过单元测试的多个模块组合成更大的模块或子系统或产品 然后进行测试集成测试是对组件之间的接口进行测试 以及测试一个系统内不同部分的相互作用 比如操作系统 文件系统 硬件或系统之间的接口 测试依据软件和系统设计文档系统架构工作流用例测试对象子系统数据库实现基础设施接口 集成测试的级别和内容 集成级别集成测试 可以应用多种集成级别 也可以根据不同的测试对象规模采用不同的级别 组件集成测试对不同的软件组件之间的相互作用进行测试 一般在组件测试之后进行 系统集成测试对不同系统或软硬件之间的相互作用进行测试 一般在系统测试之后进行 内容各单元的接口是否吻合代码是否符合规定的标准界面标准是否统一等 集成的策略和方式 策略根据系统结构 例如自顶向下或自底向上 功能任务集 事务处理顺序或系统和组件的其他方面等制定集成测试策略 为了能方便快速地隔离故障和定位缺陷 集成程度应该逐步增加 而不是采用 大爆炸 式的集成 方式非渐增式测试模式 先分别测试每个模块 再把所有模块按设计要求一次全部组装起来所要的系统 然后进行整体测试 非渐增式集成测试是不科学的集成测试方式 渐增式测试模式 把下一个要测试的模块同已经测试好的模块结合起来进行测试 测试完以后再把下一个模块结合进行测试自顶向下集成 Top Bottom 自顶向下集成时 前期完成的模块将是后期模块的驱动程序 Driver 自底向上集成 前期完成的模块将是后期模块的桩程序 Stub 系统测试概述 概述将经过确认测试的软件 与计算机硬件 外设 支持软件等一起 在实际运行环境下测试 系统测试关注的是在开发项目或程序中定义的一个完整的系统 产品的行为 目的充分运行系统 验证系统各部件是否能正常工作 符合软件需求规格说明 测试依据系统和软件需求规格说明用例功能规格说明风险分析报告典型测试对象系统 用户手册和操作手册系统配置 系统测试类型与方法 类型功能测试非功能测试 压力测试 性能测试 容量测试用户界面测试兼容性测试国际化测试 本地化测试测试方法基于需求的测试从需求导出测试目标和测试条件 设计测试用例 测试检查功能或者非功能特性 可靠性和可用性 基于业务流程的测试从业务流程的说明和对业务流程的理解导出和选择测试用例的测试方法 基于用例 UseCases 的测试黑盒测试设计方法 根据实际的场景设计测试用例 进行测试 基于风险评估的测试说明 在系统测试中 测试环境应该尽量和最终的目标或生产环境相一致 从而减少不能发现和环境相关的失效的风险 系统测试通常由独立的测试团队执行 验收测试概述 概述技术测试的最后一个阶段 在软件产品完成了系统测试之后 产品发布之前所进行的软件测试活动验收测试通常是由使用系统的用户或客户来进行 同时系统的其他利益相关者也可能参与其中 目的验收测试的目的是建立对系统 系统的某部分或特定的系统非功能特征建立信心 验证系统是否达到了用户需求规格说明书 可能包括项目或产品验收准则 中的要求 保证系统或软件产品最终被用户接受发现缺陷不是验收测试的主要目标 测试依据用户需求系统需求用例业务流程风险分析报告 验收测试的对象和内容 对象基于完全集成系统的业务流程操作与维护流程用户处理过程结构报告内容安装测试功能测试可靠性测试安全性测试性能测试易用性测试可移植性测试可维护性测试文档测试 验收测试的特点 验收测试不一定是最后级别的测试 可能会在进行某个系统验收测试之后 进行大规模的系统集成测试 验收测试可以在多个测试级别上进行商业现货软件 COTS 产品可以在安装或集成时进行验收测试 组件的可用性验收测试可以在组件测试中进行 增加新功能的验收测试可以在系统测试之前进行 验收测试的形式 形式 5种类型 用户验收测试操作验收测试系统操作验收测试由系统管理员来进行 测试内容主要包括 系统备份 恢复测试 灾难恢复测试 用户管理测试 维护任务测试 数据加载和移植活动 安全漏洞阶段性检查 合同和法规性验收测试合同验收测试根据合同中规定的生产客户定制软件的验收准则 对软件进行测试 应该在合同拟定时定义验收准则 法规性验收测试根据必须要遵守的法律法规来进行测试 比如政府 法律和安全方面的法律法规 验收测试的形式 Alphatesting 测试 在软件产品正式商业销售之前 市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到关于软件的反馈信息 Alpha测试通常在开发组织现场进行 但测试并非由开发团队执行 Betatesting 测试 Beta测试或实地测试 是在客户或潜在客户现场进行并由他们执行 概念辨析Alphatesting 测试 用户在开发环境下进行的测试 也可以是公司内部的用户在模拟实际操作环境下进行的受控测试 Alpha测试不能由程序员或测试员完成 Betatesting 测试 软件的多个用户在一个或多个用户的实际使用环境下进行的测试 开发者通常不在测试现场 Beta测试不能由程序员或测试员完成 软件测试类型 测试类型概述 软件类型众多 不同的分类标准对应不同的测试类型分类 功能性测试软件产品特性测试 非功能性测试 软件结构性测试变更相关的测试确认 验证测试 再测试 回归测试功能性测试和结构性测试可以应用于任何测试级别 功能性测试概述 概述功能性测试是基于软件产品功能和特征 以及专门的系统之间的交互进行的测试可以在各个测试级别进行 既可以用于组件级别 也可以用于集成和系统测试级别功能性测试不考虑程序的具体执行路径 仅关注功能是否实现功能测试的特点通常采用黑盒测试 Black boxTesting 又称为功能测试或数据驱动测试 是把测试对象看作一个黑盒子 利用黑盒测试法进行动态测试时 只需要测试软件产品外部表现的功能 不需考虑软件产品的内部结构和处理过程 功能性测试的错误类型 黑盒测试通常可以发现的错误类型功能错误或遗漏 界面错误 数据结构或外部数据库访问错误 性能错误 初始化和终止错误 注意 安全性测试就是功能测试的一种对安全性相关的功能 比如防火墙 进行测试 从而检测系统和数据是否能抵御外部恶意的威胁 如病毒等 互操作性测试是另一种功能性测试评估软件产品与其他一个或多个组件或系统交互的能力 非功能性测试 概述为了测量系统和软件的运行特性 需要进行的测试 可以在任何测试级别上进行 基于产品的性能 负载 可用性 交互性 可维护性 可靠性及可移植性等方面的测试 包括测试产品是否遵从指定的标准 规范和约束 以及操作界面的具体细节和构造上的限制 通过测试 可以在不同尺度上来量化软件和系统的特征 比如进行性能测试来检验系统和软件的反应时间 类型非功能测试包括但不限于 性能测试 负载测试 压力测试 易用性测试 可维护性测试 兼容性 可靠性测试和可移植性测试 结构测试概述 概述结构测试也称白盒测试 White boxTesting 又称逻辑驱动测试 把测试对象看作一个打开的盒子 利用白盒测试法进行动态测试时 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行 按照程序内部的结构测试程序 检验程序中的每条通路是否都能按预定要求工作 而不顾它的功能 最好在进行基于规格说明的测试之后使用 以便通过评估结构类型的覆盖 测量测试的完整性 覆盖覆盖 coverage 是指通过测试套件检验的结构程度 以覆盖项 item 的百分比来表示 假如覆盖率不是100 可能需要设计更多的测试用例 来测试被遗漏的项 从而提高测试的覆盖 白盒测试的主要方法逻辑覆盖 语句覆盖 判定覆盖 条件覆盖 判定 条件覆盖 条件组合覆盖和路径覆盖基本路径测试 结构性测试的特点 特点可以在任何测试级别上进行结构测试 在所有的测试级别 特别是在组件测试和组件集成测试中 可以利用工具来测量单元代码的覆盖 比如语句覆盖 statementcoverage 和判定覆盖 decisioncoverage 结构测试可以基于系统的结构 比如调用层次结构 结构测试方法也可以运用到系统 系统集成或验收测试级别 比如业务模型或菜单结构 白盒测试 法全面了解程序内部逻辑结构 对所有逻辑路径进行测试 白盒测试 法是穷举路径测试 在使用这一方案时 测试者必须检查程序的内部结构 从检查程序的逻辑着手 得出测试数据 结构性测试的缺点 白盒测试的缺点穷举路径测试不能查出程序违反了设计规范 即程序本身是个错误的程序穷举路径测试不可能查出程序中因遗漏路径而出错穷举路径测试可能发现不了一些与数据相关的错误经验与提示白盒测试和黑盒测试互相配合不同阶段采用不同的测试方法测试人员辅助程序员执行白盒测试设计白盒测试用例可能耗费很多时间大部分软件缺陷是黑盒测试方法发现的 变更相关的测试概述 验证测试 再测试 当发现和修改了一个软件缺陷后 需要重新进行测试以确定已经成功的修改了原来的缺陷 这种方法称之为确认测试 回归测试 RegressionTesting 对已被测过的程序实体在修改缺陷后进行的重复测试 以此来检验在这些变更后是否有新的缺陷引入系统 当软件发生变更或者使用软件的环境发生变化时 需要进行回归测试 回归测试的范围可以根据软件修改引起的风险程度来决定 假如测试用例是用来进行确认测试和辅助回归测试的 则它们应该是可以重复进行执行 回归测试可以在所有的测试级别上进行 同时适用于功能测试 非功能测试和基于结构的测试 回归测试套件一般都会执行多次 而且没有什么变化和修改通常变化很少 因此回归测试强烈推荐自动化执行 新功能测试 变更相关的测试 回归测试用例能够测试软件的所有功能的代表性测试用例专门针对可能会被修改影响的软件功能的附加测试针对修改过的软件成分的测试经验与提示回归测试应当设计为只包括那些涉及在主要的软件功能中出现的一个或多个错误类的那些测试各测试阶段发生的修改一定要在本测试阶段内完成回归 以免将错误遗留到下一测试阶段 回归测试期间应对该软件版本冻结 将回归测试发现的问题集中修改 集中执行回归测试 各种测试级别与测试方法对比分析 不同测试类型之间的关系 软件测试 测试级别 运行软件 查看代码 测试类型 组件测试 集成测试 系统测试 验收测试 动态测试 静态测试 黑盒测试 白盒测试 功能性测试 非功能性测试 结构性测试 维护测试 变更相关的测试 确认测试 再测试 回归测试 维护性测试 维护性测试概述 什么是维护性测试软件发布之后 系统通常要运行数年甚至数十年 在软件生命周期中的维护阶段 由于业务等方面的变化而进行修改 拓展 移植及部分软件被淘汰等原因所进行的测试称为维护性测试 维护测试是在一个运行的系统上进行 且一旦对软件或系统进行修改 移植或系统被淘汰时 就需要进行维护测试 修改可以是计划中的功能增强 例如 根据版本发布的计划 修正和应急变更 环境的变化 比如计划中的操作系统或数据库升级 为商业现货软件计划升级或由于新发现或暴露的操作系统漏洞而打的补丁等 维护性测试可以理解为软件发布后的一种变更测试维护性测试和可维护性测试的区别维护性测试 由于维护开发 例如修改 拓展 移植及部分软件的退役等都只是基于原系统的改动 并未从根本上改变系统 针对维护开发而进行的测试 完全可以遵从对原系统开发过程中测试的流程 如组件测试 集成测试 系统测试和验收测试 可维护性测试是仅针对系统是否易于维护而开展的测试 维护性测试的特点 维护性测试的特点维护测试根据变更情况的不同 可以在某一测试级别或所有测试级别和测试类型上进行 维护测试的范围取决于变更后是否有产生新缺陷的风险 系统的规模和变更的大小 维护测试通常始于客户对系统变化或发布下一个版本需求的确认 软件测试管理人员也会以这些确认文档为基础设计维护测试计划 为移植 如从一个平台移植到另外一个平台 而进行的维护测试应该包括新环境的运行测试 operationaltesting 以及对变更以后的软件的运行测试 当数据从另一个应用程序移植到正在维护的系统时 需要移植测试 转换测试 为系统退役而进行的维护测试应该包括数据移植测试 或当数据要长时间的保存时还须存档测试 经验与提示维护测试应该着重测试系统的变化和这些变化是否影响了原始系统的已有功能及性能 后者通常利用回归测试来实现 除了对已变更的部分进行测试外 维护测试还包括对系统没有发生变更的其他部分进行大范围的回归测试 确定变更如何影响现有系统的过程 称之为影响分析 它可以帮助决定实施回归测试的广度和深度 如果规格说明遗失 过时或测试人员没有具备领域知识 进行维护测试将是一件困难的事情 静态测试与动态测试 静态测试 StaticTesting 简介不实际运行被测试软件 只是静态地检查程序代码 界面或文档中可能存在的缺陷的过程 对于代码测试 测试代码是否符合相应的规范和标准对于界面测试 测试程序的实际界面和需求规格说明 规约 是否一致对于文档测试 测试用户手册和联机帮助是否满足客户的实际需求静态测试中检查代码规范的工具某些白盒测试工具包括检查代码规范的功能Telelogic的LogiScope可以检查C C Java的编码是否规范Parasoft的C Test可以检查C C 的编码规范性 动态测试 动态测试 DynamicTesting 简介实际运行被测试软件 输入相应的测试数据 检查实际输出结果和预期结果是否符合的过程 动态测试 静态测试 黑盒测试与白盒测试之间的关系黑盒测试有可能是动态测试 也可能是静态测试 不运行程序 只查看界面 白盒测试有可能是动态测试 也可能是静态测试动态测试有可能是黑盒测试 也可能是白盒测试 运行程序 并分析代码结构 静态测试有可能是黑盒测试 不运行程序 只查看界面 也可能是白盒测试这些测试类型只是分类角度不同 同一个测试 既有可能属于黑盒测试 也有可能属于动态测试 既有可能属于静态测试 也有可能属于白盒测试 静态测试与动态测试的比较 静态测试和动态测试的区别 是否执行被测试软件动态测试和静态测试这两种手段都可以提供信息来改进被测试软件系统的质量 以及改善开发和测试的过程 功过手工检查 评审 或自动化分析 静态分析 的方式对文档进行检查直接发现缺陷 引起失效的原因 发现的缺陷类型 与标准之间的偏差 需求内的错误 设计的错误 接口规格说明错误等 通过执行被测软件对软件进行检查发现失效 缺陷的外部表现 发现的缺陷类型 软件运行过程中与规格说明 用户需求之间的偏差 静态测试 动态测试