Jmeter がSSL環境に対してもちゃんと動作するようになってた

Jmeter のバージョンが 2.3.2 のころは、Java Runtime のバージョン を最新にしているとSSL環境に対するテストが動作しない状態になってました。(あえて Java のバージョンを 1.6.0 update 7 までダウングレードする必要がありました)

現在の Jmeter の最新バージョン 2.3.4 であれば、 Java が最新(1.6.0 update 14) でも正常にSSL環境に対して動作するようです。

Bugzilla用Mechanizeスクリプトの更新

Bugzilla が3系になったのに伴い、WWW::Mechanize で Bugzilla にアクセスして検索結果の数を取得していたスクリプトを修正していたところ、いろんなとこにちょっとずつはまって、思いのほか時間がかかりました。。

まずひとつは、バグジラの設定。

User Agent (ブラウザ)が Accept-language を明示していない場合、バグジラの「パラメータ」の「Localization」の「defaultlanguage」に設定してある言語によってページが表示されます。しかしここに、「languages」と同様に「ja,en」と複数指定しまっているとバグジラがエラーになります。デフォルトなんだから、ひとつでいいよね、という話。
Accept-language を持たない Mechanize でアクセスしたことで初めて発覚した設定ミス。

次に、文字コード関連。

3系になってバグジラは全体的にUTF8になったわけですが、このページを Mechanize (ないしはLWP)で取得した場合、そのコンテンツはUTF8だけどUTF8フラグが立たないようで、以下のように明示的にUTF8フラグをONにすると日本語による正規表現の文字マッチもできるようになりました。

utf8::decode($mech->content)

さらにもうひとつ、一部のリクエストに対するレスポンスの結果が「500 Line too long (limit is 4096)」となってしまいました。調べたところ、レスポンスのヘッダに長すぎるものがあるようで、以下のようにすれば回避できました。

my $mech = WWW::Mechanize->new();
{
    no warnings 'once';
    push(@LWP::Protocol::http::EXTRA_SOCK_OPTS, MaxLineLength => 16*1024);
}

参考: LWP::UserAgent で長いヘッダを受け取る方法

Bugzillaの移行完了

やっと職場のBugzillaが3系にアップグレードされました。(いろんな事情でずっとのびてました)
以前、移行方法を下調べしたときよりも時間が経ってたので、細かいところでまたビミョウにはまりました。。

細かいところ

MySQLのコンソール上でのデータ表示

コンソールで mysql コマンドで Bugzilla のデータベースに接続したとき、最初に

 SET NAMES "utf8"

とやってやらないと、SELECTとかしてデータのぞいても日本語の部分が「????」とかいう感じで文字化けする。

バグジラの設定

「パラメータ」の「Internationalization」の項では、

  • buglistmultibyteutf8 → ON に
  • utf8_decode_after_regexp → ON に
  • showbugusetextwrap → OFF に

「Localization」の項では、

  • languages の欄には「ja,en」というように記述
    • このとき、コンマの後にスペースをいれてはいけません！ Software Error になります
      • やってしまった場合は、Bugzilla がインストールされているディレクトリ/data/params をエディタで開いて 'languages' のところを直す
    • この値を変更した後、Bugzilla がインストールされているディレクトリで再度 checksetup.pl を実行してテンプレートを生成する

Bugzilla 2.16 -> Bugzilla 3.0.3 完了

実はすでにできていた

少し前に、まだ途中とか書いていたけど、実はすでにアップグレードできてたっぽいという話。

フッターのメニュー「パラメータ」から、
buglistmultibyteutf8
utf8_decode_after_regexp
showbugusetextwrap
あたりをいじると、なんかちゃんと表示されるようになった。しかし、どういじるべきなのかがいまだによく分からん。とりあえず、showbugusetextwrap あたりはOffにしておかないと、メールが文字化けしたりするっぽい(まだちょっと不明)。

あと、ターゲットマイルストーンが表示されていなかったのも、パラメータで設定しなおせばOK。そうか。。このあたりの設定は、DB中にないから、アップグレードしたらOffになるんだな。。。

というわけで、最終的な手順をざっくりまとめ

  1. Bugzilla-3.0.3-ja.7 をダウンロード
  2. checksetup.pl
  • モジュールチェック、足りないものインストール
  1. localconfig ファイルが作られたら、それを編集*1
    1. データベースへの接続設定等を環境にあわせて設定
  2. 再度、checksetup.pl
  • 新しいテーブルやインデックスが作られる
  1. データの文字コードの変更を推奨されるので、Ctrl-Cで中断
  2. contrib/recode.pl のversions の定義を修正したうえで実行
  3. ./recode.pl --charset=euc-jp --show-failures
  4. 再々度、checksetup.pl
  5. ブラウザから、新バグジラにアクセス
  • 設定を変更できる権限を持つアカウントでログイン
    • (この時点では、フッターの検索条件名や、バグの詳細ページが文字化けする)
  1. フッターのメニュー「パラメータ」
    1. Internationalization の以下の項目あたりをいじる

