软件测试复习资料 西工大

1、第1章 概述为什么要进行软件测试？就是因为软件缺陷的存在。因为只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。软件缺陷是任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求IEEE国际标准729给出了软件缺陷的定义软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求根据软件缺陷的定义，可以从两方面考虑：p 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；p 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的主要类型/现象：p

2、 功能、特性没有实现或部分实现p 设计不合理，存在缺陷p 实际结果和预期结果不一致p 运行出错，包括运行中断、系统崩溃、界面混乱p 数据结果不正确、精度不够p 用户不能接受的其他问题，如存取时间过长、界面不美观 软件缺陷的产生 技术问题，算法错误，语法错误，计算和精度问题，接口参数传递不匹配 团队工作 误解、沟通不充分 软件本身 文档错误、用户使用场合(user scenario)，时间上不协调、或不一致性所带来的问题，系统的自我恢复或数据的异地备份、灾难性恢复等问题验证和确认Verification：Are we building the product right？是否正确地构造了软件？即

3、是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性Validation： Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求需求评审和设计评审是验证软件产品的需求定义和设计实现，验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。这个阶段主要通过对需求文档、设计文档等阅读、讨论，从中发现软件需求工程和系统设计中所存在的问题 。产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试需求验

4、证。需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。单元测试的对象是程序系统中的最小单元-模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块单元测试一般由编程人员和测试人员共同完成 集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与

5、接口有关的模块之间问题 两种集成方式：一次性集成方式和增殖式集成方式。功能测试，依据产品设计规格说明书完成对产品功能进行操作，以验证系统是否满足用户的功能性需求系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等 第2章 需求和设计评审产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致软件评审是对软件元素或者项目状态的一种评估手段，以确定其是

6、否与计划的结果保持一致，并使其得到改进。 技术评审文档评审管理（流程）评审检查表（checklist）是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。p 可靠性。人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。p 效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。测试需求测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需

7、求难以确定。p 在制定测试计划之前，必须清楚测试需求p 明确测试需求的优先级p 测试需求分解得越细，对测试用例的设计质量越有帮助p 详细的测试需求还是衡量测试覆盖率的重要依据p 测试需求是规划具体项目资源和时间的基础。功能性测试需求功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。p 程序安装、启动正常，有相应的提示框、错误提示p 各项功能符合设计要求，正常运行并输出正确结果p 功能逻辑合理，并能处理各种异常操作p 能接受正确的数据输入，输出结果准确，格式清晰p 系统的各种状态按照业务流程而变化并保持稳定p 支持各种应用环境，能配

8、合硬件设备非功能性需求非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大p 客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。p Web应用系统对性能、安全性等有很高要求p 客户端/服务器应用系统。p 大型复杂企业级系统。需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。设计审查成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的

9、表示，也就是保证产品规格说明书的质量。p 系统架构的审查p 设计规格说明书的审查p 系统部署设计的审查p 多层次审查:high-level low-level 系统设计的评审标准p 设计技术评审标准。稳定、清晰、合理p 非功能性质量特性的设计评审要求。安全、性能、稳定、扩展、可靠。p 评审的输入：体系结构文档、设计规范与指南、风险列表p 评审的输出：经认可的软件体系结构文档、变更需求、评审记录p 评审的检查点：软件体系结构、设计模式、部署视图、进程视图、封装体、协议。第3章 测试用例设计测试用例（test case）是可以被独立执行的一个过程，这个过程是一个最小的测试实体，不能再被分解。测试用

10、例也就是为了某个测试点而设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。测试用例要描述Why 为什么而测？What 测什么？Where 在哪里测？When 什么时候开始测？Which 哪些输入数据？How 如何操作软件？为什么需要测试用例p 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。p 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。p 软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例单个测试

11、用例的质量要求v 具有可操作性v 具备所需的各项信息v 各项信息描述准确、清楚v 测试目标针对性强v 验证点完备，而且没有太多的验证点v 没有太多的操作步骤，例如不超过7步v 符合正常业务惯例。整体测试用例的质量要求v 覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。v 易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。v 易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。v 粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据

