范文一：软件功能测试报告

福建晨曦软件开发有限公司

<项目名称>

软件功能测试报告

版本:<1.0>

文档编号: 密 级: 秘密 编 写: 编写日期: 年 月 日 审 核: 审核日期 年 月 日 批 准: 批准日期: 年 月 日

修订记录

版本 章节名称 修订内容 修订日期 修订人 批准人

目录

1. 项目简介................................................................................................................... 1 1.1 目的 ...................................................................................................................... 1 1.2 项目简述 ............................................................................................................... 1 1.3 定义 ...................................................................................................................... 1 1.4 参考文档 ............................................................................................................... 1

2. 测试概要................................................................................................................... 13. 测试情况................................................................................................................... 1 3.1 软件情况 ............................................................................................................... 1 3.2 测试安排 ............................................................................................................... 2 3.3 测试小结 ............................................................................................................... 2

1. 项目简介

1.1 目的

本文档用于对<项目名称>的功能测试阶段的成果描述，包括对软件功能的测试过程、

测试方法及测试结果的描述。

1.2 项目简述

项目名称:<项目名称>

开发小组:

1.3 定义

1.4 参考文档

《XXXXXX》

《XXXXXX》

《XXXXXX》

2. 测试概要

本次测试主要为功能测试和界面测试测试系统各项功能是否符合设计标准，功能是否正

确，找出影响系统正常运行的错误。

3. 测试情况

3.1 软件情况

软件版本等基本信息

1

3.2 测试安排

测试模块 测试时间 测试人员 测试文档 XXX模块 2011-06-28—2011-06-28 陈晗 XXX模块测试记录

3.3 测试环境

3.4 测试小结

3.5 测试结论

范文二：软件功能测试指南

软件功能测试指南 Page 1 of 25

1.0 名称 编 号 拟 制 黄锡波

版本号 初稿 审 核 软件功能测试指南 密 级 普通 共25页 批 准 更改信息

更改日期 版本 部门及更改人 版本说明 2006-01-18 初稿 研发部 黄锡波 创建

软件功能测试指南 Page 2 of 25

简介 ...................................................................... 5

1 概述 ............................................................... 6

1.1. 功能测试目标 .................................................. 6

1.2. 功能测试类型 .................................................. 6

1.3. 功能测试阶段 .................................................. 6

1.4. 功能测试过程 .................................................. 6 2 分析功能需求 ........................................................ 7

2.1. 分析功能需求 .................................................. 7 3 了解系统设计与实现 ................................................... 7

3.1. 了解系统设计与实现............................................. 7 4 建立数据模型 ........................................................ 7

4.1. 建立数据模型 .................................................. 7

4.2. 建立数据模型示例 .............................................. 8 5 制定功能测试计划 ..................................................... 8

5.1. 测试环境 ..................................................... 8

5.2. 测试软件 ..................................................... 9

5.3. 测试人员 ..................................................... 9

5.4. 测试目标 ..................................................... 9

5.5. 测试日程 ..................................................... 9

6 设计场景 ............................................................ 9

6.1. 设计功能测试的测试案例 ........................................ 10

6.2. 功能测试案例设计模板 .......................................... 10

6.3. 设计场景示例 ................................................. 10 7 根据场景编写程序、自动测试脚本编写等 ................................... 11

7.1. 程序编写 .................................................... 12

7.2. 脚本编写 .................................................... 12

8 功能自动化测试 ...................................................... 12

8.1. 功能自动测试引入条件 .......................................... 12

8.2. 对实施自动化测试的风险分析 ..................................... 14

8.3. 什么条件下使用自动化测试 ...................................... 14

8.4. 常用功能自动化测试工具 ........................................ 14 9 执行功能测试 ....................................................... 15

9.1. 准备功能测试环境 ............................................. 15

9.2. 执行功能测试 ................................................. 16

9.2.1 执行功能测试 ................................................. 16

9.2.2 缺陷管理 ..................................................... 16

9.3. 功能回归测试 ................................................. 17

9.4. 测试报告 .................................................... 17

10 测试管理 ........................................................... 17

软件功能测试指南 Page 3 of 25

10.1. 功能测试通过标准 ............................................. 17

10.2. 测试提交物 .................................................. 17

10.3. 提交文档的模板 ............................................... 18

10.4. 测试工作流程 ................................................. 18

10.5. 迭代开发模式 ................................................. 20

11 附录 .............................................................. 20

11.1附录1:功能测试案例设计模板 .......................................... 20

11.1.1 功能测试案例设计模板 .......................................... 20

11.1.2 界面测试案例设计模板 .......................................... 21 11.2附录2:WinRunner功能测试工具简介.................................... 24 11.3附录3:MAXQ功能测试工具简介 ......................................... 25 11.4附录4:CaseDriverTest功能测试工具简介 .............................. 25 11.4附录4:TestComplete功能测试工具简介 ................................ 25

软件功能测试指南 Page 4 of 25

