软件测试的详细介绍

第1章软件测试概述

1. 软件的特点：

(1) 软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性。

(2) 软件的生产与硬件不同，它没有明显的制造过程。对软件的质量控制，必须着重在软件开发方面下功夫。

(3) 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。然而它存在退化问题，必须要对其进行多次的修改与维护。

(4) 软件的开发和运行常常受到计算机系统的制约，对计算机系统有着不同程度的依赖性。为了解除这种依赖性，在软件开发中提出了软件移植的问题。

(5) 软件的开发至今尚未完全摆脱人工的开发方式。

(6) 软件本身是复杂的。软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。

(7) 软件成本相当昂贵。软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，它的成本是比较高的。

(8) 相当多的软件工作涉及到社会因素。许多软件的开发和运行涉及机构、体制及管理方式等问题，它直接影响到项目的成败。

2. 软件的分类：

（1）按软件的功能分类

（2）按软件服务对象的范围分类

（3）按开发软件所需要的人力、时间以及完成的源程序行数分类。

（4）按软件工作方式分类

按软件的工作方式分为：实时处理软件、分时软件、交互式软件、批处理软件。

3. 软件测试的定义：

软件测试是软件工程中的一个环节，是开发项目整体的一部分。软件测试是有计划有组织的，是保证软件质量的一种手段，它是软件工程中一个非常重要的环节。因此，可以认为它是伴随软件工程的诞生而诞生的，伴随着软件复杂程度的增加、规模的增大，软件测试作为一种能够保证软件质量的有效手段，越来越受到人们的重视，软件测试最终目的是使产品达到完美。

4. 软件测试的方法：

即用试题测试、用新旧两个系统作平行处理测试和软件测试自动化工具测试。

5. 软件测试的阶段：

（1）制定测试大纲；

（2）制作测试数据；

（3）程序测试；

（4）功能测试；

（5）子系统测试；

（6）系统测试；

（7）系统接口测试；

（8）写出测试报告书；

（9）向下阶段工作提交系统运行、维护手册的草案。

6. 软件测试人员需要的知识结构：

★ 需要具有懂得计算机的基本理论，又有一定开发经验的人员；

★ 需要具有了解软件开发的基本过程和特征，对软件有良好的理解能力，掌握软件测试相关理论及技术的人员；

★ 需要具有软件业务经验的人员；

★ 需要根据测试计划和方案进行软件测试；针对软件需求开发测试模型，制定测试方案，安排测试计划，搭建测试环境, 进行基本测试，设计简单的测试用例；

★ 需要具有规划设计环境；编制测试大纲并设计测试用例；对软件进行全面测试工作的人员；

★ 需要具有编制测试计划；评审测试方案,规范测试流程及测试文档；分析测试结果,管理测试项目；

★ 需要会操作软件测试工具的人员。

7. 软件测试人员需要的素质：

① 沟通能力

② 技术能力

③ 自信心

④ 洞察力

⑤ 探索精神

⑥ 不懈努力

⑦ 创造性

⑧ 追求完美

⑨ 判断准确

⑩ 老练稳重和说服力

第2章白盒测试的实用技术

1. 白盒测试的分类：

（1）静态测试

静态测试是测试中很重要的方法之一。它不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试。静态测试大约可以找出25%—60%的逻辑错误。

（2）动态测试：

输入一组预先按照一定的测试准则设计的实例数据驱动运行程序，检查程序功能是否符合设计要求，发现程序中错误的过程。

2. 白盒测试的4个原则：

（1）保证一个模块中所有路径至少被测试一次；

（2）所有逻辑值都要测试真和假两种情况；

（3）检查程序的内部数据结构是否有效；

（4）在上、下边界及可操作范围内运行所有循环。

3. 白盒测试方法要注意的五点问题：

（1）测试中，尽量先用自动化工具来进行静态结构分析；

（2）测试中建议先从静态测试开始，如：静态结构分析、代码走查和静态质量度量，然后进行动态测试，如：覆盖率测试；

（3）利用静态分析的结果作为依据，再使用代码检查和动态测试的方式对静态分析结果进行进一步确认，提高测试效率及准确性；

（4）覆盖率测试是白盒测试中的重要手段，在测试报告中可以作为量化指标的依据，对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率；

（5）在不同的测试阶段，测试的侧重点不同：

★ 在单元测试阶段：以代码检查、逻辑覆盖为主；

