Excelログを掃討する

2016-06-11 / [excel]

問題

Excelにログを貼ることがよくある。 いわゆる検証のエヴィデンスとして。

今まで検証チームの人たちは自分の好きなテキストエディタでログを確認して、 Excelにコピペしていたんだけど、直近の検証ではテストケースも多いしログの種類も多いので いい加減手動でコピペするのが辛くなってきたというのがある。

なんでログを渡すだけでは駄目なのかというと、 工程を承認する人がテストケースとログの抜粋を一つの資料で確認したいからだ。 もうこの前提自体は是正できない。そんな政治的交渉をしている時間がない。

整理する

達成したいのはなにか。

  1. ログは自動で集められてサーバにアップロードされる
  2. サーバにある圧縮されたログファイルはrsyncで作業者の端末にダウンロードされる
  3. 作業はログを確認しシステムの挙動・状態が期待どおりであることを確認する
  4. ★作業者は期待通りであると判断した根拠となるログを複数件抜粋する
  5. ★抜粋されたログは対応する試験項目を表すExcelシートにペーストされる

★の部分を効率的に処理したい。 Excelを作業者がいちいち開いてペーストするなんてありえない。 プログラムで処理したいわけだ。

どうやって楽できるか考える。

1,2は自動化された基盤を使えることがわかっているので今は考えないでおく。

3は人間による判断をする必要がある。機械的に判断するための定式化は難しい。 というか人間が機械的に判断できることをやっているというよりは、 定式化が面倒なので人間の直観を使って判断させてる、が正解。つまりプログラマの敗北かも。

4,5が今回のスコープ。 作業者はログファイルの「ここからここまで」を抜粋したらそれにメタデータをつける。

データフロー

                        [メタ情報]
                            |
                            v
[ログ] -> (抜粋処理) -> (Excel化) -> [試験ログシート]
              ^             ^
              |             |
          [抜粋規則] [エヴィデンスシート]

考え方

どんなプログラミングでもこの考え方は有効だと思う。

すなわち**「プログラムはデータの変換(transformation)に徹する」**

データをストリームとみなす時、プログラムはストリームに対するフィルタの役割を演じる。

今回であればsourceとなるストリームは大量のログだ。それをフィルタにかけるとExcelシートが出てくる。 まるでひとつの大きな関数とみなす。

ちなみにこれはScala Cookbookから学んだ発想。便利。

Haskellで学んだデータ加工の考え方でいくと、 ログのデータは中間的な構造に変形されたあとにExcelとしてレンダリングされるだけと考える。

メタ情報

ログファイルが持つメタ情報は下記のようなものがある。

  • ノード
  • タイプスタンプ
  • タグ
  • 実行コマンド

テキストデータに構造をもたせるためにはマークアップが必要になる。 JSONだったら素直にObjectとして表現できるのだけど、可読性を重視してできるだけplain textの表現を維持するべきか。

# id: 1-a
# stage: before
# log-name: process
# node: some-host
# timestamp: 2016-01-01T00:00:00.000
# tags: process
# process: ps aux
〜ログの本文〜

こんな風にすればself containedなログファイルになりそう。 ログを取得するプログラムの修正でこうしたメタデータは追加できそうだ。

このログを処理する時の重要なデータとなる。

抜粋

いくつかのログから必要な箇所を抜粋し一つのエヴィデンスとする。 そのテストがパスしたことを示す根拠をログに求める。 試験の作業者はなんのログを見て試験結果を判断したかを示すため、ログを抜粋する。 これを複数の担当者が同時に行うことになる。(担当によって確認するところが分担されている)

ログの抜粋は集約して一つのデータとなる。 ここで生成されたエヴィデンス群は次の過程でExcelとしてレンダリングされることになる。

  1. 作業者の端末でログを確認する できれば好きなエディタで確認してほしい
  2. 担当者は一箇所にログを集める
  3. 集めたログをもとにExcelシートを生成する

気づく

あー、まてよ。ログを集約する仕組みまであればいいのかな。 集約の単位はチケットで表現できる。だからITSでいい。ただログを担当者がペーストできればいい。

Excelに貼るのは人の手でやってもいいということかもしれない。

最小限コストを書けるべきなのは、ITSの運用プロセスやルールだ。 一定のルールでnormalizeすることでプログラムそれをデータとして扱えるようになる。 本当に大事なのはそれだけだ。

ルールに従ってデータを処理するプログラムなんて後で書けるんだ。

だからITSでの運用方法を決めよう。 そしてITSのもつAPIからデータを抽出しExcelを生成するところまで考えよう。

ITSに記入するデータの正規化

ITSに登録するチケットがテストケース1件を表すとする。 各チケットには最低限テストケースの手順と合否をメモする。

例えばエヴィデンスはひとつのテストケースで1ファイルとする。 最終的にテスト全体でエヴィデンスをまとめた1ファイルがほしいなら、VBAマクロなどで適当に処理できる。 情報はできるだけ細かい粒度で保管するのが正しい。それらを合成するのは簡単だ。

だとするとエビデンスファイルの中身はどうなるだろうか。

  • テストケースについての記述
    • どの観点のテストか
    • どんな手順で記述するか
    • システムが満たすべき条件はなにか

ログ抜粋の記法

仮にITSのチケットに対してログを抜粋を貼り付ける方法を取るとする。 チケットのコメント欄にログを貼り付けることになるだろう。

この時にメタ情報とログの抜粋が必要になる。 試験者の手元にあるログに記されたメタ情報を貼り付けるか。面倒だなあ。

メタ情報をコピペすれば一発でITSで可読可能なテキストになるようにしたい。 とすると例えばmarkdown記法に準拠したメタ情報を最初から出力するべきだ。

- id: 1-a
- stage: before
- name: process
- node: some-host
- timestamp: 2016-01-01T00:00:00.000
- tags: process
- source: ps aux

---

〜ログの本文〜

こちらの方がいいか。