软件测试方法和技术 第2版 第6章 集成测试测试 和系统测试统测试 第6章 集成测试和系统测试 6.1 系统统集成的模式与方法 6.2 功能测试测试 6.3 回归测试归测试 6.4 非功能性测试测试 6.1 系统集成的模式与方法 6.1.1 集成测试前的准备 6.1.2 集成测试的模式 6.1.3 自顶向下和自底向上集成方法 6.1.4 大棒与三明治集成方法 6.1.5 持续集成 6.1.1 集成测试前的准备 人员安排 测试计划 测试内容 集成模式 测试方法 为什么总是集成不起来？ 6.1.2 集成测试的模式 渐增式测试模式与非渐增式测试模式 非渐增式测试模式：先分别测试每个模块，再把所有模块 按设计要求放在一起结合成所要的程序，如大棒模式。 渐增式测试模式：把下一个要测试的模块同已经测试好的 模块结合起来进行测试，测试完以后再把下一个应该测 试的模块结合进来测试。 各自的优缺点 6.1.3 自顶向下和自底向上集成方法 驱动程序/驱动模块（driver），用以模拟被测 模块的上级模块。驱动模块在集成测试中 接受测试数据，把相关的数据传送给被测 模块，启动被测模块，并打印出相应的结 果。 桩程序/桩模块（stub），也有人称为存根程序 ，用以模拟被测模块工作过程中所调用的 模块。桩模块由被测模块调用，它们一般 只进行很少的数据处理，例如打印入口和 返回，以便于检验被测模块与其下级模块 的接口 自顶向下法(Top-down Integration) 自顶向下法的主要优缺点 自顶向下法(Top-down Integration) 自底向上法(Bottom-up Integration) 自底向上法的主要优缺点 自底向上法(Bottom-up Integration) 混合策略(Modified Top-down Integration) 混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较 下层，使用的是“自底向上”法，两者相结合 6.1.4 大棒集成方法(Big-bang Integration) 采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段）， 然后将所有模块一次性的全部集成起来进行集成测试 。 因为所有的模块一次集成的，所以很难确定出错的真正位置、所在 的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规 模较小的应用系统中使用。 三明治集成方法(Sandwich Integration) 采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地 结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块 的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块 没有完全测试过。 改善的三明治集成方法 改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模 块得到单独的测试，使测试进行得比较彻底 。 6.1.5 持续集成 p 通常系统集成都会采用持续集成的策略，软件 开发中各个模块不是同时完成，根据进度将完成的 模块尽可能早的进行集成，有助于尽早发现Bug， 避免集成中大量Bug涌现 p 而且容易定位Bug、修正Bug，最终提高软件开 发的质量与效率 几种集成方法性能的比较 自底向上 自顶顶向下 混合策略大棒三明治改进进三明治 集成早早早晚早早 基本程序能工作时间时间晚早早晚早早 需要驱动驱动 程序是否是是是是 需要桩桩程序否是是是是是 工作并行性中低中高中高 特殊路径测试测试容易难难容易容易中等容易 计计划与控制容易难难难难容易难难难难 6.2功能测试 目的和内容 p 程序安装、启动正常，有相应的提示框、错误提示等 p 每项功能符合实际要求 p 系统的界面清晰、美观 p 菜单、按钮操作正常、灵活，能处理一些异常操作 p 能接受正确的数据输入，对异常数据的输入有提示、容错处理等 p 数据的输出结果准确，格式清晰，可以保存和读取 p 功能逻辑清楚，符合使用者习惯 p 系统的各种状态按照业务流程而变化，并保持稳定 p 支持各种应用的环境 p 能配合多种硬件周边设备 p 软件升级后，能继续支持旧版本的数据 p 与外部应用系统的接口有效 功能测试的方法 n等价类划分法 n边界值分析法 n错误推测法 n因果图法 n组合分析法 我要测试所 有的功能 回归测试的目的 p 所做的修改达到了预定的目的，如错误得到了改正， 新功能得到了实现，能够适应新的运行环境等； p 不影响软件原有功能的正确性。 回归测试的方法 p 再测试全部用例 p 基于风险选择测试 p 基于操作剖面选择测试 p 再测试修改的部分 6.3 回归测试 2000回归测试的组织和实施 回归测试 6.4 非功能性测试 p6.4.1 性能测试 p6.4.2 压力测试 p6.4.3 容量测试 p6.4.4 安全性测试 p6.4.5 可靠性测试 p6.4.6 容错性测试 6.4.1 性能测试 性能测试(Performance test)通过测试以确定系统运行时 的性能表现，如得到运行速度、响应时间、占有系统资源 等方面的系统数据。 性能测试目的和需求 目的： 为了验证系统是否达到用户提出的性能指标，同时发现 系统中存在的性能瓶颈，起到优化系统的目的。 性能测试需求： 用户对各项指标提出的明确需求；如果用户没有提出性 能指标则根据用户需求、测试设计人员的经验来设计各 项测试指标。（需求+经验） 主要的性能指标： 服务器的各项指标（CPU、内存占用率等）、后台数据 库的各项指标、网络流量、响应时间 性能测试方法 负载模拟 并发用户 + 思考时间 + 每次请求的数据量+ 负载模式 性能测试步骤 1. 确定性能测试需求 2. 根据测试需求，选择测试工具和开发相应的测 试脚本 3. 建立性能测试负载模型，就是确定并发虚拟用 户的数量、每次请求的数据量、思考时间、加 载方式和持续加载的时间等 4. 执行性能测试 5. 结果分析，并提交性能测试报告 性能测试的过程 评评估系统统 制定测试资产测试资产 执执行基线线 n如果所有用户是在一个非常短的时间内同时与系统通信， 就应该使用flat测试，将所有的用户同时加载到服务器 什么是确定容量的最好方法？ 结合两种负载类型的优点，并运行一系列的测试 如：首先使用ramp-up测试确定系统支持的用户范围该 范围内不同的并发用户负载进行一系列的flat测试，更精 确地确定系统的容量。 性能规划测试 (2) 渗入测试 渗入测试是一种比较简单的性能测试。渗入测试所需时 间较长，它使用固定数目的并发用户测试系统的总体健 壮性。这些测试将会通过内存泄漏、增加的垃圾收集 (GC)或系统的其他问题，显示因长时间运行而出现的任 何性能降低。 建议运行两次测试一次使用较低的用户负载（要在系 统容量之下，以便不会出现执行队列），一次使用较高 的负载（以便出现积极的执行队列）。 峰谷测试 兼有容量规划ramp-up测试和渗入测试的特征,目标是 确定从高负载（例如系统高峰时间的负载）恢复、转 为几乎空闲、然后再攀升到高负载、再降低的能力。 系统瓶颈分析举例-1 交易的响应时间如果很长，远远超过系统性能需求，表 示耗费CPU的数据库操作，例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考 虑是否有索引以及索引建立的是否合理；尽量使用简单 的表联接；水平分割大表格等方法来降低该值。 系统瓶颈分析举例-2 分段排除错误。测试工具可以模拟不同的虚拟用 户来单独访问Web服务器、应用服务器和数据库 服务器，这样，就可以在Web端测出的响应时间 减去以上各个分段测出的时间就可以知道瓶颈在 哪并着手调优。 系统瓶颈分析举例-3 UNIX资源监控（NT操作系统同理）中指标内存 页交换速率（Paging rate），如果该值偶尔走高 ，表明当时有线程竞争内存。如果持续很高，则 内存可能是瓶颈。也可能是内存访问命中率低。 “Swap in rate”和“Swap out rate”也有类似的解释 。 系统瓶颈分析举例-4 UNIX资源监控（NT操作系统同理）中指标CPU 占用率（CPU utilization），如果该值持续超过 95%，表明瓶颈是CPU。可以考虑增加一个处理 器或换一个更快的处理器 。合理使用的范围在 60%至70%。 系统瓶颈分析举例-5 UNIX资源监控（NT操作系统同理）中指标磁盘 交换率（Disk rate），如果该参数值一直很高， 表明I/O有问题。可考虑更换更快的硬盘系统、重 新部署业务逻辑等，另外设置Tempdb in RAM， 减低“max async IO“，“max lazy writer IO“等措 施都会降低该值。 系统瓶颈分析举例-6 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80% ，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过 一段时间后，该值将不能反映系统当前值。 6.4.2 压力测试 压力测试(Stress test)，也称为强度测试、负载测试。 压力测试是模拟实际应用的软硬件环境及用户使用过程 的系统负荷，长时间或超大负荷地运行测试软件，来测 试被测系统的性能、可靠性、稳定性等。 压力测试类型 n 并发性能测试（重点 ） n 疲劳强度测试 n 大数据量测试 在一种需要反常（如长时间的峰值）数量、频率或资 源的方式下，执行可重复的负载测试，以检查程序对 异常情况的抵抗能力，找出性能瓶颈。从本质上来说 ，测试者是想要破坏程序。 并发性能测试 考察客户端应用的性能，测试的入口是客户端 并发性能测试的过程，是一个负载测试和压力 测试的过程。即逐渐增加并发虚拟用户数负载 ，直到系统的瓶颈或者不能接收的性能点，通 过综合分析交易执行指标、资源监控指标等来 确定系统并发性能的过程。并发性能测试是负 载压力测试中的重要内容。 ramp-up测试 疲劳强度测试 通常是采用系统稳定运行情况下能够支持 的最大并发用户数或者日常运行用户数，持续 执行一段时间业务，通过综合分析交易执行指 标和资源监控指标来确定系统处理最大工作量 强度性能的过程。 疲劳强度测试案例制定的原则是保证系统长 期不间断运行的业务量，并且应该尽量去满足该 条件。 Flat测试 大数据量测试 n独立的数据量测试 针对某些系统存储、传输、统计、查询等业务进行大 数据量测试 n综合数据量测试 和压力性能测试、负载性能测试、并发性能测试、疲劳 性能测试相结合的综合测试方案 6.4.3 容量测试 容量测试目的是通过测试预先分析出反映软件系统应用特征的某项 指标的极限值（如最大并发用户数、数据库记录数等），系统在其 极限值状态下还能保持主要功能正常运行。容量测试还将确定测试 对象在给定时间内能够持续处理的最大负载或工作量。 度量系统容量举例 查看现有系统中性能与负载间的关系，并确定出现响应 时间显著延长的位置 “拐点”。可以确定是否需要增加资 源以支持额外的用户。 6.4.4 安全性测试 根据ISO 8402的定义，安全性是“使伤害或损害的风险 限制在可接受的水平内”。 安全性测试 安全性测试是检查系统对非法侵入的防范能力。安全测试期 间，测试人员假扮非法入侵者，采用各种办法试图突破防线 。例如： p 想方设法截取或破译口令； p 专门开发软件来破坏系统的保护机制； p 故意导致系统失败，企图趁恢复之机非法进入； p 试图通过浏览非保密数据，推导所需信息等等。 理论上讲，只要有足够的时间和资源，没有不可进入的系统 。因此系统安全设计的准则是，使非法侵入的代价超过被保 护信息的价值，此时非法侵入者已无利可图。 6.4.5 可靠性测试 可靠性（Reliability）是产品在规定的条件下和规定的时间 内完成规定功能的能力，它的概率度量称为可靠度。软件 可靠性是软件系统的固有特性之一，它表明了一个软件系 统按照用户的要求和设计的目标，执行其功能的