系统软件测试方案

系统软件测试方案

LL1.1总体测试任务安排

针对本项目的测试工作，我公司将按《计算机软件质量保

证计划规范》（GB/T-90）、GB/T-2008《计算机软件测试规

范》和GB/T9386-2008《计算机软件测试文档编制规范》进

行软件检查、测试、文档整理报送。我公司保证对测试错误和

缺陷进行及时修正、补充。

我公司将在本项目中全面实施标准和规范化的测试工作。

我公司将完成全部业务功能、技术功能、各种性能测试的测试

案例编写工作和实际数据采集工作。我公司将对所有测试采用

客观的测试案例和测试数据为验证标准。

在本项目的软件测试过程中，我公司将针对测试所发现的

典型性问题、常见性问题、重要性问题，建立相应的软件测试

知识库。

当项目甲方委托第三方测试机构进行测试时，我公司将予

以积极配合。

此外，在本项目的软件测试过程中，我公司将提供

测试所需的工具，免费用于项目甲方在本项目中所建

平台的测试过程。

1.1.1.2测试准备方案

4.8.10.2.1测试计划

对于本项目的应用软件测试工作，我公司将提前制定测试

计划，主要包括：测试阶段划分、测试方法、工作流程、人员

分工、进度安排等内容。在测试计划经项目甲方确认后，我公

司将按照该计划，严格执行项目测试工作。

针对本项目应用软件开发的单元测试、集成测试、系统测

试，我公司将制定切实可行的测试计划，合理安排各阶段的软

件测试工作的任务、方法、人员安排、时间进度等，从而有效

检验软件的功能、性能等方面的技术指标对项目需求的满足程

度。在本项目中，分三个阶段进行测试计划。

（1）第一阶段测试计划（基于平台2.0的预算综合管理

和门户）

第一阶段测试计划的主要内容如下：

测试阶段的序列号测试内容（对象）

1单元测试所开发软件的各

单元模块

测试方法

白盒测试

投入人员

软件开发

工程师

量

4个人

时间周期

7天

2集成测试所开发软件的各

子系统

黑盒测试软件开发

工程师、

软件测试

工程师

软件测试

工程师

同“3”

同“3”

同“3”

两个人住5天

3

4

5

6

系统测试所开发软件的整

个平台

系统集成

试验

阶段初验

测试

阶段验收

测试

系统集成完成的

软件系统

系统初验完成的

软件系统

阶段验收完成的

软件系统

同“2”

与“2”相同

同"2”

与“2”相同

2人

2人

2人

2人

7天

4天

2天

3天

（2）第二阶段测试计划（国库集中支付接入）

第二阶段测试计划的主要内容如下：

序号测试阶段测试内容（对象）

1

2

单元测试所开发软件的各

单元模块

集成测试所开发软件的各

子系统

测试方法

白盒测试

黑盒测试

投资人员

软件开发

工程师

软件开发

工程师、

软件测试

工程师

软件测试

工程师

同“3”

同“3”

同"3”

数量

2人

1人

时间周期

15天

15天

3

4

5

6

测试系统开发的软件的完整性

一个平台

系统集成

测试

阶段初验

测试

阶段验收

测试

系统集成完成的

软件系统

系统初验完成的

软件系统

竣工阶段验收

软件系统

与“2”相同

同"2”

同"2”

与“2”相同

2人

4人

4人

4个人

15天

3天

2天

3天

(3)项目最终验收测试计划

项目最终验收测试计划的主要内容如下:

序号测试阶段测试内容(对象)

1项目最终整体试运行正常

验收测试的软件系统

检测方法

黑盒测试

投资人员

软件测试

工程师

数量

4人

时间周期

5天

4.8.10.2.2测试组织

我公司为本项目成立了专门的测试团队，并设置了

明确的工作岗位，主要包括高级测试经理、具有实际

软件测试经验的专业软件测试工程师。

我公司对测试小组成员的工作职责做了明确的规定。所有

测试人员将负责根据测试计划编写测试计划和测试用例，执行

系统测试（功能、性能、安全等。），并准备测试报告。他们还

将向项目甲方做出必要的系统缺陷回应。

4.8.10.2.3测试方案

我公司针对每类测试制定了单独的测试计划，包括：测试

内容、测试环境、数据要求、测试范围和主要内容、测试工具

和测试方法、完成标准等。测试计划经项目甲方确认后，我公

司将严格执行。

4.8.10.2.4测试环境

我公司将为本项目的各类测试工作搭建所需的性能测试环

境，安装并配置性能测试工具。

4.8.10.2.5测试用例

我公司将为本项目的各类测试工作提供所需的测试用例，

并保证测试用例满足以下要求：

1）测试用例的目标清楚，并可满足软件质量管理的各方

面要求。

2）测试用例的组织和分类设计思路正确，层次清晰，结构

合理。

3）测试用例覆盖所有测试点、所有路径、所有已

知用户使用场景。

4）有足够的负面测试用例来测试各种异常和异常。

5）可根据测试阶段和情况的变化，及时更新维护测试用

例。

4.8.10.2.6测试数据

我公司将提供满足本工程要求的各种试验数据:

1）我公司将准备模拟测试数据，能够满足测试要求，覆盖

被测业务和测试边界，满足完整性和一致性要求。

2）我公司将按项目甲方指定的范围，采集测试所需实际

数据，并进行整理，以满足测试需要。我公司将按照项目保密

要求，对相关数据进行保密。

1.1.1.3测试方法

基本测试策略

测试将从软件功能、接口规范、业务处理逻辑、运行结果、

运行环境适应性等方面进行。验证软件功能点的满意度、界面

布局和人机交互的规范性、业务处理逻辑的正确性和业务运行

结果的合理性。

1）测试软件功能，验证每个功能点对合同约定需求的满

足程度。

2）根据界面规范的要求，对系统中各业务模块的输入、列

表、提示息等页面进行测试，验证其样式和布局的统一性。

3）测试系统的业务处理逻辑，验证采集和查询结果的正确

性。

4)采用白盒法执行内部逻辑测试，验证程序业务处理逻

辑的正确性。

5)测试模拟业务环境中系统的运行结果，验证模拟结果

的合理性，以及系统对运行环境的适应性。

4.8.10.3.2测试执行方法

(1)功能测试

测试软件的功能，验证各功能点是否满足要求。用测试用

例测试用户需求对应的软件功能，找出软件功能实现与用户功

能需求的不一致之处。通过功能测试，检查软件功能是否满足