阅读对象：

该文档的阅读对象为：软件开发、质量、测试人员。

排版约定：

类型 示例

注释 提示、注释

相关文档：

《软件性能测试与调优指南.doc》

软件功能测试指南 Page 5 of 25

1

1.1.

测试软件在系统中运行的正确性, 评估是否满足功能需求；

正确性是软件最重要的质量因素,因此功能测试也是最重要的。

1.2.

界面测试

功能测试

业务流程测试

周期（Cycle）测试

1.3.

可以发生在各个测试阶段中，即使是在单元层，一个单独模块的功能也可以使用黑盒测试来进

行正确性验证；

经过单元测试和集成测试的功能，即可在独立的测试环境中进行功能测试；

通常，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的功能是否满足需求。

1.4.

应用系统的功能测试通常有如下过程：

1) 分析功能需求：分析系统功能需求，建立功能测试数据模型；

2) 制定功能测试计划：规划功能测试所需的测试环境、测试程序，测试的人员组织，测试日

程等；

3) 设计场景：设计功能的测试案例；

4) 根据案例编写程序、编写脚本等；

5) 执行功能测试：建立测试环境、执行测试案例，记录测试时的系统的各个可能的参数；

6) 分析测试结果：根据应用系统表现和测试时的系统记录，分析发生的问题和测试结果；

8) 功能回归测试：程序修改后，验证功能的正确性以及对相关功能模块正确性的影响； 软件功能测试指南 Page 6 of 25

9) 测试报告：对测试进行总结，记录已改进的问题及相关改进的修改，制定未解决问题的对

策，提出系统运行、维护和改进建议。

2

2.1.

理解功能模块分类及每个功能的描述，分析每个功能的输入操作的典型值、边界值、异常值及

预期的结果；

理解每个功能操作的前置条件、操作描述和预期结果，并分析当违反操作或不满足前置条件时

的预期结果；

理解由多个功能联合而成的业务流程以及各环节操作的前置条件、操作描述、预期中间结果、

预期最终结果，并分析在各环节中当违反操作或不满足前置条件时的预期结果；

理解由多个业务流程联合而成的业务周期(日终、月终、年终、结算日等)，以及各环节操作的

前置条件、操作描述、预期中间结果、预期最终结果，并分析在各环节中当违反操作或不满足前置

条件时的预期结果。

3

3.1.

了解系统实现的系统数据、数据字典及业务基础数据；

了解每个功能的系统设计及如何实现的；

了解每个功能所对应的数据库及关键数据域的定义；

了解每个功能实现的异常处理及错误日志的定义；

了解功能实现的公共类、复杂类及复杂算法。 4

4.1.

根据功能需求的分析，以及对系统设计和实现的了解，建立功能测试所需的数据模型并依次产生相

应测试数据。

软件功能测试指南 Page 7 of 25

系统数据：是系统级数据，与业务功能没有直接关系，是支撑应用系统运行的底层数据；

数据字典：是支撑应用系统运行的公共数据，与业务功能有密切的关系；

业务基础数据：是支撑功能正确运行的基础数据。

4.2.

下面是一个建立数据模型的示例：

系统数据

建立workflow数据，脚本是insert into workflowdata (……);

建立每个线程的计时控制数据，脚本是insert into threadTC （……）；

数据字典

建立多语言网页的数据字典，脚本是insert into languages （……）；

建立业务类型、业务代码与交易代码对应关系的数据字典，脚本是insert into actives

（……）；

业务基础数据

建立佣金计算业务的基础数据，脚本是insert into commisions （……）；

建立客户基础数据：脚本是insert into clients （……）；

建立机构基础数据：脚本是insert into organization （……）；

提示：建立数据模型创建基础数据（也称基线数据），是功能测试过程中最重要的步骤

特别提示：插入基础数据的脚本必须经过设计团队审核通过，数据域定义必须清晰、无二义性，且与开发文档吻合，

特别注意null与””、大小写等问题

5

规划功能测试所需的测试环境、测试软件，测试的人员组织，测试日程等；

5.1.

测试环境示例：

表一：测试环境

CPU 服务器 机型 数量 内存 存储 网络 操作 系统 应用 备注 软件功能测试指南 Page 8 of 25

连接 系统 软件 系统

IBM Oracle 数据库

RS6000 2 8 16G SAN 1000M AIX 9.2 服务器 数据库

650

IBM WebLogic 应用 应用

RS6000 1 2 4G SAN 1000M AIX 8.1 服务器 系统

630

5.2.

（描述需要测试的应用软件）

5.3.

（描述测试人员）

5.4.

（描述本次测试任务的目标）

5.5.

表六：测试日程示例

()

2 2005-08-16 2005-08-17 第一阶段 方案设计、案例设计 黄锡波

2 2005-08-22 2005-08-23 焦求智 方案设计、案例设计review

……

6

软件功能测试指南 Page 9 of 25

6.1.

