51testing软件测试培训笔记.docx

第一阶段考试重点归纳
第一章 测试根底
1. 软件测试的目的：证明〔表达软件能够工作〕→ 检测〔发现错误〕→ 预防〔管
理质量〕
2. 测试执行：单元测试〔UT执行〕：一个测试用例的测试执行；
集成测试〔IT执行〕：一个测试用例集的测试执行；
系统测试〔ST执行〕：不同测试阶段的测试执行。
3. 测试用例〔Test Case〕：指对一项特定的软件产品测试任务的描述，表达测试方案、方法、技术和策略。
4. 测试和调试的区别：

测试
调试
目的
找出存在的错误
定位错误，修改程序以修正错误
对象
文档，代码
代码
流程
有特定流程，有方案性
无特定流程，不可设计，无方案性
条件
从条件开始，用预定义过程，有预知结果
从未知条件开始，结束过程不可预计
5. 回归测试的目的：a. 验证错误是否修复；
b. 检测对代码的修改是否引入了新的错误。
6. 软件测试的主要工作：a. 检视代码，评审开发文档；
b. 进行测试设计，写作测试文档〔测试方案、测试方案、测试用例等〕；
c. 执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正；
d. 通过测试度量软件质量。
7. 软件危机的出现主要表现在：
a. 由于缺乏大型软件开发经验和软件开发数据积累，开发工作方案很难制定；
b. 开发早期需求分析不够明确，造成开发后期矛盾集中暴露；
c. 不遵循开发标准，开发文档不完整，软件难以维护；
d. 缺乏严密有效的软件质量检测手段，交付给用户的软件质量差。
8. 软件危机的后果：a. 软件质量不高，很难稳定；
b. 软件工程延期，进度无法控制；
c. 本钱增加，无法控制预算。
9. 软件危机的根源：a. 根据摩尔定律，硬件开展很快，相应对软件系统的期望
越来越高；
b. 软件系统复杂性提高，需多人合作；
c. 软件开发是人的智力活动，无法用已有的产业工程方法来组织管理。
10. 软件生命周期的各个阶段：
方案→ 需求分析→ 设计→ 编码→ 测试→ 运行 → 评价
11. 设计： 概要设计〔HLD〕：在设计阶段把各项需求转换成相应的体系结构，每一局部是功能明确的模块；
详细设计〔LLD〕：对每个模块要完成的工作进行具体的描述。
12. 软件研发三要素：人员、过程、工具
13. 软件工程组人员组成：分析人员、设计人员、开发人员、测试人员、配置管理 人员、SQA〔质量保证人员〕
14. 软件研发流程类型：瀑布模型：无风险控制能力，适合需求变化较小的情况。
螺旋模型：基于风险管理的模型，高风险的优先考虑，对风险管理人员的要求较高。
RVP流程：面向对象的，通用的〔4大阶段，6大工作流，8项迭代〕。特点：
1) 基于风险
2) 用例集驱动

3) 以架构为中心
4) 迭代和增量
IPD流程： 1〕 产品结构重整〔资源重整〕
2〕 公共模块共用
15. 软件研发中几个重要的过程：需求管理、配置管理、缺陷管理、同行评审。
16. 常见的引入缺陷的原因：a. 开发过程缺乏有效的沟通，或者没有进行沟通；
b. 软件复杂度越来越高；
c. 编程中产生错误；
d. 需求不断变更；
e. 工程进度的压力；
f. 不重视开发文档；
g. 软件开发工具本身隐藏的问题。等等……
17. 缺陷类型：遗漏、错误、额外的实现。
第二章 软件质量
1、 软件质量的定义：一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。而质量就是实体基于这些特性满足需求的程度。
2、 软件质量的三个层次：a. 符合需求规格；
b. 符合用户显示需求；
c. 符合用户实际需求。
3、 影响软件质量的因素：流程、技术、组织。
流程：一组活动〔活动是否都是必须的，活动角色之间的关系〕
过程：一组将输入转化为输出的相关联或相互作用的活动。
4、 八项质量管理原那么：a. 以顾客为中心；b. 领导作用；c. 全员参与；
d. 过程方法；e. 管理的系统方法；f. 持续改良；
g. 基于事实的决策方法；h. 互利的供方关系。
5、 八项质量管理原那么的意义：a. 是质量管理的理论根底；
b．用高度概括易于理解的语言所表述的质量管理的最根本，最通用的一般性规律；
c 为组织建立质量管理体系提供了理论依据；
d. 是组织的领导者有效的实施质量管理工作必须遵循的原那么。
6、 CMM1：初始级，Inltial，不可预测并且缺乏控制；
CMM2：可重复级：Repeatable，可重复以前的主要经验；
〔关键过程区域：需求管理；软件工程方案；软件工程跟踪和监督；软件子合同管理；软件质量保证；软件配置管理。〕
CMM3：已定义级：Defined，过程被描述，并得到良好理解；
〔关键过程区域：组织过程定义；组织过程焦点；培训大纲；集成软件管理；软件产品工程；组际协调；同行评审。〕

