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

            技术文件名称：选课系统单元测试报告

            技术文件编号：00008-5

            版        本：V 1.0

                             拟  制  

                             审  核  

                             会  签  

修改记录

1    编写目的    1

2    执行依据    1

3    术语、定义和缩略语    1

3.1    术语、定义    1

3.2    缩略语    1

4    测试记录及分析    1

4.1    测试记录及结果    1

4.1.1    被测单元1测试过程记录及结果分析    1

4.1.2    被测单元2测试过程记录及结果分析    2

4.2    测试补充说明（可选）    3

5    测试结果统计    3

6    经验、教训和建议    4

7    附件    4

8    参考资料    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测试过程记录及结果分析

4.2测试补充说明（可选）

<要求：说明实际测试与测试方案有差异的地方，并对增加的测试内容进行补充说明。说明测试过程中的条件（如：其它功能点没有完成等），指出由于这些条件使哪些测试项没有进行。>

5测试结果统计

<要求： 一般用以下表格描述测试用例、工时数、异常发现和处理情况，其中的字段可根据实际情况进行设计和裁剪。>

说明：

1、遗留的异常个数一般要求为0。如果不为0，需要逐一说明原因。

2、实际执行的用例总数、工时数可以反映测试执行工作量。与项目计划中的工时数相比，可以得到工作量偏差。

3、发现的异常个数与被测代码规模数相比得到测试发现的缺陷密度，它可以反映单元测试的绩效。一般缺陷密度应在某一合理范围之内。太高则表明被测代码太粗糙，太低则表明测试用例有效性不高或用例数太少，测试投入不够。

4、测试代码规模和实际执行的测试用例总数分别与被测代码规模相比可以反映测试被测代码的可测试性和方案设计的好坏。测试架构设计得好，则单位被测代码执行的用例数多，测试代码少。

5、覆盖率统计的情况由于与使用的测试工具有关，所以由附件中的工具生成的测试报告提供，这里不提供。

在测试中发现的异常列表如下：

6经验、教训和建议

通过此次学生成绩管理系统的设计，使我对C++程序设计有了深一步的了解，对系统设计及开发有了比较全面的思路。首先，通过对系统进行需求分析，确定各个功能函数；然后一个个具体地对他们进行编程，并且仔细检查看是否有错；在完成这一步之后才开始构造主函数，通过主函数把各个功能函数联系起来，编译修改错误和不足之处

在实际编程过程中会遇到很多不同的错误，有时候是一些很明显很细节的语法错误，这些可以通过编译来查找错误的所在，然而那些并不明显难以查找的隐性错误却真让人头痛，没有办法只好利用断点调试来一步步检查代码中的错误，这样为了找一个错误花费了大量的时间，但是找出错误之后的感觉却是非常“爽”的。同时我翻阅了大量的书籍，尽管大部分书都只是翻了一部分页码而已，却给了我一个非常有价值的经验。

总之，此次系统设计给我们提供了一个既动手又动脑、自学、实践的机会，使我们养成了勤翻阅各种相关资料的习惯，将书本上的理论知识和实际有机地结合起来，锻炼了实际分析问题和解决问题的能力，提高了适应实际、实践编程的能力，为今后的学习和实践打下了良好的基础。

7附件

附件1：工具生成的测试报告。

<要求： 附上工具自动生成的测试报告，不允许手工修改。>

附件2：用于测试的测试脚本或（和）工程文件

<要求：由于这些文件一般都要求上CC，所以这里只需列出这些文件在CC上的路径和文件名>

8参考资料

<要求： 列出相关的资料，如《选课系统模块测试方案》、《选课系统模块详细设计说明》等。>