Tests and bugreports

Editor's Notes

1. testとbugreportについて話をしたいと思います。
2. Netでは135を名乗っています。 現在、職についていません。暇だけが資本です。 有意性は切れていますがTOEIC355点ということで英語は全然できません。
3. Softwareのtestとbugreportについてお話ししようと思います。 時間の都合で全てお話しすることができないかもしれません。 この資料はnetからdownload出来るようにすることを予定しています。 お話できなかったところはdownloadした資料を参照してください。 入手方法は東海道らぐmailing list等でアナウンスする予定です。 間違っているところも多々あると思いますが、都度、ご指摘お願いいたします。 公開後はTwitterやBLOG等で誤りを指摘していただくと助かります。
4. まずはtestについて話をしたいと思います。
5. testといってもいろいろありますよね。 Wikipediaには様々なtestについて解説されています。 またtest関連の書籍などもいろいろ出ていると思います。
6. テストに必要なものをresourceとして挙げてみました。 test対象がないとtestにはなりません。 それにtesterやtest環境がいないとtestは始まらないですよね。 test対象があればtest仕様も当然あるはずですよね。 testには時間がかかるのでこれもresourceです。 多くのtestでは納期やスケジュールが有るはずです。
7. 一般論は置いておいて、ここで扱うテストについて説明したいと思います。 ここでは主にopenSUSE等のLinuxのdistributionのリリース前testについて話をしようと思っています。 OSは大きいので網羅というのは不可能です。 OSのテストというのはsoftwareの規模に対してtesterの数は圧倒的に不足します。 testerもどこの組織に所属している訳でもない緩やかなcommunityのmemberであると考えられます。 testerのskillもまちまちで不揃いです。 testの方法論も確立しているのか、test仕様があるかどうかも怪しい状態です。 こんな中で「つれづれなるままに」testをしていくので、ここで扱うtestを私は「つれづれtest」と呼んでいます。
8. そもそもtestを始めたきっかけについて説明したいと思います。 最初は今年(2013年)2月にopensuse-ja mailing listに流れた一通のtest依頼mailがきっかけでした。 正直、私はtestが大好きです。testと聞いたら血がたぎります。 暇もあったのでopenSUSE 12.3 RC版を私は徹底的にtestすることにしました。
9. （quality assurance testing / 品質保証テスト） Testの方法についてお話ししたいと思います。 testは仕様の有る無しによって大きく2種類に分けられると思います。 Ubuntu-Japanese RemixのQA testの様にtest仕様がある場合にはそれに従ってtestすれば良いと思います。 test仕様がない場合、自分でtest仕様を作る必要があります。真面目に考えるとものすごく手間のかかる重たい作業です。
10. openSUSEの場合、一応test項目のワクはあったのですが、ざっくばらんで詳細が詰められていない感じでした。mailing listにも「作りかけ」とありました。 →「なら自由にやらせてもらおう」、というのが私の本音です。
11. testをするにはtest環境が欠かせません。 仮想環境があると重宝します。 installer周りのtestを繰り返す必要がある場合にはとても便利です。 個人的にはVirtualBoxがWindowsの上でも使えてしかも只なのでお勧めです。 実機と仮想環境は異なるので実機か仮想環境、どちらかでしか起きないbugもあり得ます。だから実機でのtestも必要です。が、私はinstall出来る実機を持っていなかったので実機でのtestはほとんどやっていません。 Windows PCにinstaller DVDを突っ込んでbootするかどうかを確かめた程度です。 ところでVM上でしか起きないbugが出た場合、どうすべきだと思いますか?私はVMも動作環境だと考えています。またVM上の異常動作が実機にも影響する可能性もありますので、bugreportすることにしています。
12. test項目を洗い出します。 test項目は思いつく限りたくさん洗い出した方がいいと思います。 コツは掛け算というか、組み合わせで考えることです。例えば、実機と仮想環境で分けて考え、KDE・GNOME・Xfce・LXDEなどデスクトップ環境で分けて考え、32bit環境と64bit環境とで分けて考えるとか組み合わせで考えれば、あっという間に項目は膨らみます。 またtest対象のsoftwareの目的に応じて、すべきことを洗い出します。例えばEditorなら編集できるか、fileの保存ができるか、などがtest項目になります。 あと、つれづれtestでは自分で個人的に試してみたいこともtest項目として書きだします。 test項目はplain textで良いので、どこかにmemoしておきます。
13. testすべきことにちょっとだけ補足します。 そのsoftwareが持っている基本的な機能は、たとえ、そんなところにbugは無いだろうという初歩的・基本的ことでも必ずtestします。 例えばLibreOffice BASEの場合、table・query・form・reportの作成を項目に入れます。 (ちなみにLibreOffice BASEのreportはエンバグしやすい項目なので必ずtestします。実際にFedora19でreportが作成できないというbugがありました。https://bugzilla.redhat.com/show_bug.cgi?id=983809 ) ついでにtest環境の準備作業もtest項目に入れておきます。 例えば最近のLinux distributionはdefaultでcoreを吐かせないように設定されています。これをcoreを吐かせるように設定変更します。これがcommandやeditorのtestを兼ねているのでtest項目に入れます。 ちなみにここに書いている設定はどんなsoftwareのcoreも/var/crash/ directoryに格納するという設定です。openSUSEのtestの際にはとても便利です。
14. 実際にテストを実行します。 test成功・失敗をmemoしていきます。 testに失敗した時には何が起こったかをmemoします。 ところでtestしているうちにもっとtest項目を増やしたいと思うことがあります。 test項目漏れや、不思議な挙動をするのでもう少し調べたい時などがそれです。 そんなときは遠慮なくtest項目を増やしていきます。 softwareの仕様を調べながらtestしているときも次々とtest項目が思いつくと思います。 したがってtest項目はどんどん増えていきます。
15. でも、test項目が増えすぎたら手に負えなくなります。 そんなときにはtestを省略する必要があります。 test項目を書いたmemoには残しておいて、何をtestしているか・していないかを記録しておきます。 掛け算で考えていたところを崩して足し算で考え直します。 例えばslideの例では掛け算にすると（3*2*2*6=)72通りのpatternをtestしなければいけなくなりますが、足し算で考え直すことで13通りにまでpatternが減らせます。 bugっていたら困る機能を中心にtestします。 過去の経験からbugが出やすそうなところを残し、大丈夫だろうと思うところはtestを省きます。
16. でもトリアージが裏目に出ることが有ります。 一例ですがこんなことがありました。 64bit環境と32bit環境のtestに成功し、64bit環境上のGNOME, KDE, Xfce, LXDEでのtestに成功したので、もうDesktopまわりのbugは出ないものと思っていました。 しかし、testを省略した32bitのKDE環境にbugが潜んでいました。32bit環境でのみKDEのshellがcrashし、loginしても使えないという影響の大きいbugでした。
17. トリアージによる見落としを避けるためにはみんなで手分けしてtestをすることが有効だと思います。 また、余裕があれば複数人で同じtestをやることでtestの精度を上げることができます。 皆さん、一緒にtestしましょう。
18. つれづれtestについて説明してきましたが、このtestには弱点もあります。 Server・daemon系のtestはつれづれでは難しいのです。 いざ、おかしなことが起こったとき、それがbugなのか、設定ミスなのか、つれづれでは区別をつけるのが難しいです。Server・daemon系の場合、多くは単に設定を誤っていただけということが多いです。 Serverをtestするにはガチガチに環境を想定して、その範囲内でtestする、つまりtest設計をしっかりする必要があります。 業務でserverをいじっている方々は当然やってますよね?w
19. 次にbugreportについて話をしたいと思います。
20. Bugが出たらreportすればいいのですが、それが割と面倒くさいです。それをこれから解説していきたいと思います。
21. Bugの報告先はいろいろ考えられます。 日本語で報告したければforumやmailing listに報告することができます。 英語になりますがbug-tracking-systemがあれば、それを使えばいいでしょう。 mailing listも使えるかもしれません。 さらに上流のbug-tracking-systemやmailing listも報告先として考えられます。
22. ではどの順番で報告すべきでしょうか? 日本語で議論できるところがあれば、まずそこで議論すればよいと思います。何しろ日本語で話ができて便利です。 その上でBug報告の必要があるならbug-tracking-systemへ上げればよいでしょう。英語に自信があるなら英語mailing listで議論してもいいと思います。 上流softwareのcommunityに報告する必要があるならdistributionへ報告してから上流のbug-tracking-systemやmailing listに報告しましょう。 Bug-report-systemが先に起動する場合はそちらへの報告が先になるかもしれません。(特にKDEはdistributionのbug-reportを飛ばしてreportする仕組みが有るのでそちらへの報告が先になるかもしれません。)
23. Bug-tracking-systemを使う上で面倒なのはaccountを取る必要があることです。ここでは主なdistributionのBug-tracking-system siteとaccount取得pageのURLを掲示しています。 赤いURLはBug-tracking-systemとAccount取得pageのsiteが異なるので注意が必要なところです。 openSUSEはNovellのSingle Sign Onが必要になります。
24. OS distribution以外の上流softwareのBug-tracking-system siteとaccount取得pageのURLも掲示しておきます。 私は一応これだけのaccountを取っています。 VirtualBoxは上流softwareとは言えませんが、重要なtest環境ですので、accountを登録しています。 VirtualBoxもOracleのSingle Sign Onが必要になります。
25. Bug-tracking-systemのaccountだけでなく、mailing listも購読しておきましょう。 mailing listで注意すべきなのは本来がbugreportが目的ではないmailing listがあることです。 不具合に関する相談に留めておくのが無難かもしれません。 主要なmailing listを載せようかとも思ったのですが、数が膨大なのと、今述べたようにmailing listの目的がbugreportとは異なる場合が多いので割愛します。
26. Bugらしき現象を見つけて、最初にすることは、そのbugが既に報告されていないかを調べることです。 Bug-tracking-systemで検索します。 既に報告済みの問題でも、自分が書き加えることで問題が進展するかもしれません。 自分の環境で再現したという事実と再現環境を書き加えましょう。 再現条件や再現率を書き加え、log等のdataがあれば添付します。
27. 何を報告するかを決めるためにbugを詳細に分析します。 再現性があるか、繰り返し操作したらどうなるかを確認します。同じ条件や、違う条件で色々testしてみます。 余裕があるならOSを変えてみたり、版を変えてみたりしてtestします。 条件をいろいろ変えることで、再現条件が絞り込めます。 但し、今挙げたことを全部やっているととても時間がかかるのでcase by caseで対応します。
28. Programがcoreを吐いていたならbacktraceを取ります。 coreの提出を求められることもあるので、coreは消さないで残しておいた方が良いかもしれません。 logを吐いているなら採取します。 問題は、applicationによって吐き出すlogが異なることです。 どんなlogをどうやって取ればよいかについては、詳しく解説されたpageがUbuntuやopenSUSEのsiteにあるのでご紹介しておきます。 例えばLibreOfficeならstraceを取るのが有効だとか、Firefoxでは逆にそれが役に立たない、などの情報が載っています。
29. backtraceを取るにはGDBを使う必要があります。でも難しくはありません。 まずfile coreでcoreを吐いたcommandを特定します。 command を特定したら、gdbにかけます。標準error出力にhintが現れるので、そのhintを元にdebuginfoをinstallします。 FedoraやCentOSなどYUM系のdistributionの場合はdebuginfo-install command一発でdebuginfoをinstall出来ます。 openSUSEの場合はgdbのerror出力を少し加工してやってshellに食わせる必要があります。 Ubuntu, Debianの場合は少しややこしいので後で説明します。 backtraceの取り方はgdbを起動し、全てのthreadに対してbacktraceを取るだけです。これは丸暗記しておいて損はないです。 ちなみにbug reportを出したcoreは残しておいた方が良いです。稀にですが提出を依頼される場合があります。
30. DebianやUbuntuの場合のdebug symbolの取り方です。commandが依存するlibraryの一覧をGDBで取ってきて、libraryがどのpackageに属するか調べて、そのpackageのdebug symbolを取ってきます。別に難しくはありませんが、正直面倒くさいです。
31. Bugreportの文章は大体形式が決まっています。 titleは少々長くていいから具体的にかつ詳細に書きます。「どういう環境や条件で」「何をしたら」「こうなった」という形式で書くと書きやすく、また解り易くなると思います。英語ではWhenやifを使えば簡単に書けると思います。但しbug-tracking-systemによっては、titleの長さが制限されている場合があるので、その場合には、本質的でないところを削って長さを合わせます。 本文でも「どういう環境や条件で」「何をしたら」「こうなった」を書きます。titleで書いたからといって、本文でその内容を省略するというようなことはしないでください。本文でもtitleで書かれた事を繰り返しさらに詳細に説明します。titleの長さ制限で書けなかったことも、本文では書けるので書きます。 bugreportの目的は開発者に再現手順を示すことです。「こうなった」という結果よりも「どういう環境や条件で」「何をしたら」の方を優先して詳細に書きます。 英語ならwhenやifを使えば文章が作り易くなると思います。 動作環境やpackageのversionを書きます。OSのversionは正確に書く必要があります。 再現率も書きましょう。必ず発生するのか、n回にm回なのか、t時間にn回なのか、具体的に書きます。 具体的な再現手順を箇条書きで書きます。英語なら命令形で書くと楽です。 起きた結果を簡潔に書きます。 最後に本来ならこう動くべきだという動作を書きます。英語なら「should」を使った文章を考えれば良いでしょう。
32. メジャーなdistributionはbug report systemを持っています。bug report systemを起動するcommandを掲載しておきます。bug report systemはapplicationの種類に応じて採取するlogを自動的に選択してくれるので便利です。 Bug report systemはprogramがcrashした場合、自動的に起動します。 便利な機能ですが、予想外のbugに出会って、急に入力画面が出てくると驚き、焦ります。GUIが壊れた場合などは入力するのが辛いこともありますが、落ち着いて入力する必要があります。 また、それぞれのcommandは使い方が微妙に異なるので、慣れておく必要があります。 メジャーなdistributionを調べてみましたが、openSUSEだけがbug report systemを持っていないようでした。残念です。
33. openSUSE等のようにdistributionがbug report systemを持っていない場合は、bug-tracking-systemに直接loginしてbugを入力する必要があります。また、bug report systemを持っているdistributionでも、それを使えない場合というのがあります。例えばFedoraのABRTは、crashしたcommandしかreport出来ないと思います。 自分の使っているdistributionのbug report systemのaddressは覚えておくとよいでしょう。
34. Bug reportで困るのは英語の壁があることです。言葉の壁でbug reportをためらってしまいがちです。でも英語ができなくてもbug reportは可能です。 英語を恐れることはありません。何とかなります。 まずpatternを活用することです。先ほど説明した「報告の形式」にあるpatternを活用してください。one patternでも一向に問題ありません。目的は相手にbugの存在と再現手順を伝えることです。それのみに注力してください。再現条件はwhenやifが使えると思います。 難しい文章を作成する必要が出たときや、解らない英語に出会ったときには翻訳サイトが役に立ちます。 私はExciteを使用しています。またgmailの翻訳機能もmailing listで役に立ちます。但しgoogleの翻訳はたまに否定文を肯定文として扱うなど、あべこべに訳すので注意が必要です。 他の人のbug reportを読んで、参考にしてください。このときnativeのこなれた英語よりも、自分のlevelにあった、英語の下手そうな人の英語の方が参考になります。mailアドレスやreporterの名前から国籍を推定できます。但し英語圏以外の人でも学歴が高い人はnativeに近い文章を書く場合があるので用心しましょう。 reportの後、返事が返ってきて、その返事の意味を取りかねることがあります。 どうしても意味が解らない時には、正直に英語が下手であることを打ち明けて、具体的に自分が何をすべきであるのか指示を仰ぎましょう。 日本語mailing listで「○○のbug reportで返事が返ってきたんだけど何て言っているのかな?」と相談を持ちかけるのも手だとおもいます。
35. testとbugreportについてお話してきましたが、bugreportを出すことで終わりになるとは私は思っておりません。 本当はpackageの修正にも手を染めたいと思っています。 packageのメンテナンスについてはopenSUSEのOpen Build Serviceが敷居が低くて取りつきやすいと感じています。