CMM4：已管理级：Managed，过程被测量并受控；
〔关键过程区域：定量的过程管理；软件质量管理。〕
CMM5：优化级，Optimizing，关注过程改良。
〔关键过程区域：缺陷预防；技术变更管理；过程变更管理。〕
7、 CMM的用途：a. 评估组用来识别组织中的强处和弱处；
b. 评价组用来识别选择不同的业务承包商的风险和监督合同；
c. 管理者用来了解其组织的能力，并了解为了提高其能力成熟度而进行软件过程改良所需进行的活动；
d. 技术人员和过程改良组用来作为指南，指导他们在组织中定义和改良软件过程。
8、 ISO9001和CMM的关系：
相似点：强调管理、过程、标准化和文档化；
不同点：CMM把焦点对准软件；ISO9001的范围包括：硬件、软件、流程性材料和效劳；
两者关系：CMM2级与ISO9001强相关；CMM的每个关键过程域至少按某种解释与ISO9001弱相关。
9、六西格玛的实施方式：Define： 定义----提出问题，确定目标
Measure：测量----收集资料，寻找原因
Analyse：分析----研究资料，确定原因

Improve：改良----优化解决方案
Control：控制----推行控制系统
10、软件质量模型:
功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力。包括：适合性；准确性；互操作性；保密平安性；功能性的依从性。
可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。包括：成熟性；容错性；易恢复性；可靠性的依从性。
易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。包括：易理解性；易学性；易操作性；吸引性；易用性的依从性。
效 率：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。包括：时间特性；资源利用性；效率依从性。
维护性：软件产品可被修改的能力。修改可能包括修正、改良或软件对环境、需求和功能规格说明变化的适应。包括：易分析性；易改变性；稳定性；易测试性；维护性的依从性。
可移植性：软件产品从一种环境迁移到另外一种环境的能力。包括：适应性；易安装性；共存性；易替换性；可移植性的依从性。
11、 SQA与测试的关系：测试从技术的角度来保证软件质量
SQA从流程的角度保障软件质量
组织用来保障SQA和测试的活动
12、 SQA的主要工作范围：· 指导并监督工程按照过程实施；
· 对工程进行度量、分析，增加工程的可视性；
· 审核工作产品，评价工作产品和过程质量目标的复合度；
· 进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，促进过程改良。
13、 度量：对事物属性的量化表示；
软件度量：是指计算机软件中范围广泛的测度，包括对软件系统、构建或生命周期过程具有的某个给定属性的度的一个定量测量。
目的：· 提高软件生产率，缩短产品研发周期，降低研发本钱、维护本钱；
· 提高软件产品质量，提高用户满意度；
· 为组织持续改良提供量化的指标和反应。
14、 软件度量的作用：1) 理解；预测；评估；改良。
2) 分类：规模；工作量；进度；质量
15、如何将度量的知识应用于实际工作中：建立测试工作的度量数据，目的是作为预测和改良的根底
a. 熟悉需求：进度、工作量、规模；
b. 设计用例：工作效率、覆盖率；
c. 执行用例：工作效率、缺陷密度；〕
第三章 测试方法
1、 什么是白盒测试：
· 白盒测试是依据被测软件，分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况；
· 白盒测试是基于程序结构的逻辑驱动测试；
· 白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试。
2、 为什么进行白盒测试：
· 一般在测试前期进行，通过到达一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问、难题能根本得到消除；
· 能保证内部逻辑结构到达一定的覆盖程度，能够给予软件代码质量更大的保证；
· 发现问题后解决问题的本钱较低。
3、 白盒测试的常用技术：
· 静态分析：控制流分析、数据流分析、信息流分析等；
· 动态分析：逻辑覆盖测试〔分支测试、路径测试等〕、程序插装等。
4、 控制流相关概念：程序元素、控制流关系、控制流图、控制流矩阵。〔步骤：5〕
5、 控制流分析能发现的问题：
1) 转向并不存在的标号；
2) 没有用的语句标号；
3) 从程序入口进入后无法到达的语句；
4) 不能到达停机语句的语句。
6、 数据流相关概念：数据的定义；数据的引用。〔步骤：3〕
7、 数据流分析的作用：分析代码中关于数据定义和引用方面的错误；进行代码优
化。〔赋值语句运算效率高〕
8、 信息流分析：输入变量和语句关系；语句和输出变量关系；输入和输出变量管
理。〔步骤：4〕
9、 覆盖率工具的作用：
· 分析被测试代码控制结构决定插装位置；
· 实施插装；
· 将插装代码重新编译；
· 执行被测对象，根据插装的监控哨信息统计覆盖率。
10、 白盒测试的特点：
· 测试人员需要了解软件的实现；
· 可以检测代码中的每条分支和路径；
· 揭示隐藏在代码中的错误；
· 对代码的测试比拟彻底；
· 实现代码结构上的优化；
· 白盒测试投入较大，本钱高；
· 白盒测试不验证规格的正确性。
11、 什么是黑盒测试：
· 黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现；
· 黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块一个函数等。
· 黑盒测试又可以被称为基于规格的测试。
12、 常见的黑盒测试类型：功能性测试；容量测试；负载测试；恢复性测试。
13、 常见的黑盒测试方法：等价类、边界值、因果图、判定表、状态迁移、正 交分解、错误猜想、输入/输出域覆盖、
14、 系统测试的时候，如果没有SRS时，有两类BUG无法发现：1〕需求遗漏；
2〕需求偏差
15、 黑盒测试的优点：
· 对于更大的代码单元来说〔子系统甚至系统级〕比白盒测试效率要高；
· 测试人员不需要了解实现的细节，包括特定的编程语言；
· 从用户的视角进行测试，很容易被大家理解和接受；
· 有助于暴露任何规格不一致或有歧义的问题。
16、 黑盒测试的缺点：
· 没有清晰的和简明的规格，测试用例很难设计；
· 不能控制内部执行路径，会有很多内部程序路径没有被测试到；
· 不能直接针对特定的程序段，这些程序可能非常复杂〔因此可能隐藏更多的问题〕。
17、 动态和静态测试的分类依据在于：被测对象是否运行起来。
18、 手工静态分析——同行评审：正规检视；技术评审；走查。
评审对象：方案、需求文档、设计图、代码等。
19、 自动化静态分析：静态验证；语法分析器；符号执行器。
20、 自动化测试应该考虑的因素：
1) 测试进度要求
2) 人力资源要求
3) 版本稳定度
4) 版本应用情况
5) 可自动化率
6) 版本规模
21、 自动化测试的误区：
1) 自动化不能取代手工测试。
2) 手工测试都做不好，或者经验积累不够，就尝试自动化，很难成功。
3) 自动化只能保证测试执行效率，确保已有的问题不会再发生，自动化 测试不能发现大量新缺陷。
4) 进行了自动化测试的软件不一定就是平安的，质量有保证的。
所以手工测试是自动化测试的一个根底
22、 自动化五大等级：
1) 录制和回放
2) 脚本
3) 自动化框架脚本
4) 数据驱动
5) 关键字驱动
Ø 自动化测试的限制〔板书〕：
· 自动化测试不具备想象力，不能够检查脚本中给定的观察点之外的错误；
· 自动化测试只能提高测试效率，不能提高测试效果，不能发现比人工测试更多的问题；如被测对象不稳定，存在变动性的话不适合开展自动化测试，否那么脚本的编写和维护所消耗的时间可能远大于人工测试；
· 只有手工测试积累到一定程度〔提供更多的观察点〕，才能做好自动化测试。
第四章 测试过程
1、 各阶段测试的目的：
1) 单元测试：检测软件模块对?详细设计说明书?的符合程度
2) 集成测试：检测软件模块对?概要设计说明书?的符合程度
3) 系统测试：通过与?需要规格说明书?作比拟，发现软件与系统定义不符或与之矛盾的地方。
2、 单元、集成、系统测试的比拟：
测试类型
目的
考察范围
评估基准
测试方法
单元测试
消除局部模块的逻辑和功能上的错误和缺陷〔消除单元、模块内部的逻辑和功能上的错误与缺陷〕
单元内部的数据结构、逻辑控制、异常处理等
逻辑覆盖率
大量采用白盒测试方法
集成测试
找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题〔找出与软件架构设计相关的程序结构，单元/子模块间的调用关系，单元/子模块间接口方米那的问题〕
接口和接口数据传递关系、模块组合后的整体功能
接口覆盖率
结合使用白盒与黑盒测试方法，较多采用黑盒方法构造测试用例〔也有说法叫灰盒测试方法〕
系统测试
对整个系统进行一系列的整体、有效性测试〔对系统规格中的功能与性能进行一系列的有效性测试〕
整个系统对需求的符合度
测试用例对需求规格的覆盖率
黑盒测试

