RUC自习助手_测试文档

文档编号:2016052601

版本信息:v1.0

开发小组:找不到地方上自习组

成员:王丹丹、赵安、吴婧、杨轹丹、孟启飞、彭宇清


版本号


编写人


修改描述


修改时间


V1.0


吴婧


编写初稿


2016-5-30

I.   引言

 i.   编写目的

编写这份需求分析规格说明书的目的是为了明确需求,规范化产品的编写,提高开发过程中的能见度,便于控制和管理产品的开发过程,同时安排项目规划与进度,便于程序员与用户之间的交流、协作,并进一步定制产品开发的细节问题,组织产品开发与测试,便于用户与开发商协调工作。这份需求分析规格说明书预期的读者主要是开发人员和管理人员。

 ii.   背景

目前,中国人民大学教学楼的管理并不完善。与之相较,从预约到选座再到超时违规处理,图书馆已经建立了一套趋于完善的选座系统(但仍有不足,我们今后也会提出分析改进的建议)。

我们观察到,教学楼的管理存在着如下问题:

a)    自习教室选择随机:由于无法提前查看教室占用情况,同学们往往是随机选定教室自习,甚至由于绝大多数教室均处于上课占用状态(如白天明德主楼四层往往所有自习室均处于有课状态),很难找到合适的自习室,不得已更换教学楼,浪费了时间和精力;

b)    举办活动占用教室流程繁琐:经改进后的由中国人民大学教务处颁布的《教室借用流程》虽从审批时间及流程上一定程度地简化了申请借用教室的流程,但仍存在提交表单部门不一致、选择活动主管单位领导人审批不及时等问题;

c)    非上课时间借用教室无需申请:晚上的教室占用则无指定流程,许多组织举行例会前没有提前告知在该教室自习的同学,导致许多同学都有上自习到一半不得不更换教室,影响学习状态。

 iii.   定义

RUC:Renmin University of China中国人民大学

 iv.   参考资料


《构建之法》


邹欣


人民邮电出版社


软件工程6th Edition


[英] Ian Sommerville


机械工业出版社,中信出版社


软件工程导论第5版


张海藩


清华大学出版社(2008)


软件工程——实践者的研究方法


Roger S. Pressman


机械工业出版社  

II.   任务概述

 i.   目标

以中国人民大学为试点,开发一个微信公众号,为学校管理员与学生用户之间提供一个平台,初步实现教室预约的信息化、公示化以及自习地点的实时查询和推荐,保证教室资源的合理调控和利用。

具体为实现以下功能点:

l 针对学生用户:

  a) 规范公共教学楼教室的非规定时间段的借用申请流程;

  b) 公共教学楼教室使用状态的公示(包含自习人数占座比、是否被活动占用中等);

  c) 图书馆,藏书馆等自习地点选座情况实时查询;

  d) 向学生用户推荐自习地点。

l 针对管理员用户:

  a) 简化批准借用教室流程;

  b) 观察教室使用情况,实现合理调控。

 ii.      运行环境

用户端运行:微信平台

开发工具:eclipse

后台数据库管理工具:SQL Server 2008

建模工具:Microsoft Visio

 iii.      需求概述

现今中国人民大学在教师预约与自习资源管理等方面存在问题,我们将开发一款产品来协助学校进行宏观自习资源调控。

 iv.      条件与限制

a) 开发时间

  一学期

b) 运行环境

  用户端运行:微信平台

  开发工具:eclipse

  后台数据库管理工具:SQL Server 2008

  建模工具:Microsoft Visio

c) 使用寿命

  预期五年及以上

III.   计划

i.      测试目标

1、测试座位情况实时展现、选座、推荐、借用四大功能是否实现,业务流程是否正确;

2、测试产品的健壮性、抗压性、稳定性;

3、尽可能多地发现并解决bug。

ii.      测试范围

本次测试涉及本产品的如下模块:

1、UI模块

2、数据库连接、同步、更新

3、服务器运行

4、用户登入模块

5、用户选座模块

6、管理员审批模块

7、选座推荐模块

iii.      测试资源及工具

测试服务器一台,IP地址:127.0.0.1;

测试人员2名

iv.      测试种类

本测试分为三种:界面测试、功能测试、压力测试。

1、界面测试:

目标:公众号界面美观,无显示异常、不兼容现象。操作方便、直观。

2、功能测试:

目标:公众号能够按照既定的流程工作,各功能运行正常。各个模块间数据通信正常,无功能顺序意外反转等情况。对极端、非法操作及输入有健壮性。

3、压力测试:

压力测试根据实际情况包含性能测试,重点模拟客户进行多用户测试。压力测试有一条8:2原则。及百分之八十的业务量在百分之二十的时间内输入。根据统计的教室、图书馆最大容纳量及上座率,本测试将在1小时内输入100条数据。

目标:产品在上述压力下运行正常。

本次测试重点在于功能测试。

v.      测试流程

    用户登入

            登入分管理员和普通用户两部分,分别测试:

登入界面是否能正常跳转;

      后台数据库是否登记成功;

      跳转后页面是否显示正常,管理员为待审批申请界面,普通用户为座位情况展示界面。

            普通用户选座、退选及申请:

建筑地图是否显示正常,是否能成功点击进入详情;

建筑内是否显示正常,是否能成功展示特定教室详情;

用户选座是否能显示正常;

后台数据库是否登记选座情况成功;

是否成功防止重复选座行为;

用户退选是否显示正常;

后台数据库是否退选成功;

后台定时(24小时)清空选座表是否成功;

申请界面是否显示成功;

待审批申请是否提交至数据库。

    管理员审批

审批界面是否显示正常;

后台数据库是否写入审批状态;