通常有下列测试案例：界面测试、功能测试、业务流程测试、周期（Cycle）等测试案例。

6.2.

提示：详见附录1 功能测试案例模板

6.3.

下面是设计场景的示例

界面测试

提示：详见附录1界面测试案例设计

功能测试

提示：详见附录1功能测试案例设计

边界内测试

如果功能包含确定的边界,那么必须设计输入域的边界内测试案例：

提示:输入域的输入特征有:

第一个、最后一个; 最小值、最大值; 开始、完成; 超过、在内; 空、满; 最短、最长; 最慢、最快; 最早、最迟; 最大、最小; 最高、最低; 相邻、最远

越界测试

如果功能包含确定的边界,那么必须设计输入域的越界测试案例：

提示:输入域的输入特征有:

第一个减1、最后一个加1; 开始减1、完成加1; 空了再减、满了再加; 慢上加慢、快上加快; 最大数加1、最小数减1; 最小值减1、最大值加1; 刚好超过、刚好在内; 短了再短、长了再长; 早了更早、晚了更晚; 最高加1、最低减1

特殊输入值测试

如果功能包含特殊输入值, 那么必须设计特殊输入值测试案例：

特别提示：特殊输入值的特征有:

默认、空白、空值、零值和无，以及非法、错误、不正确和垃圾数据的时候，预期的输出结果

业务流程测试

以买入股票为例子,业务流程: 委托->实时成交->日终清算

步骤 功能 操作 预期结果

软件功能测试指南 Page 10 of 25

1 初始值 股东:xxx

资金 余额:xxx

可用余额:xxx

可取余额:xxx

股票01,余额:xxx

可用余额:xxx

可卖余额:xxx 2 委托：买入股票01 买入500*3.80 资金变化、股票变化 3 委托：撤单股票01 撤单100 同上

4 100*3.75 实时成交 同上

5 撤单成交 撤单100 同上

6 日终清算 日终清算 同上

周期(Cycle)业务测试

以配股为例子,周期业务流程: 配股权证到帐->配股委托->日终确认->股票到帐 步骤 日期 功能 操作 预期结果 1 2000.12.18 初始值 股东:xxx

资金 余额:xxx

可用余额:xxx

可取余额:xxx

股票01,余额:xxx

可用余额:xxx

可卖余额:xxx

配股权证:xxx

配股确认:xxx 1 2000.12.19 权证到帐 日终清算 资金变化、股票变化 2 2000.12.20 委托：配股 配股500*2.80 资金变化、股票变化 3 2000.12.20 日终清算 日终清算 同上 4 2001.01.18 配股到帐 日终清算 同上

7

软件功能测试指南 Page 11 of 25

7.1.

通常情况下，需要进行以下的测试程序编写：

批量测试数据生成程序；

预期测试结果数据检索程序；

模拟前端向服务器发送业务请求程序。

7.2.

通常情况下，需要进行以下的测试脚本编写,以便于功能回归自动测试：

采用商用界面测试工具Testcomplete或WinRunner录制功能测试脚本；

也可以采用开源功能测试工具MAXQ、CANOO等工具编写或录制测试脚本；

对录制的脚本进行改写：

, 在脚本中插入与预期结果比较的检查点；

, 参数化脚本，例如在同一个脚本中参数化不同角色的用户循环向服务器发送业务请求；

, 对公共模块进行函数化改写。

当功能变化后，需要对已经录制好的脚本进行维护修改。

8

8.1.

自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理

论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能

实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的

增加测试相关的维护成本。

测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放

过程。实际上，从实现成熟度来说，自动化测试分五个级别：

级别 说明 优点 缺点 用法

自动化的测试脚本能够被拥有大量的测试脚本，当需求和应当测试的系统不会发生一级 录制和回放 自动的生成，而不需要有用发生变化时相应的测试脚本也变化时，实现小规模的自

任何的编程知识 必须被重新录制 动化

录制、编辑和回减少脚本的数量和维护的需要一定的编程知识；频繁的变化回归测试时，用于被测试二级 放 工作 难于维护 的应用有很小的变化 三级 编程和回放 确定了测试脚本的设计，要求测试人员具有很好的软件技大规模的测试套件被开软件功能测试指南 Page 12 of 25

在项目的早期就可以开始能，包括设计、开发 发、执行和维护的专业自

自动化的测试 动化测试

能够维护和使用良好的并软件开发的技能是基础，并且需要大规模的测试套件被开数据驱动的测四级 且有效的模拟真实生活中访问相关的测试数据 发、执行和维护的专业自试 数据的测试数据 动化测试

测试用例的设计被从测试需要一个具有工具技能和开发技专业的测试自动化将技使用动作词的五级 工具中分离了出来 能的测试团队 能的使用最优化的结合测试自动化 起来

自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现

测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行

定制,没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设

计工作是相当重要的。

自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测

试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲

目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备

和实施而会被拖跨。

实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。

