Tests and bugreports

Transcript

1. 1 Tests and bugreports @ItSANgo
2. 2 Who am I • @ItSANgo • http://d.hanena.ne.jp/Itisango/ • http://mixi.jp/show_profile.pl?id=789759 • http://www.facebook.com/profile.php?id=1000058 33863069 • 無職透明 – 時間だけはたっぷりある • TOEIC 355点 – 英語は話せない
3. 3 何を話すか • Tests • Bugreports • 間違っていることが書いてあったら指摘してくださ い(_ _) – 今ここで – TwitterやBLOG等にコメントでも
4. 4 Tests
5. 5 Testといってもいろいろあるよね • http://ja.wikipedia.org/wiki/%E3%8 2%BD%E3%83%95%E3%83%88%E3%82%A6%E %82%A7%E3%82%A2%E3%83%86%E3%82%B9 E3%83%88 • 単体test – sourceをdownloadしてmake checkを走らせるとか… • 結合test • ホワイトボックステスト – 無理(-_-) • ブラックボックステスト
6. 6 testのresource • 人 – tester • 物 – test対象 – test環境 – test仕様・test項目 • 金? – そんなものは無いw • 時間 – スケジュール – 納期
7. 7 ここで扱うtest • 対象 – FLOSS – Linuxのdistribution • 網羅は不可能 – リリース前test • RC版 、Alpha, Beta版 • Tester – 人数不定 – 緩い統制 – スキル不揃い • Method – test仕様は? • →題して「つれづれtest」
8. 8 きっかけ • opensuse-jaMLのmailから – http://lists.opensuse.org/opensuse-ja/2013-02/msg00002.html • testと聞いたら血がたぎる
9. 9 Testの方法は • Test仕様がある場合 – 例: Ubuntu-Japanese RemixのQAテスト – https://wiki.ubuntulinux.jp/Develop/Precise/QA/RemixCDImage • Test仕様がない場合 – 自分でtest仕様を作るしかない。 – まじめに考えると結構重たい作業だが…
10. 10 openSUSE jaの場合 • 一応test項目は有る…けど緩やか – https://ja.opensuse.org/Test_Weeks
11. 11 test環境の準備 • VMが便利 – VirtualBox個人的にお勧め – 特にinstallのtestで威力を発揮する。 • 実機でのtestも必要 – 実機でしか起きないbug – すみません、あまりtestしていませんorz • VMでしか起きないbugはどうする? – →報告する。 • VMも動作環境だ! • VM上のbugが潜在的な問題を持っている可能性
12. 12 test項目の洗い出し • とにかくたくさん洗い出す – 網羅性 – 掛け算で考える (ex: (実機 + VirtualBox + VMware) * (x86 + x64) * (DVD + netInstall) * (KDE + GNOME + Xfce + LXDE + xdm + server)) – すべきこと • softwareの目的が達成されているか? – Ex: editor → 編集できるか?fileの保存はできるか? – やりたいこと • 自分の興味で自由にw • test項目はmemoしよう。 – plain texｔで充分w
13. 13 すべきこと • testするんだからこれは必要だよねという項目を入れる • test環境の準備もtest項目に入れてしまえ! – 私がtest項目に入れているのはこれ(openSUSEの場合) • chmod 1777 /var/crash • /etc/security/limits.confの編集 – * soft core unlimited • /etc/sysctrl.d/60-core_pattern.conf – kernel.core_pattern =/var/crash/core.%e.%u.%t • Reboot • cat • C-\ (/var/crash/ にcoreが吐かれるか?) – これらをcommandやeditorのtestを兼ねて実行する。
14. 14 testの実行と見直し • test結果をmemoする(OK/NG) • NGの場合は何が起こったか記録 • testしていくうちに、新たにtestすべき項目が見つかる。 – 漏れ – 怪しい動き→もっと条件を変えてtest – 探索型・発見型test(自分も仕様を知らないsoftのtest) • それもtestに入れる • test項目は膨らむ
15. 15 トリアージ • test項目が膨らみ自分の手に負えなくなったときに • 掛け算を崩す • (実機 + VirtualBox + VMware) + (x86 + x64) + (DVD + netInstall) + (KDE + GNOME + Xfce + LXDE + xdm + server) • 類似のtestを省く • 自分が出くわしたら困ることを中心にテストする • 過去の経験を基にtest項目を取捨選択する • test項目自体は消さない – 何をtestしたか・していないかのevidence
16. 16 トリアージが裏目に出ることもある • こんなbugは出ないだろ→出ます • https://bugzilla.novell.com/show_bug.cgi?id=829298 • 64bit環境と32bit環境双方でtest OK, 各desktop 環境でtest OK – でも… GNOME KDE Xfce LXDE 64bit ◦ ◦ ◦ ◦ 32bit ◦ × - - テスト未実施
17. 17 見逃さないためには • みんなでやろう • 手分けしてやろう – 見落とし・見逃しが潰せる • 皆さん、一緒にテストしませんか?
18. 18 課題 • Server系のtest – 切り分けが難しい • Bug? • 設定miss? ←大概はこっち • ガチガチに環境を規定して、その範囲内でtestする 必要性? – ユースケースに合わせたtest – →企業内でのtest
19. 19 Bugreports
20. 20 Bugが出たらreportすればいいのよ • どこに • 何を • どうやって
21. 21 どこに • 日本語forum (ex: Ubuntu日本語フォーラム) • 日本語ML (ex: openSUSE-ja ML) • distributionのbug-tracking-system (Bugzilla)等 • 英語ML (ex: openSUSE Factory ML) • 上流(software開発元)のbug-tracking-system (ex: LibreOfficeのBugzilla) • 上流のML (ex: gcrypt-devel ML) • 等々
22. 22 どの順番で • 日本語で議論できるところがあるならまずそこで。(forum, ML) • Bug報告の必要性があるならbug-tracking-systemや英語ML へ – bugに違いないことが明らかな場合 – 日本語forumで何の反応もない場合(;_;) • 上流Softwareに報告する必要があるなら後から上流bug- tracknig-systemやMLへ • この辺は事情により前後します – Bug report systemが自動起動する場合。 – KDEなどはちょっと特殊
23. 23 Accountを取ろう • Bug-tracking-system siteとaccount取得pageの一覧 openSUSE https://bugzilla.novell.com/index.cgi https://secure-www.novell.com/selfreg/jsp/createAccount.jsp Fedora https://bugzilla.redhat.com/ https://bugzilla.redhat.com/createaccount.cgi CentOS http://bugs.centos.org/main_page.php http://bugs.centos.org/signup_page.php Ubuntu https://bugs.launchpad.net/ubuntu/ https://login.launchpad.net/+new_account Debian http://www.debian.org/Bugs/ mailベースなのでaccount取得pageは無し
24. 24 OS以外のbug-tracker-account KDE https://bugs.kde.org/ https://bugs.kde.org/createaccount.cgi GNOME https://bugzilla.gnome.org/ https://bugzilla.gnome.org/createaccount.cgi LibreOffice https://bugs.freedesktop.org/describecomponents.cgi? product=LibreOffice https://bugs.freedesktop.org/createaccount.cgi VirtualBox https://www.virtualbox.org/wiki/Bugtracker https://myprofile.oracle.com/EndUser/faces/profile/createUser.jspx
25. 25 MLを購読しよう • 本来はbugreportが目的じゃないMLも – でも他に相談するところがない – 不具合に関する相談ならありじゃない? • あまりに沢山あるので省略(_ _)
26. 26 既に報告されていないかチェック • 既に報告されていても、あなたにはやることがある! – 自分の環境でも再現したという報告 • もちろんあなたの環境を詳細に報告 – 追加情報の提供 • 再現条件 • 再現率 • logその他のdata
27. 27 何を • まずはbugを詳細に分析する • 再現性を確かめる • 繰り返し操作したらどうなるか? • 同じ条件で再現するか? • 条件を変えたら?(ex: VMware→VirtualBox) • OSを変えてみる(openSUSE→Ubuntu) – 特定distributionのみの問題か、一般的な問題か? • 版を変えてみる(openSUSE 13.1 →12.3) – デグレートか否か?
28. 28 log,backtrace, etc... • coreを吐いているならbacktraceを取ろう • logを吐いているなら採取しよう。 • でもどんなアプリがどんなlogをどこに吐くんだろう? • そこでこれらのpage – https://ja.opensuse.org/%E3%83%90%E3%82%B0%E3%8 3%AC%E3%83%9D%E3%83%BC%E3%83%88 – https://en.opensuse.org/openSUSE:Submitting_bug_reports – https://wiki.ubuntu.com/DebuggingProcedures
29. 29 backtraceの取り方(××の一つ覚えw) • core を吐いたcommandの特定 – file core • Debug symbolの取得 – Fedora, CentOS等の場合 • debuginfo-install command – openSUSEの場合 • gdb command core 2>err.txt • egrep '^Try: ' error.txt | sed 's/^Try: //' | sudo sh – Ubuntu・Debianの場合 • 次で説明します。 →めんどくさいので、頑張れ!!! • backtraceの取り方 – LANG=C gdb command core 2>&1 | tee backtrace.txt – thread apply all backtrace full • coreは残しておこう – 提出を依頼されることもあるので
30. 30 backtraceの取り方(Debian系の場合) • 1. パッケージそのもののdbgシンボルを取る。 – sudo apt-get install nautilus-dbg • 1. GDB でbacktraceを取る。 – $gdb /usr/bin/nautilus core 2>&1 | tee bt.txt – (gdb) thread apply all bt • 2. backtrace からlibrary名一覧を抽出する。 – $awk '/from/ { print $NF }' bt.txt | sort -u >libs.txt • 3. library名以外のゴミを取り除く。 – $vi libs.txt • 4. library名からpackage名を引く。 – $dpkg -S `cat libs.txt` | awk 'BEGIN { FS = ":" } { ++p[$1] } END { for (i in p) { print i }}' >pkg.txt • 5. dbg packageをinstallする。 – $sudo apt-get install `sed 's/$/-dbg/' pkg.txt` • 6. 失敗するpackageがあるなら削除して、5.をやり直す。 – $vi pkg.txt – $sudo apt-get install `sed 's/$/-dbg/' pkg.txt` • https://forums.ubuntulinux.jp/viewtopic.php?id=15386
31. 31 報告の形式 • titleは少々長くていいから具体的かつ詳細に…。 – On Virtualbox, when I search "terminal" or "console", sometimes the gnome-shell crashes with SIGABRT in __GI_raise() at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 . • (どういう環境で)何々をしたら、こうなった。 – (On ～,) when～, ～ – If ～, then ～ • 動作環境・packageのversion – 特にOSのversionは正確かつ詳細に • 再現率 – 必ず?5回に1回?、1日に5～6回?… • 具体的な再現手順 – 箇条書きが楽 – 命令形で • こうなった – 次の「こうあるべき」と対比させるために書く • でも本当はこうあるべきだよね。 – ～should～
32. 32 どうやって(1) • ディストリビューションがbug reportの仕組みを持っ ている場合 – それを使う ディストリビュー ション システム コマンド Ubuntu Apport ubuntu-bug CentOS ABRT abrt-gui Fedora(19) ABRT gnome-abrt openSUSE - - Debian reportbug reportbug
33. 33 どうやって(2) • ディストリビューションがbug reportの仕組みを持っ てい無い場合 – Bug tracking systemに直接login
34. 34 英語の壁 • パターンで乗り切れ – 「報告の形式」参照 – When～, if～,… • 強い味方があるじゃないか – Excite • http://www.excite.co.jp/world/english/ – Google 翻訳 – Gmail • 他の人のbug reportを読む、参考にする – nativeの人より、英語の下手そうな人のreportが参考になる • より深い突込みが来たら – 何かしてくれ、と言われているようだが、なんだかよく解らないとき • What should I do concretely? • (具体的に何をすればいいんだい?） – 日本語MLで相談w
35. 35 今後の課題 • 自分でpackageを修正できるようになれば…(野心) – その点openSUSEは敷居が低い(OBS: Open Build Service)
36. 36 まとめ • とにかく行動 • 英語を恐れるな! • testしよう。bugreport書こう • softwareの品質が上がる • あなたには勉強になる – しかも楽しい。 • 一石二鳥じゃね?