私はソフトウェアビルドの統計情報に取り組んでいます。成功/失敗および経過時間に関する各ビルドのデータがあり、1週間あたり約200を生成します。
成功率は簡単に集計でき、45%がどの週にも合格したと言えます。しかし、経過時間も集計したいので、データを不当に誤って伝えないようにしたいと思います。私はプロに尋ねた方が良いと考えました:-)
期間が10あるとします。それらは、成功と失敗の両方のケースを表します。一部のビルドはすぐに失敗します。これにより、時間が非常に短くなります。テスト中にハングし、最終的にタイムアウトになるものがあり、非常に長い時間がかかります。さまざまな製品をビルドしているため、成功したビルドでも90秒から4時間の間で異なります。
私はこのようなセットを得るかもしれません:
[50, 7812, 3014, 13400, 21011, 155, 60, 8993, 8378, 9100]
私の最初のアプローチは、セットをソートして中央値を選択することにより中央値時間を取得することでした。この場合は7812です(偶数セットの算術平均は気にしませんでした)。
残念ながら、特定の値を1つだけ選択するため、これは多くのバリエーションを生成するようです。したがって、この値をトレンドにした場合、どのビルドが中央値にあったかに応じて、5000〜10000秒の間で跳ね返ります。
そこで、これを滑らかにするために、別のアプローチを試みました。外れ値を削除して、残りの値の平均を計算します。私はそれを三分位に分割し、中央のものだけで作業することにしました:
[50, 60, 155, 3014, 7812, 8378, 8993, 9100, 13400, 21011] ->
[50, 60, 155], [3014, 7812, 8378, 8993], [9100, 13400, 21011] ->
[3014, 7812, 8378, 8993]
これが私にとって良く見える理由は2つあります:
- より高速なビルドではアクションは必要ありません。既に問題ありません
- 最も長いビルドはタイムアウトが原因である可能性が高く、常に存在します。それらを検出する他のメカニズムがあります
だから、これは私が探しているデータであるように思えますが、まあ、真実を取り除くことで滑らかさを達成したのではないかと心配しています。
これは議論の余地がありますか?メソッドは正常ですか?
ありがとう!