12、输入的测试要求，提高测试用例的可维护性。良好测试用例的特征v 可以最大程度地找出软件隐藏的缺陷v 可以最高效率的找出软件缺陷v 可以最大程度地满足测试覆盖要求v 既不过分复杂、也不能过分简单v 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果 待查的输出结果或文件必须尽量简单明了v 不包含重复的测试用例v 测试用例内容清晰、格式一致、分类组织第4章 自动化测试自动化测试（automated test）是相对手工测试（manual test）而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。测试工具的使用是自动化测试的主要特征自动化测试焦点集中在测试

13、执行，主要是由测试工具自动地完成测试。测试自动化指“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行” 自动化测试 测试工具 测试执行 单项活动测试自动化 理念 全过程 所有测试活动 包括测试设计 测试管理在系统功能逻辑测试、验收测试、适用性测试、涉及交互性测试时，多采用手工测试方法；单元测试、集成测试、系统负载或性能、可靠性测试等比较适合采用TA；对那种不稳定、开发周期短或一次性的软件等不适合TA工具本身缺乏想象力和创造性，自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷；代码分析代码的静态分析的关键是建立各种规则，而这种规则的建立是依赖于

14、相应编程语言的语法。如依据EBNF（扩展巴科斯-诺尔范式） 对 Java代码的分析。脚本技术线性脚本，是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。 结构化脚本，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。 数据驱动脚本，将测试输入存储在独立的（数据）文件中，而不是存储在脚本中。 关键字驱动脚本，是数据驱动脚本的逻辑扩张开源工具解决方案v 单元测试：JUnit & XUnit 家族 v 功能测试：Selenium、Abbo AutoIT/AutoHotkey v 性能测试：JMeterv 数据库：DBprobev

15、 网络监控：Wireshark/Ethereal, Netcat, Snort第5章 单元测试单元测试就是对已实现的软件最小单元进行测试，以保证构成软件系统的各个单元的质量 单元测试活动中，强调被测试对象的独立性单元测试应从各个层次来对单元内部算法、外部功能实现等进行检验，包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。 单元测试的目标单元实现了其特定的功能，如果需要，返回正确的值单元的运行能够覆盖预先设定的各种逻辑在单元工作过程中，其内部数据能够保持完整性，包括全局变量的处理、内部数据的形式、内容及相互关系等不发生错误可以接受正确数据，也能处理非法数据，在数据边界条件上，单元也

16、能够正确工作该单元的算法合理，性能良好该单元代码经过扫描，没有发现任何安全性问题单元测试主要采用白盒测试方法，辅以黑盒测试方法。白盒测试方法应用于代码评审、单元程序检验之中，而黑盒测试方法则应用于模块、组件等大单元的功能测试之中黑盒测试方法（Blake-box Testing），是把程序看作一个不能打开的黑盒子，不考虑程序内部结构和内部特性，而是考察数据的输入、条件限制和数据输出，完成测试 白盒测试方法（White-box Testing），也称结构测试或逻辑驱动测试。白盒测试方法是根据模块内部结构了解，基于内部逻辑结构，针对程序语句、路径、变量状态等来进行测试，检验程序中的各个分支条件是否得

17、到满足、每条执行路径是否按预定要求正确的工作。驱动程序（driver），对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块 桩程序（stub），也有人称为存根程序，对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。白盒方法的目标v 语句覆盖，使得程序中每一条可执行语句至少被执行一次v 分支覆盖，使得程序中每一个分支都至少被执行一次v 条件覆盖，程序中每一个条件至少有一次被满足v 路径覆盖，对程序模块的所有独立的基本路径至少要测试一次环路复杂性 v V(G) = 区域数目 v V(G) = 边界数目 节点数

18、目 + 2 v V(G) = 判断节点数目 + 1v 示例计算结果：V(G) =4MCDCv MC/DC背后的原则是每个子条件必须表现为独立的影响结果。v 在子条件不独立的情况下，MC/DC或许是不可能的v 这是由于程序的逻辑而不是由于工具的限制v 在这些情况下不可能达到100%的MC/DC代码规范性的审查v 代码规范性的审查将助于更早地发现缺陷，代码质量的提高，而且可以帮助程序员遵守规则、养成好的习惯，以达到预防缺陷的目的 v 代码风格和编程规则两者不可缺一，都应列入代码评审的范围里v 命名规则 、缩进与对齐 、注释 和函数处理 等 代码缺陷检查表把程序设计中可能发生的各种缺陷进行分类，以每

