第一部分 需求与原型改进
1.1改进的原型
1.1.1 改进说明
改进了导航栏的样式，之前没有考虑到当鼠标滑动到导航栏的相关链接上时，背景颜色改变的问题。这样的改进，使得点击的链接更为醒目，整个页面更加美观
改进了轮播图的样式
改进了排行榜中相关信息的样式，在选择某个课程查看详细介绍的时候，所在区域背景颜色发生改变
1.1.2 高保真原型
1.1.3 高保真原型下载地址
原型文件Coding.net地址：https://git.coding.net/chenf640/teamwork.git
1.2改进的需求规格说明书
1.2.1改进说明
修改1：需求规格说明书2.2用户特点更改为：经过用户调研可知，东北师范大学本科学生对自己本专业应该选修的学分、已经选修的学分数目不明确，对已经选修的科目的类型不明确，选择选修课时往往询问学长学姐，相当不方便，并且学校选课系统定期开放，不方便快速地查询学分。操作人员为本科教育水平，维护人员为本科教育水平，擅长维护系统。
修改理由：增加“对已经选修的科目的类型不明确，选择选修课时往往询问学长学姐，相当不方便”，结合用户调研的具体内容，挖掘用户需求，界定系统服务范围，明确系统功能。
1.2.2改进的需求规格说明书下载地址
https://pan.baidu.com/s/1iJ0Od6w5aVNFPGTRe5SV6g
第二部分 系统设计
2.1系统架构设计
(1)开发环境
| 序号 | 项目 | 详细信息 |
| 1 | 操作系统 | 操作系统：Windows10 运行环境：jdk1.8.0_51，jre1.8.0_51 |
| 2 | 编程语言 | JAVA、Javascript、HTML、CSS |
| 3 | 编程工具 | IntelliJ IDEA.2017 |
| 4 | 数据库 | MySQL |
| 5 | 后台开发框架 | SSM |
(2)系统整体架构
i.首先对整个系统的层次进行一个简要的说明：
| 前台 | 用户端 | 与用户进行交互 |
| 管理员端 | 展示普通用户信息，以及待处理事项 | |
| 后台 | 用户端 | 处理用户请求，并做出响应 |
| 管理员端 | 管理普通用户，并发布公告处理用户请求（举报、问题反馈） |
在系统开发中，有一般页面、Ajax、WebService等。都有对应的开发架构。具体如下图：
总体开发架构体现MVC模型，具体如下：
A.所有数据库操作都调用JDBC接口；
B.所有业务处理都在业务类（层）中完成；Ajax、页面、WebService中不直接处理业务逻辑和数据库操作，都通过调用业务层中相关类实现；
C.在访问页面之前都必须检查Session、记录日志等必须的操作；
D.每个Ajax业务都必须有固定的参数R和Action，R：每次调用都传入一个10位以上随机数，以防止缓存；Action：为Ajax调用的Action，用于具体业务操作 和权限判断；
E.Web Service也必须实现验证、权限、日志等基本的框架。
ii.前端（各个页面内容及其联系）
iii.数据库设计
数据库基本表：
数据库对应ER图：
iv.Model层
建立与数据库相对应的实体类，并创建每个实体类对应的dao层接口。
v.业务逻辑层
调用相应接口，处理客户端发送的请求，并做出响应。
(3)系统性能
在现有硬件性能的配置下，能够保证300个在线用户同时浏览，首页打开时间小于5秒；其他各个页面或操作都要及时响应；查询、统计等涉及大量数据读取或计算的页面可以适当慢一些，但是必须有提示用户稍候的提示。
(4)易用性
应有良好的用户体验，界面友好，能够根据用户特有的习惯进行一定程度的自定义。
(5)安全性
A.用户账号集中管理，用户权限由每个子系统相关管理员分散管理；
B.管理账号可以提供查询整个系统用户权限信息的功能。包括用户拥有的权限、角色信息；权限对应的用户、角色信息；角色对应的权限、用户信息；
C.在涉及到敏感操作的功能支持强认证方式，包括输入动态密码（采用手机短信动态认证方式获得）；
D.系统对于用户登陆，注销，操作等记录日志，同时提供相应界面提供管理员进行查询并生成一些报表，具体报表将来可以根据实际需求进行变更开发；
E.用户访问系统登录页面时，显示关于非授权使用系统的声明。
系统采用基于角色的访问控制（RBAC）方法。系统通过用户、角色、权限来实现用户的访问控制。需要访问控制的内容包括：
授权功能点：每个授权功能点映射到相对应的权限，当用户访问某个需要授权的功能点时，需要判断是否具有该权限。
需要授权的页面：每个需要授权的页面映射到对应的权限，当用户访问页面的时候，系统会判断该用户是否具有该页面的访问权限。
需要授权的Ajax：每个需要授权的Ajax操作都会映射到特定的权限来控制访问权限，另外，涉及到的具体业务，Ajax处理程序将判断用户具有的权限和角色。
(6)可用性
A.系统具有较高的可用性，在规定的环境条件下完成规定时间、规定功能的运行，要求达到18*5小时不间断运行；
B.系统Web应用服务器、后台数据库服务器均需支持集群部署，保证对外提供服务在一台服务器出现故障时能够在一定时间内快速切换到另外一台服务器 上，减少故障时间；
C.该平台支持主系统到远端灾难备份系统切换，当主系统部署地出现不可预见的问题或者故障时，平台所提供的服务能够在远端灾难备份处迅速恢复。
(7)开放性和可扩展性
A.整个平台支持横向扩展，当系统的处理能力达到极限时能够通过添加额外主机增加平台的访问量。无论是Web服务器还是数据库服务器都可以进行有效扩 展；
B.平台对外提供Web Service接口，允许其他系统通过这个接口发布信息。
(8)可管理性、易于维护性、容错性、兼容性
A.要有尽量全面的技术问题排查手册，涵盖日常运维时可能遇到的问题，手册要和日志对应，日志中的问题或错误代码能在技术问题排查手册中查到；要有 详细的操作以及运维文档，内容要清晰易懂，重要操作都有图片展示；提供对Web服务器管理的详细操作文档；
B.系统支持IE、火狐、谷歌、搜狗；
C.当某一子系统发生故障时，不影响其他功能的正常使用。
2.2 任务分解WBS
第三部分 测试计划
学分，选够了吗——测试计划
一、引言
1.1项目背景
我们组计划开发一款为东北师大学生选修课学分服务的软件，东北师大选修课分为自然科学、人文艺术、社会科学三大类，每一类都有学分的要求，不达到相应的学分无法毕业。而东师很多同学都不清楚自己修过的选修课属于哪一类，每到选课之际就会到处问某某课是属于什么类的，然后再大费周折地算自己每一类都修了几学分，哪一类还没修够，及其不方便。
若他们能用上我们的产品，就能够十分清楚地看到自己都修了哪些选修课，这些课是属于哪一类的，每一类都已修了几学分，还差多少分。由于这个项目是真正能够解决东师学生的实际需求的，它的潜在用户不在少数。因此我们决定开发这样一款十分有市场且能真正为东师学子服务的软件。
1.2参考资料
《学分，选够了吗——需求规格说明书》
《学分，选够了吗——用户界面说明》
《学分，选够了吗——功能设计》
1.3有关项目人员组成以及联系方式
开发人员兼测试人员：
陈芳 13159608895
马玲 13159520209
王慧珍 13159604437
马骏 13134315226
马佳欣 13104451228
吕国馨 13174414152
二、任务概述
2.1测试范围
系统的所有功能及页面
2.2测试目标
测试系统各个模块的功能是否正常，各页面在不同系统不同分辨率下是否能正常显示，系统的性能与速度是否达标，系统的抗压性是否良好等。测试完后，列出可交付模块和待修改模块。
三、测试策略
3.1测试人员需求、分工
| 角色 | （所分配的专职角色数量） | 具体职责或注释 |
| 测试总负责人 | 1 | 负责监督各阶段的测试工作及汇总 |
| 黑盒测试人员 | 3 | 代表用户，测试系统的集成测试、功能测试、用户界面测试等 |
| 白盒测试人员 | 3 | 代表开发人员，测试系统的强度、负载、容量等性能测评 |
3.2测试方法
手动测试，黑盒测试与白盒测试并存，压力测试等。
3.3工具引用及测试培训（内训／外训）
| 工具 | 用途 |
| JProfiler | 性能分析 |
| Junit | 单元测试、回归测试 |
| LoadRunner | 负载测试 |
| Selenium | 功能测试 |
测试培训：内训，自主学习测试工具的使用
3.4测试阶段计划（工作内容、人员安排、起止时间等）
| 测试活动 | 负责人 | 计划开始日期 | 结束日期 | |
| 制定测试计划 | 王慧珍 | 5.27 | 5.3 | |
| 数据库完整性测试 | 马玲 | 6.1 | 6.4 | |
| 单元测试 | 马骏 | 6.5 | 6.8 | |
| 集成测试 | 马佳欣 | 6.9 | 6.11 | |
| 功能测试 | 学分信息模块 | 陈芳 | 6.12 | 6.14 |
| 评课模块 | 马佳欣 | 6.12 | 6.14 | |
| 交流区模块 | 吕国馨 | 6.12 | 6.14 | |
| 排行榜模块 | 王慧珍 | 6.12 | 6.14 | |
| 个人中心模块 | 陈芳 | 6.12 | 6.14 | |
| 管理员端 | 马玲 | 6.12 | 6.14 | |
| 用户界面测试 | 吕国馨 | 6.18 | 6.20 | |
| 系统测试 | 王慧珍 | 6.18 | 6.20 | |
| 性能测试 | 马玲 | 6.18 | 6.20 | |
| 负载测试 | 陈芳 | 6.18 | 6.10 | |
| 线上测试版测试 | 马骏 | 6.22 | 6.23 | |
| 用户验收测试 | 吕国馨 | 6.24 | 6.25 | |
| 对测试进行评估 | 马佳欣 | 6.26 | 6.28 | |
| 产品发布 | 王慧珍 | 6.29 | 6.30 | |
3.5测试停止及恢复条件
停止条件：整个系统能够正常运行，达到用户使用标准
恢复条件：系统出现bug导致不能正常运行
3.6测试文档及缺陷提交管理等
每一测试阶段都应记录相应的测试情况，各个负责人在规定时间内提交测试文档至总负责人，汇总为一个文档。测试文档应详细记录描述测试过程中出现的问题并截图，应保证较高的可读性，便于开发人员阅读。
四．测试资源
4.1硬件资源需求
处理器：Intel(R)Core(TM)i5-6200U CPU @2.30GHz 2.40GHz
内存：4GB
4.2软件资源需求
windows10 64位
4.3其他（仪器、服务器等）
阿里云服务器
五．风险评估
| 风险项 | 风险内容 |
| 人力 | 中途会有人员的流动，交接工作较为繁琐 |
| 时间 | 临近期末，可能无法按照计划时间完全相应任务 |
| 环境 | 暂无 |
| 资源 | 各种测试软件可能要付费使用 |
| 合作 | 交流中可能出现分歧 |
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
