WordCountPro小程序
WordCountPro小程序
基本任务
1.githu地址
https://github.com/JarrySmith/WordCountPro
2.psp2.1表
PSP2.1 |
PSP阶段 |
预估耗时 (分钟) |
实际耗时 (分钟) |
Planning |
计划 |
5 | 5 |
· Estimate |
· 估计这个任务需要多少时间 |
5 | 5 |
Development |
开发 |
150 | 120 |
· Analysis |
· 需求分析 (包括学习新技术) |
10 | 5 |
· Design Spec |
· 生成设计文档 |
5 | 5 |
· Design Review |
· 设计复审 (和同事审核设计文档) |
5 | 5 |
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
5 | 5 |
· Design |
· 具体设计 |
5 | 5 |
· Coding |
· 具体编码 |
90 | 80 |
· Code Review |
· 代码复审 |
10 | 5 |
· Test |
· 测试(自我测试,修改代码,提交修改) |
20 | 10 |
Reporting |
报告 |
30 | 15 |
· Test Report |
· 测试报告 |
10 | 0 |
· Size Measurement |
· 计算工作量 |
10 | 5 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
10 | 10 |
合计 |
185 | 140 |
3.接口实现
我在这里负责开发的是核心处理模块,该模块的功能为读取出文本中的内容后对文本中单词分割,并统计它们的词频。具体接口设计如下:
Class WordCount 方法: 1.public Map<String,Integer> wordCount(String path) { String context=readFilecontent(path); processString(context); //外界调用这个方法,最后返回一个map容器,里面装了单词和相应的词频 } 2.public Map<String,Integer> processString(String context) { //遍历char Of Context进行处理 } 3.public String readFilecontent(String path) { //一次性读取出path指向的txt文件的所有内容,并以String形式返回 }
我所负责的模块中有三个函数,当需要用到核心模块的功能时,外界会直接调用里面的wordCount函数,得到一个装有单词和词频的map容器实例。wordCount函数会先调用readFilecontent函数,传递文件的路径进入函数,然后来读取文件中所有的字符,装入一个String变量中返回。再将这个变量的内容作为参数传递给processString来处理这些字符。processString函数会一个个读入String里面的内容,然后分析是否是单词,当是单词时记录,并存进map中,如果map中已经有相应的单词了,则对应的词频加一,最后返回这个map容器。
具体代码请见github内
4.设计测试用例
20个测试用例如下:
在进行设计用例测试时,首先设计时可以看到wordCount函数只有两句调用,属于简单代码,没有太大必要进行单元测试,所以单元测试的重点在于另外两个函数的测试。
对于readFilecontent函数,首先要对这个函数功能进行测试的话,先进行了传入正确的绝对路径和相对路径读取的测试,之后进行异常值的测试,输入空的或者错误的路径时,会抛出FileNotFoundExcetion,捕获异常后对其查看来判断是否通过单元测试。
对于processString函数,进行了较多的14个测试,会读取出14个不同文本的内容,测试这14个文本进行单词计数时结果是否正确。会进行-在单词的前后中时是否计数,数字是否进行计数,常用符号是否计入,异常符号是否计入,单词缩写时的单词计数,用tab、空格、换行符分隔时单词的计入等14个情况。基本覆盖了作者所能找出的所有正确、异常值的测试。
5.单元测试结果
最后编写好了测试用例后,采用Junit框架来实现单元测试,具体测试代码请见github内,测试结果如下:
测试结果评价:
测试的用例基本覆盖了可能出现的输入情况,但是在对processString函数进行单元测试时,有部分测试用例对一些输入情况进行了重复测试,具有一定的测试冗余。被测代码通过所有的测试用例,测试情况较好,被测代码符合预期要求。
6.小组贡献分
经过讨论,本人在小组中的小组贡献分为:0.23
扩展任务
1.开发规范
由于我们小组使用了java进行开发,所以采用的是《阿里巴巴java开发手册》中的开发规范,理解如下:
《阿里巴巴Java开发手册》中指出:【推荐】如果模块、接口、类、方法使用了设计模式,在命名时体现出具体模式。 说明:为了达到代码自解释的目标,任何自定义编程元素在命名时,使用尽量完整的单词组合来表达其意。
个人体验:在对变量名进行命名时,如果使用简单的a、b、c之类的变量名命名,在使用时会出现使用不明确的情况。在进行测试和重构时候更是如此,有时需要花费额外的大量时间来重新理解代码内容。
2.交叉分析
我对学号U201517088的同小组成员的代码进行了代码规范的分析,分析的标准参考的是《阿里巴巴java开发手册》。
该成员进行的是输出模块的代码开发工作,对其类outputProcess分析后发现:
一、其覆写的方法compare()没有进行覆写的@override注释编写
二、使用了尾行注释。
三、String类型在扩展时,应使用Stringbuilder的append方式扩展
使用静态工具分析结果如下:
该成员其他代码部分基本符合开发规范,全部代码约40行,简洁易懂,采用覆写方法也便于理解不同情况下对compare方法的调用。
3.静态分析
因为我们采用的是《阿里巴巴java开发手册》中的开发规范,所以使用了Alibaba Java Coding Guidelines这一工具对自己的代码进行静态分析,经过分析后的结果如下:
4.改进代码
经过和小组成员的讨论后,对之前发现的问题进行了改进,发现的问题和改进方法如下:
一、else后面有地方没加大括号,这里应该将单行的代码也用大括号括起来。
二、使用了未定义的常量,这里用一个定义final常量再对常量进行使用。
三、未添加作者信息,之后应在.java文件前加上作者信息。
四、使用了尾行注释,应另起一行。
五、在判断语句中输入了复杂的条件,这里应在前面定义一个boolean型变量,将boolean变量放入判断条件中。
六、HashMap没有指定初始化大小,这里分析了我们进行测试的用例,取了一个满足较多用例的中间值作为初始化大小。
改进后的代码使用Alibaba Java Coding Guidelines进行静态检查后结果如下:
可以发现,此时代码已经通过了静态检查。
5.小组代码评价
组内成员代码在静态分析上都或多或少的找到了一些文件,比较通有的问题是写了尾行注释和缺少对代码描述的注释,使得在阅读代码时候没有那么清晰。
高级任务
1.测试数据集
程序主要花费的时间的地方就是进行对文本统计判断,为了进行压力测试,统计文本的txt文件应足够大,采用了一个12.5MB的txt文件来进行测试。
2.优化前程序性能指标
性能指标为:在对txt文件进行测试时应在5s内完成统计。3.同行评审过程
由全体组员参与,组员徐江南主持,所有人一同评审小组的全部代码。
经过讨论,一致认定
1.在循环内定义变量会增加额外开销,建议将变量提出。
2.删去输入类中方法内对非法字符的判断不影响程序功能,而且能增强性能。
4.优化设计思路
在对认定的问题进行处理后,即将变量提出循环,删除合法字符检测后,程序效率大约提升了20%,与同行评审的结论一致。
5.作业小结
从基础功能到拓展功能到高级功能,可以说软件测试贯穿了软件开发的整个流程,同时软件测试也抱着了软件质量能达到基本要求。如果没有进行基础功能时候的单元测试,或许在进行接下来的开发时会发现一个一个原先认为的功能不完善,导致WordCountPro的质量变差,而且增加了开发的时间周期。可以说软件开发、软件测试、软件质量是互相联系的。想要做好软件开发,就要做好测试。想要达到好的软件质量,就要在开发时进行优化、测试。同时软件测试后不对软件进行维护、或者继续开发的行为,软件质量也无法保证。