★ 在集成测试阶段：需要增加静态结构分析、静态质量度量；

★ 在系统测试阶段：在黑盒测试的基础上，白盒测试技术配合黑盒测试技术进行系统测试。

4. 白盒测试常用的7类技术：

逻辑覆盖法
插桩技术
基本路径测试法
域测试法
符号测试
Z路径覆盖法
程序变异测试法

5. 逻辑覆盖主要测试以下八个方面：

（1）语句覆盖

（2）判定覆盖

（3）条件覆盖

（4）条件判定组合覆盖

（5）多条件覆盖

（6）修正条件判定覆盖

（7）组合覆盖

（8）路径覆盖

第3章黑盒测试的实用技术

1. 黑盒测试的定义：

黑盒测试（Black-Box Testing）又称为数据驱动测试或基于规格说明的测试。黑盒测试就是把程序看作一个不能打开的黑盒子，不考虑程序内部逻辑结构和内部特性的情况下，测试程序的功能，测试者要在软件的接口处进行，它只检查程序功能是否按照规格说明书的规定正常使用，程序是否能接收输入数据而产生正确的输出信息，以及性能是否满足用户的需求，并且保持数据库或外部信息的完整性。通过测试来检测每个功能是否都能正常运行，因此黑盒测试又可称为从用户观点和需求进行出发的测试。

2. 黑盒测试的优点：

★ 从产品功能角度测试可以最大程度满足用户的需求。

★ 相同动作可重复执行，最枯燥的部分可由机器完成。

★ 依据测试用例针对性地找寻问题，定位更为准确，容易生成测试数据。

★ 将测试直接和程序/系统要完成的操作相关联。

3. 黑盒测试的缺点：

★ 代码得不到测试。

★ 如果规格说明设计有误，很难发现。

★ 测试不能充分的进行。

★ 结果取决于测试用例的设计。

4. 黑盒测试的方法：

黑盒测试是一种基于证明功能需求和用户最终需求的测试方法，所以在选择测试，设计测试方法方面有如下几种：

★ 等价类划分法；

★ 边界值分析法；

★ 因果图法；

★ 判定表驱动测试；

★ 场景法；

★ 功能图法；

★ 错误推测法；

★ 正交试验设计法。

在实际测试工作中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平和测试的效率。

5. 黑盒测试的原则：

★ 根据软件规格说明书设计测试用例，规格说明书的正确性是至关重要的。

★ 有针对性的地找问题，并且正确定位等价类。

★ 功能是否有缺陷或错误现象？

★ 根据测试的重要性来确定测试等级和测试重点，减少程序可能出现的缺陷。

★ 在接口处，输入的信息是否能正确接受？接受后能否输出正确的结果？

★ 认真选择测试策略，尽可能发现程序的数据结构错误或外部信息访问错误，站在用户立场上进行测试。

第4章测试用例设计方法

1. 测试用例的定义：

测试用例（Test Case）通俗一点来讲就是编写（编制）一组前提条件、输入、执行条件、预期结果以完成对某个特定需求或目标测试的数据，体现测试方案、方法、技术和策略的文档。

2. 测试用例的内容：

★ 测试用例的编号；

★ 测试日期；

★ 测试用例设计人员和测试人员；

★ 测试用例的优先级；

★ 测试标题；

★ 测试目标；

★ 测试环境；

★ 输入数据/动作；

★ 测试的操作步骤；

★ 测试预期的结果。

3. 设计测试用例所需要的文档资料：

★ 软件需求说明书；

★ 软件设计说明书；

★ 软件测试需求说明书；

★ 成熟的测试用例（案例库或财富库）。

4. 白盒测试用例的设计技术和目的：

（1）白盒测试用例的设计技术如下：

★ 逻辑覆盖；

★ 基本路径测试。

（2）采用白盒测试技术设计用例的目的主要是：

★ 每个模块中的所有独立路径至少被执行一次；

★ 所有的逻辑值必须测试真、假两个分支；

★ 在边界值内和可操作范围至少循环一次；

★ 检查数据的内部结构保证其有效的实现预定功能。

5. 黑盒测试用例的设计技术和目的：

（1）黑盒测试用例设计技术如下：

★ 等价类划分；

★ 边界值分析；

★ 错误推测；

★ 因果图。

（2）采用黑盒测试技术设计用例的主要目的是：

