BugPhobia准备篇章：Scrum Meeting工作分析篇

特别说明：此博客不计入正式开发过程的Scrum Meeting篇章，只是工作的基础分析

前端

王鹿鸣、钱林琛撰写初稿

能否前端完成一个页面后就能在本地跑起来进行测试？
能否在前端和后端完成对接后单页面式的进行测试
充分利用JS的能力，将页面尽可能动态化

• 主页面

  • 头部菜单栏：移植到ReactJS，将登录和注册功能直接整合到菜单栏是最好的。
  • 标签云及搜索栏移植：将标签云和搜索框整合到ReactJS中。
  • 优化标签栏：移植并保证标签栏也能够点击，如果能在标签栏部分增加个性化推荐最好（后半部分不要求）
  • 优化推荐栏：移植并保证推荐栏正常实现，用户能够通过Approve和Change按钮进行更换和确定

• 用户页面

  • 移植Activity页面作为用户页面的主要页面。
  • 重新整合Profile页面和Activity页面：将Activity页面设为主页面，调整用户关注的问题及推荐的问题到显著位置。
  • Profile页面：将此前优化后的用户实体信息铺展在此页中，注意要关联用户的活跃状态（问答数、关注标签数等）
  • Profile页面：优化用户的个性化推荐，保证推荐给用户的Tags能够较为显著展示出来
  • Profile页面：重新布局Course和Question的推荐，尽可能简略反馈给用户
  • Activity页面：将用户的全部活动状况以“消息”的方式反映在用户活动栏（类似空间、朋友圈那种模式即可）
  • Activity页面：将用户关注的问题、回答、@、标签展示出来，注意增加（分页设计即不要一大堆内容直接push开来）
  • Settings页面：同Profile页面的用户实体，
  • Settings页面：增加【用户贡献】页面，贡献包括数据贡献（爬取数据，可选实现），资源贡献，回答数。
  • 【用户贡献】页面：允许上传资源。

• 搜索结果展示页：

  • 不再链接到原URL，尝试将问答对直接展示在我们的页面中。
  • 无法搜索到结果时一定要返回一个未搜到相关内容的页面，而非“空”
  • 对Like、Ask、Upload等功能按钮进行完善
  • 搜索结果分页处理，而非大量内容直接直接铺陈开来（用户能够规定每页的显示数目）
  • 对用户上传资源的文件名等进行搜索。

• 课程页面

  • 课程页面进度暂且搁置，根据数据组的行动进行进一步的设计

• 问答页面

  • 划分问答页面基本层次：提问页面和结果页面是否分离（不分离：QQ空间的做法；分离：stackoverflow的做法）
  • 实现问答对的展示
  • 实现回答问题
  • 提问页面，允许用户提出问题。

• Robot页面

  • 扩充知识库
  • 给出基本的操作方法（示意图给出即可，类似功能规格说明书的模式）

• FeedBack页面

  • 转移，放到显眼的部分，而非找半天找不到此页面
  • 允许给评论添加标签（此标签由开发者规定：吐槽，评论，BUG反馈等类似标签）

后端

冯志睿、王文基撰写初稿

总体说明

对于后端的任务，我们可以从以下的几个角度来看：

角度1：模块角度

• 用户管理模块
  • 基本信息
  • 活动记录信息
    • 记录收藏的标签、问题和课程等
    • 针对用户记录的推荐
  • 社交拓展信息
  • 文件信息
• 搜索管理模块
• 问答管理模块
• 课程管理模块
• 扩展模块

角度2:前端和接口角度

针对前端任务列表和接口说明来看任务需求。

这两个角度前者可以说是从功能角度来看的，后者是从团队配合的依赖和需求角度出发的。这两个方面在决定任务的划分、分配和时间节点安排时都非常关键，下面将对任务进行细分，给出相关的难度系数（一个 “！” 大约3~6个小时），同时给出相应的理由，供PM参考决定时间节点的安排。

---

任务详细剖析

• Beta后端结构重设（！）
  • 根据功能模块设计后端结构
  • 将已有的各个子应用调整到新结构中的相应位置上面
  • 给待开发的模块建立子应用