3、 回归测试策略：完全重复测试；
选择性重复测试〔覆盖修改法；周边影响法； 指标达成方法；选择重要级别高的测试用例〕
4、 回归测试流程：
1) 在测试策略制定阶段，制定回归测试策略
2) 确定需要回归测试的版本
3) 回归测试版本发布，按照回归测试策略执行回归测试
4) 回归测试通过，关闭缺陷跟踪单〔问题单〕
5) 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再 次提交测试人员回归测试
5、 有用户参与的其他一些测试：验收测试、α测试、β测试
6、 α测试与β测试的比拟：

Alpha测试
Beta测试
比拟
测试环境
开发环境或者模拟实际操作的环境下
实际使用环境
测试人员
可以是终端用户也可以是企业内部的用户
终端用户〔包括潜在用户〕
开发人员是否在场
有开发人员在场，实际上是一种受控的测试。
开发人员通常不在测试现场，测试情况通常不受控。
关注点
Alpha测试关注软件产品的FLURPS〔即功能、局域化、可使用性、可靠性、性能和支持〕，尤其注重产品的界面和特色。
Beta测试着重关注产品的支持性，包括文档、客户培训和支持产品的生产能力。
共同点
1.都希望从实际终端用户的使用角度来对软件的功能和性能进行测试，以发现可能只有终端用户才能发现的错误；
2.都不能由测试人员和程序员完成；

