如何测试非固定型几率算法P=p(1+0.1*N)

在上一期讲到如何测试几率型业务接口以后，产品又提出了新的需求，总结来讲是非固定性几率算法，有一套“算法”来计算用户下一次中奖的几率。

一样是一个几率获奖的活动，用户话费必定数额金币，有几率获奖，奖项不详细叙述了。

需求更改：用户获奖几率P=p(1+0.1*N)，其中p表示原始的中奖几率，N表示连续不中奖的次数，N最大为5。还额外提出一条需求，用户不能连续中奖，为了简化过程每种礼物的中奖几率以1%位单位。

接口：三个接口：1、抽奖接口；2、获取活动配置接口（包括各种礼物配置和信息）；3、我的活动详情（我的信息、抽奖次数、获奖状况）

测试工具：Java（不惟一），经过把三个接口提供的功能封装为方法，而后经过方法调用去获取数据，进而统计获得的结果。

测试时间：一天。

其中测试的重点仍是几率，可是由于这次的几率有两项：不能连续中奖+不肯定几率，因此难点在于如何测试用户获奖几率P=p(1+0.1*N)这个算式需求实现的正确性。

通过讨论大概给出了两个方案：

方案一

经过数学计算，得到用户综合中奖几率P和p对应关系，而后设定不一样数值的p，进行大量抽奖测试，统计结果与理论计算结果比较，标准依然采用上一期几率型业务接口的相同的测试标准。

方案二

首先进行大量测试（好比1万次），记录每次用户抽奖的实际状况，好比1（中奖）和0（不中奖），而后计算P和p与N的关系表格，获取某一个p的状况下，N与P的关系，好比连续2次不中奖以后，下一次中奖的几率Pn。而后统计抽奖记录里面“1000”和“1001”出现的次数，计算实际测试中连续两次不中奖，下一次中奖几率Ps，比较Pn和Ps的大小，标准依然采用上一期几率型业务接口的相同的测试标准。

以上两个方案依然会遇到与上一期相同的问题，测试量较大，耗时较长。由于这次方案几率以用户为单位，因此在使用多线程进行测试的过程当中须要讲每个线程单独绑定一个用户。

• 总结一下，这类需求其实应该直接白盒测试的。

上期文章看往期精选第9篇。

往期文章精选

1. java一行代码打印心形
2. Linux性能监控软件netdata中文汉化版
3. 接口测试代码覆盖率（jacoco）方案分享
4. 性能测试框架
5. 如何在Linux命令行界面愉快进行性能测试
6. 图解HTTP脑图
7. 写给全部人的编程思惟
8. 如何测试几率型业务接口
9. httpclient处理多用户同时在线
10. 成为杰出Java开发人员的10个步骤
11. 将swagger文档自动变成测试代码

公众号地图 ☢️ 一块儿来~FunTester