软件测试复习大纲

软件测试方法和技术
一、名词解释
☐软件测试（IEEE）定义：在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价，分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性。

更完整的定义：软件测试是由“验证（Verification）”
和“有效性确认（Validation）”活动构成的整体
☐测试驱动开发（TDD Test Driven Development），即测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。

这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

☐软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO 8492)或者书P15：质量是产品或服务所满足明示或暗示需求能力的固有特性和特征的集合
☐软件缺陷：P18（软件缺陷的现象也在该页）
☐人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误。

☐计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。

☐主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果
☐被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据.
☐系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试P29
☐错误推测法：是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试P38
☐独立路径：至少引入一系列新的处理语句或条件的任何路径
☐基本集：由独立路径构成的集合
☐基于模型的测试 (MBT, Model-based testing）：通过构建能够正确描述被测软件系统功能特性的模型，然后基于这个模型产生测试用例并执行这些测试用例的过程P57
☐状态迁移图（state transition diagram，STD）：描述系统状态变化的动态信息——动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变。

逻辑功能模型（logic function model， LFM）的定义P58☐模糊测试（Fuzz testing）方法，简单的说，就是构造大量的变异数据作为系统的输入，从而检验系统在各种数据情况下是否会出现问题
☐形式化方法:基于数学的方法（数学表示、精确的数学语义）来描述目标软件系统属性的一种技术
☐形式化验证，就是根据某些形式规范或属性，使用形式逻辑方法证明其正确性或非正确性。

☐TMap (Test Management Approach，测试管理方法)是一种结构化的、基于风险策略的测试方法体系, 目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本。

P71
☐TPI（Test Process Improvement）是基于连续性表示法的测试过程改进的参考模型，
是在软件控制、测试知识以及过往经验的基础上开发出来的
P82
☐关键测试过程（Critical Test Process，CTP）:内容参考模型、上下文相关的方法，并能对模型进行裁剪 P86
☐单元测试：是对软件基本的组成单元进行独立的测试
☐代码走查：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。

P102（注意的问题：引导小组成员在走查前通读设计和编码；限时，避免跑题；发现问题适当记录，避免现场修改；检查要点是代码是否符合标准和规范，是否有逻辑错误☐驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。

☐桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。

P106☐代码协定：用于标记代码的类、用于编译时分析的静态分析器和运行时分析器。

☐Visual Studio Team System（VSTS）：是一套工具集，全面整合了软件设计、开发、测试、部署和人员协作工具，其开发版（Development Edition）提供了静态分析、代码剖析、代码涵盖以及其它单元测试所需的功能特性。

☐大棒集成方法（Big-bang Intergration）：先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试。

(适用小规模应用系统)
☐性能测试（performance test）：就是为了发现系统性能问题或获取系统性能相关指标而进行的测试
☐渗入测试（soak test），通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾收集（GC）或系统的其他问题，以检验系统的健壮性
☐峰谷测试（peak-rest test），采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源
☐容错性测试（Fault-tolrent test）是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。

☐兼容性测试: 验证软件之间是否正确地交互和共享信息
☐验收测试:P186
☐α 测试: 开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正 ,经过α测试调整的软件产品称为β版本☐β 测试：组织外部的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、反馈使用意见。

然后软件开发公司再对β版本进行改错和完善。

☐测试自动化指“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”
☐对象库是本地在测试结构范围内存储对像信息
☐测量（Measurement）：确定一个测量的行为
☐度量（Metric）：某个给定属性的度的一个定量测量
☐指标(Indicator) ：具体测量的属性及其给定值
二、知识点
第一章
1.为什么要进行软件测试
☐软件总存在缺陷。

只有通过测试，才可以发现软件缺陷。

也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。

☐软件中存在的缺陷给我们带来的损失是巨大的，这也说明了软件测试的必要性和重要性
☐测试是所有工程学科的基本组成单元，自然也是软件开发的重要组成部分。

☐测试人员水平越高，找到软件问题的时间就越早，软件就越容易更正，产品发布之后越稳定，公司赚的钱也越多，微软就是一个典型的例子
2.什么是软件测试（书P7）
ppt：找程序的缺陷、发现一个系统的错误、找出软件中潜在的Bug、测试一下是否符合用户的需求、为即将上市的软件提供一个保证的过程、软件质量保证的一套工程的方法、让软件变得更健壮更好的一种技术、对代码进行的调试
3.软件测试的发展
☐初级阶段（1957～1971）测试通常被认为是对产品进行事后检验，缺乏有效的测试方法
☐发展阶段（1972～1982），1972年第一次关于软件测试的正式会议，促进了软件测试的发展
☐成熟阶段（1983到现在），国际标准Std 829-1983 ，形成一门独立的学科和专业，成为软件工程学科中的一个重要组成部分
4.软件测试正向思维和反向思维
Bill Hetzel博士（正向思维的代表）：
☐软件测试就是为程序能够按预期设想那样运行而建立足够的信心。

☐“软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果”
☐测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作Glenford J. Myers（反向思维的代表）：
☐测试是为了证明程序有错，而不是证明程序无错误
☐一个好的测试用例是在于它能发现至今未发现的错误
☐一个成功的测试是发现了至今未发现的错误的测试
5.软件测试定义的两面性
正向思维-验证软件正常工作-评价一个程序或系统的特性或能力并确定是否达到预期的结果 -在设计规定的环境下运行软件的所有功能，直至全部通过。

逆向思维-测试是为发现错误而针对某个程序或系统的执行过程 -寻找容易犯错误的地方和系统的薄弱环节，试图破坏系统，直至找不出问题。

6.软件测试的价值
•全面评估产品质量，获得有关产品质量的全面、客观的信息
•发现问题，督促问题解决，提高产品质量
•持续提供质量反馈、及时揭示质量风险，有助于控制项目风险，提高构建的质量•通过缺陷分析，获得缺陷模式，有助于缺陷预防
7.测试和质量保证的关系
软件质量保证（Software Quality Assurance，SQA）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。

✧对软件工程各个阶段的进展、完成质量及出现的问题进行评审、跟踪。

✧审查和验证软件产品是否遵守适用的标准、规程和要求，并最终确保符合标准、满
足要求。

✧建立软件质量要素的度量机制，了解各种指标的量化信息，向管理者提供可视信息。

8.软件测试和开发的关系（书P10软件瀑布模型图1-1）
第二章
1.ISO 9126 软件质量特征：书P16 ISO 9126软件质量三层模型（附加：McCall模型P16）
☐功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

☐可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

☐易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

☐效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

☐可维护：与进行指定的修改所需的努力有关的一组属性。

☐可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。

2.非功能特性：书P17
3.软件缺陷的产生：P19（书上比较具体，以下是PPT中）
①技术问题
算法错误，语法错误，计算和精度问题，接口参数传递不匹配
②团队工作
沟通不充分，误解
③软件本身
☐文档错误、用户使用场合(user scenario)，
☐时间上不协调、或不一致性所带来的问题
☐系统的自我恢复或数据的异地备份、灾难性恢复等问题
4.软件测试的分类：书P21
5.静态测试和动态测试
☐将需求和设计的评审纳入测试的范畴，可看作是广义测试
☐静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等☐静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析
动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。

6.产品评审和评审分类P23
互评(Peer review)、轮查(Pass-round)、走查(walk-through)、会评(Inspection)
管理评审、技术评审、文档评审、流程评审
7.白盒测试和黑盒测试P27
8.软件测试级别及任务P28
9.专业测试人员的责任和要求P31
优秀测试工程师的素质P33
第三章
1.黑盒方法：错误推测法P38、等价类划分法P39、边界值分析法P41、判定表方法P43、因果图法P45、正交试验法P48、两两组合法P47、功能图法P58、有限状态机P63
2.白盒方法：6种覆盖P49-53仔细看书上例题
3.根据等价类创建测试用例的步骤，详细题目见P67-2作业
a)建立等价类表，列出所有划分出的等价类：
b)为每个等价类规定一个唯一的编号；
c)设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类
d)重复c)，最后使得所有有效等价类均被测试用例所覆盖；
e)设计一个新的测试用例，使其只覆盖一个无效等价类。

