软件评测师考试学习计划

1、测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量；

2、测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程；

3、软件测试的根本目的：是为了提高软件质量，降低软件项目的风险；

4、软件的质量风险表现在两个方面：一种是内部风险，一种是外部风险；

5、内部风险：是在即将销售的时候发现有重大的错误，从而延迟发布日期，失去市场机会；

6、外部风险：是用户发现了不能容忍的错误，引起索赔、法律纠纷，以及用于客户支持的费用甚至失去客户的风险；

1、软件测试经典定义

在规定条件下对程序进行操作，以发现错误，对软件质量进行评估；

2、软件是由文档、数据、程序组成的，软件测试应该是对软件形成过程的文档、数据以及程序进行测试，而不仅仅是对程序进行测试；

3、软件质量保证和软件测试是软件质量工程的两个不同层面的工作；

4、质量保证（QA）

质量保证的重要工作通过预防、检查与改进来保证软件质量；

5、软件测试

测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析；

6、测试人员通过执行软件，对过程中的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。

测试人员必须假设软件存在潜在的问题，测试中所做的操作都是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题的分析、追踪与回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节；

7、软件测试目的：测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；

一个成功的测试是发现了至今未发现的错误的测试；

8、测试的目的：以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险；

9、软件测试原则：所有的软件测试都应追溯到用户需求；

应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭；

完全测试是不可能的，测试需要终止；

10、在有限的时间和资源条件下，软件趋于完美，是不可能的。主要原因有三个：

（1）软件入量太大；

（2）输入结果太多；

（3）路径组合太多；

11、测试无法显示软件潜在的缺陷；

12、充分注意测试中的群集现象；

13、根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试；

14、软件测试应贯穿于整个软件生命周期中；

15、在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试；

16、需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象；

17、在软件编码结束后，对编写的每一个程序模块进行测试，称为“单元测试”；

18、在模块集成后，对集成在一起的模块组件进行测试，称为“集成测试”；

19、在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为“确认测试”；

20、将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。

21、验证是保证软件正确性实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标；

22、确认是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合；

23、按照开发阶段划分软件测试可分为

单元测试、集成测试、系统测试、确认测试和验收测试。

24、单元测试

单元测试又称模块测试，是针对软件设计的最小单位—程序模块进行正确性检验的测试工作；其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试；

25、集成测试

集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统；

26、确认测试

是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求；

27、系统测试

系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接、并满足用户需求；

28、验收测试

按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统与评审，决定是否接收或拒收系统；

29、按照测试实施组织划分，软件测试可分为：

（1）开发方测试；

（2）用户测试（β测试）；

（3）第三方测试；

30、开发方测试

通常也叫“验证测试”或“α”测试；开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求；

31、用户测试

在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的验收测试，而是用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价；

32、第三方测试

介于软件开发方和用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。

33、按照测试技术划分

白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。

34、静态测试

是指不运行程序，通过人工对程序和文档进行分析与检查：静态测试技术又称静态分析技术，静态测试实际上是对软件的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等；

35、动态测试

是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现；

36、白盒测试

通过对程序内部结构的分析、检测来寻找问题。了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行；

37、黑盒测试

通过软件的外部表现来发现其缺陷和错误。黑盒测试把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明的规定正常实现；

38、灰盒测试

关注输出对于输入的正确性；

39、软件测试过程模型

• V模型
• W模型
• H模型
• X模型

40、V模型

它反应了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如图所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

41、V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由于测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求；

42、V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现；

43、W模型

V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则；

44、W模型应用

W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试；

45、H模型

强调测试是独立的，只要测试准备完成，就可以执行测试

46、软件生命周期测试策略

首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误无和缺陷；再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试；最后从系统整体出发，运行系统，看是否满足要求。

47、测试过程

• 单元测试
• 集成测试
• 确认测试
• 系统测试

48、测试信息流

49、测试过程需要以下三类输入：

• 软件配置
• 包括软件需求规格说明
• 软件设计规格说明
• 源代码等

50、测试配置

