测试和数学有什么关系?想要当好一名测试,难道还要学数学?现在测试都这么卷么?或许在你的测试工作中,并没有用到数学,但如果你知道一些数学小知识,一定能帮你提升测试效率的。不信?那就接着往下看。
1测试用例中的数学问题
现在有这么一个测试场景:用户想要使用银行卡去ATM机上取钱。这里面就会涉及到很多的条件组合,例如:
用户的属性:VIP客户、普通客户
银行卡的属性:I类卡,II类卡,信用卡,贵宾卡、白金卡
钱的属性:余额充足、不足
银行卡的状态属性:可用、冻结等
......
这么多属性,如果用排列组合的形式,那得有多少种呢?这类多条件组合的问题,其实我们是经常遇到的。你是否需要全量验证呢?如果条件或者属性再多点呢?
你看,如果不知道正交表,不知道PICT,是不是就会有点束手无策呢?pairwise算法的原理又是什么呢?有兴趣的同学可以去它的官网上看看(http://www.pairwise.org/tools.asp)。这里就不展开说了(主要是原理太长了,我又懒),大家自己动手去实践吧。
2性能测试中数学问题
不知道大家注意到没有,我们在初中学习各类公式的时候,都会有些前提条件,比如动量守恒定律,它的前提条件是在研究的方向上,系统不能受到外界的力的作用;或者外界的力的矢量和为零时,动量守恒定律才生效。在性能测试的理论学习中,也会有涉及到一些计算公式,但很多测试人员在使用这些公式时,往往会忽略掉某些条件。
很多人在估算并发用户数时,会想到一个很简单的公式:C = nL/T,C是平均并发用户数,n是login session的数量,L是login session的平均长度,T是考察时间的长度,然后就开始各种算。这个公式对不对?当然是对的,但是它有一个大前提,它是针对官网、论坛等静态业务系统的计算方式(泊松分布了解下?)。但是我们现在的业务系统大多数是事务型的,所以这类的公式并不适用。
性能中还有一个常见的公式:TPS=VU * R / T,其中 VU是用户数量、R是每个用户发出的请求数,T是性能测试的运行时间。这个公式从理论上讲也没有问题。但是它也有一个大前提,那就是T是不包含响应时间的,如果包含响应时间,那TPS也会出现较大的波动。所以,在反推用户数(也就是你想用多少用户来压测)时,要特别注意考虑到响应时间这个因素,否则你给老板汇报时,你给出的最大并发数可能会有很大的水分(虽然说最大并发数本身就是很外行的话术)。
3专项测试中的数学问题
这里提我自己实践到的两个场景:
第一:当我们在做接口测试的时候,想要自动生成一些很通用的用例,来测试入参参数的边界值、等价类、类型是否匹配等。如果让测试人员每个接口都写一遍,那估计会疯。这类问题是不是本文提到的第一个场景很像呢?还是多条件组合的问题,所以我会先获取接口入参的参数类型,根据不同类型的规则结合pairwise算法生成对应的测试数据,以便于驱动测试用例。这样会比全量的排列组合效率高很多。 第二:在做UI测试的时候,有个功能是自动检测系统中所有静态URL是否可访问,如果有不能访问的,需要提前暴露出来。你当然可以通过For循环一点点地去遍历,然后访问。但这样效率太低。这个场景的本质可以简化为遍历算法的问题,可以使用深度优先或者广度优先的遍历算法,来快速实现,提高性能。
4小结
我们一直都说测试是无法穷尽的,那么我们的那些测试策略、设计测试用例的方式又如何去解释呢?实际上,我们都是在用启发式算法来解决问题。我们通过自己的经验,结合行业的沉淀的共性经验,设计出高效的测试用例,虽然无法穷举所有用例,但是最终结果相差并不会太大,在可接受的范围(系统正常上线)。如果我们穷举所有的随机组合,来达到最优解,那么时间和空间复杂度会随着入参因子的增多将呈指数级上涨,不切实际。这不就是启发式算法么(一个基于直观或经验构造的算法,在可接受的花费(指计算时间和空间)下给出待解决组合优化问题每一个实例的一个可行解,该可行解与最优解的偏离程度一般不能被预计)?
5附:一个鸡汤中的数学问题
今天在和阿常聊天的时候,她发了这么一张图给我,具体的场景就不说了。这张图想表达鸡汤信息我是可以理解的。但是数学公式有点问题。因为它忽略了一个问题,就是0.01的基数问题(是不是和本文的第二点很类似),假设我现在会100个英文单词,明天多学1个,那就是会101个了,以此类推,当到了300天左右时,我每天要学20个左右单词,才能满足所谓的比昨天进步0.01,因为你的基数不再是100,而是200左右喽(学到第299天的积累)。同理,到600天的时候,你每天要学400个单词,才能比昨天进步0.01。发现问题了没有?所以,以后发这个鸡汤的时候,只要发“积跬步以至千里,积怠情以至深渊”就好,不要发公式了。这个也是本篇文章的引子。
本次话题就聊到这里,下次我们聊什么呢,敬请期待。