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

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

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

接口：三个接口：一、抽奖接口；二、获取活动配置接口（包括各类礼物配置和信息）；三、个人活动详情（个人信息、抽奖次数、获奖情况）

测试工具：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 文档自动变成测试代码