软件工程 选课系统单元测试报告.doc

.技 术 文 件 技术文件名称：选课系统单元测试报告 技术文件编号：00008-5 版 本：V 1.0 拟 制 审 核 会 签 修改记录文件编号版本号拟制人/修改人拟制/修改日期更改理由主要更改内容（写要点即可）00008-5V 1.02012.4.4无无00008-5V 1.02012.4.11无无00008-5V 1.02012.4.18无无注：文件第一次拟制时，“更改理由”、“主要更改内容”栏写“无”。精选范本目 次1编写目的12执行依据13术语、定义和缩略语13.1术语、定义13.2缩略语14测试记录及分析14.1测试记录及结果14.1.1被测单元1测试过程记录及结果分析14.1.2被测单元2测试过程记录及结果分析24.2测试补充说明（可选）35测试结果统计36经验、教训和建议47附件48参考资料4精选范本1 编写目的编写本功能点单元测试报告的目的在于记录学生成绩管理系统选课系统模块的单元测试情况，包括单元测试用例记录和单元测试执行记录。2 执行依据测试过程所遵循的规程为7.5，7.6，7.7节。所依照的方案为。3 术语、定义和缩略语3.1 术语、定义无3.2 缩略语本文件应用了以下缩略语：无4 测试记录及分析4.1 测试记录及结果4.1.1 被测单元1测试过程记录及结果分析4.1.1.1 测试用例1测试过程记录及结果分析测试用例编号00008-5测试中发现的问题记录数据库连接出错测试结果（结论）测试结果已通过测试结果分析无4.2 测试补充说明（可选）5 测试结果统计实际执行的测试用例总数实际执行的总工时数发现的异常个数遗留的异常个数被测代码规模（行）测试代码规模(行)数目51210500500表格 51 测试结果统计说明：1、 遗留的异常个数一般要求为0。如果不为0，需要逐一说明原因。2、 实际执行的用例总数、工时数可以反映测试执行工作量。与项目计划中的工时数相比，可以得到工作量偏差。3、 发现的异常个数与被测代码规模数相比得到测试发现的缺陷密度，它可以反映单元测试的绩效。一般缺陷密度应在某一合理范围之内。太高则表明被测代码太粗糙，太低则表明测试用例有效性不高或用例数太少，测试投入不够。4、 测试代码规模和实际执行的测试用例总数分别与被测代码规模相比可以反映测试被测代码的可测试性和方案设计的好坏。测试架构设计得好，则单位被测代码执行的用例数多，测试代码少。5、 覆盖率统计的情况由于与使用的测试工具有关，所以由附件中的工具生成的测试报告提供，这里不提供。在测试中发现的异常列表如下：出现异常时执行的测试用例编号严重程度故障描述故障原因00007一般进不去代码出错表格 52 测试中发现的异常6 经验、教训和建议通过此次学生成绩管理系统的设计，使我对C+程序设计有了深一步的了解，对系统设计及开发有了比较全面的思路。首先，通过对系统进行需求分析，确定各个功能函数；然后一个个具体地对他们进行编程，并且仔细检查看是否有错；在完成这一步之后才开始构造主函数，通过主函数把各个功能函数联系起来，编译修改错误和不足之处在实际编程过程中会遇到很多不同的错误，有时候是一些很明显很细节的语法错误，这些可以通过编译来查找错误的所在，然而那些并不明显难以查找的隐性错误却真让人头痛，没有办法只好利用断点调试来一步步检查代码中的错误，这样为了找一个错误花费了大量的时间，但是找出错误之后的感觉却是非常“爽”的。同时我翻阅了大量的书籍，尽管大部分书都只是翻了一部分页码而已，却给了我一个非常有价值的经验。总之，此次系统设计给我们提供了一个既动手又动脑、自学、独立实践的机会，使我们养成了勤翻阅各种相关资料的习惯，将书本上的理论知识和实际有机地结合起来，锻炼了实际分析问题和解决问题的能力，提高