第一阶段测试基础知识总结（2）

第六章：
测试过程主要内容;
1.基于项目目标，确定测试策略，选定测试方法，建立里程碑，组织测试资源
2.基于测试计划，明确测试需求，测试对象测试目标及功和性能指标
3.依据测试计划和测试设计，测试人员开展测试的相关活动
软件测试过程度量：
在CMMI 体系的测试过程中定义了四个度量指标
软件测试过程度量在CMMI 体系的测试过程中定义了四个度量指标
− 测试覆盖率：测试覆盖率是指测试用例对需求的覆盖情况
− 测试执行率：实际执行过程中确定已经执行的测试用例比率
− 测试执行通过率：在实际执行的测试用例中，执行结果为“通过”的测试用例比率
− 测试缺陷解决率：某个阶段已关闭缺陷占缺陷总数的比率
测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

第七章：
评审
审查 ：非作者等专家在内的针对特定对象进行检查以发现缺陷的过程，最正式
小组评审： 一种“轻型审查”,可采用审查的指导方针和流程
走查 ：是产品的作者向一组同事说明该产品，希望获得他们的意见以满足自己的需要
同级桌查 ：指除作者以外只有一位评审专家对工作产品进行检查
临时评审：请团队内其他同事帮忙，在短时间内解决一些问题，最不正式
代码检查内容
1. 完整性检查 2一致性检查
3.正确性检查 4.可修改性检查
5.可预测性检查 6.健壮性检查
7.可理解性检查 8.可验证性检查
9. 结构性检查 10.可追溯性检查

11.代码标准符合性检查

代码审查：代码审查组由组长、资深程序员、程序编写者与专职测试人员等，组长不能是被测程序的编写者

桌面检查：程序员自己检查自己所编写的程序

代码走查：代码走查的讨论过程是非正式的

技术评审：最正式的审查类型，具有高度的组织化，要求每一个参与者都接受训练
软件质量特性：功能性(functionality)可靠性(reliability) 可用性(usability) 效率(efficiency) 维护(maintainability) 可移植(portability)
软件质量管理的原则：1.适度原则2.落实原则3.以客户需求为指导原则
软件质量管理方法：1.技术评审2.过程检查3.实施软件测试
第八章：

黑盒测试

• 黑盒测试又称功能测试或数据驱动测试

– 把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性.

– 站在使用软件或程序的角度，从输入数据与输出数据的对应关系进行的测试

– 在软件的接口处进行测试

– 通过导出执行程序所有功能需求的输入条件集，实现功能覆盖，需求覆盖

• 黑盒测试要求

– 每个软件特性或功能必须被一个测试用例或一个被认可的异常所覆盖

– 构造数据类型和数据值的最小集测试

– 测试排斥不规则输入的能力

– 对影响性能的关键模块，应测试模块性能

– 测试用例数量为达到合理测试所需要设计的最少数

– 测试用例要能够指明是否存在某些类型的错误，而不是仅仅指出与特定测试有关的错误是否存在

– 黑盒测试与软件如何实现无关,如实现发生变化,黑盒测试用例仍然可用

– 黑盒测试用例开发可与软件开发同时进行，这样可节省软件开发时间，通过软件的用例就可设计出大部分黑盒测试用例

有效等价类：对于程序规格说明来说，是合理的，有意义的输入数据构成的集合

无效等价类：对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合

等价类划分的方法

• 按区间划分• 按数值划分• 按数值集合划分• 按限制条件或规划划分• 按处理方式划分

构建测试案例

• 为每一个等价规定一个唯一编号。

• 使用测试案例尽可能多的覆盖有效等价类。

• 使用单独的一个测试案例覆盖单独的一个无效等价类。

• 最后，直到所有的有效等价类和无效等价类均被覆盖。

边界值分析方法

– 选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据的方法
因果图分析方法
定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。
用因果图生成测试用例的基本步骤
1. 分析软件规格说明描述：原因、结果、标识符
2. 分析软件规格说明描述中的语义：找出逻辑关系画出因果图。
3. 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，添加必要的约束条件
4. 把因果图转换成判定表
5. 把判定表的每一列拿出来作为依据，设计测试用例
随机测试
• 随机测试指测试输入数据是所有可能输入值中随机选取的，是一种基本的黑盒测试方法。

白盒测试
“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。
（一）白盒测试的特点
1、可以构成测试数据使特定程序部分得到测试2、有一定的充分性度量手段

3、可获得较多工具支持4、通常只用于单元测试
（二）逻辑覆盖的种类
语句覆盖：

语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次判定覆盖

对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。

判定覆盖： 要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。
条件覆盖：不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。

判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。
判定/条件覆盖： 设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。

条件组合： 要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。

路径覆盖： 要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次 。
灰盒测试
“灰盒”测试与白盒测试的区别
– “白盒”测试在测试过程中测试者可以看到被测的源程序，通过
分析程序的内部结构，根据其内部结构设计测试用例
– 理想的“白盒”测试应该使选取的测试用例覆盖所有的路径
• 这是不可能的
• “白盒”测试它不关注测试程序的外部功能
– 灰盒测试无需关心模块内部的实现细节
• 灰盒测试与黑盒测试的区别
– “黑盒”测试是在测试者完全不考虑程序内部结构和内部特征的情况下，根据需求规格说明书设计测试用例和推断的测试结果的正确性
– “黑盒”测试只考虑了程序的输入，以及在该情况下的输出，并没有考虑程序的内部结构。
– 灰盒测试需关心模块与模块之间的交互。
测试用例设计
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期结果，体现测试方案、方法、技术和策略。
特点：正确性 完整性 准确 清晰 可维护 适用 可重用
原则：基于测试需求的原则 基于测试方法的原则 兼顾测试充分性和效率的原则 测试用例的代表性 测试结果的可判性 测试执行的可再现性原则
编写要素：名称和标志 测试追踪 用例说明 测试初始化要求 测试输入 期望测试结果 评价测试结果准则 操作过程 前提和约束 测试终止条件