包括测试计划、测试用例、测试驱动程序等。测试配置只是软件配置的一个子集。

51、测试工具

为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。

52、分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程，主要包括：

（1）需求规格说明书评测

（2）概要设计说明书评测

（3）详细设计说明书评测

（4）软件编码规范评测

53、编写良好的需求说明书8条原则

• 功能与实现分离；
• 要求使用面向处理的规格说明语言；
• 描述改目标软件与系统的其他系统元素交互方式；
• 规格说明必须包括系统运行的环境；
• 系统规格说明必须是一个认识的模型；
• 规格说明必须是可操作的；
• 规格说明必须容许不完备性并允许扩充；
• 规格说明必须局部话和松散的耦合；

54、需求说明书评测内容

需求说明书评测作为需求分析阶段工作的复查的手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。

评测的主要内容：

• 系统定义的目标是否与用户的要求一致；
• 系统需求分析阶段提供的文档资料是否齐全；
• 文档中的所有描述是否完整、清晰，准确第反应用户要求；
• 与所有其他系统成分的重要接口是否都已经描述；
• 被开发项目的数据流与数据结构是否足够、确定；
• 所有图表是否清楚，在不补充说明时能否理解；
• 主要功能是否包括在规定的软件范围之内，是否都已充分说明；
• 软件的行为和它必须处理的信息、必须完成的功能是否一致；
• 设计的约束条件或限制条件是否符合实际；
• 是否考虑了开发的技术风险；
• 是否考虑过软件需求的其他方案；
• 是否考虑过将来可能会提出的软件需求；
• 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
• 有没有遗漏、重复或不一致的地方；
• 用户是否审查了初步的用户手册或原型；
• 项目开发计划中的估算是否受到了影响；

55、需求说明书评测

编制良好的需求说明书8条原则。

原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。

原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

原则3：如果目标软件只是一个大系统中的一个元素，那么整个系统也包括在规格说明的描述之中。

原则4：规格说明必须包括系统运行的环境。

原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

原则6：规格说明必须是可操作的。

原则7：规格说明必须容许不完备性并允许扩充。

原则8：规格说明必须局部化和松散的耦合。

56、需求说明书的框架

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

57、需求说明书评测内容。

需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：

（1）系统定义的目标是否与用户的要求一致；

（2）系统需求分析阶段提供的文档资料是否齐全；

（3）文档中的所有描述是否完整、清晰，准确地反映用户要求；

（4）与所有其他系统成份的重要接口是否都已经描述；

（5）被开发项目的数据流与数据结构是否足够、确定；

（6）所有图表是否清楚，在不补充说明时能否理解；

（7）主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

（8）软件的行为和它必须处理的信息、必须完成的功能是否一致；

（9）设计的约束条件或限制条件是否符合实际；

（10）是否考虑了开发的技术风险；

（11）是否考虑过软件需求的其他方案；

（12）是否考虑过将来可能会提出的软件需求；

（13）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

（14）有没有遗漏、重复或不一致的地方；

（15）用户是否审查了初步的用户手册或原型；

（16）项目开发计划中的估算是否受到了影响。

58、概要设计说明书评测

设计说明书的框架

设计说明书的框架内容：

（1）可追溯性

（2）接口

（3）风险

（4）实用性

（5）技术清晰度

（6）可维护性

（7）质量

（8）各种选择方案

（9）限制

（10）其他具体问题

59、软件编码规范评测

程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构的输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。

60、源程序文档化

（1）符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。

（2）程序的注释。注释分为序言性注释和功能性注释。

（3）标准的书写格式。

61、数据说明

（1）数据说明的次序应当规范化。

（2）说明语句中变量安排有序化。

（3）使用注释说明复杂数据结构。

62、语句结构

在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

63、输入和输出

输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

64、开发阶段

单元测试内容：

在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之黑盒测试的测试用例。

使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

在单元测试中进行的测试工作如图2-9所示，需要在五个方面对所测模块进行检查。

在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

65、模块接口测试

