首页 > 代码库 > 结对编程2—— 单元测试
结对编程2—— 单元测试
结对伙伴:201421123048,201421123036
coding.net 地址:https://git.coding.net/YJh_/PairProject_2.git
a. 需求分析:测试上有哪些详细的需求?
1.把计算模块提取出来,单独创建一个类
2.通过单元测试代码,测试加法是否能正确工作
3.通过单元测试代码,测试加减乘除功能
4.通过单元测试代码,测试计算类对于各种参数的支持
- 输入是有错误的,例如 “1 ++ 2”
- 在数值范围是 -1000 .. 1000 的时候,传进去 “10000 + 32768”
- 或者是 “ 248 / 0” 怎么办
- 怎么告诉函数的调用者 “你错了”? 把返回的字符串定义为 “-1” 来表示?
- 那么如果真的计算结果是 “-1” 又怎么处理呢?
5.测试代码覆盖率
b. 设计测试框架, 模拟测试数据:
给出计算模块的测试用例及运行结果
1.加减乘除
2.测试分母为零
3.测试输入是有错误的,例如 “1 ++ 2”
4.在数值范围是“-2147483648”到“2147483647”的时候,传进去 “1000000000 + 2000000000”
5.测试代码覆盖率
使用EclEmma
c. 小结与感受
- 第二次结对合作还是很愉快地完成了,也起到了1+1>2的效果,互相监督,相互提出问题,相互解决问题,加快进度与效率,感觉结对编程是很好的合作方式。
- 测试代码覆盖率时,一开始还是比较迷茫的,经过查找资料,度娘,才学会了使用EclEmma工具来测试代码覆盖率。
- 在Eclipse中使用GIT提交代码,commit很多次码市中还是没有记录,只有使用PUSH的时候才有推送的记录。
- 对结对伙伴的评价:
-
- 第一片面包:在这次结对过程中,他认真对待编程项目,并按时完成项目要求。
- 中间的肉:结对编程,用《构建之法》第4章讲就是,"2个程序员、同一套设备、一起工作、一起分析、设计、写测试用例、编码、单元测试、写文档,平等互补地工作"。而1+1=?应该有三种选择即:可以大于2,可以等于2,也可以小于2。从我们这次结对编程经历看来,这个式子的答案是大于2的。这次的项目,当我充当"执行"角色,负责编程时,她则负责"观察"(或"导航")。让我明显感觉到了编程效率和编程质量的提高。在这次结对过程中,一开始,我充当"执行"角色,负责编程。有时候,我可能会对项目无从下手,可以和她一起讨论,当讨论有一点想法后,又可以和她一起着手项目。
- 中间的青菜:在这次结对过程中,可能因为我们两个人的编程习惯不同,而导致项目进行的过程中出现分歧。所以这个时候,我希望我们可以妥善解决,即一起讨论是迁就还是改变。
- 第二片面包: 她做事比较细心,时刻提醒我编程中的一点小小的错误,并且会及时提出建议,是一位很好的结对伙伴。
d. 在隔了一周之后再看之前的代码的体会
1) 良好的设计
按照之前的要求,基本功能都实现了,但是设计还是有欠缺。
2) 编码规范
规范性比较差,两个人合作多多少少会有些代码写得比较乱,规范性还有待提高,要多参照别人的代码规范。
3) 必要的注释
两个人合作,对于注释还是非常重要的,必要的注释才能让队友看得明白,这样更容易合作。
讨论合照:
PSP:
PSP2.1 |
Personal Software Process Stages |
Time (%) Senior Student(/hour) |
Time (%)(/hour) |
Planning |
计划 |
1 |
1 |
· Estimate |
估计这个任务需要多少时间 |
3 |
2 |
Development |
开发 |
4 |
5 |
· Analysis |
需求分析 (包括学习新技术) |
1 |
2 |
· Design Spec |
生成设计文档 |
0 |
1 |
· Design Review |
设计复审 |
2 |
1 |
· Coding Standard |
代码规范 |
1 |
1 |
· Design |
具体设计 |
3 |
1 |
· Coding |
具体编码 |
2 |
4 |
· Code Review |
代码复审 |
1 |
2 |
· Test |
测试(自我测试,修改代码,提交修改) |
2 |
3 |
Reporting |
报告 |
1 |
1 |
· |
测试报告 |
1 |
1 |
· |
计算工作量 |
2 |
2 |
· |
并提出过程改进计划 |
3 |
2 |
结对编程2—— 单元测试