20080615 wacate
•13 likes•2,565 views
Report
Share
Download to read offline
2008/6/15 WACATE
More Related Content
Viewers also liked
Viewers also liked(12)
More from Kouichi Akiyama
More from Kouichi Akiyama(16)
20080615 wacate
- 1. 品質本部 システム品質評価部 秋山 浩一 （NPO法人 ASTER） ■WACATE 2008 夏 ソフトウェアテストがおもしろい理由 2008年6月15日
- 2. 2 目次 1. 自己紹介 2. テストの7つの原理 3. 現在の私のテーマ
- 3. 3 自己紹介＆関連イベント 1985年4月1日： 入社（Smalltalk, UNIX WS, Network） 1996年11月21日： ソフトウェアテスト技法＆ツールを作る仕事に従事 2000年5月30日： TEF参加 2000年9月25日～9日： ２WCSQ：田口氏の発表の後に西さんの発表を聞く 2000年10月1日： TCS翻訳プロジェクト始動 ～2001年11月26日： 『基本から学ぶソフトウェアテスト』出版 2002年5月8日： LLST翻訳プロジェクト始動 ～2003年4月21日： 『ソフトウェアテスト293の鉄則』出版 2003年3月6日： JaSST’03（第一回） 2004年1月27日～28日： JaSST’04「HAYST法」発表 2005年1月5日： 『ソフトウェア・テストPRESS Vol. 2』出版 2005年12月12日： NPO法人 ASTER設立 2006年1月31日： JTCB（JSTQB）FLトライアル試験 2007年7月31日： 『ソフトウェアテストHAYST法入門』出版 2008年5月10日： 『ソフトウェアテスト入門』出版 現在： 『Foundations of Software Testing』共同翻訳中 SQiPテストWG、SEA: SS2008テストWG、SEC
- 5. 5 温故知新： 世界初のテストシンポジウム When: 1972年6月２１日～22日 Where: ノースカロライナ大学(University of North Carolina) Who: ヘッツェル(William C. Hetzel)＠大学計算センタ What: 計算機プログラム・テスト法のシンポジウム (Computer Program Test Methods Symposium) Why: テストの重要性に焦点を絞り、プログラム・テストに おける現状技術の断面図を定めること その結果は、Hetzelによって”PROGRAM TEST METHODS”という書籍にまとめら れ、1973年に出版され、日本では、鳥居 宏次（奈良先端科学技術大学院大学特任教 授）によって、翻訳され1974年9月1日に『プログラム・テスト法』として出版され た。 日本初の『ソフトウェアテスト本』！！
- 6. 6 テストの7つの原理＠『プログラム・テスト法』 1. セグメンテーション 2. 可テスト性を持つ設計 3. シミュレーション 4. サンプリング 5. 論理的簡約 6. 標準化 7. 自動化
- 7. 7 テストの原理１. セグメンテーション 複雑で大きな問題を数多くの小さな部分的な問題に分割し、それぞれ別 個に取り組むこと。テストを階層的に構造化しようというアイデア。 Wilkesがサブルーチンを使用（1951） Dijkstraによるストラクチャード（構造化）プログラミング（1968） Parnasのモジュラー・プログラミング（1971） Millsのトップ・ダウン・プログラミングとセグメント（1971） ＜現在の方法＞ • 複雑の定義： 本質的複雑性、偶発的複雑性（環境に持ち込まれた複雑性） • フェーズ： テストレベル（コンポーネント、統合、システム、受け入れ） • 視点： テスト種別（構造視点、仕様視点、顧客視点、エラー視点） • 技法： 同値分割、マインドマップ
- 9. 9 テストの原理２. 可テスト性を持つ設計 「テストを可能とする設計」というアイデア。 全体の設計とコーディングの過程を通してテストは計画されなければ ならないという認識が出てきた。 テストが可能なように問題の仕様を決めることで、暗黙的に理解され る仕様を排除し、仕様のあいまいさと誤解をなくす。 スタブを用意して全ての開発が終わらなくてもテスト可能にする。 ＜現在の方法＞ • テストプロセス： W字モデル（テスト技術を使いバグの総数を減らす） • テスト駆動： テストファースト、xUnit • 要件の検証： 要件を決める時に「テスト可能性」をレビュー • FV表： 機能と検証をセットにしてアセスメント
- 11. 11 テストの原理３. シミュレーション ソフトウェアの動作環境をソフトウェアでシミュレート。 容易に特別な環境を用意できる。 サブモジュールをテストするために主モジュールをシミュレートする。 ⇒ スタブ的シミュレータ ＜現在の方法＞ • 自動化： 組込み系ソフトウェアの自動化に無くてはならない技術 • カバレッジ： 特殊なエラー条件をシミュレート • ユースケース： ユーザシミュレーション（統計的テスト技法）
- 12. 12 統計的テストは状態遷移図を遷移確率にしたがってランダムにパスを 選択し、選択されたパスが正しく処理されることを順次確認していく。 A B C D E F70% 30% 100% 60% 40% 100% 10000件テストを自動生成した場合 A→B→F： 7000件 A→C→D→F： 1800件 A→C→E： 1200件 のテストケースがランダムに生成される ※ A～Fは状態を示す 初期 SCAN To BOX UI確認COPY To PC 統計的テストの技法
- 13. 13 テストの原理４. サンプリング 品質を評価するときに、全体のプログラムを詳細に解析するのではなく、 サンプルした部分だけを分析して得られた結果に対して外挿を行う方法。 エラーシーディングによる統計的テスト方法。 ＜現在の方法＞ • 技法： 探針（区間推定） • データ解析： パフォーマンステスト（区間推定、サンプル数の決め方） • エラー埋め込み： テスターのモチベーション向上
- 15. 15 テストの原理５. 論理的簡約 プログラムを「論理的性質を温存しながら」単純化、簡約化。 ⇒ フローチャートや有向グラフへの変換 モデルを作る ＜現在の方法＞ • Black Box技法： モデルテスト（テスト観点の列挙、整理、検討： NGT） 状態遷移テスト（統計的テスト） 組合せを数個の因子で検査（直交表、All-pairs） • White Box技法： モデル検査（SPIN）、形式手法
- 16. 16 入力 信号因子 M {M1, M2, M3,…} 出力 y (レスポンス) ノイズ 誤差因子 z {z1, z2, z3 ・・・} 対 象 システムチャート read write 内部変数の組合せ（＝状態） 信号因子 m {m1, m2, m3 ,…}
- 17. 17 テストの原理６. 標準化 コーディング規約。 インターフェースの標準化によるテストの問題の簡単化。 ＜現在の方法＞ • 技法： 「MISRA-C」（元々は車載用ソフトウェアを対象とした規約） • 静的解析： コーディング規約の遵守チェック • テスト資産： インターフェースに対するテストの資産化
- 18. 18 テスト工程の改善と上流工程の改善を 対にして進める。 テスト分析 テスト設計 テスト項目作成 テスト実施 玉石混合 となってつ き進む テスト 技法導入 支援 ツール開発 テスト 教育 テスト 戦略 ツール 活用 標準化２ 改善 改善 改善 標準化３ 改善 テスト設計 重視 テスト分析 重視 上流への 取組み人海戦術 計画 実績 設計プロセス安定化 テ ス ト コ ス ト 予実差解消 重点指向 本質的には 要件管理強化 設計品質重視 テスト分析 /設計の技術を 活かす 段階を踏んだ改善アプローチ（PDCA： A＝標準化） 標準化１ 標準化した瞬間から 増補改定が始まる！
- 19. 19 テストの原理７. 自動化 自動テスト。 テストデータの自動生成。 デシジョンテーブルを利用したテストケースの選択。 カバレッジ測定の自動化。 ＜現在の方法＞ • テスト分析： 三色ボールペン → Freemind → EXCEL（FV表） • テスト設計： 組合せ関連テスト設計（実用化）、統計的テスト • テスト実施： 負荷ツール、ユニットテストの自動化（回帰テスト） 操作の自動化 • テスト管理： TestLink、Bugzilla
- 20. 20 仕様書のチェック……三色ボールペンを使って 仕様書のチェックは三色ボールペンを用いる。 赤…客観的に見て、最も重要な箇所 青…客観的に見て、まぁ重要な箇所 緑…主観的に見て、自分がおもしろいと感じたり、興味を抱いたりした箇所 テスト設計では、 緑…主観的に見て、おかしいと感じた箇所 1. 仕様書が汚れるのを気にせずにたくさん書き込む 2. 後になって説明があるかもと思わずに違和感を感じたらすぐに書き込む 3. 仕様書に書いていないこと（補集合）に注意しメモを残す 4. （自分用のメモと思って）気楽にやる 5. 眠くない時にやる（朝イチがベスト）
- 21. 21 マインドマップによる整理
- 22. 22 FV表
- 24. 24 現在の私のテーマ１ 市場で起こっているソフトウェア問題を分析して対策をとる。 ⇒ 一人では無理なのでSEAのソフトウェアシンポジウム2008で 古川先生、にしさん、大西さん、、、etcで検討・実施する予定 日付 タイトル 2008/4/24 後期高齢者医療制度：県内１４７人分の保険料、プログラムミスで天引きできず ／愛媛 2008/4/25 住基ネット：システム故障、発給業務３０分中断 プログラムのミス－－池田市 ／ 大阪 2008/4/25 りそな銀などシステム障害 ＡＴＭで他行カード使えず 2008/4/26 京都信金：ＡＴＭ、一時使用不能に システム障害 ／京都 2008/4/26 都城市：都市計画税２６件、課税額に誤り ／宮崎 2008/4/26 富山市：国保納入通知書でミス１０８７通発送 2008/4/29 札幌市 １億5400万円過大受給 道から重度障害医療補助金で 2008/4/30 ドコモ、N902iL の「ソフトウェア更新」に不具合、配布を一時中断 2008/5/1 リコー、GR DIGITAL IIの不具合を修正 2008/5/2 三菱東京ＵＦＪ銀：世界最大のシステム完全統合作業に着手 2008/5/2 志賀原発：トラブル続き 2008/5/5 北京五輪入場券インターネット販売でシステム障害 2008/5/6 パーキングメーター誤作動、料金返還 2008/5/9 シグマ、「DP1」のファイルが消去 2008/5/9 電算システム障害で業務が一時停止／相模原市 2008/5/12 三菱ＵＦＪ システム統合初日に障害 2008/5/14 総務省、ソフトバンクモバイルに対して設備管理に関する指導 2008/5/14 竜巻情報：システム障害で伝達できず 名古屋と津気象台 2008/5/15 リコー、GR DIGITAL II シグマ製ストロボを認識しない不具合 2008/5/15 北銀ＡＴＭでシステム障害一時ストップ 2008/5/16 「ぴあ」チケット販売システムの不具合で大リストラ 2008/5/16 ヤマハ、最大120件の顧客情報が流出 2008/5/16 quanpでデータ消失 2008/5/18 Zoho Writerの検索機能にバグ--共有ドキュメントを意図しないユーザーに表示 2008/5/19 住友信託銀のシステム障害、原因はパラメータ設定ミス 2008/5/19 富士ゼロックスのDocuWorksでデータ消失を伴う不具合が発生 2008/5/19 住友信託銀：システム障害 2008/5/19 富山市教委：８幼稚園・小学校、給食費を過剰徴収 2008/5/20 福岡銀でシステム障害、ATMなどが1時間半にわたって全面ダウン 2008/5/21 住友信託銀2度目のシステム障害、原因は再びパラメータの設定ミス 2008/5/21 ムーディーズ、ＣＰＤＯの格付け問題めぐり調査を開始 2008/5/21 後期高齢者「健康診査」受診券 5200人分あて名ミス 札幌市 誰でも出来ることです！
- 25. 25 現在の私のテーマ２ 品質のコスト換算 トム・デマルコ（『Controlling Software Projects』より） You can't control what you can't measure. 測定することにより管理下に置く（正しい状態をキープ）ことができる 多次元の品質を測定する方法（Ｑの定量化へのチャレンジ） 区分原理（事実の収集＝良い・悪いではなく数値で集める） たくさんの品質特性を漏れなくダブり無く分けてそれぞれを定量化 多変量解析 まずは仮説を立ててデータを当てはめて検証してみる 最終的には数値解析（マハラノビスの距離を求めるなどしてパター ン解析） テストで品質を予測できるようになる（目的） 品質をテストによって守る（攻める）ためには予測ができるようになる 必要がある 「果因（結果⇒原因）」の異常対応から、「因果関係」を理解し予測・ 助言可能な世界へ
Editor's Notes
- <number>
- <number>