★ 检查功能是否实现或遗漏；

★ 检查人机交互界面是否出错；

★ 数据库读取、更新操作出错；

★ 性能特性是否得到满足。

第5章单元测试的实用技术

1. 单元测试目的：

（1）检查单元模块内部的错误，为软件的评审验收提供依据；

（2）单元测试是以程序设计说明书和之前所作的测试数据（正常的和错误的）为指导，测试模块内重要的路径，以检查出错误；

（3）检验信息能否正确地流入和流出单元；

（4）在单元测试工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响；

（5）在为限制数据加工而设置的边界处，能否正确工作；

（6）单元的运行能否做到满足特定的逻辑覆盖；

（7）单元中发生了错误，其中的出错处理措施是否有效。

2. 单元测试的主要任务（测试点）：

程序语法检查、程序逻辑检查、模块接口测试、局部数据结构测试、路径测试、边界条件测试、错误处理测试、代码书写规范检查。

3. 局部数据结构测试主要表现形式：

（1）局部数据结构测试最常见的积累错误；

（2）不适合或者不相容的类型说明；

（3）变量无初值；

（4）变量初始化或者缺省值有错；

（5）不正确的变量名或不正确的截断；

（6）出现上溢、下溢或地址异常。

4. 边界条件测试重点：

（1）程序内有一个n次循环，这个n次循环应该是1~n，而不是0~n；

（2）由小于小于等于等于大于大于等于不等于确定的比较值出错；

（3）出现上溢、下溢和地址异常问题。

第6章功能测试的实用技术

1. 功能测试的定义：

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

功能测试一般须在完成单元测试后集成测试前进行，而且是针对应用系统进行各功能测试。一般应用系统有多个功能（子系统），功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用、是否实现了产品规格说明书的要求、是否能适当地接收输入数锯而产生正确的输出结果等。功能测试，包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。对于功能测试，针对不同的应用系统，其测试内容的差异很大，但一般都可归为界面、数据、操作、逻辑、接口等几个方面。

2. 功能测试的特点：

功能测试（Functional testing）是基于产品功能说明书并根据产品特征、操作描述和用户方案，来测试产品的每个功能是否都能正常使用、是否达到了产品规格说明书的要求。功能测试只需要考虑它的功能点不需要考虑软件的内部结构及代码等。功能测试包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。

3. 功能测试的重点：

功能测试工作一般由程序员担当，测试的结果交系统设计、测试人员审核通过。功能测试的重点应注意如下两大点内容：

A. 整体性

（1）符合标准和规范；

（2）直观性；

（3）一致性；

（4）灵活性。

B. 重点性

（1）确认每个功能是否都能正常使用，每项功能符合实际要求；

（2）是否实现了产品规格说明书的要求；

（3）是否能适当地接收输入数据而产生正确的输出结果；

（4）用户界面测试、是否有相应的提示框、适当的错误提示；

（5）系统的界面是否清晰、美观；

（6）菜单、按钮操作正常、灵活，能处理一些异常操作；

（7）是否能接受不同的数据输入（能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理）；

（8）数据的输出结果准确，格式清晰，可以保存和读取；

（9）功能逻辑清楚，符合使用者习惯；

（10）系统的各种状态按照业务流程而变化，并保持稳定；

（11）支持各种应用的环境，能配合多种硬件周边设备，与外部应用系统的接口有效；

（12）软件升级后，能继续支持旧版本的数据。

4. Web功能测试示例：

4.1 Web功能测试方法主要有如下几点：

1. 页面链接检查：每一个链接都要有对应的页面，并且页面之间切要正确。

2. 相关性检查：检查删除/增加其中每一项是否会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查按钮的功能是否正确，如Add，delete，save，update功能键.

4. 字符串长度检查：输入超出所要求的字符串长度的内容，看系统检查字符串长度时会不会出错。

5. 字符类型检查：在应该输入指定类型的地方输入其他类型的内容，例如在应该输入浮点型的地方输入其他字符类型，看系统检查字符类型时是否报错。

6. 标点符号检查：输入内容包括各种标点符号，特别是逗号、句号、空格、回车键、回格键。看系统处理是否正确。

7. 中文字符处理：在可以输入中文的地方输入中文，看是否出现乱码或出现错误。

8. 检查带出信息的完整性：在查看信息和更新信息时，查看所填写的信息是否全部带出以及带出和添加的信息是否一致。

