软件测试知识总结

1、测试驱动开发（TDD）测试在先，编码在后开发方法（详见书本12页）

2、软件质量：功效、性能、可靠性（书本15页）

3、软件测试工作范围：测试组织与管理（PDCA）、测试计划、测试用例、测试实施、测试结果分析、测试评审与汇

报（书本29页小结中）

第三章

4、白盒测试（设计测试用例看书说明）

（又称逻辑驱动测试，结构测试）意思是把程序看成装在一个透明白盒子里，测试人员知道程序结构和处理

算法，按照程序内部逻辑进行测试，检测程序中主要执行通路是否都能按预定要求正确工作，利用白盒测

试法进行动态测试时，不需测试软件产品功效。白盒测试主要用于单元测试。（详见书本31页）

（1）语句覆盖

设计若干测试用例，运行被测试用例，使程序中每个可执行语句最少被执行一次。

（2）判定覆盖：设计若干测试用例，运行被测试用例，使程序中每个判断取真分支和取假分支最少经历一

次。（针对每次判断，又称分支覆盖）

（3）条件覆盖：设计若干测试用例，运行被测试用例，使程序中每个判断中每个条件可能取值最少满足一

次。（针对每次判断中每一个条件）

（4）判定-条件覆盖

（5）条件组合覆盖：每个判定结果最少出现一次，每个条件全部可能最少出现一次。

（6）路径覆盖：设计全部测试用例，来覆盖程序中全部可能执行路径。

（7）基本路径测试法：（依照流程图判断）

独立路径：所谓独立路径，是指最少包含一条新边路径，也就是包含一些前面路径未包含语句，当全

部语句都包含了，基路径集就够了。

5、黑盒测试（设计测试用例案例）

（又称功效测试或者数据驱动测试）黑盒测试法把程序看作一个黑盒子，完全不考虑程序内部结构和处

理过程。也就是说，黑盒测试是在程序接口进行测试，它只检验程序功效是否能按照规格说明书要求正

常使用，程序是否能适当地接收输入数据并产生正确输出信息，程序运行过程中能否保持外部信息完整

性。

（1）等价划分（见书本40页）

有效等价类和无效等价类

①输入条件要求了取值范围或者个数情况下，则能够确立一个有效等价类和两个无效等价类。

②在输入条件要求了输入值集合或者要求了“必须怎样”条件情况下，可确立一个有效等价类和一个无

效等价类。

⑤在要求了输入数据必须恪守规则情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从

不一样角度违反规则）。（参考40页实例）

（2）边界值分析

假如输入条件要求了值范围，则应取刚达成这个范围边界值以及刚才超越这个范围边界值作为

测试输入数据。

假如输入条件要求了值个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一数

作为测试数据。

假如程序规格说明中提到输入或输出是个有序集合，应该注意选取有序集第一个和最终一个作

为测试用例。

（3）正交试验

正交表具备两条性质：⑴每一列中各数字出现次数都一样多。（2）任何两列所组成各有序数对出现

次数都一样多。所以称之谓正交表。（见书本48页）

（4）错误推测表

基于经验和直觉推测程序中全部可能存在各种错误,从而有针对性设计测试用例方法。

6、主动测试与被动测试

主动测试：测试人员主动向被测试对象发送请求，验证被测试对象反应和输出结果。通常在测试环境下

进行，测试人员需要设计若干测试用例，设法输入各种数据。

被动测试：为了处理产品在线测试问题。在被动测试方法中，软件产品运行在实际环境中，测试人员不

干预产品运行，而是被动地监控产品运行，经过一定被动机制来获取系统运行数据，测试人员不需要设计测

试用例。

7、基于风险测试

指评定测试优先级，先做高优先测试，假如时间或者精力不足，低优先级测试能够暂时先不做。影响测试优

先级主要原因：对用户影响、犯错概率

第四章

8、V模型(RAD模型快速应用开发模型)书本66页

V模型大致能够划分为以下几个不一样阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集

成测试、系统测试、验收测试。

原理：在瀑布模型基础上，经过开发和测试同时进行方式来缩短开发周期，提升开发效率

适用条件：明确需求、需求改变不大

V模式是一个传统软件开发模型，通常适适用于一些传统信息系统应用开发，而一些高性能高风险系

统、互联网软件，或一个系统难以被详细模块化时候，就比较难做成V模式所需各种构件，需要更强调迭代

