3.7.2 超市结账第二回合

小八拿到第一轮的测试报告后,信心满满地表示 8 个收银台完全够用,足以应对日常高峰期的客流量。然而,收银员们却提出了异议:你的测试用例里预设的顾客都是年轻人,老年人怎么可能这么快完成支付?他们的支付时间至少是年轻人的 2 倍!而且早高峰时期,一半的顾客都是老年人,必须重新设计用例,重新测试。

收银员们的话让小八恍然大悟,确实是自己考虑不周。于是,他决定重新设计测试用例,增加老年人因素:老年人的支付时间变为年轻人的 2 倍,且老年人在所有顾客中占比为 50%。

在开始改造用例之前,我们先来认识一个新工具:java.util.concurrent.ThreadLocalRandomThreadLocalRandom 是 Java 中的一个类,专门用于生成伪随机数。它位于 java.util.concurrent 包下,顾名思义,它与多线程编程息息相关。与 java.util.Random 不同,ThreadLocalRandom 为每个线程提供了一个独立的随机数生成器,避免了多线程竞争同一个随机数生成器的情况,从而显著提升了性能。

ThreadLocalRandom 提供了多种随机数生成方法,例如生成不同数据类型的随机数(如 intlongdouble 等),以及带范围限制的随机数生成方法。在 API 使用方法和参数含义方面,ThreadLocalRandomRandom 基本一致,这让开发者可以无缝切换,毫无压力。

接下来,我们使用 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 自动化
理论、感悟、视频


↙↙↙阅读原文可查看相关链接,并与作者交流