5.饭卡管理系统测试报告(Beta)

饭卡管理系统测试文档

1. 引言

1.1 编写目的

本文档为文件检索模块的系统测试活动提供范围、方法、资源、进度、功能方面和指定目录下的文件列表以及文件相对路径的指导。

1.2 测试策略

功能测试：主要实现文件的检索功能及增、删、改、查。

性能测试: 主要是系统的适应性（在操作方式、运行环境与其他软件的接

口发生变化时，应具备的适应能力）

可靠性、稳定性测试：在一定的条件下，系统能承受住压力，不至于到崩

溃的边缘，检索系统一定要具有可靠性、稳定性。

兼容性：检索系统要在不同的硬件中与系统兼容及支持。

恢复测试: 恢复测试主要采取的是人工测试的方法，主要是系统不能正常

的工作，进而检验系统的恢复能力。

安全测试: 如果用户在系统中设置密码，系统是否支持和可靠。 强度测试: 要测试系统在检索中如果溢出系统是否会提示。

面向用户支持方面的测试：界面是否具有规范性、界面是否美观是否具有人性化、易操作性。

1.3 范围

本系统测试计划是整个软件开发项目中的一部分，起始于详细设计阶段，直到系统测试阶段结束后终止。该计划主要测试与饭卡管理系统测试有关的功能。

2. 测试概要

3.系统测试

3.1 单元测试

单元测试结果如表所示。

名称 entry() search() 函数功能 提供管理员和学生用户登录服务两种环境，限制用户对系统的使用权限 完成对系统（数据库）的查找 是否成功 是 是 是否更正 / /

pay() deposit() 3.2 集成测试

完成消费部分。对输入和消费额，进行合法性验证。 完成存款部分。对输入和存款额，进行合法性验证。 表1被测单元 是 是 / / 集成测试结果如表所示。

功能 新建 存款/消费 查询/修改 挂失/解锁 注销

函数功能说明 完成对学生申请创建饭卡的请求，激活卡，系统分配卡ID。 完成用户持卡进行存款/消费的功能 完成对数据库（学生信息，饭卡信息）的查询，修改 完成对饭卡的挂失锁定与解锁状态的转换 完成对饭卡的注销 表2集成测试

是否成功 是 是 是 是 是 是否更正 / / / / / 4. 静态测试

1代码会审

代码会审时有一组人通过阅读讨论和正义对程序进行静态分析的过程。会审小组由组长、2~3名设计人员、测试人员及程序员组成。会前要先将程序清单分发给与会者，让他们熟悉要审查的材料。开会时程序作者逐句朗读和讲解程序，其他人则集中精力，捕捉程序中在结构、功能与编码风格等方面可能存在的问题，并展开热烈的讨论甚至争议，以揭示错误的关键所在。

2走查

与会审相似，走查也是一小组的方式进行的。每小组3~5人，每次持续1~2小时。被审程序也要提前发给参加者，并要求他们在会前熟悉这些材料。

与会审的差别，走查要求与会者扮演“计算机”的角色，用人工的方法来运行被审程序，也可以仿照走查对程序进行人工运行。早期因程序规模小，常采用这种方法。

4. 动态方法

1 测试用例 见下图 1 2黑盒测试

也称功能测试或者数据驱动测试。她实在抑制产品所具有的功能的基础上，通过测试来检测每个功能是否都能正常运行并达到预期结果。 （1） 等价分类法 （2） 边界值分析法 3 白盒测试

也称结构测试或逻辑驱动测试，它是已知产品内部工作过程，通过测试来检测产片内部动作是否按照规格说明书的规定正常运行。按照程序的内部结构测试程序，检测程序中的每条通路是否都能甘于定要求正确运行。

（1） （2） （3） （4） （5） （6） （7） 语句覆盖 判定覆盖 条件覆盖 条件组合覆盖 点覆盖 边覆盖 路径覆盖

数据图 流程图

黑盒测试策略 等价分类法 有效等价类 无效等价类 输入卡号: 1 输入为空 5卡号正确 卡没有被锁 并且是定价 2卡号错误 6卡号正确 卡没有被锁 并且是正常消费 并且消费3卡被锁 回馈正确 4消费不正常 黑盒测试用例 ?图 2-1 序测试内容 测试数据 希望结果 号 1 空输入 提示空输入错误 2 卡号错误 卡号12 提示卡号错误 3 卡被锁 卡号1 提示卡被锁 4 消费不正常 卡号2 提示消费不正常 5 卡号2定价 选定价 提示正确消费 定

6 正常消费 序号 1 2 3 4 6 5 4. 测试方法

卡号2定价 不提示正确消费 选 百合测试用例 ?图 3-7 测试数据 测试节点 测试边 1,7,13 agmu 空 1,3,9,13 abiou 卡号12 1,3,4,10,13 abdjpu 卡号1 1,3,4,5,6,12,14,6,12,13 abdefjrtjsu 卡号2 卡号2定价 不选 卡号2定价 选定 1,3,4,5,11,13 abdekqu ? 保证所有的分支被测试到；

? 对可能出现的异常使用错误猜测方法；

? 某函数的缺陷被修正后，必须回归与该函数相关的所有单元测试用例。

5. 测试通过/失败标准

测试通过的标准表述如下：

? 所有的单元测试用例都被执行过； ? 所有发现的缺陷都被修正并回归测试过；

? 所有被测对象的语句覆盖率达到100%，或能明确给出不需要达到的理由； ? 所有被测对象的DDP覆盖达到100%，或能明确给出不需要达到的理由； 测试失败的标准表述如下：

? 发现有重大结构设计问题，其修改会导致20%以上的函数接口、功能、数量

的变化，进一步测试相关函数已经无意义；

? 发现关键功能未被设计，该功能的设计会导致20%以上的函数接口、功能、

数量的变化，进一步测试相关函数已经无意义；

6. 测试挂起/恢复的条件

测试挂起的条件有：

? 当某个函数在单元测试执行过程中发现有阻塞用例的时候，该函数的单元测

试将被挂起；

? 当有20%以上的被测函数都遇到有阻塞用例的时候，所有函数的单元测试执

行将被挂起；

? 当出现有新增需求的时候，与该需求相关模块的所有函数的单元测试将被挂

起；

? 当开发人员提出要进行设计变更的时候，相关函数的单元测试将被挂起。 测试恢复的条件有：

? 测试被挂起的条件已经被解决；

? 需要恢复测试的对象达到单元测试入口条件，在这里，要求这些被测对象已

经通过代码走读，PC-LINT检查。

8. 环境需求

8.1 硬件需求

一台目前标准的办公PC。

8.2 测试工具

人工对其进行测试。

本文来源：https://www.bwwdw.com/article/p09o.html