开发模型或者灵敏开发模型。

优缺点：(详见瀑布模型优缺点)

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后一个阶段，无视了测试对需求分析,系统设

计验证，需求满足情况一直到后期验收测试才被验证。

9、软件质量体系标准

(1)CMM针对软件产品质量管理和质量确保标准

CMM全称为(CapabilityMaturityModel),汉字名称为能力成熟度模型

CMM划分为五级:级别越高表明该企业在提供合格软件产品方面能力越强

（2）CMMI

为了整合不一样模型最好实践,提议统一模型，覆盖不一样领域，供企业进行整个组织全方面过程改进,

并于正式公布了能力成熟度集成模型（CMMI）。

（3）ISO9000原本是硬件标准（见书本83页）

IS09000不是指一个标准，而是一类标准统称。ISO9000族标准是用来提供一个通用质量体系标准关

键，适适用于广泛工业行业和经济部门。

测试分类：单元测试、集成测试、系统测试、验收测试

第五章单元测试

10、单元测试（见书本97页）：单元测试是对软件基本组成单元进行测试

为何要进行单元测试？

■尽早发觉错误

错误发觉越早，成本越低.

开发人员过于自信,后期复杂度高，发觉处理BUG困难.

■检验代码是否符合设计和规范

目标：

（1）主要目标：确保各单元模块被正确地编码

（2）确保代码在结构上可靠且健全，能够在各种条件下给予正确响应

概括起来，单元测试是对代码对单元代码规范性、正确性、安全性和性能等进行验证。

内容（任务）：单元中全部独立执行路径、数据结构、接口、边界条件、容错性等测试。

（详见ppt单元测试）

10、走查和审查（见104页表5-1）

静态测试三部曲：走查、审查、评审

(1)走查

采取讲解、讨论和模拟运行方式进行查找错误活动。

■引导小组组员在走查前通读设计和编码。

■限时，防止跑题。

■发觉问题适当统计，防止现场修改。

■检验关键点是代码是否符合标准和规范，是否有逻辑错误。

(2)审查

采取讲解、提问方式进行，通常有正式计划、流程和结果C主要方法采取缺点检验表。

■以会议形式，制订会议目标、流程和规则，结束后要编写汇报。

■按缺点检验表逐项检验。

■发觉问题适当统计，防止现场修改。

■发觉重大缺点，改过后会议需要重开。

■检验关键点是缺点检验表，所以该表要依照项目不一样不停积累完善。

走查审查

准备通读设计和编码应准备好需求描述文档、程序设计文档、程序源代

码清单、代码编码标准和代码缺点检验表

形式非正式会议正式会议

参加人员开发人员为主项目组组员包含测试人员

主要技术方法无缺点检验表

注意事项限时、不要现场修改代限时、不要现场修改代码

码

生成文档会议统计静态分析错误汇报

目标代码标准规范，无代码标准规范，无逻辑错误

逻辑错误

12、驱动程序与桩程序(在黑盒测试中)

驱动程序：也称驱动模块，用以模拟被测模块上级模块，能够调用被测模块。在测试过程中，驱动模块接收测试

数据，调用被测模块并把相关数据传送给被测模块，开启被测模块，并打印出对应结果。

桩程序：也称桩模块，用以模拟被测模型工作过程中所调用下级模块。桩模块由被测模块调用，它们通常只进行

极少数据处理。

驱动模块

被测试单元

一一块1II桩侯块2

第六章集成测试与系统测试

13、集成测试模式

（1）非渐增式测试模式

先分别测试每个模块。再把全部模块按设计要求放在一起结合成所要程序。如：大棒模式

概括地说，非增量式测试就是采取一步到位方法结构测试，即对全部模块进行单元测试后，按照程序结

构图将全部模块连接起来，进行整体测试.

其显著缺点是轻易出现混乱，判断犯错原因和位置比较困难，因为测试时可能出现很多错误，而且在修

正一个错误同时，可能会引入新错误。

（2）渐增式测试模式

把下一个要测试模块同己经测试好模块结合起来进行测试，测试完以后再把下一个应该测试模块结合进

来测试。

详细优缺点详见书本126页

14、自顶向下与自底向上集成方法

（1）自顶向下：从主程序开始，沿着软件控制层次向下移动，从而逐步把各个模块结合起来。在组装过程中，能