用户对管理的要求，从而找出软件存在的功能问题。

(2)性能测试

使用测试用例测试用户提出的软件性能需求所对应的软件

的性能和效率指标。在一定的工作负载和配置条件下，测试软

件的响应时间、处理速度、资源占用率、并发性、准确性、适

应性、可靠性、安全性等特性。验证软件的各项性能指标是否

满足用户提出的性能指标要求，从而找出软件性能实现与性能

要求的差距。

(3)文档测试

对安装手册、配置手册、操作手册、维护手册等软件文档

进行测试，找出软件文档资料与使用要求之间的不一致之处，

从而检查文档的正确性、完备性和可理解性。

(4)环境接口测试

测试软件界面与环境的兼容性和可用性。接口测试内容包

括：联网

(5)安全性测试

评价软件的安全性，检验软件的安全访问控制体系是否能

起到应有的作用。安全性测试将从访问控制、日志记录是否完

善，以及用户误操作、非法数据能否引起数据破坏等方面，对

软件的安全性进行严格测试。

(6)可安装性测试

通过安装程序或按照安装规程，来测试软件的安装过程中

是否存在错误，以便验证软件的可安装性。

(7)边界测试

在输入域、输出域、状态转移、功能边界和性能边

界等边界或端点测试软件的临界运行状态。

(8)余量测试

测试软件的容差能力(容差指标如总存储量、输入/输出通

道、处理时间等。)满足用户提出的技术指标要求。

(9)容量测试(负载测试)

对所测试的软件加载大量数据进行应用处理，验证软件能

否按照其技术规格说明来处理大批量数据。

(10)强度试验

在负载情况不确定的情况下，通过测试软件的各项压力指

标是否符合要求，来检验软件的稳定性。在规定时段和强度的

测试条件下，通过运行软件的所有功能，来验证软件是否存在

严重错误，以及一般错误是否超过规定范围。

(11)可靠性测试

在有代表性的应用环境中，为了评估软件的可靠性，根据

其稳定性来测试其功能。具体来说，可靠性测试将从合理使用

资源(防止内存泄露)、数据备份和恢复、用户误操作或非法数

据是否会导致系统异常退出/程序损坏/数据破坏等方面测试软

件的可靠性指标。

(12)恢复性测试

当软件出现故障并需要重新工作时，测试软件重建其性能

水平和恢复直接受影响的数据的能力。

4.8.10.3.3测试用例设计方法

测试用例设计方法如下所述:

1）确定测试用例的角色、场景;

2）确定测试用例的主事件流、分支事件流和异常事件流;

3）确定测试用例的约束条件，包括：角色、不可空性、存

在性、可重复性、相关性、数据格式、处理状态、接口处理限

制运行条件等。

4）确定测试用例的边界条件，包括输入数据格式、数据

存取错误检测点、最小/最大值、处理量边界（一条、多条数

据）、处理顺序边界（首条、末条）；

5）确定测试用例的并发条件，包括并发读写处理和并发控

制。

测试结果记录方案

按照子系统、业务模块、功能点，分别记录以下测试结果:

1）记录任务类型，包括：公共处理、基本数据处

理、业务逻辑处理、界面操作处理四类任务;

2）记录测试日期、测试人、测试迭代次数、测试状态;

3）记录测试输入数据、测试步骤、预期结果;

4）记录测试输出结果;

5）记录测试问题分析。

4.8.10.3.5测试工具选型

在本项目的软件测试过程中，我公司将提供测试所需的工

具（如测试管理工具、测试结果分析工具等）。），将免费用于甲

方在本项目中搭建的平台的测试过程。主要包括以下测试工具:

1）测试环境工具；

2）预测试自动化工具；

3）测试结果提炼工具；

4）测试结果分析工具；

5）测试结果比较工具；

6）性能测试数据库服务器。

1.1.1.4测试管理

我公司将在软件开发过程中，组织专职软件测试工程师进

行软件测试工作。通过对上述定制开发软件进行单元测试、集

成测试、系统测试，来验证本项目所建系统的功能、性能等技

术指标是否满足应用要求。在软件通过各阶段测试后，项目组

将软件的测试计划、测试用例、测试问题描述、测试报告等测

试文档一起交付绐项目甲方。

在上述软件测试过程中，我公司将采取严格而有效测试过

程管理，对软件的功能、性能、文档等方面的指标进行全面测

试，具体测试管理方案如下所述。

1.1.1.4.1制定软件测试计划。

根据项目进度计划，由软件测试小组的各成员共同

协商具体的测试计划。测试组长按照指定的模板起草

《测试计划》，其内容包括：测试目的、测试对象、

测试范围、测试环境要求、测试任务、测试方法、测

试接收准则、测试人员安排、测试进度计划、记录与

报告管理机制等。

项目经理对《测试计划》审核批准后，执行下一步骤。

1.1.1.4.2设计软件测试用例

根据《计算机软件质量保证计划规范》，测试团队的每个

成员根据指定的模板设计待测软件的《计算机软件测试规范》，

重点是软件各子系统的功能、性能、接口的整体测试用例设计。

测试组长邀请开发人员和相关专家，对《测试用例》进行

技术评审，通过评审后方可执行下一步骤。

1.1.1.4.3执行软件功能和性能测试

我公司将在本项目中全面实施标准和规范化的测试工作,

完成全部业务功能、技术功能、各种性能测试的测试案例编写

工作和实际数据采集工作。对所有类型的测试，我公司将采用

客观的测试案例和测试数据为验证标准，而不以个人主观判断

作为测试标准。

我公司的项目测试小组将按GB/T-2008《计算机软件测

试规范》进行软件检查、测试。

软件测试小组各成员依据《测试计划》、《测试用例》执

行软件测试，重点测试软件运行过程中的整体功能、性能、接

口联接关系等技术指标，并形成测试问题记录与报告。

对于测试过程中所发现的问题，采用我公司的自有“缺陷

管理工具”进行沟通和管理，以便将测试结果及时通报给产品

原厂商或我公司的技术人员。

测试结束后，将测试结果和统计息记录在书名号123中。

1.1.1.4.4缺陷管理与改错

在本项目的软件测试过程中，我公司将针对测试所发现的

典型性问题、常见性问题、重要性问题，建立相应的软件测试

知识库。在制定软件测试计划、设计软件测试用例、执行软件

测试、记录和报告测试问题的过程中，对于测试人员所发现的

缺陷使用“缺陷管理工具“，来记录相关缺陷的状态息，并形成

《缺陷管理报告》。

