测试和数学有什么关系？想要当好一名测试，难道还要学数学？现在测试都这么卷么？或许在你的测试工作中，并没有用到数学，但如果你知道一些数学小知识，一定能帮你提升测试效率的。不信？那就接着往下看。
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。发现问题了没有？所以，以后发这个鸡汤的时候，只要发“积跬步以至千里，积怠情以至深渊”就好，不要发公式了。这个也是本篇文章的引子。
本次话题就聊到这里，下次我们聊什么呢，敬请期待。
