测试用例是测试执行效果的最佳保障途径。因为一直很强调测试用例的执行记录,而且在工作中也总是依赖测试用例的执行记录给予自己软件质量的信心,因此很难想象没有测试用例的测试是什么样子的。
和研发组长交流中,时常听到说,代码的测试,我们自己会做的,你为什么要看我的记录呢?我不会去做没有记录,有执行就行了。
然而,“有执行”和“有效执行”之间的差距到底有多大呢?
我想,它们之间的差距也就是有信心和无信心的区别吧,有效的执行记录能给人以信心,没有记录只能给人一个大大的问号。
代码的测试(也叫白盒测试)并不是随意去执行的随机事件,也应该经过评估、计划后去实施。 对哪些代码进行测试?测试的目的是什么(达到何种覆盖条件)?只有满足了一定测试目的并且覆盖了选中的代码范围的白盒测试,才能算作是“有效”的。
白盒测试的多种覆盖策略;分支覆盖、判断覆盖、语句覆盖等,具体是怎么实现的呢? 我们以一段C函数的分支覆盖为例,进行分析。
在wireshark代码包中,有这样一个函数原型:
Void get_column_format_matches(gboolean *fmt_list, const gint format)
输入参数:format
输入、输出参数:fmt_list
处理:当format分别为 COL_DEF_SRC、COL_RES_SRC、COL_UNRES_SRC等25种情况时,分别将fmt_list的与之有关联意义(用枚举数据结构作为数组参数的下标进行关联)位置的数组元素及其下级元素置为true;format不在其中时,将frm_list【format】置true其下级元素置false;format<0或format>59时,fmt_list不做修改。
测试用例结果如下:
全局变量的初始化 | 输入参数 | 输出/结果 |
/ | frm_list:全false | 没有为true的element,初始化输入参数frm_list,以下每个用例都包含 |
/ | format<0 | 没有为true的element |
| Format>59, | 没有为true的element |
| format不在case的范围之内 | frm_list[format]\ 置为truefrm_list[format]的下级format为false |
| Format为每个case时 | frm_list[format]\ frm_list[format]的下级format置为true |
| 0, 59,-1,1,60,58, | .... |
最后一条的输入参数,采用了接口测试的数据边界值分析方法。