此外，我公司保证对测试错误和缺陷进行及时修正、补充。

我公司技术人员将根据缺陷记录，及时消除已经发现的缺陷，

并进行相应的回归测试，以确保在后续测试和使用过程中不再

引入新的缺陷。

对于定制开发软件，修改其测试问题的软件版本变更控制

流程如下图所示：

1.1.1.5测试实施计划

1.1.1.5.1功能测试

对于用户功能需求说明中定义的功能需求，按照不同阶段

的测试用例，对本项目系统与相关外部系统的应用集成接口进

行测试。通过验证系统功能是否满足需求说明书中描述的功能

需求，来发现系统目前存在的问题。功能测试工作覆盖系统全

部源代码。测试'内容除对代码正确进行验证外。还包括测试是

否满足界面设计要求、是否满足软件功能需求要求等各方面要

求。

（1）测试内容

对测试对象的功能测试应侧重于所有可直接跟踪到的用例

或业务功能和业务规则的测试需求。

功能测试主要是为了发现以下几类错误：

1）是否有不正确或缺失的功能？

2）功能实现是否满足用户需求和系统设计的隐藏需求

3）能否正确地接受输入；能否正确的输出结果。

功能测试要求测试设计人员熟悉产品规格、需求文档、产

品业务功能，对测试用例设计方法有一定的掌握，从而设计出

良好的测试计划和测试用例，高效地进行功能测试。

（2）测试规范

进行功能测试时，应遵循以下规范：

1）为每个清晰的功能需求设计至少一个基本用例，两个异

常测试用例；

2）对每个隐含的功能需求至少设计一个基本用例和两个

异常测试用例；

3）为每个可能的功能异常设计1到2个测试用例；

4）关键用例或优先级高的用例要保证有效得到执行；

5）功能测试发现的缺陷要全部得到处理。

（3）测试方法

在进行功能测试时，首先需要对需求规格进行分析，因为

这是功能测试的基本输入。

1.需求和规范的测试和分析步骤

1）对每个明确的功能需求进行标号（对于在需求规格文

档中已经有标号的可以直接饮用）；

2）标注每个可能隐含的功能需求；

3）对于可能出现的功能异常进行分类分析，并标号；

4）对于前面3个步骤获得的功能需求进行分级；由于我

们不可能测试任何东西，因此可以根据风险来决定对每个功能

投入多少关注。一般来说，可以把功能划分为关键功能和非关

键功能。其中关键功能是指那些对用户来说必不可少的功能，

这类功能的丧失将导致用户拒绝产品。

5）对每个功能进行测试分析，分析是否可以测试，如何测

试，可能的输入，可能的输出等。

6）脚本化和自动化。

2、常用功能测试用例设计方法

1）等价类划分法；2）边界值法；3）因果图；4）判定表;

5）正交实验设计；6）基于风险的测试；7）错误猜测法。

（4）风险分析

功能测试时存在的主要风险有：

1)遗漏重要的功能点的测试；

2)系统功能改变后，自动化测试脚本没有更新，导致执行

脚本时出现虚警或脚本失败。

(5)测试组织

功能测试主要由测试团队完成。测试组长负责编写功能测

试计划、方案和测试总结报告。团队成员负责编译和执行功能

测试用例，编辑、调试和执行测试脚本，填写测试日志和问题

报告。功能测试的基本工作过程如下：

(6)效果评估

由测试组长撰写测试分析报告，对功能测试过程中的工作

组织、测试进度、缺陷分布、严重性、数量、人员效率、项目

质量等方面进行综合评估。

1.1.1.5.2界面测试

(1)测试内容

用户界面测试用于核实用户与软件之间的交互。目标是确

保用户界面会通过测试对象的功能来为用户提供相应的访问和

浏览操作。另外，用户界面测试还可确保用户界面中的对象按

照预期的方式运行，并符合公司或行业的标准。

用户界面测试的测试内容包括:

1、用户界面适合于软件的功能（合适性）

用户界面合适性是指界面与软件功能相融洽的程度。软件

的功能需要通过用户界面来展现。毫无疑问，用户界面一定要

适合软件的功能，这是最基本的要求。如果用户无法通过这个

界面来使用软件，“易用性”根本就无从谈起。合适性差的界面

会混淆软件功能意图，即使它不损害软件功能与性能，也会给

用户不该有的麻烦（费解、难用、气恼）。

2、容易理解

如果用户很难理解界面的意图，那么他使用起来肯定费劲。

所以“容易理解”是“容易使用”的前提条件。

3、及时反馈息

当用户进行某项操作后，如果过了一会儿（几秒钟）用户

界面一点反应都没有，这将使用户感到迷茫和不安，因为他不

知道是自己操作错了还是软件死机了。所以及时反馈息很重要,

至少要让用户心里有数，知道该任务处理得怎么样了，有什么

样的结果。

4、防错处理

在使用软件的过程中，难免会出现一些错误的操作。如果

用户不小心输入了错误的数据或者删除了有用的数据，软件被

愚蠢地执行了，那么用户会非常生气，以后也不敢放心使用软

件。

5、合理的布局

界面的整体布局要符合逻辑，最好和工作流程保持一致。

窗口（或页面）上界面元素的布局应该整洁、清新。

6.合理的颜色

界面色彩要合理，使用颜色的时候要保持一致，同时根据

对象的重要性来选择颜色，但是又不能过分依赖颜色，因为有

些用户可能是色盲或色弱。

7、风格一致和必要的个性化

风格一致的最大好处就是能够减少用户的记忆量、减少出

错几率，并且迅速积累操作经验。而个性化界面设计又能吸引

用户眼球培养用户对软件的兴趣。所以要求用户界面在具备必

要的“一致性”的前提下，突出该软件的“个性”。不仅让用户使

用起来方便，而且对软件留下深刻的向象。

8、适应用户群体和国际化

软件设计要适应多种类型的用户，比如对计算机比较外行

的、计算机专家等，努力使用户在操作软件的时候感觉不到差

异和麻烦。为了达到这个目标，一般需要提供多种操作途径以

适应各种水平的用户。

为了能够更好地适应国内和国际市场，在用户界面应当充

分考虑语言和文化的差异。使用标准的图解方式和国际通行的

语言，要求简单易懂，易于翻译，方便不同母语的用户。

9、最少操作步骤(最高效率)

用户界面应当尽可能地替用户着想，用户应当用最少的操

作步骤完成某项操作任务，获得最高的使用效率。

10、可复用

