个人作业-软件测评

这个作业属于哪个课程	2020春W班
这个作业要求在哪里	作业要求
这个作业的目标	学会软件测试、评测、调研
作业正文	作业
其他参考文献	...

一、调研、评测

测试

微信小程序

• BUG一：修改群昵称后，群信息仍为原来昵称

  

  详细描述：在群信息页面进行群昵称修改，点击“确认修改”后不会跳转回群信息页面，这样设计对于使用者并不是很友好，因为使用者没有获得任何反馈，不能确定是否执行命令。在主动返回群信息页面后，显示的群昵称仍为原来的群昵称（实际上此时已经修改完毕，重新进入群信息页面才会显示修改后的昵称），这样很容易误导使用者。
  为什么开发人员没发现这个问题：我个人认为是因为开发人员太过于专注功能（修改数据库中的昵称）的实现，而忽略了交互的友好性。也有可能是原型设计时的疏忽了“确认修改”按钮的功能设计，而导致后续的开发人员没有去实现。

• BUG二：群消息发送后仍然存在输入框中
  

  详细描述：在输入框中输入信息，点击发送按钮后，在输入框中仍然存在发送了的消息
  为什么：开发人员在完成发送请求的工作后，疏忽了改变输入框控件的text字段。

• BUG三：在搜索群聊时，没有显示结果
  

  详细描述：在输入框中输入GroupID后点击搜索没有显示候选结果，虽然说通过groupid搜索得到的群聊都是唯一的不存在多个的情况，但是可能存在使用者输错id的可能性，显示候选可以让用户判断是否是自己想要加入的群。

  为什么：同上

web

• BUG一：创建的群聊无法邀请人加入

详细描述：在自己创建的群聊无法邀请新的群成员加入，但是修改群名称、发布公告和修改添加方式等管理员行为却能正常使用。

为什么：能使用发布公告等群管理员才能使用的功能，说明我的操作权限应该是群管理员权限，但是在错误提示中却出现“普通成员”。说明在数据库中可能存在两处地方涉及群成员权限的存储，并且在发布公告和添加群成员时查询了数据库中不同表的数据。我的个人猜测，在创建群时，在群表中存有创建者，可想而知群创建者拥有群管理权限。同时，群创建者也作为群聊天功能参与者之一，也属于一个特殊的群员，那么在创建群时作为被邀请加入者参与加入群功能的执行，而邀请者为错误信息中提到的App管理员，这个功能可能使用了一般群员被邀请加入群的功能，默认值可能为一般群员权限。故群信息表和群员信息表中的权限信息不匹配。

• BUG二：没法添加好友

详细描述：在好友界面没有添加好友的功能入口，而在群聊里也没有添加好友的功能。

为什么：开发人员没有对这项功能进行开发

Android

• BUG一：昵称在两个昵称间反复横跳

详细描述：在修改了两次或者多次昵称之后，再次点击修改昵称按键，进入修改昵称页面，不做任何修改点击确认修改之后会修改为另一个昵称，重复上述操作，昵称在两个昵称之间反复变换

为什么：

• BUG二：没有加入黑名单功能

详细描述：在个人信息页面没有加入黑名单功能

为什么：开发人员没有对这一功能进行开发

采访

采访对象的背景：高校在读大三女学生

需求：

• 方便快捷
• 消息能够及时收到
• 能够有像紧急联系人这样的功能

腾讯即时通信IM体验：

优缺点：
* 在群聊接年的一些按钮阻挡了其他信息
* 聊天中无法点击自己的头像
* 聊天信息发多了，就会有滞后性，反应有点慢
* 对话框宽度小
* 语音发送停了，还在录音
* 小程序无法修改头像

建议：
* 增加直接点击头像更换头像
* 发起绘画页面添加好友id以供选择
* 添加邀请其他成员入群的功能
* 群公告信息应发布在聊天界面中
* 群员进群自动提醒群公告
* 添加字体大小设置

结论：不推荐

