Github实战测试情况

##测试情况 很久没有熬夜测试程序了,经过测试,没有复现功能的有echo、葫芦娃、火鸡堂、那周余嘉熊掌将得队、为了交项目而干杯、修!咻咻!、云打印和追光的人。据汪老师反应在现场实践课程中大都能实现的,公平起见,将测试结果公布如下,望以上没我没复现成功能够解释原因,若在原有程序基础上能够复现成功,排除助教个人环境搭建错误的原因,按照测试通过积分,若无则按照未通过测试,基本功能实现得分在原有基础上乘以0.5

待就业六人组

很好的给出了错误提示功能,但是我没运行成功

提到的附加功能也没加载出来。如图所示

葫芦娃

界面看起来不错,但是如何加载聊天记录文件得到和博客中截图相同的结果,死活没找到怎么做。

附加功能都做出来了

SkyReach

实现了基本功能,附加功能设置的是通过有效发言的判定,改变用户中奖几率。看起来没那么炫酷,但是很有想法很实用的一项设计。

美中不足是一等奖和二等奖的人数写死了2个和3个,不能实现对一二三等奖获奖人数的自定义

Echo

界面很惊艳,在线测试没有给出结果。

附加功能采用本地脚本,实现了发言时间段统计和发言次数统计,运行结果和博客内容一致。

火鸡堂

看团队博客的发言,给人的感觉的是大神组长带不动的吐槽。规定的绝大部分本地功能没有实现。

基于云的胜利冲锋队

果断放弃了附加功能的设计,出色完成了基本功能的设计。并且开发流程完整,包括原型设计和逻辑设计,是测试环境最快捷的一个。但是美中不足好像是遗忘了附加功能的实际,毕竟在博客中很自豪的提到提前完成了**"作业的各项要求与程序的运行测试"** 属于学霸阴沟里翻船的类型。而且对于空白用户名,并没有考虑在内。 完整的令人看着很舒服的文件结构图

空白用户名没考虑在内

那周余嘉熊掌将得队

界面华丽,更令人惊喜的是有一个简单的苹果app

但是本地网络并没有运行成功

男上加男

效果很惊艳,美中不足是附加功能的设定较少

修!咻咻!

界面还不错,但是在测试过程中出现了异常抛出的现象。很遗憾没看到最后结果。

而且关键字的设置在活动管理和中奖结果生成界面重复出现

云打印

实现了基本功能,但是在在线测试中并没有出现海报,未看到中奖结果。

往期抽奖结果和邮箱通知中奖结果也是个亮点

追光的人

实现简单,但是我在测试的时候不知道哪个类是主类

为了交项目而干杯

界面看起来很美好,但是不知道哪里出了问题出现了这个结果。另外在博客中没有给出团队贡献比,贡献比结算按照每人0.1结算。

点赞
收藏

评论区

加载中...

相关推荐

MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1

文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s

Oracle 分组与拼接字符串同时使用

SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(

手写Java HashMap源码

HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22

distinct效率更高还是group by效率更高?

目录00结论01distinct的使用02groupby的使用03distinct和groupby原理04推荐groupby的原因00结论先说大致的结论(完整结论在文末):在语义相同,有索引的情况下groupby和distinct都能使用索引,效率相同。在语义相同,无索引的情况下:distinct效率高于groupby。原因是di

SpringCloud 启动时报No active profile set, falling back to default profiles default

这在Spring程序启动时没有找到默认的配置文件所引发的错误,默认文件application.yml如下图: !这里写图片描述(https://oscimg.oschina.net/oscnet/4a822ce35ff8ed227a2c57f496787d95e5a.png)一般在项目中都会有多个,如有正式环境、测试环境等。如下

Twitter的分布式自增ID算法snowflake (Java版)

概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移