(XX V1.0)
测试总结报告
| 文件编号 | 文件版本 | V1.0 | ||
| 编写单位 | ||||
| 编 写 人 | 编写日期 | |||
| 审 核 人 | 审核日期 | |||
| 批 准 人 | 批准日期 | |||
| 版本 | 修订人 | 修订日期 | 修订内容 |
1.1 编写目的
XXX系统测试总结报告编写的目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合客户的需求。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。
1.2 系统简介
“XXX系统” 旨在采用先进的软件技术、数据库技术。。。系统功能包括。。。本系统致力于通过计算机技术和XXX业务的结合，充分发挥信息化优势，提高业务人员的办公效率和业务质量，便于。。，以快速把握。。。，提高对。。的科学管理水平和信息化水平。
1.2.1系统架构
图 1系统架构
1.2.2技术架构
图 2技术架构
1.2.3功能列表
| 功能类别 | 子功能 | 描述 |
| 术语、缩略语 | 解 释 |
| XXX | XXX系统（） |
《XXX系统软件需求规格说明书》
《XXX系统软件高层设计说明书》
《XXX系统测试用例说明书》
2测试概要
2.1 测试用例设计
测试用例广义地可以分为两类：
| 黑盒测试 | 白盒测试 | 其他技术 |
| 使用单元接口和功能描述，不需了解被测单元的内部结构 | 使用被测单元内部如何工作的信息 |
采用白盒测试的目的主要是:
1.保证一个模块中的所有路径至少被执行一次；
2.对所有的逻辑值均需要测试真、假两个分支；
3.在上下边界及可操作范围内运行所有循环；
4.检查内部数据结构以确保其有效性。
黑盒测试用例设计：使用详细设计导出测试用例。
采用黑盒测试的目的主要是：
1.检查功能是否实现或遗漏；
2.检查人机交互是否错误；
3.数据结构或外部数据库访问错误；
4.性能等其它特性要求是否满足；
5.初始化盒终止错误。
2.2 测试环境与配置
2.2.1服务器端
| 硬件 | 配置 | |
| 硬件环境 | CPU | Pentium 3GHz |
| 内存 | 4G | |
| 硬盘 | 40G | |
| 软件环境 | 简体中文Windows桌面操作系统 Oracle Database 10g DB Release2或更高版本 | |
| 硬件 | 配置 | |
| 硬件环境 | CPU | Pentium 2GHz |
| 内存 | 1G | |
| 硬盘 | 20G | |
| 软件环境 | 简体中文Windows桌面操作系统 .NET FRAMEWORK3.5或更高版本 Oracle Database 10g Client Release2或更高版本 XXX系统V1.0 | |
XXX系统测试主要用到了以下几种测试方法：等价类、边界值、因果图、错误猜测等，用到最多的是等价类和边界值，错误猜测的方法。
所谓等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。
例如：本系统中测试用户名不存在，系统应该给出什么样的提示时，就可以将所有用户名分为两类，一类是已经注册的用户，另一类是没有注册的用户，前者为有效等价类，后者为无效的等价类。
所谓边界值法是指相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。基于边界的方法是根据定义域来实现的，最终演变成边界值分析、健壮性测试、最坏情况测试和健壮最坏情况测试四种技术。
例如：本系统中，对经纬度输入范围进行测试，由于经度的范围是（-180，+180），所以在选择测试数据时，我们选择（-180.000001，-180.000000，-179.999999,-90，0,90,179.999999,180.000000,180.00001），这样就能测试出系统对经纬度的约束是否准确。
因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
3测试结果及缺陷分析
3.1 测试执行情况与记录
3.1.1测试组织
测试组成：
图 3测试人员结构
测试人员的工作分配：
| 编号 | 测试内容 | 责任人 |
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 |
本次测试中为了使需求覆盖率达到100％，现在对以下功能点进行了测试。希望对需求规格说明书中的各个功能点尽量全部测试，最大限度的找出系统错误，为完善程序提供合理的建议。
| 功能编号 | 测试点描述 | 是否 测试 | 重要等级 | [Y][P][N][N/A] |
| 1 | 测试系统能否正常将规范格式文件中的数据导入到数据库。 | 是 | 重要 | P |
| 2 | 测试系统能否正常通过手动填写和选择各项目录入数据 | 是 | 重要 | P |
| 3 | 测试系统能否正常将所选文件夹的中的规范格式文件的数据批量导入数据库。 | 是 | 重要 | P |
| 4 | 是 | 重要 | P | |
| 5 | 是 | 重要 | Y | |
| 6 | 是 | 一般 | Y | |
| 7 | 是 | 重要 | P |
3.2.1测试覆盖
功能
| （或编号） | 用例 个数 | 执行 总数 | 未执 行数 | 未/漏测分析和原因 |
| 1 | 5 | 5 | 0 | |
| 2 | 5 | 5 | 0 | |
| 3 | 5 | 5 | 0 | |
| 4 | 5 | 5 | 0 | |
| 5 | 3 | 3 | 0 | |
| 6 | 1 | 1 | 0 | |
| 7 | 10 | 10 | 0 | |
| 8 | 5 | 5 | 0 | |
| 9 | 5 | 5 | 0 | |
| 10 | 8 | 8 | 0 | |
| 11 | 3 | 3 | 0 | |
| 12 | 11 | 11 | 0 | |
| 13 | 7 | 7 | 0 | |
| 14 | 7 | 7 | 0 | |
| 15 | 8 | 8 | 0 | |
| 16 | 14 | 14 | 0 | |
| 17 | 2 | 2 | 0 | |
| 18 | 10 | 10 | 0 | |
| 19 | 5 | 5 | 0 |
| 20 | 1 | 1 | 0 | |
| 21 | 7 | 7 | 0 | |
| 22 | 13 | 13 | 0 | |
| 23 | 11 | 11 | 0 | |
| 24 | 3 | 3 | 0 | |
| 25 | 10 | 10 | 0 | |
| 26 | 3 | 3 | 0 | |
| 27 | 1 | 1 | 0 | |
| 28 | 3 | 3 | 0 | |
| 29 | 4 | 4 | 0 | |
| 30 | 10 | 10 | 0 | |
| 31 | 7 | 7 | 0 | |
| 32 | 7 | 7 | 0 | |
| 33 | 6 | 6 | 0 | |
| 34 | 9 | 9 | 0 | |
| 合计 | 214 | 214 | 0 |
3.3 缺陷统计与分析
3.3.1缺陷汇总
Bug等级定义如下表所述
| 等级 | 描述 | 说明 |
| 严重 | 发现可重复出现的致命问题 | ——导致系统崩溃； ——导致程序模块丢失； ——主业务流程出现断点； ——内存泄漏； ——导致死机 |
| 一般 | 发现可重复出现的严重问题 | ——被测功能不能正确实现； ——软件错误导致数据丢失； ——被测数据处理错误； ——用户需求未实现。 |
| 微小 | 一般性的错误或功能实现有不完美处 | ——操作界面错误； ——打印内容、格式错误； ——简单的输入未放在前台进行控制； ——删除操作未给出提示。 ——界面不规范； ——辅助说明描述不清楚； ——输入输出不规范； ——长操作未给用户提示； ——提示窗口文字未采用行业术语。 |
| Bug级别 | 严重 | 一般 | 微小 | 无效 |
| Bug数目 | 3 | 6 | 27 | 12 |
图 4各类Bug数目
各类bug所占比例如下饼状图所示
图 5各类Bug比例
3.3.2缺陷引入原因分析
测试过程中发现的缺陷主要有以下几个方面：
1．需求理解不明确
开发人员根据需求进行设计时，没有考虑相关功能的关联性， 以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。
2．功能性错误
功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。主要是统计分析出图时数据因编码错误出现处理异常，导致显示错误统计数据。
3．界面设计和需求不一致
界面设计没有根据需求进行，输入，输出字段文字错误，用户无法理解字段含义。界面设计没有完成需求规定的输入验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。
4．界面设计易用性缺陷
界面设计不够友好，系统中很多界面的输入字段无明确的输入提示，用户无法快速理解何种输入是正确的，但是用户输入错误后，系统提示出错，增加用户负担。
提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确，引起用户误解。
提示信息一致性，用户在不同界面执行相同的操作，提示信息不同。
5．开发人员疏忽引起的缺陷
因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系统需要进行输入控制的地方没有进行相应的控制。
4测试结论
| 测试类别 | 缺陷总数 | 遗留问题数目 | 用例总数 | 测试功能点数 | 结论 |
| 功能测试 | 48 | 0 | 214 | 34 | 通过 |
| 安装测试 | 0 | 0 | 8 | / | 通过 |
资源消耗：
| 测试时间 | |
| 测试人力 | 6人×6天+1人×10天=46人天 |
| 硬件 | 服务端PC 1台 客户端PC6台 |
| 用例质量 | 缺陷总数/测试用例总数=48/214=22.43％ |
| 缺陷密度 | 缺陷总数/功能点数=48/34=1.41 |
XXX系统完整实现了需求规格说明书中的需求，主要分为。。等功能模块。
5.2 缺陷和
XXX系统中的短信发送功能需要硬件支持，基本功能按照需求完成，但在公司本部没有相应硬件支持导致无法进行详细测试。
5.3 建议
下面根据此次测试，提出下面几条建议：
1．开发人员要严格的按照需求规格说明书进行系统开发。
2．开发与测试同时进行，这样可以尽早发现项目的问题，提高整个系统的开发的效率。
3．开发人员要和测试人员分开，避免定向思维，更准确快速的找到系统缺陷。下载本文
