3.7.2 超市結賬第二回合
小八拿到第一輪的測試報告後，信心滿滿地表示 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 自動化
理論、感悟、影片