7、 主要的测试文档：测试方案；测试方案；测试用例；测试规程；测试报告；测 试日报
8、 验证与确认V&V：验证〔VERIFICATION〕强调过程；确认〔VALIDATION〕强调
结果。
9、 V&V模型优点： · 实现了测试设计和测试执行相别离；
· 揭示了软件测试活动分层和分阶段的本质特性：测试执行的顺序与开发活动相反

10、 V&V模型：

系统测试执行
集成测试执行
单元测试执行
代码审查
需求分析
SRS评审
SRS基线化
概要设计
HLD评审
HLD基线化
详细设计
LLD评审
LLD基线化
CODE
系统测试方案
系统测试方案设计
系统测试用例设计
集成测试方案
集成测试方案设计
集成测试用例设计
单元测试方案
单元测试方案设计
单元测试用例设计

11、 系统测试分为几个阶段，每个阶段的输入 /输出是什么？

系统测试阶段
输入
输出

系统测试
方案阶段

系统测试方案

设计阶段

系统测试方案
实现阶段

执行阶段

5.系统测试预测试项

集成测试
方案阶段

集成测试方案
设计阶段

集成测试方案
实现阶段

执行阶段

单元测试
方案阶段

单元测试方案
设计阶段

单元测试方案
实现阶段

执行阶段

