More Related Content More from Kuniaki Igarashi (20) 1. プログラマのためのテスト
Kuniaki IGARASHI
igarashikuniaki@gmail.com
http://igarashikuniaki.net/tdiary/
2007.4.16 3. なんでかというと、
バグの発生しやすいところ
人と人との境界
プロジェクトとプロジェクトの境界
そこを埋めるのはコミュニケーション、
そしてコードを使う人、読む人への思いやり、
ユーザーさんへの思いやり
そしてバグを無くす技術的手段の1つがテスト 5. テストってなんだろう？
IEEE 610.12-1990
ある特定の条件下でシステムまたはコンポー
ネントを操作するプロセスであり、その結果を
観察または記録して、システムまたはコン
ポーネントのある側面を評価すること
IEEE（The Institute of Electrical and Electronics Engineers, Inc.)(アイトリプルイー)
アメリカに本部を持つ電気・電子技術の学会。
非営利の専門機関。規格策定の有名どころ。
ISO (International Organization for Standardization) (アイエスオー、イソ)
工業標準の策定を目的とする国際機関。本部はスイス・ジュネーブ。 9. テスト技術のレベル
• レベル2
「テストの目的は、ソフトウェアが動作すること
を示すことである」
• レベル3
「テストの目的はソフトウェアが動作しないと
いうことを示すことである」
たとえば、干し草の山から針を探さなけ
レベル2とレベル3の差は大きい ればならないとします。あなた方はたぶ
ん、針が１本見つかるまで探すでしょう。
「ある」と思ってモノを探すか、 私は、針が全部、見つかるまで探し続け
「ない」と思ってモノを探すか。 ると思います。
アルバート・アインシュタイン 10. テスト技術のレベル
• レベル4
「テストの目的は、何かを証明することではな
く、プログラムが動かないことによって発生す
る危険性をある許容範囲までに減らすことで
ある」
ソフトウェアの不完全性に関する情報、
及び現時点で出荷した場合にどれだ
けマイナスのインパクトがあるかの
リスクを把握し、減少させる。 11. テスト技術のレベル
• レベル5 (最高レベル)
「テストは行動ではない。大げさなテストをすること
なく品質の高いソフトウェアを作るための精神的
な規律である。」
ポイント：
作ったものをテストするのではなく、
テスト容易性を考慮して設計・実装を行う。
今日、3番目に言いたいこと！！ 13. プログラマ向けの
主なテスト手法
UnitTest DailyAutoTest
ユニットテスト 自動テスト
ManualTest CodeAnalysis
手動テスト 静的コード解析 14. UnitTest
ユニットテスト
メソッド単位でコードを検証するテストコードを書き、
戻り値、副作用が妥当であることを確認するテスト
• コード修正時に想定以外の変更が生じても、
ユニットテストが発見してくれる
• 閾値に関するUnitTestをしっかり書けば、
バグの出やすい閾値付近でのバグ発生率減少
UnitTestのCode例
// テスト対象メソッド addition(int arg1, int arg2)
// 引数の和を返し、メンバ変数m_lastResultに結果を格納するメソッド
int result = addition(2,3); // テスト対象のメソッドを実行して
CPPUNIT_ASSERT_EQUAL((int) 5, result); // 結果を確認
CPPUNIT_ASSERT_EQUAL((int) 5, m_lastResult); // 結果を確認 15. DailyAutoTest
自動テスト
全体結合(または部分結合)し、
テスト対象を実行する環境を構築し
毎日テスト実施
メリット
•たくさんのテストを回すことができる
•毎日実行することでバグが入り込んだタイミングがわかる
•実行コストが非常に安価 (PC1台から可) 16. ManualTest
手動テスト
人の手による結合テスト
万能！
自動化をどんなに進めても、
手動検証なしでは出荷は不可能
検証エンジニアさんはすごい！
報告：動きがカクつきます
→絵が1枚落ちていた
→ 1/30秒を見切っている 17. CodeAnalysis コード静的解析
動的な実行を行わずに静的なコード解析を行うのもテストの一環。
• コンパイラワーニング
UnitTest実行よりも前にできるテスト
• ソース静的解析ツール
Fortify
バッファオーバーフロー、メモリリークなどを検出
• コードレビュー
やはり人の目で見るのは有益
• ペアプログラミング
常時コードレビュー
隣にぬいぐるみを置いて話しかけるだけでも効果があ
るそうです。 18. テストの種類 まとめ
メソッド単位でコードを検証するテストコード
UnitTest 実行時間：10分程度が好ましい
ルール例：これが通らない場合はコミット禁止
全体結合または部分結合テスト
DailyAutoTest 実行時間：9時間以内が好ましい
ルール例：エラーが出た場合はリリース禁止
人の手による結合テスト
ManualTest ルール例：致命的なバグが残っていればリリース禁止
CodeAnalysis 静的コード解析
ルール例：レビュー実施、リリースまでに解消 21. バグ発見までの時間
繰り返し
実装 社内リリース 検証 納品日
週1回程度
UnitTest ※
実装からの
DailyTest ManualTest
時間 このへんでバグがみつかると
数時間 1日 1週間 関係部署に迷惑をかける上、
修正後の手動検証も
限定的になってしまい危険
※但し、ManualTestまでの
時間を短くする工夫として、 出荷後にバグがみつかると
毎日自動でリリース作業 最悪、回収で大きな損害
さらにユーザー満足度も低下
も行っています。 22. バグを抱えない利点
ゼロ欠陥法(某M$社)
「いかなる場合でも新しいコードを書く前に
バグを取り除くことを最優先とする」
理由
• コスト
バグ修正にとりかかるまでの時間が長くなればなるほど、修正にかか
るコストは（時間においても金額においても）高くなる
• スケジュール見積もり
バグが存在している場合、スケジュールの見積もりは非常に困難。既
存のバグを修正する時間よりも、新機能を実装する時間の方が遙か
に見積もりし易い
→リスク見積もりができる 25. Test First Development
Test Driven Development
本番コードを書く前にユニットテストコードを書く
→ テストコードに駆動される開発
テストコードで境界値や全てのケースを網羅しようという意識になる
仕様が固まっていない部分は固めようとする
テスト容易な設計を考慮するようになる
テストを満たすように、突貫コードを書く
仕様破綻がないかチェックする
エラーケースをケアするコードを書く
リファクタリング 28. UnitTestデザインパターン
どのようなUnitTestを書けばいいのかを形式
化し、テストファーストをプログラマの習慣に
することを目指すwebページ
• web
http://www.marcclifton.com/tabid/87/Default.aspx
現在鋭意翻訳中
http://igarashikuniaki.net/fswiki/wiki.cgi?page=UnitTestPatterns 30. デイリーテストを
必ず実行するための工夫
• CriuseControl.NET
コミット時に自動的にビルド
→ビルドに失敗すればメールでお知らせ
参考文献：
http://igarashikuniaki.net/tdiary/20060824.html#p01
※本ドキュメントは概論であるため、↑と重複する部分があります。 31. デイリーテストのメリット
デイリーテストの成果
• お行儀の悪い素材でエラー処理が不適切なのを発見
• 外部製 library 置き換えによる挙動変更に気づく
• 実装した場所とは違う場所への副作用を発見
• 出力ファイルの差分をとることで発覚した不定値問題
• 過去に不具合のあった素材をテストし不具合再発防止 33. テストの基本はお手本との差分
テスト出力結果 正しい出力結果
差分比較ツール
• Fc - Windows 標準コマンドラインツール
• Diff - Unix, Linux
• ExamDiff - Windows GUIツール シェアウェア 35. ログ比較テスト
ソースコードの要点にログ書き出しを仕込んで置く。
Input 変数Dumpや、関数のIn/Outなど。
変数の内容や処理経路が異なる場合に発見できる。
テスト対象 お手本
ソースコード
Log Log
差分比較
Reference
Output 下回りのライブラリが置き換えられた場合も、
自分たちのコード上を通る経路が
変わる場合は違いに気づける。 36. 出力適格判断テスト
Input 出力が規格に適合しているか調べる
テスト対象 Reference
ソースコード お手本
規格適合性
チェックツールを 結果
入手または作成
差分比較
規格Checker
Output 結果 37. パフォーマンス測定
パフォーマンスを定期的に測ることで
Input パフォーマンス悪化を早期発見、原因把握
テスト対象
ソースコード
出力にかかる グラフ化
Output
時間を測定
→コード履歴をみれば悪化
の原因を絞り込める 43. 参考文献
• はじめて学ぶソフトウェアのテスト技法
著：リー・コープランド ISBN : 4-8222-8251-1
これ1冊でプログラマレベルではテストマスター
• CPPUnitによる実践テスト技法
http://www.mikamama.com/CppUnitBook/draft/index.html (draft)
著：大月美佳 ISBN:4-7980-0571-1
ユニットテストの入門書。リファレンスとしても便利。
• 知識ゼロから学ぶソフトウェアテスト
著：高橋寿一 ISBN:4-7981-0709-3
SONYのテストエンジニアさんの著書。
実際の経験に基づくノウハウが多数。
