测试自动化和持续交付测试自动化和持续交付
软件测试和验证是细致活也是辛苦活,需要模仿最终用户尝试各种用法和输入场景、比较并断言所期望的行为。而这
些细致的辛苦活是可以让计算机程序去做的。自动化测试套件中那些可编程部分对于大规模软件交付是非常有帮助
的。在我做过的大部分项目里,有些测试是可以自动化的,也有些不能。不过,只要有自动化测试套件,我的团队都
将倚重于它,而将精力集中在那些没有自动化的功能测试。而且,自动化测试还让我们能够满足客户快速变化的需
求,并使我们达到了一个更高的层次,使得每次构建(即使只是微小变动)都是经过测试和验证的稳定版本。正如Jez
有关持续交付的文章中所言,自动测试“让交付团队超越了基本的持续集成”并走上持续交付的康庄大道。实际上,我觉
得自动化测试是非常重要的,如果你要实践持续交付,就必须在自动化测试上进行投入。本文解释了之所以我这么认
为的原因。
时间周期 - 从最后一次代码提交到发布
当软件复杂度不断增长时,验证其变化部分和已构建部分的工作量都会随之增加,这种增长至少是线性的。这就意味
着测试时间与需要验证正确性的测试用例数量是成比例的。因此,增加新特性即意味着从开发完成到交付软件的时间
会拉长,如果投入更多测试人员来应对增加的工作量(假设所有测试任务是相互独立的),那么交付成本也会增加。
很多团队通过保留一个测试人员池来应对这一问题,这票人马在整个发布版本验证期间都在做“回归”测试,以检查新变
化是否破坏了已有功能,我待过的一些团队也是这么干的。但是这么做不仅成本高昂,而且效率低下、进展缓慢且容
易出错。
在自动化测试场景下,你可以减少花在验证用户功能工作上的时间和金钱。我们不妨假设你的测试场景中有合理数量
的测试用例是可以自动化的,比如50%,这通常是软件项目可自动化测试用例的下限。如果你的团队能够自动化该数
量的测试用例,那么人们就可以将把更多注意力集中于那些新近变化的特性上。假设跑一遍这些自动化测试需要3小时
(时间越短越好,甚至少于20分钟),这一时间将直接影响将产品推出的时间。增加自动化测试的数量,并尽量减少
测试运行的时间,那么你快速响应的能力将显著提升,同时成本得到缩减。下面我用一些简化数字(平均用例数)加
以说明:
团队团队A
1、需测试场景数量 - 1000且在增加中。
2、建立构建环境所需的时间 - 10分钟。
3、测试一个场景所需的时间 - 10分钟。
4、团队中的测试人员数量 - 5。
5、假定不存在blocker(阻塞)。
如果没有自动化测试,测试单次提交的时间总量为(以分钟计):
10 + (1000*10)/5 = 2010 分钟。
接近于4个工作日(每工作日8小时)。如此不仅成本高昂,而且开发人员在4天后才能得到反馈。这种设置日后还有可
能在你的迭代中形成迷你瀑布。