如果测试过程是不合理的，引入自动化测试只会给项目团队带来更大的混乱。

那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可

持续性的开展下去呢？

第一，从项目规模上来说，没有严格限制。无论项目大小，都需要提高测试效率，希望测试工作标

准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是从公司高层开始，直到测试部门的

任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个

这样的软件开发团队可以优先开展自动化测试工作：测试与开发人员比例合适，比如1：3到1：5，

开发团队总人数不少于10个。

第二，从公司的产品特征来说，一般开发产品的项目实施自动化测试要比纯项目开发要优越些。但

决不是说做纯项目开发不能实施自动化测试，只要软件的开发流程、测试流程、缺陷管理流程规范了，

自动化测试自然水到渠成。

第三，从测试人员个人素质和角色分配来说，除了有高层重视外，还应该有个具有良好自动化测试

背景和丰富自动化测试经验的测试主管，不仅在技术方面，更重要的是在今后的自动化测试管理位置起

着领导的作用。还要有几个出色的开发经验良好的测试人员，当然也可以是开发工程师，负责编写测试

脚本、开发测试框架,还有一些测试执行者，他们要对软件产品业务逻辑相当熟练，配合测试设计者完

成设计工作，并在执行自动测试时，敏锐的分析和判断软件缺陷。

综合分析上述三个条件，就可以决定是否推行自动化测试；但是为了减少实施风险，还要预测到其

他潜在的风险，做好事先解决问题规避风险的思路。

软件功能测试指南 Page 13 of 25

8.2.

资金风险，虽然有些项目具备实施自动化测试的条件，但还是要引入自动化测试后组织结构调整等

方面的成本估算是很必要的。

自动化测试对软件功能类型的切入点的风险，开发的产品业务和功能是否需要自动化测试？包括白

盒自动化测试、功能自动化测试和性能自动化测试。

软件自动化测试切入方式的风险，一定要将自动化测试与手工测试结合起来使用，不合理的规划会

造成工作事倍功半。首先，对于自动化测试率的目标开始是 20/80 （20% 的自动化测试和 80% 的

手工测试），当这些目标都实现了，再将自动化测试率提高。

时间估算，在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的

时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍

的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降

低风险。

工作流程变更风险，测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的

工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多

抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。 8.3.

具有良好定义的测试策略和测试计划（知道要测试什么，知道什么时候测试）；

对于自动化测试你拥有一个能够被识别的测试框架和候选者；

能够确保多个测试运行的构建策略；

多平台环境需要被测试；

拥有运行测试的硬件；

拥有关注在自动化过程上的资源。

没有标准的测试过程；

没有一个测试什么、什么时候测试的清晰的蓝图；

在一个项目中，测试责任人是一个新人，并且还不是完全的理解方案的功能性和或者设计；

整个项目在时间的压力下；

在团队中没有资源或者具有自动化测试技能的人；

8.4.

名称 性质 GUI测试 J2EE应用 DotNET应用 基本描述

TestComplete 商用 ? ? ? GUI测试工具

软件功能测试指南 Page 14 of 25

Winrunner 商用 ? ? × GUI测试工具 MAXQ 开源 × ? ? B/S测试工具 CanOO 开源 × ? ? B/S测试工具 CaseDriverTest Struts MVC 自开发 × ? ×

测试工具 注释:详见附录相关工具的介绍

9

9.1.

硬件、系统软件、网络、存储、测试程序、测试工具

一个充分准备好的测试环境有三个要点：一个稳定、可重复的测试环境，能够保证功能的正确

测试；保证达到功能测试执行的技术需求；保证得到可重复的以及易分析的测试结果。

测试数据

在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的

测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测

试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存

储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

系统配置

测试环境中各种系统软件、测试工具、测试软件的配置，对测试的结果可能都有重大影响，因

此，必须认真进行系统配置的管理，并测试前后，以及修改前后，进行相应的备份。

通常需要仔细检查系统的配置有：

操作系统配置：硬件的配置(CPU、内存、硬盘等)、核心参数、TCP/IP参数以及补

丁的情况等。这里对操作系统的配置,除了更新最新的补丁程序以保证应用程序正常运行之外,

就是调整TCP/IP参数、文件描述符,对于个别操作系统还有其它特别的参数调整。

JVM的配置：-Xms、-Xmx、-verbose:gc、-XX:MaxPermSize、-Xmn等参数的

配置。

Server配置：线程数、连接参数、执行队列参数等。

JDBC配置：连接池配置。

WEB配置、JMS配置、EJB配置。

数据库配置：核心参数、SGA、进程数和游标数等。

提示：系统配置的详细资料可参阅文档《J2EE应用调优指南》。

软件功能测试指南 Page 15 of 25

9.2.

9.2.1

在功能测试的执行过程中，主要关注的是功能是否满足预期的结果。 执行功能测试的步骤是：

预置案例要求的基础数据；

执行案例；

检查返回结果是否满足预期结果；