19、一类列举尽可能多的典型缺陷，形成代码缺陷检查表。代码评审常常会使用这类检查表，以表的内容为检查依据、要点，防止人为的疏漏，并提高评审效率。在每次评审之后，对新发现的缺陷也要进行分析、归类，不断充实缺陷检查表 复杂度度量控制流结点 圈复杂度 基本结点和基本圈复杂度 循环嵌套和结构化 (时间间隔) 函数的扇入, 扇出 不可达性圈复杂度145236789例子:12 边9 节点VG = 12 - 9 + 2 = 5圈复杂度和结点度量是相互补足的.一般而言, 程序结构度量测量了软件属性的大小 .圈复杂度是问题复杂性的一个指示.结点 度量了由程序执行产生的附加复杂性.集成测试的模式渐增式集成模式与非渐增式

20、集成模式非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口采用三明治方法的优

21、点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。第6章 功能测试功能测试，依据产品设计规格说明书完成对产品功能进行操作，以验证系统是否满足用户的功能性需求功能测试用例的设计p 6.2.1 等价类划分法p 6.2.2 边界值分析法p 6.2.3 循环结构测试的综合方法p 6.2.4 因果图法p 6.2.5 决策表方法p 6.2.6 功能图法p 6.2.7 正交试验设计方法等价类法v 等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的v 将程序

22、可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例，、v 在分析需求规格说明的基础上划分等价类，列出等价类表设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。有效等价类和无效等价类v 有效等价类是有意义的、合理的输入数据，可以检查程序是否实现了规格说明中所规定的功能和性能v 无效等价类和有效等价类相反，即不满足程序输入要求或者无效的输入数据构成的集合 边界值计方法程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷。设计方法：确定边界情况（

23、输入或输出等价类的边界）选取正好等于、刚刚大于或刚刚小于边界值作为测试数据循环结构测试v 循环结构在软件程序中应用较多，但其测试用例的设计需要采用综合方法v 将白盒方法和黑盒方法结合起来，将条件覆盖方法、路径覆盖方法和黑盒测试方法中的等价类划分、边界值分析相结合起来，才能解决问题。v 循环结构有单循环、嵌套循环、并列循环等多种形式。从单循环结构开始，逐步深入地进行讨论 嵌套循环结构1. 除最内层循环外，从最内层循环开始，置所有其它层的循环为最小值。2. 对最内层循环做简单循环结构的全部测试。测试时保持所有外层循环的循环变量取最小值，另外，对越界值和非法值做类似的测试。3. 逐步外推，对其外面一

24、层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。4. 反复进行，直到所有各层循环测试完毕。并列循环结构 独立循环，没有依赖性，可以看作两个单循环结构 非独立循环，则可以看作嵌套循环结构因果图法v 在实际应用的测试之中，经常碰到多种条件及其组合的情况 v 通过因果图，可以建立输入条件和输出之间的逻辑模型，从而比较容易确定输入条件组合和输出之间的逻辑关系，有利于设计全面的测试用例 设计步骤 v 分析软件规格说明书中的输入输出条件并划分出等价类，将每个输入输出赋予一个标志符v 分析规格说明中的语义，通过这些语义来找出多个输入因素之间的关系。v 找

25、出输入因素与输出结果之间的关系，将对应的输入与输出之间的关系关联起来，并将其中不可能的组合情况标注成约束或者限制条件，形成因果图。v 由因果图转化成决策表，任何由输入与输出之间关系构成的路径，形成决策表的一列v 将决策表的每一列拿 决策表方法一个决策表由“条件和活动”两部分组成，也就是列出了一个测试活动执行所需的条件组合。所有可能的条件组合定义了一系列的选择，而测试活动需要考虑每一个选择。 v 条件桩，列出问题的所有条件v 动作桩：列出可能针对问题所采取的操作v 条件项：针对所列条件的具体赋值（可取真值和假值）v 动作项：列出在条件项组合情况下应该采取的动作v 规则：任何一个条件组合的特定取值

