目录
1、知识点总结（1~8章）
第一章 软件工程要点
1、软件三要素？
程序、数据和文档
2、软件分类？
应用软件、中间件、系统软件、支撑软件
3、软件危机的原因？
1）用户的需求不明确
2）缺乏正确的理论指导
3）软件开发规模越来越大
4）软件开发复杂度越来越高
4、消除软件危机的方法
1）对计算机软件有一个正确的认识。
2）充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目
3）推广使用在实践中总结出来的开发软件成功技术和方法
4）开发和使用更好的软件工具
5、软件工程
1）将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件：
2）软件工具为工程方法提供了自动或半自动的软件支撑环境：
3）将软件工程方法和工具综合起来，以达到合理、及时第进行计算机软件开发的目的。
6、软件工程的本质特征
关注：软件工程关注于大型程序的构造
•中心课题：软件工程的中心课题是控制复杂性
•控制和管理：软件经常变化
•工具与环境：开发软件的效率非常重要
•团队精神：和谐地合作是开发软件的关键
•有效支持：软件必须有效地支持它的用户
•创造产品：在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品
7、软件生命周期模型：瀑布模型
1970年温斯顿•罗伊斯（WinstonRoyce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
8、瀑布模型的优缺点
1）优点
•提供了软件开发的基本框架
•为项目提供了按阶段划分的检查点
•当前一阶段完成后，您只需要去关注后续阶段
2）缺点
•在项目各个阶段之间极少有反馈
•线性模型，早期的错误可能要等到后期才能发现，且只有等到全过程的末期才能见到开发成果，增加开发风险
•阶段之间产生大量的文档，增加了管理工作量
3）应用场景
•在开发时间内需求没有或很少变化
•分析设计人员对应用领域很熟悉
•低风险项目（对目标、环境很熟悉）
•用户使用环境很稳定
•用户除提出需求以外，很少参与开发
9、软件生命周期模型：V模型
V模型是在瀑布模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期[
10、软件开发主流技术
软件系统体系结构应用模式大体上分为
•主机终端模式
•文件服务器模式
•C/S模式
•B/S模式
11、C/S与B/S结构
C/S结构的基本原则是将计算机应用任务分解成多个子任务，由多台计算机分工完成，克服了终端/主机结构中主机负担过重，用户界面不友好等缺点，因而得到了广泛的应用。
C/S结构
•两层结构的C/S前端是客户机(通常是PC)；后端是服务器，运行数据库管理系统，提供数据库的查询和管理。
•三层结构的C/S模式是利用中间件将应用分为表示层、业务逻辑层和数据存储层三个不同的处理层次,即客户机、服务器和中间件。
B/S（Browser/Server，浏览器/服务器）模式又称B/S结构
•B/S模式是指在TCP/IP的支持下，以HTTP为传输协议，客户端通过Browser访问Web服务器以及与之相连的后台数据库的技术及体系结构。
B/S的优势
•简化客户端
•简化系统的开发和维护
•用户操作变得简单
•适用于网上信息的发布
12、项目管理
•就是在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。
13、实施软件项目管理的根本目的
•通过对成本、人员、进度、质量、风险等进行分析和管理，使软件项目的整个生命周期都能在有效的控制下，按照预定的成本、进度、质量顺利完成。
14、软件项目管理中存在的误区
1. •项目经理不够专业
2. •项目计划缺乏纲领性
3. •缺乏有效的管理意识
4. •缺乏有效的沟通制度和机制
5. •风险管理意识淡泊
6. •项目干系人的不确定性
7. •缺乏项目团队的合理分工
15、解决软件项目管理中存在的误区的有效策略
1. •项目经理接受系统的项目管理知识培训室非常必要的
2. •计划的制定需要在一定条件的限制和假设之下不断完善
3. •加强项目管理方面的培训并考核
4. •制定有效的沟通制度和沟通机制
5. •掌握项目风险管理所必备的知识
6. •实现干系人的需求和愿望
7. •项目经理应对项目成员的责任进行合理的分配和明示
16、软件配置管理的概念
软件配置管理（以下简称SCM，Software Configuration Management）定义是指在开发过程中各阶段，管理计算机程序演变的学科。即配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科
17、配置管理对软件开发的重要意义
管理人员受益于配置管理
•准备掌握项目的开发进度
•了解项目组成员的工作负荷、工作效率以及工作质量
•减少人员流动所带来的影响
•有效提高过程管理
开发人员和测试人员受益于配置管理
•提交的代码被有效保存
•提高团队的协作效率
•提高修复缺陷的效率
•职责清楚，任务明确
第二章软件测试基础
1、软件测试的原则
1） 测试显示缺陷的存在
测试可以显示缺陷的存在，但不能证明系统不存在缺陷。测试能减少软件中存在未被发现缺陷的可能性。但即使测试没有任何缺陷，也不能证明软件或系统是完全正确的。
2） 穷尽测试是不可能的
除了小型项目进行完全（各种输入和前提条件的组合）的测试是不可能的，通过运用风险分析和不同系统功能的测试优先级来确定测试的关键点，从而代替穷尽测试
3） 测试要尽早介入
在软件或系统开发生命周期中，测试活动应尽可能早的介入并且将关注点放在已经定义的测试目标上
4） 缺陷的集群（80~20原则）
版本发布前进行的测试所发现的大部分缺陷和软件运行失效性是由少数软件模块引起的
5） 杀虫剂悖论原理
采用同样的测试用例多次重复进行测试最后将不能发现新的缺陷，为了克服这个杀虫剂悖论测试用例需要进行定期的评审和修改，同时需要不断地增加新的不同的测试用例来测试软件和系统的不同部分，从而发现潜在的更多缺陷
6） 测试活动依赖于测试背景
针对不同的测试背景进行测试活动也是不同的，对安全关键的软件进行测试与对一般电子商务进行测试是不一样的。
7） 不存在缺陷的谬论
假如系统无法使用或者系统不能完成客户的需求和期望发现和修改缺陷是没有任何意义的。
第三章基于生命周期的软件测试
1、生命周期测试方法意味着测试与软件开发平行
生命周期测试应伴随整个软件开发周期，此时测试的对象不仅仅是程序，需求、功能和设计同样要测试
1. •在软件开发的所有阶段进行测试，被设计用来减少测试成本
2. •测试与开发同步进行，有利于尽早地发现问题，同时缩短项目的开发建设周期
2、生命周期各阶段的测试工作
按照软件生命周期去划分阶段，形成基于生命周期的软件测试
1. 需求阶段
a) 重点是确认定义的需求符合机构的要求
2. 设计和编程阶段
a) 重点是验证设计和程序实现了需求
3. 测试和安装阶段
a) 重点是检查实现的系统符合系统规格说明
4. 维护阶段
a) 系统将重新测试以决定改变的部分和未改变的部分能继续工作
3、基于开发生命周期的测试特点
1. •在软件开发过程中持续的进行测试
2. •在尽可能早的阶段点去介入
3. •需要正式的开发流程来支持
4. •组建专门的测试团队
5. •当软件整体开发活动开始的时候，测试活动就可以开始
4、测试准入/准出条件
1）测试准入条件
−测试合同（或项目计划）；
−软件测试所需的各种文档；
−所提交的被测软件受控；
−软件源代码正确通过编译或汇编；
−最好从一开始就介入到被测软件的开发周期
2）测试准出条件
−按要求完成了合同（或项目计划）所规定的软件测试任务
−实际测试过程遵循了原定的软件测试计划和软件测试说明
−客观、详细地记录了软件测试过程和软件测试中发现的所有问题；
−软件测试的全过程自始至终在控制下进行；
−软件测试中的问题或异常有合理解释或正确有效的处理；
−软件测试工作通过了测试评审；
−全部测试软件、被测软件、测试支持软件和评审结果已纳入配置管理。
5、基于风险的软件测试方法
1、•概念
可定义为事件、危险、威胁或情况等发生的可能性以及由此产生不可预料的后果,即一个潜在的问题
−风险级别由出现不确定事件的可能性和出现后所产生的影响（事件引发的不好的结果，即严重性）两个方面来决定
2、•控制要求
因测试团队需要在时间、成本和质量等各个方面进行平衡和协调，很难达到“零”缺陷的理想测试目标
−由此带来了软件存在着应用上的风险
3、•影响
风险的存在会导致用户等对软件质量或项目成功的信心下降
基于风险的软件测试
1. 评估被测软件的风险，以此决定所采用的测试力度
2. •列出一个风险的列表
3. •对每个风险进行分析和评估，确定风险级别
4. •进行考察每项风险的测试
5. •当风险消失而新的风险出现的时候，调整测试策略
6. 在基于风险的软件测试中，需要解决的主要问题
7. •确定测试的优先级
8. •测试重点的有效选择
9. •有效地配置测试资源
10. •分析和评枯测试的有效性等
11. 要有效地选择测试重点和测试优先级
12. •风险测试将测试活动和测试任务根据风险划分优先等级，将测试资源主要分配在高风险的部分
6、全生命周期中软件测试的最终要求
1. •保证软件系统在全生命周期中每个阶段的正确性，验证在整个软件开发周期中各个阶段的软件质量是否合格
2. •保证最终系统符合用户的要求和需求，验证最终交付给用户的系统是否满足用户需要、符合其需求
3. •用样本测试数据检查系统的行为特性
4. •把尽可能多的问题在产品交给用户之前发现并改正
1、 需求阶段评估被测软件的风险，以此决定所采用的测试力度
•软件测试、验证，确认只有当具备软件需求分析时才有意义
–所有的花费都是值得的
–大部分缺陷将不会进入到设计&编码阶段
•准备风险列表
−确定风险：风险分析、风险检查表
−建立控制目标
−确定有足够的控制力度
•分析测试要素
测试活动
−彻底分析需求的充分性，生成基础测试用例
−澄清和确定哪些需求是可测试的，舍去含糊的、不可测试的需求，建立产品需求和确认需求
2.设计阶段（一）
软件测试、验证、确认只有当具备软件需求分析时才有意义
设计阶段测试任务
设计阶段的测试活动
•在概要设计阶段，测试人员应阐述测试方法和测试评估准则，编写测试计划，成立测试小组，安排具有里程碑的测试日程
•在详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例
设计阶段的评审
•对实际阶段处理的完整性进行正式的评价
设计阶段工具的应用
•在设计阶段使用静态和动态测试工具测试系统的结构
•涉及的检查项目包括：遗漏的情况，错误的逻辑，模块接口的不匹配，数据结构不合理错误的I/O假定，用户界面不充分等
分析测试要素，给测试要素打分
3、编码阶段
在编程阶段完成测试用例开发，对程序进行实际的测试
测试需要解决的首要问题是编码是否和设计一致，其次是
•系统是否可维护
•系统的规格说明是否正确地实现
•编码是否按照既有的标准进行
•是否有充分的测试计划评价可执行的程序
•程序是否提供了足够的文档资料
•程序内部是否有足够的注释等
单元测试完成后，形成下列输出：
在全生命周期软件测试方法中，由于在需求、设计、编码阶段都进行了测试，因此测试阶段的问题相对传统的软件测试中的问题要少一些
在测试阶段要进行第三方的正式确认测试，检验所开发的系统是否能按照用户提出的要求运行
在测试阶段要使得用户能成功地安装一个新的应用系统来进行测试
典型测试类型
•手册与文档测试（易用性）
•一致性测试（授权, 安全性, 性能）
•功能点测试（完整性、正确性、审计，追踪）
•覆盖性的测试（测试的连续性）
•压力测试（服务水平）
•依照预先定义的测试方法
•检查（可维护性）
•灾难性的测试（可携带性）
•功能和回归测试（耦合性）
•操作性的测试（易用性）
8、测试阶段的测试活动
•测试阶段要参考第三方的测试反馈
•测试阶段对成功安装的应用系统所需进行的测试有
–功能测试：运行部分或全部系统，确认用户的需求被满足
–符合性测试：验证软件系统与相应的国际标准或国军标的符合程度
–强度测试：将系统置于强度下进行验收测试，测试系统对极端条件的反应，标识软件的薄弱点，指出系统能够经受的正常的工作量
–性能测试：通过测量响应时间、CPU使用和其它量化的操作特征，评估软件系统的性能指标
–操作测试：在没有开发人员的指导和帮组情况下，由操作人员进行测试，以评估操作命令的完整性和系统是否容易操作
–恢复测试：故意使系统失败，测试人工和自动的恢复过程
测试报告
•有关测试结果的积累数据
•测试任务，测试集合和测试事件的描述
•缺陷分析(严重的缺陷、缺陷类型、是否存在没有发现缺陷以及是何原因导致的)
•测试效果评估
测试期间数据的收集
第四章、 软件测试分类与分级
1、对于软件测试，可以从不同的角度进行分类
1、是否关心内部结构
1.白盒测试
1. 黑盒测试
2. 灰盒测试
2、开发过程级别
1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试
3、是否执行程序
1. 静态测试
2. 动态测试
4、 执行过程是否需要人工干预
2、 手工测试
3、 自动化测试/5
5、 测试实施组织
1、 开发测试
2、 用户测试
3、 第三方测试
2、基于CSCI的软件测试分类
1、功能测试
•功能测试主要对软件需求规格说明中的功能需求进行测试,找出被测软件的实现与需求不一致的地方,确认一致的地方
2、性能测试
3、外部接口和人机交互界面测试
•外部接口和人机交互界面测试主要对平台各个服务域提供的应用编程接口、应用程序接口、外部环境接口以及人机交互界面的符合性和可用性进行测试
4、强度测试
•主要对软件需求规格说明中定义的性能需求进行测试，费事在一定工作负荷和配置条件下，系统的响应时间及处理速度等特性/
•强度测试必须在预先规定的一个时期内，在软件设计能力的极限状态，进而超出此极限状态下，运行软件的所有功能
5、余量测试
•测试程序全部存储量、输入/输出通道及处理时间的余量满足需求规格说明的要求
6、可靠性测试
•可靠性测试是在有使用代表性的环境中，为进行软件可靠性估计而对其进行的功能测试/
7、安全性测试
•安全性测试主要对平台软件配置项的安全性进行测试，包括系统安全评估和系统侵入测试两个部分
8、安全性测试
•对有恢复或重置（RESET）功能的软件，必须验证恢复或重置功能，对每一类导致恢复或重置的情况进行测试
9、本地化测试
•本地化测试的内容，主要对平台软件配置项的本地语言、时间等本地特色的支持能力进行测试，验证软件配置项是否能全面、正确地支持、处理本地特色化要素
10、功能多余物测试
•验证程序中没有附加的软件需求中没有指明的功能及功能边界的不适当。所有输出都应有意义并在软件需求中指明/
11边界测试
•测试程序在输入域（或输出域）、数据结构、状态转换、过程参数、功能界限等的边界或端点情况下运行状态
12、安装性测试
•安装性测试主要对平台软件配置项的可安装性/可卸载性进行测试/
13应用基准测试
•应用基准测试主要对平台软件配置项的综合性能进行测试
软件错误或软件缺陷是软件产品的固有成分，是软件“生来具有”的特征
软件缺陷包括检测缺陷和残留缺陷
一般符合下列5个规则之一，就是软件缺陷
软件未实现产品说明书要求的功能
软件出现了产品说明书指明不应该出现的错误
软件实现了产品说明书未提到的功能
软件未实现产品说明书虽未明确提及但应该实现的目标
软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好
2、软件缺陷带来的风险
1)软件缺陷的定义
1、 •代码错误
2 •数据未被验证
3•操作流程不符合预期
4•安全性无法保证
5. •使用过程复杂
6. •系统无法正常启停
7. •系统文件被破坏
8. •系统性能下降
9. •系统不可恢复
10. •系统无法稳定运行
11. •系统维护复杂/2
2导致软件产生缺陷的原因
需求的不完善定义
•客户——开发者通信失败
•对软件需求的故意偏离
•逻辑设计错误
•编码错误
•不符合文档编制与编码规定
•测试过程不足
•规程错误
•文档编制错误
3）软件缺陷产生的原因
调查研究表明：大多数软件缺陷并不是由于编码造成的，导致大多数软件缺陷产生的最大的原因是需求分析阶段，其次是在软件设计阶段
（1）需求分析是造成软件缺陷出现的最大来源
•软件需求规格说明书描述了系统应该具有的功能和性能。
它是开发流程与测试流程的输入
•在软件开发之初，由于客户——开发者之间的沟通问题，造成需求规格说明的不完善或者是对软件需求的偏离
•在开发过程中因需求规格说明的不全面或经常变更，再加上整个开发小组不能很好的沟通造成设计和编码与需求规格说明之间的不一致等等
（2）设计是缺陷产生的一个主要来源
•设计是软件开发人员规划软件的过程，在这个过程中可能会存在一些逻辑错误
•设计的变化、修改，加上整个开发小组沟通问题，这些就造成了软件缺陷的产生
（3）软件缺陷在编码阶段出现是另一个主要来源
•通常是因代码错误而造成，由于软件复杂、文档不足、进度压力、普通的低级错误或者是因程序员的思维定势而引起
3、缺陷基本信息
| 1 | 缺陷标题 | 8 | 缺陷的类型 |
| 2 | 标题 | 9 | 严重性 |
| 3 | 报告人 | 10 | 优先级 |
| 4 | 报告日期 | 11 | 关键词 |
| 5 | 程序的名称 | 12 | 缺陷描述 |
| 6 | 版本号 | 13 | 重现步骤 |
| 7 | 配置 | 14 | 结果对比 |
4、缺陷的属性
•缺陷标识(Identifier)
−缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识
•缺陷类型(Type)
−缺陷类型是根据缺陷的自然属性划分的缺陷种类。
•缺陷严重程(Severity)
−缺陷严重程度是指因缺陷引起的失效对软件产品的影响程度。
•缺陷优先级(Priority)
−缺陷的优先级指缺陷必须被修复的紧急程度。
•缺陷状态(Status)
−缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
•缺陷起源(Origin)
−缺陷起源指缺陷引起的失效或事件第一次被检测到的阶段。
•缺陷来源(Source)
−缺陷来源指引起缺陷的起因。
•缺陷根源(Root Cause)
5、软件缺陷流程管理的要点
1、–为了保证错误的正确性，需要:
•有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误
•测试步骤是否准确、简洁、可以重复
2、–软件错误的确认并不总是轻而易举的事情
•由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，本地化服务商需要与软件供应商交流并确认
3、–每次对错误的处理都要保留处理信息
•包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等
4、对错误的拒绝不能由程序员单方面决定
•应该由项目经理，测试经理和设计经理共同决定
5、–对错误延期处理不能由本地户服务商决定
•应该由软件供应商决定
6、–错误修复后必须由报告错误的测试人员验证后，确认已修复，才能关闭。
6、软件缺陷度量的主要方法有：
•1、缺陷密度（缺陷在规模上的分布）
缺陷密度=已知缺陷的数量/产品规模
2、缺陷率（缺陷在时间上的分布）
缺陷率=一定时间范围内的缺陷数/错误几率
3、•缺陷清除率
整体缺陷清除率=开发过程中发现的所有缺陷数/发现的总缺陷数
阶段性缺陷清除率=开发阶段清除的缺陷数/产品潜伏的缺陷总数/
7软件缺陷统计是软件分析报告中的重要内容之一
•从统计的角度出发，可以对软件过程的缺陷进行度量
软件功能模块缺陷分布、缺陷严重程度分布、缺陷类型分布、
缺陷率分布、缺陷密度分析、缺陷趋势分布、缺陷注入率/消除率等
8、缺陷报告是软件测试过程中最重要的文档
•是缺陷被修正的唯一方法
•记录了缺陷发生的环境，如各种资源的配置情况，缺陷的再现步骤以及缺陷性质的说明
•记录着缺陷的处理过程和状态
•缺陷的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程
报告缺陷的基本原则
•尽快报告缺陷
•有效描述缺陷
–短小：只解释事实和演示、描述缺陷必需的细节
–单一：每一个报告中针对一个缺陷
–步骤清晰：要清楚地描述出缺陷的发生场景，包括前置条件和操作的详细步骤
–使用IT业界惯用的表达术语和表达方式
–明确指明错误类型
•报告缺陷时不做任何评价
•确保缺陷可以重现
第六章软件测试过程及其管理
1、W模型特点
•增加了软件各开发阶段中应同步进行的验证（verification）和确认（validation）活动。
•基于“尽早地和不断地进行软件测试”的原则。
•串行活动，无法更好适应变更：把软件的开发视为需求、设计、编码等一系列的串行活动，无法解决需求变更等变更调整。
•线性的前后关系，无法有效支持迭代：开发和测试保持线性的前后关系，上一阶段完成才能开始下一阶段，无法有效，快速支持产品迭代。
•测试完整性不足：顺序模型中没有很好体现测试流程的完整性。
2、尽早测试
尽早测试的理念是：测试与开发是两个相互依存的并行的过程，测试活动在开发活动的前期已经开展。
尽早测试的意义 1）降低成本 2)规避风险
3、独立的，迭代的测试
“独立的、迭代的测试”着重强调了测试的就绪点，也就是说，只要测试条件成熟，测试准备活动完成，测试的执行活动就可以开展。
测试过程是独立的
4、软件测试计划制定义
1、定义：软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
制定测试计划的目的
综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果；
建立模型，定义测试项目中每个角色的责任和工作内容。
开发有效的测试模型，能正确地验证正在开发的软件系统；
确定测试所需要的时间和资源，以保证其可获得性、有效性
确立每个测试阶段测试完成以及测试成功的标准、要实现的目标
识别风险，消除风险，降低风险带来的损失
5、测试计划的要点
计划的目的
•项目的范围和目标，各阶段的测试范围、技术约束和管理特点
项目估算
•工作量、成本、时间估算依据
风险计划
•测试可能存在的风险分析、识别，以及风险的回避、监控、管理
日程
•分解项目结构，制定时间/资源表
项目资源
•人员、硬件和软件等资源的组织和分配
跟踪和控制机制
按照国家标准或有关行业标准编写测试计划，测试计划要提供被测软件的背景
信息、测试目标、测试步骤、测试数据整理以及评估准则。
•质量保证和控制、变化管理和控制等
测试计划的编写内容
•测试环境
•测试基本原理和策略
•测试计划阶段划分
•测试计划要点
•功能描述和功能覆盖说明
•测试用例清单
•测试开始和退出准则
制定测试策略
测试需求分析需要制定测试策略。测试策略描述当前测试的目标和所采用的
测试方法。
−要使用的测试技术和工具
−测试完成标准，用以计划和实施测试，及通报测试结果
−影响资源分配的特殊考虑
确认测试方法
静态测试
动态测试
是否需要执行被测软件
白盒测试
黑盒测试
测试用例设计的方法和管理
黑盒测试用例设计方法
•等价类划分、因果图法、边值分析
白盒测试用例设计方法
•逻辑覆盖基于程序结构的域数据流
测试执行分类
手工测试
•按照测试用例的条件、步骤要求，手工输入，比较实际结果与预期结果
自动化测试
•通过测试工具，运行测试脚本，得到测试结果
6、软件测试文档
概念
软件测试文档描述要执行的软件测试及测试的结果，用来记录、描述、展示测试过程中一系列测试信息的处理过程，通过书面或图示的形式对软件测试过程中的活动或结果进行描述、定义及报告，记载了整个测试的过程和成果
软件测试文档的作用
•提高软件测试过程的能见度
•文档化能规范测试问题的反馈，提高测试效率
•便于团队成员之间的交流与合作
•测试文档是测试人员经验提升的最好途径
•有利于项目测试的监控作用
•有利于测试工作的开展
测试文档常见问题
•文档编写不够规范
•测试文档没有统一入库管理
•只重视测试文档的形式，实用性不强
测试文档的管理
测试文档与测试过程的关系
测试用例
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试数据
测试数据是在测试中使用的实际值（集合）或执行测试
需要的元素。
测试脚本
测试脚本是自动执行测试过程（或部分测试过程）的计算机可读指令。
第七章软件静态测试
1.静态测试的概念及特点：
1.静态测试概念
通常是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。
2.静态测试测试对象
各种与软件相关的有必要进行测试的产物，比如各类文档、源代码等。
3.静态测试引入的目的：
首先，软件产品内部结构复杂、混乱，代码的编写也没有规范，
使得软件内部存在一些不易被察觉的错误。
其次，软件产品需要升级维护时，由于程序的复杂度和代码
编写的混乱，维护工作很难进行。
静态测试所要做的就是对代码标准以及质量进行监控，以此来提高代码的可靠性，使系统的设计符合模块化、结构化、面向对象的要求。
4.静态测试的特点：
不必动态地运行程序。
可以人工进行，充分发挥人的思维优势。
不需要特别的条件，容易展开。
对测试人员要求比较高。
2.静态测试的主要内容：
1.各阶段的评审
一般评审包括：培训评审、预备评审、同行评审，我们所关心的是同行评审
2.代码检查
主要检查代码和设计的一致性、代码对标准的遵循、代码的可读性、代码的逻辑表达正确性，代码的合理性
3．软件复杂性分析
主要包括软件复杂性度量与控制，软件复杂性度量元，面向对象的软件复杂性度量
4.软件质量度量
就是从整体上对软件质量进行评测，用于软件开发中对软件进行质量控制，并最终对软件产品进行评价和验收
5.McCabe圈复杂度
•把程序结构的控制流程图转化为有向图（即程序图），然后计算强连通有向图的环数来衡量软件的质量，用此方法得到的复杂度称为圈复杂度。（为了使之强连通，我们可以从出口点到入口点画一条虚弧。）
–计算公式为：V(G)=m-n+p
•G是强连通有向图
•V(G)是强连通有向图G中的环数
•m是G中的弧数
•n是G中的节点数
•p是G中分离部分的数目
•对于一个正常的程序来说，程序图总是连通的，即p=1
第八章 动态测试
1、概念
动态测试是指通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效率和健壮性等指标。
2、“白盒”测试
“白盒”测试是一种典型的测试方法，是一种按照程序内部逻辑结构和代码结构设计测试数据并完成测试的测试方法。所采用的测试方法是逻辑覆盖（包括语句覆盖、条件覆盖、分支覆盖、分支-条件覆盖、条件组合覆盖
、路径覆盖）
1. 语句覆盖:要求每一条语句至少执行一次。
2. 分支覆盖：要求每一条分支都要至少执行一次。
3. 条件覆盖：要求判断中每一个条件的可能取值至少执行一次。
4. 分支-条件覆盖：要求判断中每一个条件的可能取值至少执行一次，每一条分支都要至少执行一次。
5. 条件组合覆盖：要求每一个判定中条件的各种组合至少执行一次。
6. 路径覆盖：要求每一条路径都要至少执行一次。
3、“黑盒”测试，又称功能测试或数据驱动测试。
黑盒测试主要应用的方法：等价类划分法，因果图法、边界值法、随机数法、猜错法等。
等价类的划分法
等价类的划分法是把程序的输入域划分成若干部分.然后从每个部分中选取少量有代表性的数据当测试用例.
边界值法
边界值法是一种补充等价类划分的测试用例的方法，确定的方法为：四个刚好
即：刚好小于最小值、刚好等于最小值、刚好等于最大值、刚好大于最大值。
因果图法生成测试用例的步骤：
1)分析软件的规格说明，确定那是结果，那是原因，并给每一个原因和结果赋予一个标识符。
2)找出原因和结果之间的关系，画出因果图。
3)在因果图上标出约束和限制条件。
4)把因果图转化成判定表。
5)依据判定表设计测试用例。
4、灰盒测试
灰盒测试是将“黑盒”测试，“白盒”测试，回归测试和变异测试结合在一起，构成一种无缝测试技术。
1、 测试用例设计
1、 高质量测试用例的特点
1） 正确性
2） 完整性
3） 准确
4） 清晰、简洁
5） 可维护性
6） 适应性
7） 可重用性
8） 其他
2、 测试用例设计基本原则
1） 基于测试需求的原则
2） 基于测试方法的原则
3） 兼顾测试充分性和效率的原则
4） 测试用例的代表性
5） 测试结果的可判定性
6） 测试执行的可再现性原则
5、单元测试
软件单元测试是指软件设计说明中一个可以独立测试的元素，是程序中一个逻辑上独立的部分，它不能在分解为其他软件成分。
单元测试的好处
1） 将注意力集中在程序的基本组成部分
2） 单元测试可以平行开展
3） 单元规模较小，复杂性较小
4） 效果显而易见
5） 单元测试的好坏直接影响到产品质量
单元测试的内容
1） 模块接口测试
2） 局部数据结构测试
3） 路径测试
4） 边界测试
5） 错误处理测试
5、单元测试的要求
1） 语句覆盖率达到100%
2） 分支覆盖率达到100%
3） 错误处理路径达到100%
4） 单元的软件特性覆盖
5） 各种数据特性覆盖
进行单元测试前要对程序进行静态分析和代码审查
目的：静态分析依据需求文档，分析模块需要实现的功能，模块的逻辑，数据结构等
代码审查就是检查代码有没有实现静态分析中模块应实现的功能、逻辑机构、数据结构等。
单元测试步骤
1） 构造测试用例的运行环境
2） 设计黑盒测试用例
3） 设计白盒测试用例
原因:看各模块定义的常量在集成后是否还能发挥应有的功能
为什么开展集成测试？
1） 在把各模块连接起来时，穿越模块接口的数据是否会丢失。
2） 一个单元模块是否会对另一个单元模块产发生不利影响。
3） 各模块能否达到预期的效果。
4） 全局数据结构是否有问题。
5） 资源共享是否有问题。
集成测试的内容
1） 集成后的功能性测试
2） 接口测试
3） 全局数据结构测试
4） 资源测试
5） 性能测试
6） 稳定性测试
集成测试步骤
1） 体系结构分析
2） 模块分分析
3） 接口分析
4） 风险分析
5） 可测试性分析
6） 集成测试策略分析
集成测试方法
1） 一次性组装方式
2） 渐增式测试
1— 自顶而下集成测试方法
2— 自底而上集成测试方法
3） 混合渐增式集成测试方法（三明治集成方法）
概念：测试软件是否达到需求中规定的软件应实现的功能和技术指标。
确认测试必须由用户参与。
确认测试的结果：
1） 功能和性能与需求文档及用户的要求一致，软件可以接受，即通过测试
2） 功能和性能与需求文档及用户的要求有一点差距，此时需要详细列出软件各项缺陷或问题的清单或列表，提交对应的问题报告。
确认测试应交付的文档：确认测试分析报告，最终的用户手册和操作手册、项目开发总结报告。
1） 定义
系统测试是为了判断系统是否符合规定而对集成的软、硬件系统进行测试活动。
系统测试要交付的文档主要有：系统测试计划、系统测试计划评审报告、系统测试用例、系统测试用例评审报告、系统测试脚本、系统测试脚本评审报告、系统测试报告、系统测试报告评审报告、缺陷问题单等。
扫一扫
704
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