复用有利于提高质量、提高生产率和降低成本。因此用户

界面也应该做到能够被复用。

(2)测试规范

用户界面设计规范如下表：

设计要素重要性规范描述

用户界面是否与软件的功能相融洽？用户界面是否适合用

户

的应用环境？

非常重要

说明：如果是否定的，说明用户不能有效地使用这个软件。

是不可原谅的缺陷。这个缺陷是需求分析错误造成的。

界面元素有错别字，或者措词含糊、逻辑混乱。

解释：如果出现如此低级的缺陷，说明开发人员根本没有

把用

非常重要

用户把界面放在心上，用户对这种不专业的态度很反感。

不可原谅。

的缺陷。

容易理解

重要

对于常用的功能，用户能否不必阅读手册就使用？

是否所有界面元素提供了充分而必要的提示？

界面结构和工作流程匹配吗？

你提供在线帮助吗？

解释：如果实现上述要求，说明界面细节做得很好。

是进度条，动画等。以反映正在进行的耗时过程？

重要操作是否返回必要的结果息？

解释：如果否定的话，说明用户界面不够专业。

合适性

及时反馈

息

重要的

错误预防处理

在执行破坏性操作之前，是否得到用户的确认？

输入数据或递交数据时，是否进行相应的数据校验（检查

数据

合法吗）

非常重要

是否根据用户的权限自动隐藏或者禁用某些功能？

解释：如果是否定的，说明开发者没有防误常识，是的

不可原谅的缺陷。

可选择的

是否提供撤销功能来撤销意外操作？

解释：如果实现该要求，说明界面细节做得很好。

设计要素

一致性

重要性

重要的

规范描述

相似的界面元素是否有相同的视觉感，相同的操作方式？

是否符合广大用户使用同类软件的习惯？

解释：如果否定的话，说明用户界面不够专业

是否在具备必要的“一致性”的前提下，设计了与众不同的、

一个让用户记忆深刻的界面？

解释：如果实现这个要求，说明界面很有创意。

界面的布局符合软件的功能逻辑吗？

界面元素是水平对齐还是垂直对齐？

界面元素的尺寸是否合理？

行距一致吗？

是否恰当地利用窗体和控件的空白，以及分割线条？

窗口切换、移动、改变大小时，界面正常吗？

解释：如果否定的话，说明用户界面不够专业。

界面的色调是否让人感到和谐、满意？

重要的对象是否用醒目的色彩表示？

颜色的使用是否符合行业习惯？

是否可以让色盲、色弱的人员使用？

说明：如果实现了这个要求，界面细节非常好。

有没有适合初学者和专家操作这个界面的方法？

色盲或者色弱的用户能正常使用该界面？

解释：如果实现该要求，说明界面细节很好。

度量单位、日期格式、人的名字是否让用户误解？

翻译文字是否地道，是否符合读者习惯？

你是否使用合理的最少步骤来实现常见操作并实现高效率?

解释：如果实现该要求，说明界面细节和好。

用户界面的原型、代码、文档可以重用吗？

解释：如果实现该要求，说明软件的需求分析、设计、实

现做

干得好。

个性化可选

合理布局可选

合理的颜色很重要。

用户可选择的适应

国际化

最少步骤

高效率

可复用

重要的

重要

重要

(3)测试方法

界面测试应当尽早进行，测试方法有：对界面原型采用场

景测试方法，由测试人员扮演场景中的角色，模拟各种可能的

操作以及可能的操作序列，并且由用户来判断是否合理，是否

有功能的遗漏。

界面原型确定后，开始设计界面测试用例，用例设计的思

路如下：

1、划分界面元素，并根据界面的复杂性进行分层

一般分为三个层次：第一个层次是界面原子，即不可再分

的界面元素，例如：一个菜单项、一个按钮、一个列表等。第

二个层次是界面组合元素，是由多个具有相同属性的界面原子

或者彼此协助的一组界面原子组合而形成的一类界面元素。例

如：工具栏、组合框等；第三个层次是一个完整的窗口，一个

完整的窗口是由一系列界面组合元素组成的能够完成一个完整

的输入输出功能的界面属性组合，并且它具有自己的视图。

2、在不同的界面层次确定不同的测试策略

一般在界面原子层，主要考虑界面原子的显示属性、触发

机制、功能行为、可能的状态集等内容。对于界面原子可能接

受的输入可以从等价类划分，边界值分析等角度考虑，触发机

制可以从规范导出的方法分析，功能行为可以使用因果图或判

定表，可能的状态集可以使用错误猜测法或基于错误的测试方

法等。对于界面组合元素，主要考虑界面原子组合顺序、排列

组合、整体外观、组合后功能行为的多个角度测试。对于一个

完整的窗口，主要考虑窗口的整体外观、窗口元素的排列组合、

窗口属性值、窗口可能的各种组合行为等。

3.分析测试数据并提取测试用例。

对于界面元素的外观，可以从以下几个角度获取测试数据:

1）界面元素尺寸；

2）界面元素的形状；

3）界面元素的颜色、对比度、亮度；

4）界面元素中包含的文本属性（如字体、排序方式、大小

等。）.

对界面元素的布局，可以从以下几个角度获取测试数据：

1）各界面元素的位置；

2）各界面元素的对齐方式；

3）各界面元素间间隔；

4）Tab顺序；

5）所有界面元素的配色。

对于界面元素的行为，可以从以下角度获取测试数据：

1）回声功能；2）输入限制和输入检查；3）输入提醒；

4）联机帮助；5）默认值；6）激活或取消激活；

7）焦点状态；8）功能键或快捷键；

9）操作路径；10）行为回退。

4、使用自动测试工具进行脚本化工作。

(4)风险分析

界面测试存在的主要风险有：

1)在测试后期，界面发生重大改变，导致测试工

作被动。

2)受整个测试进度影响，界面测试用例未能完全执行。

(5)测试组织

用户界面测试主要由测试团队完成。测试组长负责编写用

户界面测试计划、方案和测试总结报告。团队成员负责编写和

执行用户界面测试用例，编辑、调试和执行测试脚本，填写测

试日志和问题报告等。用户界面测试与功能测试相同，通常与

功能测试同时进行。具体流程如图。

(6)效果评估

由测试组长撰写用户界面测试报告，对用户界面测试阶段

的工作组织、测试进度、缺陷分布、严重性、数量、人员效率

等方面进行综合评估。

1.1.153负载测试(压力测试)

(1)测试内容

负载测试也是一种性能测试。在这种测试中，将使测试对