该任务的优先级是最高的，建议尽快安排该任务。因为后期的重构面积比较大，同时根据Alpha阶段的源码路径来看存在较大的“泥球”，所以重构很迫切。同时虽然该任务的技术细节基本没有，实际操作起来不存在bug问题，但是需要明确功能模块设计结构，从而明确各个后端开发者的负责区域，会让人有“选择困难症”的表现，还是建议讨论一下~

• 用户管理

  • 后端对新架构的适应（！）
    • 在后端给注册登录等补上验证（Alpha只做了前端验证，后端验证没有做全）
    • 根据接口文档上面的接口要求将数据准备好
    • 统一一下相关的代码（Alpha的有点乱）
  • “Read Later”功能，就相当于收藏、喜欢、关注，同时做一个推荐（！！）
    • 针对接口需求封装Json数据，并实现接口
    • 需要对标签、对问答、对课程都设置相关操作
    • 由于我们的系统用户基础数据不多，所以相当于“冷启动”，所以我们的数据分析不是建立在用户上，而是建立在内容上的相关性
    • 根据用户的收藏和喜好，将相应的推荐内容找出来
  • 社交网络第三方内容（！）
    • Oauth第三方登录
    • 一键分享推广（之间通过JS就可以完成，可推到QQ空间、微博、朋友圈、Facebook、Twitter、Linkin等等）
  • 简化的百度文库形式（！！）
    • 上传
    • 对上传内容进行分类管理

• 搜索管理

  • 实现搜索结果信息的反馈（！）
    • 将结果封装成接口对接数据
    • 做好分类，因为问答数据、课程数据（站内和站外数据也会产生区别）等等都是来自不同的地方用不同的结构存储的，最好分别实现操作。

• 问答管理

  • 问答数据展示（！）
    • 涉及0x0500-0x0510接口的功能实现
    • 由于这些问题都是读取数据库的操作，所以直接放到一起完成
    • 相关的数据库安排也在此任务项之下
  • 操作数据处理（！！）
    • 从0x0514（提问）后面的操作都需要对数据库进行插入和修改操作，所以作为一组。
    • 需要有记录用户行为的数据库，需要与用户管理方面关联
    • 需要有celery的学习安排

• 课程管理

  • 接口数据的封装（!）
  • 用户对于课程的操作（！）

• 扩展

  • robot（！）
    • 其实聊天返回的类型有很多种，Alpha只是将内容展示出来了，其实还有很多相关链接，这次都要展示出来。
    • 根据功能方案完成数据库的类型需求分析

大致的任务情况就是这样，具体时间安排其实还得看看每天有多少时间能够抽出来，以及编码效率问题

测试

李云涛撰写初稿

Beta阶段测试工作分类

Beta阶段在延续Alpha阶段测试计划的基础上稍有改进，主要测试任务分类如下：
从测试类型上，Beta阶段测试工作主要分为以下三种：

• 脚本型功能测试
  用于持续测试各模块功能是否正确执行。主要方式是，使用脚本模拟用户正常使用时发出的各种请求，发送给网站，匹配返回结果于期望结果是否基本一致。由于功能尚处于添加阶段，因此脚本也将不断进行扩充。

• 手工测试
  人为测试功能实现是否正确，针对部分敏感功能进行白盒测试或灰盒测试。测试前端在不同平台上的显示是否正常以及对人的动作响应是否正常。

• 脚本型安全性测试及性能测试
  用于持续测试网络的健壮性和鲁棒性。对于安全测试中的sql注入，每天会使用sqlmap对所有注入点进行尝试注入，如有注入成功的情况则反馈bug。对于性能测试，使用load runner模拟用户的持续并行访问。本阶段测试暂时忽略跨站攻击的测试，但是在代码复审中会着重审核阻止跨站攻击的代码是否正确。

Bug反馈机制

对于测出的Bug，执行如下反馈机制以保证修复的及时：

• 在测试出现Bug后，使用issue的方式将Bug反馈至github和team@osc
• 将Bug指派给响应组的开发人员进行修复
• 修复完成后创建新的任务重新测试，若测试不通过则继续反馈issue