9. 信息重复：在一些需要命名并且名字是唯一的信息中输入重复的名字，看系统是否处理、报错；重名包括是否区分大小写；以及在输入内容的前后输入空格，系统是否作出正确处理。

10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按“delete”键，看系统如何处理，是否出错；然后选择一个和多个信息，进行删除，看是否正确处理。

11. 检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为浮点型的项，修改也必须为浮点型。

12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看能否处理、报错。同时也要注意，会不会报和自己重名的错。

13. 重复提交表单：一条已经成功提交的纪录，回格后再提交，看看系统是否做了处理。

14. 检查多次使用回格键的情况：在有回格的地方回格，回到原来页面，再回格，重复多次，看是否出错。

15. Search检查：在有search功能的地方输入系统存在和不存在的内容，看搜索结果是否正确。如果可以输入多个搜索条件，可以同时添加合理和不合理的条件，看系统处理是否正确。

16. 输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否会跳动。

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件能否打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统能否做到。

18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息。

19. 快捷键检查：是否支持常用快捷键，如Ctrl+C ，Ctrl+V等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

20. 回车键检查：在输入结束后直接按回车键，看系统处理如何，是否报错。

4.2 Web翻页功能测试的方法主要包括的内容：

★ 有无数据时控件的显示情况；

★ 在首页时，首页和上一页是否能点击；

★ 在尾页时，下一页和尾页是否能点击；

★ 在非首页和非尾页时，四个按钮功能是否正确；

★ 翻页后，列表中的记录是否仍按照指定的排序列进行了排序。

B．总页数，当前页数

★ 总页数是否等于总的记录数/指定每页条数；

★ 当前页数是否正确。

C．指定跳转页

★ 是否能正常跳转到指定的页数；

★ 输入的跳转页数非法时的处理。

D．指定每页显示条数

★ 是否有默认的指定每页显示条数；

★ 指定每页的条数后，列表显示的记录数，页数是否正确；

★ 输入的每页条数非法时的处理。

4.3. 搜索功能测试的方法主要通过以下八点测试：

1．页面检查；

2．默认条件搜索；

3．修改可选条件搜索；

4．修改输入条件搜索；

5．修改区间条件搜索；

6．组合可选、输入条件搜索；

7．操作后检查搜索条件及查询结果；

8．错误、空记录搜索。

第7章集成测试技术

1. 集成测试的定义：

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

2. 集成测试的过程包括：

制定集成测试计划，设计集成测试，实施集成测试，执行集成测试，评估集成测试。如下图所示。

3. 集成测试的五个步骤：

1. 首先确定子系统有哪些模块组成，保证这些模块都进行过单元测试。

2. 由开发人员组装这些模块，生成一个子系统，并保证在此子系统中，各个模块的功能尽可能发挥出来。

3. 测试前，要设计测试用例，所以一个关键的模块为核心展开，以功能和性能为两条主线，注意模块间接口。

4. 搭建必要的测试环境，按照所写测试用例，进行模块连接的充分测试。

5. 记录测试结果，总结测试问题。

4. 集成测试的注意事项：

4.1 测试中问题的处理

（1）问题的定位，由谁定位，定位的时间

在测试过程中发现与测试计划中测试项预期结果有所不同，即是问题。如果测试人员有能力定位问题，需明确程序代码中出错的地方，并记录下来；否则找开发人员到现场来定位。定位的时间最好是在问题产生之前，这样有利于保护现场和问题重现，但时间不能太长，否则影响测试进度，原则上说，集成测试中发现的问题都应该定位到语句，除非涉及到方案设计上的错误。

（2）环境问题的处理

集成测试的环境可以是单机、双机或机架。测试过程中需要有独立的、稳定的和良好的实验环境。但在实际中由于条件限制，测试环境是大家共享的，为保证本次测试不影响下次测试工作或其他人测试工作的开展，所以测试人员需要做以下的工作：

★ 测试环境的申请；

★ 测试环境的维护；

★ 测试环境的移交。

（3）测出问题的记录与提交

测试过程中发现的现象和问题由测试人员做详细记录，测出的问题最好先由开发人员确认，然后以内部问题报告单的形式提交，这样防止测试人员提交的问题并非是程序的问题，（可能是环境因素或其他因素造成），同时保证发现的问题能够被跟踪到回归测试，即被彻底解决为止。

4.2 测试过程记录