象承担不同的工作量，以评测和评估测试对象在不同的工作量

条件下的性能行为，以及持续正常工作的能力。负载测试的目

标是确定并确保系统在超出最大预期工作量的情况下仍能正常

运行。此外，负载测试还要评估性能特征，例如相应时间、事

物处理速率和其他与时间相关的方面。

（2）测试规范

测试规格：

1）负载测试应考虑虚拟用户数量的增加幅度和方式；

2）负载测试使用组装点模拟数据集中提交；

3）负载测试的负载增加方式要模拟系统的实际需求和用

户真实的负载产生情况。

（3）测试方法

负载测试使用loadrunner控制器模拟生成特定数量的

vuser来运行实际程序，从而逐步增加负载。运行渐增vuser时,

吞吐量、响应时间、cpu负载、内存使用等关键性能指标。可

以根据业务需求进行监控。

（4）风险分析

负载测试存在的主要风险为对负载测试工具使用不熟练，

导致测试效率低下；场景规划不合适，导致负载模拟没有体现

真实的系统负载。

（5）测试组织

负载测试主要由测试小组来完成，测试组长负责负载测试

计划、方案和测试总结报告的编写，组员负责负载测试用例的

编写、执行、测试脚本的编辑、调试和执行并填写测试日志和

问题报告等。负载测试的基本工作过程如下：

（6）效果评估

由测试组长撰写负载测试报告，对负载测试阶段的工作组

织、测试进度、缺陷分布、严重性、数量、人员效率等方面进

行综合评估。压力测试需保证系统满足平台建设性能要求。测

试结果形成《压力测试报告》提交用户方。

性能测试

在一定工作负荷和配置条件下，测试系统的各项性能指标,

验证其对合同约定的性能需求的满足程度（确保测试结果高于

性能指标要求）。

性能测试前，设置模拟运行环境、访问用户数等性能测试

的基本条件，编写单用户和并发用户环境下的系统访问脚本。

在测试过程中，测试主测试系统的响应能力指标、处理能

力指标、可用性、可靠性、稳定性、适应性、可操作性和可扩

展性。

（1）测试内容

性能测试是对响应时间、事务处理速率和其他与时间相关

的需求进行评测和评估。性能测试的目标是核实性能需求是否

都已满足。根据本项目实际情况要求如下：

1）操作界面响应时间：在稳定的网络环境下，简单系统查

询响应时间小于5秒，复杂系统响应时间小于30秒；

2）息发布响应时间，单个管理氏户登录后台页面的平均

时间3秒内；

3）前端并发要求，系统应能支持50个用户同时在线使用。

测试内容包括：

1）应用在客户端性能的测试：比如并发性能测试、疲劳

强度测试、大数据量测试、速度测试等。

2）网络性能测试：如网络模拟、网络应用性能分析、网络

应用性能监控、网络预测等。

3）应用在服务器上性能的测试：对主机和操作系统的监

控、对数据库及应用系统的监控、对中间件服务器的监控。

（2）测试规范

性能测试需遵循如下规范：

1）需考虑测试工具的硬件和软件配置要求。

2）定义测试类型以及与该类型相关的测试环境需求。

3）性能测试不仅要评估系统当前的性能，还要预测未来的

性能

4）性能测试的关键是寻找系统瓶颈所在。

性能测试的基本方法：

性能测试基本方法：

1、明确测试需求和测试内容

通过综合分析系统的业务需求说明，结合系统运行的实际

环境，列出明确的性能测试需求。对关键业务进行重点性能分

析。

2、制定测试案例

按照公司性能测试规范，编写性能测试案例。

3、测试环境准备

搭建性能测试环境，安装并配置性能测试工具。

4、测试脚本录制、编写和调试

依照性能测试案例，录制自动化测试脚木，通过编辑调试

保证脚本的正确运行。

1）制定脚本分配、回放配置和加载策略：根据前面分析

的性能测试需求，确定脚本的分配、配置和加载策略。

2）测试执行跟踪：在测试工具中运行预定脚本，跟踪性

能测试过程。

3）结果分析与测试评估：使用专门的结果分析软件对性

能测试结果进行分析汇总，确定系统瓶颈所在。明确关键业务

交易时间并预测未来趋势。

（4）风险分析

性能测试存在的主要风险为：

1）无法构建独立的完善的性能测试环境

2）性能测试结果不准确；

（5）测试组织

性能测试主要由测试小组来完成，测试组长负责性能测试

计划、方案和测试总结报告的编写，组员负责性能测试用例的

编写、执行、测试脚本的编辑、调试和执行并填写测试日志和

问题报告等。性能测试的基本工作过程如下：

（6）效果评估

由测试组长撰写性能测试报告，对性能测试阶段的工作组

织、测试进度、缺陷分布、严重性、数量、人员效率等方面进

行综合评估。

1.1.1.5.5强度测试

（1）测试内容

强度测试是一种功能测试，实施和执行此类测试的目的是

找出因资源不足或资源争用而导致的错误。如果内存或磁盘空

间不足，测试对象就可能会表现出一些再正常条件下并不明显

的缺陷。而其他缺陷则可能由于争用共享资源（如数据库或网

络带宽）而造成的。强度测试还可用于确定测试对象能够处理

的最大工作量。

强度测试的目的在于：

1）获得系统总用户负荷增加时单个用户真实的个人体验

2）确定运行该应用程序硬件的最大负荷，从而决定在将

应用程序推广到实际应用中去前，是否有必要对硬件进行升级。

3）根据平均页面响应时间，为程序的使用者确定可接受

的运行性能的阈值。

4）确保系统在预期的最大并行比户负荷时，性能的阈值

仍然处于可接受的水平。

（2）测试规范

强度测试规范为：

1)强度的设置需考虑业务系统的实际情况，避免过多或

过少地增加系统强度；

2)需对强度测试结果进行分析确定哪部分硬件设备或软

件模块影响了系统的性能。

(3)测试方法

强度测试首先是使用LoadRunner工具对业务系统进行强

度测试，测定Web服务器每秒种所能处理的最大请求数，这

是定量的测量。第二步确定CPU、内存或终端设备中哪一项

限制了每秒请求数达到更高的水平：

(4)风险分析

强度测试存在的主要风险有：

1)用户强度负荷设置不合理；

2)没有合适的强度测试工具。

(5)测试组织

强度测试主要由测试小组来完成，测试组长负责强度测试

计划、方案和测试总结报告的编写，组员负责强度测试用例的