在单元测试的开始，应对通过所测模块的数据流进行测试；
如果数据不能正确的输入和输出，就谈不上进行其他测试；
对模块接口可能需要如下的测试项目：
（1）调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；
（2）是否修改了只作输入用的形式参数；
（3）输出给标准函数的参数在个数、属性、顺序上是否正确；
全局量的定义在各模块中是否一致；
（4）限制是否通过形式参数来传送；

66、局部数据结构测试
模块的局部数据是最常见的错误来源，应设计测试用例以检查以下各种错误：
（1）不正确或不一致的数据类型说明；
（2）使用尚未赋值或尚未初始化的变量；
（3）错误的初始值或错误的缺省值；
（4）变量名拼写错或书写错；
（5）不一致的数据类型

67、路径测试
常见不正确的计算有：
（1）运算的有限次序不正确或误解了运算的优先次序；
（2）运算的方式错，即运算的对象彼此在类型上不相容；
（3）算法错：初始化不正确；
（4）运算精度不够；
（5）表达式的符号表示不正确；

68、错误处理测试
比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。模块和错误处理功能包含有错误或缺陷：
（1）出错的描述难以理解；
（2）出错的描述不足以对错误定位，不足以确定出错的原因；
（3）显示的错误与实际的错误不符；
（4）对错误条件的处理不正确；
（5）在对错误进行处理之前，错误条件已经引起系统的干预等；

69、边界测试
单元测试的步骤：
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块，这些辅助模块分为两种：
（1）驱动模块
相当于所测模块的主程序。它接收测试，把这些数据传送给所测模块，最后在输出实测结果；
（2）桩模块

也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

70、集成测试
集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
组装时要考虑的问题：
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3）各个子功能组合起来，能否达到预期要求的父功能；
（4）全局数据结构是否有问题；
（5）单个模块的误差累计起来，是否会放大，以至达到不能接受的程度；

71、确认测试

确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试结构进行。

进行有效性测试

有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。通过实施预订的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时，对其他软件需求，例如可移植性、可靠性、易用性、兼容性、可维护性等，也都要进行测试，确认是否满足。

在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。

(1)测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符，从而接受了这部分程序；

（2）测试结果与预期的结果不符。这说明软件的这部分功能或性能与需求规格说明书不相符，因此要为它提交一份问题报告；

软件配置复查

72、系统测试

系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行环境下，对计算机系统进行一系列测试；

73、验收测试

验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试；

74、软件验证与确认过程

软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途和用户需要。软件的V&V过程包括软件产品和过程的分析、评价、评审、审核、评估和测试。

软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务与管理也要符合软件V&V过程的有关规定。下面重点介绍软件V& V中的测试过程与管理；

V&V基本概念

验证：通过检查和提供客观证据，证实规定的需求已满足；

确认：通过检查和提供客观证据，证实预期用途的需求是否得到满足；

独立验证和确认由在技术、管理和财务上与开发组织有关规定程度独立性的组织执行的V&V过程；

74、软件V&V过程中的测试

测试过程包括：测试计划过程、测试设计过程、测试执行过程和测试结束过程；

75、软件失效分类与管理

软件失效分类：

软件错误

软件缺陷

软件故障

软件失效（软件错误—>软件缺陷—>软件故障—>软件失效）

软件错误是指在软件生存周期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是另一种外部行为。

软件缺陷存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定

条件时出现软件故障，这时称软件缺陷激动。

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。

软件失效是指软件运行时产生一种不希望或不可接受的外部行为结果。

76、缺陷与错误严重性和优先级

软件存在的缺陷与错误会带来软件失败的风险，重要软件故障与失效会导致重大经济损失与灾难。在报告软件缺陷时，一般要讲明如何处置它们。测试员要对软件缺陷分类，以简明扼要的方式指出其影像，以及修改的优先次序；

软件缺陷与错误划分严重性和优先级的通用原则是：

（1）标识软件缺陷所造成的的危害的恶劣程度；

（2）优先级标识修复缺陷的重要程序与次序；

77、严重级

严重：系统崩溃、数据丢失、数据损坏；

