小八拿到第一轮的测试报告后，信心满满地表示 8 个收银台完全够用，足以应对日常高峰期的客流量。然而，收银员们却提出了异议：你的测试用例里预设的顾客都是年轻人，老年人怎么可能这么快完成支付？他们的支付时间至少是年轻人的 2 倍！而且早高峰时期，一半的顾客都是老年人，必须重新设计用例，重新测试。
收银员们的话让小八恍然大悟，确实是自己考虑不周。于是，他决定重新设计测试用例，增加老年人因素：老年人的支付时间变为年轻人的 2 倍，且老年人在所有顾客中占比为 50%。
在开始改造用例之前，我们先来认识一个新工具：java.util.concurrent.ThreadLocalRandom。ThreadLocalRandom 是 Java 中的一个类，专门用于生成伪随机数。它位于 java.util.concurrent 包下，顾名思义，它与多线程编程息息相关。与 java.util.Random 不同，ThreadLocalRandom 为每个线程提供了一个独立的随机数生成器，避免了多线程竞争同一个随机数生成器的情况，从而显著提升了性能。
ThreadLocalRandom 提供了多种随机数生成方法，例如生成不同数据类型的随机数（如 int、long、double 等），以及带范围限制的随机数生成方法。在 API 使用方法和参数含义方面，ThreadLocalRandom 与 Random 基本一致，这让开发者可以无缝切换，毫无压力。
接下来，我们使用 ThreadLocalRandom 构造一个随机方法，返回 1 或 2。如果返回 1，则认为是年轻人；如果返回 2，则认为是老年人。
改造的重点在于多线程任务中的 pay() 方法。改造后的代码如下：
/**
* 支付
*/
public void pay() {
// 顾客支付阶段
int milliseconds = (int) (System.currentTimeMillis() % 10000) / 100;
int i = ThreadLocalRandom.current().nextInt(2) + 1; // 随机生成1或2
ThreadTool.sleep(milliseconds * i); // 如果是老年人，支付时间翻倍
}
这样一来，测试用例就更加贴近现实了。小八立刻安排重新对超市的结账功能进行了第二轮的性能测试。
正所谓 “实践出真知”，这次的测试结果一定会更加准确，帮助小八做出更合理的决策。收银员们也纷纷表示，这次的测试用例设计得更加接地气，终于不用再为老年人支付慢的问题背锅了！
通过这次超市收银台性能测试的改进，小八不仅解决了一个技术问题，更深刻地理解了一个道理：技术存在的意义，是为了更好地服务用户，而不是为了追求冰冷的效率。无论是年轻人还是老年人，他们都是超市的重要顾客，他们的需求都应该被认真对待。
在第一轮测试中，小八只关注了系统的理论性能，却忽略了现实中的多样性。收银员们的反馈让他意识到，技术测试不能脱离实际场景，更不能忽视用户的真实体验。这次改进不仅让测试用例更加贴近现实，也让小八和团队之间的关系更加紧密。
FunTester 原创精华
【连载】从 Java 开始性能测试
故障测试与 Web 前端
服务端功能测试
性能测试专题
Java、Groovy、Go
白盒、工具、爬虫、UI 自动化
理论、感悟、视频