buglistmultibyteutf8
utf8_decode_after_regexp -> このあたりOffにしないと、メールとか文字化けするっぽい？
showbugusetextwrap ->

  1. Bug Fields の設定で、以下のあたりがOffになっているのをOnにする(使ってる場合)

usetargetmilestone
useqacontact
usestatuswhiteboard

  1. その他、環境や利用方法に合わせて設定項目いじる

*1:前バージョンのコピーをあらかじめ置いておいても可

Bugzilla 2.16 -> Bugzilla 3.0 バージョンアップ移行記(まだ途中)

ちょびっと進捗。

recode.pl での処理時の versions テーブルの扱い

2.16 では、プロダクトごとに登録するバージョンが格納された versions テーブルに、プライマリーキーがなかったとして、それの代わりに以下のようなコードが contrib/recode.pl の52, 53行目に定義してあるのだが、

     52     # The 2.16 versions table lacked a PK
     53     versions          => 'product_id,value',

実際 versions テーブルに存在するカラムは program と value なので、これを

     52     # The 2.16 versions table lacked a PK
     53     versions          => 'program,value',

としてやる必要がある。

残る課題

  • 検索結果の一覧では文字化けせずに表示されるのに、バグの詳細ページや、フッターの保存された検索名が依然として文字化けしている
    • 日本語版ではなく本家の 3.0.3 を使って同じセットアップをすると大丈夫っぽいので、日本語版のアプリケーションの問題っぽい
  • ターゲットマイルストーンが検索フォームに表示されない…
    • これも上の、versions テーブルで起こってる話に近い？それか、文字化けにからむ問題か

ソフトウェアテストシンポジウム (JaSST 08) に行ってきた(初日のみ)

JaSST 08 に行ってきました。去年は2日間参加したけど、今年は初日の30日のみだけど、チュートリアルを受講してみました(会社の金で)。それも含めて、個人的なメモを残しておきます(あくまで、僕視点のまとめです)。

基調講演

SPR の Capers Jones 氏による基調講演。タイトル「Software Quality in 2008」、幅広すぎ。。

  • 万国のいろんなプロジェクトから集めた品質指標のまとめが中心
  • 不具合*1除去効率が大事
    • 「リリース前に見つけた不具合」 対 「リリース後の不具合」
  • 不具合の原因となるのは、コーディングだけじゃない
    • 要件定義、設計、ドキュメントなどでも不具合は混入する
    • むしろ、高級言語のプロジェクトほど、コーディング以外に起因する不具合が多い
    • たとえば、Y2K問題では、年が2桁で定義されていること自体が仕様バグ。だけど昔は誰も不具合とは思ってなかった
  • FP(Function Point) を使おう。LOC(Line of Code) よりも
    • LOC はコードがないと計測できない(上での、コーディング以外のバグに起因する数値をはかれない)
    • 統計的な平均値で、変換可能 (例: C言語だと 128 LOC = 1 FP, C++ だと 50 LPC = 1 FP, など)
    • FP での規模感覚をつかむための参考として、世の中のプログラムが大体どれくらいのFPか*2
      • Windows Vista は 160,000 FP くらい
      • Microsoft Office は 100,000 FP くらい
      • SAP とかは 300,000 FP くらい
      • ケータイ(の制御ソフト？) は 15,000 FP くらい
      • iPhone は 20,000 FP くらい
      • iPod は 5,000 FP くらい
      • 車の制御ソフトは 3,000 FP くらい
      • 飛行機の制御ソフトは 25,000 FP くらい
  • "Error-Prone Module" …全体の5割のバグの原因となっているモジュール
    • 50％以上のバグが、5％のモジュールによって発生しているという統計も
    • そういうモジュールは取り除き、置き換えるべき (必ずしもできる気はしないが…)
  • 要求仕様がどれくらい膨れたのかもFPで計れる
  • 不具合除去率は、CMMレベルの高い組織ほど高い
    • 最近、CMMレベルの高い企業が多いのはインドという話
  • 「FPあたりの不具合率」と「不具合除去効率」を軸とした表に、自分のプロジェクトをプロットしてみよう
    • 不具合率が 3以下で、除去率 90％以上を目指すべき
  • インスペクション大事
    • テスティング以前の、要件仕様、設計など
    • インスペクションによって、各フェーズでの不具合をそのフェーズで検出できる
  • 個別のテストやインスペクションだけでは不具合検出は十分にできない
    • 各フェーズでの各種テストを総合的に実施しないと、高い検出率は達成できない

チュートリアル