如果返回结果有缺陷，则需要在缺陷管理系统中记录缺陷信息，主要的信息有：

, 缺陷ID

, 缺陷状态（新的、重新打开、正在修改中、已经修正完毕、待验证、验证未通过、验

证正确、缺陷暂不解决或缺陷悬挂）；

, 执行的案例号；

, 预置的数据；

, 执行的步骤；

, 中间结果（标志、状态、数据）；

, 预期结果；

, 缺陷级别（有四个级别的缺陷）；

, 缺陷的主要表现（界面表现、日志表现、数据库数据表现）；

, 是否可以重现或重现的频率；

, 要求开发组响应级别（一级缺陷要求立即响应，二级缺陷要求一天内响应，三级以上

缺陷由开发组长决定）；

, 缺陷附件（例如缺陷表现的图片）；

, 其它有利于开发人员阅读、理解的附加缺陷描述。

根据需要进行数据备份（通常在业务流程测试和周期测试中，需要对中间结果进行数据备

份，这样便于重现缺陷及功能的回归测试）；

记录案例的测试人、测试状态和测试时间等案例测试管理信息；

根据测试的实际情况完善和修正测试案例，必要时补充测试案例。

9.2.2

采用mantis开源缺陷管理系统

缺陷级别

, ：系统死机或挂起等导致系统不能继续运行;

, ：功能完全错误；

软件功能测试指南 Page 16 of 25

, 功能部分错误;

, 界面拼写错误或易用性差等问题或需要完善的问题。

9.3.

当功能进行了改进或缺陷的改正后，必须进行相应的回归测试，以验证功能修改是否正确。

9.4.

测试报告：

对测试进行总结，记录已改进的问题及相关改进的修改，制定未解决问题的对策，提出系统运

行、维护和改进建议。

10

10.1.

案例执行

, 每个用例需求均有测试案例；

, 每个测试案例均已执行。

通过标准

, 性能满足需求；

, 功能一级、二级、三级错误已经全部解决并通过回归测试；

, 未解决的四级错误数量 < 3%（100个测试案例中，未解决的四级错误少于3个）。="">

10.2.

通常,测试提交物有:

, 测试计划;

, 阶段性测试计划;

, 测试方案及案例;

, 自动测试程序及脚本;

, 测试报告。

软件功能测试指南 Page 17 of 25

10.3.

10.4.

软件功能测试指南 Page 18 of 25

编码及

单元测试

缺陷状态改

变,自动发邮件

给测试人员

N集成测试自动发邮件

给开发人员

mantis开发人员功能测试案缺陷管理系PL/SA确认改变缺陷状例统态

Y

功能测试有缺陷回归测试

性能测试案达到功能测

例试要求

有缺陷

性能测试

达到性能要

求

测试报告

软件功能测试指南 Page 19 of 25

10.5.

通常, 每个开发迭代的测试工作分四个阶段:

, 1 – 初始测试阶段

编写测试计划

, 2 -- 精化测试阶段

本次迭代测试计划、测试案例；

准备本次迭代的测试环境。

, 3 -- 构造测试阶段

对已经过集成的功能进行功能测试、性能测试（评估新增功能对架构的影响）；

细化测试案例及数据；

构建自动测试案例。

, 4 -- 用户测试阶段

测试组:完成本次迭代的功能测试；性能测试；测试报告；开发建议及测试过程优化。

用户：本次迭代功能的试运行并提出项目过程改进意见。

11

11.11:

11.1.1

参数设置

0001

A

系统能够正确读取参数设置，并按照设定的参数运行。

SAF_DISPATCHERS（SAF线程定义表）定义数据：INTERVAL＝5000ms（间隔时间）

SAF_DISP_PARTIES（线程－落地方关系定义表）：STOP_FLAG＝Y/N

SAF_DISP_PARTIES（线程－落地方关系定义表）：HPARTY_ID落地方机构码与某线程对应

关闭saf多线程，打开debug，预期结果:间隔时间是5000ms

关闭saf多线程，打开debug，如果STOP_FLAG＝Y,打开saf多线程,预期结果:线程是不会

起来。反之,当STOP_FLAG＝N,预期结果：线程能够起来

HPARTY_ID落地方机构码没有定义上海,做一笔落地方是上海的VIP机场交易,检查saf表,预

期结果：STATUS=1(未处理)

软件功能测试指南 Page 20 of 25

SAF_DISPATCHERS（SAF线程定义表）定义线程记录3条，重起来线程，预期结果：线程数3

条（注意线程名字）

正确依照设置的参数运行

提示：案例优先级，A（重要的模块功能和业务流程）、B（比较重要的模块功能和业务流程）、C（次重要的模块功能和

业流程）、D（不重要的模块功能和业务流程）、E(系统小单元、系统容错功能)

11.1.2

界面测试案例组编号：xxx_SCR0001,共有25个案例,优先级别:均为B

/

UI界面风格是否1. 符合 符合界面规范设计