第五章 单元测试
1、 单元的根本属性：
1) 明确的功能
2) 可定义的规格
3) 与其他单元接口的清晰划分
2、 单元测试的目的：
在于发现各模块内部可能存在的各种错误，主要是基于白盒测试。
a) 验证代码是与设计相符合的；
b) 发现设计和需求中存在的错误；
c) 发现在编码过程中引入的错误。〔和设计不相符或和设计相符，但是由于
编码疏漏引起〕
3、 单元测试关注的重点：
出错处理表达软件的成熟性和容错性
、单元接口、局部数据结构、独立路径、边界条件
4、 单元测试的主要关注点：
1) 参数的属性、顺序、个数是否与LLD一致
2) 不能修改只做输入用的形参，否那么可能导致数据的错误修改
3) 约束条件是否通过形参来传送
5、 驱动和桩的功能：
1) 驱动单元：被测函数的主函数，能接受输入数据，输出实际测试结果
2） 桩单元：用来代替所测单元调用的子单元
6、 单元测试策略：
孤立的测试策略、自顶向下、自底向上的单元测试策略
1) 孤立的测试策略：
· 方法：不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块。每个模块进行独立的单元测试。
· 优点：该方法是最简单，最容易操作的。可以到达高的结构覆盖率。该方法是纯粹的单元测试。
· 缺点：桩函数和驱动函数工作量很大，效率低。
2) 自顶向下的单元测试策略：
· 方法：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块。其次对第二层进行测试，使用上面已测试的单元做驱动模块。如此类推直到测试完所有模块。
· 优点：可以节省驱动函数的开发工作量，测试效率较高。
· 缺点：随着被测单元一个一个被参加，测试过程将变得越来越复杂，并且开发和维护的本钱将增加。
3) 自底向上的单元测试策略：
· 方法：先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模
块的模块做驱动模块。然后再对上面一层做单元测试，用下面已被
测试过的模块做桩模块。以此类推，直到测试完所有模块。
· 优点：可以节省桩函数的开发工作量，测试效率较高。
· 缺点：不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产
生很大的影响。
5、 单元测试的四个阶段：· 测试方案：完成单元测试方案；
· 测试设计：完成单元测试方案；
· 测试实现：完成单元测试用例、单元测试规程、单元测试脚本及数据文件；
· 测试执行：执行单元测试用例，修改发现的问题并进行回归测试，提交单元测试报告。
² 单元测试：桩&驱动举例：
无论是单元测试还是集成测试都涉及到以下三个函数：
主控函数：int ctrl(int x, int y)
加法函数：int add(int x, int y)
减法函数：int sub(int x, int y)
注意：进行单元测试时，设计用例时依据的是LLD；进行集成测试时，设计测试用例依据的是HLD。下面给出来的是需要测试的实际的代码。

34

int ctrl(int x, int y)
{
int temp=0;
if(x>=y)
temp=add(x, y);
else
temp=sub(x, y);
return temp;
}
int add(int x, int y)
{
return(x+y);
}

int sub(int x, int y)
{
return(x-y);
}

² 自顶向下单元测试策略
不同测试步骤中的驱动可以写到一起，也可以分开写，这里是写到一起了。

ü 测试ctrl函数
需要写一个驱动和两个桩。
Ø 驱动函数
void driver()
{
int ret=0;
ret=ctrl(2,1); //x>y
if(ret==3)
printf(“testcase JISUAN_UT_CTRL_001 pass〞);
else
printf(“testcase JISUAN_UT_CTRL_001 fail〞);

ret=ctrl(11); //x=y
if(ret==2)
printf(“testcase JISUAN_UT_CTRL_002 pass〞);
else
printf(“testcase JISUAN_UT_CTRL_002 fail〞);

ret=ctrl(1,2); //xt x, int y)
{
if(x==2 && y==1)
return 3;
if(x==1 && y==1)
return 2;
return 999999;
}

int stub_sub(int x, int y)
{
if(x==1 && y==2)
return -1;
return 999999;
}

Ø 修改代码
为了让桩能表达在测试过程中，需要修改ctrl函数：
int ctrl(int x, int y)
{
int temp=0;
if(x>=y)
temp=stub_add(x, y);
else
temp=stub_sub(x, y);
return temp;
}
ü 测试add函数

Ø 驱动函数
同测试ctrl函数时的驱动
Ø 桩函数
同测试ctrl函数时sub函数对应的桩

Ø 修改代码
int ctrl(int x, int y)
{ int temp=0;
if(x>=y)
{
temp=add(x, y);
if(x==2 && y==1 && temp==3)
printf(“testcase JISUAN_UT_ADD_001 pass〞);
else
printf(“testcase JISUAN_UT_ADD_001 fail〞);
if(x==1 && y==1 && temp==2)
printf(“testcase JISUAN_UT_ADD_002 pass〞);
else
printf(“testcase JISUAN_UT_ADD_002 fail〞);
}
else
temp=stub_sub(x, y);
return temp;}
测试sub函数

Ø 驱动函数
同测试ctrl函数时的驱动
Ø 桩函数
无

Ø 修改代码
int ctrl(int x, int y)
{
int temp=0;
if(x>=y)
temp=add(x, y);
else
{ temp=sub(x, y);
if(x==1&&y==2 && temp==-1)
printf(“testcase JISUAN_UT_SUB_001 pass〞);
else
printf(“testcase JISUAN_UT_SUB_001 fail〞);
}return temp; }
第六章 集成测试
1. 集成测试的目的：确保各组件组合在一起后能够按照既定意图写作运行，并确保增量的行为正确〔属于灰盒测试〕
1) 验证接口是否与设计相符
2) 发现设计和需求中存在的错误
2. 集成测试关注的重点：单元间的接口、集成后的功能
3. 集成测试的层次：模块内集成、子系统内集成、子系统间集成
4. 集成测试策略：
1) 大爆炸集成
2) 自顶向下集成
3) 自底向上集成
4) 三明治〔混合式〕集成
重要
5) 基干集成
6) 分层集成
7) 基于功能的集成
8) 基于消息的集成
实际中应用较多
9) 基于进度的集成
10) 基于风险的集成
5. 各种集成测试策略的优缺点：

