縮める前に判定器を作る

一言でいうと

最小再現例を作る仕事の半分は、縮める技術ではなく、「まだ同じ失敗なのか」を機械に判定させることです。判定ツールがなければ、縮める作業は推測になります。

なぜ必要なのか

顧客が送ってくれた再現手順は、たいていその人がその日にしたことのすべてです。12ステップの手順と、200行の入力ファイルが付いてきます。そのすべてを抱えたまま原因を探そうとすると、見るべき組み合わせが爆発し、どこから始めてもよい状態になり、2日たっても同じ場所にいます。

縮めなければならないことは、誰もが知っています。問題は、縮めている途中で道に迷うことです。1行を抜くと、プログラムが別のエラーで落ちます。別のエラーもエラーなので「まだ再現される」と勘違いして、縮め続けます。そうしてできた3行の入力は、私たちが探していた欠陥とは無関係な、別の欠陥を再現します。その3行を持って顧客の開発チームに行くと、1日が消えます。

なぜ判定ツールが先なのか

そのため、順序があります。縮める前に判定ツールを作ります。判定ツール(オラクル)は、候補の入力を1つ受け取り、「いま、これは私たちが追っているその失敗を起こすか」にだけ答えるプログラムです。人が目で見る判定は、縮小には使えません。縮小は候補を数十回から数百回試す作業で、その回数を人は負担できないからです。

判定ツールが見るのは、3つほどです。

• 終了コード: 0でないというだけでは足りません。どのコードかまで見ます。
• シグネチャ文字列: その失敗にだけ出るエラー名や例外名です。ERR-QTY-COMMAのように、狭いほどよいです。
• 場所: 必要なら、どのステップで起きたかまで見ます。同じ例外が2か所で起きるプログラムがあります。

逆に、判定ツールが見てはいけないものもあります。実行時刻、一時ファイル名、ログの行数のように、実行ごとに変わるものは、判定に入れません。入れると、同じ候補が、ある日は再現され、ある日は再現されません。

どう動くのか

判定ツールができれば、縮める作業は機械が行います。最も単純な方法は、1行ずつ抜いてみることです。200行なら判定ツールを200回呼び、1周するたびに残りの行が減るので、さらにもう1周します。正しいのですが、遅いです。

ZellerとHildebrandtのddminは、これを塊の単位で行います。候補をn個に分けて、1つの断片だけで再現されるかを先に見て、だめなら1つの断片を抜いた残りで再現されるかを見ます。どちらもだめなら、さらに細かく分けて同じことを繰り返します。原因になる行が2つだけなら、呼び出す回数が行数の対数に近くまで下がります。256行から2行を探すのに、判定ツールを100回あまり呼べば足ります。

[a b c d e f g h]        전체가 재현된다
  갈라 본다 → [a b c d] [e f g h]
  [a b c d] 재현 안 됨
  [e f g h] 재현 안 됨          ← 조각 하나만으로는 안 된다
  나머지로 본다 → [e f g h](= a b c d 를 뺀 것) 안 됨, [a b c d] 안 됨
  더 잘게 → [a b] [c d] [e f] [g h]
  [a b] 뺀 나머지 재현됨 → 후보가 [c d e f g h] 로 줄었다
  … 반복 …
결과: [c g]  — 여기서 c 나 g 를 빼면 재현되지 않는다

結果が1-最小(1-minimal)だという言葉は、残ったもののうちどれか1つを抜いても、再現が止まるという意味です。「最も小さい」という意味ではありません。まったく別のもっと小さい組み合わせがあるかもしれません。そのため、縮小を終えたあとは、残った行を1つずつ抜いてみて止まることを、別に証明して書いておきます。この証明がなければ、「なぜこの行が必要なのか」という質問に答えられません。

現場での姿

1つ目に、手順も入力と同じように縮めます。12ステップのうち、実際に必要なのは4ステップだけという場合がよくあります。残りの8ステップは担当者の習慣です。手順を縮めると、「環境のせい」というあいまいな説明が消えます。

2つ目に、まっさらな場所で実行します。前の実行が残したファイルがあると、「設定ファイルを作るステップ」を抜いても再現されます。そうすると、そのステップは不要だという誤った結論が出ます。手順を試すたびに、空のディレクトリを新しく用意します。

3つ目に、縮めた例が本物かどうかを、値を変えて確認します。残った2行がlocale=deとqty=1,5なら、数字を9,25に変えても再現されるかを見ます。再現されるなら、原因はその数字ではなく、カンマとロケールの組み合わせです。ここまでして初めて、顧客の開発チームがすぐに直せる報告になります。

4つ目に、最小例は判定ツールと一緒に送ります。入力2行だけを送ると、受け取る側はまず「これがなぜ問題なのですか」と尋ねます。判定ツールを一緒に送れば、受け取る側が自分の環境で1回実行してみて、すぐ同じ場所に立てます。

実務で本当に大切なこと

• 判定ツールを先に作ります。この順序を変えると、縮める作業は推測になります。
• どんな失敗でも同じ失敗とは限りません。終了コードとシグネチャを一緒に見ます。
• 1-最小を証明して書きます。行ごとに抜いてみて止まることを、記録に残します。
• 値ではなく構造かを確認します。値を変えても再現されるなら、原因は構造です。

次のラボですること

(架空の)デリム物産が送ってきた障害資料一式を広げます。処理プログラム1つ、フィード200行、再現手順12ステップです。まず「同じ失敗」を判定するオラクルを作り、そのオラクルでフィードを縮め、残った行を1つずつ抜いてみて、1-最小であることを証明します。そのあと、ddminを自分で実装して縮小を自動化します。採点ツールは、毎回違う場所に答えを隠した256行の入力で、作成した縮小ツールを動かし、結果が正しいかと、判定ツールを何回呼んだかを一緒に見ます。最後に、手順12ステップを縮め、値を変えても再現されるかを確認して、レポートにして出します。