审批状态是否实时通知申请用户。

            座位推荐

推荐界面是否显示正常;

推荐计算模块是否工作正常;

回显是否正常。

 

 vi.      测试进度及任务安排


时间


测试种类


测试模块


测试人员


2016.05.15


界面测试


UI模块


赵安


2016.05.17-

2016.05.25


功能测试


数据库连接、同步、更新;

服务器运行;

用户登入模块;

用户选座模块;

管理员审批模块;

选座推荐模块。


王丹丹、孟启飞、杨轹丹、彭宇清


2016.05.27


压力测试


公众号整体


赵安

时间: 2024-08-25 09:28:32

RUC自习助手_测试文档的相关文章

RUC自习助手_概要设计说明书

文档编号:2016052303 版本信息:v3.0 开发小组:找不到地方上自习组 成员:王丹丹.赵安.吴婧.杨轹丹.孟启飞.彭宇清 版本号 编写(修改)人 修改描述 修改时间 V1.0 吴婧 编写初稿 2016-4-20 V2.0 吴婧 对之前版本进行修改 2016-4-26   I.   引言   i.   编写目的 本说明书是在充分理解软件需求分析基础上,为详细设计及编码设计准备的,是详细设计和系统编码的根据,同时也是与用户进行交流的文档之一.本文档的预期读者为软件用户,软件设计师(详细设计

RUC自习助手_需求分析规格说明书

文档编号:2016051603 版本信息:v3.0         RUC自习助手 需求分析规格说明书 开发小组:找不到地方上自习组 成员:王丹丹.赵安.吴婧.杨轹丹.孟启飞.彭宇清 版本号 编写(修改)人 修改描述 修改时间 V1.0 吴婧 编写初稿 2016-3-14 V2.0 吴婧 对之前版本进行修改 2016-3-28 V3.0 吴婧 对之前版本进行修改 2016-5-16 目录 I.  引言................................................

ASP.NET WebAPI使用Swagger生成测试文档

ASP.NET WebAPI使用Swagger生成测试文档 SwaggerUI是一个简单的Restful API测试和文档工具.简单.漂亮.易用(官方demo).通过读取JSON配置显示API .项目本身仅仅也只依赖一些html,css,js静态文件.你可以几乎放在任何Web容器上使用 捣鼓了好久最终效果如下 1.API控制器和action描述 2.测试接口 使用swagger 1.创建webapi项目解决方案 2.引用swagger nuget包 swashbuckle和swagger.NET

测试文档和用户说明书

最近把项目编写的差不多了,然后组长让我写测试文档和用户说明书,说明书给了一个以前他们写过的,然后就想着先把用户说明书写完,过程还好,但是在我写测试文档的时候发现自己真是一波三折. 说明文档的时候,大概有4个窗体,然后呢,我就是先把窗体界面截出来,然后就会在文档上写1-->2-->3-->4,第一步,单击某个按钮,弹出某个窗口,然后选择数据.... 很快,用户说明书写完了,感觉好简单,但是测试文档以前没有好好的写过,所以这次写的时候我还特意要了一个别人写过的文档,但是我对人家的项目也也没什

Hello World!这是一篇测试文档

这是用Windows Live Writer写的一篇测试文档仅供测试

五种方式来消除你对测试文档的仇视

据我所知,测试人员还没有一个专门的吐槽论坛.但是如果有的话,我相信我们中的很多人会承认对撰写测试文件有多么厌恶. 我工作的一部分是不断叨扰别人去写测试文件.我要他们去写文档模板,去查看团队写出的大量测试文档.我可以告诉你,想要在测试过程中发现一个有趣的bug让你的测试工作充满乐趣这只存在于想象中. 更糟糕的是,由于我是一个公司做测试文件的头儿,那么我就必须时刻标榜自己,成为别人的榜样,才能下属心甘情愿为我做事.即使我真的不喜欢,我也不能直接忽视我所负责要做的测试文件. 然而,即使测试并不是一份最

测试文档锁:doc.LockDocument()

/// <summary> /// 总结:用到DocumentManager.Open(filePath)时,如果是ForWrite,就需要用到lock文档锁. /// </summary> [CommandMethod("T38")] //测试文档锁 public void T38() { //Document doc = Application.DocumentManager.MdiActiveDocument; //如果是MdiActiveDocument

测试人员必掌握的测试文档

软件测试文档一般是提供测试信息的一组文档,可以是测试人员的工具,也可以是项目开发团队的开发辅助工具. 一般情况下,与项目相关的测试文档主要有以下几个 ~ 1.测试计划.(详情可参考一份标准的测试计划包含哪些要素文章)测试计划由测试小组编写完成后,需同项目中相关人员进行评审,以确保当前的计划与项目进度等方面是一致的. 2.测试策略.一般情况下,较大型的项目会有附加的测试策略文档 ,即详情测试设计.与开发小组中的概要设计文档类似.测试策略文档编写完成后也需要由相关项目经理.开发人员进行评审 .了解测

逆转海绵组测试文档

1.引言 本部分介绍测试基本情况和要求,包括编写目的.项目背景和术语等. 1.1 编写目的 为软件测试建立计划,供软件测试人员作为软件测试实施时的参考. 1.2 项目背景 <海绵宝宝>是一部1999年发行的美国喜剧动画,可以说是一部和我们同龄,陪伴我们成长的一部动画,它的内容搞笑,轻松解压.<逆转裁判>CAPCOM公司制作的法庭辩论型AVG游戏,在游戏中玩家扮演辩护律师,在假象规则的序审法庭上与检察官进行辩论,通过追问和质疑嫌疑人和证人,为委托人获得无罪判决是最终的胜利目的. 2