26、及其相应要执行的操作根据输入3条边（a、b、c）边长的值来判断是否构成一个三角形，如果是三角形，继续判断是等腰三角形还是等边三角形等 v 如果不能构成三角形，则不需要判断后3个条件v 如果构成三角形，即a+bc、a+cb和b+ca都必须成立，没有例外v 如果a=b且a=c，则b=c肯定成立v 如果a=b，而a=c不成立，就不需要判断b=c，实际上b=c也肯定不能成立，只能为等腰三角形 功能图法每个程序的功能通常由静态说明和动态说明组成，静态说明描述了输入条件和输出条件之间的对应关系，而动态说明描述了输入数据的次序或者转移的次序。 功能图法就是为了解决动态说明问题的一种测试用例的设计方法 功能图

27、由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model， LFM）构成状态迁移图，描述系统状态变化的动态信息动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变功能图法是综合运用黑盒方法和白盒方法来设计测试用例，即整体上选用白盒方法路径覆盖、分支和条件覆盖等，而局部上选用的是黑盒方法决策表或因果图方法 从功能逻辑模型（决策表或因果图）导出局部测试用例，即设计测试用例覆盖某个状态的各种输入数据的组合从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径可用性可用性是指以有效性、效

28、率和满意度为指标，产品在特定使用背景下为了特定的目的可为特定用户使用的程度 v 满意：对用户界面赏心悦目的程度。v 可学习性：用户第一次使用软件时完成基本任务的容易程度。v 效率：一旦用户学会了使用，完成任务的速度v 可记忆性：当用户在一段时间没有使用产品，重新使用产品，再次达到熟练程度的容易程度。v 正确性：用户会碰到多少错误？系统又如何从错误中恢复 软件可用性测试，仅靠软件组织的内部测试是不够的，还需要真正的用户参与，并观察他们的表情、行为，这需要建立专业的适用性测试实验室 回归测试策略1. 测试全部用例，选择测试用例库中的全部测试用例构成回归测试套件。2. 基于风险选择测试，基于一定的风

29、险标准来从测试用例库中构造缩减的回归测试用例套件。3. 基于操作剖面选择测试，会优先选择那些最重要或最频繁使用功能所关联的测试用例（如80-20原则中20的重要功能），有助于发现那些对质量有显著影响的缺陷，而放弃次要功能关联的测试用例。4. 测试修改的部分。 1. 通过代码相依分析，识别出软件中被修改的部分和影响的范围。 2. 从原有测试用例基线库中，排除不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，从而建立起新的测试用例基线库T0。 3. 基于操作剖面和风险选择相结合的策略，从新的测试用例基线库中选择测试用例构造有效的套件，测试被修改的软件。 4. 如果回归测试套件不能达到所

30、需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。 5. 用T1执行修改后的软件。 第7章 国际化和本地化测试本地化的概念软件本地化是在源语言版本的基础上，通过翻译、定制和参数配置等工作，使软件产品或系统在语言、时区、度量衡、文化、风俗习惯等各个方面与当地国家和地区的相应内容相一致，从而满足特定地区的用户的使用需求。国际化的概念国际化为保证所开发的软件能适应全球市场的本地化工作而不需要对程序做任何系统性或结构性变化的特性，这种特性通过特定的系统设计、程序设计、编码方法来实现国际化测试方法v 设计评审和代码审查 v 针对源语言的

31、功能测试，如不同的区域设置、不同的时区显示v 针对伪翻译（pseudocode，pseudo-translation）版本的测试本地化测试v 7.3.1 软件本地化的实现v 7.3.2 功能测试v 7.3.3 数据格式验证v 7.3.4 UI验证v 7.3.5 配置和兼容性验证v 7.3.6 翻译验证技术层面的更改调整大小、调整默认设置、重新编译、创建新的图形、重新编排文档格式；文化层面的更改 包装、图标、宣传、样品、政治敏感的术语，地方规章和宗教信仰 功能性测试，所有基本功能、安装、升级等测试；p 翻译测试，包括语言完整性、术语准确性等的检查；p 可用性测试，包括用户界面、度量衡和时区等；p

