目录

软件测试定义、原则

全程质量保证

软件测试流程

软件测试启动和结束准则

软件测试沟通技巧

软件测试定义

• 软件测试的目标应该服从于软件项目的目标。软件测试通过使用更高效的方法和工具，提升软件开发效率及软件开发质量。
• 在规定条件下对软件系统进行审核、运行和评估，验证软件系统是都满足需求。
• 预防、发现、跟踪软件的缺陷，提高产品质量。
• 软件测试通过技术手段，更早、更快、更多的发现缺陷，从而降低这些缺陷可能带来的风险。

软件测试原则–思维

• 发现尽可能多的缺陷，不是为了说明软件中没有缺陷。
• 成功的测试在于发现了迄今为止未发现的缺陷。—-追求
• 测试绝不能证明软件100%正确，即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在软件中。
• 评审–>头脑风暴–>交叉测试                例如：5个人，10个人
• 测试越早，发现问题后解决问题的成本越小。

软件测试原则

1. 测试工作是有计划的，应尽早开展测试工作。–测试计划
2. 尽量避免测试自己开发的程序。
3. 测试只能证明缺陷存在，不能证明缺陷不存在。
4. “彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。
5. 测试都应追溯到用户追求。
6. 测试设计和测试执行应该进行分离。
7. 软件缺陷具有免疫性，应尽早可能采用多种方法和数据对软件进行测试。

（标准意义上测试应从需求评审开始）

推荐书籍：《人人都是产品经理》前三章

全程软件质量保证

• 决定软件质量的关键因素由需求分析、设计和实现等，测试是贯穿于上述过程的一种检查手段；
• 测试是提高软件质量最直接的手段，但不是全部，软件开发生命周期中的各个环节都会影响到软件的质量；
• 测试能提高软件的质量，但是提高软件质量不能完全依赖测试。 

如何进行高效的测试

• 测试工程师可以尝试通过一些持续集成的手段，尽早地开展测试活动，还可以加入自动化技术，通过不断、反复地测试来发现更多的缺陷。
• 以下两个方面都是有效提高软件质量的重要手段：

1. 测试可以做到对缺陷的预防。
2. 测试需要对缺陷进行检查。

• 一个高质量的软件系统是设计和开发出来的，并不是测试出来的。

 软件测试与软件缺陷

• 软件缺陷被测试工程师和开发工程师们称作Bug。
• 软件缺陷会导致软件不能正常运行，它的存在会在一定程序上导致软件不能满足用户的需求，甚至有可能破坏或泄露用户的重要数据。
• 虽然软件测试为了消灭软件缺陷，但是迄今为止，还没有一种有效的软件缺陷检测机制可以完全达到这个目标。

为什么软件缺陷无法完全消除

1. 软件运行的环境多种多样；
2. 逻辑关系复杂；
3. 多种多样的数据结构等因素；

• 都决定着软件测试活动不可能通过遍历所有的功能和使用场景来发现软件系统中所有的缺陷。
• 在软件开发的每个环节都可能把软件缺陷引入系统中，通过测试只能发布部分缺陷，并不能检测到系统中的所有缺陷。

80-20原则

• 80%的缺陷聚集在20%的模块中，经常出错的模块改错后还会经常出错。

软件测试流程图

                                                                                                                                                  如何进行测试执行或开展的/p>

撰写测试报告改为 撰写测试缺陷报告

 软件测试流程图详解

软件测试规范流程细化

 敏捷测试流程图

每一轮都要发布一个可使用的产品。对测试人员技能要求高，其他方面（原理）一样。

测试启动准则

• 同时满足以下条件，允许开始测试：

1. 测试计划已经制定并且通过了审批；
2. 测试用例已经设计并且并且通过了审批；
3. 被测对象已经开发完毕并等待测试。

测试何时结束

1. 基于测试用例的规则：8000个用例；
2. 基于“测试期缺陷密度”的规则：5天总bug数小于多少个，没有严重的bug；
3. 基于“运行期缺陷密度”的规则

