大学教室管理系统软件工程测试报告.doc

软件测试报告 教室管理系统 小组成员：陈鑫 杨博 石松 梁岑 王文博（执笔） 时间：2009.4.9 软件测试报告 ——大学教室管理系统测试报告 1 引言1.1 编写目的：本测试报告为大学教室管理系统项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员。?1.2 项目背景：为了适应现代社会人们高度强烈的时间观念，大学教室管理系统软件为师生进行正常有序的教学，学习活动带来了极大的方便。该软件是以高级编程语言为实现语言，其功能在系统内部有源代码直接完成。通过操作手册，使用者可以了解本软件的基本工作原理。操作人员只需输入一些简单的汉字、数字，即可达到自己的目标。 1.3 系统简介 系统流程图如下： 学生教师1课程查询2空闲教室查询3大型报告会通知4临时调课课程维护更新管理员大型报告会通知大型报告会信息维护更新教室全部信息课程信息课程查询请求查询报告会请求空闲教室信息空闲教室查询请求报告会信息临时调课信息课程信息课程查询请求临时调课信息临时调课请求空闲教室信息空闲教室查询请求请求报告会信息查询报告会请求 学 生 教师 1 课程查询 2 空闲教室查询 3 大型报告会通知 4 临时调课 课程维护更新 管理员 大型报告会通知 大型报告会信息 维护更新 教室全部信息 课程信息 课程查询请求 查询报告会请求 空闲教室信息 空闲教室查询请求 报告会信息 临时调课信息 课程信息 课程查询请求 临时调课信息 临时调课请求 空闲教室信息 空闲教室查询请求请求 报告会信息 查询报告会请求 1.4 参考资料：《软件工程导论》，张海藩，清华大学出版社。 2 目标及准则2.1 测试目的：测试是为了发现程序中的错误而执行程序的过程，好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案，成功的测试是发现了至今为止尚未发现的错误的测试。 2.2 测试准则:所有的测试都应该改能追溯到用户需求，应该在测试之前就制定出测试计划，把Pareto原理应用到软件测试中，应该从“小规模”测试开始，并逐步进行“大规模”测试，穷举测试是不可能的，为达到最佳的测试效果，应该由独立的第三方从事测试工作。 3 测试过程3.1 测试内容：该系统的所有模块3.2 测试时间：2009.3.263.3 测试环境： CPU：AMD Althion(tm) 64 X2 Dual Core Processor 50000+? 内存：?1GB 硬盘：160GB? 操作系统：Windows xp? 3.4 测试用例设计: 3.4.1单元测试用例编写 (1)规格导出法。根据相关的需求规格描述来设计测试用例，每一个测试用例用来测试一个或者多个规格陈述语句。 (2)边界值分析法。用边缘特殊值测试，程序往往在边缘情况时犯错误，故测试边缘情况比较有效。例如输人数据值的范围是1一16，则可选1,16,14,17等数据作为测试数据c (3)等价类划分法。等价分类法是将输人数据的可能值 分成若干“等价类”，每一类以一个代表性的测试数据进行测 试，这个数据就等价于这一类中的其他数据，该方法的关键在 于如何将输人数据分类。例如输人的数据范围是1一999，则 可以划分气类:xl;l}x999;x}999o (4)错误猜测法。根据以前的测试经验，猜测容易出错点，针对这个点所写的测试用例。 3.4.2 集成测试用例编写 集成测试用例应该包括一个合适的检查点，需要注意以下几个方面:①功能的正确性;②消息的流程是否正确;③来往的消息中的数据项、参数是否正确;④ 消息异常、错误、超时等问题是否能正常处理;⑤各个模块的状态迁移及相关数据结构的正确性;⑥资源的占用和释放情况，运行过程中资源的占用和释放是否正常;⑦全局数据的正确性，如全局变量、全局数组、全局数据表;⑧桩函数参数;⑨函数调用顺序。在写集成测试用例时，从覆盖率来讲可以从以下几 个方面来考虑: (1)模块的消息接口。①每类消息的每个具体消息都应该设计测试用例;②对于消息结构中每一个数据成员的各种合法取值情况都应该设计测试用例;③对于消息结构中每个数据成员的非法取值情况应该设计测试用例;④模拟各种消息丢失的情况;⑤模拟各种消息超时到达的情况;⑥模拟收到各种不期望的消息的情况(如收到的消息超长、超短等)。 (2)模块的功能流程。根据概要设计文档描述中所确定的模块应该完成的功能，每个功能描述都应该设计测试用例验证。需要多个模块以及它们之间的接口共同完成的功能，需要设计测试用例验证。 (3)模块间使用数据表。针对数据的修改操作，如增加、 删除、增加满、删除空、频繁地增加、删除等 (4)桩函数。对于无返回