用户对我想开发的产品的意见：做好安全监控，预防诈骗、欺骗事件。

分析

团队人数大约六人左右，计算机大学毕业生，这个SDK做到这样的程度大约需要7~8周的事件。

（与网易云信网页版比较）
从界面上来看，界面对于用户而言都是相当友好的；在美观程度上，两者各有千秋，可以说是不相上下。
在基础功能的实现上来看，网易云信的基础功能实现地相当完全，满足了用户的基本需求，且没有明显地Bug；但是腾讯即时通信IM的功能实现的就没太过完善，有些功能没有实现，而且存在一些Bug，在逻辑上可能也存在一些漏洞，网易云信在这方面来说更好一些。单单从我在对两个demo的十分钟体验中，网易云信的用户体验相对较好。

个人建议：

• 开发人员都去体验一下使用自己开发出来的demo，思考一下自己的那部分工作有哪些可以优化的，或者说跟其他部分的开发人员之间的沟通是否完全理解；
• 还有数据库结构是否存在可以优化的地方。

建议和规划

我想要利用该SDK开发的产品为：一款进行匿名聊天功能的app

主要功能有：

• 匿名与他人进行交流，能够从app中得到的信息只有该用户的昵称
• 举报用户功能
• 删除现有聊天功能
• 匹配网友聊天功能
• 限制匹配的网友数量
• 随机分配昵称，可以主动变换昵称

产品主要面向的用户为：学生、青年用户

N-Need 需求

有的人想找人说话，但碍于身份
有的人想跟人分享自己的秘密，但却不能对身边的人说，积压在心底
有的人有很多的烦恼想要发泄，却不希望破坏朋友关系，而作罢
就以上而言，匿名交流是由需求的

A-Approach 做法

完全匿名，能够从app中得到对方的信息只有昵称
没有搜索功能，没有针对性的交流
随机匹配，相识即是缘分，且行且珍惜
每隔一周，清空所有聊天信息
每隔一周，随机分配昵称

B-Benefit 好处

用户可以畅所欲言（正当的发言），不用担心又被认出的风险，每周清除交流信息，不用任何的负担，用户可以放心的交流，发泄心中的烦恼、郁闷，向别人吐露心声。

C-Competitors 竞争

优势：符合当代快餐文化的潮流，信息流动很快，人们接受的信息也很多，同时也需要将一些信息发泄出去，我们的产品就是一个很好的选择。市面上也存在一些匿名交流的软件，但是它们要么是在自己认识的圈子内匿名，存在被认出的风险；要么是在一定地理位置内的，也容易暴漏自己的信息。
劣势：现在市面上的产品积累的经验丰厚，并且做出转变跟我们产生竞争也相对容易、迅速。

现在市面上有的同类产品有：QQ的漂流瓶功能、匿名群聊功能，Soul，一罐等。
我们的产品优势在于，我们的聊天都是完全随机的，不存在任何的目的性，像Soul和一罐是通过各种条件对比匹配的，或年龄相近、或兴趣相投，并且匹配的都是异性，soul的定位是寻找生命中的另一半。QQ的匿名群聊也局限于一个群内，有被猜出身份的可能，QQ的漂流瓶捆绑于QQ邮箱，而邮箱又很少使用，用的也大多是市面上的其他邮箱，所以能够吸引的用户很少，且定位不同，竞争关系不算激烈。而我们的匹配时没有任何条件的、完全随机的。我们瞄准的时广大青年朋友的好奇心，它们想体验不同的身份，了解不一样的生活，探寻不同的人生。

团队配置：美工一人、开发三人、测试一人

开发时间安排：
第一周：需求分析
第二周：原型设计
第三周：软件体系机构设计，数据库结构设计，以及编写项目规范
第四周：接口设计，编写说明文档
第五到十二周：软件开发
第十三到十六周：软件测试及修复，优化

部署：

应用服务器配置：4核 8G*2
关系型数据库：Mysql（读1、写1、备份1）
缓冲数据库：Redis（主1、备1）
网站安全性：WAF、DDOS