编写、执行、测试脚本的编辑、调试和执行并填写测试日志和

问题报告等。强度测试的基本工作过程如下：

(6)效果评估

由测试组长撰写强度测试报告，对强度测试阶段的工作组

织、测试进度、缺陷分布、严重性、数量、人员效率等方面进

行综合评估。

LL1.5.6容量测试

能力测试的内容包括：

容量测试使测试对象处理大量数据，以确定是否达到了使

软件发生故障的极限。容量测试还将确定测试对象在给定的时

间内容能够持续处理的最大负载或工作量。例如，如果测试对

象正在为生成一份报表而处理一组数据库记录，那么容量测试

就会使用一个大型测试数据库，检验该软件是否正常运行并生

成了正确的报表。

容量测试分为两种，一是独立的容量测试：针对某些存储、

传输、统计、查询等业务进行容量测试；二是综合容量测试：

和压力性能测试、负载性能测试、强度性能测试相结合的综合

测试方案。

容量测试的内容包括：

1）当使用敏感操作时进行的相关数据比较；

2）对包含大量数据的记录进行模糊查询操作；

3）对大量数据进行批量修改操作；

4）对大量数据记录的计算、分析操作；

5）在网络上大量发送邮件息。

（2）测试规范

进行容量测试时须遵守如下规范：

1）测试数据需充分考虑实际业务需求；

2）测试数据要有有效的管理手段，以方便数据转换、编

辑、数据浏览、数据比较、数据迁移等。

（3）测试方法

进行容量测试关键是能产生符合业务要求的大量数据记录,

可以使用测试数据生成工具TestBytes或DataFactory确定需要

生成的数据类型，通过与数据库的连接来自动生成百万行的正

确的测试数据。

在该项目的测试中共我们将使用DataFactory结合

LoadRunner来完成测试数据的生成和综合容量测试。

进行容量测试一般可以通过以下几个步骤来完成：

1）分析系统的外部数据源，并进行分类；

2）对每类数据源分析可能的容量限制，对于记录类型数

据需要分析记录长度限制、记录中每个域长度限制和记录数量

限制；

3）对每个类型数据源，构造大容量数据对系统进行测试;

4）分析测试结果，并与期望值比较，确定目前系统的容

量瓶颈；

5）对系统进行优化并重复（1）〜（4）步骤，直到系统

达到期望的容量处理能力。

（4）风险分析

容量测试存在的主要风险为：

1）进行容量测试所使用的测试数据的数量和实际业务系

统未来的数据量存在明显偏差而导致容量测试不能发现真正的

容量隐患。

2）对测试数据生成工具不熟悉，无法快速生成大量有效

的测试数据。

（5）测试组织

容量测试主要由测试小组来完成，测试组长负责容量测试

计划、方案和测试总结报告的编写，组员负责容量测试用例的

编写、执行、测试脚本的编辑、调试和执行并填写测试日志和

问题报告等。容量测试的基本工作过程如下：

（6）效果评估

由测试组长撰写容量测试报告，对容量测试阶段的工作组

织、测试进度、缺陷分布、严重性、数量、人员效率等方面进

行综合评估。

1.1.1.5.7安全性和访问控制测试

(1)测试内容

安全性和访问控制测试侧重于安全性的两个关键方面：应

用程序级别的安全性，包括对数据或业务功能的访问；系统级

别的安全性，包括对系统的登录或远程访问。

1、应用程序级别的安全性

可确保在预期的安全性情况下，主角只能访问特定的功能

或用例，或者只能访问有限的数据。例如，可能会允许所有人

输入数据，创建新账户，但只有管理员才能删除这些数据或账

户。如果具有数据级别的安全性，测试就可确保“用户一“能够

看到所有客户消息(包括财务数据)，而“用户二”只能看见同

一客户的统计数据。比如B/S系统，不通过登入页面，直接输

入URL,看其是否能够进入系统？

2、系统级别的安全性

可确保只有具备系统访问权限的用户才能访问应用程序，

而且只能通过相应的网关来访问。

安全性是一种保护系统，它不仅对于保证机密数据的安全

性是必需的，而且出于竞争目的而保护第三方数据这一点来说

它也是必要的。安全性测试用于评价保护性程序以及安全对策

的充分性。

安全性测试分为物理安全性测试和逻辑安全性测试。物理

安全性主要针对利用物理方法收集息的手段，而逻辑安全性主

要针对使用计算机处理或通能力进行非法获取息的手段。另外,

访问控制也可根据访问身份不同而区分。

安全性测试主要验证隐私是否受到保护、数据是否加密、

数据是否防篡改，以及应用程序是否能够承受各种类型的恶意

攻击。

测试内容如下：

1）系统的登录；

2）用户管理；

3）防火墙；

4）系统数据；

5）WEB安全性，如WEB的加密，解密，数字签名等；

6）数据库的安全性；

7）内部通协议；

8）系统防病毒测试；

9）测试未经许可的访问，保证系统可以识别和防止资源

的未授权访问。

（2）测试规范

1）确定对识别安全风险足够重视。

2）确定对系统的现实定义及其加强措施已经实施。

3）确定由足够的专家执行充分的安全性测试。

4）执行合理的测试来确保安全性保护措施的正确执行。

（3）测试工具

安全性测试使用的工具主要为DOS模拟攻击工具、网络

探测工具。

（4）测试方法

1）借助安全性测试工具对系统漏洞进行攻击发现潜在安

全漏洞；

2）访问控制测试用例质量不高，无法发现访问控制中存在

的问题。

（5）风险分析

安全性和访问控制测试存在的主要风险为：

1）使用安全性测试工具并不能全部暴露系统安全隐患；

2）访问控制测试用例质量不高，不能发现访问控制中存

在的问题。

（6）测试组织

安全性和访问控制测试主要由测试小组来完成，测试组长

负责安全性和访问控制测试计划、方案和测试总结报告的编写,

组员负责安全性和访问控制测试环境的搭建、测试用例的编写、

执行并填写测试日志和问题报告等。安全性和访问控制测试的

基本工作过程如下：

（7）效果评估

由测试组长撰写安全性和访问控制测试报告，对安全性和

访问控制测试过程的工作组织、测试进度、缺陷分布、严重性、

数量、人员效率等方面进行综合评估。

1.1.158故障转移测试（灾备与恢复测试）

（1）测试内容

故障转移可确保测试对象能成功完成故障转移，并能从导

致意外数据损失或数据完整性破坏的各种硬件、软件或网络故

