软件测试理论基础

2018 软件测试理论基础 汇报人 汇报时间 2018年1月 一 绪论 1 测试用例及测试用例的设计 3 软件质量的保证和软件测试 2 软件测试的方法 4 大量软件的测试策略 回顾 什么是软件测试软件测试的正反两面性验证软件发现缺陷V V软件测试和开发的关系TDD 1 测试用例的引进及其测试用例的使用 2 1测试用例及测试用例的设计 2 测试用例的规范要求 3 测试用例的模板 第2章软件测试的基本概念 软件测试计划试用例的引进 软件测试工作的组织与管理 制定测试策略 测试计划 确认所采用的测试方法与规范 控制测试进度 管理测试资源 测试工作的实施 编制符合标准的测试文档 搭建测试环境 开发测试脚本 与开发组织协作实现各阶段的测试活动 测试工作流程 测试计划内容 目标和范围项目估算风险计划进度安排资源配置跟踪和控制机制 测试用例的引进 测试用例 TestCase 是为某个特殊目标而编制的一组测试输入 执行条件以及预期结果 以便测试某个程序路径或核实是否满足某个特定需求 测试用例 TestCase 是将软件测试的行为活动做一科学化的组织归纳 目的是能够将软件测试的行为转化成可管理的模式 同时测试用例也是将测试具体量化的方法之一 不同类别的软件 测试用例是不同的 不同于诸如系统 工具 控制 游戏软件 管理软件的用户需求更加不同的趋势 测试用例的规范要求 一个好的用例的表述要点 即用例中应当包含的信息一个优秀的测试用例 应该包含以下信息 1 软件或项目的名称2 软件或项目的版本 内部版本号 3 功能模块名4 测试用例的简单描述 即该用例执行的目的或方法5 测试用例的参考信息 便于跟踪和参考 6 本测试用例与其他测试用例间的依赖关系7 本用例的前置条件 即执行本用例必须要满足的条件 如对数据库的访问权限8 用例的编号 ID 如可以是软件名称简写 功能块简写 NO 9 步骤号 操作步骤描述 测试数据描述10 预期结果 这是最重要的 和实际结果 如果有BUG管理工具 这条可以省略 11 开发人员 必须有 和测试人员 可有可无 12 测试执行日期 测试用例的模板 测试用例的优点 测试用例是测试人员在测试过程中的重要参考依据测试用例将有助于节约测试时间 提高测试效率 良好的测试用例不断地被重复使用 使得测试过程事半功倍测试用例是一个知识积累的过程 软件测试的方法 不同的分类 按测试的对象或范围分类 如单元测试 文档测试 系统测试等 按测试目的分类 如功能测试 回归测试 性能测试 可靠性测试 安全性测试和兼容性测试等根据测试过程中被测软件是否被执行 分为静态测试和动态测试根据是否针对系统的内部结构和具体实现算法来完成测试 可分为白盒测试和黑盒测试 静态测试和动态测试 静态测试和动态测试 将需求和设计的评审纳入测试的范畴 可看作是广义测试静态测试包括对软件产品的需求和设计规格说明书的评审 对程序代码的复审等静态分析的查错和分析功能是其他方法所不能替代的 可以采用人工检测和计算机辅助静态分析手段进行检测 但越来越多地采用工具进行自动化分析动态测试是通过真正运行程序发现错误 通过观察代码运行过程 来获取系统信息 对系统行为进行验证 产品评审 通过软件评审 可以更早地发现需求工程 软件设计等各个方面的问题 大大减少大量的后期返工 将质量成本从昂贵的后期返工转化为前期的缺陷发现 评审是对软件元素或者项目状态的一种评估手段 以确定其是否与计划的结果保持一致 并使其得到改进 检验工作产品是否正确地满足了以往工作产品中建立的规范 评审的形式和方法 互为评审 Peerreview 轮查 Pass round 走查 walk through 会议评审 Inspection 评审分类 管理评审技术评审文档评审流程评审 需求和设计审查 测试人员参与产品需求分析和系统设计 认真阅读有关文档 真正理解客户的需求和技术上的设计 检查需求说明书对产品描述的准确性 一致性等 检查系统设计的合理性和可测试性等 静态分析 人工检测 人工检测偏重于编码风格 质量的检验 对设计 代码进行分析 有效地发现逻辑设计和编码错误 计算机辅助静态分析 利用静态分析工具对被测程序进行特性分析 从程序中提取一些信息 以便检查程序逻辑的各种缺陷和可疑的程序构造 验证和确认 Verification Arewebuildingtheproductright 是否正确地构造了软件 即是否正确地做事 验证开发过程是否遵守已定义好的内容 验证产品满足规格设计说明书的一致性Validation Arewebuildingtherightproduct 是否构造了正是用户所需要的软件 即是否正在做正确的事 验证产品所实现的功能是否满足用户的需求 主动测试和被动测试 主动测试方法 测试人员主动向被测试对象发送请求 或借助数据 事件驱动被测试对象的行为 从而验证被测试对象的反应或输出结果被动测试方法 测试人员不干预产品的运行 而是被动地监控产品在实际环境中运行 通过一定的被动机制来获得系统运行的数据 包括输入 输出数据 黑盒测试方法和白盒测试 功能测试数据驱动测试 结构测试逻辑驱动测试 黑盒测试方法和白盒测试 一个微软测试工程师的一天 产品编译必须在此之前完成每日凌晨3时 测试编译自动开始如果测试编译成功 BVT测试自动开始测试工程师每早来上班 先检查TestBuild与BVT结果的email如果有BVT错误 在第一时间里分析原因 隔离错误代码并汇报Pri0Bug 0级缺陷 开发团队对于Pri0Bug应当于当日之内修改完毕测试工程师接着用ProductStudio检查Bug情况 验证分配给自己的Bug已修改合格 一个微软测试工程师的一天 续 关闭Bug并增加针对此Bug的RegressionTest验证最近的LabRun结果如果其中有新的错误 隔离并汇报新Bug开发新的测试Spec与新的测试代码使用个人PrivateRun来验证新开发的测试程序使用个人PrivateRun来验证开发伙伴新开发的产品程序没有重大错误改进与提高自动化测试系统的功能参与Spec TestSpecReview会议 做测试同伴测试代码Review UE帮助文件Review 回答内外Newsgroup的问题 软件缺陷的定义 Anyproblem disfigurement limitationinproductdesign developmentFeatureorfunctioncan tworkUnreasonabledesignPartlyrealizationinfunctionDataerrorRunerrorLimitationinfeaturesDifferencebetweenactualresultsandexpectedresultsUnfriendlyUI LowperformanceOthers 任何程序 系统中的问题 和产品设计书的不一致性 不能满足用户的需求 软件缺陷的定义 缺点 defect 偏差 variance 谬误 fault 失败 failure 问题 problem 矛盾 inconsistency 错误 error 毛病 incident 异常 anomy 软件缺陷 IEEE 1983 729软件缺陷一个标准的定义 从产品内部看 软件缺陷是软件产品开发或维护过程中所存在的错误 毛病等各种问题 从外部看 软件缺陷是系统所需要实现的某种功能的失效或违背 ISO29119 1 aflawinacomponentorsystemthatcancauseittofailtoperformitsrequiredfunction 2 anyconditionthatdeviatesfromexpectationbasedonrequirementsspecifications designdocuments NOTEDefectsmaybefoundduring butnotlimitedto reviewing testing analysis compilation oruseofsoftwareproductsorapplicabledocumentation 软件缺陷 功能 特性没有实现或部分实现设计不合理 存在缺陷实际结果和预期结果不一致运行出错 包括运行中断 系统崩溃 界面混乱数据结果不正确 精度不够用户不能接受的其他问题 如存取时间过长 界面不美观 软件缺陷的产生 技术问题算法错误 语法错误 计算和精度问题 接口参数传递不匹配团队工作沟通不充分 误解软件本身文档错误 用户使用场合 userscenario 时间上不协调 或不一致性所带来的问题系统的自我恢复或数据的异地备份 灾难性恢复等问题 软件缺陷的构成 在真正的程序测试之前 通过审查 评审会可以发现更多的缺陷 规格说明书的缺陷会在需求分析审查 设计 编码 测试等过程中会逐步发现 而不能在需求分析一个阶段发现 缺陷成本 什么是质量 软件质量的内涵 IEEE 质量是系统 部件或过程满足明确需求客户或用户需要或期望的程度不同软件质量 软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和 ISO8492 软件质量 软件产品满足使用要求的程度 软件质量的内涵 为了能够在产品发布前 对产品质量能够做出比较准确的判断 需要清楚质量的属性 这就需要建立质量模型产品质量质量模型 McCall模型 Boehm模型 ISO9126模型过程质量 软件能力成熟度模型CMM CapabilityMaturityModel 国际标准过程模型ISO9000软件过程改进和能力决断SPICE SoftwareProcessImprovementandCapabilitydEtermination 在商业过程中有关的质量内容 培训 成品制作 宣传 发布日起 客户 风险 成本 业务等 产品质量的标准 功能性Functionality 可用性Usability 可靠性Reliability 性能Performance 容量Capacity 可伸缩性Scalability 可维护性Servicemanageability 兼容性Compatibility 可扩展性Extensibility 非功能特性 软件质量特征 ISO9126 功能 与一组功能及其指定性质有关的一组属性 这里的功能是满足明确或隐含的需求的那些功能 可靠 在规定的一段时间和条件下 与软件维持其性能水平的能力有关的一组属性 易用 由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性 效率 与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性 可维护 与进行指定的修改所需的努力有关的一组属性 可移植 与软件从一个环境转移到另一个环境的能力有关的一组属性 其中每一个质量特征都分别与若干子特征相对应 ISO9126软件质量三层模型 Boehm软件质量模型 产品操作 产品修改 产品维护 ISO IEC9126 1991被分为两个标准体系 质量模型 ISQ IEC9126 1 2001 信息技术 产品质量 的第一部分 质量模型 ISO IECTR9126 2 2003 IT 产品质量 的第二部分 外部质量 ISO IECTR9126 3 2003 IT 产品质量 的第三部分 内部质量 ISO IECTR9126 3 2003 IT 产品质量 的第四部分 使用质量 ISO IEC14598 1 1999 IT 软件产品评估 第一部分 综述 ISO IEC14598 2 2000 IT 产品评估 第二部分 计划和管理 ISO IEC14598 3 2000 IT 产品评估 第三部分 开发者过程 ISO IEC14598 4 1999 IT 产品评估 第四部分 购买方过程 ISO IEC14598 5 1998 IT 软件产品评估 第五部分 评估方过程 ISO IEC14598 6 2001 IT 产品评估 第六部分 评估模型文档 软件质量评价方法 内部质量 外部质量 使用质量 下面两张图给我们展示了软件质量的各部分关联与区别 在内部质量和外部质量的属性上 两者是一致的 但实践中 可以简单的将内部质量等同于开发人员自己发现的代码或设计缺陷的问题集合 将外部质量等同于测试人员在实验室测试所发现bug的集合 软件产品质量需求一般要包括对于内部质量 外部质量和使用质量的评估准则 用户质量要求可通过使用质量的度量 外部度量 有时是内部度量来确定为质量需求外部质量需求从外部视角来规定要求的质量级别 外部质量需求用作不同开发阶段的确认目标 外部质量需求应在质量需求规格说明中用外部度量加民描述 宜转换为内部质量需求 而且在评价产品时应该作为准则使用 内部质量需求从产品的内部视角来规定要求的质量级别 内部质量需求用来规定中间产品的特性 内部质量需求可用作不同开发阶段的确认目标 也可以用于开发期间定义开发策略以及评价和验证的准则内部质量是基于内部视角的软件产品特性的总体 估计的 预测的 外部质量是在了解内部质量的基础上 对每个开发阶段的最终软件产品的各个质量特性加以估计或预测的质量 外部质量是基于外部视角的软件产品特性的总体 估计的 预测的 使用质量是在了解内部和外部质量的基础上 对每个开发阶段的最终软件产品的各个使用质量的特性加以估计或预测的质量 使用质量是基于用户观点的软件产品用于指定的环境和使用周境时的质量 它测量用户在特定环境中能达到其目标的程度 而不是测量软件自身的属性 内部质量和外部质量 1 功能性 当软件在指定条件下使用时 软件产品提供满足明确和隐含要求的功能的能力 1 适合性 软件产品为指定的任务和用户目标提供一组合适的功能的能力 2 准确性 软件产品提供具有所需精度的正确或相符的结果或效果的能力 3 互操作性 软件产品与一个或更多的规定系统进行交互的能力 4 安全保密性 软件产品保护信息和数据的能力2 可靠性 在指定条件使用时 软件产品维护规定的性能级别的能力 1 成熟性 软件产品为避免由软件中故障而导致失效的能力 2 容错性 在软件出现故障或者违反其指定接口的情况下 软件产品维持规定的性能级别的能力 3 易恢复性 在失效发生的情况下 软件产品重建规定的性能级别并恢复受直接影响的数据的能力3 易用性 在指定条件下使用时 软件产品被理解 学习 使用和吸引用户的能力 1 易理解性 使用用户能理解软件是否合适及如何能将软件用于特定的任务的能力 2 易学性 使用用户能学习其应用的能力 3 易操作性 使用户能操作和控制它的能力 4 吸引性 软件产品吸引用户的能力 六个特性 功能性 可靠性 易用性 效率 维护性 可移植性 4 效率 在规定条件下 相对于所用资源的数量 软件产品可提供适当性能的能力 1 时间特性 软件执行其功能时 提供适当的响应和处理时间以及吞吐率的能力 2 资源利用性 软件执行其功能时 使用合适数量和类别的资源的能力5 维护性 软件产品可被修改的能力 包括纠正 改进或对环境 需求和功能规格说明变化的适应 1 易分析性 诊断软件中的缺陷或失效原因或识别待修改部分的能力 2 易改变性 使指定的修改可以被实现的能力 3 稳定性 避免由于软件修改而造成意外结果的能力 4 易测试性 使已修改软件能被确认的能力6 可移植性 软件产品从一种环境迁移到另外一种环境的能力 1 适应性 无需采用额外的活动或手段就可适应不同指定环境的能力 2 易安装性 软件产品在指定环境中被安装的能力 3 共存性 在公共环境中同与其分享公共资源的其他独立软件共存的能力 4 易替换性 在同样的环境下 替代另一个相同用途的指定软件产品的能力 使用质量的质量模型 使用质量的属性分为四个特性 有效性 生产率 安全性和满意度1 有效性 软件产品在指定的使用周境下 使用户能达到与准确性和完备性相关的规定目标的能力2 生产率 在指定的使用周境下 使用户为达到有效性而消耗适当数量的资源的能力3 安全性 在指定使用周境下 达到对人类 业务 软件 财产或环境造成损害的可接受的风险级别的能力4 满意度 使用户满意的能力 内部度量可以应用于设计和编码期间的非执行软件产品 当开发一个软件产品时 中间产品宜使用测量内在性质的内部度量来评价 内部度量的主要目的是为了确保获得所需的外部质量和使用质量 内部度量使得用户 评价者 测试人员和开发者可以在软件产品可执行之前就能评价软件产品质量和尽早地提出质量问题 外部度量是通过测试 运行和观察可执行的软件或系统 由该软件产品所在的系统行为的测试而导出 使用质量的度量测量产品在特定的使用周境下 满足特定用户达到特定目标所要求的有效性 生产率 安全性和满意度的程度 它是根据使用软件的结果而不是软件自身的属性来测量的 使用质量是面向用户的内部和外部质量的组合效果 大型软件测试 大型软件具有涉及子模块繁多 建设过程复杂 功能全面 性能具有较高要求的特点 依据ISO IEC9126软件产品评估标准 1 需要对软件的功能性 可靠性 可用性 效率 可维护性 可移植性等方面进行评估 因此 需要有一种方法能够对大型软件进行测试 保障其软件质量 针对大型软件功能模块多 流程复杂 性能要求高的特点 总结了一种测试方法 该方法主要由功能测试和性能测试方法组成 功能测试方法由功能测试流程和功能测试用例设计方法组成 其中功能测试用例设计方法采用以等价类划分方法为主 多种其他黑盒方法为辅助的方法 性能测试方法由性能测试流程 测试工具选择 性能测试指标设计和性能调优方法组成 实践表明 该测试方法具有良好的效果 能够达到大型软件进行功能和性能把关的目的 大型软件具有涉及子模块繁多 建设过程复杂 功能全面 性能具有较高要求的特点 依据ISO IEC9126软件产品评估标准 1 需要对软件的功能性 可靠性 可用性 效率 可维护性 可移植性等方面进行评估 因此 需要有一种方法能够对大型软件进行测试 保障其软件质量 针对大型软件功能模块多 流程复杂 性能要求高的特点 总结了一种测试方法 该方法主要由功能测试和性能测试方法组成 功能测试方法由功能测试流程和功能测试用例设计方法组成 其中功能测试用例设计方法采用以等价类划分方法为主 多种其他黑盒方法为辅助的方法 性能测试方法由性能测试流程 测试工具选择 性能测试指标设计和性能调优方法组成 实践表明 该测试方法具有良好的效果 能够达到大型软件进行功能和性能把关的目的 大型软件测试流程 1 1功能测试流程功能测试目的是测试产品是否达到了合同技术协议书规定的功能 其流程如图1所示 1 2功能测试测试用例设计业务测试用例由10项内容组成 1 用例ID 2 用例名称 3 测试目的 4 测试级别 5 参考信息 6 测试环境 7 前提条件 8 测试步骤 9 预期结果 10 设计人员 业务测试用例的方法有包括等价类划分方法 边界值分析方法 错误推测方法 因果图方法 判定表驱动分析方法 正交实验设计方法 功能图分析方法和场景设计方法等 各种方法可以相互补充 2 大型软件测试流程 2 1性能测试流程性能测试需要验证产品是否达到了合同技术协议书规定的性能指标 通过自动化的测试工具模拟多种正常 峰值及异常负载条件来对系统的各项性能指标进行测试 性能测试可以分为负载测试 压力测试