1.基本任务
小组github地址:https://github.com/LongtermPartner/ExtendWordCount
PSP表格:
PSP2.1 |
PSP阶段 |
预估耗时 (分钟) |
实际耗时 (分钟) |
Planning |
计划 |
60 | 60 |
· Estimate |
· 估计这个任务需要多少时间 |
60 | 60 |
Development |
开发 |
720 | 720 |
· Analysis |
· 需求分析 (包括学习新技术) |
90 | 90 |
· Design Spec |
· 生成设计文档 |
20 | 20 |
· Design Review |
· 设计复审 (和同事审核设计文档) |
20 | 20 |
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
20 | 20 |
· Design |
· 具体设计 |
30 | 30 |
· Coding |
· 具体编码 |
300 | 240 |
· Code Review |
· 代码复审 |
60 | 60 |
· Test |
· 测试(自我测试,修改代码,提交修改) |
180 | 240 |
Reporting |
报告 |
180 | 180 |
· Test Report |
· 测试报告 |
120 | 120 |
· Size Measurement |
· 计算工作量 |
30 | 30 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 | 30 |
合计 |
960 | 960 |
接口的实现:
计数模块,由CountAndSort类中的parse函数实现,主要功能是对有效的输入文件进行读取并统计其单词词频。
由main函数调用,传入参数为输入模块分析得出的有效文件名,统计出各单词词频后,放入一个Map中(key为单词名,value为单词词频),返回值为此Map,供后面的排序模块使用。
测试用例的设计:
此模块共使用了20个测试用例,由于模块功能较少,既采用白盒测试覆盖各判定,又有黑盒测试, 包括:
>>字母与数字的组合
>>字母与各种常用字符的组合
>>短横线在字母前
>>短横线在字母后
>>短横线在单词中间
>>字母大小写是否对单词有影响
等各种情况。
每个测试用例针对性较强,且单词数不多,都不可缺少,能较好地满足测试效率的要求。
单元测试及其评价:
如图所示,对计数模块编写了测试脚本并进行了单元测试,20个测试用例通过。
此次测试根据需求列举了各种可能出现的情况,使这次测试可信度很高,且测试效率较高;
对被测模块,20个测试用例都通过了,在功能方面满足了用户提出的需求。
2.扩展任务
对开发规范的理解:
邹欣老师对代码规范和代码复审的讨论:http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html
(1)断行与空白的{ }行:
邹欣老师在博客中指出,为了程序精简、调试、结构清晰,尽量每个“{”或“}”都独占一行,即
if ( condition) { DoSomething(); } else { DoSomethingElse(); }
我认为这一点很容易被忽视,比如我由于个人习惯,经常将左大括号写在前一行,虽然没影响,但看上去可能没那么清晰。
(2)命名:
对于一个好的命名,尽量使用匈牙利命名法,且让程序员一眼就能看出变量的含义甚至类型,避免在使用中出错。比如对一个简单的int变量,我们最好不要直接用i、j、k这种简单但完全看不出含义的变量名,而应该用能看出其含义的命名,易于自己、他人阅读代码,弄清含义,可读性高,且可维护性好。
(3)缩进:
在Eclipse中,换行时会自动进行缩进,但是在编写代码的过程中不断的增加、删除还是会出现缩进格式不太整齐的现象。
根据规范分析小组成员代码:
对17067负责模块的代码,就以上标准进行分析。
断行与空白的{ }行、命名规范:较为标准,如wordsCount、valueComparator等变量的命名,都较为规范、易于理解。
缩进:有些地方的缩进格式较为混乱,不容易一眼看清层次,如
private int getInt(String key) { int i=0; try{ Pattern pattern=Pattern.compile("^\\d+"); Matcher matcher=pattern.matcher(key); if(matcher.find()){ i=Integer.valueOf(matcher.group()); } }catch(NumberFormatException e){ e.printStackTrace(); } return i; } };
静态代码检查工具:
PMD,在Eclipse中的安装方法如下
选择Help菜单项,选择Install From Site...,并点击add键,在Name一项填“PMD for Eclipse Update Site”,Location一项填
运行截图及扫描结果:
存在的主要问题如下:
(1)AvoidCatchingGenericException:即抛出异常时最好指定异常的类型,而不是直接用Exception类型。
改进方法:因为要对某特定异常进行处理,改为catch(FileNotFoundException e)。
(2)Avoid printStackTrace(); use a logger call instead.:即在catch中最好不要直接用e.printStackTrace(),如果不对异常进行处理,可以直接throw抛出,若要处理则用自己的方法处理。
改进方法:由于已经要对此异常进行处理,删除e.printStackTrace()即可。
(3)无用的括号:某些表达式里没必要加括号的地方多加了括号。
改进方法:去掉某些无用的括号。
(4)IfElseStmtsMustUseBraces:即if或else语句必须用大括号括起。
改进方法:用大括号括起,更规范。
(5)LocalVariableCouldBeFinal:即某些局部变量可以被定义为final类型。
改进方法:将某些变量设定为final类型,更安全。
(6)OnlyOneReturn:即在try里有一个return,外面又有一个return。
改进方法:去掉try里的return语句,将return语句放在外面。
小组代码主要问题:
代码没有太大问题,但不够规范,有些小问题,可以尽量改的规范一些。
3.高级任务
测试数据集:
如图,测试数据集使用了一个1600多行的文本文件test.txt,其中包含了各类单词。
处理时长:
如图,经过多次试验,处理此测试数据集的时间在300ms~400ms左右。
同行评审:
每位小组成员都作为作者、讲解员、评审员、记录员等身份进行了评审。
经过评审,我们得出结论:影响程序性能的主要因素是计数和排序两个模块,即计数时对单词的判定方法和排序的算法快慢。
实际测试:
通过测试,我们发现制约程序性能指标的主要因素是计数和排序两方面,即和同行评审结果相似。
软件开发、软件测试、软件质量的关系:
在本次实践作业中,软件开发主要是第一阶段,即基本任务的完成,而二、三阶段要对软件进行修改,再提交,即二、三阶段也能反映开发过程;而软件测试则是贯穿整个始终,在一、二、三阶段都有体现,也反映了软件测试的重要性;软件质量则是在各阶段一点点变好。不论是单元测试、静态测试还是最后的压力测试,都影响着软件开发过程和软件质量。
>>小组贡献分:
经过小组讨论,小组贡献分为0.29。