够使用深度优先或者宽度优先策略。

■逐步集成和逐步测试是按照结构图自上而下进行

＞深度优先集成是先集成一个主控路径下全部模块，主控路径选择是任意;

A广度优先集成首先是沿着水平方向，把每一层中全部直接属于上一层模块集中起来，直到最底

层。

集成测试整个过程主要由3个步骤完成：

>1）主控模块作为测试驱动器；

>2）依照集成方式，下层桩模块依次被替换为真正模块；

>3）每个模块集成时，进行单元测试。

（2）自底向上：从原子模块开始集成以进行测试。

（3）改进自顶向下：基本使用“自顶向下”，但在早期，使用自底向上测试少数关键模块。

混正当：对软件结构中较上层，使用是“自顶向下”法；对软件结构中较下层，使用是“自底向上”法，二者相

结合

15、改进三明治集成方法

三明治方法：

采取三明治方法优点是：它将自顶向下和自底向上集成方法有机地结合起来，不需要写桩程序因为在测试初

自底向上集成已经验证了底层模块正确性。采取这种方法主要缺点是：在真正集成之前每一个独立模块没有

完全测试过。

改进三明治集成方法：

不但自两头向中间集成，还确保了每个模块得到单独测试，使测试进行比较彻底。

16、连续集成

（1）连续集成（ContinuousIntegration,Cl）是连续地编译、测试、检验和布署源代码过程。

（2）优点：连续集成能够降低集成阶段“Bug”消耗时间，从而最终提升软件开发质量和效率。

（3）连续集成测试原理

连续集成，是一个软件开发实践，即团体开发组员经常集成它们工作，通常每个组员天天最少集成一次，也

就意味着天天可能会发生数次集成。每次集成都经过自动化构建（包含编译，公布，自动化测试）来验证，从而尽

快地发觉集成错误。

17、回归测试

（1）概念：指修改了旧代码后，重新进行测试以确认修改没有引入新错误或造成其余代码产生错误。

（2）方法:再测试全部用例、基于风险选择测试、基于操作剖面选择测试、再测试修改部分。

（3）目标：

所做修改达成了预定目标，如错误得到了改过，新功效得到了实现，能够适应新运行环境等；

不影响软件原有功效正确性。

18、非功效测试（设计测试用例主要看课件）

（1）性能测试

A性能测试目标：

为了验证系统是否达成用户提出性能指标，同时发觉系统中存在性能瓶颈，起到优化系统目标。

》性能测试指标起源:

用户对各项指标提出明确需求；假如用户没有提出性能指标则依照用户需求、测试设计人员经验来设计各

项测试指标。（需求+经验）

》主要性能指标：

服务器各项指标（CPU、内存占用率等）、后台数据库各项指标、网络流量、响应时间

（2）压力测试（累积效应）

压力测试是在一个需要反常数量、频率或资源方式下，执行可重复负载测试，以检验程序对异常情况抵抗能

力，找出性能瓶颈。

压力测试总是迫使系统在异常资源配置下运行。

（4）容量测试

容量测试目标是经过测试预先分析出反应软件系统应用特征某项指标极限值（如最大并发用户数、数据库

统计数等），系统在其极限值状态下还能保持主要功效正常运行。容量测试还将确定测试对象在给定时间

内能够连续处理最大负载或工作量。

（5）安全性测试

安全性测试是检验系统对非法侵入防范能力。安全测试期间，测试人员假扮非法入侵者，采取各种方法试

图突破防线。

（6）可靠性测试

可靠性（Reliability）是产品在要求条件下和要求时间内完成要求功效能力，它概率度量称为可靠度。软件

可靠性是软件系统固有特征之一，它表明了一个软件系统按照用户要求和设计目标，执行其功效可靠程

度。软件可靠性与软件缺点关于，也与系统输入和系统使用关于。理论上说，可靠软件系统应该是正确、

完整、一致和健壮。

（7）容错性测试

容错性测试是检验软件在异常条件下本身是否具备防护性方法或者某种灾难性恢复伎俩。如当系统犯错

时，能否在指定时间间隔内修正错误并重新开启系统

压力测试、容量测试和性能测试测试目标即使有所不一样，但其伎俩和方法在一定程度上比较相同，通常会

使用特定测试工具，来模拟超常数据量、负载等，监测系统各项性能指标，如CPU和内存使用情况、响应时

