5.饭卡管理系统测试报告（Beta）.doc

1、饭卡管理系统测试文档1. 引言1.1 编写目的本文档为文件检索模块的系统测试活动提供范围、方法、资源、进度、功能方面和指定目录下的文件列表以及文件相对路径的指导。1.2 测试策略 功能测试：主要实现文件的检索功能及增、删、改、查。性能测试: 主要是系统的适应性（在操作方式、运行环境与其他软件的接口发生变化时，应具备的适应能力）可靠性、稳定性测试：在一定的条件下，系统能承受住压力，不至于到崩溃的边缘，检索系统一定要具有可靠性、稳定性。兼容性：检索系统要在不同的硬件中与系统兼容及支持。恢复测试: 恢复测试主要采取的是人工测试的方法，主要是系统不能正常的工作，进而检验系统的恢复能力。安全测试: 如果

2、用户在系统中设置密码，系统是否支持和可靠。强度测试: 要测试系统在检索中如果溢出系统是否会提示。面向用户支持方面的测试：界面是否具有规范性、界面是否美观是否具有人性化、易操作性。1.3 范围本系统测试计划是整个软件开发项目中的一部分，起始于详细设计阶段，直到系统测试阶段结束后终止。该计划主要测试与饭卡管理系统测试有关的功能。2. 测试概要3.系统测试3.1 单元测试单元测试结果如表所示。名称函数功能是否成功是否更正entry()提供管理员和学生用户登录服务两种环境，限制用户对系统的使用权限是/search()完成对系统（数据库）的查找是/pay()完成消费部分。对输入和消费额，进行合法性验证。

3、是/deposit()完成存款部分。对输入和存款额，进行合法性验证。是/表1被测单元3.2 集成测试集成测试结果如表所示。功能函数功能说明是否成功是否更正新建完成对学生申请创建饭卡的请求，激活卡，系统分配卡ID。是/存款/消费 完成用户持卡进行存款/消费的功能是/查询/修改完成对数据库（学生信息，饭卡信息）的查询，修改是/挂失/解锁完成对饭卡的挂失锁定与解锁状态的转换是/注销完成对饭卡的注销是/表2集成测试4. 静态测试1代码会审代码会审时有一组人通过阅读讨论和正义对程序进行静态分析的过程。会审小组由组长、23名设计人员、测试人员及程序员组成。会前要先将程序清单分发给与会者，让他们熟悉要审查的

4、材料。开会时程序作者逐句朗读和讲解程序，其他人则集中精力，捕捉程序中在结构、功能与编码风格等方面可能存在的问题，并展开热烈的讨论甚至争议，以揭示错误的关键所在。2走查与会审相似，走查也是一小组的方式进行的。每小组35人，每次持续12小时。被审程序也要提前发给参加者，并要求他们在会前熟悉这些材料。与会审的差别，走查要求与会者扮演“计算机”的角色，用人工的方法来运行被审程序，也可以仿照走查对程序进行人工运行。早期因程序规模小，常采用这种方法。4. 动态方法1 测试用例见下图 12黑盒测试也称功能测试或者数据驱动测试。她实在抑制产品所具有的功能的基础上，通过测试来检测每个功能是否都能正常运行并达到预

5、期结果。（1） 等价分类法（2） 边界值分析法3 白盒测试也称结构测试或逻辑驱动测试，它是已知产品内部工作过程，通过测试来检测产片内部动作是否按照规格说明书的规定正常运行。按照程序的内部结构测试程序，检测程序中的每条通路是否都能甘于定要求正确运行。（1） 语句覆盖（2） 判定覆盖（3） 条件覆盖（4） 条件组合覆盖（5） 点覆盖（6） 边覆盖（7） 路径覆盖 数据图 流程图 黑盒测试策略等价分类法有效等价类无效等价类输入卡号:5卡号正确 卡没有被锁 并且是定价6卡号正确 卡没有被锁 并且是正常消费 并且消费回馈正确1 输入为空2卡号错误3卡被锁4消费不正常黑盒测试用例 图 2-1序号测试内容测

6、试数据希望结果1空输入提示空输入错误2卡号错误卡号12提示卡号错误3卡被锁卡号1提示卡被锁4消费不正常卡号2提示消费不正常5定价卡号2定价 选定提示正确消费6正常消费卡号2定价 不选提示正确消费百合测试用例 图 3-7序号测试数据测试节点测试边1空1,7,13agmu2卡号121,3,9,13abiou3卡号11,3,4,10,13abdjpu4卡号21,3,4,5,6,12,14,6,12,13abdefjrtjsu6卡号2定价 不选5卡号2定价 选定1,3,4,5,11,13abdekqu4. 测试方法Q 保证所有的分支被测试到；Q 对可能出现的异常使用错误猜测方法；Q 某函数的缺陷被修正

7、后，必须回归与该函数相关的所有单元测试用例。5. 测试通过/失败标准测试通过的标准表述如下：Q 所有的单元测试用例都被执行过；Q 所有发现的缺陷都被修正并回归测试过；Q 所有被测对象的语句覆盖率达到100%，或能明确给出不需要达到的理由；Q 所有被测对象的DDP覆盖达到100%，或能明确给出不需要达到的理由；测试失败的标准表述如下：Q 发现有重大结构设计问题，其修改会导致20%以上的函数接口、功能、数量的变化，进一步测试相关函数已经无意义；Q 发现关键功能未被设计，该功能的设计会导致20%以上的函数接口、功能、数量的变化，进一步测试相关函数已经无意义；6. 测试挂起/恢复的条件测试挂起的条件有：Q 当某个函数在单元测试执行过程中发现有阻塞用例的时候，该函数的单元测试将被挂起；Q 当有20%以上的被测函数都遇到有阻塞用例的时候，所有函数的单元测试执行将被挂起；Q 当出现有新增需求的时候，与该需求相关模块的所有函数的单元测试将被挂起；Q 当开发人员提出要进行设计变更的时候，相关函数的单元测试将被挂起。测试恢复的条件有：Q 测试被挂起的条件已经被解决；Q 需要恢复测试的对象达到单元测试入口条件，在这里，要求这些被测对象已经通过代码走读，PC-LINT检查。8. 环境需求8.1 硬件需求一台目前标准的办公PC。 8.2 测试工具 人工对其进行测试。