较严重：操作性错误、错误结果、遗漏功能；

一般：小问题、错别字、UI布局、罕见故障；

78、优先级

最高优先级：立即修复，停止进一步测试；

次高优先级：在产品发布之前必须修复；

中等优先级：如果时间允许应该修复；

最低等优先级：可能会修复，但是也能发布；

79、软件错误跟踪管理

软件测试的主要目的在于发现软件存在的错误，如何处理测试中发现的错误，将直接影响到测试的效果；只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合要求设计的目标。在实际的软件测试过程中，每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节；

错误跟踪管理

为了正确地跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条记录输入指定的错误跟踪管理系统；

作为一个错误跟踪管理系统，需要正确记录错误信息和错误处理信息的全部内容；

一、Bug记录信息

主要包括以下几项内容：

（1）测试软件名称；

（2）测试版本号；

（3）测试人名称；

（4）测试事件；

（5）测试软件和硬件配置环境；

（6）发现软件错误的类型；

（7）错误的严重等级；

（8）详细步骤；

（9）必要的附图；

（10）测试注释；

二、Bug处理信息

主要包括以下4项内容：

（1）处理者姓名；

（2）处理时间；

（3）处理步骤；

（4）错误记录的当前状态；

三、软件错误的状态

新信息（New）：测试中新报告的软件Bug；

打开（Open）：被确认并分配给相关开发人员处理；

修正（Fixed）：开发人员已完成修正，等待测试人员验证；

拒绝（Declined）:拒绝修改Bug；

延期（Deferred）：不在 当前版本修复的错误，下一步修复；

关闭（Closed）：Bug已被修复

80、错误管理流程

错误管理的流程可以概括为以下几项内容：

（1）测试人员提交新的错误入库，错误状态为“New”；

（2）高级测试人员验证错误；

如果确认是错误，分配给相应的开发人员，设置状态为“Open”；

如果不是错误，则拒绝，设置为“Declined”状态；

（3）开发人员查询状态为“Open”的错误，做如下处理。

如果不是错误，则置状态为“Declined”；

如果是错误，则修复并置状态为“Fixed”；

如果不能解决的错误，要留下文字说明并保持错误为“open”状态；

对于不能解决和延期解决的错误，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可；

（4）测试人员查询状态为“Fixed”的错误，验证错误是否已解决，做如下处理：

如问题解决了，置错误的状态为“Closed”；

如问题没有解决，则置状态为“Reopen”；

81、白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预订要求正确工作。

82、黑盒测试

黑盒测试也称为功能测试，它是通过测试来检测每个功能是否都正常使用。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑内部结构和内部特性的情况下，在程序接口进行测试，它只是检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和功能进行测试。

83、黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误：

功能不正确或遗漏；

界面错误；

数据库访问错误；

性能错误；

初始化和终止错误；

黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动方法、正交实验设计法、功能图法等。

84、自动化测试的基本概念

自动化测试的定义：通过测试工具或其他手段，按照测试工程师的预订计划对软件产品进行自动的测试，它是软件测试的一个重要部分，它能够完成许多手工无法完成或难以实现的一些测试。正确、合理地实施自动化测试，能够快速、全面地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。

85、自动化测试的优势

避免重复测试，同时，还能完成大量手工无法完成的测试工作，如并发用户测试、大数据量测试、长时间运行可靠性测试等，优点：

（1）提高测试质量；

（2）提高测试效率、缩短测试工作时间；

（3）提高测试覆盖率；

（4）执行手工测试不能完成的测试任务；

（5）更好地重现软件缺陷的能力；

（5）更好地利用资源；

（6）增进测试人员与开发人员之间的合作伙伴关系；

以下项目和环境中更适合使用自动化测试工具：

需要反复进行的工作；

负载压力测试；

测试人员和开发人员有效合作借助测试管理工具，会取得事半功倍的效果；

若需要进行测试系统后台或者内部的性能特性，进而进行故障定位和性能调优；

86、选择合适的自动化测试工具

自动化测试工具分类：

