结对编程二--单元测试

结对编程二--单元测试

coding地址：https://coding.net/u/lhl1212/p/work2/git

结对伙伴：201421123037和201421123041

一、题目描述

    上一周大家为四则运算程序设计了2-3个新功能，本次在隔了一周之后，我们循序渐进地进阶。本次目标：

    1、把计算模块提取出来，单独创建一个类；

    2、针对提取出来的计算类的接口函数做单元测试。

二、题目要求

    1、结对编程实现上述功能，同样的，在程序正式开发之前，请先预估下PSP每个环节的消耗时间(分钟)，并在过程中统计实际耗时(分钟)，最后提交PSP表格。依然注意，这个主要是给你们自己看的，不必造假数据；

    2、继续两人结对协作，把编码规范、领航员和驾驶员角色互换做到位；

    3、单元测试: 有单元测试保证，有代码覆盖率。

三、需求分析

    1、通过单元测试代码，测试加法是否能正确工作；

public void testAdd() {
        calc.add("1+1");
        assertEquals("2" , calc.getResult());
        calc.add("1/3+1/3");
        assertEquals("2/3" , calc.getResult());

    }

运行截图：

    2、通过单元测试代码，测试加减乘除功能；

	public void testSubstract() {
		calc.substract("1-2");
        assertEquals("-1", calc.getResult());
        calc.substract("2/3-1/3");
        assertEquals("1/3", calc.getResult());
	}

　　运行截图：

 

Junit的结果显示：

该函数的代码覆盖率：

没覆盖到的部分主要是队输入字符串进行处理的部分，由于这一块主要是测试加减乘除这几个算法，所以暂时还没覆盖到，接下来的测试就会覆盖到了。

 

当输入的测试代码有错误时，Failure Trace会报错。错误的测试例子（这个是从coding上下下来的时候由于除号字符编译器不支持的原因）：

   

在除法计算方法中当除数为0的时候也会显示错误：

    

 

对报错部分进行修改后，红色覆盖部分就变为绿色了：

   

    3、通过单元测试代码，测试计算类对于各种参数的支持：

a. 输入是有错误的，例如 “1 ++ 2”，

b. 在数值范围是 -1000 .. 1000 的时候，传进去 “10000 + 32768”,

c. 或者是 “ 248 / 0” 怎么办?

d. 怎么告诉函数的调用者 “你错了”? 把返回的字符串定义为 “-1” 来表示？

e. 那么如果真的计算结果是 “-1” 又怎么处理呢?

输入错误时，返回的结果为null,应该是预料到的情况，用“-1”来表示的话，当结果为“-1”的时候就会产生误判。

正确测试的例子：

对以上提到几种特殊情况的测试：

    

    

Failure Trace会显示在函数写出的抛出异常。

 

 

四、PSP

PSP2.1	personal sofware process stages	time（%）senior student	time(%)
planning	计划	10	15
estimeate	估计这个任务需要多少时间	225	340
development	开发	15	20
analysis	需求分析	20	10
design spec	生成设计文档	20	15
design review	设计复审	10	5
coding standard	代码规范	10	20
design	具体设计	30	60
coding	具体编码	110	200
code review	代码复审	20	10
test	测试	50	100
reporting	报告	40	50
	测试报告	15	10
	计算工作量	5	10
	并提出过程改正计划	10	5

五、结对照片

 

 

七、小结   

在隔了一周之后再看之前的代码，是否更能体会到下面这些东西

(1) 良好的设计

　　一开始的设计真的很重要，比如一开始设计的时候，没有用字符串来封装式子，导致在主函数中，要对输入的字符串进行各种拆分各种判断，导致逻辑结构不清晰，代码冗余大。所以这一点的改进使得后续的一些函数编写容易多了。

(2) 编码规范

　　编码规范在一开始就定好，除了少数的变量名字还是有些争议，比如我觉得有的时候起了个变量名“questions”，有时又用“formula”...就是在命名上面还没有完全做到统一。

(3) 必要的注释

　　注释这方面做得还是有点少，后期应该把必要的地方加上注释。可是对于注释的多和少怎么界定还是有点模糊。

 

 队友的总结： 这是第二次结对编程了，相比第一次有了的陌生，这一次合作更加默契。总的来说，基本功能得到实现，测试内容也得到了解决，但还是需要加强编程方面的练习。

 本人总结：对于测试这一块感觉了解的还不是很透彻，需要继续花时间去研究。在一个软件工程项目中，前期的开发重要，后期的测试也很重要，可以帮助我们发现一些bug。这次的实验也是不仅仅是个人掌握知识情况缺乏限制着我们，更要命的是一些工具安装方面总是遇到问题，好在我的朋友告诉我，对于这些问题“重启重装重买”一般就能解决。装不上EclEmma的时候，第二天开机之后就发现能用了。。。所以还是有一定的道理的吧。团队合作方面，在这一次的结对中比上次情况好一些，问题解决花的效率也比前一次要高。对于我队友的话，还是很适合合作的一个搭档，会主动着手去解决问题。

关于EclEmma的使用，参考了教程：http://liangruijun.blog.51cto.com/3061169/803473

转载于:https://www.cnblogs.com/shizhuangde/p/6641064.html