测试完成准则

• 对于非严格系统可以采用“基于测试用例”的准则。同时满足以下条件允许结束测试：

(1)功能性测试用例通过率达到100%；

(2)非功能性测试用例通过率达到90%时。

• 对于严格系统，应当补充“基于测试期缺陷密度”的规则：

(3)n天内“测试期缺陷密度”全部低于某个值m。

测试沟通

开发人员的注意事项：

1. 不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。
2. 不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。

测试人员的注意事项：

1. 发现缺陷是不要嘲笑开发人员，别说他的程序真臭、到处是Bug。
2. 在开发人员压力太大时或者心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。

• 另一种极端：如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。

需求、类型、阶段、策略

软件测试需求

软件测试的对象

软件测试阶段

软件测试策略

探索式软件测试

企业软件测试人员组织

软件测试应该从需求开始

软件测试的对象

• 软件是由文档、数据以及程序组成的 。
• 测试应该是对文档、数据以及程序进行的测试。
• 60%以上的软件错误并不是程序错误，而是分析和设计错误。
• 测试概念扩大化，提倡软件全生命周期测试的理念。

软件测试阶段

单元测试、集成测试、系统测试、验收测试是“从小到大”、“由内而外”、“循序渐进”的测试过程，体现了“分而治之”的思想。

软件测试阶段详解

1. 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
2. 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
3. 系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
4. 验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。

 

软件测试阶段对照表 

测试阶段	主要依据	测试人员、测试方法	主要测试内容
单元测试	系统设计文档	由开发小组执行白盒测试	接口测试、路径测试
集成测试	系统设计文档 需求文档	由开发小组执行白盒测试和黑盒测试	接口测试、路径测试 功能测试、性能测试
系统测试	需求文档	由独立测试小组执行黑盒测试	功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试
验收测试	需求文档	由用户执行黑盒测试

 

 测试人员组织

• 如何组织测试人员：应当视企业的人力资源而定

1. 条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。
2. 条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。
3. 条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。
4. 条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好。

 测试优先级选择

1. 哪些功能是软件的特色/li>
2. 哪些功能是用户最常用的/li>
3. 如果系统可以分块卖的话，哪些功能块在销售时最昂贵/li>
4. 哪些功能出错将导致用户不满或索赔/li>
5. 哪些程序是最复杂、最容易出错的/li>
6. 哪些程序是相对独立，应当提前测试的/li>
7. 哪些程序最容易扩散错误/li>
8. 哪些程序是全系统的性能瓶颈所在/li>
9. 哪些程序是开发者最没有信心的/li>

 探索式测试

测试人员在测试程序中可以天马行空地设计和执行测试，利用应用程序所提供的信息自由发挥，没有限制，不受任何约束地探索程序的各种功能。

关注重点

1. 输入
2. 状态
3. 代码路径/业务逻辑
4. 用户数据
5. 执行环境

合法输入&非法输入

明确哪些是合法输入，哪些是非法输入。

关注程序对于非常输入的处理、反应。

            处理输入的二种方式：

1. 输入筛选器
2. 输入检查

输入筛选器

用于防止非法的输入值传递给程序。

列表框、下拉框是常用的输入筛选器。

            测试关注点：

1. 提供的输入选项本身是否正确；
2. 是否可以绕过筛选器的屏蔽而进入系统

使用输出来指导输入选择

首先把所有的输出结果罗列出来；

然后确定哪些输入会引发这些输出；

该方法可以保证重要的场景都被测试。

状态

软件的一个状态就是状态空间中的一个点，由它所有内部数据结构的取值来唯一确定。

实例：

12306网站，首次订票和第二次订同一张票，是完全不同的两个状态，应该视为两个不同的用户场景，分别设计不             同的测试用例。

用户数据

创建一个含有特定数据的测试环境，含有的数据应该和软件真实使用的数据尽量相似。

常用的方法是取得用户的数据导入测试环境中。

运行环境