f)重复e)使所有无效等价类均被覆盖。

4.判定表元素，同时也是判定表的方法步骤
☐条件桩，列出问题的所有条件
☐动作桩：列出可能针对问题所采取的操作
☐条件项：针对所列条件的具体赋值
☐动作项：列出在条件项（各种取值）组合情况下应该采取的动作。

☐规则：任何一个条件组合的特定取值及其相应要执行的操作。

5.为什么使用正交试验法
在许多应用系统的测试工作中，不会象判断三角形那样简单，输入条件的因素很多，而且每个因素也不能简单用“是”和“否”来回答。

测试组合会变得很多，如果按照传统的测试方法，会导致很大的测试工作量
6.循环测试
简单循环：完全跳过循环；只经过循环一次；经过循环两次；经过循环m（ m < n ）次；
分别经过循环n-1, n, n+1 次
嵌套循环：在最里面的循环完成前面所述的简单循环测试，同时设定外部循环的最小迭代次数；逐步向外循环进行，直到所有循环被测试
串行连接的循环：独立循环à可以分别看着简单循环测试；依赖性循环à可以看着是嵌套循环
7.基于缺陷的测试，DPBT测试过程步骤P56
预处理/预编译，词法分析(Lexical Analysis) ，语法分析( Parsing) 和语义处理( Semantic Analysis) ，抽象语法树生成，控制流图生成，IP 扫描，人工确认
8.如何设计测试用例
✧功能图法设计测试用例，就是如何覆盖软件所表现出来的所有状态，可以转化为两
个层次的测试用例
✧从功能逻辑模型（决策表或因果图）导出局部测试用例，覆盖各个状态的各种输入
数据的组合
✧从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径
9.基于场景的测试方法
⏹基于Use case或User Story直接进行验证
⏹根据UML的序列图来进行验证
⏹列出各种系统事件、观察和分析用户行为，设想各种可能的user scenario
来进行验证
⏹分析同类系统和竞争对手的系统
第四章
1.敏捷宣言的原则：
①时间：尽早和持续地交付有价值的软件来满足客户
②变更：欢迎需求变更——即使是在项目开发后期。

