单元测试技术培训练习总结报告

单元测试技术培训练习总结报告

培训日期：2007年9月14日到2007年9月15日
日程安排：
第1天:
上午：单元测试的技术与方法培训
下午：LINUX下CUNIT单元测试工具的使用方法
第2天：
上午：分组练习
下午：分组练习
练习总结
练习情况概述：
约50名开发人员参加了练习，分成了7个小组进行了练习，其中一个小组原来采用C#在windows开发平台下进行软件开发，其他小组均是在LINUX环境下用C语言开发。练习均在实际的工作环境中进行的，有的是2个开发人员合用一台机器进行了练习。
在设计测试用例时，每个小组都对函数的输入参数进行了等价类划分，设计了对应的测试用例，大部分小组对输入参数也进行了边界值分析，有的小组也对程序的内部逻辑进行了分析，设计的测试用例达到了100%语句覆盖。对于测试用例的设计技巧需要继续在实践中提高。
有3个小组的测试程序中，函数的返回值是结构体或数据文件，需要自己编写预期结果与实际结果比较的函数。

练习结果的度量数据：

组	被测程序行数	测试程序行数	用例个数	BUG个数
1	90	100	9	3
2	90	70	19	3
3	102	142	5	2
4	150	140	14	3
5	76	40	6	0
6	65	54	7	1
7	1000	210	23	8
合计	573	546	60	12

其中有6个组被测的代码行在65行到150行之间，有一个小组的被测的代码行在1000行，因此在统计分析时，将该小组的度量数据排除在外。经过对6个项目组的有效数据进行分析，得出如下的度量结果：
平均缺陷密度=21个缺陷/KLOC;
单元测试用例密度=105个用例/KLOC；
测试代码行数：产品代码行数=1：1
测试用例的有效性=每5个测试用例发现1个缺陷。

学员的总结与咨询顾问的点评：
（1）程序员普遍感到最多的错误是边界的错误和异常处理的错误。
(2）感觉cunit工具还不错，测试框架本身提供了丰富的函数，用户无需关心cunit的内部细节，而只需专注于测试用例的设计上
（3）测试用例在设计上，要周全考虑，做到代码覆盖率100%。
（4）对于被测试函数中一些系统调用，可以通过单独封装一个函数模拟出错情况。
（5）在编码前编写测试用例可以提醒程序员在写代码时避免哪些缺陷。
（6）对于每个单元应该在本单元内对入口参数进行合法性检查，而不是在调用它的函数中做合法性检查，以提高函数的可复用性与健壮性。
（7）对于不可逆的加密类复杂算法的测试，可以采用编写另外一个已经得到验证的函数计算测试数据的结果，和被测函数的实际结果进行对比，以判断被测函数的正确性。
（8）如果代码难以做单元测试，需要写多个桩程序，则要考虑对该单元进行重构，调整结构，优化函数的分工。
（9）设计测试用例时，要充分考虑：
i) 对入口参数等价类划分
ii)边界值分析
iii)函数内部的逻辑分析。