优点
缺点
适用范围
大爆炸集成

2.可并行工作，人力、物力资源利用率较高

1.维护型工程〔增强型〕
2.每个函数都经过了充分单元测试的小规模系统〔特别是接口函数〕
自顶向下

2.选用按深度方向组装的方式，可首先实现和验证一个完整的软件功能
3.功能可行性较早得到证实〔带来信心〕
4.最多只需一个驱动，减少驱动开发费用

4.产品控制组件具有较大的技术风险，需要尽早被验证

自底向上

2.对高层的验证被推迟到了最后，设计上的错误不能被及时发现
1.底层接口比拟稳定、变动较少的产品

三明治集成
集合了自顶向下和自底向上策略的优点
中间层在被集成前测试不充分
大局部软件开发工程
基干集成
具有三明治集成的优点

大型复杂工程
基于功能集成/基于消息集成
1.可尽快看到关键功能的实现，并验证正确性

1.对有些接口测试不充分，会丧失许多接口错误
试

基于进度集成

1.许多接口要到后期才能验证，无法发现有效的接口问题

3.由于进度，组件很不稳定且会不断变动，导致测试的重复和浪费
进度优先级高于质量的工程
基于风险集成
最具有风险的组件最早进行验证，有助于系统的快速稳定
需要对各组件的风险有一个清晰的分析

第七章 系统测试
1. 系统测试目的：
1) 通过与需求做比拟，发现与系统定义不符合或与之矛盾的地方
2) 系统测试的用例应根据需求分析说明书来设计，并在实际使用环境下运行
2. 系统测试对象
1) 软硬件集合在一起的系统
2) 验证时应尽可能模拟实际的运行环境与条件
3. 系统测试常用类型：功能、性能、压力、容量、平安性、GUI、可用性、安装、配置、异常〔恢复性〕、备份、健壮性、文档、在线帮助、网络、稳定性测试
4. 功能测试：
1) 概念：根据产品的SRS和测试需求列表，验证产品的功能实现是否符合产品的需求规格
2) 目标：为了发现以下几类错误
a) 是否有不正确或遗漏了的功能
b) 功能实现是否满足用户需求和系统设计的隐藏需求
c) 输入能否正确接受？能否正确输出结果？
5. 性能测试：
1) 概念：用来测试软件在集成系统中的运行性能
2) 目标：度量系统相对于预定义目标的差距
3) 工具：LoadRunner、WebLoad、SilkPerformer
4) 重要性：a) 性能是质量的重要组成局部
b) 给用户树立良好形象
c) 节省本钱的重要手段
6. 性能测试的关键：有效的协调、正确的模型、瓶颈的定位、合理的建议
7. 性能需求五大特性：需求行、代表性、完整性、可测试性、可用性
8. 压力测试：关注稳定性和破坏性
1) 目的：调查系统在其资源超负荷的情况下的表现
2) 目标：通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力，主要验证系统的可靠性。
9. 容量测试：
1) 目的：使系统承受超额的数据容量来发现它是否能够正确处理
2) 关注点：a) 整体的业务流量〔一般关注静态容量〕
b) 数据库的容量
c) 最大文件数目
d) 最大事务数
10. 平安性测试：口令认证、加解密技术、权限管理、平安日志
11. GUI测试：
1) 关注点：界面实现与界面设计的吻合情况、确认界面处理的正确性
2) 对象：简单界面元素、组合类界面元素、完整界面〔窗口〕
3) 内容：外观、界面元素行为、布局、友好功能
12. 可用性测试：关注点：
1) 过分复杂的功能或指令
2) 困难的安装过程
3) 错误信息过于简单
4) 用户被迫去记住太多的信息
5) 语法、格式和定义不一致
13. 配置测试：
概念：测试系统在各种软硬件配置、不同的参数配置下系统具有的功能和性能
目标：验证全部配置的可操作性和有效性，特别需要对最大配置、最小配置或特殊配置进行测试
14. 异常测试：
概念：又叫系统容错和可恢复性测试，通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态，到达检验系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段。
容错处理：系统自动处理、人工干预处理
系统可靠性指标：平均失效时间间隔〔MTBF〕、平均恢复时间〔MTTR〕
系统可靠性设计技术：
1) 避开错误
2) 容错技术：结构冗余〔动、静态〕、信息冗余、时间冗余、硬件冗余、附加冗余技术
15. 健壮性测试：Robustness Testing
用于测试系统在出现故障时，是否能够自动恢复或忽略故障继续运行
16. 网络测试：
概念：在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。
内容：考察系统的处理能力、系统兼容性、系统稳定可靠性及用户使用等方面。
1) 一致性测试：检测系统与协议标准符合程度
2) 性能测试：检测协议实体或系统的性能指标
3) 互操作性测试：
4) 巩固性测试：检测协议实体或系统在各种恶劣环境下运行的能力
17. 系统稳定性测试：
目的是评价系统在一定负荷情况下、长时间的运行情况。