负载压力测试工具；

功能测试工具；

白盒测试工具；

网络测试工具；

测试管理工具；

测试辅助工具；

87、自动化测试应用策略

在测试过程中应用测试工具最主要有以下几个目的：

提高测试质量；

减少测试过程中的重复劳动；

实现测试自动化，解决手工测试不能解决的问题；

88、功能自动化

测试原理：

功能自动化测试工具基本上都是采取录制回放的方式模拟用户的实际操作。当你在软件操作中点击图形用户界面上的对象时，测试工具会用一种类C或者其他脚本语言（TSL）生成一个测试脚本，改脚本记录了你的操作过程，然后工具就可以回放刚才的操作过程。测试工具采取两种录制模式：

（1）环境判断模式

这种模式根据你选取的图形用户界面对象（对窗体、清单、按钮等），把你对软件的操作动作录制下来，每一次你对被测软件进行操作，测试脚本语言会记录并描述你选取的对象和你的操作动作。当你进行录制时，测试工具会对你选取的每个对象做惟一描述并写入相应的文件中。回放时，测试工具从指定文件中读取对象描述，并在被测软件中查找符合这些描述的对象并模拟用户使用鼠标选取该对象、用键盘输入数据的操作。

（2）模拟模式

这种模拟记录鼠标点击、键盘输入和鼠标在二维平面上的精确运动轨迹。执行测试时，测试工具让鼠标根据轨迹运行；

通常情况下，其实实施测试必须经历的几个操作步骤如下：

（1）创建脚本。你可以通过录制、编程或两者同用的方式创建测试脚本。测试工具可以自动记录你的操作并生成所需的脚本代码，你还可以直接修改测试脚本以满足各种复杂的测试需求，录制测试时，在需要检查软件反应的地方插入检查点。在这个过程中，测试工具会自动捕捉数据，并将该数据作为期望结果存储下来。

（2）调式脚本：脚本录制或编辑结束后，可以现在调试模式下运行脚本。并可以设置中断点来监测变量，控制对象识别和隔离错误。

（3）执行测试：脚本调式结束后，便可以在检验模式下测试被测软件。运行测试时，测试工具会自动操作应用程序，就像一个真实的用户根据业务流程执行着每一步的操作。此时，测试工具在运行脚本过程中如果遇到了检查点，就把当前数据和事先捕捉并保存的期望值进行比较。

（4）结果分析：每次测试结束，测试工具都会把测试情况显示在测试结果报告中

89、负载压力自动化测试

负载测试是为了证明在与产品（预期）规模等同的数据库中处理给定的事务请求的容量下，系统功能与性能是否与需求规格说明中规定的，可接受的响应时间一致的测试过程。而压力测试则是使客户机在大容量情况下运行的测试过程，目的是查看应用将在何时何处出现中断，即识别系统的薄弱环节。

负载压力测试工具基本上都是采取录制回放的方式来模拟用户的实际操作，而且测试工具一般都会有一个后台代理进程，通过该代理进程，测试工具可以监视并获取在各种通信协议下应用系统的客户与服务器的通信信息，测试工具会用一类C或者其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你对服务器的请求过程，然后测试工具就可以回放刚才的访问过程，接收服务器的响应，当然你也可以用手工编程生成这个脚本。

同时，控制台还可以通过服务器上开启的远程RPC服务，获取相关的资源使用信息，最后还可以收集测试数据。

在进行测试脚本录制与分配的过程中，应遵循如下几个原则：

（1）脚本越小越好；

（2）选择负载压力最高的业务功能进行测试；

（3）选择所需要的操作进行录制；

测试工具模拟多用户并发访问可以有以下两种方式：

（1）进程回放模式；

（2）线程回放模式；

操作步骤如下：

（1）协议选择；

（2）创建测试脚本；

（3）参数化测试数据；

（4）创建虚拟用户，设定负载方案；

（5）执行测试；

（6）结果分析；

1、质量的定义

反映实体满足明确和隐含的需要的能力特性的总和。