障中恢复。故障转移测试可确保：对于需持续运行的系统，一

旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统,

以避免丢失任何数据或事务。

故障测试内容包括：当主机系统发生故障时，能否顺利切

换到备机系统，切换的时间有多长？在主备机切换的过程中业

务处理过程会不会中断，未存盘的业务数据会不会丢失。

(2)测试规范

故障转移测试规范为：进行故障转移测试时需测试业务数

据是否丢失、业务操作过程是否中断；需保证主备机的切换操

作时间满足系统业务需求。

(3)测试工具

靠手工干预主机操作来触发故障转移动作，不需要额外的

测试工具。

故障转移测试方法包括：

故障转移测试方法有：

1)制定故障转移测试计划，列出进行测试的时间、环境、

触发动作等；

2)编写故障转移测试用例，按尺例执行既定的操作，需

要多人配合完成一次故障转移的执行、监督和查看。

(5)风险分析

故障转移测试存在的主要风险为故障的不可预见性和破坏

力，模拟测试很难完全实现全部的故障类型和故障强度的模拟,

存在发生某些故障后主备机无法完成切换的问题；

1)主备机切换的时间过长不能满足业务需求；

2)主备机切换中出现数据丢失、流程中断等错误。

(6)测试组织

故障转移测试主要由测试小组来完成，测试组长负

责故障转移测试计划、方案和测试总结报告的编写，

组员负责故障转移测试环境的搭建、测试用例的编写、

执行并填写测试日志和问题报告等。故障转移测试的

基本工作过程如下：

（7）效果评估

由测试组长撰写故障转移测试报告，对故障转移测试过程

的工作组织、测试进度、缺陷分布、严重性、数量、人员效率

等方面进行综合评估。

1.1.1.5.9恢复测试

（1）测试内容

恢复测试是一种对抗性的测试过程。在这种测试中，将把

应用程序或系统置于极端的条件下（或者是模拟的极端条件

下），以产生故障（例如设备输入/输出（I/O）故障或无效的数

据库指针和关健字）。然后，调用恢复进程并监测和检查应用

程序和系统，核实应用程序或系统和数据已得到了正确的恢复。

恢复测试包括：在应用程序人工干预、输入能力丢失、通

线路失效、硬件或操作系统失效、数据库完整性遭到破坏、操

作错误以及应用系统崩溃等情况下的恢复操作。

（2）测试规范

恢复测试规范如下：

1）如果系统本身能够自动地进行恢复，则应检验重新初

始化、检验点设置机构、数据恢复以及重新启动是否正确。

2）如果这一恢复需要人为干预，则应考虑平均修复时间

是否在限定的范围以内。

（3）测试工具

恢复测试需要人为的置入故障来测试，例如：在系统运行

过程中突然中断电源或切断网络连接等。基本上不需要特定的

测试工具。

（4）测试方法

对该项目的恢复测试应该使用为功能和业务周期测试创建

的测试来创建一系列的事务。一旦达到预期的测试起点，就应

该分别执行或模拟以下操作：

1）客户机断电：关闭PC的电源。

2）服务器断电：模拟或启动服务器的断电过程。

3）通过网络服务器产生的中断：模拟或启动网络的通中

断（实际断开通线路的连接或关闭网络服务器或路由器的电

源）。

4）DASD和DASD控制器被中断、断电或与DASD和

DASD控制器的通中断：模拟与一个或多个DASD控制器或

设备的通，或实际取消这种通。

一旦实现了上述情况（或模拟情况），就应该执行其他事

务。而且一旦达到第二个测试点状态，就应调用恢复过程。

在测试不完整的周期时，所使用的方法与上述方法相同，

只不过应异常终止或提前终止数据库进程本身。

对以下情况的测试需要达到一个已知的数据库状态。当破

坏若干个数据库字段、指针和关键字时，应该以手工方式在数

据库中（通过数据库工具）直接进行。其他事务应该通过使用

”应用程序功能测试”和“业务周期测试”中的测试来执行，并且

应执行完整的周期。

（5）风险分析

恢复测试存在的主要风险为故障的不可预见性和破坏力，

模拟测试很难完全实现全部的故障类型和故障强度的模拟。

（6）测试组织

恢复测试主要由测试小组来完成，测试组长负责恢复性测

试计划、方案和测试总结报告的编写，组员负责恢复性测试环

境的搭建、测试用例的编写、执行并填写测试日志和问题报告

等。恢复性测试的基本工作过程如下：

(7)效果评估

由测试组长撰写恢复测试报告，对恢复测试过程的工作组

织、测试进度、缺陷分布、严重性、数量、人员效率等方面进

行综合评估。

LLL5.10配置测试

(1)测试内容

配置测试核实测试对象在不同的软件和硬件配置中的运行

情况。在大多数的生产环境中，客户机工作站、网络连接和数

据库服务器的具体硬件规格会有所不同。客户机工作站可能会

安装不同的软件。例如，应用程序、驱动程序等，而且在任何

时候，都可能运行许多不同的软件组合，从而占用不同的资源。

配置测试的内容有：

1、硬件配置测试

测试系统在不同的CPU、内存、显示器分辨率下的运行

状况。例如：该软件是烧在并口设备中的，测试同时使用其他

并口设备，系统是否可以正确使用。比如在INTER,

AMDCPU芯片下系统是否能够正常运行？这样的测试需建立

测试实验室，在各种环境下进行测试。

2、软件配置测试

测试系统在不同的操作系统、不同的浏览器版本下的运行

状况。测试软件在不同厂商的浏览器下是否能够正确显示与运

行，例如：测试IE,Natscape浏览器下是否可以运行这套软

件？测试WINDOWS98,WINDOWS

2000,WINDOWSXP,LINUX,UNIX下是否可以运行这套软件？

3、网络配置测试

测试系统在不同的网络环境和网络速率下的运行状况。

(2)测试规范

配置测试要规范如下：

1)搭建配置测试环境要充分考虑系统需求，避免测试环

境过少而遗漏测试，同时也不能模拟过多的环境来增加测试的

负担和成本，通常配置测试需要考虑到当前流行的硬件配置、

操作系统版本和浏览器版本。

2)对于不同屏幕大小的测试取决于系统设计规格的定义，

如果系统只能运行在1024*768的环境下，则就没有必要考虑

系统在800*600环境下的表现。前提是这种设计规格要经过客

户的签字确认。

(3)测试工具

在实施配置测试时，可使用VMWare来生成虚拟的各种

软硬件环境来实现。

（4）测试方法

