软件测试第四周作业WordCount优化

1.小组github地址：https://github.com/whoNamedCody

   小组成员：17048冷福星   17050李慎纲  17039付佳韵  17040康之是

2.psp表格：

 

PSP2.1	PSP阶段	预估耗时 （分钟）	实际耗时 （分钟）
Planning	计划	30	20
· Estimate	· 估计这个任务需要多少时间	30	20
Development	开发	245	255
· Analysis	· 需求分析 (包括学习新技术)	15	20
· Design Spec	· 生成设计文档	30	30
· Design Review	· 设计复审 (和同事审核设计文档)	20	15
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	20	20
· Design	· 具体设计	20	20
· Coding	· 具体编码	60	60
· Code Review	· 代码复审	20	20
· Test	· 测试（自我测试，修改代码，提交修改）	60	70
Reporting	报告	130	120
· Test Report	· 测试报告	50	50
· Size Measurement	· 计算工作量	30	30
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	50	40
	合计	405	395

基本任务：

　　（1）接口实现：

　　　　本次小组作业中我负责的是输入控制的模块。和负责核心功能的同学商量后约定好我需要写的输入控制wcinput class中：input()函数读取命令行参数，在input（）函数中进行判断，不符合要求的输入会提示重新输入并退出；符合要求的输入会作为input（）函数的返回值传递给核心模块。

　　　　具体实现过程：

　　　　　　a.先判断输入命令行参数是否为空。

　　　　　  b.再判断命令行参数个数是否大于1（要求里只接收一个输入文本）。

　　　　　　c.对命令行参数判断完成后，判断输入参数是否符合形式规范（.txt）.

　　　　　　d.对符合形式规范的输入，判断是否为存在的txt文件。

　　　　　　e.筛选得到的正确输入作为作为返回值，返回给核心模块

　　（2）测试用例设计：

　　　　白盒测试：应用对路径的测试，程序中对输入的命令行参数进行了4次二分判定，圈复杂度为5

　　　　

　　　　测试用例设计分类为：

　　　　　　　　　　　   a.1-2-10

　　　　　　　　　　　   b.1-3-4-10

　　　　　　　　　　　   c.1-3-5-6-10

　　　　　　　　　　　   d.1-3-5-7-8-10

　　　　　　　　　　　   e.1-3-5-7-9-10

　　　　覆盖了input()方法中所有的路径。

 

　　　　黑盒测试：使用划分等价类和边界测试的方法。

　　　　　　（1）有效等价类：命令行参数为xxx.txt，且该txt文件确实存在

　　　　　　（2）无效等价类：输入的命令行参数为空；输入命令行参数内容为空（多个空）；输入多个文件；输入无效非txt文件；输入不存在的txt文件；

　　　　　　（3）边界测试：对参数个数进行边界值判定，对参数内容进行边界判定

　　(3)单元测试

　　

 

　　测试质量：  单元测试覆盖了程序的所有路径，对白盒测试和黑盒测试的几类测试用例都基本实现了覆盖，每个等价类中典型测试用例选择了2到3个 。

　　被测模块质量：被测模块基本可以应对各种正确与非正确输入，单元测试中输入字符串为{}空时，显示为“未输入参数”；输入字符串为{“”}时，显示为“未输入.txt”，该单元测试显示为失败。实际上进行命令行输入时，只会出现args数组内容为空的情况，或者出现内容为多个“ ”的情况，都能被正确判断输出，因此被测模块质量满足要求。

 

 

扩展任务：

　　（1）代码规范：代码规范与复审（精简版）现代软件工程讲义 3 代码规范与代码复审

　　　　　　选择部分：代码风格规范，代码设计规范中的函数和错误处理

　　（2）规范分析：分析了17048的代码

　　　　　　对项目中各模块的静态分析见（3）

　　　　　　不足之处：代码中定义了两个没有无用变量；对{}的使用没有另起一行，使得结构清晰标准；

