《软件测试报告[推荐]》由会员分享，可在线阅读，更多相关《软件测试报告[推荐]（6页珍藏版）》请在金锄头文库上搜索。
1、XX 软件测试报告 1 / 6 1 范围 本文档适用于XX软件的单元/集成测试。 1.2 系统概述 1.3 文档概述 本文档用于对XX软件的测试工作阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别， 软件测试的过程描述，软件测试的结果等内容。 2 引用文档 XX 软件需求规格说明 XX 软件设计说明 XX 系统接口协议 3 测试概述 3.1 被测软件的基本概况 使用的编程语言：XXX 汇编语言 程序行数：1590 子程序个数：11 单行注释行数：669 注释率：约为42% 3.1.1. 测试小结 本次测试对XX 软件进行了静态分析和动态测试。测试工作分为两个阶段。第一阶段进行了软
2、件静态分 析， 软件测试人员和开发人员分别对软件V1.00 版本的代码进行走读。在此 基础上软件开发人员对代码走查 中发现的问题进行了修改，做了97 处代码变更并提交了 V1.01 版本进行动态测试。 在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行 考查。 在软件测试中首先根据软件测试的规范进行考核，将书写规范，注 释等基础问题首先解决，其次考核 软件测试中的问题是否存在设计上的逻辑缺陷，如果存在 设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。软件开发人员在以上基础上对软 件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改
3、善结果。 2 / 6 软件代码1.00与1.01版变更明细表 : 编号1.00版行号1.01版行号更改说明 1 19 22 注释变更 226 29 注释变更 32932注释变更 49598注释变更 5108行后113?116增加新变量 6 171、172 180、181 命令字大小写变更 7以下略 从上表可以看出，注释变更一共有15处，主要排除了对原程序的理解错误问题；根据 程序的书写规范要求，一行多条语句改为一行一条语句的更改一共有42处；命令字大小写 变更一共有7处；在代码走查中对冗余和无用的代码作了更改，将这些代码注释掉，此类更 改一共有14处。上述4类更改一共有78处，这些更改对程序本
4、身的功能没有任何影响，但 从软件规范的角度 来看提高了程序的可读性和规范性。 其余19处变更为代码变更，主要是在软件测试中发现原程序的可靠性不足，在不改变原程序功能的基础上 相应的增加了新变量、新语句、新程序以提高整个程序的可靠性。 在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修 改，提交了V1.02版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段 发现的软件问题进行了修改，消除了原有的软件问题并且确认没有弓I入新的软件问题。认定 V1.02版为可以发行的软件版本。 3.1.1.1 静态分析小结 静态测试采用人工代码走查的方式进行。参加代码走查的软
5、件开发人员有：（略）；参加 代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。静态分析过程中 共进行了四次会议审查。静态测试阶段的主要工作内容是： 根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图（见附件1）； 对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析；对软件汇编源代 码进行编程规范化分析。 通过静态测试查找出软件的缺陷18个，其中 轻微的缺陷4个，占所有缺陷的22.2 % 中等的缺陷11个，占所有缺陷的61.1 % 严重的缺陷：3个，占所有缺陷的16.7 % 上述软件缺陷见附件软件问题报告单 3 / 6 3.1.1.2 动态测试小结
6、 动态测试使用的测试工具为XXX 软件集成开发环境。总共的测试用例数：143 个。全部由测试人员人工 设计。 其中单元测试用例138 个，集成测试用例5 个。 发现的软件缺陷有2 个，都是在单元测试过程中发现的。集成测试阶段未发现新的软件缺陷。在发现的软 件缺陷中： 中等的缺陷1 个，占所有缺陷的50 严重的缺陷1 个，占所有缺陷的50 上述软件缺陷见附件软件问题报告单 动态测试中代码覆盖率： 代码行覆盖率100% 分支覆盖率100% 程序单元调用覆盖率100 3.1.1.3 回归测试小结 对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测 试。本报告中
7、的数据是回归测试后的测试数据。 3.1.1.4 测试分析 下面将对此次软件测试中的所有缺陷以及改进设计进行分析。 1静态测试中的缺陷分析： 1) 4 个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在 程序设计完成 后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。修改 后程序的效率得到提高。 2) 11 个中等缺陷属于注释变更，在原程序代码的注释中存在注释不准确的问题，会影响程序 员对程序的理解，修改后的程序提高了程序的可读性。 3) 重点分析3 个严重缺陷：第一个严重缺陷属于XX 号的无效判别和相应的处理问题，程 序对XX 号进行 无效判别时，判别界限并
8、不完全，在本跟踪程序中XX 号的有效数为01-10(用4 位 表示)，而判别无效时只判了为00 的情况，没有判别大于10 的情况。而且在为00 时也没有作相应的 处理， 修改后的程序对设计进行了改进，详见改进设计分析3。 第二个严重缺陷属于程序设计中读取地址错误问题，经分析在调试中读取的数据是正确的，但是 读取的地址与设计初衷不相符，修改后问题得到了解决，详见改进设计分析1。 第三个严重错误是近区/远区子程序判断与进入条件反了，经分析对程序的影响不大，但与设计 4 / 6 初衷不一致，修改后问题得到了解决，详见改进设计5。 2 动态测试中的缺陷分析： 1） 中等缺陷1 个，在程序的注释中出现错
9、误，将近区注释为远区，修改后问题得到了解决，提高 了程序的可读性。 2） 严重缺陷1 个，在XX 号无效的判别中，本应判断大于10，但误设计为0， 修改后经回归 测试问题得到了解决。 3 改进的设计分析： （因和产品相关，略） 3.1.2 测试记录 a 测试时间：2005 年8 月5 日至2005 年9 月17 日。 b 地点：（略）。 c硬件配置：P4CPU/2.0G 内存256M硬盘1G d 软件配置：Wondows 98， e 被测软件版本号：V1.0，V1.01 ，V1.02 f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。 4 测试结果 在两个阶段测试过程中共
10、发现软件缺陷20 个，经软件开发人员确认的缺陷为20 个，经 过改正的代码消除 了所有以确认的软件缺陷并通过了回归测试。因测试条件所限，未能进行软件的确认测试和系统测试。 5 评估和建议 5.1 软件评估 5.1.1 软件编码规范化评估 经过回归测试，未残留的软件编码规范性缺陷。软件代码文本注释率约为42%，代码 注释充分，有利与代码的理解和维护。 5.1.2 软件动态测试评估 被测软件单元的总数：11 个 使用的测试用例个数：143 个 达到软件测试出口准则的软件单元数为11 个，通过率100 通过单元和集 5 / 6 成测试得知：软件代码逻辑清晰、结构合理、程序单元间接口关系一致，运行稳定。 5.2 改进建议 a. 建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。 b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。特别是应该将系统中的 硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。 c. 尽早开展软件测试工作。在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试 必要的支撑。 d. 建议结合系统联试，开展软件的确认和系统测试。 附件： 软件问题报告单（略） 软件更改通知单（略）软件测试记录（略） 6 / 6