配置测试有两个工作量最大的操作，分别是搭建不同的配

置环境和在不同的配置环境下运行测试。进行此类测试需要的

设备资源和人力资源相对较多，要实现完全的配置测试需要下

面的方法：

1）分析系统业务需求，列出配置测试环境对照表格；

2）按表格条目要求使用虚拟软件工具依次搭建所需的环

境；

3）在测试环境中运行系统的关键测试用例，报告并发现

问题所在。

（5）风险分析

配置测试中存在的主要风险有：

1）无法完整模拟客户真实的工作环境，导致的测试不充

分问题；

2）测试所需资源多、工作量大，测试小组不能获得足够

的人力、物力资源来完成所有配置测试。

（6）测试组织

配置测试主要由测试小组来完成，测试组长负责配置测试

计划、方案和测试总结报告的编写，组员负责配置测试环境的

搭建、测试用例的编写、执行并填写测试日志和问题报告等。

配置测试的基本工作过程如下：

(7)效果评估

由测试组长撰写配置测试报告，对配置测试过程的工作组

织、测试进度、缺陷分布、严重性、数量、人员效率等方面进

行综合评估。

1.1.1.5.11安装测试

(1)测试内容

安装测试有两个目的。第一个目的是确保该软件在正常情

况和异常情况的不同条件下：例如，进行首次安装、升级、完

整的或自定义的安装都能进行安装。异常情况包括磁盘空间不

足、缺少目录创建权限等。第二个目的是核实软件在安装后可

立即正常运行。

安装测试的步骤和内容包括：

编号

1

步骤名称

启动安装程序

测试内容

如果安装了CD-ROM,插入安装盘后自动启动安装程序或

在CD盘中

突出显示setup.exe文件，双击文件启动安装程序

“载入安装程序”对话框出现后，检查：内容是否正确；拼

写是

否正确；在安装过程中，随着载入安装程序界面的出现，

闪屏也

随即出现。

弹出框出现时，检查：内容是否正确；拼写是否正确。

点击右上角的X按钮关闭时是否出现询问退出的对话框,

如“您

确定要退出吗？'选择取消按钮是否出现询问退出的对

话框，

如“您确定要退出吗？"；单击"是”后出现提示应用系统没

有被正确地安装，用户需重新安装的息；单击“否”后关闭

对

话框且返回到先前的界面；

安装导航引导用户到正确的屏幕，例如下一步（Next）,

返回

(Back),取消(Cancel)按钮；焦点停留的按钮能够引

导到下2

3

闪屏

弹出框

4中途退出

5安装导航

编号步骤名称测试内容

一个合理的操作，例如standalone安装类型将引导到

standalone

安装中的下一个屏幕；使用键盘导航。

程序可以选择“C：”以外的目录；通过单击按钮可以

选

择其他的安装路径；可以通过以下方法选择路径：焦点在

“确

定”按钮上,按“Enter”键、焦点在“确定”按钮上，点击“确

定”按钮、从浏览文件夹中双击选择路径、直接输入路径;

文本框中输入的路径不存在时，系统可以创建。

无异常出现；所有的文字可以正常显示（无截断）；界面

上的版

本息，公司息（图标，时间，地址等）正确；许可证协议

息完整、正确。

有弹出窗口显示安装完毕；所有的文件都安装在选择的目

录下；

要求的dl全部安装；帮助文件安装在指定的文件夹下；

检查.exe

和dl文件的版本号是否正确；检查Ini文件是否记载了

正确的

路径和IP地址息；检查需注册息在注册表中是否存在且

在正

确的地方；快捷方式创建在选择的文件夹/启动菜单中，

例如：

C:\WINNT\Profiles\xs564gb\StartMenu\Programs\Executive

Workbench；日志文件（Log）中的息完整、正确

可以通过以下方式启动应用程序：双击目录中的应用程序

图标；

从开始菜单中选择;焦点放在exe文件上，敲“Enter”键;

双击

exe文件；运行命令下启动；双击桌面上的快捷方式

如果有对话框提示需重启计算机才能完成安装，重启机器

再启动

应用程序是否可以正常工作。

通过Uninstall程序或控制面板卸载应用程序；卸载后，

检查安

装的文件/文件夹/注册表息是否被删除

6目的地文件

7安装过程

8安装完毕

9启动应用程序

重启后启动应用

程序

卸载

10

11

(2)测试规范

安装测试应遵循的规范如下：

1)测试应用程序安装、运行脚本时未出现错误，以及所

有主要功能都能通过测试。

2）测试安装在客户端计算机上的所有文件版本（包括代

码和内容）都正确。

3）测试可以卸载应用程序并测试清理的验证。

4）在安装中验证文件的命名标准。

5）验证安装程序在遇到错误情况（例如磁盘空间不足）

时可以正常退出。

6）在安装过程中验证注册表项，以及在卸载过程中验证

注册表的清理。

7）执行全新的计算机安装。这台计算机带有新安装的操

作系统和少量必需的已安装组件。

8）测试具有不同软件配置的计算机上的安装。

9）测试安装程序创建了正确的Start菜单项。

10）测试安装程序将文件置于正确的文件夹中。

11）测试程序集是否在部署服务器上进行加密和数字签名,

并在客户端下载时进行验证。

（3）测试工具

安装测试靠手工完成，不需要测试工具。

（4）测试方法

构建不同的操作平台，然后在平台上按安装测试操作步骤

和内容执行安装。

（5）风险分析

安装测试存在的主要风险为：安装测试操作平台模拟不够,

在个别平台上可能会出现安装问题。

（6）测试组织

安装测试主要由测试小组来完成，测试组长负责安装测试

计划、方案和测试总结报告的编写，组员负责安装测试用例的

编写、执行、测试脚本的编辑、调试和执行并填写测试日志和

问题报告等。安装测试的基本工作过程如下:

（7）效果评估

由测试组长撰写安装测试报告，对安装测试阶段的

工作组织、测试进度、缺陷分布、严重性、数量、人

员效率等方面进行综合评估。

1.1.1512文档测试

由测试人员按照用户需求对用户需求说明书、软件需求规

格说明书、软件设计说明书、数据库设计说明书、接口设计说

明书、安装配置手册、用户手册、培训手册等文档进行测试。

通过测试，检查文档的正确性、完备性和可理解性，并找出系

统实现与需求之间的不一致之处，并提交相应的测试报告。

在本项目的文档测试中，各类文档具有不同的测试优先等

级，如下所示：

序号

1

2

3

4

5

6

7