　　　　　　好的规范：写了详尽的注释，并且注释为英文，格式统一，长注释在前一行开头，变量短注释在定义后；

　　　　　　　　　　  变量命名遵循规范，具有一定的实际意义，便于区分；

　　　　　　　　　　  变量统一在方法前集中声明，说明变量含义；

　　　　　　　　　　  函数方法设计分工合理；

　　　　　　　　　　  对可预料的各种错误输入和异常情况进行处理；

　　（3）选择静态检查工具：findbugs　　http://downloads.sourceforge.net/project/findbugs/findbugs%20eclipse%20plugin/1.3.9/edu.umd.cs.findbugs.plugin.eclipse_1.3.9.20090821.zip?use_mirror=ncu

　　

 

findbugs检查输入模块（input）没有发现问题；

代码规范上不足之处：{}的使用与小组其他成员不统一；注释没有使用英文注释，平台移植时可能出现问题；缺乏统一的变量说明注释

　　　　　规范之处：变量命名遵循规范，有实际意义；对各种错误输入有所处理，容错性提高；函数方法设计合理

　　（4）小组问题：小组成员各模块函数和类的命名不够统一（已改进）；代码风格不统一（以改进）；整合后部分变量和说明有冗余（已改进）；衔接后部分异常处理重合（已改进）

 

 

高级任务：

　　（1）测试数据集设计思路：a.有140个以上需要根据词频排序的单词

　　　　　　　　　　　　　　　b.每种类型的单词出现20个以上：纯单词如software；连字符单词如content-based；单引号单词如Let’s；带短横线的单词如moon-;带双引号的单词如“aaa;带数字、常用字符和单词的情况如(see Box 3–2).8885d_c01_016；带数字的单词如bbb-2;

　　　　　　　　　　　　　　　c.5个以上统一单词的大小写形式，如apple和APPLE

　　　　　　　　　　　　　　　d.5个以上词频相同的不同单词排序，如：apple 5

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　camera 5

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　demo 5

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　yellow 5

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　zero 5

　　（2）优化前：统计从main函数开始运行到统计输出完成的时间（单位毫秒）

　　　　　　　　

　　　　　　　　

　　（3）同行评审：

　　　　　　参加者：小组成员：康之是，冷福星，李慎刚，付佳韵

　　　　　　主持，记录：康之是

　　　　　　评审者：李慎刚，付佳韵

　　　　　　开发者，代码讲解：冷福星

　　　　　　评审对象：核心模块（kernel）

　　　　　　评审过程：开发者讲解代码逻辑，函数功能等；

　　　　　　　　　　　开发者运行程序，测试压力txt文件，反复多次，得到平均运行时间；

　　　　　　　　　　　评审者提出意见，开发者回答；

　　　　　　　　　　　达成共识，进行改进

　　　　　　提出意见：核心功能中先进行大小写转换再进行判断，并且更改对单词的判断方法函数，采用正则表达式进行词法分析。

　　（4）优化后：

　　　　　　改用正则词法进行单词判断，并且先进行了大小写的转换

 　　　　　　　　

　　（4）影响性能的主要因素是核心功能中对单词的判断步骤，判断语句的多少和嵌套的重数

　　（5）感悟：通过本次实践，以及完成基础任务，扩展任务以及高级任务，我认识到软件开发要达到预期的要求，提升质量离不开对于软件的测试。开发过程就像依据需求的图纸在建一栋房子的基础轮廓，能完成大致的形状与功能；而搭好轮廓以后，需要进行测试检查房子的承重，细节处是否存在偏差等。测试的过程中慢慢暴露基础轮廓的各种缺陷，再进行调整与修改，经过多次自己的，他人的评审与测试，多次的修改，最终使得软件质量达标。

 

        小组贡献度25%

　　　　　　　　　　　　　　　

　　　　

 

　　　　

 

转载于:https://www.cnblogs.com/fujiayuntest/p/8710985.html