软件运行的环境本身也是一种输入源，测试人员在产品发布之前应尽量尝试各种各样的用户环境。

单元测试：

也叫模块测试，对源程序中每一个程序单元进行测试，检查各个模块是否正确实现规定的功能，从而发现模块在编码中或算法中的错误。该阶段设计编码和详细设计文档。

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

在单元测试中进行的测试工作需要在五个方面对被测模块进行检查。

1.模块接口测试：

对通过被测模块的数据流进行测试。为此对模块接口，包括参数表，调用子模块的参数、全程数据、文件输入/输出操作都必须检查。模块接口测试是单元测试的基础，主要检查数据能否正确地通过模块。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。

• 测试接口正确与否应该考虑下列因素：

1. 输入的实际参数与形式参数的个数是否相同；
2. 输入的实际参数与形式参数的属性是否匹配；
3. 输入的实际参数与形式参数的量纲是否一致；量纲详解
4. 调用其他模块时所给实际参数的个数是否与被调模块的形式参数个数相同；
5. 调用其他模块时所给实际参数的个数是否与被调模块的形式参数属性匹配；
6. 调用其他模块时所给实际参数的个数是否与被调模块的形式参数量纲一致；
7. 调用预定义函数时所用参数的个数、属性和次序是否正确；
8. 是否存在与当前入口无关的参数引用；
9. 是否修改了只读型参数；
10. 对全程变量的定义各模块是否一致；
11. 是否把某些约束作为参数传递。

• 如果模块内包括外部输入输出，还应该考虑下列因素：

1. 文件属性是否正确；
2. 打开或关闭语句是否正确；
3. 格式说明与输入输出语句是否匹配；
4. 缓冲区大小与记录长度是否匹配；
5. 文件使用前是否已经打开；
6. 是否处理了文件尾；
7. 是否处理了输入/输出错误；
8. 输出信息中是否有文字性错误。

对模块接口可能需要如下的测试项目有:

• 调用本模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；
• 本模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只做输入用的形式参数‘输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传送。
• 当模块通过外部设备进行输入/输出操作时，必须附加如下的测试项目：文件属性是否正确；OPEN语句与CLOSE语句是否正确；规定的I/O格式说明与I/O语句是否匹配；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写/输入错误，以及I/O错误是否检查并做了处理。

2.局部数据结构测试

• 检查局部数据结构是为了保证临时存储在模块内的数据在程序执行中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

1. 不合适或不相容的类型说明；
2. 变量无初值；
3. 变量初始化或缺省值有错；
4. 不正确的变量名（拼错或不正确的截断）；
5. 出现上溢、下溢和地址异常。
6. 除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（FORTRAN的公用区）对模块的影响。

3.重要的执行路径测试

在模块中应对每一条独立执行路径进行测试。单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误，其中基本路径测试和循环测试是最常用且最有效的测试技术。

• 计算中常见的错误包括：

1. 误解或用错了算符优先级；
2. 混合类型运算；
3. 变量初值错；
4. 精度不够；
5. 表达式符号错。

• 比较判断与控制流常常紧密相关、测试用例还应致力于发现下列错误：

1. 不同数据类型的对象之间进行比较；
2. 错误地使用逻辑运算符或优先级；
3. 因计算机表现的局限性，期望理论上相等而实际上不相等的两个量相等；
4. 比较运算或变量出错；
5. 循环终止条件或不可能出现；
6. 迭代发散时不能退出；
7. 错误地修改了循环变量。

4.错误处理测试

• 一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：

1. 输出的出错信息难以理解；
2. 记录的错误与实际遇到的错误不相符；
3. 在程序自定义的出错处理段运行之前，系统已介入；
4. 异常处理不当；
5. 错误陈述中未能提供足够的定位出错信息。

5.边界条件测试