间、数据传输量等。

19、（1）。测试.0测试

a测试是指软件开发企业组织内部人员模拟各类用户行对即将面市软件产品（称为a版

本）进行测试，试图发觉错误并修正。

经过a测试调整软件产品称为B版本。紧随其后B测试是指软件开发企业组织各方面经典用户在日

常工作中实际使用p版本，并要求用户汇报异常情况、提出批评意见。然后软件开发企业再对B版本进

行改错和完善。

（2）文档测试：

非代码文档测试主要检验文档正确性、完备性和可了解性。

□验证正确性

□验证完备性

□验证可了解性

软件驱动文档还得像程序一样运行起来测试。

第八章面向对象软件测试

20、分层与增量原理（160页）

类C和其派生类D间增量改变能够用来帮助确定需要在D中测试什么。因为D是C子类，那么全部用于C基

于规范测试用例也都适适用于Do引入术语“继承测试用例”来代表从父类测试用例中选取出来、用于子类测试

用例。能够经过简单分析来确定继承测试用例中哪些适适用于测试子类、哪些在测试子类时无须执行。

21、分类测试关键点（泛化）与组装结构（聚合）

分类测试：表现了问题空间实例中通常与特殊关系

组装结构：表现了问题空间实例中整冰与局部关系

第九章基于应用服务器测试

21、解释以下故障名称及原理

数据库并发能力:多个应用请求并发处理过程.

并发主要考虑几个方面：（详见书本196页）

（1）数据丢失（解释）

（2）不可重复数据（解释）

（3）读脏数据（解释）

（4）数据库锁

第十章软件当地化测试

22、翻译错误测试方法

翻译错误

⑴产生原因

1)翻译人员不悉翻译要求

2)翻译人员工作疏漏

3)用户界面翻译与标准词汇表不致

表现特征

1)应该翻译而没有翻译英文字符

2)不应该翻译而翻译汉字字词

3)错误翻译字词

4)只在当地化版本中存在该类型错误

5）较多隐含在对话框各控件以及帮助文档中。

测试要求

1)明确需要翻译和不需要翻译为

2)明确正确翻译方式

3)依照术语表确认术语翻正确性与致性

⑷测试方法

1)主要同时打开中英文版本执行相同操作

4

2)结标准界面词汇翻译表参考对比

⑸说明

1）对于对话框，假如含有下拉列表框，要打开列表框查看全部项。

23、布局错误测试方法

⑴产生原因

1）软件当地化后，因为源语言和当地化语言表示方式不一样，当地化后字符数与源语言不一样，每个字符所占空

间尺寸不一样，使得在英文版本正确显示控件字符，可能在当地化版本显示不正确。

2)当地化人员调整程序资源不妥引发，比如，对话框及其控件高度或宽度不正确调整。

表现特征

1)控件相互重合或排列不均匀

2)控件中字符显示不完整

3）主要出现在当地化版本对话框中o

(3)测试要求

1)对话框中控件布局均匀字符显示完整正确

2)对话框中控件数相等没有多出或丢失控件

测试方法

1)执行将要打开对话框菜单或工具栏按钮，观察打开对话框中控件布局。

2)对比检验源语言软件和当地化软件对应对话框中控件数量

⑸说明

1）可能在执行不一样操作后，如选择了不一样单项选择或复选按钮后，编辑框显示重合等。

第十一章软件测试自动化

24、测试自动化

（1）概念：自动化测试是把以人为驱动测试行为转化为机器执行一个过程。

（2）与手工测试辩证关系

测试自动化能:

□显著降低重复手工测试时间

□建立可靠、重复测试，降低人为错误

□增强测试质量和覆盖率

测试自动化不能:

□完全代替手工测试和手工测试工程师

□确保100%测试覆盖率

软件测试自动化（TA）即使具备很多优点，但只是对手工测试一个补充，TA绝不能代替手工测试，有各自特点：

□在系统功效逻辑测试、验收测试等多采取黑盒测试手工测试方法；

□系统性能、稳定性、可靠性测试等比较适合采取TA；

□对那种不稳定软件测试、开发周期很短软件、一次性软件等不适合测试自动化

□工具本身并没有想象力和灵活性，依照经验报道，自动测试只能发觉15%缺点，而手工测试能够发觉85%