测试用例设计步骤
1.测试需求分析 2.业务流程分析 3.测试用例设计 4.测试用例评审 5.测试用例更新完善
单元测试
单元测试内容：模块接口 出错处理 局部数据结构 独立路径 边界条件
单元测试要求：
• 各种数据特性覆盖
• 单元的软件特性覆盖
• 语句覆盖达到 100%
• 分支覆盖达到 100%
• 错误处理路径达到 100%
单元测试-静态分析和代码审查
• 使用动态测试技术要准备测试用例，进行结果记录和分析，工作量大，
• 发现错误太多会降低动态测试效率
• 目前的动态测试技术局限性比较大，有相当类型的错误靠动态测试
是难以发现的
• 有些错误在动态测试时无法检查到
• 使用代码审查技术，一旦发现错误，就知道错误的性质和位置，
调试代价较低
• 使用静态分析方法一次就能揭示一批错误，并且随后就可以立即纠正错误
单元测试步骤
第一步：构造测试用例的运行坏境，即确定用例运行的前提条件，明确被测模块或被测单元所需的程序环境，启动测试驱动，设置桩，调用被测模块，设置预期输出条件判断，最后恢复环境。
第二步：设计黑盒测试用例，即接口测试用例。
第三步：设计白盒测试用例，即覆盖测试用例，找出单元内部控制结构和数据使用可能存在的问题。
集成测试
集成测试在软件分级测试中的意义：
在单元测试和系统测试间起到承上启下的作用，既能发现大量单元测试阶段不易发现的接口类错误，又可以保证在进入系统测试前及早发现错误，减少损失(事实上，对系统而言，接口错误是最常见的错误)；能够较容易地测试到系统测试用例难以模拟的特殊异常流程，从纯理论的角度来讲，集成测试能够模拟所有实际情况。
自顶向下组装测试的具体步骤
以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有
桩模块用实际模块替代
依据所选的集成策略以及新模块的选择原则，每次用一个实际单元替换一
个被调用的桩模块，并开发该单元可能需要的桩模块
每集成一个模块的同时立即进行测试
判断系统的组装测试是否完成，若没有完成则转到②循环进行直到集成结束自底向上组装测试的具体步骤
开发一个测试驱动模块，由驱动模块控制最底层模块的并行测试；也可以
把最底层模块组合成实现某个子功能的模块群，由驱动模块控制它进行测
试
用真实模块代替驱动模块，与它已经通过测试的下属模块组装成为完成更
大功能的新模块群。
每集成一个模块的同时立即进行测试
判断程序组装的过程是否已经达到主模块，如果是则代表完成组装结束测
试，否则从(1)开始循环执行直到组装结束
混合渐增式集成测试方法(或称三明治集成方法)
衍变的自顶向下的渐增式测试
自底向上—自顶向下的渐增式测试
回归测试
组装测试
混合渐增式集成测试方法的优缺点
优点：运用一定的技巧，能够减少桩模块和驱动模块的开发
缺点：集成之前中间层不能尽早得到充分的测
确认测试
概念：
• 确认测试是严格遵循有关标准的一种符合性测试，以确定软件产品是否所给定的要求。
• 确认测试是在完成集成测试后，依据确认测试准则，针对需求规格说明行
的测试，以确定所开发的软件系统是否能满足规定的功能和性能要求。
• 确认测试必须有用户参加，或者是以用户为主进行用户应参与设计测试方案，使用用户界面输入测试数据，并分析测试结果，为使用户积极参与测试，有
效使用系统，通常需要对用户进行培训。
有效性测试
– 在模拟的环境下，运用“黑盒”测试的方法，验证被测软件是否满足需求规格说明书列出的需求
– 仔细设计测试计划和测试过程
– 有效性测试两种结果：
• 功能和性能与用户要求一致
• 功能和性能与用户要求有差距
系统测试
过程定义：
制定测试计划 设计测试系统 实施系统测试 执行系统测试 评估系统测试
系统测试需求分析的几条准则
– 测试需求必须是可观测、可评测的行为
– 每个用例或系统的补充需求与测试需求之间不存在一对一的关系
– 需求规格说明书中的每个功能、性能、安全描述等将派生一个或多个测试需
求
– 功能测试需求和性能测试需求是整个系统测试需求中的核心
系统测试需求的核心
– 功能性测试需求
• 功能性测试需求来自测试对象的功能性说明
– 性能测试需求
• 性能测试需求来自测试对象的指定性能行为
• 性能通常被描述为响应时间和资源使用率的某种评测
系统测试的测试类型一般包括：
– 功能测试、性能测试、接口测试
– 强度测试、人机交互界面测试、余量测试
– 可靠性测试、安全性测试、恢复性测试
– 边界测试、数据处理测试、安装性测试
– 容量测试、互操作性测试、敏感性测试
– 标准符合性测试、兼容性测试、中文本地化测试