• 测试的方法是为被测试模块编写驱动模块和桩模块来实现被测试单元的可运行。
• 通过驱动模块来模拟被测试模块的上级调用模块，以上级模块调用被测模块的格式驱动被测模块，接收被测模块的测试结构并输出。
• 桩模块则用来代替被测模块所调用的模块。它的作用是返回被测模块所需的信息。
• 边界条件测试是单元测试中最后一项任务，也是最重要的一项任务。
• 众所周知，软件经常在边界上失败，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

单元测试方法

• 一般单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试，测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述错误的可能性。在确定测试用例的同时，应给出期望结果。
• 由于被测的模块往往不是独立的程序，它处于整个软件结构的某一层上，被其他模块调用或调用其他没看，其本身不能单独运行，因此在单元测试时，应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub），如图显示了一般单元测试的环境。

 

• 驱动模块的作用是用来模拟被测模块的上级调用模块，功能要比真正的上级模块简单得多，它接收测试程序并将这些数据传递到被测试模块，被测试模块被调用后，打印“进入-退出”消息。桩模块用来代替被测模块所调用的模块，用以返回被测模块所需的信息。
• 驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，其编写需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块并不能完成某些模块的测试任务，这些模块的单元测试只能采用后面讨论的集成测试方法。

集成测试：

集成测试是测试和组装软件的系统化技术，其主要目标是发现与接口有关的问题。如：数据穿过接口时可能丢失；一个模块对另一个模块由于疏忽可能造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等等。集成测试：是为了检查与设计相关的软件体系结构的有关问题，也就是检查概要设计是否合理有效。

集成测试完成的标志包括成功地执行了测试计划中规定的所有集成测试；修正了所发现的错误；测试结果通过了专门小组的评审。

在集成测试过程中可能查到错误类型有：接口实现有错；访问全局变量引起模块间的相互干扰；损害了文件和数据结构的完整性；不适当地把控和排列数据模块；出错处理不适当或不正确。在组装测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：

1. 满足某些软件需求；
2. 在程序的模块结构中位于较高的层次（高层控制模块）；
3. 较复杂、较易发生错误；
4. 有明确定义的性能要求。

在做回归测试时，也应该集中测试关键模块的功能。集成测试赛应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。在完成预定的集成测试工作之后，测试小组应负责对测试结果整理、分析，形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供评审和最终决策，以提出处理意见。集成测试需要提交的文档有：集成测试计划、集成测试规格说明、集成测试分析报告。

集成测试方法

一、非渐增式测试方法

非渐增式测试方法指先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序进行测试。

二、渐增式测试方法

先把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法实际上同时完成单元测试和集成测试。目前在经常集成测试时普遍采用渐增式测试方法，渐增方式把模块结合到程序中去时，有自顶向下和自顶向上两种继承策略。但是实践中常采用混合的策略。

三、回归测试

任何成功的测试都会发现错误，而且错误必须被改正。每当改正软件错误的时候，软件配置的某些成分（程序、文档或数据）也被修改了。回归测试就是用于保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。

即：回归测试是指重新执行已经做过测试的某个子集，以保证修改变化没有带来非预期的副作用。

回归测试集（已经执行过的测试用例的子集）包括下述3类不同的测试用例：

1. 检查软件全部功能的代表性测试用例；
2. 专门针对可能受修改影响的软件功能的附件测试；
3. 针对被修改过的软件成分的测试。

• 时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作，其主要原因是模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块可能对另一个模块造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误等等。集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。
• 某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱，因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。增量式集成方法主要包括自顶向下和自顶向上集成两种类型。

自顶向下集成

自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略优先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。在下图，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。

自顶向下集成测试的具体步骤 如下：

1. 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；
2. 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；
3. 每集成一个模块立即测试一遍；
4. 只有每组测试完成后，才着手替换下一个桩模块；
5. 为避免引入新错误，需不断地进行回归测试，即全部或部分地重复已做过的测试。

从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕，如上图中，实线表示一部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。

自顶向下集成的优点是能尽早地对程序的主要控制和决策机制进行检验，因此较早的发现错误。缺点是在测试较高模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种方法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，是错误难于定位和纠正，并且师傅了在组装模块时进行一些特定测试的可能性；第二种方法无疑大大增加开销；第三种方法比较切实可行。

