How to Test Variable‑Probability Lottery APIs with Non‑Fixed Odds

In the previous article we covered how to test probabilistic business interfaces. The new requirement introduces a non‑fixed probability algorithm where the winning probability P = p(1 + 0.1 × N), with p the base probability and N the number of consecutive losses (capped at 5). An additional rule forbids consecutive wins, and probabilities are rounded to the nearest 1 %.

The API consists of three endpoints: a lottery draw, an activity‑configuration query (including gift settings), and a personal activity detail (user info, draw count, win record). The test is implemented in Java by wrapping each endpoint into a method, invoking them repeatedly, and aggregating the results over a one‑day test window.

Testing focus

The challenge lies in verifying the dynamic probability formula while also ensuring no consecutive wins. Two testing approaches were proposed.

Solution 1

Calculate the theoretical overall winning probability P from the formula, set various base probabilities p, run a large number of draws, and compare the observed win rate with the theoretical value using the same standards as the previous probabilistic‑interface test.

Solution 2

Execute a massive draw batch (e.g., 10 000 attempts), record each outcome (1 = win, 0 = loss), then build a table of P versus N for a given p. For example, after two consecutive losses, compute the expected next‑draw probability Pₙ. Count occurrences of the pattern “1000” and “1001” in the result stream to derive the empirical probability Ps, and compare Ps with the theoretical Pₙ, again using the prior test criteria.

Both solutions suffer from large test volume and long execution time. Because the probability is evaluated per user, multithreaded testing must bind each thread to a distinct simulated user.

In practice, this type of requirement is best addressed with white‑box testing.