软件测试概念复习

1.在软件测试过程中，应该遵循的原则

原则1：测试用例中一个必须部分是对预期输出或结果的定义。
原则2：程序员应当避免测试自己编写的程序。
原则3：编写软件的组织不应当测试自己编写的软件。
原则4：应当彻底检查每个测试的执行结果。
原则5：测试用例的编写不仅应当根据有效和预料到的输入结果，而且也应当根据无效和未预料的输入结果。
原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了不该做的”。
原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
原则8：计划测试工作时不应默许假定不会发现错误。
原则9：程序某部分存在更多错误的可能性，与该部分已发现的的错误数量成正比。
原则10：软件测试是一项极富创造性、极具智力挑战性的工作。
（不同教材对于测试的基本原则有所不同）

2.测试用例的设计

好的测试用例的特征

1. 可以最大程度地找出软件隐藏的缺陷
2. 可以最高效率的找出软件缺陷
3. 可以最大程度地满足测试覆盖要求
4. 既不过分复杂、也不能过分简单
5. 使软件缺陷的表现可以清楚的判定
6. 测试用例包含期望的正确的结果
7. 待查的输出结果或文件必须尽量简单明了
8. 不包含重复的测试用例
9. 测试用例内容清晰、格式一致、分类组织

测试用例的4性

测试用例的4性是指代表性、针对性、可判定性、可重现性：
代表性： 能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
针对性： 对程序中的可能存在的错误有针对性地测试
可判定性： 测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果
可重现性： 对同样的测试用例，系统的执行结果应当是相同的。

3.测试用例的原则

1. 利用成熟的测试用例设计方法来指导设计
2. 测试用例的针对性
3. 测试用例的代表性
4. 测试用例的可判定性
5. 测试用例的可重现性
6. 足够详细、准确和清晰的步骤
7. 测试用例必须符合内部的规范的要求

4.常用到的软件质量模型

Jim McCall模型（1977年）
Boehm模型（1978年）
FURPS模型
Dromey模型
ISO9126模型

5.软件测试计划

测试计划并非一成不变，而是随着项目的发展不断完善。测试计划需要按照国家标准或者行业标准的格式和内容来写。

6.制定软件测试的计划的原则

1. 制定的测试计划应尽早开始
2. 保持测试计划简洁和易读
3. 尽可能争取多渠道评审测试计划
4. 计划测试的投入

7.制定软件测试的计划的步骤

1. 分析和测试软件的需求
2. 定义测试策略
3. 定义测试环境
4. 定义测试管理
5. 编写计划文档

8.静态测试、动态测试

• 静态测试(static testing),是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程。
• 动态测试(dynamic testing)：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
  

9.白盒测试、黑盒测试以及二者的关系

白盒测试

又称为结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试全面了解程序内部结构、对所有逻辑路径进行测试。白盒测试是穷举路径测试，测试人员必须了解程序的内部结构，从检查程序的逻辑出手，从而得到测试数据。白盒测试必须遵循以下规则：

1. 一个模块所有的独立路径都需至少得到一次测试。
2. 所有的逻辑值的真与假情况都需要被测试到。
3. 为了保证程序结构的有效性，需要检查程序的内部逻辑结构。
4. 在程序的上、下边界与可操作范围内能保证循环的顺利运行。

黑盒测试

黑盒测试是一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。黑盒测试的基本观点：任何程序都能看作是输入定义域到输出值域的映射。在测试过程中，因为无法看到盒子里面的内容，所以只关心程序输出的结果。

测试人员使用黑盒测试的时候，唯一使用的信息就是软件的规格说明。黑盒测试是从用户观点出发的测试，它需要尽可能发现程序的外部错误，在已知的软件产品功能的基础上进行功能、交互、性能等方面的检测。
黑盒测试由两个重要的优点：

1. 黑盒测试与软件的具体实现无关，因此软件实现方式如果发什么变更、修改但功能测试不变的话，仍可以使用原来的测试用例。
2. 在软件开发的同时，也可以进行黑盒测试用例的设计，这样可以节省时间成本。

但是如果希望利用黑盒测试检测出所有的软件错误，只能采用穷举法，但这是不现实的，也不合理。
常见的黑盒测试方法有等价类划分、边界值设计、因果图分析和正交实验法等。