测试人员在测试过程中完成必要的测试记录，记录的内容包括：测试版本；测试任务；使用环境；测试项目；测试结果；问题描述；产生原因。

每一阶段性的测试任务结束后，应向测试负责人提交测试记录，测试负责人做存档处理。

4.3 测试人员在测试过程中应不断地与开发人员进行经验交流，讨论程序中的疑问以及问题的解决，加深程序的理解，以积极合作的方式来完成测试工作。

4.4 测试用例、CHECKLIST、测试进度的适当修正

随着集成测试的进一步进行，对程序代码的理解不断加深，会发现以前的测试集不够理想，这就需要及时更新测试用例，以提高测试覆盖率和达到需要的异常测试，相应也要修改CHECKLIST和调整测试进度。

4.5 判断集成测试过程完成与否，需要注意以下几个方面：

4.5.1 成功地执行了测试计划中规定的所有集成测试；

4.5.2 修正了所发现的错误；

4.5.3 测试结果通过了专门小组的评审。

第8章性能测试的实用技术

1. 性能测试的定义：

性能测试主要是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈及问题，找到软件的可扩展点，优化软件，最后起到优化系统的目的。

性能测试的目的主要有以下几点：

（1）评估系统的能力

性能测试主要考查系统的能力，它对系统的负荷和响应时间是相当重要的，也是验证系统能力的依据之一。

（2）识别体系中的弱点

性能测试考查系统受控的负荷还存在有哪些缺陷，并为解决这些缺陷提供路径。

（3）系统调优

性能测试的系统调优就是重复运行测试，验证系统的活动是否得到了预期的结果，从而改进系统性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中隐含的问题或冲突。

（4）验证稳定性及可靠性

验证稳定性及可靠性是在一个生产负荷下，执行一定时间的测试，是评估系统稳定性和可靠性是否满足要求的唯一方法。

2. 性能测试的先决条件：

（1）针对性能测试对象的技术要成熟；

（2）性能测试的测试环境要稳定；

（3）进行性能测试的准备要充分；

（4）性能测试的目标要明确；

（5）性能测试的计划要详细；

（6）性能测试的数据要精确以及要有代表性；

（7）性能测试的描述要精练。

满足了这些之后我们才能够进入测试阶段。

3. 性能测试主要分为三类：

（1）应用在客户端性能的测试

应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

（2）应用在网络上性能的测试

应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

（3）应用在服务器端性能的测试

对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控。

4. 性能测试的准备文档：

（1）用户需求规格说明及其相关文档；

（2）软件开发的前期数据；

（3）前期工作的详细资料（单元测试、集成测试、功能测试等的相关文档）；

（4）在真正进入性能测试之前的软件数据的备份等；

（5）性能测试的测试大纲；

（6）性能测试的审批文稿及所签署的合同等。

5. 标准的性能调优过程：

（1）确定基准环境、基准负载和基准性能指标；

（2）调整系统运行环境和实现方法，执行测试。（包括硬件环境的调优、Weblogic调优、Oracle调优）；

（3）记录测试结果、进行分析。

第9章系统测试的实用技术

1. 系统测试的内容：

系统测试一般要考虑功能测试、性能测试、负载测试、容量测试、安全性测试、用户界面测试、配置测试、安装测试、回归测试等。

2. 系统测试的目标：

确认系统测试的过程是按需求说明书进行的；
确认新系统是否与需求说明书有不同或者缺陷；
对新系统在进行测试的过程中出现的不足或不符合要求的地方时行进行记录；
建立完善的系统测试缺陷记录跟踪库；
将测试过程中出现的问题进行修改，使之能达到令用户满足。

3. 系统测试的策略：

测试策略用于说明测试工作的方法和目标，系统测试策略主要是对系统测试的需求，确定测试类型和怎样进行测试的方法和技术。

测试策略应包括如下内容：

★ 要进行的测试类型和测试目标；

★ 进行测试时要采用的技术；

★ 对测试的结果制定标准；

★ 对测试过程中所出现问题存在的影响的特殊事项；

★ 进行系统测试的系统应是完整的、集成的计算机系统；

★ 按照设计说明书的规定，逐项测试系统的功能．性能等特性。

4. 系统测试常用的三个方法：

多任务测试
临界测试
中断测试。

3.1中断测试可分为：人为中断、硬件异常中断、程序执行中断以及意外中断4种情况，4种中断情况说明如下：