自底向上集成

自底向上集成是从软件结构最底层的模块开始组装测试，因测试到较高层模块，所需的下层模块功能均已具备，所以不再需要桩模块。

自底向上综合测试的步骤分为：

1. 把低层模块组织成实现某个子功能的模块群（cluster）；
2. 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
3. 对每个模块群进行测试；
4. 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。

从第一步开始循环执行上述各步骤，直至整个程序构造完毕。

下图说明了上述各步骤，即首先最底层模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此驱动模块D1、D2去掉后，模块群1与模块群12直接与Ma接口。同样，在模块群3与Mb接口前去掉D3，最后Ma、Mb和Mc全部集成在一起进行测试。

自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象，它与自顶向下综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混合使用两种策略更为有效，上层模块自顶向下的方法，下层模块用自底向上的方法。

系统测试 

计算机软件是基于计算机系统的一个重要组成部分，软件开发完成后应与系统中其他成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅有软件开发人员完成。

在系统测试之前，软件工程师完成系列工作：

1. 为测试软件系统的输入信息设计出错处理通路；

2. 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；

3. 参与系统测试的规划和设计，保证软件测试的合理性。

系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。

恢复测试

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

安全测试

安全测试检查系统对非法侵入的防范能力，安全测试期间，测试人员假扮测试入侵者，采用各种办法试图突破防线。例如：

1. 想方设法截取或破译口令；
2. 专门定做软件破坏系统的保护机制；
3. 故意导致系统失败，企图趁恢复之机非法侵入；
4. 试图通过浏览非保密数据，推导所需信息等等。

理论上讲，只要有足够时间和资源，没有不可进入的系统。因此，系统安全设计的准则是使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。

强度测试

强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如：

1. 当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；
2. 定量地增长数据输入率，检查输入子功能的反映能力；
3. 运行需要最大存储空间（或其他资源）的测试用例；
4. 运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例等等。

性能测试

对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真是环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

所谓系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起。在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析规格说明来设计，并在实际使用环境下来运行。

1.可靠性测试（Reliability Testing）

如果系统需求说明书中有对可靠性的要求，则需进行可靠性测试。

2.强度测试（Stress Testing）

强度测试是要在系统运行环境不正常到发生故障的情况下，系统可以运行到何种程度的测试。强度测试的一个变种就是敏感性测试。在数学算法中经常可以看到，在程序有效数据界限内一个非常小的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降的情况发生。因此利用敏感性测试以发现在有效输入类中可能引起某种不稳定或不正常处理的某些数据的组合。

3.性能测试（Performance Testing）

性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统，软件只满足要求的功能而达不到要求的性能是不行的。所以还需要进行性能测试。性能测试可以出现在测试过程的各个阶段，甚至在单元层次上，也可以进行性能测试。这时，不但需要对单个程序的逻辑进行白盒测试（结构测试），还可以对程序的性能进行评估。然而，只有当所有系统的元素全部组装完毕，系统性能才能完全确定。性能测试常常需要与强度测试结合起来进行，并常常要求同时进行硬件和软件检测。例如，对资源利用（如处理机周期）等进行精密的度量，对执行间隔、日志事件（如中断）等进行检测。通常，对软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区，例如缓冲区、工作区的大小等、处理精度，等等。

确认测试又称有效性测试也成为验收测试

通过综合测试之后，软件已完全封装起来，接口方面的错误也已排除，这是可以开始对软件进行最后的确认测试。确认测试主要检查软件是否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

实现软件确认要通过一系列黑盒测试。确认的是同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求水墨的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

确认测试的另一个重要环节是配置复审，如下图所示，复审的目的在于保证软件配置齐全、分类有序、并且包括软件维护所必须的细节。

事实上，软件开发人员不可能完全遇见用户实际使用程序的情况，例如，用户可能命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划有系统 的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。

