代码改变世界

omiga——凡事预则立

2019-12-23 16:52  omiga  阅读(377)  评论(0编辑  收藏  举报

一、GITHUB地址

github地址链接

二、针对之前提到的问题进行思考和总结

前述总结:对于先前在项目中所遇到的问题可以根据三个开发的阶段进行分类。在项目进展工作的第一阶段,我们小组主要讨论的问题是针对于项目需求而进行的功能选择。主要体现的问题以因爬虫技术对网络图书资源信息进行获取而省略了有关数据库的使用。在项目进展的第二阶段,主要讨论了有关于项目前端选用的框架问题和后端功能的实现。集中于如何完成阶段一提出的需求。在项目进展的第三阶段,小组之间讨论的问题主要集中于如何在算法方面优化原有的功能,使得程序运行的效率在一定程度上得到更好的提升。

下面对各问题的思考进行提炼总结:

(1)在第一阶段改用爬虫技术获取图书信息资源替代原计划的数据库打算,部分成员的在团队中的工作重心转移至前后端功能代码的实现

(2)在第二阶段的前后端框架问题的选择:小组成员讨论的两种前端框架python flask 和 Dijango中进行选择,考虑到django遵循MVC的框架模式。在django框架中,控制器接受用户输入的部分由框架自行处理,是一个高水准的Python语言驱动的一个开源模型。这符合我们前期工作讨论中选择的语言。因此采用这个Dijango的框架进行开发。项目进展到第二阶段中期后,有小组成员提出采用PHP进行后端的开发,考虑到程序的框架已经具备雏形,改换语言将导致大量的人力浪费并且有部分小组成员对PHP开发后端并不熟悉,因此不采用该建议。

(3)在第三个阶段中,我们的主要问题在于讨论如何优化功能和改进算法,使得小程序能更加完善。具体体现在如何优化图书查询的算法以及预约功能中的模块添加。在讨论图书查询算法中,我们打算建立哈希索引对查询算法进行优化。与此同时SQL Server提供了一种简化并自动维护数据库的工具。这个称之为数据库维护计划向导(DMPW)的工具也包括了对索引的优化。还可以在DMPW中选择重新组织数据和数据页,这将停止旧有索引并按特定的填充因子重建索引。虽然不使用数据库,但数据库的查询思维可以被我们优化算法借鉴。

三、需要改进的团队分工

(1)团队前期主要面临的问题是分工的问题。我们开始的分工没有考虑到每个人的擅长的方面,所以基本上只是一股脑地将每个任务平均分配给每个人。这就导致了一部分同学对于该部分不擅长而最终到达DDL的时候交出不成果,即使交出了也不尽人意。因此我们团队认为任务分配方面是改进的核心,组长需要根据每个组员的情况尽可能各尽所长。比如有的同学就是不擅长写代码,但适合组织队员,适合写材料,那么在分配任务的时候应该着重分配到其擅长的部分,这样团队才能更加高效。
(2)分工的时候对于代码的提交我们团队都是统一放到GitHub上,这导致了在虽然每个人在各自电脑上测试都没有问题,但一合并则漏洞百出。一方面和我们前期的接口定义不够清晰有关,另一方面也和团队之间缺少沟通有关。后来老师有提及到issues的功能,在后面我们慢慢学会使用issues,如果能够早些使用这些功能,那么即使不见面也能够更好地交流。
(3)团队分工方面的组织纪律还需要加强。我们很多时候有些组员即使超过了DDL但是顾及同学情面也不会有很重的批评,大多是讲两句了之,但是这样造成的一个后果就是容易让这种情况再次发生。我们认为最好的还是组长要制定严格的纪律,可以不用是批评,而是可以超过DDL最晚的同学需要请小组成员请一顿饭,这样子也能够督促大家按时按量完成任务。 

四、团队的代码规范

(1)组件文件
所有组件相关文件统一放在components目录下。
(2)图片文件
项目图片文件放置于根目录的images文件夹下,组件独有的图片放在当前组件images目录下
(3)模型文件
模型文件主要用于编写各类业务模型。项目模型文件放置于根目录的models文件夹下,组件相关模型放置于components目录下的models文件夹中。

(4)行为文件
行为文件放在所引用的组件目录下。

(5)注释规范
除组件外的其他块级元素,均需注释出其功能,并在其上下空出一行与其他代码进行区分。

<view>...</view>

//导航栏
<view>...</view>

<view>...</view>

(6)WXML规范
控制每行HTML的代码数量在50个字符以内,方便阅读浏览,多余的代码进行换行处理,标签所带属性每个属性间进行换行。
 (7)CSS规范
在开发过程中rpx和px均可能用到,如通常情况下间距使用rpx,字体大小和边框等使用px,开发者根据实际情况而定。
(8)JS规范
变量名以及函数名统一采用驼峰命名法,正常情况下函数名前缀需加上清晰的动词表示函数功能,私有函数或者属性以下划线开头表明。常量需用const 声明。类的命名首字母需大写。采用ES6 关键字let定义变量,尽量不使用var

(9)组件名命名规范
组件在使用时命名以 “v-”为开头的组件名,若组件名称为多个单词名拼接而成,采用 ' - ' 连接。组件标签在page页面使用时推荐使用单闭合标签(此条约束对于包含有slot的组件无效)

 

五、测试工作安排

我们将测试工作安排分为三个阶段,在临近期末时针对三个阶段对应的功能安排人员分别进行测试,测试表格如下所示:

 

 

 测试工作概述:

(1)基本测试

输入、输出:用户上传的材料、描述,登录时输入的用户名、密码等;
边界值测试:黑盒测试,确定测试域,对具体测试点进行等价类划分,确定上点、内点、离点,进行较为全面的测试;
页面交互:页面与页面之间跳转、点击、下拉、翻页等;

(2)兼容性测试

Android:程序运行于X5内核;

IOS:程序运行于JavascriptCore;

微信版本的不同,小程序开发所提供的API库也不同,在测试的时候选择测试小程 序能支持的最低微信版本,选择最低版本以上的所有版本对Android系统和IOS系统分别测试;

(3)安全测试

安全测试是接口测试;

接口测试一般测试传递数据是否安全,身份信息是否加密等方面,由于微信小程序是内嵌于微信平台的应用,微信的安全系数极高,所以安全测试可以忽略。

 (4)性能测试;

页面的渲染时间:Javascript前端各种动态效果的加载时间;

白屏:页面打开响应的时间;

注:微信测试 时可以忽略测试仪器的屏幕大小问题,原因是微信小程序重新的定义了一个新的单位尺寸:rpx,微信小程序把页面分割哼750份,1rpx=1/750,自定义适配屏幕。

(5)易用性测试:
微信的提示信息,操作是否能够让从未培训过的用户会使用。

(6)测试流程:

 

 

 

六、测试工具的选择和使用

采用 Trace 工具 :利用trace工具可时时监控小程序的性能。分析trace文件可获取内存、CPU、fps、启动时间、各函数的执行时间等

七、测试用例的文档PDF和github链接地址

测试用例的PDF和GITHUB地址

八、项目测试评述

1、测试结果评价:

(1)对于八项基本功能:登录、借书、查书、还书、增书、删书基本完成,但查书算法的优化程度方面没有达到我们预期的目标,对于哈希索引的建立和使用我们并不是十分熟练。除此之外,界面设计较为合理,也有一些附加功能在其中,整体运作较为流畅。

(2)设计合理,操作简单,思路清晰。

(3)能够批量添加书籍,交互友好,响应速度快。

(4)对于一些非法输入,错误输入和不合理输入具有相应的检测与判断措施。

(5)团队合作意识较强,解决突发问题能力较高,具有较好的沟通能力等。

2、需要改进的地方:

(1)对于程序最开始运行时,可以考虑将账号密码隐藏。

(2)在查询书本时,对于空栏需要更加规范,本系统中查询时未输入内容可查询到书籍。

(3)在管理员界面里面,应该加入学生书本借阅记录。