この方法をテストする方法--機能編

本文のテーマは知識の星から来て、バックグラウンドは“知識の星”に返事して質疑応答に参加することができます.
先日、ある友达の交流を得ました.彼らは唯一の注文番号を生成する機能を持っていて、コードを単独で提出しました.この方法に何か問題がありますか.どうやってテストしますか?まずコードを出して、以下のようにします.

  /**
     *  
     *
     * @return
     */
    public static String createUniqueOrderNo() {
        SimpleDateFormat nyrsfm = new SimpleDateFormat("yyyyMMddHHmmss");
        return nyrsfm.format(new Date()) + getRandomLengthCode(4);
    }


    /**
     *  
     *
     * @return
     */
    public static String getRandomLengthCode(int length) {
        return String.valueOf((int) ((Math.random() * 9 + 1) * Math.pow(10, length - 1)));
    }

1つ目は生産オーダー番号で、2つ目は4桁の乱数を生成する方法です.まず、最初の方法の考え方を話します.注文番号は2つの部分に分かれています.1つは時間(このyyyyMMddHHmmss形式のもの)で、2つ目の部分は4桁のランダム数です.第2の方法:1つの[0,1)間のdoubleタイプの数字を生成し、次いで1つの数式(*9+1)によって1つの[1,10]間の数字を得、その後、10のあるべき乗(ここでは3)を乗じて1つの[1001000000]の数字を得、その後intタイプに強く回転して[1000000]範囲の4桁の整数を得る.
説明が終わったら、私のこの方法に対する認識を共有します.最初、私たち二人が議論した中心的な問題は、重複する注文番号が発生するかどうかです.答えは明らかで、説明すると以下の通りです:時間は秒1級まで正確で、それから乱数の範囲はざっと9000個で、1秒以内に9000+個の注文を生成したら、きっと繰り返します.
では、どのようにテストしますか?それともどうやってこのバグを持ち出すのでしょうか?
私は2つの案を提出しました:1つは口頭あるいは文字の解釈で、上述の内容です;二つ目は、テストによって重複注文番号を生成することです.

シナリオ1:

人を見て、事を見て、事実は証明して、この方法はあまり役に立たない.主な原因は開発が認めないのではなく、直す必要があるとは思わない.原因は2つある.1つは業務量がそんなに多くないこと、2つは発生確率が小さすぎることだ.

シナリオ2:

圧力測定で重複注文番号が発生し、管理が面倒になり、N回試しても重複注文番号は発生しなかった.主な原因はテスト環境の性能があまりにも悪いことで、大体数十QPS(注文インタフェース全体)で、長すぎる時間の圧力測定はサービスが不安定で、汚いデータが多すぎる.

次は知識星のパートナーが与えた案です。

年月日時分秒加算➕メール認証コードは、唯一の注文番号を構成します.危険:特定の環境で複数のサーバが一緒に走ると、同じ注文番号が表示される可能性があります.名前など、ユーザーの一意の値を設定することを推奨します.UUIDの使用を推奨します.コードは次のとおりです.

  /**
     *  
     *
     * @return
     */
    public static String createUniqueOrderNo() {
        return UUID.random.toString;
    }

より多くの方法は、マルチスレッドを使用する必要がなく、この方法を単独でテストすることです.forループの記録が速く、私のテストコードを共有します.

 public static void main(String[] args) {
        List list = new ArrayList<>();
        range(250).forEach(x->
        {
            String randomLengthCode = getRandomLengthCode(4);
            if (list.contains(randomLengthCode))
                output(x);
            else
                list.add(randomLengthCode);
        });
    }

レンガを投げて玉を引いて、もっと良い方法があれば、伝言を歓迎したり、知識の星に行って一緒に交流したりします.
次に性能の問題にも注目しました.これはまた詳しく話す機会があります.
ソリューションが多く、多くのフレームワークがサポートされており、一般的にはユーザーのアイデンティティIDに関連しています.簡単なことを言えば、注文番号にユーザーIDなどの一意のラベルを追加し、インタフェースはユーザーの注文頻度を制限します(例えば、5 s時計は次の注文しかできません).

厳粛な声明:文章は第三者(テンセント雲を除く)の転載、発表を禁止して、事の経緯は巣をテストして、トップページは私の7編のオリジナルを写してまだ黒くなって、あなた达の良心は痛くありませんか?