午後に入って、引き続き、Caper Jones氏のチュートリアル。内容はけっこう基調講演ともかぶる部分もあって、それは残念。

  • いろいろなインスペクションや機能テストや各種非機能テストなどについて、下記の項目などの統計情報
    • どういった種類の不具合をどの程度除去できるか
    • FPあたりどの程度の時間がかかるものか
    • FPあたりどの程度テストケースが必要なものか
  • テストプランとテストケースのインスペクションは、やってないなら是非やるべき
  • 膨らんだ要求仕様は、元の要求仕様より、潜在的な不具合が含まれる率が高く、バグ除去効率が低い
  • FP の 1.25 乗で、平均的な潜在不具合数が算出できる
    • たとえば 100 FP なら、およそ 316 の潜在的な不具合があると見積もれる
    • CMMレベルが高ければ、1.25 よりも少なくはなる
  • FP の 0.25 乗で、必要な修正フェーズ回数を見積もれる
    • 100 FP なら、およそ 3
  • FP の 1.2 乗で、最大必要なテストケースの数を見積もれる
    • 100 FP なら、およそ 251
    • 最小限必要なテストケースを見積もりたいのであれば、 1.05 乗をかける
  • FP の 0.2 乗で、テスト実施回数を見積もれる
基調講演＆チュートリアルを受けての個人的な所感

基調講演の最後で、「これからの課題」みたいな項目に「自動テスト」とか「アジャイルプロジェクトのデータ」とか、個人的にキーワードになりそうなところが入ってて、へこーッとなりました。つまり、全体的にウォーターフォールモデルを前提とした話のようで、そのあたりはかなりビミョウ。。

チュートリアルの終わりで、質問者が「たとえばユニットテストのテストケース内容を修正して再度テストを実施した場合、それぞれでひとつのテストステージとカウントするのか、それとも合わせてひとつなのか？」といった質問をしたら、「なぜ同じテストを繰り返すのか理解できない」といったようなことを言っていたので、完全にウォーターフォール脳のような印象を受けました。(単純に、質問を誤解していたのかもしれませんが。。)

あと、テスト以外の、インスペクションやレビューでの不具合検出率をはかるためには、そこで見つかった不具合を個別に記録しなければいけないけれど、そのコストがけっこう高そう。

ただ、テストによるバグの検出率は今のうちのサイクルでも算出できるはず。あとは、本番バグの原因分析(仕様バグなのか、テストでの見落としなのかなど)や、メジャーリリース後のバグFixリリースでどういった項目を今まで対応してきたのかの確認などは、もうちょっとちゃんとやろうと思いました。

セッション D4 「テスト設計かじり虫」

残りの時間は、D4の小セッション3つを聞く。

「テスト分析の方法 HAYST法とマインドマップを使って」

仕様書から、機能的なカットだけでHAYST法のテストケース作るのではなく、マインドマップを使って顧客視点を盛り込むと、リスクも捉えた充実したテストケースが組めるよ、という話。顧客視点で見たときに現れる内容は暗黙知であり、経験であるが、マインドマップの各枝を知識ベースとして蓄積することで共有できる。それによって、これまでは障害として報告されてはじめて分かっていたことが、予測的にケースとして捉えることができるようになる。というような内容と理解しました。

HAYST法でテスト作ったことがないのでアレですが、今後、機能によっては参考にするといい部分があるかも。

「テストの”質”評価と欠陥分析によるソフトウェア信頼性評価」

信頼度成長曲線だけだと、テスト完了判断に使うのは微妙。テスト観点(テストの種類)ごとにテスト件数と検出されるバグ数の見積もりをたてておいて、実際に検出されるバグ数とつき合わせてフェーズごとに見ていくとより精度の高い曲線を得られるよ、という話。と理解しました。

うちも今は、実装する項目×平均検出バグ数という大雑把なかたちでしか見積もりたてていないので、このあたりの精度を上げることを考えるときに参考になるかも。少なくとも、実際に見つかったバグが、意図したタイミングに、意図したテストで出たものなのかどうか？という点はもう少し注意してみていくべきかと思いました。

「不具合に関する知識の抽出に関する研究」

バグの分析をする際、間違ったナレッジを抽出してしまわないようにしたい。そのため、誤解を招くような仕様や設計はアフォーダンスの観点から悪設計だとして、適切な原因分析のレベルに到達できるようにするべき、といった話。

正直、ちゃんと理解できた気がしていません。。プレゼンで紹介されていた例だと、「すでにメニューが表示されているときだけ、メニューボタンを押したときはメニューを表示するのではなく、メイン画面を表示する」こと、開発の際に間違いやすい(常にメニュー画面を表示するように作ってしまう)、といったことを言っていたが、この例だと、ユーザー視点からの仕様として求められているのでは？といった疑問を持ったので、いまいち納得感がありませんでした。

*1:「Defects」をとりあえずこのエントリーでは「不具合」と記述します

*2:数字はもしかしたら聞き間違えてるものあるかも…

改行コード混在ファイルの扱い

ちょっとしたPerlスクリプトをいじっていて、Windowsで保存したためにCSVファイル中の改行コードが(あたりまえだけど)CR+LFになっている文字列と、Perlのスクリプト中で組み立てた文字列との比較がなぜか一致しなくて地味にはまりました。。

http://perl.g.hatena.ne.jp/Cress/20070226/1172461972
こちらの記述を参考にして、結局は CR+LF があっても LF だけに置換するようにして対応しました。

もうこういう地味なところでひっかかるの止めたい。。