文学网站的设计说明书.docx
- 文档编号:28565307
- 上传时间:2023-07-19
- 格式:DOCX
- 页数:41
- 大小:195.43KB
文学网站的设计说明书.docx
《文学网站的设计说明书.docx》由会员分享,可在线阅读,更多相关《文学网站的设计说明书.docx(41页珍藏版)》请在冰豆网上搜索。
文学网站的设计说明书
1可行性分析
1.1问题描述
21世纪是信息化的,互联网实现了社会世界范围的网络间的互联和信息共享,并已全面介入人类生产生活的方方面面,带动着人类社会的飞速发展。
网站的设计与实现是目前比较热门的课题之一。
文学网站的设计与实现可以使得文学作品得到快速的推销,是读者和作者一个交流的平台。
随着信息时代的发展,对效率的要求日益提高,因而文学网站已经取代了传统的书店。
文学网站具有自身的特点:
信息要求一般齐全;读者可以方便的通过网上冲浪浏览文学作品;在软件角度看,数据较少,对存储和速度要求不高。
因此,文学网站建设的好坏直接影响人们的关注度和网站的效益。
1.2可行性分析研究
当接受一个软件开发任务,就进入软件生命的第一个阶段,即进行可行性的研究。
并不是所有问题具有简单的解决办法,许多问题不能在预定的规模之内解决。
因此通过可行性的研究分析可以知道问题。
有无可行性的解决方法,进而避免人力、物力和才力的浪费。
在现行系统初步调查的基础上就可以提出新系统目标,即新系统建立后所要求达到的运行指标,这是系统开发和评价的依据。
系统目标应充分体现,直接为文学网站服务,并且,程序可以分期分批实现。
但是,需要指出的是,系统目标是不可能在总体规划阶段就提得非常具体,它还将在开发过程中逐步明确和定量化。
以达到更加出色的程序系统。
可是,目标的提法不尽相同,例如:
·提高文学网站的打开速度;
·提高图书浏览速度和准确性;
·为读者提供更方便的服务项目。
1.2.1技术可行性
技术上的可行性分析主要分析现有技术条件能否顺利完成开发工作,硬、软件配置能否满足开发者需要等。
目前各用人单位有局域网,并且采用PC机作为工作台,其容量、速度能满足系统要求。
根据网站建设提出的系统功能、性能及实现系统的各项约束条件,根据新系统目标来衡量所需的技术是否具备,本系统是一个数据库管理和查询的系统,现有的技术以较为成熟,硬件、软件的性能要求、环境条件等各项条件良好,估计利用现有技术条件应完全可以达到该系统的功能目标。
1.2.2经济可行性
主要是对开发文学网站的经济效益进行评价,一方面是估算开发它的支出费用,其中包括设备购置费、软件开发费、管理和维护费、人员工资等。
另一方面是估算文学网站可能取得的收益中可以用钱来衡量的那部分。
并对目前的软件市场进行调查,所做软件是否有很大的销售市场和相当规模的用户群。
所做软件的开发成本与客户提出的要求是否可达到双方都满意。
并且,分析系统开发是否会对其它产品或利润带来一定影响。
经过对上述几个方面的调查研究和分析,我们得出文学网站的市场前景是相当客观的,在经济角度来说,开发文学网站是可行的。
1.2.3操作可行性
本系统采用基于Windows的图形用户界面,而该系统是大家熟悉的操作系统,对于那些有一般的计算机知识的人员就可以轻松上手。
而整个文学网站采用最友好的交互界面,简介明了,不需要对数据库进行深入的了解。
由此,该系统的操作是可行的,有必要开发该系统。
综合以上三方面,该系统具有很高的开发可行性,无论是从技术上或者经济上还是操作上。
因此,可以设计该系统的数据流程图,建立数据字典。
1.3结论意见
经过认真地可行性研究,系统基本上做到了在技术、经济、运行、法律上的可行。
因此,相信在按照计划上实施的前提下,全系统的设计将会按时、高质量完成。
所以,系统研制和开发是可以马上进行的。
2项目开发计划
2.1编写目的
经过项目的可行性分析,得出项目可进一步进行下去的结论,在软件继续进一步的开发之前首先给出此软件项目计划。
2.2项目背景
项目分析单位在接到项目分析员给出的项目可行性分析报告后,在本系统,即文学网站开发主管部门的统一下制定用于软件实质开发的软件项目计划,以使软件开发单位理解软件开发要求,进行开发。
2.3项目概述
1.工作内容
让计算机对图书的各种信息进行自动管理,读者可以直接通过计算机进行阅读。
2.条件与限制
开发该软件的条件比较简单,以开发单位目前的经济与技术条件已完全具备开发的条件。
该系统可在用户要求的期限内完成。
3.产品
(1)程序
该项目因开发时间较短,这里只给出设计思想,具体程序没写。
(2)文档
文档内容包括:
封面
可行性分析
项目开发计划
需求规格说明(包含需要的系统流程图、数据流程图、数据字典、E-R图)
概要设计(包含总体软件结构图、总体数据结构)
详细设计(对概要设计内容进行详细设计)
设计总结、参考文献、致谢等
4.验收标准
软件的验收标准完全由用户提出的软件需求制定,能保证软件的基本符合用户的要求。
2.4项目开发计划
1.任务分解
分三个大的阶段进行开发第一阶段完成本系统的数据流图跟E-R图。
第二阶段完成概要设计跟详细设计。
第三阶段书写文档。
2.预算
软件资金投入较少,具体预算分配简略。
3.关键问题
各模块之间的联系和后台数据库的完成。
使用目前的设备与现有开发技术完全可以开发出该系统,总的来说该项目没有较大的技术难点与其他的一些风险因素。
对于出现的一些小难点总都能得到解决。
2.5交付期限
所要开发的系统较简单,所有开发工作用户要求要完成项目的最迟时间为2014年12月30日。
3需求分析
3.1任务需求分析
经分析先给出该系统的系统框架图,如图3.1所示:
图3.1系统框架图
该系统主要包括前天文学发布子系统和后天信息管理子系统两部分,而没个部分又有个子的几个子模块。
系统要实现基本信息录入、修改、查询等功能:
1.信息的输入,包括前台页面信息、作者信息、用户注册信息、文章信息等。
2.信息的修改、删除。
3.根据要求,查询统计符合条件的各类信息。
4.依据实际需要,对重要新信息进行统计。
3.2数据流图、数据字典及实体联系图
3.2.1数据流图
以下是文学网站的数据流程图。
前台界面包含的信息内容如下所示:
该数据图如图3.2所示:
图3.2数据流图
数据流图由四种基本的元素构成:
数据流(DataFlow),处理(Process),数据存储和数据源(数据终点)。
数据流(DataFlow):
为具有名称且有流向的数据,用标有名称的箭头表示,一个数据可以是记录、组合项或基本项。
处理(Process):
表示对数据所进行的加工和变换,在图中用矩形框表示。
指向处理数据流为该处理的输入数据,离开处理的数据为处理的输出数据。
数据存储:
表示用文件方式或数据库形式所存储的数据,堆砌进行的存取分别以指向或离开数据存储的箭头表示。
数据源及数据终点:
表示数据的来源或数据的去向,可以是一个组织或人员,它处于系统范围之外,所以又称它为外部实体,它是为了帮助理解系统界面而引入的,一般只出现在数据流图的起点和终点,具体数据流图见图3.3
3.2.2数据字典
数据字典是关于数据的信息的集合,也就是对数据流图中包含的所有元素的定义的集合。
1.管理员=用户名+密码
2.会员信息=自动编号+会员用户名+会员密码+姓名+性别+出生日期+身份证件号码+民族+户籍所在地+教育程度+联系电话+手机+电子信箱+联系地址+ 注册时间
3.作者信息=编号+籍贯+用户名+爱好+性别+姓名+出生年月+作品
4.编号=(0,1,2,3,4,5,6,7,8,9)
5.信息=汉字+英文字母+数字
文件条目
(1)加工名:
查询
加工逻辑:
根据要查询的文学作品信息,检索出作品信息明细表
输入流:
作品信息查询,发出作品信息请求
输出流:
作品信息清单,用户信息请求
(2)加工名:
更新
根据作品信息更新库存信息
输入流:
新增会员信息,新增图书信息
输出流:
发出新增信息检索请求
(3)加工名:
查询
根据要查询的作者信息和用户信息,检索出作者的作品明细表
输入流:
作者信息查询
输出流:
作者及作品信息清单
(4)加工名:
更新
加工逻辑:
根据作者信息和会员信息
输入流:
前台作者信息和注册信息
输出流:
更新后台清单
3.2.3实体联系E-R图
根据对数据流图和数据字典的分析,我们可以确定该应用中的实体,属性和实体之间的关系,并画出如下所示的E-R图。
联系电话
会员密码
会员
用户名
编号
联系地址
姓名
注册时间
性别
图3.3会员实体E-R
图3.4管理员E-R模型
图3.5作者实体E-R图
图3.6文章实体E-R图
图3.7总体E-R图
3.3测试计划
3.3.1引言
1.编写目的
本测试计划主要用于控制整个文学网站项目测试,本文档主要实现以下目标:
通过此测试计划能够控制整个测试项目合理、全面、准确、协调地完成。
为网站测试提供依据。
项目管理人员根据此计划,可以对项目进行宏观调控。
测试人员根据此计划,能够明确自己的权利、职责,准确地定位自己在项目的任务。
相关部门,可以根据此计划,对相关资源进行准备。
2.背景
(1)本测试计划从属于理工科技有限公司,为文学网站实现B/S模式网站系统的测试。
(2)项目任务的提出者为:
公司项目管理部;系统的开发者为:
公司开发管理部;系统的使用者为:
文学网站管理。
(3)此测试项目的进行,将在需求确认后开始执行,基准是准确、全面的需求文档。
测试重点是对开发实现的功能和性能进行测试。
3.定义
无
4.参考资料
《B/S文学网站需求规格说明书》1.0版本
《B/S文学网站测试计划编写规范》
5.控制信息
本项目测试小组:
石鹏飞、史一凡;电话号码:
(0931)4256475。
6.测试目标
该测试项目将通过设计和执行接受测试、界面测试、功能测试和性能测试,对软件实现的功能,以及软件的性能、兼容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。
基于本系统的业务复杂性和开发周期短的特性,系统测试的重点将放在功能测试和性能测试上。
通过测试提高软件的质量,为用户提供最好的服务,并合理地避免软件的风险和减少软件的成本。
3.3.2计划
1.测试过程
2.进度安排及里程碑
图3.8
如表3.1出进行各项测试的日期和工作内容(如熟悉环境、培训、准备输入数据、实施测试等)。
表3.1各项测试的日期和工作内容
里程碑任务
工作
开始日期
结束日期
制定测试计划
石鹏飞、史一凡
2014-12-15
2014-12-16
设计测试
石鹏飞、史一凡
2014-12-17
2014-12-19
实施测试
石鹏飞、史一凡
2014-12-20
2014-12-24
对测试进行评估
李彦明、路飞
2014-12-26
2014-12-27
3.角色
角色如表3.2所示:
表3.2角色表
负责人:
史一凡
其他负责人
职责
联系信息
职责:
负责制定测试计划;负责编写和验收用例;完成项目实测;负责与外部合作部门交互;负责协调内部人员的工作;负责编写测试报告。
史一凡
编写用例
史一凡
编写测试报告
石鹏飞
制定测试计划
石鹏飞
项目实测
测试组成员
姓名
职责
联系信息
石鹏飞
负责功能测试用例的编写和实施
史一凡
负责性能和其他非功能测试用例的编写和实施
4.系统
表3.3列出了测试项目所需的系统资源。
表3.3测试项目所需的系统资源
系统资源
资源
名称/类型
数据库服务器
AccessNet
网络或子网
服务器名称
数据库名称
Access
客户端测试PC
IE8
包括特殊的配置需求
Dreamweaver8
测试存储库
Bugs
网络或子网
服务器名称
测试开发PC
Window7
硬件环境
IntelCore(TM)CPU2.0GHz;内存2GB
5.可交付工件
测试计划:
一份。
测试用例:
一份。
测试缺陷记录:
一份。
测试报告:
一份。
测试模型
文学网站系统1.0
测试记录
采用测试用例的形式提交测试过程,详见《测试用例》文档。
缺陷报告
采用缺陷记录的形式,详见《测试缺陷记录》文档。
6.测试资料
测试文档:
测试相关模块。
需求文档:
项目需求文档。
7.项目风险分析
项目风险分析如表3.4所示:
表3.4项目风险表
风险类型
风险综述
现有人力资源严重不足。
在确保质量的前提下,人力资源与项目周期比例失调,因此人员不到位,将存在项目风险。
增加人员
测试中使用IE7,因此在IE8等其他环境下运行存在风险。
与客户确定为争取时间保证质量仅使用IE7进行测试
进度存在风险
实际进度将按照开发进度进行,预期进度按照开发进度进行,但是实际开发
度变更时,将按照实际开发进度及时
正测试进度。
测试环境各服务器的配置低于实际产品使用时的服务器配置
与客户商议达成一致
人员变动风险
通过培训等措施使变更后的人员了解
统的业务流程,对系统深入了解,以
求在最大限度内保证测试质量
数据库测试中存在风险。
因测试周期的限制,因此根据实际情况选择的测试策略存在的风险情况反应给客户,与客户商议达成一致。
版本部署风险
版本在部署的时候,可能会由于数据库的导入错误等原因导致系统出错。
因此在实际给客户部署时同样存在此种风险。
数据迁移部分增加了一个测试策略以验证迁移数据的完整性,该策略是以自建的小数据来模拟大数据。
因此对于实际超大数据量的数据迁移存在一定风险。
但是该方法能够验证数据迁移的迁移方法的正确性,且能够非常直观的查看结果。
8.测试设计说明
8.1概述
(1)测试方法和测试用例选取的原则
系统:
根据《系统需求说明书》对系统进行单元测试、集成测试、系统测试、验收测试、性能测试,并结合可能的用户测试。
全面:
要求测试用例能够覆盖每一个测试点的要点。
合理:
从可行性角度考虑,测试不可能全面覆盖,所以设置好等价类划分,测试的用例的选择避免重复测试、选择最好的测试方法将测试点合理覆盖。
(2)测试的控制方式
测试用例的实现必须遵守测试计划的安排,实际测试必须以测试用例为基准。
实际测试中测试用例的状态记载:
failed:
如果某一步测试用例失败,但不影响以后测试处理。
block:
如果某一步测试用例失败,并影响以后测试用例处理。
good:
测试成功。
实际测试与外部交互使用缺陷记录清单进行交流。
测试人员必须详细、准确填写缺陷记录内容,开发修改人员要详细、准确地填写修改情况,通过缺陷记录清单的状态进行测试和修改交互。
open:
当开始一个问题报告单时为open,开发返回后,错误仍存在为re-open。
fixed/return:
开发人员对错误进行了修改为fixed,开发人员对错误没有进行修改,返回测试部为return。
close/cancel:
测试人员确认错误已经修改为close,测试人员确认错误的无效或可以接受(标记)为cancel。
测试版本的控制
由项目开发组随版本发布时提交版本提交单,测试组完成测试后提交版本测试报告,版本更新时由开发组填写更新记录。
测试用例的命名原则:
[测试点]-编号。
例如:
LZ-01。
缺陷记录清单命名原则
缺陷记录清单+_测试人员名称+_日期
例如:
缺陷记录清单_史一凡_20141210
8.2数据选择策略
数据的选择全面覆盖所有数据、并要求避免冗余数据的使用(采用边界值、特殊值、以及普通值)。
8.3测试过程描述和操作步骤
8.3.1测试过程描述
8.3.2书写测试计划
8.3.3参考测试计划、需求、概要设计以及部分详细设计文档进行用例设计
8.3.4参考测试计划和测试用例进行实际测试操作
8.3.5测试总结和报告
操作步骤
(1)测试基本流程(简易的IVT)。
(2)测试功能块(重点为容错测试)。
(3)统计信息的测试(IVT)。
9.软件说明
文学网站系统主要涵盖会员、游客两种角色访问,实现功能主要有:
用户管理、留言管理、订单查询,详见《需求规格说明书》。
10.测试内容及策略
本测试将通过用户界面测试、集成测试,系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。
用户界面测试用于核实用户与软件之间的交互,测试用户界面的正确性和易用性。
(1)用户界面及易用性测试
目的:
确保用户界面通过测试对象的功能来为用户提供相应的访问或浏览功能;另外,UI测试还可以确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。
内容:
对系统的功能页面进行各种可操作性测试。
重点:
容错检测,易用性。
(2)集成测试
目的:
检测系统是否达到需求,对业务流程及数据流的处理是否符合标准,检测系统对业务处理是否存在逻辑不严谨及错误,检测需求是否存在不合理的标准和要求。
内容:
利用有效的和无效的数据来执行各个用例,用例流或功能,以核实在使用有效数据时得到的预期结果,在使用无效数据时显示相应的错误消息或警告消息,个业务规则都得到了正确的应用。
重点:
测试的单元模块之间的接口和调用是否正确,集成后是否实现了某个功能。
(3)系统测试
目的:
将软件整合为一体,看各个功能是否全部实现。
内容:
将整个软件系统看作一个整体进行测试,测试功能是否能满足需求,是否全部实现,后期主要包括看系统运行的性能是否满足需求,以及系统在不同的软硬件环境中的兼容性等。
重点:
系统在配置好的环境中是否可以正常运行。
(4)压力测试
目的:
了解(被测应用程序)一般能够承受的压力,同时能够承受的用户访问量(容量),最多支持有多少用户同时访问某个功能。
内容:
因为事先我们不知道将有多少用户访问是临界点,所以在测试过程中需要多次改变用户数来确定,
计划的设置,每x时间后加载10用户(根据总用户数设置),完全加载后持续运行不超过5分钟(根据需要设置)。
当运行中的用户数100%达到集合点时释放。
重点:
找到系统的临界值点。
(5)功能测试
目的:
功能测试就是对系统的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。
内容:
(1)页面链接检查:
每一个链接是否都有对应的页面,并且页面之间切换正确。
(2)相关性检查:
删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。
(3)检查按钮的功能是否正确:
如update,cancel,delete,save等功能是否正确。
(4)字符串长度检查:
输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度,会不会出错。
(5)字符类型检查:
在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型是否报错。
(6)标点符号检查:
输入内容包括各种标点符号,特别是空格,各种引号,回车键,看系统处理是否正确。
(7)中文字符处理:
在可以输入中文的系统输入中文,看会否出现乱码或出错。
(8)检查带出信息的完整性:
在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。
(9)信息重复:
在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
(10)检查删除功能:
在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理是否出错,然后选择一个和多个信息,进行删除,看是否正确处理。
(11)检查添加和修改是否一致:
检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填,添加规定为整型的项,修改也必须为整型。
(12)检查修改重名:
修改时把不能重名的项改为已存在的内容,看会否处理报错,同时也要注意会不会报和自己重名的错。
(13)重复提交表单:
一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。
(14)检查多次使用back键的情况:
在有back的地方back,回到原来页面,再back重复多次,看会否出错。
(15)search检查:
在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确。
如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确。
(16)输入信息位置:
注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
(17)上传下载文件检查:
上传下载文件的功能是否实现,上传文件是否能打开。
对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。
(18)必填项检查:
应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*。
(19)快捷键检查:
是否支持常用快捷键,如Ctrl+C、Ctrl+V、Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。
(20)回车键检查:
在输入结束后直接按回车键,看系统处理如何,会否报错。
重点:
确保各项功能和用户需求一致
3.3.3性能测试
目的:
核实性能是否满足用户需求,将测试对象的性能行为当作条件的一种函数来进行评测和微调。
内容:
负载测试、强度测试。
1.单个事务单个用户时候,在每个事务所语气时间范围内成功完成测试脚本,没有发生任何故障;多个事务多个用户时,可完成脚本没有发生故障的情况临界值。
2.使测试系统承担不同的工作量,得出系统持续正常运行的能力。
3.找出因资源不足或资源争用导致的错误。
重点:
确保性能指标满足用户需求。
3.3.4容量测试
目的:
所计划的测试全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。
内容:
在客户机长时间内执行相同的、最坏的业务时候系统维持的时间。
重点:
核实系统能否在连续或模拟了最多数量的客户机下正常运行。
3.3.5安全性和访问控制测试
目的:
保证只有访问权限的用户才能访问系统,核实用户以不同身份登录有不同的访问权限。
内容:
数据或业务功能访问的安全性,包括系统登录或远程访问。
重点:
确保治具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
。
3.3.6故障转移和恢复测试
目的:
检测系统可否在意外数据损失、数据完整性破坏、各种硬件、软件、网络故障中恢复数据。
内容:
1.客户机断电、服务器断电看事务可否发生回滚。
2.网络服务器中断。
重点:
看数据库的恢复情况,以及系统在经历意外时间时候是否会发生崩溃现象。
3.4测试用例范围
3.4.1功能测试
测试的重点将主要放在功能测试上,按照三种角色:
管理员、普通用户,每种角色包括如下模块:
1.管理员
模块
编号
测试项
登录
1
以会员身份登录,登录成功则跳转会员管理主界面
2
用户账号被屏蔽,无法登录成功
3
输入非法标识符,提示输入错误字符
4
输入用户名错误,提示用户不存在
5
输入密码错误,提示密码错误
用户管理
1
可设置每个用户的开启或屏蔽权限,进行开启用户或删除用户
2
单击角色修改按钮,进入角色修改页面,点选角色,修改成功,跳转登录界面
3
对用户信息进行修改,输入已注册用户新信息,提交后跳转到登录界
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 文学 网站 设计 说明书