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