1.1.2 软件缺陷与故障
软件测试定义（通识观点）
（1）软件测试是为了发现错误而执行程序的过程；
（2）测试是为了证明程序有错，而不是证明程序没有错误；
（3）一个好的测试用例是在于它能发现至今未发现的错误；
（4）一个成功的测试时发现了至今未发现错误的测试。 描述性定义
定义1：为了发现错误而执行程序的过程。 定义2：根据软件开发各阶段规格说明和程序内部结构而精心设计的一批测试用例（即输入数据及其预期的输出结果），并利用测试用例运行程序以及发现错误的过程，即执行测试步骤。 1.2.1 软件测试的目的与原则 软件测试的目的
（1）测试是执行过程，并限于执行有限的测试用例发现软件的缺陷或错误
（2）检测软件是否满足软件定义的各种需求目标
（3）执行的测试用例发现了未曾发现的缺陷或错误，即实现了成功的测试 软件测试的原则
（1）尽早并及时进行测试，测试始于软件产品开发初期
（2）测试用例由测试数据与预期结果两部分组成，并包括测 试前置条件或后置条件
（3）测试根据其需求和风险由专业测试者进行或开发者自检
（4）需严格执行测试计划并排除测试随意性 （5）注意测试中的集群效应（80%错误仅与20%程序有关）
（6）对测试结果作核查并保存用例、缺陷统计和分析报告，为软件维护提供资料及条件 测试的基本原理
原理1：测试可证明缺陷存在，但不能证明缺陷不存在 原理2：穷尽测试是不可能的 原理3：测试活动应尽早开始 原理4：缺陷集群性 原理5：杀虫剂悖论 原理6：测试依赖于测试内容 原理7：没有失效就是有用的系统是一种谬论 测试的特性准则 对任何软件系统都存在有限的充分测试集合; 测试单调性; 测试的非复合性; 测试的非分解性; 测试的充分性与软件需求与软件实现相关; 测试复杂性; 测试回报递减率; 1.2.3 软件测试的基本策略
确定测试目标 确认测试对象 建立测试生命周期 制定实施测试策略
选择测试类型 : 功能测试 / 非功能性测试 / 恢复 测试 1.4.1 软件质量体系 1．质量与质量管理 GB/T 6583—1994 idt（等同）ISO 8402. 1994定义：“反映实体满足明确和隐含需要的能力和特性综合”。这里实体指产品、活动、过程、组织的体系等。因此，质量“是一组固有特性满足要求的程度”。要确保产品质量，必须保证有生产过程的质量和组织体系的质量等实体的质量。 ISO 9000 的重要科学依据是“质量生存于全部的生产过程中”。具体体现在事前计划、严格按计划实施、事后检查、总结分析并采取改进措施的循环方式上。
所谓质量管理就是组织在产品生产中的质量策划、质量控制、质量保证和质量改进等与质量有关的相互协调的活动，有下列内容。 （1）质量管理体系
（2）质量管理运作实体，主要为4部分：① 组织结构；② 程序；③ 过程；④ 资源。
（3）ISO 8402：1994定义的质量策划：确定质量及采用质量管理体系要素和要求活动。 包括：① 产品策划；② 质量管理体系管理和运作策划；③ 编制质量计划。
（4）质量控制 （5）质量保证 （6）质量改进
现代质量管理已从单纯对产品质量检验拓展到对产品形成过程的控制，控制策略从静态发展到动态与持续的过程，其核心思想是对过程的策划、控制和过程能力持续改进。 2．软件质量管理
ANSI/IEEE Std 729—1983定义的软件质量：与软件产品满足规定的和隐含的需求的能力有关的特征或特征的全体。定义实质反映三方面。 （1）软件需求是度量软件质量的基础
（2）在各种标准中定义开发准则，指导软件开发要使用工程化的方法
（3）软件需求中常有一些隐含需求未明确提出 软件质量是软件产品特性可满足用户的功能、性能需求的能力
ISO/IEC 9126 软件质量的完整定义标准，包括六部分：功能性、可靠性、可用性、有效性、可维护性和可移植性。每部分质量为软件属性的各种标准度量的组合
软件质量管理是软件组织在软件生产中的质量策划、质量控制、质量保证和质量改进等与质量相关的相互协调的活动。软件质量管理具有质量管理的特征和所有属性。 （1）软件质量策划内容
确定组织-为建立软件组织的质量管理体系所做的基础准备。
确定组织的质量管理体系目标-通常以CMM及ISO 9126作为质量管理体系符合性标准
标识和定义组织质量过程-对组织的质量过程进行策划，确定过程的资源、主要影响因素、作业程序和规程、过程启动条件和过程执行结构的规范等。
标识产品质量特性-建立起目标、质量要求和约束条件。
（2）软件组织的质量过程
软件工程过程-软件生命周期中的活动，包括需求分析、软件设计、软件编码、软件测试、交付、安装使用与软件维护。
组织支持过程-为保证软件工程过程实施和检查而建立的一组公共支持过程，主要包括管理过程与支持过程。 （3）软件质量控制
5项内容：依职责分工进行质量活动；活动依策划的方法、途径和时间有序进行；对关键过程和特殊过程实施适当过程控制方法；活动记录完整且真实保存供统计分析。
质量控制技术：配置管理和过程流程管理 （4）软件质量度量
软件质量度量分为产品质量度量和过程质量度量。
产品质量标准-通过测试获得产品质量特性数据，统计确定产品是否满足规定要求。软件度量包含复杂性/可靠性度量等，采用统计，如Bug发生率、千行程序误码率等。
软件质量过程度量-过程度量的成熟非表现在简单复制等再生产环节的成熟，是整个软件过程的成熟，目前对产品设计、开发、测试、评审等开展过程的度量；软件质量过程管理对软件验证通常包括对各层级设计的评审、检查及各阶段测试，过程验证是对过程数据的评估与审核。 （5）软件质量改进
ISO 9000规定组织定期进行内审和管理评审，采取有效纠正与预防措施，保持组织的质量方针与目标的持续发展。软件质量策划对软件过程质量改进有具体要求。
质量度量与审核-通常包括软件可靠性度量、软件复杂性度量、软件缺陷度量、软件规模性度量。度量活动涉及需求分析、实现、测试、软件维护，各种评审内容。
纠正和预防措施-质量改进重要手段。纠正针对不合格情况本身，纠错是消除实际的不合格原因。预防与纠正不同，预防措施目的是消除潜在不合格原因，防止不合格的发生；纠错措施目的是防止不合格再次的发生。 1.3.3 软件测试模型分析 1．V模型分析
V模型主要反映软件从需求定义到实现与测试活动的关系，强调在整个软件项目生命周期中需要经历的若干开发与测试的对应级别。
V模型从左到右、从上到下描述开发过程和测试行为，测试和开发过程对应。
V模型基于一套须严格按一定顺序进行开发的步骤，但可能没有反映实际工程 V模型从需求处理开始，体现“尽早地和不断地进行软件测试”原则。 V模型不足是需求、设计、编码活动被视为串行，测试和开发保持线性关系，上一阶段完成才开始下一阶段活动，难于支持迭代方式和不适于开发过程的变更调整。
在V模型增加各开发阶段的同步测试，演化为基于V&V原理的W模型，体现“尽早地和不断地进行软件测试”原则，形成双“V”，即“W”结构。
2．X模型分析
X模型对测试过程模式重组，形成“X”。X代表未知，含探索性测试特征。
X模型左边描述针对单独程序片段进行的相互分离的编码和测试，将进行频繁交接，通过集成最终合成为可执行程序，对可执行程序还需测试。 对已通过集成测试的成品进行封版，提交用户，也可作为更大规模和范围内集成的一部分。多根并行曲线表示变更可在各部分发生。
X模型还定位探索性测试。该方法有助经验测试者探索发现更多的缺陷。
3．前置测试模型分析
前置测试模型将测试与开发紧密结合，代表测试新思想。该模型提供灵活方式使开发加快进程。前置测试需运用测试技术的开发者、测试者、项目经理及用户带非传统方法的内在价值，用较低成本及早发现错误，并充分强调测试对确保高质量的重要意义。 模型要点
开发和测试相结合; 对每一个交付内容进行测试 ;模型包括两项测试计划技术; 设计阶段进行计划和测试设计; 增加静态审查及独立的QA测试; 测试和开发结合在一起; 验收测试和技术测试保持相互独立; 反复交替的开发与测试; 2.2.5 手工测试与自动化测试 1．手工测试
软件测试主要、经典的方法，其优势是因人具有很强的逻辑判断能力，能被灵活运用。其不可被替代的原因： 测试用例的设计：测试人员根据规格说明书而设计测试用例，其经验和对错误的判断能力工具所不能完全替代。
软件界面与用户体验的测试：人的审美、心理感受及体验工具无法模拟。
正确性检查：人对错误的判断、逻辑推理能力，工具不能或完全替代。
各种评审测试：均需要通过人工方式来完成。 2．自动化测试
自动化测试是软件测试必然发展，是对手工测试的有力补充。
目的是帮助测试，部分替代手工测试。 主要手段是采用测试工具。
测试工具（或测试平台）是设计的特殊软件系统并利用其功能完成测试任务或工作
实际自动化测试含义广泛，任何帮助软件测试流程的自动流转、替换手工的动作、解决问题的过程，以及帮助测试人员进行测试工作的相关技术，或工具（包括开发测试的工具和测试工具）的应用，都属于自动化测试。 2.3.1 组件测试的类别及模式 1．组件测试对象
组件测试根据内容进行正确性检验，其目的是发现组件内部可能存在的缺陷或错误。
组件测试处理对象直接来自开发工作结果。 2．组件测试类别
组件测试分广义和狭义。狭义组件测试指编写测试用例验证被测代码正确性。如针对某类或方法（函数）的测试。
广义组件测试指编写测试用例进行小到一行代码验证、大到一功能模块验证，从代码规范性检查、代码审查、代码功能、代码性能、程序安全性检查，一系列的验证测试均包含。
组件测试有静态测试与动态测试。静态组件测试主要指代码走读这类检查性测试，针对代码文本检查，不需编译和运行代码。动态组件测试要通过编写测试代码（或设计测试用例）测试，需编译和运行代码，调用被测代码运行。
组件测试不论静态测试还是动态测试都可采用人工方式或自动化方式。 3．组件测试模式
测试驱动模式。测试用例设计提前到代码未产生前，强迫开发对即将编写代码程序进行需求的细节分析和代码设计方案考虑。这种测试策略使开发习惯改变，如敏捷开发中的测试。
代码先行模式。先编码后测试。这种方式较易实施和控制，可选重要代码测试。 2.3.2 组件测试的任务 1．组件内部模块接口检测
针对内部模块接口测试应进行检测主要有： 模块接收的输入参数个数与模块的变量个数是否一致。参数与变量的属性是否匹配。参数与变量所使用的单位是否一致。给另一被调用模块的变量个数与参数个数是否相同。传送给另一被调用模块的变量的单位是否与参数的单位一致。调用内部函数时，变量个数、属性与次序是否正确。在模块有多入口情况下，是否有引用与当前入口无关的参数。是否会修改只是作为输入值的变量。出现全局变量，这些变量是否在所有引用它们的模块中都有相同的定义。是否把常数作为变量来传送。文件属性是否正确。文件打开语句格式是否正确。格式说明与输入、输出语句给出的信息是否一致。缓冲区设置的大小是否与记录的大小相匹配。是否所有的文件在使用前均已打开。对文件结束条件的判断和处理是否正确。
对输入、输出错误的处理是否正确。是否有输出信息的正文错误。 2．局部数据结构检测
模块局部数据结构是常见错误发生源，对局部数据结构应在组件测试中发现。 不正确的或不一致的类型说明 错误的初始化或默认值
错误的变量名（拼写错误或缩写错误） 下溢、上溢或地址错误
除局部数据结构外单元测试中还应明确全程数据对模块影响 3．路径检测
测试用例须能发现计算错误、不正确数据流、不正确程序判定或控制流产生的错误。
误解的或不正确的算术优先级; 混合模式的运算; 错误的初始化; 数据及计算机结果的精确度达不到精确度的要求; 表达式的不正确符号表示 ;
针对判定和条件覆盖，执行测试用例将可能发现： 不同数据类型的比较; 不正确的逻辑操作或优先级错误; 应相等的计算结果因精度的错误而不能相等 ;不正确的判定或不正确的变量 ;不正确的或不存在的循环终止; 分支循环程序不能实现退出循环 ;不适当地修改了程序的循环变量; 4．边界条件检测
软件常在模块边界处发生问题 边界测试也是组件测试的内容
针对边界条件检查采用边界值分析法测试
5．出错处理检测
测试重点是检验模块在工作中发生错误后其出错处理措施与处理是否有效 检验出错处理可能面对情况：
对运行发生的错误描述的信息难以理解; 所报告的错误与实际遇到错误不一致; 出错时，在错误处理之前就引起系统的干预 ;例外条件的处理不正确 ;提供的错误信息不明确以至无法找到出错的原因
2.3.3 组件测试的过程
（1）驱动模块 用来模拟被测模块的上一级模块。驱动模块在测试中接收数据，把相关数据传给被测模块，启动被测模块，并输出相应结果。 （2）桩模块 用来模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，只进行较少数据处理，以检验被测模块与其下一级模块接口。
有图
2.3.4 组件测试管理
组件测试管理规范内容包含制订组件测试计划、设计原则与执行过程。
组件测试通常由开发人员完成（敏捷开发普遍） 组件测试需注意测试与调试两者具完全不同含义，主要体现在目标、方法与思路上。 测试从已知条件始，预先定义内容（条件、用例）及过程，可预知测试结果并可控。
调试是从未知条件开始，预期过程与结果不可预计。调试难以预期过程及时间。
测试能在无详细设计下进行而调试无详细设计（或代码）则无法进行。 2.4.1 集成测试概念 集成测试（Integrated Testing）阶段是指每个模块完成组件测试后，需按照设计时确定的软件结构图，将它们连接起来，进行集成测试。集成测试也称为综合测试
2.4.2 集成测试策略 1．非增量式测试
采用一步到位的方法构造测试。对所有模块测试后，按结构图将模块连接后整体测试。 2．增量式测试
增量式测试与非增量式测试不同，集成逐步实现，测试也是逐步完成。可认为是将组件测试与集成测试结合进行。
增量式集成测试按不同次序实施产生两种不同方法，自顶向下方法和自底向上方法。 自顶向下增量式测试
整个过程由以下3步骤完成：（1）主控模块作为测试驱动器。（2）根据集成方式（深度或广度）下层桩模块一次次被替换为真正模块。（3）在每个模块被集成时都必须进行单元测试。重复（2），直至整个系统被测试完成。
自底向上的增量式测试
自底向上的增量式测试表示逐步集成和逐步测试是按结构图自下而上进行。
因从底层开始集成所以不再需要使用桩模块进行辅助测试。
2.5.1 系统测试的概念、对象、环境与目标 1．系统测试的概念
系统测试主要从系统的角度来检验和寻找缺陷。这部分测试主要包含功能测试、性能测试、安全测试、可靠性测试、恢复性测试与兼容性测试等。 2．系统测试的对象与环境
经集成测试软件已完全组合起来系统测试将系统作为整体测试
系统测试应尽可能在与目标运行环境一致的情况下进行
在测试平台上安装要用到硬件和软件以替代测试驱动器和桩
系统测试需要独立的测试环境
如在客户运行环境下而非独立环境下执行系统测试会有较大风险。原因如下： -系统测试很可能发生失效并对客户运行环境造成破坏，系统发生崩溃和数据丢失 -测试者对运行环境的参数设置与配置控制有限或完全没有容易产生失控
-客户环境下其他系统也同时运行，测试条件会渐变，使测试执行不能或难以重现，将影响测试结果正确，造成测试结论失真 3．系统测试的目标
系统测试目标是确认整个系统是否满足了软件规格说明中的功能性、非功能性各项需求满足程度。系统测试应能发现和找出因需求不正确、不完整或实现与需求间的不一致而引起的软件失效，并识别在无文档时或被遗失的需求。 4．系统测试实践中的问题
在不明确系统需求下软件系统行为都正确，系统测试则无法对系统各项功能进行正确评估。此时针对系统测试只能采用探测性测试。错误的测试分析和决策将导致系统测试失败，并由此造成项目（系统或开发）的失败。 2.5.2 系统的功能性测试
功能性测试包括验证系统输入/输出行为的各种测试。功能性测试的基础是功能需求，功能需求详细描述系统行为和定义了系统必须完成的功能。
根据ISO/IEC 9126 定义，功能特性包括适应性、准确性、互操作性和安全性等。
功能性测试一般采用黑盒测试技术。
功能性测试可在软件生命周期不同阶段进行。 功能测试细分为逻辑功能测试、界面测试、易用性测试、安装测试等。 1．逻辑功能测试
逻辑功能测试基本思路是设计和运用某种测试方法，根据软件规格说明（达到功能）构造合理的输入（测试用例）并输入软件，检查是否得到期望结果的输出，即使用有限的输入值来测试和验证软件的逻辑（业务）功能。
逻辑功能测试常采用动态测试技术，如等价类划分法、边界值法、因果图法、决策表法、状态转换法、配对法（正交试验法）等。 2．界面测试
界面测试（User Interface Testing）为功能测试范畴。现软件中用户选择性操作（或交互行为）不断增加，使得界面测试内容丰富、形式众多。这里以Windows软件为例说明。
针对窗口（1）窗口是否基于相关的输入和菜单命令适当地打开及关闭。（2）窗口能否改变大小、移动和滚动。（3）窗口中的数据项和内容能否用鼠标、功能键、方向键和键盘访问。（4）当窗口被覆盖并重新调用时，窗口能否正确地重现。（5）所有窗口相关功能是否可操作。（6）是否有相关下拉菜单、工具栏、滚动条、对话框、按钮、图标和其他控制并显示。（7）在多个窗口同时打开时，能否正确地表示。（8）被激活的窗口是否被加亮。（9）调用多任务时是否所有窗口能被实时更新。（10）不正确地单击鼠标是否会导致无法预料的结果发生。
针对下拉式菜单和鼠标操作（1）菜单条目是否显示在合适的环境中。（2）下拉式菜单操作时能否正确地工作。（3）鼠标操作时能否正确地工作。 针对数据项（1）字母、数字数据项能否正确地回显并输入系统中。（2）图像模式的数据项（如滚动条）能否正常地工作。（3）能否识别非法数据。（4）数据输入消息能否被正确理解。 3．易用性测试
易用性测试指从软件使用的合理与方便程度对
软件进行的测评，
发现该软件不便于用户使用的某些缺陷。该性测试主观性较强，不同用户可能对易用性理解不同。
（1）常用功能具有快捷方式，不同版本主要使用方法和操作步骤变化小，版本连续性
（2）尽可能将功能相同或相近的操作设计在一个区域，以方便用户查找和使用。
（3）对可能响应较长时间实现的功能，提供进度显示和中止按钮的选项。
（4）具有比较完善的用户联机帮助与在线使用指导。
（5）工具栏图标能够直观地代表要完成的操作。 （6）当软件运行出现问题时提示信息中提供相应技术支持信息和联系方式。 4．安装测试 安装 （1）典型安装和完全安装：检查安装步骤、安装过程中各个界面。（2）自定义安装：检查安装步骤、安装过程中各个界面、安装不同路经和选项。 （3）中断安装： 关闭程序、关机、断网、安装磁盘空间不足时能否实现断续性安装。（4）检查能否同时安装同一软件的多个版本。 卸载 （1）从程序组里卸载：检查桌面、程序组、注册表中信息是否被删除。（2）从控制面板中卸载：检查桌面、程序组、注册表中信息是否被删除。（3）中断卸载过程：检查关闭程序、关机、断网等操作，是否显示卸载成功等信息。（4）检查是否可卸载正在使用的程序。 2.5.3 系统测试的非功能性测试
软件还体现一些非功能特性。非功能需求不描述功能而描述功能行为的属性或系统的属性，即系统执行其功能有“多好”，或程度如何，这些属性需求的表现，对客户满意度有重大影响。 根据ISO/IEC 9126 质量规范，需求特性包括可靠性、可用性和效率等。这些特性检验与度量，含性能、安全性、恢复性、兼容性测试和其他非功能性测试。 1．性能测试
性能测试检验软件是否达到性能设计的要求，找出未达到性能要求所产生的原因，性能测试检验系统的性能运行表现。性能测试属软件测试高端领域，通常采用自动化测试。 软件性能包括多方面，主要为时间性能与空间性能两类。
（1）时间性能。指软件的一个具体事物的响应时间（Respond Time）。通常响应时间是在多次、多种情况下事务响应的最大值、最小值和平均值。响应时间长短没有绝对标准，需根据软件设计的响应时间指标来确认。
（2）空间性能。指软件系统运行时所消耗的系统资源。CPU占用率、内存占用率等。
性能测试可在测试过程中任意阶段进行，即使是组件测试。
2．性能测试的梯度
性能测试可分为一般性能测试、负载测试、压力（强度）测试与稳定性测试。 3．安全性测试
系统漏洞，也称系统脆弱性. 安全性测试含系统操作的安全功能检测、数据安全传输功能测试等。 4．其他测试
恢复性测试 兼容性与数据转换测试 文档检查 可维护性检查 2.7.1 验收测试的含义
验收测试是检验软件产品质量的最后一个过程。 验收测试通常更突出客户的主导作用，同时也需开发人员参与。
验收测试可分布在多个测试级别上进行，甚至可以在较低测试级别执行。
对商业现货软件可在安装或集成时进行验收测试，对组件（自行开发或引进）可用 性验收测试在组件测试时进行，系统测试前可进行新功能验收测试等。
常见验收测试形式:
（1）根据合同的验收测试。最重要验收测试通过验收判断合同条款是否满足。
（2）用户和用户群组织的验收测试为整个系统得到确认的最后测试阶段。 （3）测试常有测试备份、灾难恢复、用户管理、维护项目和安全攻击检查。
（4）用户现场的测试（α与β测试）。
验收测试范围取决于软件的风险评估。若软件是用户定制，则风险相对较高，需进行全面验收测试。若获得是标准软件产品，并在一类似环境中运行了很长时间，则验收测试仅包括安装系统，运行代表性测试用例（User Case）。若系统要通过一种新方式和其他系统协同合作运行，则至少要测试互操作性。
验收测试安排通常由开发者与用户协商，并在验收测试计划中规定和说明。 2.7.2 验收测试的任务及内容 1．通常验收测试应完成的任务
（1）明确验收项目，规定验收测试通过的标准。（2）决定验收测试组织机构、利用的资源。（3）选定测试结果分析方法。（4）指定验收测试计划并进行评审。（5）设计验收测试所用的测试用例。（6）审查验收测试准备工作。（7）执行验收测试。（8）分析测试结果。（9）做出验收结论，确认通过验收或不通过验收。
2．验收测试计划中应包括的验收测试内容（1）功能测试。（2）出错/恢复测试。例如，检验不符合要求数据而引起出错的恢复能力。（3）特殊情形测试。例如，极限测试、不存在的路径测试。（4）文档测试（正确性及可用性检查）。（5）强度测试。如大数据（大批量数据或大容量文件）或最大用户并发使用情形测试。（6）恢复性测试。如因硬件故障或用户不良数据引起故障下系统的恢复能力测试。（7）对软件可维护性的检查与评价。（8）某些用户操作性的测试。例如，安装、卸载系统，启动、运行与退出系统等。（9）软件的用户友好性检验。（10）安全性测试。如实施人为各种安全性攻击，观察和检验系统的防护能力。
2.7.3 软件文档验收测试
软件测试是复杂过程，涉及软件开发中各种文档。软件文档是软件需求、软件开发计划、软件过程及软件测试的结论，是以正式文件形式写出的各种文本、源程序等。对软件文档测试是测试规范的组成，这对保证软件质量、正常运行与维护十分重要。
测试文档对测试阶段工作具有重要指导作用。需特别指出：在完成开发并发布、投入运行的软件维护阶段中，常需回归测试，这需要使用软件文档。
对文档的测试包含以下内容。 （1）检查产品说明书属性。（2）检查内容是否完整。（3）检查描述是否准确。（4）检查描述是否精确。（5）检查描述是否一致。（6）检查描述是否贴切。（7）检查代码无关性。 本章小结
1．软件测试贯穿于软件生命周期的全过程。这表明测试活动伴随软件全过程。
2．通用V模型定义基本测试级别：组件测试、集成测试、系统测试和验收测试。
（1
）每个开发阶段都有一个对应的测试级
别。
（2）每个测试级别的测试目标是变化的且各自明确。
（3）每个测试级别的测试设计应尽可能早地开始，在开发活动初期进行。
（4）测试者应尽早地加入开发文档的评审中。
（5）测试级别的数量与深度可根据项目的具体需要进行裁剪。
3．组件测试检查单一模块、类与函数；集成测试检查组件合成的接口协调关系；系统测试检查整个系统；验收测试根据开发合同进行验收，运行预备版本及现场测试。
4. 通过缺陷修复和进一步开发改变或扩展产品，对改变后的新版本须回归测试。
5. 测试技术分静态测试、动态测试、基于规格说明的测试、基于程序结构测试、基于经验测试，及手工测试与自动化测试的区分。基于软件风险测试依风险程度和使用风险分析方法识别风险，并决定其测试的数量与测试的级别。
6．软件测试可以不同角度，根据查找缺陷或故障的策略、技术、范围等进行分类。这反映了软件测试领域的认识体系、技术体系、工程体系、应用体系与层次体系，各类测试和各种测试技术将解决不同的测试问题。 7．ISO/IEC 9126定义软件质量的标准与规范体系，主要有功能测试与非功能测试，每部分含不同测试内涵和度量标准，检验软件产品质量各部分。 3.1.1 静态测试技术概要 2．静态测试内容及过程
内容及过程主要有：测试需求分析、测试概要设计、测试详细设计、测试执行与结果分析。 3.1.2 静态测试技术 1．代码检查
代码检查包括代码走查[代码审查,技术评审]（自检、他检或审查会），主要检查代码和设计的一致性，代码对标准遵循及可读性，代码逻辑表达正确性及结构合理性。 2．程序结构静态分析
静态结构分析主要是以图形方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。
函数调用关系图以直观图形方式描述一个应用程序中各个函数的调用和被调用关系；
控制流图显示一个函数的逻辑结构，由许多节点组成，一个节点代表一条语句或数条语句，连接节点的叫边，边表示节点间的控制流向。
检查项： 代码风格和规则审核； 程序设计和结构的审核； 业务逻辑的审核； 走查、审查与技术复审手册。
3．程序代码质量度量
针对软件或代码复杂度度量测试主要有三种方式（或称度量参数）。
Line复杂度 以代码行数作为度量计算的基准。
Halstead复杂度 以程序中出现的操作符和操作数（运算符和运算元）作为计算对象，直接测量指标并据此计算程序长度和容量，描述程序最小实现和实际实现之间关系，以此度量程序复杂程度。任意程序P，总由操作符和操作数通过有限次组合连缀而成。
P的符号表词汇量 N＝n1＋n2（n1：P 中出现所有唯一操作数数量，n2：P中出现所有唯一操作符数量）
度量指标计算：程序长度N＝n1＋n2 程序容量V＝N×log2 N。
代码体量会因程序实现方式和编码习惯有所差异，还会因所采用设计语言（保留字数量、语句结构等）有所不同。因此又有如下标准
程序语言等级：L＝Vmin/V（Vmin是程序实现时可能的最小代码容量） 编程效率 E＝V/L
Halstead 分析优势：系统划为单独模块，短代码设计、编码及测试难度都比长代码低
McCabe复杂度（圈复杂度） 是将程序流程图结构转化为有向图结构，以图论法计算程序复杂度，实质为衡量程序判定结构的复杂程度。度量在数量上表现为独立的程序现行路径条数。这是合理预防错误缺陷所需进行测试的最少路径条数，可简单理解为圈复杂度相当于至少需少个测试用例才能对该程序实现全路径覆盖。圈复杂度越大程序代码质量可能越低。程序可能存在错误及缺陷与高圈复杂度有关，以致难于设计测试用例及后期维护。
完整的McCabe复杂度包括：圈复杂度、基本复杂度、模块设计复杂度和集成复杂度等 4．评审与检查
静态测试的活动主要分为静态测试评审和静态测试检查两部分
（1）静态测试评审 对需求分析和概率（2）静态测试检查 检查过程的内容：从所指定测试计划开始，检查测试的初始工作和测试的准备情况，检查以会议的形式进行，根据检查结果决定是否需要重新开始制订计划或其后的某项环节及工作。若检查通过，则继续测试过程。 （4）静态测试可发现的错误
错用局部变量和全局变量，所用变量和常量的交叉应用表； 未定义的变量、不匹配的参数； 不适当的循环嵌套或分支嵌套、死循环、不允许的递归； 调用不存在的子程序或函数，遗漏标号或代码； 从未使用过的变量，不会执行到的死代码、从未使用过的标号； 标识符的使用方法和过程调用层次，潜在的死循环 。 3.3.1 程序的控制流图 1．控制流图
程序结构就是一幅控制流图。
在一程序控制流图中所涉及图形符号只有两种：判断节点和控制流线。
（1）判断节点：由带有标号的圆圈表示，可代表一个或多个语句、一个处理框的序列和一个条件判断框（不含复合条件）。
（2）控制流线：带有箭头弧线及直线表示，称为边，代表程序中控制流。包含条件的节点称判断节点，由判断节点发出边须终止于某一节点，边和节点所限定范围称区域。 2．矩阵图
矩阵图是控制流图的矩阵表示形式，其矩阵的维数等于控制流图的节点数 3．控制流异常
通过控制流图描述很易理解程序结构顺序，也可发现可能的异常情况。
静态测试分析工具还能产生前驱后继表，以表示每个语句之间的相互关系。若某语句无前驱，则该语句为不可达（死代码），可能为缺陷。 有三种计算环形复杂度V(G)的方法
（1）V(G)=控制流图G中的封闭区域的数量+1。 （2）V(G)=E?N+2 E流图中边数量，N流图中节点数量
（3）V(G)=P+1 P是流图G中判定节点的数量。
本章小结
1．软件静态测试（或称分析）包含静态分析和评审两大部分。静态分析和评审是从不同的方式和角度来寻找和预防软件的缺陷或故障，消除和减低软件失效的概率。
2．静态分析常采用代码检查、结构分析、质量度量等方法和手段来实现。
3．静态测试方法策略不同，其过程也不同，但目的是一致的。实际测试常用测试方法分人工方式和自动化方式，但多采用混合措施达到测试目的。 4．检查和分析程序代码与规范、标准的一致性，数据流和控制流分析手段是静态测试可操作性的策略与过程。
5．软件评审是静态测试主要方法之一，评审应用人的智能分析能力检查和评估复杂的问题。通过对评审基础、评审内容、评审过程、评审类型、评审者角色和职责的分析，清晰理出评审的脉络，及可操作的过程。评审也用于测试风险分析，风险分析用于指导测试，即具体测试技术和测试强度的选择与确定。
6. 文档检查有多种技术，通过检查强度、形式、必要人力和时间资源以及其目的区分。 4.2.1 等价类划分法简介
等价类划分法（Equivalence Class Testing）典型动态测试技术之一。该方法只根据程序功能规格说明进行测试用例设计并对输入和输出做不同对待与处理。
1．等价区间与等价测试原理
等价区间：若 (A,B) 是命题 f(x) 的一个等价区间，在 (A,B) 中任意取xi 进行测试。如果 f(xi) 错误，那么 f(x) 在整个 (A,B) 区间都将出错；如果 f(xi) 正确，那么 f(x) 在整个(A，B) 区间都将正确
据此原则而设计的测试方法称等价测试。等价类划分法技术基础是等价测试原理。
等价类划分法把程序输入域划分为若干部分，然后从每个部分中选取少量代表性数据作为测试用例（数据），而每一测试数据对于揭露程序中的缺陷或错误均为等效，并作合理假定：采用等价类中的某任意值进行测试，就等同于用该类中所有值的测试，即如某等价类中的一个测试用例检测出了缺陷或错误，那么这一等价类中的其他测试用例也能发现同样问题。反之，如某一等价类中没有一个测试用例能够检测出缺陷或错误，则这类中的其他测试用例也不会检测出问题（除非该类中某些测试用例又属另一个等价类）。 2．等价类划分
测试有两个重要问题：完备性和无冗余。输入域须提供一种形式的完备性，若测试输入域互不相交则可保证形式的无冗余。 （1）等价类划分的任务
划分与确定等价类。为每一等价类建立测试用例建立测试最小数目并提供充分覆盖.
划分等价类前需先从软件功能规格说明书中找出所有输入条件，再为每个输入条件划分两个或多个等价类，形成若干互不相交子集，称等价类。所有等价类的并集就是整个测试输入域。 等价类划分会有两种不同情形：有效等价类和无效等价类。
有效等价类：有效区间的合法输入范围。指对程序功能规格说明是合理、有意义的输入数据所构成的集合。利用有效等价类检验程序是否实现规格说明中所规定的功能。根据具体程序，有效等价类可由一个或多个组成。
无效等价类：无效区间的非法输入范围。指对程序功能规格说明是无意义、不合理的输入数据所构成的集合。利用无效等价类可检查被测对象的功能的实现是否存在不符合程序规格说明要求的情形。根据具体程序，无效等价类可由一个或多个组成。
（2）等价类划分原则
输入条件指定是在一个连续范围的值则划分一个有效等价类及两个无效等价类
输入条件指定的是在一个离散（不连续的）范围的可允许的离散值则划分一个有效等价类及两个无效等价类
输入条件规定了输入值的集合或规定了“必须如何”的条件情形下则可划分一个有效等价类和一个无效等价类
输入条件为一个布尔量的情况下可确定一个有效等价类和一个无效等价类
在规定了输入数据的一组值（假定N个）并要对每一输入值进行分别处理的情形下，可确立N个有效等价类及一个无效等价类
规定了输入数据必须遵守某规则情形下可确立一个有效等价类（符合规则）及若干个无效等价类（违反规则）。
按照数值集合划分。如规格说明规定了输入值的集合，则可确定一个有效等价类（该集合有效值之内）和一个无效等价类（该集合有效值之外） 3．常见等价类划分形式
等价类测试分标准等价类测试和健壮等价类测试。
（3）对等区间划分
对等区间划分是测试用例设计的非常规形式化的方法。它将被测对象的输入、输出划分成一些区间，对一个特定区间的任何值均为等价。 4．用等价类划分法设计测试用例
（1）用等价类划分法设计测试用例的步骤
根据程序说明的规则，定义确立等价类，建立等价类表，列出所有划分出的等价类：
输入条件、有效等价类和无效等价类，从划分出的等价类去设计测试用例。
通常从每个类中设计选取一个测试用例，这些测试用例应具备互斥性。连续写出测试用例，直至有效等价类覆盖确定的规则说明。
预期结果是测试用例的必要组成部分，用例设计必须包含对输入的预期结果。
用等价类划分法设计测试用例的实例。 5．等价类测试结束准则
等价类划分覆盖率=（执行的等价类数量/总共划分确定的等价类数量）×100%
覆盖率决定测试完备性。测试前定义覆盖率作为测试活动是否充分标准及测试执行后判断测试强度是否达到要求的一个指标。 4.2.2 边界值测试 1．边界值分析法（Boundary Value Analysis, BVA） BVA是对等价类划分法的补充，是与等价类划分法紧密结合的黑盒测试，即对输入定义域或等价区间的边界进行测试。这种测试法具较强的发现缺陷或错误的效能，因程序设计可能常会疏忽对“边界”的正确处理，从而造成缺陷或错误。 每一输入域在边界处测试用例包括以下情形: （1）取值在边界上（在可能或有效的情形下） （2）取值恰比边界值略小 （3）取值恰比边界值略大
需注意：边界值须考虑边界值上限邻近值和下限邻近值的数量。具体数量只含不相等的输入值。对邻近等价类重叠数据作为一个边界值看待每个测试数据只有一测试用例与之对应 3．边界值法测试结束准则
边界值覆盖率=（执行的边界值数量/总的边界值数量）×100% 4.3.1 因果图法 1．因果图法的原理
当需关注程序输入条件之间相互关联关系及相互组合时会产生复杂情况。
因为测试要检查程序输入条件组合关系并非容易，即使将所有输入条件都划分为一个个等价类，它们之间复杂的组合情况仍难以用等价类来描述，并进行测试用例设计将很困难。
考虑采用一种适合描述多输入条件且具有组合情形下设计测试用例的方法。
因果图是一种以因果逻辑关系的图示模型来描述可能的输入条件的组合关系，以及可能产生的相应动作（输出结果）的情形的方法。
方法实质：从程序规格说明（需求）的描述中找出因（输入条件）与果（输出结果或程序状态改变）的关系。
2．因果图元素及构造
因果图使用4种简单的逻辑符号，以直线连接左、右节点。左节点表示输入状态（或称原因），右节点表示输出状态（或称结果）。
因果图中用符号形式分别表达软件规格说明中的4种因果关系图 4-5 绘制因果图：将原因和结果用逻辑符号连接得因果图
4.3.2 决策表法
决策表（Decision Table）也称判定表，是分析和表达多逻辑条件下，执行不同操作的一种描述形
式。 可把复杂逻辑关系与多种条件组合情况表达得具体、明确，并体现严密逻辑关系。 软件功能说明通常可用决策表的形式表示，描述所定义的条件（需求）集合、复杂的业务逻辑关系，以及所规定的相应操作（动作）。 1．决策表的构成
决策表由四部分（区域）组成
（1）条件桩：列出问题所有条件，条件先后次序无关紧要。
（2）动作桩：列出问题规定的可能操作，操作排列顺序无约束
（3）条件项：针对条件桩给出的条件列出所有可能取值。
（4）动作项：列出在条件项的各种取值情况下应采取的动作。 2．决策表建立
决策表中将任何一个条件组合的特定取值及相应要执行的动作称为规则，表中贯穿条件项和动作项的一列为一条规则。判定表中列出多少组合条件的取值，就产生多少条规则。 建立决策表步骤如下 （1）确定规则个数。（2）如有n个条件，且每个条件有两种取值（0、1或N、Y），将产生2n种规则。（3）列出所有的条件桩和动作桩。（4）填入条件项。（5）填入动作项。（6）得到初始决策表。（7）化简决策表。对初始决策表合并相似规则，得简化决策表，实际上减少了列数量。 3．应用因果图-决策表法的小结 （1）适于有以下特征的应用程序。
①if-then-else逻辑关系突出。②输入变量之间存在逻辑关系。③涉及输入变量子集的计算。④输入与输出之间存在因果关系。
（2）适于使用决策表设计测试用例的情况。 ①规格说明以决策表形式给出，或较容易转换为决策表。②条件的排列顺序不会也不应影响执行的操作。③规则的排列顺序不会也不应影响执行的操作。④当某一规则的条件已经满足并确定要执行的操作后，不必检验别的规则。⑤如果某一规则的条件要执行多个操作任务，则这些操作的执行顺序无关紧要。
（3）当决策表规模较大时，若有n个判定的条件，在决策表中就会有2n个规则产生，这基于对每个条件取了真、假值。此时，可通过扩展条目决策表（条件使用等价类）、代数化表的方法，将大表“分解”为小表，以减小决策表的规模，有利于简化设计测试用例。 4.5.1 全配对法测试原理
全配对法是基于正交矩阵（Orthogonal Arrays）与组合分析的一项测试技术。 2．正交表的相关概念
正交表是运用组合数学理论构造出的一整套规则的表格。
正交表符号表示：L runs (levels ^ factors) 或 L runs ( levels factors ) 或Ln（t c )
n 为次数（Runs） t 为水平（Level）数 c 为列数，即可能设置的最多因素（Factor）个数例如，L9 (34)，表示要进行9 次操作（试验、测试），最多可考察4 因素（试验/测试项目），每因素有3个水平（如试验项目、测试项目的不同参数值、设置值）
次数：运用在试验中，为操作或运行次数。运用在测试中，为运行多少个测试用例 Runs = Σ(t?1)×c+1
因素：在试验中，将准备考察的变量称为因素，在测试中即为测试项
水平：在试验中，将因素被考察的不同的值称水平，在测试中即为测试项不同用例值 例如，L34（2）、L8（27）、L9（34）、L618（361）分别是四个不同正交表。其中， L34 (2)， Runs=(2?1)×3+1=4 L78 (2)， Runs =(2?1)×7+1=8 L49 (3)， Runs =(3?1)×4+1=9
L618 (361)，Runs =(3?1)×6+(6?1)×1+1=18 4.6.1 逻辑覆盖
动态测试主要方法之一，是以程序内部逻辑结构为基础的测试技术，通过对程序逻辑结构遍历实现程序设计的覆盖
覆盖测试不是目标只是一种手段。覆盖测试目标仍是尽可能发现错误 1．语句覆盖
语句覆盖的测试目标是运行若干测试用例，使被测试的程序的每一条可执行语句至少执行一次。 测试主要集中在测试对象语句上。语句覆盖第一步是将源代码转换为控制流图。语句覆盖可保证程序中每语句都得到执行但并不能全面检验每个语句，即它并非一种充分检验方法。语句覆盖也称C0覆盖，是较弱的覆盖准则。 测试完成准则定义：满足语句覆盖率 语句覆盖率=（被执行语句的数量/所有语句数量）×100%
2．分支（或称判定）覆盖（Branch Coverage） 分支覆盖具有更有效的覆盖准则。要求测试每个判定的结果，如IF、CASE语句中的所有可能。控制流图边是分支覆盖关注点。分支覆盖又称判定覆盖，其覆盖率称C1覆盖
分支覆盖是比语句覆盖强的覆盖测试。通过执行测试用例，使程序每个判定至少都获得一次“真”值和“假”值，即要使程序中每个取“真”分支
和取“假”分支至少均经历一次。
注意：两组测试用例在满足判定覆盖同时还完成语句覆盖，判定覆盖比语句覆盖更仅满足判定覆盖仍无法确定判断内部条件错误。
判定覆盖更为广泛含义：使每个判定获得每种可能的结果至少一次。
测试完成准则定义：每个分支分别对待，对分支的组合没有特别的要求。
3．条件覆盖（Condition Coverage）
如判定是由逻辑运算符连接的几个条件确定的，则测试中需考虑条件复杂性、条件组合时的不同需求和相应测试强度。 （1）分支条件测试
运行被测程序使程序中每个判断的每个条件所有可能值至少执行一次，并每个可能的判断结果也至少执行一次，即要求各个判断的所有可能的条件取值组合至少执行一次。
分支条件测试目标是每个原子条件都需取到“真”、“假”两值。在测试对象源代码中，一个条件可包含多个原子条件。 （2）分支条件组合测试
分支条件组合测试也称分支条件组合覆盖，是比分支条件覆盖更强的覆盖。含义：设计的测试用例需将原子条件所有true-false组合至少执行一遍。如可能所有变量都需构建相应值。
分支条件组合测试包括语句覆盖和分支覆盖。 计算公式如下： 分支条件组合覆盖＝（被评价到的分支条件组合数）/（分支条件组合总数） （3）条件确定测试
条件确定测试可消除组合的限制条件。
对于测试用例，每个原子条件对测试结果都有实际影响。若对于测试结果并不随某个原子条件的改变而改变的测试用例，可以考虑不设计。 4．测试完成准则 与前述内容类似，可通过计算已运行的逻辑值和要求的所有条件的逻辑值之间的百分比作为测试完成准则。
对于比较关注源代码条件复杂程度的逻辑，应达到完全验证。
如代码中没有复杂的条件表达式，分支测试覆盖就足够了。
4.6.2 路径覆盖
任何有关路径分析的测试都可称路径测试。路径覆盖最简描述：路径测试就是从一程序入口开始执行所经历各语句的完整过程。它属基于结构的测试，完成路径测试的理想状况是做到路径完全被覆盖。路径覆盖目的是设计足够多测试用例要求遍历测试对象的所有不同路径 1．路径表达式
逻辑路径测试是一种穷举路径的测试方法。一软件系统通常贯穿程序路径数量很大，即使其每条路径都经测试，仍可能存在缺陷或错误。 原因如下
（1）穷举路径测试无法检查出程序本身是否违反设计规范，即程序本身是否是错误的。
（2）穷举路径测试不能查出因遗漏路径而导致的程序出错。
（3）穷举路径测试发现不了与数据相关的错误情形。
路径测试须遵循以下原则才能达测试目的
（1）保证一个模块中的所有独立路径至少被测试过一次。 （2）所有逻辑值均需测试真（True）、假（False）两种情况。
（3）测试将检查程序的内部数据结构，并保证其结构的有效性；
（4）在取值的上下边界处，即在可操作范围内运行所有的循环。 2．基本路径测试方法
在不能做到覆盖所有路径前提下，如某一程序每个独立路径都被测试过，可以认为程序中每个语句都被检验了，即达到语句覆盖，这种测试即通常所说基本路径测试方法。
从基本集导出的测试用例保证对程序中每条执行语句至少执行一次。 基本路径测试用例设计步骤
（1）画出控制流图 （2）计算圈数 （3）导出测试路径 （4）设计测试用例 本章小结
3．路径能否被全面覆盖是测试重要问题。路径完全覆盖是测试理想状况，但很多情况下不可能实现。路径覆盖目的是设计足够测试用例为测试代表达到覆盖程序所有可能路径。
4．软件失效的严重程度和预期的风险能够指导测试技术的选择和测试强度的确定。
5．应该明确测试对象的类型，根据测试对象选择合适的测试技术。测试对象本身特征预测是测试技术首选问题。行业标准与法规也会要求使用特定测试技术与覆盖准则。
6．测试方法选择策略须确定将要采用的测试策略和测试方法，依此制定详细测试方案。确定测试方法应遵循2 个原则：根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点；选择的策略用尽可能少的测试用例发现尽可能多的错误。 综合使用各种方法可有效提高测试效率及测试覆盖率。
第五章
自动化测试的优势与特点:
可使某些测试任务提高执行的效率;方便进行回归测试;在较少时间内运行更多测试;可执行某些手工测试难以或不可能实现的测试;更好地利用人力资源;具有一致性与可重复性;具有测试脚本的复用性;让软件尽快发布、投入市场;增强软件的可信度;非常重要的测试和涉及范围很广的测试;可较快或实时获得测试结果;测试执行与控制可实现自动化方式;可自动完成对测试用例的调用控制;对测试结果与标准输出需进行大量或精确比对;若测试运行时间只占总体测试时间的10%而需花费90%的总体测试时间进行准备则可考虑实施自动化测试 自动化测试的局限性:
不现实的期望;缺乏自动化测试的经验;期望自动化测试能够发现大量新的缺陷;错觉自动化测试可靠性一定高;错误认为自动化测试无须维护;技术问题的影响因素
6.5 运用Junit 进行组件测试 6.5.1 Junit的基本概要
Junit 是功能强大的开源Java组件测试工具。常用组件测试工具是xUnit系列框架，根据支持的语言不同而分为JUnit（Java），CUnit（C++）、DUnit（Delphi）、NUnit（.NET）、PhpUnit（PHP）等。第一个和最常用是开源的Junit
JUnit本质上是一框架。所谓框架就是确定的一些规则，由开发者制定了一套条条框框，遵循此条条框框的要求编写测试代码。编写测试代码须遵循规则。因此，将JUnit看成一个测试平台更为确切。
实际运用流程：用JUnit编写测试代码 → 编写实现代码 → 运行测试 → 测试失败 → 修改实现代码 → 再运行测试 → 直到测试成功 以Class测试为例说明
（1）JUnit的优势：① 可以使测试代码与产品代码分开② 针对某个类的测试代码通过较少的改动便可应用于另一个类的测试③ 易于集成到测试者的构建过程中，JUnit和Ant结合可实施增量开发④ JUnit公开源代码便于二次开发⑤ 可方便对JUnit进行扩展
（2）编写原则① 简化测试编写，包括测试框架的学习和实际测试组件编写② 使测试组件保持持久性③ 可利用既有测试编写相关的测试 JUnit特征：使用断言方法判断期望值与实际值的差异，并返回Boolean值；测试驱动设备使用共同的初始化变量或者实例；测试包结构便于组织与集成的运行；支持图形交互模式与文本交互的模式。
Junit基本用法：
1．Junit是JAVA中的一个测试包，所有的测试类都继承于TestCase类。
2．测试类中的方法均为public，并且无返回值。它的每一个方法都是一个测试用例。 3．构造一个测试类：
1）继承TestCase类，类名以大写的Test结尾。 2）在继承的同时，重载父类里的setup和tearDown方法。
其中public void setup()主要是做一些初始化的工作，如初始化字段，打开日志记录，重置环境变量，包括数据库的连接等。在这个方法中都需先执行super.Setup(),然后再执行子类的setup()。 junit3会在每个测试运行之前先调用setup()方法，junit4仍然可以在每个测试方法运行之前初始化字段和配置环境，然而完成操作方法不再需要setup()方法，只要用@before注释来指示即可。 而public void tearDown ()与之相反，它是关闭连接，释放内存的，同样先要执行super.tearDown（）;然后再执行子类的tearDown。在junit4中用@after方法来清除。
3）编写自已的测试用例方法。
注意无返回值，且为public，用例名以小写的test开头，若是大写的Test，此用例将不会被执行。所以，如果有多个用例，只想测其中N个时，把余下的用例名改成大写的Test开头即可。
如果用例中有必要抛抛出异常的可以抛出异常 。 4）测试类中的静态方法。
断言函数： assertEquals([参数1],参数2,参数3) 其中参数1是可选的，参数1为测试末通过时的错误提示消息。参数2为期望值，参数3是实际测试某个方法的值。
4．若有些方法耦合性高，如用到Session,request等Tomcat容器中的对象以及特殊的DAO，时，这时用到的测试是高级测试，传送一个模拟的容器对象进来。 第七章
软件系统性功能测试的内容 1．针对一般的软件系统
软件系统性功能测试的范围及内容主要是检测软件各项业务功能是否正确实现。除对GUI 的软件功能测试之外，还将针对软件操作中所涉及的功能实现（1）相关性检查。（2）检查操作的功能是否正确。（3）字符串长度检查。（4）字符类型检查。（5）标点符号检查。（6）检查带出信息
的完整性。（7）信息重复性检查。（8）检查删除功能。（9）检查添加与修改信息的操作是否一致（10）search（搜索）功能检查。（11）检测输入信息的位置。（12）上传/下载文件检查。（13）必填项的检查。（14）回车键检查。 2．针对Web应用软件系统
对Web 应用软件除上述一般软件需检测内容之外，测试还应增加以下内容：（1）链接测试。（2）表单测试。（3）数据校验测试。（4）Cookies测试。（5）Web设计语言的测试。（6）数据库测试。（7）应用系统特定功能测试。 软件系统性功能测试的基本要素
1．功能测试的策略:本章所述功能测试是指在软件系统性测试与验证性测试阶段中所进行的功能性测试。依据软件设计功能要求和指标逐项完成，检验是否达用户要求或软件设计预期功能。软件系统性功能测试策略采用手工、自动混合方式
2．功能测试的流程:功能测试流程：编制测试计划→创建测试用例（脚本）→增强测试用例（脚本）功能→运行测试→分析测试结果。功能测试测试计划是根据被测项目的具体需求及所使用测试工具而制定，完全用于指导测试全过程 3．功能测试的测试用例或测试脚本:功能测试的测试用例或测试脚本设计主要源于软件需求说明及功能说明的相关文档和相关设计说明。应尽可能收集所有项目文档并分解出若干“功能点”，理解“功能点”，编写相应测试用例。各功能点与相应测试用例建立联系，当需求与设计变化时只需跟踪“功能点”是否变化，是否增加了新功能.功能测试的测试脚本可人工设计编写或由自动化测试工具生成 第八章
性能测试目的:验证软件系统是否达到了软件用户需求的软件在某些项的性能指标，同时发现系统所存在的影响性能的瓶颈并期望优化系统.定义：性能测试是主要针对应用系统的性能而进行的测试
性能测试主要内容（1）预期指标的性能测试。（2）独立业务性能测试。（3）组合业务性能测试。（4）疲劳强度性能测试。（5）大数据量性能测试。（6）网络性能测试。（7）服务器性能测试。（8）特殊测试。
性能测试主要类型如下：（1）压力测试。指对系统不断施加压力，通过确定一个系统瓶颈，即不能接受用户请求的性能点，来获得系统能够提供的最大服务级别的测试。例如测试某Web应用站点在大量的负荷下，系统事物响应时间何时会变得不可接受或事务不能被正常执行。2负载测试。通过在被测系统上不断施加压力，直到性能指标达到极限。这种测试能找到系统的处理极限，为系统性能调优提供依据。（3）强度测试。主要检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常资源配置下运行。（4）并发测试。测试多个用户同时访问同一个应用程序、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 （5）大数据量测试。针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一种是与并发测试相结合的极限状态下的综合数据测试。（6）配置测试。主要是通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。如可通过不停调整数据库内存参数进行测试，使之达到一个较好效果。（7）可靠性测试。系统加载一定压力情况下并使系统运行预定的一段时间（数周或数月等），以此检测系统正常运行的能力。
性能调优通常在性能测试之后针对系统性能瓶颈而进行的系统性能提高和修正调整的过程。性能调优依据是性能测试的结果及分析。 1）确定问题（1）针对应用程序代码。（2）数据库配置。（3）操作系统配置。（4）硬件配置。（5）网络问题。（6）听取用户意见。（7）分析响应时间是否随着使用时间的延长而延时加剧（8）是否因CPU使用率低而I/O使用率高而造成性能不佳（9）性能问题是否集中某一类模块中，系统的硬件配置是否够用
2）确定调整目标：通常的目标：提高系统的吞吐量，缩短响应时间，更好地支持开发
3题，测试则要重复前面工作。在测试系统调整过程中需经常分析所做过的工作（进行评估） 分析单元测试和代码调试的区别。
表面上这两项技术很相似，因为它们都包括查看代码、运行程序和处理软件缺陷的过程，但是它们的目标不同：单元测试是为了发现软件缺陷，而代码调试的目标是修复软件缺陷。在分离和查找软件缺陷原因时这两个过程发生交叉。 第十章
测试管理的内容主要有测试组织（机构）的管理、测试需求的管理、测试件的管理、测试用例的管理、测试过程的管理、缺陷跟踪的管理、软件配置管理与测试环境的搭建，以及测试报告管理等。 测试组织管理通常包含测试团队建设和测试组织运行两方面.
组织团队的原则:确定规模，按照测试工作负荷所需最少人数配备测试人员.确定测试团队组成结
构:非独立测试团队/独立测试团队 独立测试好处：（1）独立测试人员无偏见，能找到开发人员未能发现的缺陷。（2）独立测试人员能验证开发人员在设计和实现系统时所做的假设. 独立测试不足：（1）可能会与开发团队缺乏沟通（2）若测试者无必要资源，独立测试可能成为瓶颈 选择合适人选：（1）测试工作的合适人选首先应为一个专业的“悲观主义者”（2）测试人员应具备适度好奇心设计期望将能够引发错误出现的测试用例（3）测试者充分理解软件规格说明书，与开发者讨论“假设分析”的场景，反复深入分析被测系统思考从各角度检查缺陷并明确如何跟踪缺陷
测试专业技能的界定： （1）具有普适性专业技能 （2）具有软件专业技能
（3）熟悉和理解软件（含应用系统）的领域知识，了解系统解决业务、技术或科学问题
（4）具有软件测试系统性的知识与某些专门技能，能从测试角度考虑和处理解决测试问题 测试组织的结构
依据测试项目的性质和测试人员所具有技能，将测试组织分为基于技能的组织或基于项目的测试组织两种形式（1）基于技能的测试组织形式（图10-1）（2）基于项目的测试组织形式（图10-2）
测试组织的管理主要有确定测试组织角色与职责，安排测试任务，估算测试工作量，运用测试心理学和建立完善的沟通机制等
测试人员的角色与职责（1）测试经理/测试主管（2）测试设计师/测试分析员（3）测试自动化人员（4）测试工程师（5）测试管理员
测试人员管理:对测试人员的管理，主要依赖于测试心理学的正确运用。在测试认知方面，测试工作是对他人工作的检验;强调测试的各种原则，强调测试的破坏性思维，强调测试中发散性思维;强调团队各角色统一协作，学会换位思考;提倡学习和运用软件工程知识解释和解决实际测试问题。;建立完善沟通机制，构建统一交流平台，提高沟通效率;在沟通机制方面设立和组织：① 测试中心例会；② 测试交流；③ 通过网络BBS方式
测试计划的内容:计划是指导测试过程的决定性文件，测试计划包括下列内容（1）目的（2）测试策略（3）资源配置（4）任务明确（5）进度安排（6）风险分析（7）停测标准（8）测试用例库（9）组装方式（10）记录手段（11）测试工具（12）回归测试 测试计划的制定
1）制订概要测试计划
定义被测试对象与测试目标；确定测试阶段与测试周期划分，确定测试人员、软硬件资源、测试进度计划；任务分配与责任划分；规定测试方法及测试标准
2）制订详细测试计划
制订具体测试实施计划，规定测试者负责测试内容、测试强度、工作进度。详细测试计划检查测试实际执行情况重要依据；主要内容：绘制计划进度和实际进度对照表；确定测试要点；制定测试策略；确认尚未解决的问题和障碍所在 3）设计测试用例
测试用例包含测试项目、测试步骤、测试完成的标准、测试方式
4）制定测试通过或失败的标准
测试标准指明判断/确认测试满足哪些条件可通过及何时结束
5）制定测试任务安排（明确七项工作）（1）任务2）方法标准（3）输入/输出：（4）时间安排（5）资源（6）风险和假设（7）角色和职责 6）制定应交付的测试工作产品
指明应交付文档、测试代码及测试工具，一般包括测试计划、测试方案、测试用例、测试规程、测试日志、测试总结报告、测试输入与输出数据、测试工具
7）编写测试方案文档
测试方案文档包括以下内容（1）概述（2）被测对象（3）应测试的特性（4）不被测试的特性（5）测试设计综述（6）测试模型（7）测试组网图 测试管理工具:
TestDirector测试管理工具:TD 是一个实施集中、分布式的专业测试项目管理平台.
Rational Test Manager测试管工具:Rational Test Manager对测试计划、测试设计、测试实现、测试执行和结果分析进行全方位的管理，能让测试者随时了解需求变更对于测试用例的影响 Test Manager可处理针对测试计划、执行和结果数据收集，通过创建、维护或引用测试用例来组织测试计划，包括来自外部模块、需求变更请求和表格数据
测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，这种测试方法称为黑盒测试(Black-box Testing)方法。
黑盒测试又称为功能测试、数据驱动测试和基于
规格说明的测试。它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。
黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。 黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。
黑盒测试的特点：
（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。 黑盒测试的具体技术方法：
边界值分析法;等价类划分法;因果图法;决策表法
白盒测试的测试方法有代码检查法、
静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
白盒测试的测试方法中运用最为广泛的是基本路径测试法。
1.程序的控制流图：描述程序控制流的一种图示方法。
2.程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数
3. 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
4. 准备测试用例：确保基本路径集中的每一条路径的执行。
白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构。 白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。
白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。
通常的程序结构覆盖有：语句覆盖;判定覆盖;条件覆盖;判定/条件覆盖;路径覆盖
黑盒测试与白盒测试的比较：图11-1
白盒工具：Logiscope的使用方法与过程。 黑盒工具：QTP的使用方法与过程
LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。 Loadrunner性能测试过程
LoadRunner使用虚拟用户来模拟实际用户对业务系统施加压力。虚拟用户在一个中央控制器的监视下工作。
在做一个测试方案时，要做的第一件事就是创建虚拟用户执行脚本。LoadRunner提供了Virtual User Generator来录制或编辑虚拟用户脚本。 使用Vugen创建虚拟用户执行脚本
A．从菜单中选择运行Virtual User Generator： B．创建一个单协议脚本，选择协议类型为"Tuxedo 7"
C．在弹出的窗口中输入Tuxedo客户机程序的可执行文件名（SimpApp.exe），并选择"Record into Action"为Action。
D．编辑Vuser脚本。在C中做的所有操作都被录了下来，记录到一个脚本文件中，把它存为simpapp。代码中加粗的函数是LoadRunner对TUXEDO函数的二次包装。
E．点击工具栏中的"执行"按钮来执行我们刚才录制的脚本，确保执行无误。 使用控制器来调度虚拟用户
A．从菜单中选择运行Controller：
B．创建一个新的Scenario，选择刚才录制的脚本（simpapp）：
C．点击"Edit Schedule"来编辑压力调度。 D．选择"Runtime settings"来作运行时设置。 E．选择"Start scenario"来开始本次压力测试调度。
测试组件
1.VuGen Load Generator（虚拟用户生成器）用于捕获最终用户业务流程和创建自动性能测试脚本 （也称为虚拟用户脚本）。
2.Controller （控制器）用于组织、驱动、管理和监控负载测试。3.Analysis （分析器）有助于您查看、分析和比较性能结果