UI界面大小是否2. 一致 与界面设计一致

UI界面标题是否3. 正确 正确

UI界面标题是否

4. 与其他界面标题命一致

名规则一致

UI界面是否有错5. 无 别字

UI界面各个功能

按钮排列是否易于6. 易于操作 操作，不会遗漏操

作按钮

UI界面各个功能

7. 按钮风格是否符合符合

界面规范

UI界面是否有合8. 有帮助 适的帮助

1. 所填信息

正确保存到

用户通过用户界面输入刚好等于字数限制相应的数据9. 输入信息 的正确信息，提交 库表中

2. 客户端提

示提交成功 10. 系统提示信息风格符合 软件功能测试指南 Page 21 of 25

/

是否符合界面规范

系统提示信息格式

11. 是否符合提示信息符合 统一规范

系统提示信息内容

是否明确，能正确12. 能正确引导 引导用户进行下一

步的操作

系统提示信息大小

13. 是否与界面设计一一致 致

1. 所填信息

不能正确保

存到相应的

数据库表中 用户通过用户界面输入略超过字数限制的14. 2. 客户端提输入信息 正确信息，提交 示字数超长

3. 引导用户

定位超长输

入

1. 所填信息

正确保存到用户通过用户界面输入略少于字数限制的相应的数据15. 输入信息 正确信息，提交 库表中

2. 客户端提

示提交成功

1. 所填信息

不能保存

到相应的

数据库表

中 用户通过用户界面16. 输入非法字符，提交 2. 客户端提输入信息 示有错误

输入

3. 引导用户

定位错误

输入

1. 应有必填用户通过用户界面17. 输入为空，提交 项判断 输入信息 2. 客户端提

软件功能测试指南 Page 22 of 25

/

示必填项不

能为空 3. 引导用户

定位必填项

4. 所填信息

不能保存到

相应的数据

库表中

1. 客户端提

示错误输入

2. 引导用户

定位错误输用户通过用户界面该输入汉字的输入英文18. 入项 输入信息 字符，提交 3. 所填信息

不能保存到

相应的数据

库表中

1. 客户端提

示错误输入

2. 引导用户

定位错误输用户通过用户界面该输入汉字的输入数19. 入项 输入信息 字，提交 3. 所填信息

不能保存到

相应的数据

库表中

1. 客户端提

示错误输入

2. 引导用户

定位错误输用户通过用户界面该输入英文字符的输入20. 入项 输入信息 汉字，提交 3. 所填信息

不能保存到

相应的数据

库表中

1. 客户端提

示错误输入 用户通过用户界面该输入英文字符的输入21. 2. 引导用户输入信息 数字，提交 定位错误输

入项

软件功能测试指南 Page 23 of 25

/

3. 所填信息

不能保存到

相应的数据

库表中

1. 客户端提

示错误输入

2. 引导用户

定位错误输用户通过用户界面该输入数字的输入汉22. 入项 输入信息 字，提交 3. 所填信息

不能保存到

相应的数据

库表中

1. 客户端提

示错误输入

2. 引导用户

定位错误输用户通过用户界面该输入数字的输入英文23. 入项 输入信息 字符，提交 3. 所填信息

不能保存到

相应的数据

库表中

输入汉字的字节数与输用户通过用户界面24. 入英文字符的字节数相相同 输入信息 同

用户通过用户界面输入汉字的字节数与输25. 相同 输入信息 入数字的字节数相同

11.22:WinRunner

软件功能测试指南 Page 24 of 25

11.33:MAXQ

11.44:CaseDriverTest

11.44:TestComplete

软件功能测试指南 Page 25 of 25

范文三：软件功能测试报告

软件功能测试报告

软件功能测试报告

1.概述

(同时注明软件软本和测试软件名称: 软件版本:

包的cvs版本) 开发经理: 申请单号:

测试人员: 测试日期:

测试内容:

备注:

表1 概述

2.测试环境

用途 硬件环境 软件环境

表2 测试环境

3.问题统计

(说明:该报告为阶段性测试的统计报告，该报表统计的bug数量为:本发布阶段内第一份申请单提交日期为起，直至填写报告这天为止的BUG数量,如果以前版本中有问题延期至本发布阶段来修正，那么该缺陷也需要统计进来;如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的)

3.1 按BUG状态统计(表格后面可以附上柱形图,以示更直观)

BUG状态 BUG数量 备注

未分配(new)

不是缺陷(Not Bug)

第1页 共7页

软件功能测试报告

未修改(open) 已修改(fixed) 不予修改(Won’t Fix) 延期(Deffered)

无法重现 被拒绝

信息不足 (Declined)

重复的 已关闭(Closed) 重开启(Reopen) 合计

表3 按bug状态统计

3.2 按BUG类型统计(表格后面可以附上柱形图,以示更直观)

BUG数量

被拒绝

不 不重

未 未 已 已 无信BUG 是 予 延 新 合重备注 类型 分 修 修 关 法息

