标签:2.0 主键 测试结果 其他属性 需要 一个 提交 head 数据
本阶段项目的测试主要由平时开发过程中的单元测试和本开发阶段末期的集成测试组成。
时间安排上主要在项目的后期才开始对系统进行标准化的测试,平时在编码阶段所进行的一些测试由于缺乏足够的文档支持所以作用有限,但它们还是花费了项目组一定的工作量的。
测试主要由各个成员先各自粗略完成一遍,以保证系统在一般情况下可以正常运行不会产生恶性漏洞,然后再在项目后期由单个成员进行有文档有规范的测试,以保证系统的可用性。
测试工具主要包括了windows端的各类主流浏览器,如Google Chrome 62.0.3202.94,QQ浏览器9.6.2等。
1.用户登录测试用例:
主要测试用户登陆界面能否正常处理用户输入的登陆信息和跳转对应页面。
测试用例ID | 场景 | 测试步骤 | 预期结果 | 备注 |
---|---|---|---|---|
LOG1 | 登陆页面显示 | 输入地址进入登陆界面 | 界面显示符合预期,无多余或缺少个别要素 | |
LOG2 | 用户名输入 | 输入合法用户名并显示输入字符 | 用户名正常显示 | |
LOG3 | 密码输入 | 输入密码,输入字符由*字符代替显示 | 密码显示为*字符串 | |
LOG4 | 用户登陆-用户名及密码校验 | 输入已存在的用户名及密码后,单击登陆按钮 | 系统登陆成功,跳转相应用户的管理界面 | 输入存在的用户及密码 |
LOG5 | 用户登陆-密码校验 | 输入合法用户名,不输入密码,单击登陆按钮 | 系统提示登陆失败 | |
LOG6 | 用户登录-密码正确性 | 输入合法用户名,输入错误密码,单击登陆按钮 | 系统提示登陆失败 | |
LOG7 | 用户登陆-用户存在性 | 输入不存在用户,输入密码,单击登陆按钮 | 系统提示不存在该用户 |
2.学生基本信息管理测试用例:
主要测试事务管理员对学生信息的操作是否有预期的提示信息,以及管理员操作是否正确的改变了数据库。
测试用例ID | 场景 | 测试步骤 | 预期结果 | 备注 |
---|---|---|---|---|
BM1 | 学生基本信息的显示 | 进入学生基本信息界面 | 显示已有学生基本信息 | 学生信息的显示采用分页显示 |
BM2 | 学生基本信息的添加-进入 | 单击添加按钮,进入学生基本信息输入界面 | 进入信息添加界面 | |
BM3 | 学生基本信息的添加-全部项输入 | 在进入添加界面后输入所有学生信息项,单击提交 | 信息录入数据库,提示成功 | 输入正确的学生信息 |
BM4 | 学生基本信息添加-判重输入 | 在添加界面输入已存在学生的学号及其他学生信息,单击提交 | 提示已存在该学生,添加失败 | |
BM5 | 学生基本信息添加-省略输入 | 在添加界面不输入学生的学号但输入其他学生信息,单击提交 | 提示学号不能为空,添加失败 | |
BM6 | 学生基本信息删除-选择 | 选择需要删除的学生,并单击删除 | 提示是否删除 | |
BM7 | 学生基本信息删除-确定 | 选择删除并确定删除 | 提示已删除该学生,数据库删除该学生 | |
BM8 | 学生基本信息删除-取消 | 选择删除但在提示后取消删除 | 返回上层界面,不进行删除操作 | |
BM9 | 学生基本信息修改-进入 | 选择一学生并单击修改 | 进入学生基本信息修改界面 | |
BM10 | 学生基本信息修改-判重 | 在修改界面输入已存在学生的学号及其他学生信息,单击提交 | 提示已存在该学生,修改失败 | |
BM11 | 学生基本信息修改-省略输入 | 在修改界面不输入学生的学号但输入其他学生信息,单击提交 | 提示学号不能为空,修改失败 |
3.学生信用信息管理测试用例:
主要测试事务管理员对学生信用信息的操作是否具有正确的提示信息,并且管理员相应的操作是否正确的修改了数据库内容。
测试用例ID | 场景 | 测试步骤 | 预期结果 | 备注 |
---|---|---|---|---|
IM1 | 信用信息显示 | 进入学生信用信息界面 | 显示学生的信用信息 | 学生信用信息分页显示 |
IM2 | 信用信息搜索 | 在文本框输入需要查找的信用信息 | 显示目标信用信息 | |
IM3 | 信用信息添加-进入 | 单击添加,进入信用信息添加界面 | 显示信用信息添加界面 | |
IM4 | 信用信息添加-选择 | 选择一个可用的信用事务添加到当前学生,单击确认 | 显示添加完成 | |
IM5 | 信用信息删除 | 选择一条信用信息并单击删除 | 显示信用信息删除成功 | |
IM6 | 信用信息修改-进入 | 单击信用信息修改选项,进入信用信息修改界面 | 进入信用信息修改界面 | |
IM7 | 信用信息修改-确认 | 输入需要修改的信用信息,单击确认修改 | 提示修改成功 | 输入合法修改 |
4.奖惩事务管理测试用例:
主要测试对奖惩事务的操作是否具有合理的提示信息,且管理员对奖惩事务的操作能否更新到相关的数据表种。
测试用例ID | 场景 | 测试步骤 | 预期结果 | 备注 |
---|---|---|---|---|
PM1 | 奖惩事务添加-进入 | 单击添加,进入奖惩事务属性页面 | 显示正常布局的奖惩事务添加界面 | |
PM2 | 奖惩事务添加-提交 | 输入合法的奖惩事务属性并单击提交 | 显示提示信息,数据库更新此条数据 | 输入合法奖惩事务 |
PM3 | 奖惩事务添加-完整性判别 | 将奖惩事务的主键留空,其他属性正常填写并单击提交 | 显示提示信息提示用户主键不能为空 | |
PM4 | 奖惩事务添加-重复性判别 | 输入奖惩事务的主键与现有主键相同,其他属性不同,单击提交 | 显示提示信息当前奖惩事务已存在 | |
PM5 | 奖惩事务删除-选择 | 选择删除项,并单击删除 | 提示用户是否确认删除 | |
PM6 | 奖惩事务删除-确认 | 单击删除 | 提示用户删除成功 | |
PM7 | 奖惩事务修改-进入 | 选择一奖惩事务并单击修改 | 进入奖惩事务修改界面 | |
BM8 | 奖惩事务修改-判重 | 在修改界面输入已存在奖惩事务的编号及其他事务信息,单击提交 | 提示已存在该事务,修改失败 | |
BM9 | 奖惩事务修改-省略输入 | 在修改界面不输入奖惩事务的编号但输入其他事务信息,单击提交 | 提示编号不能为空,修改失败 |
本次测试主要发现的问题在于测试中存在一些忽略的测试点很难发现,这有可能在后续的使用中通过某些偶然事件而产生较大的系统问题。
采用测试自动化技术能够在很大程度上加快测试速度,提高测试的覆盖面,并生成可追溯的测试数据,所以学习如何使用测试自动化工具也是一个比较有意义的事情。
测试用户比较全面的覆盖了项目的基本功能。
测试的过程按照了一定的规程,使得测试结果可追溯。
测试工作包括了项目组内部的互相查验和项目组外部假定的用户来查验。保证了项目在一般使用过程中的可靠性。
标签:2.0 主键 测试结果 其他属性 需要 一个 提交 head 数据
原文地址:http://www.cnblogs.com/willingtosmile/p/7989986.html