在测试中人为中断是为了表现测试结果而设置的中断。在测试中是常用的一种手段。
而硬件异常中断是由计算机硬件异常或故障引起的中断，对硬件异常中断主要测试系统设备有没有在线功能和备用设备。
程序执行中断主要是由程序中执行了中断指令引起的中断，也称为软中断。这是不应该发生的，对这类问题测试重点审查集成测试的过程和结果。
意外中断主要是外部原因引起的中断，对他的测试主要是审查有没有备用电源、有没有安装UPS。

第10章验收测试的实用技术

1. 验收测试的首要条件：

1．软件开发已经完成，并全部解决了已知的软件缺陷；

2．验收测试计划已完成评审并批准，并且置于文档控制之下；

3．对软件需求说明书的审查已经完成；

4．对概要设计、详细设计的审查已经完成；

5．对所有关键模块的代码审查已经完成；

6．对单元、集成、系统测试计划和报告的审查已经完成；

7．所有的测试脚本已完成，并至少执行过一次，且通过评审；

8．使用配置管理工具且代码置于配置控制之下；

9．软件问题处理流程已经就绪；

10．新系统已通过尝试运行工作；

11．所被测的新系统应该是稳定的，要符合技术文档和标准的规定；

12．已经制定、评审并批准验收测试完成标准；

13．合同、附件规定的各类文档齐全。

2. 验收测试的目的：

★ 新建系统产品是否是按照用户需求开发的，体验该产品是否能够满足用户使用要求、有没有达到原设计水平、完成的功能怎样；

★ 对照合同的需求进行验收测试，是否符合双方达成的共识；

★ 新建系统产品的可靠性和可维护性好不好？

★ 新建系统产品通过运行的结果表明，对业务处理的能力；

★ 新建系统产品对用户操作的容错能力；

★ 新建系统产品新系统对系统运行时发生故障的恢复能力；

★ 承建单位向业主单位提交的有关技术资料是否俱全。

3. 验收过程中涉及到的文档：

1. 测试任务说明书；

2. 测试计划说明书；

3. 测试用例说明书；

4. 测试报告说明书；

5. 测试总结说明书；

6. 测试验收说明书；

7. 缺陷跟踪报告说明书。

4. 正式验收测试：

正式验收测试，是系统测试的后续，也就是说正式验收测试的测试工作和系统测试差不多，测试计划和测试用例设计都应很详细，在这个测试过程中应用的测试用例应是系统测试的用例的子集，不能对系统的测试方向有所偏离，在很多测试过程中，正式验收是自动进行测试的。

正式验收测试的优点是：

要进行验收测试的软件的功能和特性都是已知的；
可以对测试的过程进行评测；
正式验收测试可以自动进行测试；
对软件的要求是由用户需求说明书所决定的。

正式验收测试的缺点：

进行正式验收测试需要大量的资源和计划；
正式验收测试可能和系统测试差不多；
正式验收测试过程中可能不能发现某些缺陷。

5. 非正式验收测试：

非正式验收测试过程分为Alpha 测试和Beta 测试。

Alpha测试

Alpha测试是用户在开发环境下所进行的测试，或者是开发内部的人员在模拟实际环境下进行的测试。Alpha测试没有正式验收测试那样严格，在Alpha测试中，主要是对用户使用的功能和用户运行任务进行确认，测试的内容由用户需求说明书决定。

Beta 测试

进行Beta 测试时，各测试员应负责创建自己的测试环境、选择数据，决定要研究的功能、特性或任务，并负责确定自己对于系统当前状态的接受标准。

第11章回归测试的实用技术

1. 回归测试的定义：

在软件开发过程当中，只要软件发生改动，就可能给该软件带来诸多的问题，我们就必须重新测试现有的功能模块。软件的改动可能是源于功能的变更、模块的增加或者bug的修改，具体表现在以下几个方面：

(1) 跟踪和管理系统不够健全，遗漏对bug的修改；

(2) 开发者对bug理解不够深入，只修改了bug的表面现象，而没有对bug做本质修改；

(3) 本bug被修改，之前版本bug掩盖的其他错误暴露出来；

(4) bug被修改，但并没有考虑到与此问题相关联的其他功能模块。