缺 修期 开 计 复

配 改 改 闭 重不

陷 改 启 的

现 足

功能

界面

交互

表4 按bug类型统计

3.3 按BUG严重级别统计(表格后面可以附上柱形图,以示更直观)

BUG数量 BUG

备注

严未 未 不 已 不延 被拒绝 已 重 合

第2页 共7页

软件功能测试报告

重 分 修 是 修 予 期 无信关 新 计

重级配 改 缺 改 修法息闭 开

复别 陷 改 重不启

的

现 足

紧

急

严

重

中

等

轻

微

建

议

表5 按bug严重级别统计

3.4 按功能模块统计(表格后面可以附上柱形图,以示更直观)

BUG数量

被拒绝

不 不重 模块 未 未 已 已 无信

备注 是 予 延 新 合重名称 分 修 修 关 法息

缺 修期 开 计 复

配 改 改 闭 重不

陷 改 启 的

现 足

模块

1

模块

2

… …

第3页 共7页

软件功能测试报告

…

表6 按功能模块统计

3.5 按所属人员统计(表格后面可以附上柱形图,以示更直观)

BUG数量

被拒绝

不 不重 开发 未 未 已 已 无信

备注 是 予 延 新 合重

人员 分 修 修 关 法息

缺 修期 开 计 复

配 改 改 闭 重不

陷 改 启 的

现 足

张 三

李 四

…

…

…

表7 按所属人员统计

4.用例统计(可选，对于TD的项目则要填写)

(如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的)

4.1 用例的分布情况(可用图形来表示)

有多少测试用例，测试用例的分布。执行了多少用例，有多少个Bug是由执行用例发现的。

功能模块 用例个数 执行个数 发现Bug数 模块1

模块2

…

…

第4页 共7页

软件功能测试报告

…

…

总计

表8 用例分布情况

4.2 按用例的执行状态统计(可用图形来表示)(如果是功能+验证测试，则需要按测试集和模块两个方面来进行统计)

总执行失败未运行未完成用例通过率(%)

通过用

功能模块 用例数 用例的用例用例数

例数

数 数

模块1 模块2 … …

总计

表9 按用例的执行状态统计

5.测试综述

本轮测试持续将近×××周，到目前为止(如果是功能测试则是指本轮次，如果是功能+验证测试则是指本发布阶段)发现的BUG数据量×××，其中，重新开启:××，未解决:×××，已解决:×××。(如果是功能+验证测试，则还需说明本轮次新发现的bug情况，如:本轮测试新发现的问题有多少个,其中严重的有多少个,)从测试的角度给出该轮测试是否通过，是否需要做回归测试，或验证测试。

6.问题与建议

总结项目测试过程，以及和开发人员交互过程中存在的问题，经验，也可以提出自己的一些改进建议等

第5页 共7页

软件功能测试报告

7.其他

(如果对应的测试申请单中既有功能测试类型，又有验证测试类型，那么只出功能测试报告即可，同时该项必填，需要在此附上本发布阶段的遗留问题清单以及本发布阶段新发现的重大bug清单;遗留问题清单中如果不属本发布阶段测试范围的须在备注中说明)

7.1 遗留问题列表(本发布阶段发现的，以及前发布阶段延期至本阶段来修正的缺陷)

序号 问题详细描述 严重程度 备注 1 如果不是本轮测

试范围的，请说明 2 3 …

表10 遗留问题列表

7.2 重大bug列表(指本阶段新发现的重大BUG清单)

序号 问题详细描述 严重程度 备注 1 如果不是本轮测

试范围的，请说明 2 3 …

表11 重大bug列表

7.3 质量风险[可选]

主要是在本发布阶段针对开发经理要求不测试且最终确实未测试,但是测试人员从质量的角度认为需要测试的功能点做简要说明

序号 风险点描述 备注

第6页 共7页

软件功能测试报告

1 2

第7页 共7页

范文四：软件功能测试报告

软件功能测试报告

软件功能测试报告

软件功能测试报告

1.概述

2.测试环境

表2 测试环境

3.问题统计

(说明:该报告为阶段性测试的统计报告，该报表统计的bug数量为:本发布阶段内第一份申请单提交日期为起，直至填写报告这天为止的BUG数量,如果以前版本中有问题延期至本发布阶段来修正，那么该缺陷也需要统计进来;如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的)

3.1 按BUG状态统计(表格后面可以附上柱形图,以示更直观) 第1页 共7页

软件功能测试报告

表3 按bug状态统计

3.2 按BUG类型统计(表格后面可以附上柱形图,以示更直观)

3.3 按BUG严重级别统计(表格后面可以附上柱形图,以示更直观) 第2页 共7页

软件功能测试报告

表5 按bug严重级别统计

3.4 按功能模块统计(表格后面可以附上柱形图,以示更直观)

第3页 共7页

软件功能测试报告

表6 按功能模块统计

