回归测试的精确化

令人郁闷的回归测试

测试工作中最没成就感,最枯燥无味的莫过于回归测试了。

回归测试简单的讲就是有新的改动时,把旧的没有改动的功能也测一遍,这是为了防止新改动影响了已有功能。

测新功能吧，还有点新鲜感,但回归话完全是重复工作啊,让你重复个几百上千次看你想吐不。

回归测试的实际情况

手工回归

（A）对于不太复杂的系统,回归的时候可以把所有用例跑一遍。

（B）如果系统非常复杂,就挑比较重要的功能用例跑一遍。

自动化测试

将所有自动化用例脚本跑一遍。

实际上除了性能测试,自动化测试最大的用处就是在回归测试上。

很多领导寄希望自动测试在新功能上发现太多bug是不太现实的。

成本与风险的平衡

对于手工测试,回归所有用例人力时间成本太高。只回归一部分重要用例就会导致漏测。

绝大部分自动化用例都是可以短时间跑完,所以是非常理想的解决方法。但是理想是美好的，现实是残酷的。会有这样一些场景

（1）系统中只有一部分功能才能通过自动化脚本实现。

比如UI展示的美观不,你没法自动化。另外由于测试人员的技能欠缺,一些复杂的场景难以实现自动化,或者实现的成本太高。

（2）一些复杂的系统,自动化用例执行时间过长

不是所有的用例都是分分钟能跑完的，比如一些复杂的ERP系统,你生成个报表得要几十分钟甚至几小时。

理想化的回归测试

不管是通过手工还是自动化测试去回归。 最理想的情况是,改动的功能影响到了哪些功能,就只回归受影响的功能。

但问题来了？ 你怎么准确的知道哪些功能受到影响？ 

简单点的改动，你通过查看源代码或者可以看出来。但复杂的改动呢？

一种理想化的方法就是把类或函数跟用例建立一个映射关系。下面以函数为例。

（1）映射的建立

前期需要把所有的用例执行一遍,通过在函数中打桩记录,结合代码覆盖率的分析,保证所有函数都被覆盖。这样得出一张映射表

函数名用例ID my_functiontc_20150001
tc_20150002 

函数跟用例是一对多的关系。

这样每改动一个函数,通过查这个映射表就可以发现对应的用例ID,然后回归这些用例就行。

对于自动化测试通过脚本代码实现映射的建立还是比较容易,如果手动的话还得手动做些记录,这样比较麻烦点。

你可能会问,函数间存在调用关系,函数A改动了,调用它的B也会受到影响。这个不用担心,在建立映射关系的时候,A映射的用例肯定会是B映射用例的子集。

可能存在的困难

上面说的理想化的回归测试如果在真正实现肯定存在很多困难要克服。

(1) 用例的规范、完整性

一个完整覆盖所有函数的用例库可不是那么容易整出来的。

(2)函数的耦合性

如果函数设计的不好,耦合性太大。可能改动较少函数就把所有用例映射过来了。这样就辛苦白忙乎了，还不如老实的直接把用例执行一遍呢。

(3)初始化函数的剔除

做一些初始化动作的函数会调用非常多其他函数,这样它映射的用例是非常多的。如果只针对初始化函数做点小改动会导致需要回归非常多的用例。应该把映射用例太多的函数拿出来做人工分析,是不是需要剔除出去。

实施的建议

刚开始可以尝试建立类和用例的映射。类的数量一般是比较少的。慢慢再尝试函数的映射。

前期找一个小模块的功能做实验,看效果明显不。

当觉得有效果时才考虑全面推广。