软件评测
这个作业属于哪个课程 | 2021春软件工程实践 | W班 (福州大学) |
---|---|
这个作业要求在哪里 | 软件评测 |
这个作业的目标 | 了解软件测评的流程 |
其他参考文献 | 《构建之法》、知乎 |
BUG量化指标:
严重性 | 说明 |
---|---|
★★★★★ | 系统安全漏洞,危害到用户的信息安全 |
★★★★ | 系统相关功能缺陷,某些模块无法使用 |
★★★ | 用户的数据产生异常,无法保证其正确性 |
★★ | 需要通过多次重新载入或是等待的方式,才能继续完成目标 |
★ | 略微影响用户体验,可以通过绕过该问题,完成既定目标 |
第一部分:调研和评测
CODE.CHINA
CODE.CHINA
是 CSDN 推出的开源代码托管平台,具备使用 GitLab 最新高可靠部署方案、独立第三方平台等特点,
1. 基本体验
- 登陆注册:
在注册的过程中发现,需要扫码关注公共号后再进行注册,过程有些许繁琐,但考虑到平台用户的留存率和活跃度,以及当代各大网站向公众号、微博等新媒体运营的大趋势,也是可以理解。
- 基本使用:
和大多数的代码托管平台一样,支持不同分支(Branch)上开发,变动以提交(Commit)来体现;对与分支的合并(Merge)则使用Merge Request功能。支持开发者以外的人Fork一个拷贝来进行修改;事项(Issue)则用来解决大家针对 项目所提出的问题,项目管理者在完成事项后关闭(Close)这些事项。
2. BUG描述
- BUG的测试环境:iPad Air4 Safari浏览器
- BUG的可复现性及具体复现步骤:
a. 步骤:点击导航栏,点击浏览项目进入项目广场,即可观察到star排序出错的现象
b. 可复现性:必然发生。采取网页刷新的方式进行20次测试,20次均出现以上情况,并在进行BUG反馈时发现已有用户对该BUG进行反馈,由此可见为必然发生。
- BUG的具体情况描述:
在使用的过程中发现项目广场上的star排序并不起作用,如图所示,最后一条的star数明显高于前面几条
- BUG分析:
a. BUG可能成因:目测应该是排序算法出现问题
b. BUG严重性:★
c. BUG的预期及改进建议:建议修改并优化排序算法
3. 结论
非常不推荐。
从功能的角度来看,CODE.CHINA
的功能模块十分混乱(例如导航栏的分类不太明确精准); 通过查看项目广场的Star、Forkr等的相关项目指标,会发现该产品上的项目并不多。通过使用发现该平台有部分是基于Github
的镜像,但这部分的内容貌似也不能满足相关需求。
GitHub
GitHub
是目前最大的代码托管平台,有人说它是业界标杆,总之就是很厉害的样子。
1. 基本体验
- 登陆注册:
登陆注册界面简洁美观,由于在此之前拥有GitHub
账号直接使用该账号进行登陆,在新设备进行登陆时,需要进行邮箱验证,保证了账户安全。
- 基本使用:
a. 登陆后,界面为英文,不支持中文切换,在使用上,对于英文不佳的用户并不友好。并且可以看到时间线上已关注用户的动态(不学习都觉得自己好罪恶,我哭);用户也可以看到历史浏览的项目,极大地便利了用户后续的直接访问。
b. 支持黑夜模式(深色模式),这一点还是不错的!
c. 在使用的过程中GitHub
的连接上有些不太顺畅,查询百度、CSDN等网站发现是由于某些特殊原因,因此在接下来的评测中忽略延迟的问题。
d. 和所有的代码托管平台一样,具有支持不同分支(Branch)上开发,提交(Commit)项目的代码变动;支持Fork一个拷贝来进行项目修改,然后通过pull request
来合并到原项目等功能。相比之下,GitHub
的界面分布、功能分类等指标就显得比较优秀了。
e. 支持第三方账户绑定,很好!
2. 结论
非常推荐
总体使用下来没有明显的BUG,扣分点主要就是连接不畅,在使用Git Bash
进行操作时总会error
和Timeout
,进行pull
、push
等操作的时候总是需要至少10次的反复操作(心累)。
Gitee
Gitee
是开源中国(OSChina)推出的基于Git的代码托管服务,拥有三个版本,分别是:社区版、企业版和高校版。
1. 基本体验
- 登陆注册:
支持第三方绑定,在注册的过程中由于Github
日常连不上,所以使用了华为账号绑定。
- 基本使用:
a. 在开源项目平台上可以看到分类多、涉猎广,从star数来看,用户量相对CODE China
来说比较大
b. 在单个项目的使用上,和前两个类似,在此不再赘述。
c. 使用过程中存在几大亮点,个人认为还挺有意思的。
i) 在.md
文件中有一个目录,可以迅速的找到想浏览的位置。
ii) 在统计的部分所规划的分类实用性很高。
2. BUG描述
- BUG的测试环境:iPad Air4 Safari浏览器
- BUG的可复现性及具体复现步骤:
a. 步骤:进入仓库,点击管理,点击仓库挂件,出现404情况。
b. 可复现性:必然发生。采取网页刷新的方式进行20次测试,20次均出现以上情况。- BUG具体情况描述:
点击仓库挂件,出现404
- BUG分析
a. BUG可能成因:由于查找资料后还是没懂仓库挂件是什么,所以这一点还没搞清楚。针对404页面,推测是错误类型提示这一块没有做好。
b. BUG的严重性:如果用户用到该功能则为四星,没用到则为一星。
c. BUG预期改进建议:错误提示应该进行详细分类和描述。
3. 结论
非常推荐
在具备代码托管平台基本功能的基础上,还是比较喜欢它的连接速度,在CODE.China
比较废,和Github
经常连接不上的情况下,真的是比较好的平台了,听说高校老师还可以批改作业,貌似还是挺棒的。
第二部分:分析
CODE.CHINA
1.开发时间估计
- 省去UI的原型时间成本计算
- 熟悉GitLab代码框架需要花费半个月的时间
- 在需求分析和数据库分析以及接口文档编写阶段,需要花费一个月的时间
- 在页面和接口的分工之后,完成第一版需要至少一个半月
- 进行网页相关测试和优化等后期操作则需要一个月
- 同类产品对比排名
和其他两款产品相比来说,CODE.CHINA
是排在最后一名的产品。实用的功能和模块不如Github
,虽然使用中文作为主体显示语言,但界面设计以及开源项目的质量与数量远不如Gitee
。
Github
- 开发时间估计
- 同样省去UI的原型时间成本计算
- 学习成本至少一个半月
- 在需求分析和数据库分析以及接口文档编写阶段,需要花费一个月的时间
- 在页面和接口的分工之后,完成第一版需要至少三个月
- 进行网页相关测试和优化等后期操作则需要两个月
- 同类产品对比排名
业界标杆,名副其实的第一。Github
的实力是毋庸置疑的,令人头疼的英文界面也可以通过网页自带翻译功能解决,虽然经常出现经常出现代码也一同被“贴心”的翻译情况。但它的连接问题是令我一直以来头疼的点,在关键时候掉链子,明明pull --rebase
接着push
之后就可以火速下班,偏偏卡在error,经常deadline或者急需要查询库的的时候直接卡住(累了)。
Gitee
- 开发时间估计
- 同样省去UI的原型时间成本计算
- 学习成本至少一个半月
- 在需求分析和数据库分析以及接口文档编写阶段,需要花费一个月的时间
- 在页面和接口的分工之后,完成第一版需要至少三个月
- 进行网页相关测试和优化等后期操作则需要一个月
- 同类产品对比排名
排在第二位。在我心里Gitee和Github不相上下,但考虑到其用户量和项目质量与数量等相关指标,Gitee还是存在很大差距的,因此只能位居第二。作为国内最良心的平台(相比Github
主要是快到飞起),结合了企业和高校的不同需求,进行针对性的功能设计,有自己亮点;页面布局和功能相对完善,虽然和Github
相比项目比较少,但总体来看还是可以看出团队有自己独到的想法与思考的。
第三部分:建议与规划
1. 市场概况
Q1: 市场有多大?
A1: 每个软件从业人员都是开源代码托管服务的潜在使用者,数量庞大,通过搜索有关GitHub用户量的相关资料获得了以下资料:
Q1: 直接的用户有多少?潜在的用户又有多少?
A2:
- 直接用户是从事软件相关的人员,根据工业和信息化部2019年发布的报告及多家线上外包服务平台的统计数据,《报告》指出,软件与信息服务领域从业者实际总人数约为900万至1000万之间。其中,有法人主体的软件和信息技术服务业从业人数为634.5万,基础级从业人员的数量至少为300万。
- 潜在用户是计算机方向或对计算机感兴趣的学生群体,通过知乎平台得知,每年计算机专业大学生新增约10余万人,可见用户量在不断增长。
2. 市场现状
Q1: 目前市场上有什么样的产品?
A1: 通过搜索资料得知,目前除了前面提到的Github、CODE.CHINA以及Gitee外。在开源代码仓库网站方面,还有GitLab、Coding、BitBucket等相关产品。
Q2: 上述产品的定位、优势与劣势在哪里?
A2: GitHub是面向全球开发者的平台,范围广、项目种类和质量都很优秀,但语言系统和连接问题使其在国内使用上有些许不便。相比之下CODE.CHINA以及Gitee虽然比较小众但由于其用户体量小因此功能更具有针对性。
Q3: 上述产品之间呈现什么样的关系,哪些为竞品关系?以及竞争中的各方态势如何?
A3: 总体来看GitHub业界标杆的地位是无法被动摇的,一骑绝尘。CODE.CHINA以及Gitee之间的竞争,我更看好Gitee。无论从UI设计、项目种类和质量还是使用感受来看,Gitee都是比较优秀的。
3. 市场与产品生态
Q1: 这个产品的核心用户群是什么样的人?典型用户是什么样的?学历,年龄,专业,爱好,收入,表面需求,潜在需求都是什么?
A1:
- 核心人群:需要通过需要线上仓库管理代码,并获取开源代码资料的人群
- 典型用户1:计算机相关的在校学生,表面需求是通过该产品完成课设编程,潜在需求是方便快捷地完成代码整合。
- 典型用户2:计算机相关的从业人员,表明需求是进行项目开发,潜在需求是压缩时间成本和加速项目开发进程。
Q2: 产品的用户群体之间是否存在一定的关系?是否有利用其相互作用二次构成特定用户生态的可能性?
A2: 第一类典型用户就业后,可能会成为第二类典型用户。学生时期使用的代码托管平台的体验会影响未来的典型用户2的选择。
Q3: 产品的子产品,以及其他相关产品之间是否存在一定的关系?是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性?
A3: 以Gitee为典型代表,高校版的使用会直接影响企业版的选择,产品的子产品会给其他子产品引流。
4. 产品规划
新功能:Github的语言系统
N: 目前大多数企业为让自己的产品国际化,语言系统是基本标配。Github作为全球开发者最常用的平台,庞大的用户量更需要一个健全的语言系统来优化用户的使用感受。
A: 根据用户的地域分布,对世界常用语言进行筛选。后期可通过问卷、后台反馈来增减语言种类。
B: 新增语言系统,不仅便利了老用户的使用,更减少了新用户进行初体验时由于语言不通或不熟带来的诸多不便,用户留存率和活跃度会大大提升。
C: 通过查找相关资料得知,目前比较主流的几大产品中,除了GitLab外,并没有出现能选择语言的功能,由此可见存在“商机”。
D: 由于Github已经占据了巨大的市场份额,所以减少广告等传统的推广方式,一方面在主页对语言系统进行推广,或在新用户注册时提供语言系统选项;另一方面可以通过邮件的方式提醒老用户新功能的推出。
针对新功能的团队规划
- 团队配置:
- 美工:1
- 前端开发人员:2
- 后端开发人员:2
- 测试人员:1
- 详细规划:
周数 | 说明 |
---|---|
1-2 | 新功能的需求分析 |
3 | 新功能的原型设计 |
4-5 | 进行系统设计和数据库设计 |
6 | 新功能的接口文档编写 |
7-10 | 新功能的Alpha阶段与集成测试 |
11 | 小规模发布新功能测试服并获取反馈 |
12-13 | 新功能的Beta阶段——优化与改进 |
14-15 | 新功能的Beta阶段——集成测试 |
16 | 新功能的公测 |