总结与展望Word文档格式.docx
《总结与展望Word文档格式.docx》由会员分享，可在线阅读，更多相关《总结与展望Word文档格式.docx（13页珍藏版）》请在冰豆网上搜索。
3、确认测试
通过集成测试以后，接口错误已经发觉被发觉并更正了，接下便要进行确认测试。
所谓确认测试确实是验证所开发软件的功能性及其他特性是不是符合软件需求规格说明书的要求。
因此，确认测试又被称为有效性测试。
4、系统测试
系统测试是更大范围内进行测试，它将通过确认测试的软件作为整个基于运算机的系统的一个元素，在实际运行环境下，对系统进行的一系列集成和确认测试。
二、微博系统测试
（一）注册页面的错误提示和提交注册信息测试
反复点击注册页面的输入框，检测其失焦提示错误的JS事件是不是会失效。
然后再别离依“
”次增多地填入用户名、密码等，点当即注册按钮，看其是不是提示缺失的必填选项。
接着，再新建一个合法账户，然后从头注册个与其名字相同的账户，看系统是不是提示，而且不为其添加记录。
通过以上反复测试，该模块测试成功。
（二）登录功能及模块进入身份限制的测试
利用建好的账户不断登录退出系统，检测系统存储的用户信息是不是转变。
然后检测，不同身份的用户是不是能进到其身份不符合的模块。
（三）输入模块的测试
关于微博的发布各项比如表情，图片，音频等反复地测试，利用它们发送是不是正常。
（四）我的首页模块的测试
关于登录成功的用户跳转到用户自己的微博首页，会显示校园即时微博信息，而且首页链接到各项功能模块，而且能够发布微博。
测试各个功能模块是不是正常，假设有问题，马上修改。
（五）@提到我的模块的测试
当他人发布的微博或转的微博含有@用户名的信息，那么会给被@的用户即时消息提示，检查此功能是不是正常，若是没有过失那么测试成功。
（六）微博正文模块，包括转发、收藏、评论的测试
是不是能够正常转发、收藏、评论他人的微博，检查功能是不是正常，若是没有过失那么测试成功。
通过反复测试，该模块测试成功。
第六章总结与展望
二、总结
（一）、学习
通过这次的毕业设计，我主若是学习到了如何利用ROR进行WEB开发，如何灵活利用CSS写出想要的页面样式，同时也学习了软件工程和数据库方面的知识。
在整个系统的开发中，碰到了很多的难题，比如如何正确的去统计转发数量和评论数量等。
通过几回的修改和借鉴Sina微博的做法,才得以初步解决。
也让我对权限和授权的知识的熟悉更进了一步。
而且自己学习利用PHOTOSHOP等工具，也是为了配合CSS让自己的系统页面更好看，有一个好的视觉成效，也是花了很长的时刻。
对UI设计也更有了解了。
（二）、反思
固然，由于各方面知识的不专业，如此的一个系统还不够成熟。
而且许多当初的设计的功能最后因为各类缘故也未能加入。
系统在一开始编写时未能给那些功能预留扩展，这是我在详细设计时候未设计完善所致使的，是一个专门好的体会教训。
希望以后自己有更好的设计。
一、展望
通过这一次毕业设计，使我熟悉到自己在运算机领域所擅长的和所需要弥补的是什么。
我喜爱着眼于一个软件产品的UI，自己会学习各类相关的知识来完成一个自己设计的UI。
而且CSS也是我自己擅长的。
以后我会更尽力学习关于产品UI的专业的知识，以从事于相关职业，更好的做好产品的图形界面设计。
参考文献
[1]、DaveThomas,DavidHansson等.应用Rails进行敏捷Web开发.电子工业出版社.2006.
[2]、裴有福.Web技术大全.中国水利水电出版社.1998
[3]、XX明白.、Baron
Schwartz、Peter
Zaitsev、Vadim
Tkachenko、Jeremy．高性能MySQL（第2版）.电子工业出版社:
2020
[5]、贾铮等.HTML+CSS网页布局开发指南.清华大学出版社.2020
[6]、邓蔚等.编程红宝书：
Ruby完全自学手册.机械工业出版社.2020
[7]、柳靖等．Ruby
on
Rails快速Web应用开发实战[M].电子工业出版社.2006
[8]、〔美〕杰克﹒戴维斯.ThePhotoshopWow!
.
致谢
通过一个学期的尽力，毕业设计系统的开发临时告一段落了。
这次毕业设计，让我充分的把这几年所学到的专业知识融会贯通，从做需求分析、设计数据库、到系统整体设计和具体的代码实现。
整个设计，让我学到了许多以前在课堂上面学不到的知识，专门大程度的增强了自己的实践能力。
在此，感激我的指导老师许精明教师的指导和催促，在整个的开发步骤上，教师给咱们列出了详细的任务工作打算，使咱们在开发进程上，不致于茫然。
在设计思路和系统功能结构方面，教师给咱们提出了许多宝贵的意见，同时不断地给咱们提出更高的要求。
另外，感激在我的毕业设计进程中给过我帮忙的所有同窗，是大伙儿的帮忙才得以完成我的那个系统。
同时在设计进程中，我也发觉了自己的不足，因为是第一次进行如此的课题开发，在代码的实现上略现笨拙，整个程序在架构上也算不上完美，以致予一些最初设计的功能最终并未实现,但我相信通过尔后的学习和实践，自己在开发能力必然能够取得大大的提高。
最后衷心感激四年来辛勤教育咱们的教师，感激朝暮相处的同窗和在毕业设计中被我引用或参考的论著的作者，并向参与这次答辩的教师致以深深的谢意!
附录二附录文献翻译
模型、视图和操纵器
Rails应用的架构
Rails应用的一个有趣特性是它在如何组织web应用上强制推行一些严格的限制。
令人惊讶的是，这些限制让创建应用变得方便，而且不止一点的方便。
让咱们来看看是什么缘故。
让咱们回到1971年，TrygveReenskaug为开发交互应用制造了一种新架构。
在他的设计中，应用被分解为三种组件：
模型、视图和操纵器。
模型负责保留应用的状态，有时状态是临时的，仅与用户交互时存在，有的状态是持久的，通常被保留在应用之外的数据库中。
但模型不单单只是数据，它实施与数据有关的所有业务逻辑。
举例来讲，若是一个账户不该被用于一个小于20美元的定单额度，模型将为账户施加该约束。
这确实是意义所在。
通过在模型中制约业务逻辑规那么，咱们能够确保没有任何其他东西会阻碍数据的稳固性。
模型同时作为数据库和看管者而存在。
视图负责更新用户界面。
通常它基于模型中的数据。
举例来讲，某在线商店有个产品目录要呈现给用户，该目录可通过模型取得。
但取得目录并以必然格式呈献给最终用户的却是视图，尽管视图可能为用户提供多种输入数据的方式，但它本身并非治理这些输入的数据。
当数据呈现给用户以后，视图的工作就完成了。
可能会有许多视图共享同一数据模型。
在网络商店案例中，一些视图负责呈现商品目录信息，而另一些视图用于治理员增加或修改商品信息。
操纵器负责和谐整个应用。
它从外部世界（一般是用户输入）接收事件，与模型交互，并给用户呈现相应视图。
这三者——模型、视图与操纵器都是从咱们熟知的MVC框架中来的，要明白这三者是如何协同运作的，请看图3-1。
MVC最初的假想是将其用于传统的GUI应用，开发者们希望能够分离它们各自的表示，从而使保护和编写代码变得更易。
每一个概念或行为都能够在MVC框架中呈现，利用MVC就像在已放置好大梁的基础上建造摩天大楼，有了它，构建其他部份就变得更易了。
在开发应用的进程中，咱们将尽可能利用Rails为构建应用的搭脚手架的能力。
ROR也是个MVC框架，Rails为你的应用实施一个框架——开发模型、视图及操纵器。
作为分离的功能区，而且在程序运行时将它们联接在一路。
利用Rails的一个乐趣是那个联接进程基于一个智能的框架。
因此你不用去写任何外部配置就能够够让它们运作。
这是Rails“适应优于配置”哲学的一个表现。
在Rails应用中，送进来的请求最先传递给Router，Router用于发送和解析请求，最终，会在操纵器的某段代码中标识一个特定的方式（该方式在Rails中被称为Action行为）。
该行为会在请求中查看数据，还可能与模型交互，也可能使其他行为被唤醒。
最终，该行为为视图预备需要提交给用户的信息。
Rails如图3-2那样处置请求，在本例中，应用开始时呈现商品目录页面，用户只需点击位于商品隔壁的[AddtoCart]按钮，该按钮传递信息给，其中line_items是咱们应用中的一个资源，2是咱们已选商品的内部ID。
途径组件接收到送来的请求，并专门快将其分解。
该请求包括一个途径（/line_items?
product_id=2）和一个方式（该按钮执行POST方式，其他常见方式还有PUT和DELETE）。
在那个简单例子中，Rails取得了途径的第一部份——line_items作为操纵器名称，和product_id作为商品编号。
依照老例，POST方式与创建动作相关联。
（咱们将在267页谈到命名老例问题）
Create方法用于处置用户请求。
在本例中，该方式找到目前用户的购物车，购物车是由模型操纵的一个对象，接着它也要同时要求模型找到商品2的相关信息。
然后该方式告诉购物车自己添加商品2的信息（看到模型是如何被用于保留所有交易信息了吗？
操纵器告知应用去做什么，模型明白该如何去做）。
此刻购物车已将新商品包括在内，咱们能够让用户看看它了。
操纵器唤醒视图代码，但在此之前，它已为视图从模型中读取购物车对象做好了预备。
在Rails中，那个约定一般是隐性的，又一次，是约定帮咱们在视图和操纵器间成立联接。
关于一个MVCweb应用来讲，这已经够用了。
通过跟从约定和合理划分功能区，你将发觉代码变得易于扩展和保护，看起来是笔画算的交易不是吗？
若是MVC只是简单将你的代码划分为适当功能区，你可能会奇怪为何还需要ROR这么一个框架，答案很简单：
Rails为你包揽了所有琐碎的家务活儿，那些将占用你大量时刻的恼人细节，使你将注意力集中在应用的核心功能上。
让咱们来看看Rails是如何做到这点的。
支持模型
总的来讲，咱们希望在关系数据库上保留应用的信息。
定单实体系统将在数据库表中保留定单，在线商品及用户细节。
乃至那些通常利用非结构化文本的应用，如weblog及一些新闻站点，都会利用数据库作为它们的后台存储工具。
尽管一两句话无法说明操作数据库的SQL（结构化查询语言），关系数据库事实上是基于数据集理论被设计而成。
理论上讲这设计没什么问题，但它很难与面向对象语言结合在一路。
对象是关于数据和操作的，数据库关于值的集合。
在OO系统中，难以用代码表达的操作能够在数据库中轻松实现，反之，难以用关系数据库实现的，能够用代码表达。
随着时刻推移，人们发明了多种方式来整合这两种途径，来一起呈现数据。
让咱们看看Rails采纳了那种方式将关系数据库映射到对象上面。
对象—关系映射
ORM库将数据库表映射为各类类，若是数据库中出名为orders的表，咱们的程序就会有个Order类，表中的行与该类的对象关联，一个特定的定单表示Order类中的某个对象。
在该对象中，属性用于获取和设置表中的特定列，Order对象中有内部方式用于获取和设置账户信息、缴纳税金和其他操作。
另外，Rai
升级会员 