扫码阅读
手机扫码阅读

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

241 2023-07-12

培训日期20079142007915
日程安排
1:
上午:单元测试的技术与方法培训
下午:LINUXCUNIT单元测试工具的使用方法
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
测试代码行数:产品代码行数=11
测试用例的有效性=5个测试用例发现1个缺陷。

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

原文链接: https://measures.blog.csdn.net/article/details/4962560

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席

79 篇文章
浏览 28.5K
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线