回归测试正是为了验证以上几个方面是否发生，以便确定修改是否达到了预期的目的，验证修改是否损害了原有的正常功能。与此同时，还需要补充新的测试用例来测试新增的、被修改了的功能模块。验证修改的正确性及其影响，即为回归测试。回归测试不是特定的测试级别，软件开发的各个阶段都会进行多次回归测试。

2. 回归测试的范围：

(1) 测试所有修改或修正过的功能模块；

(2) 测试与被修改的模块相关的模块；

(3) 测试所有新增加的功能模块；

(4) 测试整个系统。

方法(1)、方法(2)和方法(3)中只进行了部分的回归测试，这样的测试是不健全的，因为在软件系统中，对本地代码的修改可能导致整个系统产生副作用。

3. 回归测试用例库的维护：

删除过时的测试用例
改进不受控的测试用例
删除冗余的测试用例
增添新的测试用例

4. 回归测试的方法:

再测试全部用例

基于风险进行测试

基于操作进行测试

仅测试修改部分

5. 回归测试可遵循的基本过程:

(1) 识别出软件中被修改的部分。

(2) 从测试用例库中，排除所有不再适用的测试用例，确定哪些对新的软件版本依然有效的测试用例，其结果是建立一个新的测试用例库。

(3) 依据一定的策略从新的测试用例库中选择测试用例测试被修改的软件。

(4) 如果必要，可生成新的测试用例集，用于测试新的测试用例库无法充分测试的软件部分。

(5) 用测试用例集执行修改后的软件。

其中第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证修改工作本身。

第12章配置测试的实用技术

1. 配置测试的目标：

★ 验证应用程序（确定它是否满足了它的配置要求）。

★ 确定配置问题的软件出错。

★ 帮助识别那些不能有效地在单元和集成测试发现的一些缺陷。

★ 决定增加或修改，如硬件资源的影响：内存、磁盘和磁带资源、处理器、负载均衡。

★ 确定最佳的系统配置。

2. 进行配置测试的前提条件：

★ 进行配置测试的需求分析已经完成。

★ 已完成应用程序的多个版本。

★ 相关的软件组件已通过单元测试。

★ 软件集成测试已经进行，但在配置测试开始之前软件组件必须已经安装在被测硬件设备上。

★ 相关系统组件已通过系统集成测试。

★ 在独立的测试小组配备足够的人员进行配置测试和训练。

★ 配置测试环境准备完成。

3. 配置测试的环境：

配置测试的目标是为了使软件在尽可能多的硬件平台上运作，那么进行配置测试一般需要测试它的硬件环境和软件环境。

3.1 硬件环境主要包括：

★ 不同的主机；

★ 不同的组件；

★ 不同的外设；

★ 不同的接口以及可选项的测试。

3.2 软件环境包括：

★ 对操作系统平台的兼容测试；

★ 对同一操作系统平台不同版本的测试；

★ 软件自身向前向后更新操作时的测试；

★ 同其他软件产品兼容性测试以及数据兼容性（主要是数据共享）的测试。

4. 配置测试所需的文档：

4.1 工作开始前所需的文档

配置测试进行前需要以下文档资料：

★ 测试计划；

★ 需要进行的测试列表；

★ 被测程序源码；

★ 配置测试软硬件设备清单；

★ 配置测试用例。

4.2 工作结束后递交的文档

配置测试结束后需要递交以下文档资料：

★ 配置测试报告；

★ 配置测试总结报告。

5. 配置测试设计的八要点：

★ 确定哪些功能是软件需要用到的，例如一个办公程序可能对显卡要求是很低的，没有必要去测试太多。又或者一个大型游戏根本不需要打印功能，那么就不需要管打印机了；

★ 看看要对哪些牌子，型号，具体那些驱动程序的硬件是可用的。一般都会选用市场上比较流行的软件；

★ 看看哪些硬件特性，模式和选项是可用的；

★ 在已有的测试集合里面挑选出一个可维护可管理的测试集，还是挑出表常见的硬件；

★ 找出软件中对配置特别敏感的特有功能；

★ 不同配置下的测试用例需要分别设计；

★ 在每个配置环境下至少执行一边测试用例；

★ 反复执行测试用例直到结果具有说服力。

参考文献：

《google软件测试之道》

《敏捷软件测试：测试人员与敏捷团队的实践指南》

《软件测试的艺术》

《软件测试方法和技术》

软件测试模板：

https://blog.csdn.net/zalman123456/article/details/132637057?spm=1001.2014.3001.5502