3.5 按所属人员统计(表格后面可以附上柱形图,以示更直观) 4.用例统计(可选，对于TD的项目则要填写)

(如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的)

4.1 用例的分布情况(可用图形来表示)

有多少测试用例，测试用例的分布。执行了多少用例，有多少个Bug是由执行用例发现的。 第4页 共7页

软件功能测试报告

4.2 按用例的执行状态统计(可用图形来表示)(如果是功能+验证测试，则需要按测试集和模块两个方面来进行统计)

5.测试综述

本轮测试持续将近×××周，到目前为止(如果是功能测试则是指本轮次，如果是功能+验证测试则是指本发布阶段)发现的BUG数据量×××，其中，重新开启:××，未解决:×××，已解决:×××。(如果是功能+验证测试，则还需说明本轮次新发现的bug情况，如:本轮测试

新发现的问题有多少个,其中严重的有多少个,)从测试的角度给出该轮测试是否通过，是否需要做回归测试，或验证测试。

6.问题与建议

总结项目测试过程，以及和开发人员交互过程中存在的问题，经验，也可以提出自己的一些改进建议等

第5页 共7页

软件功能测试报告

7.其他

(如果对应的测试申请单中既有功能测试类型，又有验证测试类型，那么只出功能测试报告即可，同时该项必填，需要在此附上本发布阶段的遗留问题清单以及本发布阶段新发现的重大bug清单;遗留问题清单中如果不属本发布阶段测试范围的须在备注中说明)

7.1 遗留问题列表(本发布阶段发现的，以及前发布阶段延期至本阶段来修正的缺陷) 表10 遗留问题列表

7.2 重大bug列表(指本阶段新发现的重大BUG清单) 7.3 质量风险[可选]

主要是在本发布阶段针对开发经理要求不测试且最终确实未测试,但是测试人员从质量的角度认为需要测试的功能点做简要说明

第6页 共7页

软件功能测试报告

第7页 共7页

范文五：软件功能测试报告

文档编号:[文档编号]

[项目名称]

功能测试报告

版本号:[版本号] 受控编号:[受控编号]

编写部门:[编写部门]

编写人:[编写人]

审核人:[审核人] 审核日期:2016年2月6日

批准人:[批准人]

日期:2016年2月6日

目 录

1(引言……………………………………………………………………….. 1

编写目的

背景

定义

参考资料

2(模块测试环境…………………………………………………………….. 1

模块用于进行测试的环境

参于测试的人员

使用的测试方法

3(元素测试结果表………………………………………………………….. 1 4(内联测试结果表………………………………………………………….. 1 5(模块集成测试结果……………………………………………………….. 1

第一次集成测试记录

6(测试中的例外…………………………………………………………….. 1

无法达到的极限

不确定的元素

测试无法涵盖部分

7(其它……………………………………………………………………….. 2

.1.

1(引言

1.1) 编写目的

在此说明编写这份概要设计说明书的目的，指出预期的读者。 1.2) 背景

[系统名称]

[项目提出者、开发者、用户、运行地点]t 1.3) 定义

[术语和缩写说明]

1.4) 参考资料

[本项目计划任务书或合同、上级机关文]

[本项目已发布文档]

[本文引用的其它文档资料(包括各种开发标准)]

2(模块测试环境

2.1) 模块用于进行测试的环境

[各种测试环境的描述、用途及生成此环境的代码] 2.2) 参于测试的人员

[所有参于测试的人员及其在测试工作中的职能] 2.3) 使用的测试方法

[将有测试中使用的测试方法，及各种方法将用于哪些无元素的测试中。]

(元素测试结果表 3

在《功能设计说明书》中归为

下表是本模块内所有元素最后一次的测试情况:

元素 说明 功能目标 测试时间 测试内容 评价 测试人员

4(内联测试结果表

下表是本模块内部分元素内部联接能功测试记录:

参于元素 环境 测试内容 测试日期 评价 测试人员

5(模块集成测试结果

5.1) 第一次集成测试记录

a) 时间，参于人员

[此次测试开始及结束时间]

[参于此次测试的人员列表(姓名及职务)]

b) 测试内容

[此次测试的详细内容]

c) 测试过程记录

[以上各项内容的具体测试方法及相应在的反应]

d) 测试结果

[此次测试的综合情况，需对模块集成作一个整体陈述]

e) 评价

[按期望值为100分给此次测试的结果评分，及此模块是否可交付]

5.2) 同 5.1

6(测试中的例外

6.1) 无法达到的极限

- 1 -

[若存在无法为需进行极限测试的元素模似极限值的情况，在此列出] 6.2) 不确定的元素

[某些元素可能具有不确定性，无法进行测试，在此列出.] 6.3) 测试无法涵盖部分

[因为保密或其它原因，部分代码可能无法测试，若有，在此列出]

7(其它

[以上示能包含的部分]

- 2 -

转载请注明出处范文大全网 » 软件功能测试报告