一个软件产品，可以拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

α测试是指软件开发公司组织内部人员模拟各类用户行为对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试测试的关键在于尽可能真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

确认测试又称有效性测试。它的任务是验证软件的有效性，即验证软件的功能和性能及其它特性是否与用户的要求一致。在软件需求规格说明书描述了全部用户可见的软件属性，其中有一节叫做有效性准则，它包含的信息就是软件确认测试的基础。

在确认测试阶段需要做的工作如下图所示，肯定要进行有效性测试以及软件配置复审，然后进行验收测试和安装测试，再通过了专家鉴定之后，才能成为可交付的软件。

 确认测试：主要检查已实现的软件是否满足需求规格说明书中的确定了的各种需求。

确认测试也称为验收测试，它的目标是验证软件的有效性。

确认（validation）:指的是为了保证软件确实满足了用户需求而进行的一系列活动。

验证（verificaion）:指的是保证软件正确地实现了某个特定要求的一系列活动。

有效性的简单定义:如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的。需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理期望，因此是软件有效性的标准，也是进行确认测试的基础。

1.确认测试的范围

确认测试必须有用户积极参与，或者以用户为主进行。用户应该参与设计测试方案，使用用户界面输入测试数据并且分析评价测试的输出结果。

确认测试通常使用黑盒测试法。应该仔细设计测试计划和测试过程，测试计划包括要进行的测试的种类及进度安排，测试过程规定了用来检测软件是否与需求一直的测试方案。

通过测试和调试要保证软件能满足所有功能要求，能达到每个性能要求，文档资料是准确而完整的，此外，还应该保证软件能满足其他预设的要求（例如，安全性、可移植性、兼容性和可维护性等）。

软件配置复查

确认测试重要的一个内容是复查软件配置。软件配置：软件需求规格说明书、软件设计规格说明、源代码等。

复查的目的是保证软件配置的所有成分都齐全，质量符合要去，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。

除了按合同规定的要求和内容，由人审查软件配置之外，在确认测试过程中还应该严格遵循用户指南及其他操作程序，以便检验这些使用手册的完整性和正确性。必须仔细记录发现的遗漏和缺陷，并且适当地补充和改正。

2.Alpha和Beta测试

Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。该测试是在受控制的环境中进行的。

Beta测试由软件的最终用户们在一个或多个客户场所进行。Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在Beta测试过程中遇到的一切问题（真实的或想象的），并且定期把这些问题报告给开发。接收到在Beta测试测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准确向全体用户发布最终的软件产品。

Alpha测试是由一个用户在开发者环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。这是在受控制的环境下进行的。Alpha测试的目的是评价软件产品的FURPS(即功能、可实用性、可靠性、性能和支持)。尤其注重产品的界面和特色。

Alpha测试是除产品开发人员之外首选见到产品的人，他们提出的功能和修改意见是特别有价值的。Alpha测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应事先准备好。

Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与Alpha测试不同的是，开发者通常不在测试现场。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记录遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最后将软件产品交付给全体用户使用。

Beta测试主要衡量产品的FURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当Alpha测试达到一定的可靠程度，才能开始Beta测试。由于它处在整个测试的最后阶段，不能指望这时发现问题。同时，产品的所有手册文本也应该在此阶段完全定稿。由Beta测试的主要目的是测试可支持性，所以Beta测试应尽可能由主持产品发行的人员来管理。

确认测试的结果有两种情况，

（1）功能和性能与用户的要求一致，软件可以接受；

（1）功能和性能与用户的要求有差距。

出现后一种情况，通常与软件需求分析阶段的差错有关。这时需要开列一张软件各项缺陷表或软件问题报告，通过与用户的协商解决所发现的缺陷和错误。

确认测试应交付的文档有：确认测试分析报告、最终的用户手册和操作手册、项目开发总结报告。

1.冒烟测试

就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。

2.回归测试

就是以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug。

我有两层理解，一是就是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug。

来源：weixin_44863926