白盒测试与黑盒测试的区别

1. 已知产品因素

   1. 黑盒测试：已知程序的功能需求、设计规格，可以通过测试验证程序需要的功能是否已被实现，是否符合要求。
   2. 白盒测试：已知程序的内部工作结构，可以通过测试验证程序的内部结构是否符合要求，是否含有缺陷。

2. 检查测试的主要内容

   1. 黑盒测试主要检查的内容包括但不限于：
      功能是否都满足需求；是否有功能出现缺陷。
      接口上是否能正确接受输入；输入结果是否正确。
      是否有数据结构信息或者外部信息访问错误。
      是否有初始化或终止性错误。
   2. 白盒测试主要检查的内容包括但不限于：
      所有的程序模块的独立路径等都需要至少被测试一遍
      所有的逻辑判定的正值与假值都需要至少被测试一遍。
      在运行的界限内和循环的边界上执行循环体。
      测试内部的数据结构是否有效。

10.软件测试与软件开发的过程的关系

测试的尽早介入是软件测试的一个基本准则。软件测试是质量保证的重要手段之一，它是贯穿整个软件开发周期的。

软件测试在开发各阶段的作用：

1. 项目规划阶段：负责监控整个测试。
2. 需求分析阶段：确定测试需求分析，同时制定系统测试计划。
3. 概要设计和详细设计阶段：制定集成计划和单元测试计划。
4. 程序编写阶段：开发相应的测试代码和测试脚本。
5. 测试阶段：实时测试，并提交相应的测试报告。

11.白盒测试的覆盖准则

1. 语句覆盖：每条语句至少被执行一次
2. 判定条件覆盖：每个判断的分支取真分支和取假分支至少经历一次
3. 条件逻辑覆盖：使得判定条件都需要至少满足一次
4. 判断逻辑条件覆盖：使得每个判断取到的可能的结果，并且判断中每个条件也要取到可能的结果。判断和条件都必须满足。
5. 条件组合判断：即每个判定中条件的各种取值至少出现一次。
6. 路径覆盖：执行所有可能执行的路径。

12. 白盒测试的常用工具，各适用于什么

1. Jtest：是一个代码分析和动态类、组件测试工具，是一个集成的、易于使用的和自动化的Java单元测试工具。
2. Jcontract：在系统级验证类/部件是否正确工作并被正确使用。
3. C++Test：自动测试C和C++类、函数或组件
4. CodeWizard：是一个代码静态分析工具，先进的C/C++源代码分析工具，但是不能检查到代码结构。
5. Insure++：是一个基于C/C++的自动化内存错误、内存泄漏的精确检测工具，能够可视化内存操作，准确检测出内存泄漏产生的根源，还能覆盖性分析，指示那些代码被已经测试过。
6. .test：.TEST是专为.NET开发而推出的使用方便的自动化单元级测试与静态分析工具。
7. BoundsChecker：BoundsChecker Visual C++ Edition 是针对Visual C++开发人员的首选的运行时的错误检测和调试工具。

单元测试

单元测试又称模块测试，针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

单元测试的原则

1. F-FAST(快速原则)：单元测试应该是可以快速运行的，在各种测试方法中，单元测试的运行速度是最快的，通常应该在几分钟内运行完毕

2. I-Independent(独立原则)：单元测试应该是可以独立运行的，单元测试用例互相无强依赖，无对外部资源的强依赖

3. R-Repeatable(可重复原则)：单元测试应该可以稳定重复的运行，并且每次运行的结果都是相同的

4. S-Self Validating(自我验证原则)：单元测试应该是用例自动进行验证的，不能依赖人工验证