2、质量是多维的概念，包括：实体、实体的属性和对实体的观点；

质量实体特性的总和，满足明确或隐含要求的能力

3、测度与度量

测量需要首先建立质量指标体系或质量模型，然后使用特定测量方法才能实施测量。

测度的运用时间里测量方法的依据，也是解决软件质量测量的关键；

在软件质量中用于测量一种量化的标度和方法即为“测度”，而名词的“度量”用来指测量的结果；

4、软件质量模型

影响软件质量的因素可以分为两大类：可直接测量（如每个功能点的错误）和间接度量（如可用性、可维护性）。

5、McCall质量模型

集中在软件产品的三个重要方面：操作特性（产品运行）、承受可改变能力（产品修订）、新环境适应能力（产品变迁）。

6、软件产品质量评价标准GB/T 16260-1996。它是一个分层质量模型，有6个影响质量的特性。

7、国际标准化组织1991年颁布了ISO-9126-1991标准《软件产品评价—质量特性及其使用指南》。我国也于1996发布了同样的软件产品质量评价标准GB/T16260-1996。它是一个分层质量模型，有6个影响质量的特性。如图所示说明了质量特性与质量子特性的层次结构。

产品评价：注重软件质量评价的支持和评价过程；

产品质量：注重软件本身的质量度量模型。

软件质量评价的基本部分包括：质量模型、评价方法、软件的测量和支持工具。

标准的软件质量测度是这样建立的：软件质量模型分三个层次，第一层有6个影响软件质量的主要因素，称为“质量特性”。每个质量特性又可通过第二层的若干个子特性测量，第二层的每个子特性在评价时要定义并实施若干个度量。ISO9126资料性的附录中给出21个子特性。

8、评价需求

软件质量评价的目的是为了直接支持开发和获得满足用户和消费者要求的软件。最终目标是保证产品能提供所要求的质量，即满足用户（包括操作者、软件结果的接受者，或软件的维护者）明确和隐含的要求。

（1）评价中间产品质量的目的

决定（是否）接受分包商交付的中间产品；

决定某个过程的完成，以及何时把产品送交下个过程；

预计或估计最终产品的质量；

手机中间产品的信息以便控制和管理过程；

（2）评价最终产品质量的目的

决定是否接受产品；

决定何时发布产品；

与相互竞争的产品进行比较；

从众多可选的产品中选择一种产品；

使用产品时评估产品积极和消极的影响；

决定何时增强或替换该产品；

9、确定要评价产品的类型

10、规定质量模型

GB/T16260.1提供了一个通用模型，它定义了6种软件质量特性，包括功能性、可靠性、易用性、效率、可维护性和可移植性。

11、规定评价

（1）选择度量；

（2）测量的种类；

评价有两个主要目的：

确定问题以便解决问题；

与可替换的产品进行比较，或对照需求比较产品质量；

（3）确立度量评定等级；

（4）确立评估准则；

12、GB/T16260.1产品质量

GB/T16260-2003《软件工程 产品质量》。标准由以下4部分组成：

质量模型、外部度量、内部度量、使用质量度量。

13、基本组成

GB/T16260-2003《软件工程 产品质量》。该系列标准由以下4部分组成。

GB/T16260.1《软件工程 产品质量》第1部分，质量模型。

GB/T16260.1《软件工程 产品质量》第2部分，外部质量。

GB/T16260.1《软件工程 产品质量》第3部分，内部质量。

GB/T16260.1《软件工程 产品质量》第4部分，使用质量度量。

14、标准的范围

标准可从软件的获取、需求、开发、使用、评价、支持、维护、质量保证和审核相关的不同观点来确定和评价软件产品的质量；

本标准中定义的质量模型使用实例是：

确认需求定义的完整性；

确定软件需求；

确定软件设计目标；

确定软件测试目标；

确定质量保证准则；

为完整的软件产品确定验收准则；

15、质量模型框架

软件质量特性与度量

质量特性和子特性GB/T16260.1）；

外部度量（GB/T16260.2）；

内部度量（GB/T16260.3）；