32、 兼容性调试，包括硬件兼容性、版本兼容性等测试；p 文化、宗教、喜好等适用性测试p 手册验证，包括联机文件、在线帮助、PDF文件等测试不仅要查看用户界面，而且要对文件保存、打印等类似的功能进行测试，特别要注意语言环境特定的组件，比如时间、日期格式以及文字处理等相关方面的功能进行测试。 软件本地化的配置和兼容性测试，是适应本地的一些特殊应用环境要求，所以兼容性测试也被称为本土测试（In-country testing), 包括本地的硬件（如键盘、打印机、扫描仪等）、第3方本地化软件等兼容性验证。 第8章 系统测试用户的需求可以分为功能性需求和非功能性需求，而非功能性的需求被归纳为软件产品的各种质

33、量特性，如安全性、兼容性和可靠性等系统测试就是针对这些非功能特性展开的，就是验证软件产品符合这些质量特性的要求，从而满足用户和软件企业自身的非功能性需求。所以，系统测试分为负载测试、性能系统、容量测试、安全性测试、兼容性测试和可靠性测试等 v 系统性能的改善是测试、调整、再测试、再调整、一个持续改进的过程性能调优v 性能调优需要借助负载测试方法的帮助 v 负载测试和性能测试有较多相似之处，例如，测试方法比较接近、都关注系统的性能，而且多数情况下使用相同的测试工具 v 负载测试可以看作是性能测试所采用的一种技术 v 压力测试可以被看作是负载测试的一种，即高负载下的负载测试 v 容量测试也采用负载

34、测试技术来实现v 负载测试是通过模拟实际软件系统所承受的负载条件、改变系统负载大小和负载方式来发现系统中所存在的问题 v 压力测试是在强负载情况下（如大数据量、大量并发用户连接等）稳定性进行测试，查看应用系统在峰值（瞬间使用高峰）使用情况下的行为表现，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等，确认系统是否具有良好的容错能力和可恢复能力。 v 性能测试是为获取或验证系统性能指标而进行的测 负载测试过程v 可以分为静态和动态两部分。静态部分是指设置模拟用户生成器、用户数量、用户组等，动态部分主要指添加性能计数器、检查点、阀值等，从而获得负载测试过程中反回来馈的数据系统运行的动

35、态状态。 v 可以依据业务模式变化、随时间段变化来进行设置 v 也可分为手工场景 和面向目标的场景 v 大量的虚拟用户要运行在多个客户端，并由控制器管理、代理（agent）驱动 v 负载测试的执行，需要针对不同维度的变化进行，包括时间维、负载维和系统维v 监控、详细的记录和适当的分析是十分重要的 性能测试v 性能验证测试，验证事先已定义的系统性能指标、系统能否满足系统的性能需求v 性能基准测试，在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基准线v 性能规划测试，在多种特定的环境下，获得不同配置的系统的性能指标，从而决定在系统部署时采用什么样的软、硬件配置v 容量测试可以看作性能的

36、测试一种，因为系统的容量可以看作是系统性能指标之一容量测试v 容量测试（Capacity test），通过负载测试或其它测试方法，预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），在其极限值状态下系统主要功能还能保持正常运行 v 容量测试属于性能测试中的一种，一般采用逐步加载的负载测试方法，也可以先采用逐步加载方式，获得一个基本的容量值或容量范围，然后再考虑用一次性加载方式，来决定实际可支持的容量值。 压力测试压力测试是在系统（如CPU、内存和网络带宽等）处于饱和状态下，测试系统是否还具有正常的会话能力、数据处理能力或是否会出现错误，以检查软件系统对异常情况

37、的抵抗能力，找出性能瓶颈、功能不稳定性等问题。 v 稳定性压力测试，高负载下持续运行24小时以上的压力测试 v 破坏性压力测试，通过不断加载的手段，快速造成系统的崩溃，让问题尽快地暴露出来 v 渗入测试（soak test），通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾收集（GC）或系统的其他问题，以检验系统的健壮性 v 峰谷测试（peak-rest test），采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源。兼容性测试兼容性测试是在特定的或不同的硬件、网络环境和操