5. T-Timely(及时原则）：单元测试必须及时的进行编写，更新和维护，以保证用例可以随着业务代码的变化动态的保障质量

单元测试的重要性即目的

1. 保证代码质量
2. 保证代码的可维护
3. 保证代码的可扩展

单元测试主要测试问题

1. 模块接口测试
2. 局部数据结构测试
3. 路径测试
4. 错误处理测试
5. 边界条件测试

14.插桩程序设计

程序插桩是一种基本的动态测试方法。程序插桩的基本原理是在不破坏测试程序原有逻辑完整性的前提下，在程序的相应位置上插入一些探针。这些探针本质上就是进行信息采集的代码段，可以是赋值语句或采集覆盖信息的函数调用。最简单的实现方法就是在程序中加入print语句。通过探针的执行并输出程序的运行特征数据。基于这些特征数据的分析，揭示程学的内部行为和特征。

15.集成测试

集成测试的主要任务

1. 将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。
2. 将各个子功能组合起来，检查能否达到预期要求的各项功能。
3. 一个模块的功能时候会对另一个模块产生不利的影响；全局数据结构是否有问题，会不会被异常修改。
4. 单个模块的误差积累起来，是否被方法，从而达到不可接受的程度。

集成测试与单元测试，系统测试的区别

1. 单元测试：最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
   测试的重点是系统的模块，包括子程序的正确验证等。
2. 集成测试：单元测试基础上，增加静态结构分析、静态质量度量。
   将所有的模块按照设计要求，组装成子系统或系统，进行集成测试。
   测试的重点是模块间的衔接以及参数的传递等
   程序在某些局部反映不出来的问题，在全局上很可能暴露出来。
3. 系统测试：经过单元测试、集成测试的子系统装配成一个完整系统来测试。
   检验系统能提供系统方案说明书中指定功能。
   测试重点是整个系统的运行以及其他软件的兼容性。

集成测试的内容

通常在单元测试的基础上，将所有程序模块进行有序的，递增的测试，重点测试不同模块的接口部分。

集成测试的方法

1. 自下而上的测试：从应用程序的最低或最里面的单位开始，逐渐向上移动。集成测试从最低模块开始，逐步向应用程序的上层模块发展。这种集成一直持续到所有模块都集成在一起，整个应用程序作为一个单元进行测试。
2. 自上向下的方法：该技术从最顶层的模块开始，逐渐向较低的模块发展。只有顶层模块是单独进行单元测试的。在这之后，下层模块逐个集成。重复到该过程，直到所有的模块都被集成和测试。

16.系统测试

系统测试与验收测试的区别

1. 测试目的不同：确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。

   1. 系统测试的目的是发现软件潜在的问题，保证系统的正常运行。
   2. 验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

2. 测试任务不同：确认测试是为了进一步验证软件的有效性。

   1. 系统测试是经过集成测试的软件，作为系统计算机的一部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试。
   2. 验收测试是向未来的用户表明系统能够像预期要求那样工作。

3. 测试顺序不同

   确认测试和系统测试都是在集成测试之后，位于倒数第二位。
   验收测试是部署软件之前的最后一个测试操作。

4. 关系：所有的测试都是保证产品最终符合需求（包括明确要求和隐含需求），只不过粒度不一样。

系统测试的主要内容

1. 安全测试
2. 压力测试
3. 流畅度测试
4. 兼容性测试等

常见的系统测试方法

1. 黑盒测试
2. 多任务测试
3. 临界测试
4. 中断测试
5. 白盒测试

17.容量测试与压力测试的区别

1. 容量测试的目的是通过测试预先分析出软件系统应用特征的某项指标的极限值。
   容量测试是在预先分析的极限值下，系统能否正常运行。

2. 压力测试是在强负载下查看应用系统在峰值使用情况下操作行为，从而有效地发现某项功能隐患、系统是否具有良好的容错能力和可恢复能力。
   压力测试是在给系统不断加压，增加并发量，直到崩溃，找到系统所能承受的极限值。

一般情况下容量测试大多是正向测试，即是合法条件下的，而压力测试有时候是极端异常的，会导致错误的，倾向于反向测试，或者找到临界点。

18.验收测试

验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试的主要内容

1. 制定验收测试的标准
2. 复审配置项
3. 执行验收测试

19.α 测试和β测试的不同（内测与公测）

含义上的不同：

1. α 测试是一种非正式验收测试，是由一个用户在开发环境下进行的从测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
2. β测试是一种验收测试，是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动。

是否在现场测试的不同：
3. α 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。
4. 与α 测试不同，开发者通常不在β测试的现场，因β测试是软件在开发者不能控制的环境中的“真实”应用。

注意：α 测试与β测试都不能由开发者进行测试。

20.如何组织软件测试团队

1. 搞清楚软件测试团队需要多少人？
2. 确定这个团队将来要成为的类型。
3. 其次就是根据人员分工寻找能力和心里都符合的成员。
4. 组织分配工作。

软件测试团队分为四种类型：融合型、相对独立型、完全独立型、相互制约型。

1. 融合型软件测试团队是指软件测试人员和软件开发人员融为一体。
2. 相对独立型软件测试团队是指软件测试人员和软件开发人员同属于一个部门，但属于不同的小组。
3. 完全独立型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门。
4. 相互制约型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门，但测试人员和开发人员之间存在互相评价工作质量的关系。

从融合型到相互制约型，测试质量提高的同时成本也会增大。

21.软件测试人员的培养方法

合理的人才结构。既有软件开发人员，测试人员，技术人员，精通行业知识的领域专家。有明确的职责和分工。
开发者：倾向于证明软件能证明工作和本身的逻辑而不是用户的角度；清楚错误可能出现的位置，保证独立单元实现了所定义的功能，软件结构完整性得到保证。
专家：澄清需求文档中复杂的领域专业问题，保证满足用户需要。

素质和技能要求：
素质要求：

1. 责任心
2. 沟通能力
3. 团队合作精神
4. 耐心细心信心
5. 怀疑态度和预防缺陷意识
6. 不断学习能力

技能要求：

1. 业务知识
2. 产品设计知识
3. 软件结构知识
4. UML语言
5. 测试工具和开发工具
6. 用户心理学
7. 编程技能
8. 文档能力

22.文档测试主要测试内容

测试开发工程中生成的文档，以需求规格说明、软件设计、用户手册、安装手册等为主，检验原文档是否和实际存在差别，无需编写测试用例。

24.常见的黑盒测试用例的设计方法?并分别简单介绍一下各自的思想。

1. 等价类划分：将程序所有可能的输入情况划分为若干个等价类，然后从每个部分中选取具有代表性的数据作为测试用例进行合理的分类，测试用例由有效等价类和无效等价类的导表组成，从而保证测试用例具有完整性和代表性。
2. 边界值划分：确定边界情况，选取正好等于、刚刚大于过刚刚小于边界值作为测试数据。
3. 错误推测法：利用直觉和经验猜测出出错的可能类型，列举出程序中所有可能的错误和容易发生错误的清单，然后根据清单编写测试用例。
4. 因果图法：利用因果图测试所有的输入条件的排列组合。
5. 正交表试验法：从大量的试验点中挑选出适量的，有代表性的点，利用“正交表”，合理的安排试验。
6. 场景图：描述流经用例路径的过程，这个过程从开始到结束遍历用例中所有基本流和备选流。
7. 流程图：针对整个系统业务功能流程图画出业务流程和写用例。

25.恢复测试

恢复测试主要检查系统的容错能力。
当系统出错时，能否在指定时间间隔内修正错误并重新开启系统。恢复测试首先要采用各种方法强迫系统失败，然后验证系统能否尽快恢复。
对于自动回复需验证重新初始化（reinitialization）、检查点（checkpointing mechanisms）、数据恢复（data recovery）和重新启动（restart）等机制的正确性，对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

26.压力测试与强度测试

1. 压力测试：是在标准工作环境下，不断增加系统负荷，最终测试出该系统能达到的最大负荷（稳定和峰值）
2. 强度测试：是在非标准工作环境下，甚至不断人为降低系统工作环境所需要的资源，如网络带宽、系统内存、数据锁等等，以测试系统在资源不足的情况下的工作状态。

27.正确性测试

正确性测试检查软件的功能是否符合规格说明。

28.Web测试

web测试就是针对B/S结构的系统，一般指浏览器访问服务器。
包括：
功能测试：链接测试、表单测试、Cookie测试、数据库测试
性能测试：连接速度测试、负载测试、压力测试
用户界面测试：导航测试、图形测试、压力测试、整体界面测试
兼容性测试：平台测试、浏览器测试、组合测试
安全测试：
（1）目录设置：正确设置目录
（2）SSL：使用安全传送，确定是否有相应的替代页面。
（3）登录：验证系统阻止非法的用户名/口令登录。
（4）日志文件：注意验证服务器日志是否正常。
（5）脚本语言：脚本语言是常见的安全隐患。
接口测试：服务器接口、外部接口、错误处理

29.条件组合覆盖

设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次。

30.软件可靠性

软件可靠性 (software reliability )是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。规定的条件是指直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或称为软件运行时的外部输入条件；规定的时间区间是指软件的实际运行时间区间；规定功能是指为提议共给定的功能，软件产品所必须具备的功能。软件可靠性不但与软件存在的缺陷和（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量称为软件可靠度。

31.软件缺陷

软件缺陷（Defect），常常又被称为Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误、或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

软件缺陷的类别

1. 界面缺陷：界面错误，如界面显示不符合需求，提示信息不和规范等
2. 功能：系统功能无效、不响应、不符合需求
3. 性能：系统响应过慢、无法承受预期负荷等
4. 安全性：存在安全隐患的缺陷
5. 数据：数据导入或设置不正确
6. 其他：不再上述类别范围的其他错误

软件缺陷的分析流程

1. 提交：测试人员发现缺陷之后，将缺陷提交给测试组长。
2. 分配：测试组长接收到测试人员提交的缺陷之后，将其移交给开发人员。
3. 确认：开发人员接受到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷。
4. 拒绝/延期：如果经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷，如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等选择立即处理或延期处理。
5. 处理：开发人员修改缺陷
6. 复测：开发人员修改好缺陷之后，测试人员重新进行测试（复测），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。
7. 关闭：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。
   

33. 变异测试

变异测试是一种对测试集的充分性进行评估的技术，以创建更有效的测试集。变异测试与路径或者数据流测试不同，没有测试数据的选取规则。
变异测试应该与传统的测试技术结合，而不是取代它们。
说白了，就是将源程序( Parent)进行变异，产生不同的变体( Mutant)，然后再使变体运行测试用例，比较源程序与变体程序在执行过程中的差别。当执行情况与源程序的执行情况完全一样时，该变体称之为存活( Survived)；反之，执行情况有所不同，称之为杀死( Killed)。

变异测试主要用来评价测试人员的水平，通过对被测程序修改产生多少个变异体，然后检测测试人员发现变异体的不同。

34. 回归测试

回归测试是指修改了旧代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回顾测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

35. 兼容性测试

软件兼容性测试是指检查软件之间能否正确地进行交互和共享信息。随着用户对来自各种类型软件之间共享数据能力和充分利用空间同时执行多个程序能力的要求，测试软件之间能否协作变得越来越重要。软件兼容性测试工作的目标是保证软件按照用户期望的方式进行交互。

36. 第三方测试

1. 定义：第三方测试是有开发者和用户之外的第三方进行的软件测试，其目的是保证测试的客观性。
2. 职责：验证软件是否符合需求和设计、检测错误、对结果进行分类分析，将分析结果反馈给开发人员以改进软件过程管理。
3. 测试阶段：集成测试、系统测试、验收测试+单元测试由开发方做
4. 主要方法：以黑盒测试为主；手工+自动
5. 流程：
   （1）测试计划
   （2）测试设计
   （3）测试实施
   （4）测试总结
6. 第三方软件测试相关概念比较
   （1）开发者测试：思维定势、心理因素、利益驱动
   （2）用户测试：很难进行全面的功能性测试，其他的功能、并发等方面的测试
   （3）外包测试：利益不同，外包测试代表着开发者团队的利益

第三方测试有别于开发人员或用户进行的测试，其目的是为了保证测试工作的客观性。第三方测试工程主要包括需求分析审查、设计审查、代码审查、单元测试、功能测试、性能测试、可恢复性测试、资源消耗测试、并发测试、健壮性测试、安全测试、安装配置测试、可移植性测试、文档测试以及最终的验收测试等十余项。

37. 冒烟测试

是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。

冒烟测试先选择核心基础功能的测试用例进行验证，确保业务流程没有严重bug问题。

冒烟测试一般都是基础的一些功能，如果能做到自动化测试，可以集成到持续集成中，版本构建结束后，立即去执行冒烟测试，根据持续集成以及冒烟脚本的执行结果，判断版本是不是可用，是不是继续开展测试。

如果无法做到自动化测试，那冒烟测试可以由人工测试轮流负责，避免一个人长期重复做这件事情，产生惯性或者疲劳。

此外，可以将冒烟测试失败的次数、失败的原因记录下来，开发周期结束后，反向推动开发人员软件质量的改进。

38. 确认测试与验收测试

系统测试与确认测试有很多相同之处，但是 最大的差别在于考虑到系统环境因素，例如软硬件环境，人的行为模式，网络环境等等，除了功能性外对于性能、可靠性等关注较多，也主要由团队测试人员进行的；

验收测试，为用户主导实施，一般在最后阶段，即系统测试以后。

确认测试主要指的是一个阶段，但是无论怎样，都与可靠性、安全性等不冲突，因为不是一个纬度，即在确认测试阶段即可以做可靠性测试，也可以做安全测试（当然这些类型测试最好放在系统测试阶段）
验收测试是测试生命周期的最后一步，而确认测试是第三个环节。

39. 性能测试

测试软件是否到达需求规格说明书中规定的各类性能指标，并满足相关约束和限制条件。

1. 时间性能（事务响应时间等）

2. 空间性能（系统资源消耗）

3. 一般性能测试

4. 可靠性测试

5. 负载测试

6. 压力测试

40.压力测试

压力测试（强度测试）：压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

41. 负载测试

负载测试:是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。 压力测试:是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。

42. 安全测试

安全测试是在IT软件产品的生命周期，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
目的：

1. 提升IT产品的安全质量
2. 尽量在发布前找到安全问题予以修补降低成本
3. 度量安全
4. 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。

43. 自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与预期结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

自动化测试在软件项目团队中的作用举足轻重，众所周知合理地展开自动化测试，可以有效降低错误修复成本，并对软件质量保证(QA)过程起到全面推进的作用。

优点：

1. 对程序的回归测试更方便
2. 极大提高测试效率
3. 建立可靠、重复的测试，减少人为失误，更好地利用资源
4. 更好地利用资源
5. 增强测试质量和覆盖率
6. 测试的复用性
7. 增加软件的信任度

缺点：

1. 自动化测试不能取代人工测试
2. 手工测试比自动化测试发现的缺陷更多
3. 对测试质量的依赖性极大——不能用于测试周期很短的项目、不能保证100%的测试覆盖率、 不能测试不稳定的软件和软件易用性。

44. 软件质量保证

软件质量保证是贯穿软件项目整个生命周期的有计划的系统活动，经常针对整个项目质量计划执行情况进行评估，检查和改进，确保项目质量与计划保持一致。

45.逻辑覆盖

逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。

根据覆盖目标的不同和覆盖源程序语句的详尽程度，逻辑覆盖又可分为：

1. 语句覆盖(SC)

2. 判定覆盖(DC)

3. 条件覆盖(CC)

4. 条件/判定覆盖(CC)

5. 条件组合覆盖(CDC)

6. 多条件覆盖(MCC)

7. 修正判定条件覆盖(MCDC)

8. 点覆盖

9. 边覆盖

10. 路径覆盖

46. SDL

安全开发生命周期（SDL）即Security Development Lifecycle，是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。它的核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。

48. 模糊测试

模糊测试是一种介于完全的手工渗透测试与完全的自动化测试之间的安全性测试类型。它充分利用了机器的能力：随机生成和发送数据；同时，也尝试将安全专家在安全性方面的经验引入进来。从执行过程来说，模糊测试的执行过程非常简单：
测试工具通过随机或是半随机的方式生成大量数据；
测试工具将生成的数据发送给被测试的系统（输入）；
测试工具检测被测系统的状态（如是否能够响应，响应是否正确等）；
根据被测系统的状态判断是否存在潜在的安全漏洞。

49. 渗透测试

渗透测试就是一种通过模拟使用黑客的技术和方法，挖掘目标系统的安全漏洞，取得系统的控制权，访问系统的机密数据，并发现可能影响业务持续运作安全隐患的一种安全测试和评估方式。渗透测试包括黑盒测试,白盒测试和 灰盒测试。

50. SBSE

Search-Based Software Engineering）基于搜索的软件测试，从问题的解空间出发，将传统的软件工程问题转化为优化问题，并使用高性能的搜索算法，在问题所有可能解的空间中，寻找最优解或者近似最优解。常用局部搜索、模拟退火SA、遗传算法GAs、遗传规划GP、爬山HC。