要善于利用需求变更，帮助客户
获得竞争优势
③周期：要不断交付可用的软件，周期从几周到几个月不等，且越短越好
④协同：项目中，业务人员与开发人员必须一起工作
⑤信任：要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成
任务
⑥沟通：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
⑦产品：可用的软件是衡量进度的主要指标
⑧速度：敏捷过程提倡可持续的开发。

项目方、开发人员和用户应该能够保持长期稳
定的开发速度
⑨追求：对技术的精益求精、对设计的不断完善将提升敏捷性
⑩简单：尽可能减少不必要的工作——一门艺术
⑪团队：最佳的架构、需求和设计出自于自组织的团队
⑫自省：团队要定期反省如何能够做到更有效，并相应地调整团队的行为
2.敏捷测试的特征和流程P74
3.为什么引入探索式测试
☐开发人员多、测试人员少，测试更关注效率
☐整个开发节奏很快，测试要跟上这个节奏
☐测试时间很少，需要快速完成测试
☐对产品或业务不够熟悉，需要操作或使用它来熟悉
☐产品某些部分复杂，需要不断探索，才能很好地完成测试
4.ST vs ET 书P77
5.风险测试步骤
列出软件的所有功能和特性；确定每个功能出错的可能性；如果某个功能出错或欠缺某个特征，需要评估对用户使用软件产品的影响程度；根据上面两个步骤，计算风险度；根据可能出错的迹象，来修改风险度；决定测试的范围，编写测试方案
6.完整的软件测试规范是怎样的
规范目的，范围，文档结构，词汇表，参考信息，可追溯性，方针，过程/规范，指南，模板，检查表，培训，工具，参考资料等
7.制定测试规范需要考虑的内容
角色的确定，进入的准则，输入项，活动过程，输出项，验证与确认，退出的准则，度量
第五章
1.尽早发现错误的原因
•错误发现越早,成本越低.
•发现问题比较容易
•修正问题更容易
2.为什么要进行单元测试P95，单元测试的目标P96
3.实施代码规范的原因P99
4.走查和会议审查的对比P103
5.JUnit的主要特征P119
•测试代码与产品代码分开
•提供了编写测试类的框架
•通过与Ant结合，易于集成到程序的构建过程中，实施增量开发
•源代码公开，易于二次开发
•可扩展性强
6.JUnit七个类核心关系图P120
7.开源的单元测试工具P129
☐C/C++ 语言单元测试工具：CppTest、CppUnit、…
☐Java语言单元测试工具：TestNG、PMD、Checkstyle、Findbugs、Jalopy……
☐Mock Object类工具: MockObjects、Xdoclet、EasyMock、MockCreator、MockEJB、ObjcUnit、jMock等
8.商业单元测试工具P130
☐C/C++语言的单元测试工具以商业工具为主，例如Parasoft C++、PR QA•C/C++、CompuWare DevPartner for Visual C++ BoundsChecker Suite、Panorama C++等☐内存资源泄漏检查工具，如CompuWare BounceChecker， IBM Rational PurifyPlus 等
☐代码覆盖率检查工具，如CompuWare TrueCoverage， IBM Rational PureCoverage，TeleLogic Logiscope等。

☐代码性能检查工具，如Logiscope和 Macabe等
9.集成测试的模式P133
非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

各自优缺点
10.三明治集成方法
采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上
11.自顶向下和自底向上的集成P133持续集成P135
第六章
1.功能测试的要点
☐功能逻辑清楚，符合使用者习惯
☐系统的各种状态按照业务流程而变化，并保持稳定
☐每项功能符合实际要求
☐系统的界面清晰、美观
☐菜单、按钮操作正常、灵活，能处理一些异常操作
☐能接受正确的数据输入，对异常输入的容错处理
☐数据的输出结果准确，格式清晰，可以保存和读取
☐程序安装、启动正常，有相应的提示框、错误提示等
2.回归测试的目的（回归测试的策略及方法P150）
☐所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；
☐不影响软件原有功能的正确性。