缺点；TA工具在进行功效测试时，其准确含义是回归测试工具，因为工具不能发觉更多新问题，但能够

确保对已经测试过部分进行测试准确性和客观性

（3）黑盒测试主要步骤

（自动化测试有哪些主要步骤？）

录制测试过程成为自动化测试脚本

增强和改进录制自动化测试脚本

执行自动化测试脚本完成自动化测试

（4）性能测试测什么？

各种操作响应速度、最大并发用户数

最大数据容量

（5）单元测试、集成测试、系统测试区分与联络

单元测试

单元测试是对软件基本组成单元（软件设计最小单位）进行正确性检验测试工作，如函

数、过程（function,procedure）或一个类方法（method）。

集成测试

集成测试是在单元测试基础上，将全部模块按照概要设计要求组装成为子系统或系统，验

证组装后功效以及模块间接口是否正确测试工作。集成测试也叫组装测试、联合测试、子

系统测试或部件测试。

系统测试：

系统测试是将己经集成好软件系统，作为整个基于计算机系统一个元素，与计算机硬件、

外设、一些支持软件、数据和人员等其余系统元素结合在一起，在实际使用环境下，对计

算机系统进行一系列组装测试和确认测试工作。

测试阶段测试方法测试内容评定基准对应阶

段

单元测试白盒测试单元内部数据结构，逻辑控制，异常处理等逻辑覆盖率详设

集成测试灰盒测试模块间接口以及模块组合后整体功效接口覆盖率概设

系统测试黑盒测试整个系统对需求符合度测试用例对需求覆盖率需求

第十三章布署测试环境（设计测试环境）

25、测试环境主要性（详见书本289页）

使用错误测试环境，可能引发以下一系列问题：

得犯错误结果

与实际误差很大

忽略了实际使用可能出现严重错误

造成项目返工，成本加大

造成项目延期

26、（1）测试环境5要素

■硬件

■软件

■数据准备

■网络环境

■测试工具

（2）数据准备（需要了解透彻）

数据准备包含数据量和真实性两个方法。（详见书本294页）

第十五章汇报所发觉缺点

27、（1）软件缺点

软件缺点指是系统或系统部件中那些造成系统或部件不能实现其功效缺点。假如在执行

中碰到一个缺点，可能引发系统失效。那么准确有效定义和描述软件缺点，能够使软件缺

点得以快速修复，节约了软件测试项目标成本和资源，提升产品质量。

（2）软件缺点描述基本要求

软件缺点描述是软件缺点汇报中测试人员对问题陈说一部分而且是软件缺点汇报

基础部分。同时，软件缺点描述也是测试人员就一个软件问题与开发小组交流最初且最好

机会。一个好描述，需要使用简单、准确、专业语言来抓住缺点本质。

□单一准确

□能够再现

□完整统一

□短小简练

□特定条件

□补充完善

□不做评价

28、分离和再现缺点原理

开发人员有时能够依摄影对简单错误信息就能找出问题所在。因为开发人员熟悉代

码，所以看到症状、测试用例步骤和分离问题过程时，可能得到查找软件缺点线索。一个

软件缺点分离和再现问题有时需要小组共同努力。假如软件测试人员尽最大努力分离软件

缺点，也无法表示准确再现步骤，那么依然需要统计和汇报软件缺点。

29、缺点描述主要内容

软件缺点详细描述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再

做深入讨论：

□“步骤〃提供了怎样重复当前缺点准确描述，应简明而完备、清楚而准确。这些信息

对开发人员是关键，视为修复缺点向导，开发人员有时埋怨糟糕缺点汇报，往往

集中在这里；

□“期望结果〃与测试用例标准或设计规格说明书或用户需求等一致，达成软件预期功

效。测试人员站在用户角度要对它进行描述，它提供了验证缺点依据。

□“实际结果〃测试人员搜集结果和信息，以确认缺点确实是一个问题，并标识那些影

响到缺点表现要素。

优异缺点汇报

重现步骤:

a）打开一个编辑文字软件而且创建一个新文档（这个文件能够录入文字）

b）在这个文件里随意录入一两行文字

c）选中一两行文字，经过选择Font菜单然后选择Arial字体格式

d）一两行文字变成了无意义乱字符

期望结果：当用户选择已录入文字并改变文字格式时候，文本应该显示正确文字格式不会

出现乱字符显示。

实际结果:它是字体格式问题，假如