软件测试工程师复习要点.doc

本文档系作者精心整理编辑，实用价值高。第一章 软件测试的基本概念 141.软件质量的定义软件产品必须提供用户所需的功能。2.软件质量的三种模型ABohm质量模型可移植性、可用性、可维护性BMcCall质量模型产品运行、产品修正、产品转移CISO软件质量模型内部质量和外部质量模型、使用质量模型内部质量和外部质量：功能性、可靠性、易用性、效率、可维护性、可移植性。内部质量需求包括静态模型、动态模型和其他文档、源代码等。使用质量：有效性、生产性、安全性、满意度；对于最终用户来说，使用质量主要是功能性、可靠性、易用性和效率的结果； 对于维护软件的人员来说，使用质量是可维护性的结果； 对于移植软件的人员来说，使用质量是可移植性的结果。3.软件质量的度量外部度量：在测试和使用软件产品过程中进行；内部度量：在软件设计和编码过程中进行；使用质量的度量：在用户使用过程中完成。4.软件测试的定义与目的软件测试是为了证明程序有错。软件测试的目的：找出软件中潜在的各种错误和缺陷；能够证明软件的功能和性能与需求说明相符合。5.软件缺陷主要类型：没有实现要求功能、出现错误、实现了没提到的功能、没实现虽然没明确提及但应实现的目标、难理解不易使用。级别：致命的、严重的、一般的、微小的。基本状态：激活、已修正、关闭或非激活。产生原因：技术问题算法错误、语法错误、计算和精度问题、系统结构不合理、算法选择不科学、接口参数传递不匹配； 团队合作 软件本身文档错误，内容不正确或拼写错误。分类：功能缺陷规格说明书缺陷、功能缺陷、测试缺陷、测试标准引起的缺陷；系统缺陷外部接口缺陷、内部接口缺陷、硬件结构缺陷、软件结构缺陷、操作系统缺陷、控制与顺序缺陷、资源管理缺陷；加工缺陷算数与操作缺陷、初始化缺陷、控制与次序缺陷、静态逻辑缺陷；数据缺陷动态数据缺陷、静态数据缺陷、数据内容结构和属性缺陷；代码缺陷程序编写错误（数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入输出错）、文档和其他错误。6.软件质量保证活动的实施步骤：目标、计划、实施（评审）、检查、行动。软件质量验证和确认：关键性分析整体上分析整个系统的资源分配策略；可跟踪性分析标识原始需求和相应开发结果之间的关系；评估软件开发各个阶段都需要进行；接口分析用户接口、硬件接口、软件接口。第二章 软件测试类型及其在软件开发中的地位 61.软件生存周期的主要阶段制定计划、系统与软件需求定义（评审）、软件设计（核心）、编程和单元测试、集成和系统测试、运行和维护。2.测试过程的三类输入：软件配置软件需求规格说明、软件设计规格说明、源代码； 测试配置测试计划、测试用例、测试程序； 测试工具为测试实施提供某种服务，减轻人的手工劳动。3.软件规划和设计阶段的测试规划阶段的主要目标：需求的获取和定义。软件设计的分类：外部设计设计用户界面； 内部设计结构设计、数据设计、逻辑设计。软件设计测试的对象来自设计文档，主要采取评审方式进行。设计文档：外部设计规格说明用户界面设计、与其他元素接口设计、系统构件部署设计； 内部设计规格说明功能设计、系统体系结构设计、数据设计； 逻辑设计规格说明模块算法与数据结构设计。4.编码、运行和维护阶段的测试结构测试属于白盒测试，功能测试属于黑盒测试。静态测试不必运行程序，目的是收集有关程序代码的结构信息而非查错；动态测试需要运行程序，目的是查错而非检查程序代码的结构信息。第三章 代码检查、走查与评审 41.桌上检查桌上检查是一种程序员（非程序编写者）自己检查源程序的方法，目的是发现程序中的错误。桌上检查的检查项目检查交差引用表、检查程序的语句代码和比较控制流图；检查变量、标号的交叉引用表，检查子函数、宏、函数，等价性检查，常量检查，标准检查，风格检查（命名规则、变量说明、程序格式、注释的使用、结构化程序设计、基本控制结构的使用），比较控制流，选择、激活路径、补充文档等。桌上检查的静态分析生成引用表和进行静态错误分析。引用表按功能可以分为：可直接从表中查出说明/使用错误循环层次表、变量交叉引用表、标号交叉引用表等；为用户提供辅助信息子函数（宏、函数）引用表、等价（变量）表、常数表等；用来做错误预测和程序复杂度计算操作符和操作数的统计表。静态错误分析类型和单位分析、引用分析、表达式分析、接口分析。2.代码检查代码检查就是以小组为单位阅读代码，其重要部分就是对照错误列表来检查常见错误。大规模的代码检查小组主要检查文档，小规模的代码检查小组主要检查具体技术的实现。小组人员：协调人员全面负责代码检查工作； 开发人员主要负责提供项目资料和回答检查人员问题； 检查人员小组每一个人都可以认为是检查人员；讲解员最佳人选是相关文档和程序代码的编写者；记录员除了记录也承担作为一般检查人员的任务。3.走查走查是对程序进行模拟，一步步展示程序如何处理测试数据，走查小组集体扮演计算机角色检查源程序。负责在走查期间作出所有说明的是走查小组秘书。走查的主要目标是发现缺陷、遗漏和矛盾的地方，改进产品，考虑可替换的实现方法。走查与代码检查的不同：两种检查方法过程大致相同，只有规程和错误检查技术略有不同；走查小组人员有限，通常仅有一人是程序编写者。走查的优点：能在代码中对错误进行精确定位，降低调试成本；可以发现成批错误，便于一同得到修正。4.同行评审同行评审是一种通过作者的同行来确定缺陷和需要变更区域的检查方法，产生需要的一个可交付的文档。同行评审的过程主要由评审小组组织和进行，评审小组主要由协调人（评审组长）、作者（确保即将评审的文件已经准备好）、评审员（读者）组成。同行评审的内容：管理评审对项目管理体系的适应性和管理活动的有效性进行评审，评审结果是提交管理评审报告；技术评审对产品以及各阶段的输出内容进行评估，目的是确保需求说明、设计说明书与用户需求保持一致，并按计划对软件进行正确的开发；评审的对象包括需求文档、源代码、测试用例、评审检查列表（检查项目）、其他必须的文档等；文档评审主要包括需求评审、设计评审、代码评审和质量验证评审；又可分为格式评审（检查文档格式是否符合标准）和内容评审（对文档的一致性、可测试性等方面进行检查）；过程评审对软件开发过程的评审，其评审对象是质量保证流程。同行评审的方法：临时评审桌上检查或轮查结对评审（最便宜）走查（非正式，应用最广泛）小组审查（“轻型”审查）正式审查（最系统最严格最实用）。第四章 覆盖率（白盒）测试 161.覆盖率覆盖率是度量测试完整性的一个工具，通常可以分为逻辑覆盖和功能覆盖。2.逻辑覆盖逻辑覆盖属于白盒测试，可以分为：语句覆盖每个可执行语句至少执行一次；判定覆盖也称为分支覆盖，每个判定的取真分支和取假分支至少评价一次；DDP（判定路径覆盖率）=被评价到的判定路径数量/判定路径的总数；条件覆盖每个判定的每个条件的可能取值至少评价一次；条件/判定覆盖判定语句的每个条件的所有可能取值至少评价一次，同时每个判定语句本身的所有可能分支也至少评价一次；条件组合覆盖每个判定的所有可能条件取值至少评价一次；路径覆盖执行程序中所有可能的路径，最强的覆盖测试。各种逻辑覆盖之间存在的关系：条件组合覆盖判定覆盖语句覆盖； 条件组合覆盖条件覆盖； 条件覆盖不一定包含判定覆盖、语句覆盖；判定覆盖不一定包含条件覆盖；路径覆盖判定覆盖语句覆盖。3.路径测试分支结构有两种：嵌套型分支结构和串联型分支结构。对于嵌套型分支结构，若有n个判定语句，则存在n+1条测试路径；对于串联型分支结构，若有n个判定语句且，在正交实验设计法中，存在条测试路径。程序的控制流图是描述程序控制流的一种图形方法，其中控制流图中的箭头称为边，表示控制流的方向，一条边必须终止于一个结点，边与结点圈定的空间称为域，当对区域计数时，图形外的空间也应记做一个区域，程序流程图可以转换为控制流图。程序的环路复杂性又称圈复杂度，是对程序逻辑结构所作的一种定量度量。环路复杂性的求法将环路复杂性定义为控制流图中的区域数；控制流图G的环路复杂性记做V(G)=E-N+2，其中E为边数，N为图中结点总数；V(G)=P+1,其中P表示控制流图中判定节点数。4.数据流测试数据流测试是路径测试的一种，它主要关注一条路径上变量在何时定义、何时使用，通过变量的定义和使用异常来检查程序错误。定义节点对应的语句有：输入语句、赋值语句、循环控制语句和过程调用语句；使用节点对应的语句有：赋值语句、输出语句。第五章 功能（黑盒）测试 141.黑盒测试主要包括：等价类测试、边界值测试、基于决策表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试、比较测试、规范（规格）导出法、内部边界值测试法、错误猜测法、基于接口的测试、基于故障的测试、基于风险的测试。2.等价类测试等价类测试的原则：如果输入条件规定取值范围或者值的个数，则可以确定一个有效等价类和两个无效等价类； 如果输入条件规定输入值的集合，则可以确定一个有效等价类和一个无效等价类；如果规定了输入数据的一组值，并且程序要对每个输入值分别处理，则可为每个输入值确立一个有效等价类，此外根据这组值确立一个无效等价类，即所有不允许的输入值的集合；如果规定了输入数据必须遵守的规则，则可以确定一个有效等价类和若干个无效等价类；如果确知已划分的等价类中各元素的处理方式不同，则进一步对等价类进行划分。3.基于决策表的测试决策表的四个部分：条件茬列出各种可能的单个条件；动作茬列出可能采取的单个动作；条件项针对各种条件给出多组条件取值的组合；动作项指出在条件项的各组取值组合下应采取的动作。决策表可以分为：有限条目决策表所有条件都是二元条件； 扩展条目决策表条件可以有多个值。4.基于场景的测试该方法从系统分析的结果用例出发，通过对每个用例的场景进行分析，逐步实现测试用例的构造。5.其他黑盒测试用例设计技术规范（规格）导出法：该测试是根据相关的规格说明书描述来设计测试用例，每个测试用例用来测试一个或多个规格说明的陈述语句。规范导出法就是根据陈述所用语句的顺序来相应地为被测试单元设计测试用例。规范导出法是一种正向的测试用例设计技术，其变化形式可应用到保密分析、安全分析、软件故障分析或其他对单元测试规格说明做出补充的文件上。基于接口的测试：输入域测试目标是选用域的代表值，从它们的执行中得到整个输入域的测试结果；特殊值测试基于计算功能的特性来选择测试用例的方法，该方法尤其适用于数学计算；输出域测试通过选择能够使得每个输出域会达到极端值的输入数据作为测试用例来执行测试。第六章 单元测试和集成测试 81.单元测试单元测试是在软件开发过程中要进行的最低级别的测试活动，或者说是针对软件设计的最小单元程序模块，进行正确性检验的测试工作。单元测试的目标是：验证代码是与设计相符合的、跟踪需求与设计的实现、发现设计和需求中存在的缺陷、发现在编码过程中引入的错误。2.单元测试与集成测试的区别：测试对象不同单元测试对象是实现了具体功能的程序单元；而集成测试对象是概要设计规划中的模块及模块间的组合；测试方法不同单元测试主要测试方法是基于代码的白盒测试；而集成测试主要是使用基于功能性的黑盒测试；测试时间不同集成测试要晚于单元测试；测试内容不同单元测试主要是模块内程序的逻辑、功能、参数传递、变量引用、出错处理及需求和设计中具体要求方面的测试；而集成测试主要验证各个接口、接口之间的数据传递关系，及模块组合后能否达到预期结果。3.单元测试与系统测试的区别：单元测试属于白盒测试，是从开发者角度考虑问题，关注的是单元的具体实现、内部逻辑结构和数据流向；系统测试属于黑盒测试，是从用户角度出发上看问题，主要目的是证明系统已满足用户的需要；单元测试使问题及早暴露，便于定位解决，属于早期测试；系统测试是一种后期测试，定位错误比较困难；单元测试允许多个被测单元同时进行测试；系统测试是基于需求规格说明的。4.单元测试环境的辅助模块：驱动模块用于代替被测模块的主模块；桩模块用于代替被测模块调用的子模块。5.单元测试分析：模块接口（参数表、输入/输出文件、出错信息处理）、局部数据结构、独立路径、出错处理、边界条件（最重要）。6.单元测试用例设计单元测试用例设计的根据是软件设计文档，即详细设计规格说明书。设计测试用例是为了发现因计算错误、比较不正确和控制流不恰当而造成的错误，发现这些错误最常用且最有效的测试技术就是基本路径测试和循环测试。通常一个完整的单元测试不仅仅要进行正向测试还要进行逆向测试。单元测试用例的设计方法通常白盒和黑盒都可以，但主要以白盒测试为主。7.集成测试所谓集成测试是指在实际情况下对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确性检验。8. 集成测试与系统测试的区别测试对象不同集成测试的对象是由通过了单元测试的各个模块所集成起来的构件；系统测试的对象除了软件之外，还包括计算机硬件及相关的外设、数据采集和传输机构、支持软件、系统操作人员等整个系统；测试时间不同集成测试先于系统测试；测试方法不同集成测试通常采用白盒测试和黑盒测试相结合的灰盒测试方法，系统测试通常采用黑盒测试；测试内容不同集成测试主要是测试各个单元模块之间的接口及各模块集成后的功能；系统测试主要是测试整个系统的功能和性能；测试目的不同集成测试的主要目的是发现单元间接口的错误，以及集成的软件同概要设计规格说明不一致的地方；系统测试的主要目的是找出软件与系统定义不符合或矛盾的地方；测试角度不同集成测试是站在测试人员角度上进行的；系统测试是站在用户角度上来进行。9.集成测试的层次对传统软件来讲，集成测试可划分为三个阶段：模块内集成测试、子系统内集成测试、子系统间集成测试。对面向对象应用系统来讲，集成测试可分为两层次：类内集成测试、类间集成测试。10.集成测试的策略方法基于分解的集成策略：一次性集成方式也称为大突击测试，是一种非增量式测试，这种测试是把所有系统构件一次性集成为一个完整的系统进行测试，不考虑构件之间的相互依赖性或可能存在的风险；所有东西都集成到一起测试很容易整体测试，也很容易导致整个崩溃；该测试的主要目标是在最短的时间内把系统组装起来，使用最少的测试来验证整个系统；优点是无须编写桩模块和驱动模块代码；缺点是要找出导致失败的原因很困难、一个模块中存在的缺陷还可能妨碍其他模块的测试。自顶向下的增量式集成方式是从顶层控制开始，采用与设计一样的顺序，将模块按系统结构的层次，沿控制层次自顶向下逐步集成测试，以验证系统的接口稳定性。自底向上的增量式集成方式是从程序模块结构的最底层开始集成和测试，目标是验证整个系统的稳定性。采用契约式设计的产品、底层接口比较稳定的产品、高层接口变化比较频繁的产品、底层模块较早完成的产品可以优先考虑自底向上的集成测试策略。混合的增量式（三明治）集成方式综合了上面两种集成方式的优点，将系统划分为三层，中间一层为目标层，测试时对目标层上面的使用自顶向下集成策略，对目标层下面的采用自底向上集成策略，最后测试在目标层会合。改进的三明治集成弥补了三明治集成不能充分测试中间层的缺点，尽可能提高测试的并行性；具体策略是并行目标层、目标层上面一层、目标层下面一层，并行测试目标层与其上面一层的集成和目标层与其下面一层的集成。其他集成策略：基于功能的集成策略是从功能的角度出发，按照功能的关键程度对模块的集成顺序进行组织，目的是采用增量式集成的方法，尽早验证系统的关键功能，做到所有模块的覆盖；基于调用图的集成策略集成调用图是一种有向图，节点表示程序单元，边表示程序调用；基于调用图的集成方式有两种，即成对集成和相邻集成；基于路径的集成策略该策略把功能测试和结构测试的方法结合在一起，但基于路径的测试需要投入标志MM路径的时间；基于进度的集成策略是在兼顾进度和质量两者之间寻找一个均衡点，该集成基本策略就是把最早可获得的代码拿来立即进行集成，必要时开发桩模块和驱动模块，在最大限度上保持与开发的并行性，从而缩短项目集成的时间；基于风险的集成策略是基于一个假设，即系统风险最高的模块间集成往往也是错误最集中的地方，因此尽早验证这些接口有助于系统的快速、稳定开发。11.集成测试分析主要从以下几个方面进行分析：体系结构分析、模块分析、接口分析、可测试性分析、集成测试策略分析。12.集成测试模块划分合理的划分应满足被集成的几个模块之间的关系必须密切、可以方便地隔离集成模块的外围模块、能够简便地模拟外围模块向集成模块发送消息、外围模块向被测试的集成模块发送的消息能够模拟实际环境中的大多数情况。第七章 系统测试1.系统测试与单元测试、集成测试的区别测试方法不同系统测试主要是黑盒测试，而单元测试、集成测试主要属于白盒测试或灰盒测试；考察范围不同单元测试主要测试模块内部接口、数据结构、逻辑、异常处理等对象；集成测试主要测试模块之间的接口和异常；系统测试主要测试整个系统相对于用户的需求；评估基准不同系统测试的评估基准是测试用例对需求规格说明的覆盖率，而单元测试和集成测试的评估基准主要是代码的覆盖率。2.系统测试分析在做系统测试分析时，通常从以下几个层次进行分析：用户层因为用户层面向的最终使用者是用户，因此用户层的测试主要围绕着用户界面的规范性、友好性、可操作性、系统对用户的支持，以及数据的安全性等方面展开，另外用户层的测试通常还应注意可维护性测试和安全性测试；应用层应用层的测试主要是针对产品工程应用或行业应用的测试，从应用软件系统的角度出发，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行测试。针对整个系统的应用层测试，包含并发性能测试、负载测试、压力测试（强度测试）、破坏测试；功能层功能层的测试是主要检测系统是否已经实现需求规格说明中定义的功能，以及系统功能之间是否存在类似共享资源访问冲突的情况；子系统层针对产品内部结构性能的测试；协议/指标层协议/指标层的测试是针对系统所支持的协议，进行协议一致性测试和协议互通测试。3.常见系统测试方法功能测试功能测试属于黑盒测试，是系统测试中最基本的测试；功能测试主要根据产品的需求规格说明和测试需求列表，验证产品是否符合需求规格说明；常见的测试用例设计方法有规范导出法、等价类测试法、边界值分析测试法、基于因果图的测试、基于判定表的测试、基于风险的测试、正交实验设计法、错误猜测法；协议测试通常包括协议一致性测试、协议性能测试、协议互操作性测试、协议健壮性测试；协议测试常用的测试用例设计方法有规范导出法、等价类测试、边界值测试；性能测试压力测试又称强度测试，是在各种资源超负荷情况下观察系统运行情况的测试；容量测试容量测试是在系统正常运行的范围内测试并确定系统能够处理的数据容量；常用的测试用例设计方法有规范导出法、边界值测试、错误猜测法； 安全性测试失效恢复测试失效恢复测试的目标是验证系统从软件或硬件失效中恢复的能力；备份测试目的是验证系统在软件或者硬件失效的事件中备份其数据的能力； GUI测试即图形化用户界面测试，一般将其分为界面层、功能层和界面与功能的接口层，而进行测试的重点是界面层和接口层，界面元素可以分为界面原子层、界面组合元素层、完整的窗口层；在软件自动化测试中占有重要地位，主要适合于回归测试阶段。稳健性测试又称容错性测试，用于测试系统在出故障时能否自动恢复或者忽略故障继续运行；一般方法是软件故障插入技术，需要关注三个方面目标系统、故障类型和插入故障的方法；兼容性测试易用性测试安装测试文档测试在线帮助测试数据转换测试4.系统测试的实施确认测试主要工作是进行功能测试（模拟环境下）和软件配置复审；测试和测试测试是用户在开发环境下进行的测试，也可以是产品供应商内部的用户在模拟实际操作环境下进行的测试，软件在一个自然设置状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题，这是在受控制环境下进行的测试；测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试，通常是在不受控制环境下进行的测试；测试与测试不同的是，开发者通常不在测试现场；验收测试是以用户为主的测试，软件开发人员和质量保证人员也应参加，由用户参加设计测试用例，使用用户测试界面输入测试数据，并分析测试的输出结果；回归测试是在软件变更之后，对软件重新进行的测试，其目标是检验对软件进行的修改是否正确，保证改动不会带来不可预料的行为或者另外的错误。第八章 软件性能测试和可靠性测试 141.软件性能的指标：响应时间、系统响应时间和应用延迟时间、吞吐量、并发用户数、资源利用率；软件性能的视角：用户视角、管理员视角、开发人员视角。软件性能测试的目标：发现缺陷、性能调优、能力检验与规划。2.软件性能测试的分类性能测试、并发测试、压力测试、可靠性测试、负载测试、配置测试、失效恢复测试；压力测试是指在较大业务压力下，即系统运行环境超常的情况（如提供超常数量、频率或总量资源）下，测试软件是否存在功能和性能上的缺陷；负载测试是指不断增加软件的业务压力，测试软件在保证预定性能指标（如响应时间）的情况下所能负担的最大压力。3. PTGM测试过程模型性能测试通用模型（PTGM）包括：测试前期准备、引入测试工具、定制测试计划、测试设计与开发、测试执行与管理、测试结果分析。4.软件性能下降曲线的分析性能下降曲线是指性能指标随用户数的增加而变化的曲线，由于性能总体是随用户数的增加而下降的，故称性能下降曲线。通常分析该曲线时会将其划分为三个区间：性能平坦区平均响应时间保持不变或略有增加，吞吐量明显上升，该区是软件运行的正常状态，希望越长越好；性能轻微下降区平均响应时间明显增加，吞吐量不上升甚至开始下降，该区是软件承受高负载的缓冲区，希望能够越长越好；注意进行压力测试时，软件性能通常在该区内；性能急剧下降区平均响应时间用户不能忍受，吞吐量急剧下降，该区对于分析性能瓶颈有很大作用。一般把平坦区和轻微下降区交界处的用户数定为最大建议用户数。5.软件性能计数器的分析性能计数器指与性能有关的资源利用率指标。基于性能计数器的分析技术有内存分析、处理器分析、磁盘I/O分析、进程分析。6.性能测试自动化性能测试自动化的基本原理压力的产生和调度、性能监控、结果分析、性能测试工具。7.软件可靠性测试软件可靠性测试的目的是收集软件测试时揭示软件故障的情况，并对其进行整理从而为分析和预测软件的可靠性提供帮助，可靠性测试的目的是通过受控的软件测试过程来预测软件在实际运行中的可靠性，而不是通过测试软件缺陷并通过修改缺陷来提高软件可靠性，即在规定的条件下、在规定的时间内软件不引起系统失效的概率，在规定的时间周期内、在所述条件下程序执行所要求的功能的能力。从软件的可靠性测试过程可知，它通常用于有可靠性要求的软件，在一次可靠性测试中，执行的测试用例必须完全符合所定义的软件运行剖面，并且通常要对测试结果进行分析才能获得测试结论。软件可靠性测试代价非常高，既可用白盒测试又可用黑盒测试，也适用于面向对象软件测试。可靠性测试的过程确定可靠性目标、定义软件运行剖面、设计测试用例、实施可靠性测试、分析测试结果。8.可靠性分析方法失效模式影响分析（FMEA）严酷度分析（CA）故障树分析（FTA）事件树分析（ETA）潜在线路分析（SCA）在硬件可靠性分析中获得成功；对于硬件，SCA法旨在发现硬件中存在的但硬件设计中不存在的线路；对于软件，SCA法旨在发现程序中异常的控制流和数据流。第九章 面向对象软件的测试 101.面向对象的特点封装、继承和多态封装指一组相关的变量和方法被封装到一个类中。继承多态多态指对类的引用可以与多个类的实现绑定，绑定有静态和动态之分，所以为达到较高的测试充分性，应对所有可能的绑定都进行测试。2.面向对象程序的测试组织问题通过执行程序代码完成的测试通常包括单元测试、集成测试和系统测试三个主要方面。对于传统的结构化程序，单元测试是指针对完成单一功能的函数的测试，集成测试是指针对程序中的集成结构的测试，而系统测试是指测试整个应用系统是否满足用户需求。在测试面向对象程序时，由于一个类的各个成员通常是相互依赖的，因此很难对一个类中的单个成员方法进行充分的单元测试。面向对象的一个类甚至都不能作为可以被独立测试的单元。类的成员方法对成员变量有依赖性，故成员方法通常不能实现独立的功能，需要在不同的实例状态下才能展示出来，甚至有的成员方法要在特定的实例状态下才能执行，因此在测试面向对象软件时，不能简单地对每个类的成员方法进行测试，在调用任何成员方法之前还必须保证相应的实例处于该方法的预期工作状态，即设计类的测试用例时，不仅要考虑调用各成员方法的输入参数，还要考虑如何设计调用的序列，而有的测试序列会在某些成员方法执行时因为不能满足方法正常执行的前提条件而导致方法处于不正常的工作状态，这些测试序列不是合理的测试序列。集成测试一般是针对程序的集成结构进行的，在面向对象程序中，许多集成机制在传统结构化程序中很少见，对于这些机制的测试难以直接应用到传统结构化程序的集成测试中。类似的，对于由多个类组成的继承树的测试，传统的集成测试技术也难以适用。3.面向对象软件的测试模型OOA、OOD、OOP、OOS面向对象分析的测试检查分析结果是否符合相应面向对象分析方法的要求，检查分析结果是否可以满足软件需求；分析结果包括对象、结构、主题、属性和实例连接、服务和消息连接；面向对象设计的测试对设计结果本身的审查，设计结果与分析结果一致性的审查，设计结果对编程的支持；前两者的主要区别是在OOD中要考虑与实现相关的内容，而在OOA中不需要考虑。面向对象编程的测试执行代码进行测试，检查代码风格。4.面向对象软件的单元测试方法层次的测试常用的测试技术有等价类划分测试、组合功能测试（也称为基于判定表的测试）、递归函数测试、多态消息测试；类层次的测试常用的测试技术有不变式边界测试、模态类测试、非模态类测试；类树层次的测试常用的测试技术有多态服务测试和展平测试。抽象类中的方法没有具体的定义，不能进行方法层次的测试，方法层次的测试是单元测试中非常重要的方面，缺少了这一方面也就不能进行单元测试。5.面向对象软件的集成测试传统的集成测试策略大突击集成测试、自底向上集成测试、自顶向下集成测试、夹层式集成测试；协作测试在集成测试时，针对系统完成的功能，将可以相互协作完成特定功能的多个类集成在一起进行测试；基干集成更加适合大型复杂项目的集成；高频集成一般采用冒烟测试的方式，即不预测每个测试用例的预期结果，如果测试中未出现反常现象，就认为通过测试；对采用迭代或增量开发过程模型开发的产品进行集成时适合采用高频集成；基于事件的集成基于使用的集成客户机/服务器的集成分布式集成针对一个类的多个实例间协作的测试属于集成测试。6.面向对象软件的类间连接测试类关联的多重复性测试在面向对象中，类间的关联关系存在多重性方面的限制，对多重性的测试是针对类间连接测试的重要方面，测试关注的重点是与连接关系有关的增删改操作；受控异常测试往返场景测试在面对对象中，许多功能是通过多个类相互协作完成，往返场景测试就是针对类间协作的一种测试技术；本质上讲，往返场景测试就是把与实现特定场景相联系的代码抽取出来，针对这些代码设计具有百分之百覆盖率的测试用例集，但在实际应用时，往返场景测试可以不基于代码而基于顺序图；模态机制测试进行模态机测试时，多个类被看作是一个大的模态类，而且该类遵循全局状态转换图；7. 面向对象程序的系统测试功能测试基于大纲的测试，这也是传统软件系统测试常用的技术，基于用例的测试，这是利用OOA文档中的用例进行的系统测试。其他系统测试完整的系统测试还包括性能测试、兼容性测试、易用性测试和文档测试等，这些与传统结构化软件的系统测试方法相同。第十章 Web应用软件测试1. Web应用软件的特点基于无连接协议、内容驱动、开发周期短、演化频繁、安全性要求较高、美观性要求较高。2.应用服务器对Web应用软件测试的影响应用服务器的功能主要包括： 构建运行环境互操作机制对Web应用软件而言，应用服务器的互操作机制能为Web应用软件集成异构成分和实现负载均衡提供帮助；对测试而言，需要更多地分析程序间的影响关系，并有针对性的设计测试用例；公共服务所有的应用服务器至少提供三种公共服务查找服务、事务服务、安全服务；除此之外，消息服务、集群服务、目录服务、日志服务、邮件服务也是多数应用服务器常提供的公共服务，在测试Web应用软件时，通常要针对所使用的服务器经常出现的误用情况进行有针对性的测试。3. Web应用软件的测试策略通常Web应用软件的测试分为三层：表示层排版结构的测试、链接结构的测试、客户端程序的测试、浏览器兼容性的测试；业务层对单个程序的测试、对一组程序的测试；数据层数据完整性的测试、数据量下数据库的性能测试。层间的集成测试表示层与业务层的集成、表示层与数据层的集成、业务层与数据层的集成。4.Web应用软件系统测试技术功能测试链接测试、表单测试、Cookie测试；性能测试并发测试、负载测试和压力测试、配置项测试和性能调优；易用性测试安全性测试、功能易用性测试、用户界面测试；内容测试测试数据库中的内容、测试服务器端程序和客户端程序是否会在数据的处理过程中引入错误的内容；安全性测试服务器端的内容安全性、客户端的内容安全性、Cookie安全性、日志功能；接口测试使用接口、提供接口。5. Web应用软件系统安全检测和防护入侵检测基于主机的检测（重点分析对主机的网络连接和Web应用软件的日志）、基于网络的检测（查找可疑的数据包）、基于完整性的检测（把每个文件的信息摘要记录在数据库中，有权限修改文件的管理员同时拥有查看和修改相应信息摘要的权限）；漏洞扫描操作系统漏洞、网络漏洞、数据库漏洞；安全策略物理安全策略（包括物理破坏的保护和信息窃取的防护）、访问安全策略（包括入网访问控制、权限控制、服务器安全控制和结点安全控制、网络监测控制和防火墙控制）、信息加密策略（包括保护策略和加密算法）、安全管理策略（包括建立数据、人员和流程的安全级别）。第十一章 其他测试1.兼容性测试主要考虑硬件、软件和数据三个方面。硬件兼容性测试与整机的兼容性、与板卡及外设的兼容性；软件兼容性测试与操作系统的兼容性、与数据库的兼容性、与浏览器的兼容性、与中间件的兼容性、与其他软件的兼容性、与平台软件的兼容性；数据兼容性测试不同版本间的数据兼容性、不同软件间的数据兼容性。2.易用性测试不仅仅针对应用程序，还包括用户文档，通常包括：易安装性测试安装手册的易用性、安装的自动化程度、安装的灵活性、安装中断的处理、修复安装和卸载、多环境安装的支持；功能易用性测试业务符合度、功能定制性、功能的关联度、数据的共享度、用户约束的合理性；用户界面测试界面整体测试、界面元素测试、输入测试。3.构件测试主要特性是可复用性；与测试相关的构件特性有可观察性、可追踪性、可控制性、可理解性。测试构件软件有机构性、源代码的可得性、演化性等困难。4.极限编程主要特征是简单的分析设计、频繁的客户交流、增量式开发、连续的测试；主要优点是可以随时应对新增或改变的需求；主要缺点是编码人员的自由度过大；极限编程的单元测试单元测试是极限编程中最重要的发现缺陷手段，它与传统单元测试类似，主要区别是极限编程的单元测试由编码人员完成和极限编程要求再编码之前进行测试，这样做一为提高编码人员测试自己编写代码的效率，二为使编码人员更好地把握软件需求，三为编码人员设立明确的编码目标。极限编程的验收测试主要由用户完成，当然编码人员也必须在场，以便与用户进行交流。极限测试实施需要注意单元测试用例的生成、单元测试工具的使用、模拟对象的使用。5.文档测试文档的类别开发文档、管理文档（属于管理范畴）、用户文档。对文档的测试只能通过文档审查的方式进行。用户文档的内容宣传资料和包装资料、用户许可说明书、手册（一致性、完备性、准确性）（安装手册、用户手册、概念手册）、在线帮助（内容的测试、功能的测试、风格的测试）、示例和模板。第十二章 软件测试过程和管理1.软件测试过程模型V模型反映出测试活动与分析设计活动的关系；指出单元测试与集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需求或合同的要求；强调了在整个项目开发过程中需要经历不同测试级别；W模型指出软件各开发阶段中应同步进行的验证和确认活动，即测试与开发也应是同步进行的，有利于尽早和全面地发现问题；指出测试对象不仅仅是程序，需求、设计等同样需要进行测试；H模型揭示了软件测试是一个独立的流程，贯穿于产品的整个生命周期中，与其他流程并发进行；强调只要达到测试就绪点，即测试条件成熟，测试准备活动完成，测试执行就可以开展（独立的、迭代的思想）。X模型提出针对单独的程序片段进行相互分离的编码和测试。2.测试阶段中的测试活动软件测试过程包括四项基本活动：测试策划、测试设计与实现、测试执行、测试总结。测试策划制定测试计划，以确定测试范围、测试策略和测试方法，规划测试任务日程表，对测试资源进行安排，并提前评估测试风险，制定风险控制策略；测试设计和实现制定测试的技术方案，选择测试工具，并根据测试技术方案设计测试用例；测试执行建立相关的测试环境、配置测试数据，按日程安排执行测试用例并记录测试执行结果，对发现的软件缺陷进行报告，并配合开发人员进行软件缺陷分析、处理和追踪；测试总结对测试结果进行综合分析，以确定软件产品质量的当前状态，为产品的改进和发布提供数据和依据，同时编制测试报告，提交相关测试文档。3.软件测试过程管理的原则有关测试需求应当有一个经各方同意的、完整的、清楚地、详细的、整体的、可实现的和可测试性的需求并文档化，尽可能坚持最初的需求；软件需求分析阶段测试的内容有真正的需求、需求是否完备、是否兼容；测试计划先行软件项目管理过程从项目的计划活动开始，软件测试项目也不例外，也是从测试计划开始；建立任务优先级在测试任务较多的情况下，应该为各项任务建立测试优先级，这也可以根据优先级来先后处理各项任务；建立客观的评估标准这样使整个项目过程具有良好的可测性和可跟踪性，强调以数据说话；尽早测试这是从W模型中抽象出来的理念，一指测试人员早期参与测试项目，二指尽早开展测试执行工作；全面测试也是从W模型中的重要思想，一指要对软件所有产品进行全面的测试，二指软件开发人员与测试人员参与到测试工作中；全过程测试从W模型中抽象出来的另一理念，一指测试人员要充分关注开发过程，二指测试人员要对测试的全过程进行全程跟踪；独立的、迭代的测试是H模型的重要思想，强调只要达到测试就绪点，即测试条件成熟，测试准备活动完成，测试执行就可以开展。4.软件测试和软件开发人员的比例操作系统类型的产品对测试要求最高，测试人员和开发人员的比例为2:1；应用平台、支撑系统类型的产品对测试要求比较高，测试人员和开发人员比例为1:1；对于特定应用系统一类产品测试人员和开发人员的比例至少保证在1:2的水平上。5.测试计划的整体目标测试计划的整体目标是为了确定测试的任务、所需要的各种资源和投入、预见可能出现的问题和风险，以指导测试的执行，最终实现测试目标：制定测试计划要达到的目标为测试各项活动制定一个现实可行的、综合的计划；为项目实施建立一个组织模型；开发有效的测试模型；确定测试所需要的时间和资源；确立每个测试阶段的测试完成及测试成功的标准和要实现的目标；识别出测试活动的各种风险。测试策略要使用的测试技术和工具、测试完成的标准和影响资源分配的特殊考虑。6.测试计划活动计划初期收集信息、确定测试需求和测试层次、计划起草、内部审查、计划讨论和修改、测试计划的多方审查、测试计划的定稿和批准。其中最关键的一步是确定测试需求和测试层次。7.软件测试设计和开发制定测试的技术方案、设计测试用例、设计测试用例的特定集合以满足一些特定的测试目的和任务、测试开发、测试环境的设计。8.测试环境软件测试环境设计环境、实施环境、管理环境。软件测试环境组成要素软件（操作系统和应用程序）、硬件（服务器和测试用机）、网络环境、数据准备（数据量、真实性）、测试工具。9.缺陷的跟踪和管理缺陷的跟踪和管理一般由数据库系统执行，主要思路为：设计好每个缺陷应包含的信息条目、状态分类等；通过系统自动发出邮件给相应开发和测试人员，使缺陷能得到及时处理；通过日报、周报等各类项目报告跟踪当前缺陷状态；在到达各个大小里程碑前，召开会议对缺陷进行会审；通过一些历史曲线和统计曲线分析来预测未来情况。10.测试执行结束测试执行结束要完成的管理操作审查测试全过程、对当前状态的审查、结束标志、项目总结。11.软件缺陷分析方法软件缺陷评估是软件质量评估的重要途径之一。常用的软件缺陷分析方法缺陷分布报告、缺陷趋势报告、缺陷年龄报告、测试结果进度报告。对于缺陷分析，常用的主要缺陷参数有状态、优先级、严重性、起源。第十三章 软件测试自动化1.软件自动化测试自动化测试是指测试执行和测试结果比较的自动化；软件自动化测试基本结构构建存在程序软件包和测试软件包的文件服务器；存储测试用例和测试结果的数据库服务器；控制执行的运行环境；控制服务器；Web服务器；客户端程序。实现方法代码的静态和动态分析、测试过程的捕获和回放、测试脚本技术、虚拟用户技术和测试管理技术。2.脚本脚本的作用用于回放测试者执行过的操作； 可以大量减少测试用例实现的工作量。脚本的基本结构：线性脚本适合于简单的、一次性的测试，多用于演示或培训；结构化脚本健壮性好，具有很好的可重用性和灵活性，可以对一些易于导致测试失败的特殊情况进行处理；共享脚本以较少开销实现类似测试，维护开销低于线性脚本，删除了明显的重复，可以在共享脚本中增加更为智能的功能；数据驱动脚本将测试输入存储在独立的数据文件中，而不是存储在脚本中；关键字驱动脚本3.测试执行自动化前处理后处理自动化测试过程自动化测试过程的核心内容是执行测试用例；前处理和后处理任务的典型特性为数量多、成批出现、类型重复多、容易自动化。自动化测试过程中，除了选择确定要执行的测试用例和分析失败原因外，其他过程都可以自动开展；自动化辅助手工测试过程中，设置和清除测试环境这些任务都是手工开展的，意味着测试用例无法连续自动运行。4.测试结果比较自动化比较是软件测试中自动化程度最高的任务。自动比较的实现方式动态比较，即在执行测试用