1. 重要
1. 软件测试的正面性观点【验证软件正常工作】
软件测试就是为程序能够按预期设想那样运行而建立足够的信心
【软件测试是一系列活动已评价一个程序或系统的特性或能力是否达到预期的结果】
测试是为了验证软件是否符合用户需求，即验证软件产品是够能正常工作
2. 软件测试的反面性观点【测试是为了证明成粗有错误】 测试是为了发现错误而执行的一个程序或者系统的过程
3. IEEE 的软件测试定义
使用人工或自动手段来运行或测试某个系统的过程，其目的是在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别
4. 什么是“验证
“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性
5. 什么是“有效性确认”
“有效性确认”是确认所开发的软件是否满足用户真正需求的活动
[软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体]
6. 软件测试和软件开发的关系
2. 次重要
1. 为什么要进行软件测试 1.软件总存在缺陷
2.软件中存在的缺陷给我们带来的算是是巨大的
3.测试所有工程学科的基本组成单元，自然也是软件开发的重要组成部分。
4.软件人员水平越高，找出问题的时间越早，软件越容易更正，产品发布后越稳定
2. 软件测试的其它观点
风险的观点：软件测试就是对风险的不断评估，引导软件开发的工，进而将最终发布的软件所存在的风险降到最低
经济的观点：以最小的代价获得最高的软件产品质量
第2章
1. 重要
1. ISO 8492对质量的定义
质量是产品或服务多满足明示或暗示需求能力的固有特性和特征的集合 2. IEEE对软件质量的定义
软件产品满足规定的和隐含的于需求能力有关的全部特性和特征 3. McCall软件质量模型
4. IEEE (1983) 729 软件缺陷一个标准的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 5. 软件缺陷的产生原因
1.技术问题（算法语法错误等） 2.团队合作（误解） 3.软件本省（文档错误，用户适用场合等） 6. 软件缺陷构成
其他, 6%代码, 15%规格说明书,54%设计, 25%规格说明书缺陷最多 7. 什么是软件评审及其分类
评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。
分类：管理评审、技术评审、文档评审、流程评审
[软件测试包含技术和文档评审，管理评审和流程评审则属于软件质量保证的组织和过程管理的活动内容] 8. 什么是软件质量保证
软件质量保证是通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查、跟踪以获取有用信息，形成分析结果以指导软件过程。 9. 软件测试的分类
2. 次重要
1. 什么是产品质量
是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量.
质量模型: McCall 模型, Boehm 模型, ISO 9126 模型 2. 什么是过程质量
软件能力成熟度模型 CMM 国际标准过程模型 ISO 9000
软件过程改进和能力决断 SPICE
3. ISO 9126软件内部/外部质量
4. 软件缺陷的主要类型/现象 1.功能、特性没有实现或部分实现 2. 设计不合理，存在缺陷 3. 实际结果和预期结果不一致
4.运行出错，包括运行中断、系统崩溃、界面混乱 5. 数据结果不正确、精度不够
6. 用户不能接受的其他问题，如存取时间过长、界面不美观
5. SQA与软件测试有什么关系和区别
SQA 是管理工作、审查对象是流程、强调以预防为主 测试是技术工作、测试对象是产品、主要是以事后检查 SQA指导测试、监控测试 测试为SQA提供依据
第3章
1. 重要
1. 什么是静态的和动态的测试
静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等
动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。 2. 什么是自动测试和手工测试
3. 什么是黑盒和白盒测试
白盒：已知程序的内部工作过程 黑盒:完全不考虑程序内部结构和内部特性 4. 什么是主动测试和被动测试
主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果
被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据.
5. 什么是形式化方法 形式化方法实际上就是基于数学的方法来描述目标软件系统属性的一种技术
6. 什么是基于模型的软件测试
基于模型的测试（Model-based testing，MBT）是利用模型来生成相应的测试用例，然后根据实际结果和原先预想的结果的差异来测试系统 先从概念上形成模型，然后试图用数学的方法来描述这个模型，形成仿真模型，完成所需的测试
7. 语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖的概念，以及测试用例的设计。
语句：覆盖每个可执行语句
判定：每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被
满足【又称为分支覆盖】 条件：每个判断中每个条件的可能取值至少满足一次。（不考虑通过的路径） 判定条件：判断条件中的所有条件可能取值至少执行一次，同时，所有判断
的可能结果至少执行一次【假如两个判断，每个判断2个条件，则需要2个测试用例，即T1T2T3T4 F1F2F3F4】p34
条件组合：每个条件的所有可能至少出现一次，并且每个判断本身的判定结
果也至少出现一次。【需要4个，即T1T2 T1F2 F1T2 F1F2 T3T4...,然后覆盖这8个组合，即T1T2T3T4,T1F2T3F4,F1T2F3T4,F1F2F3F4】p35 8. 基本路径测试的概念
在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。 9. 依据代码绘制程序控制流图 10. 计算流图的圈复杂度M-N+2
11. 确定线性独立路径的基本集合P37
独立路径： 至少引入一系列新的处理语句或条件的任何路径
由基本集导出的测试用例，保证每行代码语句至少被执行一次 ；基本集合不一定唯一
12. 等价类划分法、边界值分析法、判定表方法的概念，以及测试用例的设计
ONE. 有效等价类 无效等价类
1.格式 **位数字 含有非数字字符
小于**位。。。。。。
2.范围 []（）（][) 小于0 大于 测试用例 输入数据 覆盖等价类 1 ******* 2 *****
针对Test函数按照基本路径测试方法设计测试用例。
int Test(int i_count,int i_flag) {
1 int i_temp=0; 2while(i_count>0){ 3if(0==i_flag){ 4 i_temp=i_count+100; break; }else{ 5 if(1==i_flag) { 6 i_temp=i_temp+10; }else{ 7 i_temp=i_temp+20; } } 8 i_count--;
} 9return i_temp; }
先画程序流程图（流程控制图），然后计算环路复杂度，环路复杂度为G，则找出G条基本路径。
TWO.判定表：条件： 动作： 然后画表格，N个条件2^N列 THREE.边界值分析：
范围：1》输入条件规定了值得范围，则取刚刚达到这个范围的边界值和刚刚超过边界的值（最大值、比最大值大一、最小值、比最小值小一）
2》规定了值的个数，则用最大个数、比最大个数大一、最小个数、比最小个数小一
3》给出的输入域或者输出域是有序集合（有序表、顺序文件），则应选取集合的第一个和最后一个元素作为测试数据
13. 因果图法、正交试验法的概念
因果图法多种输入条件的组合，产生多种结果设计测试用例
正交试验法依据Galois理论，从大量的（实验）数据（测试例）中挑选适量的有代表的点（条件组合）,从而合理地安排实验（测试）的一种科学实验设计方法。L8（2^7）代表8行7列【正交表】
2. 次重要
1. 通过维恩图考察测试
2. 功能图法
功能图由状态迁移图（STD）和逻辑功能模型（ LFM）构成
功能图法是综合运用黑盒方法和白盒方法来设计测试用例，即整体上选用白盒方法——路径覆盖、分支和条件覆盖等，而局部上选用的是黑盒方法——决策表或因果图方法
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例
4. 形式化的具体方法
基于模型的方法，如Z语言、B语言等 代数方法，如OBJ、CLEAR、ASL、ACT等
过程代数方法，如CSP、CCS、ACP、LOTOS、TPCCS等
基于逻辑的方法，如区间时序逻辑、Hoare 逻辑、模态逻辑、时序逻辑、时序代理模型等。 基于网络的方法
5. 形式化验证的一些具体方法
1.有限状态机（FSM）或扩展有限状态机（EFSM）2.SPIN和线性时态语言 3.UML语义转换 4.标准RBAC模型5.扩展的RBAC模型和基于粒计算的RBAC模型 6.符号模型检验 7.BAN逻辑模型
6. 软件测试模型
故障模型 安全漏洞模型 差性能模型 并发故障模型 不良习惯模型 代码国际化模型 易诱骗代码模型
7. 扩展有限状态机方法
EFSM在FSM模型基础上增加了动作和转移的条件，以处理数据流问题，FSM只能处理系统的控制流问题
8. 基于风险的测试
基于风险的测试是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做
9. 模糊测试方法
模糊测试（Fuzz testing）方法，简单的说，就是构造大量的随机数据作为系统的输入，从而检验系统在各种数据情况下是否会出现问题 模糊测试方法可模拟黑客对系统发动攻击测试
10. ALAC测试和随机测试方法
ALAC，是Act-like-a-customer（象客户那样做）的简写，ALAC测试方法是一种基于客户使用产品的知识开发出来的测试方法，它的出发点是著名的Pareto 80/20规律
第4章
1. 重要
1. 用V模型诠释软件测试过程 【v模型不同步，W模型同步】
2. W模型
3. TMM【吸收CMM的精华，基于历史演化的测试过程，业界的最佳实践】
组成：（1）5个别级的一系列测试能力成熟度的定义，每个级别的组成包括到期目标、到期子目标活动、任务和职责等。（2）一套评价模型，包括一个成熟度问卷、评估程序 和团队选拔培训指南。
2. 次重要
1. TMap
TMap (Test Management Approach，测试管理方法)是一种结构化的、基于风险策略的测试方法体系, 目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本。 TMap所定义的测试生命周期由计划和控制、准备、说明、执行和完成等阶段组成【TMap的基石：与软件开发生命周期一致的测试生命周期L，组织O，基础设施和工具I，技术T】 2. TPI基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的
1.4个级别，A最低； 2.度量工具—检查点，发现问题；
3.建议帮助解决问题 3. CTP
关键测试过程（CTP）评估模型主要是一个内容参考模型，一个上下文相关的方法，并能对模型进行裁剪
使用CTP的过程改进，始于对现有测试过程的评估，通过评估以识别过程的强弱，并结合组织的需要提供改进的意见
计划、准备、执行和完善 ；计划和完善主要是管理工作，准备和执行是实践工作
4. STEP
STEP（系统化测试和评估过程）是一个内容参考模型，认定测试是一个生命周期活动，在明确需求后开始直到系统退役。
STEP与CTP比较类似，而不像TMMI和TPI，并不要求改进需要遵循特定的顺序。某些情况下，STEP评估模型可以与TPI成熟度模型结合起来使用 5. 软件测试标准和规范
对软件测试的流程过程化并对每一个过程元素进行明确的界定，形成完整的规范体系。【 角色的确定 进入的准则 输入项 活动过程 输出项 验证与确认 退出的准则 度量】
6. 建立软件测试管理和评判体系
第5章
1. 重要
1. 什么是单元测试【代码完成后，由开发人员完成】 单元测试是对软件基本组成单元进行的测试 2. 单元测试的目标和任务概述
目标: 单元模块被正确编码【出题可能是问哪个不是单元测试】 ✓ 信息能否正确地流入和流出单元；
✓ 在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互
关系不发生错误，也包括全局变量在单元中的处理和影响。 ✓ 在为限制数据加工而设置的边界处，能否正确工作。 ✓ 单元的运行能否做到满足特定的逻辑覆盖。
✓ 单元中发生了错误，其中的出错处理措施是否有效。 任务概述：
1.检查每一条独立执行路径的测试，保证每条语句被至少执行一次【算符错，初值错，精度错】
2.检查局部数据结构完整性【无初值或初始化错，不相容，越界，地址异常，从未使用】 3.模块接口是否正确【参数不一致，全程变量不一致，外部输入输出】
4.检查临界数据处理的正确性【合法非合法数据处理，边界值内合法、外不合法边界数据处理】
5.预见、预设的各种出错处理是否正确有效【输出的信息难以理解，记录册无不对，出错前系统已介入】
3. 静态测试技术【走查【逻辑错误】、审查【缺陷检查表】、评审】 不运行被测试程序，对代码通过检查、阅读进行分析。 4. 什么是驱动程序和桩程序
驱动模块（driver）:对底层或子层模块进行测试所编写的调用这些模块的程序。 桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。
驱动：调用底层模块的程序 桩模块：替代下层模块的程序
JUnit概述
JUnit是一个开源的java测试框架，它是XUnit测试体系架构的一种实现
JUnit是一个开放源代码的Java测试框架，用在编写和运行可重复的的测试上，它是单元测试框架体系xUnit的一个实例，包括如下特性： 用于测试期望结果的断言；用于共享共同测试数据的测试工具；用于方便地组织和运行测试的测试套件
JUnit单元测试框架设计的三个目标：
✓ 简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写 ✓ 使测试单元保持持久性
✓ 可以利用既有的测试来编写相关的测试
JUnit的版本：
JUnit以jar包形式提供
2. 次重要
1. 单元测试常用工具简介
Junit、Junit+Ant构建自动的单元测试、CheckStyle（源程序是否与代码规范相符）/PMD（检查java源文件中潜在问题）与FindBug（不检查java源文件，查找java bytecode中的潜在bug）的使用、SourceMonitor（检测代码复杂度）
第6章
1. 重要
1. 什么是集成测试和系统测试
集成测试：将已分别通过测试的单元按设计要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题 系统测试：（经过集成测试之后，各模块间接口存在的问题基本已消除，测试开始进入系统测试） 一般由若干个不同的测试组成，目的是充分运行系统，验证整个系统是否满足非佛那个能行的质量需求 2. 集成测试的模式 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。
3. 自顶向下和自底向上集成方法
自顶向下：从主控模块（“主程序”）开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在组长过程中，可以使用深度优先策略（先序遍历）和或宽度优先策略（层次遍历）。【优点：无需测试驱动程序，早期发现上层模块接口的错误】
【缺点：需要桩程序，底层模块错误发现较晚，在早期不能充分展开人力】 自底向上：从“原子”模块（即在软件结构最底层的模块）开始集成以进行测试。
【混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用“自底向上”法】
4. 什么是功能测试
根据产品规格说明书，来检验被测试的系统是否满足各方面功能的使用要求
5. 什么是回归测试 回归测试的目的 ：所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；不影响软件原有功能的正确性。 6. 性能测试、压力测试、容量测试、安全性测试、可靠性测试、容✓ ✓
✓
✓ ✓
错性测试的概念【非功能测试】 性能测试通过测试以确定系统运行时的性能表现，如得到运行速度、响应时间、占有系统资源等系统数据。【重复使用率较高，重点在于前期数据的设计与后期数据的分析】 压力测试(Stress test)，也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。[本质破坏] 【并发性能测试（重点）：即逐渐增加并发虚拟用户数负载，直到系统的瓶颈或者不能接受的性能点[ramp-up测试] 疲劳强度测试:采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务[Flat测试] 大数据量测试 :】 容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。 安全性测试是检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线 测量软件系统的可靠性，可靠性是产品在规定的条件下和规定的时间内完成规定功能的能力【可靠性的三个要素：规定的时间（可靠性体现在运行阶段）、规定的环境条件（不同的环境可靠性不同）、规定的功能（任务和功能有关）】 ✓ 容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面：输入异常数据或进行异常操作，以检验系统的保护性；灾难恢复性测试 7. 负载模拟的概念
并发用户 + 思考时间 + 每次请求的数据量+ 负载模式
并发用户：在同一时间做同一件事情或者同样的操作的用户
思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间 负载模式：就是加载的方式，如是一次建立多个并发连接，还是逐渐增加连接数，还有如随机加载、峰谷交替加载等
8. “flat”测试和ramp-up测试的概念【性能测试的两种负载类型】
“Flat”测试: 对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。【疲劳强度测试（大数据量测试）】
Ramp-up测试: 用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。其优点是，可以看出随着系统负载的改变，测量值是如何改变的，据此选择要运行的flat测试的范围【并发性能测试】
2. 次重要
1. 大棒集成方法【非渐增式测试】
先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试【难确定出错的真正位置，规模较小的应用系统中使用】 2. 三明治集成方法【自两头向中间集成】
它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。【缺点是：在真正集成之前每一个独立的模块没有完全测试过】
改进的三明治，自两头向中间集成，且保证每个模块得到单独的测试，使测试进行得比较彻底 。
3. 峰谷测试【性能测试】
兼有容量规划ramp-up测试和渗入测试的特征,目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。
4. 渗入测试【性能测试】
渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。
建议运行两次测试——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。 5. 性能规划测试 【性能测试】
性能规划类型的测试其目标是找出在特定的环境下，给定应用程序的性能可以达到何种程度。例如，如果要以5秒或更少的响应时间支持8,000个当前用
户，需要多少个服务器？
加载用户以模拟负载状态：最好的方法是模拟高峰时间用户与服务器通信的状况。
如果用户负载状态是在一段时间内逐步达到的,选择ramp-up测试，每隔几秒增加x个用户;如果所有用户是在一个非常短的时间内同时与系统通信，就应该使用flat测试，将所有的用户同时加载到服务器
确定容量的最好方法：结合两种负载类型的优点，并运行一系列的测试。如：首先使用ramp-up测试确定系统支持的用户范围，该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。
6. 基准测试【性能测试】
基准测试的关键是要获得一致的、可再现的结果。【flat运行是获得基准测试数据的理想模式】
将系统置于相同的高负载下，将请求之间间隔时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果会非常精确
flat运行是获得基准测试数据的理想模式
【质量三个纬度：功能、性能、可靠性】
第7章
1. 重要
1. 什么是验收测试
验收测试(Acceptance Test):在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段,也称为交付测试。
2. α测试
α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
3. β测试
β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
4. 用户界面的7个要素，及其概念
符合标准和规范。直观性。一致性。灵活性。舒适性。正确性。实用性。
5. 兼容性测试
软件兼容性测试是指验证软件之间是否正确地交互和共享信息。 向后兼容是指可以使用软件的以前版本。 向前兼容指的是可以使用软件的未来版本。
2. 次重要
1. 验收测试的过程和主要内容
过程：
✓ 制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
✓ 建立测试环境，设计测试用例，并经过评审。 ✓ 准备测试数据，执行测试用例，记录测试结果。
✓ 分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
测试项目通过；
测试项目没有通过，并且不存在变通方法，需要很大的修改； 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进；
测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
✓ 提交测试报告
内容：验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容。 2. 验收标准和注意事项 验收测试完成标准:
✓ 完全执行了验收测试计划中的每个测试用例。
✓ 在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待
下一版本中修改。 ✓ 完成软件验收测试报告。 注意事项：
✓ 必须编写正式的、单独的验收测试报告 ✓ 验收测试必须在实际用户运行环境中进行
✓ 由用户和测试部门共同执行。如公司自开发产品，应由测试人员，产品设计
部门，市场部门等共同进行。 3. 可安装性和可恢复性测试
恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误或重新启动系统。【 恢复测试首先要通过各种手段，让软件强制性地发生故障，然后验证系统是否能尽快恢复。】
4. 文档测试
非代码的文档测试主要检查文档的正确性、完备性和可理解性。
第8章
1. 重要
1. 面向对象层次结构测试重点
对认定的对象的测试：
1.认定的对象是否全面，其名称应该尽量准确、适用，是否问题空间中所涉及到的实例都反映在认定的抽象对象中。
2.认定的对象是否具有多个属性。只有一个属性的对象通常应看作其他对象的属性而不是抽象为独立的对象
3.对认定为同一对象的实例是否有共同的、区别于其他实例的共同属性，是否提供或需要相同的服务，如果服务随着不同的实例而变化，认定的对象就需要分解或利用继承性来分类表示。
4.如果系统没有必要始终保持对象代表的实例信息，提供或者得到关于它的服务，认定的对象也无必要。
对认定的结构的测试 ：
1.处于高层的对象，是否在问题空间中含有不同于下一层对象的特殊可能性，即是否能派生出下一层对象。
2.处于同一低层的对象，是否能抽象出在现实中有意义的更一般的上层对象。 3.对所有认定的对象，是否能在问题空间内向上层抽象出在现实中有意义的对象。 4.高层的对象的特性是否完全体现下层的共性，低层的对象是否有高层特性基础上的特殊性。【高层是父类】
对构造的类层次结构的测试：【着重体现父类和子类间的一般性和特殊性】
1.类层次结构是否涵盖了所有定义的类；
2.是否能体现OOA中所定义的实例关联、消息关联； 3.子类是否具有父类没有的新特性；
4.子类间的共同特性是否完全在父类中得以体现。
类测试的方法【类测试系列的充分性三标准：状态、约束、代码的覆盖率】
通过代码检查或执行测试用例能有效地测试一个类的代码。 3. 面向对象的集成测试
【对象的协作方式决定了程序能做什么，从而决定了这个程序执行的正确性】
2.
主要是两个方面：1.类的线性测试，交互测试。2.类的独立性测试（跨平台）方面测试。
第9章
1. 重要
1. 常用的Web元素功能测试
1.GET、OPTIONS、HEAD、POST、PUT、DELETE、TRACE、CONNECT 2.页面链接；3.设计脚本；4.Web图形；5.表单
2. 数据库并发控制测试
并发主要考虑的几个方面:
数据丢失：A、B对同一数据修改，其中一个对数据库修改失效
不可重复数据：A读取数据后B修改，A无法重现B修改前读的数据 读脏数据：A修改后B读，A撤销（事务回滚）B读到脏数据
2. 次重要
1. Web服务器的安全测试
登录、身份验证；超时、Cookie和Session；输入验证（防止脚本语言)；数据加密、SSL (安全套接字)；SQL注入；XSS（跨站点攻击）；日志文件；目录；
第10章
1. 重要
1. 软件本地化与国际化【国际化是本地化的基础和前提】
软件国际化（SW Internationalization，I18N） I18N是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化传统，使创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。
软件本地化（SW Localization，L10N）
L10N是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。 G11N = I18N + L10N（G11：软件全球化）
全球化
2. 软件本地化基本步骤
建立配置管理体系，跟踪目标语言各个版本的源代码；
创造和维护术语表;
源语言代码和资源文件分离、或提取需要本地化的文本； 把分离或提取的文本、图片等翻译成目标语言；
把翻译好的文本、图片重新检入目标语言的源代码版本； 如果需要，编译目标语言的源代码;
测试翻译后的软件，调整UI 以适应翻译后的文本； 测试本地化后的软件，确保格式和内容都正确；
本地化 翻译
国际化 1) 2) 3) 4) 5) 6) 7) 8)
1) 2) 3) 4) 5) 6)
3. 软件本地化测试
功能性测试，所有基本功能、安装、升级等测试； 翻译测试，包括语言完整性、术语准确性等的检查； 可用性测试，包括用户界面、度量衡和时区等；
兼容性调试，包括硬件兼容性、版本兼容性等测试； 文化、宗教、喜好等适用性测试
手册验证，包括联机文件、在线帮助、PDF文件等测试
2. 次重要
1. 国际化测试方法
1.设计评审和代码审查
2.针对源语言的功能测试，如不同的区域设置、不同的时区显示 3.针对伪翻译（pseudocode，pseudo-translation）版本的测试
第11章
1. 重要【测试自动化项目本质上是软件开发项目】
1.
什么是测试自动化【验证失败继续执行，断言失败，退出当前测试】
测试自动化指“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”
【“一切”：不止测试执行工作，还有管理维护等工作；“可以”：某些无法由系统完成，需要手工处理；即使由系统自动化测试，还是少不了人工干预】
2. 什么是自动化测试【测试工具的使用是自动化测试的主要特征】
自动化测试（automated test）是相对手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。
3. 代码分析的概念
类似于高级编译系统，在工具中定义类/对象/函数/变量等定义规则、语法规则等，在分析时对代码进行语法扫描，找出不符合编码规范的地方。
4. 捕获和回放概念
代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。
5. 脚本技术的概念和分类
直接编写脚本来操作、控制、验证对象：包括对象识别、脚本技术、对运行结果进行比较
6. 线性脚本
线性脚本，是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。
7. 结构化脚本
结构化脚本，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。
8. 数据驱动脚本
数据驱动脚本，将测试输入存储在独立的（数据）文件中，而不是存储在脚本中。
9. 关键字驱动脚本
关键字驱动脚本，是数据驱动脚本的逻辑扩张
2. 次重要
✓ ✓ ✓ ✓
1. 自动比较
静态比较和动态比较 简单比较和复杂比较
敏感性测试比较和健壮性测试比较
比较过滤器：测试数据很多，结果很多时，筛选结果
2. 测试工具的分类
根据测试方法不同，分为白盒测试工具和黑盒测试工具、静态测试工具和动态测试工具等。
根据工具的来源不同，分为开源测试工具（多数是免费的）和商业测试工具、自主开发的测试工具和第三方测试工具等。
根据测试的对象和目的，分为单元测试工具、功能测试工具、性能测试工具、测试管理工具等
3. 功能测试工具介绍
基于GUI功能测试工具主要适合回归测试阶段
4. Web功能测试工具
【主要进行链接检查、HTML检查、Web功能和Web站点安全性等各个方面的测试。】 开源的Web功能测试工具：Selenium、MaxQ、Canoo WebTest、Slimdog、WatiR、WatiN、WatiJ、FIT 商业的Web功能测试工具：Parasoft WebKing、SOAPtest、WebCheck、 客户端测试工具：AutoIT、 商业的:HP QTP
6. 嵌入式测试工具
5.
实时地将测试信息通过网线/串口传到宿主机（Host）上，并实时在线地显示。因此，对源代码的插装和目标机上的信息收集与回传成为嵌入式测试工具要解决的关键问题
7. 性能测试工具： JMeter
能模拟实际用户的操作行为，记录和回放多用户测试中的事务处理过程，自动生成相应的测试脚本 能针对脚本进行修改，增加逻辑控制、完成参数化和数据关联 可以设置不同的应用环境和场景，通过虚拟用户执行相应的测试脚本 通过系统监控工具获得系统性能的相关指标的值
8. 安全性测试工具 9. 缺陷跟踪系统
1) 基于缺陷数据库，可统一数据格式、完成数据校验，而且确保每一个缺陷不会被忽视 2) 基于数据库系统，有利于建立各种动态的数据报表，用于项目状态报告和缺陷数据统计
分析
3) 基于系统可以随时得到最新的缺陷状态，消除沟通上的障碍。
4) 基于系统可以将缺陷和测试用例、需求等关联起来，更深度的分析，有利于产品的质量
改进
10. 测试管理系统
能管理整个测试过程，提高管理的效率和准确性，并提供一个协同合作的环境 测试管理系统以测试用例库、缺陷库为核心
【在需求/功能点、测试用例、缺陷等之间建立必要的映射关系 】
第12章
1. 重要
1. 软件测试团队的责任
测试人员的基本责任：
1) 发现软件程序、系统或产品中所有的问题
2) 尽早发现问题；
3) 督促开发人员尽早地解决程序中的缺陷 测试团队的责任还包括：
4) 帮助项目管理人员制定合理的开发计划； 5) 对问题进行分析、分类总结和跟踪
6) 帮助改善开发流程，提高产品开发效率
7) 督促代码编写具有更好的规范性、易读性、可维护性等
2. 软件测试团队的两种组织模型
1.按技术领域来组建团队的模型【可充分交流，人员来自不同部门，凝聚力差】 2.按产品线来组建团队的模型【适合产品比较多、公司规模比较大】
3. 优秀测试工程师的素质
高度的责任感；非常好的沟通能力、幽默感；技术能力、自信心、耐心；怀疑一切的精神、勤奋精神；洞
察力、适度的好奇心；反向思维和发散思维能力、记忆力；自我学习能力、创新能力等
2. 次重要
✓ ✓ ✓ ✓ ✓ ✓
1. 测试团队的基本构成
QA/测试经理：人员管理，资源调配、测试方法改进等； 实验室管理人员：设置、配置和维护实验室的测试环境
内审员：审查流程，建立测试模板，跟踪缺陷测试报告的质量等； 测试组长：负责项目的管理、测试计划、测试用例、任务安排等；
测试设计人员/资深测试工程师，产品设计规格说明书的审查、测试用例的设计、技术难题的解决、培训和指导、实际测试任务的执行； 一般（初级）测试工程师，执行测试用例和相关的测试任务。
第13章
1. 重要
1. 测试环境概述
测试环境包括设计环境、实施环境和管理环境。 软件环境分为主测试环境和辅测试环境。
主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境 辅助测试环境满足特殊的测试需求：兼容性测试；模拟真实环境测试；横向对比测试
1) 2) 3) 4)
2. 测试环境要素
硬件、网络环境、软件、数据准备、测试工具
3. 实验室建立的评估分析
是否需要长期使用测试设备
是否需要体积庞大的测试工具 是否需要特殊的环境 是否存在安全性问题呢
2. 次重要
1. 虚拟机软件介绍
每个虚拟机由一组虚拟化设备构成，其中每个虚拟机都有对应的虚拟硬件而不会影响高层应用层。通过虚拟机，客户可以再单个计算机上并发运行多个操作系统
【充分利用硬件资源、 节约能源和空间、提升运作效率、 有利于环境的建立和维护】
第14章
1. 重要
1. 什么是测试用例
测试用例是有效地发现软件缺陷的最小测试执行单元，是为了特定目的而设计的测试数据及与之相关的测试规程的一个特定的集合。
2. 测试用例设计书写标准
标志符、测试项、测试环境要求、输入标准、输出标准、测试用例之间的关联
3. 良好测试用例的特征
1) 2) 3) 4) 5) a. b. 6) 7)
可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷
可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果
待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例
测试用例内容清晰、格式一致、分类组织
4. 测试用例设计考虑因素
1) 具有代表性、典型性
2) 寻求系统设计、功能设计的弱点
3) 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分
析怎样使得这样的错误或者异常能够发生 4) 考虑用户实际的诸多使用场景
5. 测试用例设计的基本原则
1) 尽量避免含糊的测试用例
2) 尽量将具有相类似功能的测试用例抽象并归类 3) 尽量避免冗长和复杂的测试用例
6. 什么是测试用例套件
测试套件是根据特定的测试目标和任务而构造的某个测试用例的集合。
【测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，满足测试执行的特定要求。通过测试套件，将服务与同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来】
2. 次重要
1. 测试用例的重要性
测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障
2. 测试用例的作用
有效性、可复用性、易组织性、客观性、可评估性和可管理性、（知识传递）
3. 单个测试用例的质量要求
1) 2) 3) 4) 5) 6)
具有可操作性
具备所需的各项信息 各项信息描述准确、清楚 测试目标针对性强
验证点完备，而且没有太多的验证点 没有太多的操作步骤，例如不超过7步 7) 符合正常业务惯例
4. 整体测试用例的质量要求
覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。
2) 易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的
测试用例执行顺畅。 3) 易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。
1)
易用性和易读性，也有助于易维护性。
4) 粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提
高测试用例的可维护性。
第15章
1. 重要
1. 软件缺陷生命周期 是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。
2. 软件缺陷的严重性和优先级
严重性：衡量缺陷对客户满意度的影响程度（致命的、严重的、一般的、微小的） 优先级(Priority)：指缺陷被修复的紧急程度 缺陷优先级 描述 立即解决(P1级) 缺陷导致系统几乎不能使用或测试不能继续，需立即修复 高优先级(P2级） 缺陷严重，影响测试，需要优先考虑 正常排队(P3级） 缺陷需要正常排队等待修复 低优先级(P4级） 缺陷可以在开发人员有时间的时候被纠正
3. 缺陷描述的基本要求
单一准确 可以再现 完整统一 短小简练 特定条件 补充完善 不做评价
4. 分离和调试软件缺陷之间的区别 【为了划分测试和开发人员的责任】
P335
5. 软件缺陷处理技巧
审阅。可以由测试管理员、项目管理员或其他人来进行，审阅缺陷报告的质量水平； 拒绝。如果审阅者决定需要对一份缺陷报告进行重大修改，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交； 完善。完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告； 分配。分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员； 验证。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题；
重新打开。重新打开一个缺陷，要加注释说明、电话沟通等，否则会引起“打开-修复”多个来回，造成测试人员和开发人员不必要的矛盾 关闭。只有测试人员有关闭缺陷的权限，开发人员没有这个权限。
暂缓。如果每个人都同意将确实存在的缺陷移到以后处理，应该指定下一个版本号或修改的日期。一旦新的版本开
始时，这些暂缓的缺陷应该重新被打开
6. 软件缺陷报告 【任何一个缺陷跟踪系统的核心都是“软件缺陷报告”】
2. 次重要
1. 缺陷的其它属性
缺陷标识，缺陷类型，缺陷产生可能性，缺陷来源，缺陷原因
2. 软件缺陷的详细描述
操作步骤、期望结果、实际结果
【“步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导 。 “期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。是验证缺陷的依据。 “实际结果”实际执行测试的结果，不同于期望结果，从而确认缺陷的存在 】
第16章
1. 重要
1. 什么是软件度量及其作用
软件度量是对软件所包含的各种属性的量化表示 作用：
用数据指标表明验收标准； 监控项目进度和预见风险； 分配资源时进行量化均衡；
预计和控制产品的过程、成本和质量。
2. 软件度量的内容
规模度量：代码行数，功能点和对象点等 复杂度度量：软件结构复杂度指标。
1) 2) 3) 4)
1) 2)
3) 缺陷度量：帮助确定产品缺陷变化的状态，并指示修复缺陷活动所需的工作量，
分析产品缺陷分布的情况
4) 工作量度量 5) 进度度量
6) 生产率度量：代码行数／人·月，测试用例数/人·日；
7) 风险度量：“风险发生的概率”和“风险发生后所带来的损失”
3. 软件度量的过程
1) 识别目标。分析出度量的工作目标和列表，并由管理者审核确认
2) 定义度量过程。定义其收集要素、收集过程、分析、反馈过程、IT支持体系，为具
体的收集活动、分析、反馈活动和 IT设备、工具开发提供指导。
3) 搜集数据。应用IT支持工具进行数据收集工作，并按指定的方式审查和存储。 4) 数据分析与反馈。根据数据收集结果，按照已定义的分析方法进行数据分析，完成
规定格式的图表，进行反馈。
5) 过程改进。根据度量的分析报告，管理者基于度量数据做出决策。
4. 软件测试评估主要有两个目的
1) 量化测试进程，判断测试进行的状态和进度 2) 为测试或质量分析报告生成所需的量化数据，如缺陷清除率、测试覆盖率等。
5. 经典的种子公式
已测试出的种子Bug (s) 已测试出的非种子Bug (n) 所有的种子Bug (S) 全部的非种子Bug (N)
则可以推出程序的总Bug数为：
N = S * n /s其中n是所进行实际测试时发现的Bug总数。如果 n = N, 说明所有的Bug已找出来，说明做的测试足够充分。
这种测试是否充分，可以用一个信心指数来表示，即用一个百分比表示，值越大，说明对产品质量的信心越高，最大值为1。 = 1 ，if n>N C｛
= S/(S-N+1), if n<=N
2. 次重要
1. 软件需求的估算
假设有R个需求，功能需求的数目为F,非功能需求数为N, 则：R= F + N. Q1＝ M/R其中Q1表示需求的确定性，M是所有复审者都有相同解释的需求数目。
功能需求的完整性Q2： Q2＝Fu/(Ni×Ns)
其中Fu是唯一功能需求的数目，Ni是由规格设计说明书定义的输入个数，Ns是被表示的状态的个数。
考虑非功能需求 :
Q3＝Fc/(Fc＋Fnv) Fc是已经确认为正确的需求的个数，Fnv是尚未被确认的需求的个数 2. 基于需求的测试覆盖评估
假定Tx已执行的测试过程数或测试用例数，Rft是测试需求的总数： 已执行的测试覆盖 ＝ Tx／Rft
假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数。
成功的测试覆盖 ＝ Ts／Rft
3. 基于代码的测试覆盖评估
基于代码的测试覆盖通过以下公式计算： 已执行的测试覆盖 ＝ Tc／Tnc
其中Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数，Tnc（Total number of items in the code）是代码中的项目总数。
4. 基于缺陷清除率的估算方法
F为描述软件规模用的功能点；D1为在软件开发过程中发现的所有缺陷数；D2为软件发布后发现的缺陷数；D为发现的总缺陷数。因此，D=D1+D2。 质量=D2/F； 缺陷注入率=D/F； 整体缺陷清除率=D1/D；
5. 软件产品性能评估
【软件产品性能评估其技术性相对比较强，方法的基础是获取与性能表现相关的数据。性能评测一般和测试的执行结合起来做，或者是在执行测试时记录、保存各种数据，然后在评估测试活动中进行计算结果】 主要的性能评测包括：
动态监测；响应时间／吞吐量； 百分比报告；比较报告； 追踪报告
第17章
1. 重要
1. 测试项目管理的特点
1) 2) 3) 4) 5)
软件测试存在较大风险，质量标准定义不准确、任务边界模糊 软件测试项目的变化控制和预警分析要求高。 软件测试管理要求更严格和细致 测试任务的分配难
测试要求人力资源十分稳定
6) 测试人员在待遇、地位可能受到一些不公正的待遇
1) 2) 3) 4) 5) 6) 1)
2)
3) 4)
2. 如何做好测试项目管理
测试项目的管理原则 测试计划先行 建立优先级 依靠团队的能力
建立客观的评价标准
软件测试项目管理者的责任
3. 软件测试项目的过程管理概述
测试项目启动：首先确定项目组长，然后才可以组建整个测试小组，然后参加有关项目计划、分析和设计的会议 测试计划阶段：确定测试范围、测试策略和方法，以及对风险、日程表、资源等进行分析和评估
测试设计阶段：制定测试的技术方案、设计测试用例、选择测试脚本等，并让其他部门审查测试用例 测试执行阶段：建立或设置相关的测试环境，准备测试数据，执行测试用例，报告、分析、和跟踪所发现的软件缺陷
5) 测试结果的审查和分析
4. 影响测试策略的因素
1、要使用的测试技术和工具；2、测试完成的标准；3、资源状况
2. 次重要
1. 测试计划内容
内容主要集中在测试目标和需求说明、测试工作量估算、测试策略、测试资源配置、进度表、测试风险等
2. 不同测试阶段的执行要点
代码审查，确保测试人员参与代码的会审 单元测试一般由程序员自己做 集成测试应尽早进行、持续进行
功能测试：交叉进行，从用户的角度出发，尽量挖掘和模拟各种使用情景（特殊场合或边界条件） 系统测试：方案可行、工具有效、环境正确
获得用户的反馈
3. 测试项目进度的特性及外在关系（数量和质量的双重特性）
进度与质量关系 进度与成本的关系
4. 测试项目的风险管理
5. 软件测试文档的管理
文档的分类管理；文档的格式和模板管理； 文档的一致性管理；文档的存储管理
因篇幅问题不能全部显示，请点此查看更多更全内容