结对编程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 |