38、作系统平台上、不同的应用软件之间，验证软件系统能否正常地运行，以及能否正确存取原先版本的用户数据所进行的测试p 与硬件兼容p 与操作系统、平台的兼容p 与数据库系统的兼容p 与浏览器的兼容p 与第三方系统的兼容p 与内部业务系统的兼容p 与自身系统的不同版本的用户数据兼容等 硬件兼容性测试 数据兼容性测试 系统版本之间的兼容性向后兼容是指新发布的软件版本可以使用该软件的以前版本所产生的数据。向前兼容是指在设计和开发软件一个新版本时，考虑如何和未来版本的数据兼容安全性测试软件安全性测试就是检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出上述各种安全性漏洞 容错性测试容错

39、性测试就是在各种异常条件下对系统的功能进行测试，以检验系统是否具有防护性的措施或者某种灾难性恢复的手段或能力。容错性测试可以分为两个层次：v 功能层次的容错性测试，也称负面测试（negative test）、例外测试（exception test）。v 系统层次的容错性测试，主要是灾难恢复性测试或故障转移测试。负面测试负面测试是从逆向思维出发，检查系统在异常条件下或用户的非法操作下系统是如何响应的，是否有异常行为或执行了不应该执行的动作 v 无效等价类的测试用例就是一种负面的测试 v 在一些异常的或恶劣的条件下进行操作 v 探索性测试 故障转移测试v 故障转移测试就是验证故障转移机制能否正常实

40、现，满足事先的设计要求。v 故障转移测试是在软件系统发生故障的情况下，检验系统的恢复能力，验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复或在指定时间内恢复，包括验证重新初始化、检查点、数据恢复和重新启动 等机制的正确性 可靠性测试软件可靠性是软件系统在规定的时间内及规定的环境条件下，完成规定功能的能力 ,软件可靠性主要包含以下三个要素 v 规定的时间 v 规定的运行环境条件 v 规定的功能 可靠性的最常用的度量是平均无故障时间，例如通过压力测试，并借助软件失效模式、影响分析来获得有关可靠性数据 第9章 缺陷报告和分析缺陷的严重性和优先级v 严重性：缺陷对软件产品使用的影响程度v 优

41、先级：缺陷必须被修复的紧急程度v 缺陷越严重，越要优先得到修正，缺陷严重等级和缺陷优先级相关性很强 v 也有例外，如有些缺陷比较严重，但由于技术的限制或第3方产品的限制，暂时没法修正，其优先级就会低 缺陷的类型和来源v 缺陷类型可以分为业务逻辑、数据处理、接口、UI、性能、安全性、兼容性、配置、文档等v 缺陷来源，如需求说明书、设计规格说明书、代码、用户手册等v 缺陷关联的模块名，缺陷来自于产品的特定模块的名称v 缺陷发生的阶段，例如需求、系统架构设计、详细设计、编码等有效报告缺陷v 单一准确，每个报告只针对一个软件缺陷v 可以再现，不要忽视或省略任何一项操作步骤，特别是关键性的操作一定要描述

42、清楚，确保开发人员按照所描述的步骤可以再现缺陷v 完整统一，提供完整的软件缺陷描述信息v 短小简练，如使用业务关键词v 特定条件，必须注明缺陷发生的特定条件v 不做评价，客观描述缺陷状态软件缺陷生命周期缺陷数据库所带来的益处v 不仅可以统一数据格式、完成数据校验，而且确保每一个缺陷不会被忽视，使开发人员的注意力保持在那些必须尽快修复的高优先级的缺陷上。v 可以随时建立符合各种需求的查询条件，而且有利于建立各种动态的数据报表，用于项目状态报告和缺陷数据统计分析。v 可以随时得到最新的缺陷状态，大家获得一致又准确的信息，掌握相同的实际情况，消除沟通上的障碍。v 可以将缺陷和测试用例、需求等关联起来，可以完成更深度的分析，有利于产品的质量改进等。第10章 测试计划和管理测试的原则尽早和不断地测试 重点测试 测试阶段性 测试独立性测试客观性 计划是一个过程 测试是开发的一部分发现缺陷更多的地方，其风险更大 想用户所想测试计划p 测试计划是项目计划的组成部分p 测试计划依赖于软件组织过程、质量文化和方针。p 测试计划是指导今后一系列测试活动的文件p 测试计划更是一