第八章 测试覆盖率
1. 覆盖率概念：
· 覆盖率是用来度量测试完整性的一个手段。覆盖率是测试技术有效性的一个度量。覆盖率=〔至少被执行一次的item数〕/item的总数；
· 覆盖率大体可以划分为两大类：逻辑覆盖和功能覆盖；
· 测试用例设计不能一味追求覆盖率，因为测试本钱虽覆盖率的增加而增加。
2. 逻辑覆盖主要类型语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、路径覆盖。
3. 语句覆盖率：〔Statement Coverage〕，在测试时运行被测程序后，程序中被执行到的可执行语句的比率；
语句覆盖率 = 〔至少被执行一次的语句数量〕/〔可执行的语句总数〕
4. 分支覆盖率：〔Branch Coverage〕也叫判定覆盖〔Decision Coverage〕，它的含义是：在测试时运行被测程序后，程序中所有判断语句的取真分支和取假分支被执行到的比率；
判定覆盖率=〔判定结果被评价的次数〕/〔判定结果的总数〕
5. 条件覆盖率：〔Condition Coverage〕的含义是，在测试时运行被测程序后，所有判断语句中每个条件的可能取值〔真值和假值〕出现过的比率；
条件覆盖率=〔条件操作数值至少被评价一次的数量〕/〔条件操作数值的总数〕
6. 分支-条件覆盖率：〔Branch Condition Coverage〕也叫判定条件覆盖〔Decision Condition Coverage〕，它的含义是，在测试时运行被测程序后，所有判断语句中每个条件的所有可能值〔为真为假〕和每个判断本身的判定结果〔为真为假〕出现的比率；
分支条件覆盖率=〔条件操作树枝或判定结果至少被评价一次的数量〕/〔条件操作数值总数+判定结果总数〕
7. 路径覆盖率：〔Path Coverage〕的含义是，在测试时运行被测程序后，程序中所有可能的路径被执行过的比率；
路径覆盖率=〔至少被执行到一次的路径数〕/〔总的路径数〕
8. 其他覆盖率：功能覆盖率；面向对象的覆盖率；函数覆盖；指令块覆盖；判定路径覆盖。
第九章 测试用例举例
测试用例编号
BOSS_ ST_ MARKETING_NEW_01P
重要级别
高〔还有“较高、中、较低、低〞几个等级〕
测试工程
新增营销记录
测试标题
新增10元的营销记录
用例类型　
根本领件〔对应还有“备选事件〞、“异常事件〞〕
用例设计者
songfun　
设计日期　
2005-04-2