3.一些常见的性能问题
•启动系统、打开页面越来越慢
•查询数据，很长时间才显示列表
•网络下载速度很低
•资源耗尽，如CPU使用率达到100%
•资源泄漏，如内存泄漏，最终会导致资源耗尽
•资源瓶颈，如线程、GDI、DB连接等资源变得稀缺
4.并发性能测试
并发性能测试的过程也是一个负载测试过程，即逐渐增加并发虚拟用户数负载，直到系统出现性能瓶颈或者崩溃为止。

破坏性压力测试，通过不断加载的手段，快速造成系统的崩溃，让问题尽快地暴露出来
5.性能的具体指标
•数据传输的吞吐量（Transactions）
•数据处理效率（Transactions per second）
•数据请求的响应时间（Response time）
•内存和CPU使用率
•连接时间（Connect Time）、发送时间（Sent Time）
•处理时间（Process Time）、页面下载时间
•第一次缓冲时间
•每秒（SSL）连接数
•每秒事务总数、每秒下载页面数
•每秒点击次数、每秒HTTP 响应数
•每秒重试次数
6.功能性测试VS安全性测试
☐功能性测试：软件做它应该做的事，验证正确的输出
不正确的输出 /行为 / 缺陷(Bug)
☐安全性测试：软件不做它不应该做的事, 应用输入验证, 没有不安全的事情发生，在测试软件系统中对危险防止和危险处理设施进行的测试，以验证
其是否有效
第七章
1.验收测试的测试内容
验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试尽可能地发现软件中存留的缺陷，并保证系统或软件产品最终被用户接受。

主要包括易用性测试、安装测试、文档测试(如用户手册)等几个方面的内容。

2.验收测试的测试步骤,完成标准,注意事项P187
3.产品规格说明书的审核和验证(各四点)P188
4.用户界面的七要素P191
符合标准和规范 ,直观性 ,一致性 ,灵活性 ,舒适性 ,正确性 ,实用性
第八章
1.国际化的测试方法
☐设计评审和代码审查
☐针对源语言的功能测试，如不同的区域设置、不同的时区显示
☐针对伪翻译（pseudo-code，pseudo-translation）版本的测试
2.软件国际化标准和软件本地化基本步骤P198本地化测试(6点)P201
3.UI验证的细节
☐控件相互重叠或排列间隔不均衡。

☐文字遮挡图像、文字超过边界或者控件中字符没有完整显示等问题
☐文字方向的问题，如希伯莱文和阿拉伯文是从右到左显示
☐左右对齐问题，如阿拉伯文应右对齐。

中英文之间有区别，中文段落开头需要空两个字的距离，而英文开头则不是。

☐连字符对多数拉丁语言有效，但对东方语言一般无效。

☐拉丁语言的大小写问题、多字节语言的显示乱码问题等等
第九章
1.手工测试的局限性,测试自动化和自动化测试的区别P214
2.测试自动化带来的好处P215(9点)
3.正确认识测试自动化
☐不现实的期望注定测试自动化的失败
☐测试自动化能：
显著降低重复手工测试的时间
建立可靠、重复的测试，减少认为错误
增强测试质量和覆盖率
☐测试自动化不能：
完全替代手工测试和手工测试工程师
保证100%的测试覆盖率
弥补测试实践的不足
4.各种测试的应用范围
a)在系统功能逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，多采用手
工测试(黑盒)方法；
b)单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用TA；
c)对那种不稳定软件的测试、开发周期很短的软件、一次性的软件等不适合测试自动
化
d)功能测试时，工具更能发挥回归测试作用，因为工具缺乏想象力和灵活性而不能发
现更多的新问题（自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷），但可以保证对已经测试过部分进行测试的准确性和客观性
5.测试自动化实现的原理和方法(与书上略有不同)P217
☐代码分析: 类似于高级编译系统，在工具中定义类/对象/函数/变量等定义规则、语法规则等，在分析时对代码进行语法扫描，找出不符合编码规范的地方。

☐捕获和回放: 代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。

☐直接编写脚本来操作、控制、验证对象：包括对象识别、脚本技术、对运行结果进行比较
6.测试工具的分类P224
☐根据测试方法不同，分为白盒测试工具和黑盒测试工具、静态测试工具和动态测试工具等。

☐根据工具的来源不同，分为开源测试工具（多数是免费的）和商业测试工具、自主开发的测试工具和第三方测试工具等。

☐根据测试的对象和目的，分为单元测试工具、功能测试工具、性能测试工具、测试管理工具等
更细的分类
•静态测试工具
- 扫描分析：Findbugs, JTest/C++Test
- 规则定义
•动态测试工具。