Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
Next
Download to read offline and view in fullscreen.

13

Share

Download to read offline

20080615 wacate

Download to read offline

2008/6/15 WACATE

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

20080615 wacate

  1. 1. 品質本部 システム品質評価部 秋山 浩一 (NPO法人 ASTER) ■WACATE 2008 夏 ソフトウェアテストがおもしろい理由 2008年6月15日
  2. 2. 2 目次 1. 自己紹介 2. テストの7つの原理 3. 現在の私のテーマ
  3. 3. 3 自己紹介&関連イベント 1985年4月1日: 入社(Smalltalk, UNIX WS, Network) 1996年11月21日: ソフトウェアテスト技法&ツールを作る仕事に従事 2000年5月30日: TEF参加 2000年9月25日~9日: 2WCSQ:田口氏の発表の後に西さんの発表を聞く 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
  4. 4. 4 おもしろく過ごすポイント:その1 話が来たら 断らない 他力本願とは、自分で何もせずに他人任せにするので はなく、これも一つのご縁として「自分には無理」と か思わずに積極的にチャレンジすること。なんとかな ると思うから声をかけてきたと思おう。
  5. 5. 5 温故知新: 世界初のテストシンポジウム When: 1972年6月21日~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. 6 テストの7つの原理@『プログラム・テスト法』 1. セグメンテーション 2. 可テスト性を持つ設計 3. シミュレーション 4. サンプリング 5. 論理的簡約 6. 標準化 7. 自動化
  7. 7. 7 テストの原理1. セグメンテーション  複雑で大きな問題を数多くの小さな部分的な問題に分割し、それぞれ別 個に取り組むこと。テストを階層的に構造化しようというアイデア。  Wilkesがサブルーチンを使用(1951)  Dijkstraによるストラクチャード(構造化)プログラミング(1968)  Parnasのモジュラー・プログラミング(1971)  Millsのトップ・ダウン・プログラミングとセグメント(1971) <現在の方法> • 複雑の定義: 本質的複雑性、偶発的複雑性(環境に持ち込まれた複雑性) • フェーズ: テストレベル(コンポーネント、統合、システム、受け入れ) • 視点: テスト種別(構造視点、仕様視点、顧客視点、エラー視点) • 技法: 同値分割、マインドマップ
  8. 8. 8 設計による複雑さの軽減 システム全体(分割していない) A C D B 点の数:本質的複雑性、線の数:偶発的複雑性
  9. 9. 9 テストの原理2. 可テスト性を持つ設計  「テストを可能とする設計」というアイデア。  全体の設計とコーディングの過程を通してテストは計画されなければ ならないという認識が出てきた。  テストが可能なように問題の仕様を決めることで、暗黙的に理解され る仕様を排除し、仕様のあいまいさと誤解をなくす。  スタブを用意して全ての開発が終わらなくてもテスト可能にする。 <現在の方法> • テストプロセス: W字モデル(テスト技術を使いバグの総数を減らす) • テスト駆動: テストファースト、xUnit • 要件の検証: 要件を決める時に「テスト可能性」をレビュー • FV表: 機能と検証をセットにしてアセスメント
  10. 10. 10 要求 (RFP) 要件定義 仕様 詳細設計 基本設計 テストアクティビ ティ開始 システムテスト 計画 コンポーネントテスト 計画 統合テスト 計画 コーディング デバッグ &変更 デバッグ &変更 デバッグ &変更 デバッグ &変更 受け入れテスト 実施 システムテスト 実施 コンポーネントテスト 実施 統合テスト 実施 レビュー レビュー レビュー レビュー Wモデルを実現する上で大切なこと は、まず下流のテストにおいてテス トの質を高め、「テストを設計するこ とだけでバグが発見できるという実 感を持つ」こと。その上で、上流工程 のレビューに参画していくことで上 流の質が高まる。 Wモデルありきでレビュー会を開い ても成功しない。 にしさんのご講演内容より ソフトウェア開発モデル(Wモデル)
  11. 11. 11 テストの原理3. シミュレーション  ソフトウェアの動作環境をソフトウェアでシミュレート。  容易に特別な環境を用意できる。  サブモジュールをテストするために主モジュールをシミュレートする。 ⇒ スタブ的シミュレータ <現在の方法> • 自動化: 組込み系ソフトウェアの自動化に無くてはならない技術 • カバレッジ: 特殊なエラー条件をシミュレート • ユースケース: ユーザシミュレーション(統計的テスト技法)
  12. 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. 13 テストの原理4. サンプリング  品質を評価するときに、全体のプログラムを詳細に解析するのではなく、 サンプルした部分だけを分析して得られた結果に対して外挿を行う方法。  エラーシーディングによる統計的テスト方法。 <現在の方法> • 技法: 探針(区間推定) • データ解析: パフォーマンステスト(区間推定、サンプル数の決め方) • エラー埋め込み: テスターのモチベーション向上
  14. 14. 14 探針(区間推定)の実際 http://hayst.com/qptest.aspx
  15. 15. 15 テストの原理5. 論理的簡約  プログラムを「論理的性質を温存しながら」単純化、簡約化。 ⇒ フローチャートや有向グラフへの変換  モデルを作る <現在の方法> • Black Box技法: モデルテスト(テスト観点の列挙、整理、検討: NGT) 状態遷移テスト(統計的テスト) 組合せを数個の因子で検査(直交表、All-pairs) • White Box技法: モデル検査(SPIN)、形式手法
  16. 16. 16 入力 信号因子 M {M1, M2, M3,…} 出力 y (レスポンス) ノイズ 誤差因子 z {z1, z2, z3 ・・・} 対 象 システムチャート read write 内部変数の組合せ(=状態) 信号因子 m {m1, m2, m3 ,…}
  17. 17. 17 テストの原理6. 標準化  コーディング規約。  インターフェースの標準化によるテストの問題の簡単化。 <現在の方法> • 技法: 「MISRA-C」(元々は車載用ソフトウェアを対象とした規約) • 静的解析: コーディング規約の遵守チェック • テスト資産: インターフェースに対するテストの資産化
  18. 18. 18  テスト工程の改善と上流工程の改善を 対にして進める。 テスト分析 テスト設計 テスト項目作成 テスト実施 玉石混合 となってつ き進む テスト 技法導入 支援 ツール開発 テスト 教育 テスト 戦略 ツール 活用 標準化2 改善 改善 改善 標準化3 改善 テスト設計 重視 テスト分析 重視 上流への 取組み人海戦術 計画 実績 設計プロセス安定化 テ ス ト コ ス ト 予実差解消 重点指向 本質的には 要件管理強化 設計品質重視 テスト分析 /設計の技術を 活かす 段階を踏んだ改善アプローチ(PDCA: A=標準化) 標準化1 標準化した瞬間から 増補改定が始まる!
  19. 19. 19 テストの原理7. 自動化  自動テスト。  テストデータの自動生成。  デシジョンテーブルを利用したテストケースの選択。  カバレッジ測定の自動化。 <現在の方法> • テスト分析: 三色ボールペン → Freemind → EXCEL(FV表) • テスト設計: 組合せ関連テスト設計(実用化)、統計的テスト • テスト実施: 負荷ツール、ユニットテストの自動化(回帰テスト) 操作の自動化 • テスト管理: TestLink、Bugzilla
  20. 20. 20 仕様書のチェック……三色ボールペンを使って 仕様書のチェックは三色ボールペンを用いる。 赤…客観的に見て、最も重要な箇所 青…客観的に見て、まぁ重要な箇所 緑…主観的に見て、自分がおもしろいと感じたり、興味を抱いたりした箇所 テスト設計では、 緑…主観的に見て、おかしいと感じた箇所 1. 仕様書が汚れるのを気にせずにたくさん書き込む 2. 後になって説明があるかもと思わずに違和感を感じたらすぐに書き込む 3. 仕様書に書いていないこと(補集合)に注意しメモを残す 4. (自分用のメモと思って)気楽にやる 5. 眠くない時にやる(朝イチがベスト)
  21. 21. 21 マインドマップによる整理
  22. 22. 22 FV表
  23. 23. 23 おもしろく過ごすポイント:その2 本は読もう 読んだら使おう ソフトウェアテストは原理原則が長く使える領域の技 術です。それは、「専門技術」ではなく「汎用技術」 だからです。ゆえに様々な先人の知識が応用できます。 色々ためしてみましょう!
  24. 24. 24 現在の私のテーマ1  市場で起こっているソフトウェア問題を分析して対策をとる。 ⇒ 一人では無理なのでSEAのソフトウェアシンポジウム2008で 古川先生、にしさん、大西さん、、、etcで検討・実施する予定 日付 タイトル 2008/4/24 後期高齢者医療制度:県内147人分の保険料、プログラムミスで天引きできず /愛媛 2008/4/25 住基ネット:システム故障、発給業務30分中断 プログラムのミス--池田市 / 大阪 2008/4/25 りそな銀などシステム障害 ATMで他行カード使えず 2008/4/26 京都信金:ATM、一時使用不能に システム障害 /京都 2008/4/26 都城市:都市計画税26件、課税額に誤り /宮崎 2008/4/26 富山市:国保納入通知書でミス1087通発送 2008/4/29 札幌市 1億5400万円過大受給 道から重度障害医療補助金で 2008/4/30 ドコモ、N902iL の「ソフトウェア更新」に不具合、配布を一時中断 2008/5/1 リコー、GR DIGITAL IIの不具合を修正 2008/5/2 三菱東京UFJ銀:世界最大のシステム完全統合作業に着手 2008/5/2 志賀原発:トラブル続き 2008/5/5 北京五輪入場券インターネット販売でシステム障害 2008/5/6 パーキングメーター誤作動、料金返還 2008/5/9 シグマ、「DP1」のファイルが消去 2008/5/9 電算システム障害で業務が一時停止/相模原市 2008/5/12 三菱UFJ システム統合初日に障害 2008/5/14 総務省、ソフトバンクモバイルに対して設備管理に関する指導 2008/5/14 竜巻情報:システム障害で伝達できず 名古屋と津気象台 2008/5/15 リコー、GR DIGITAL II シグマ製ストロボを認識しない不具合 2008/5/15 北銀ATMでシステム障害一時ストップ 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 富山市教委:8幼稚園・小学校、給食費を過剰徴収 2008/5/20 福岡銀でシステム障害、ATMなどが1時間半にわたって全面ダウン 2008/5/21 住友信託銀2度目のシステム障害、原因は再びパラメータの設定ミス 2008/5/21 ムーディーズ、CPDOの格付け問題めぐり調査を開始 2008/5/21 後期高齢者「健康診査」受診券 5200人分あて名ミス 札幌市 誰でも出来ることです!
  25. 25. 25 現在の私のテーマ2  品質のコスト換算  トム・デマルコ(『Controlling Software Projects』より)  You can't control what you can't measure.  測定することにより管理下に置く(正しい状態をキープ)ことができる  多次元の品質を測定する方法(Qの定量化へのチャレンジ)  区分原理(事実の収集=良い・悪いではなく数値で集める)  たくさんの品質特性を漏れなくダブり無く分けてそれぞれを定量化  多変量解析  まずは仮説を立ててデータを当てはめて検証してみる  最終的には数値解析(マハラノビスの距離を求めるなどしてパター ン解析)  テストで品質を予測できるようになる(目的)  品質をテストによって守る(攻める)ためには予測ができるようになる 必要がある  「果因(結果⇒原因)」の異常対応から、「因果関係」を理解し予測・ 助言可能な世界へ
  26. 26. 26 おもしろく過ごすポイント:その3 おもしろい テーマを見つけよう 「好きこそ物の上手なれ」。「好き ⇒ できる」の順 番です。ソフトウェアテストの領域はとても広くまた 世の中から求められています。きっと「おもしろ い!」と思えるテーマが見つかることと思います!
  • taroyamakawa18

    Aug. 14, 2017
  • KiyohitoTouyama

    Jul. 24, 2015
  • rdpish

    Apr. 26, 2015
  • ikumahayasaka

    Apr. 23, 2015
  • fukuihi

    Mar. 25, 2015
  • kauji0522

    Feb. 27, 2015
  • KazuhiroTakehana1

    Feb. 18, 2015
  • takashiyamasaki378

    Feb. 18, 2015
  • fujiiki

    Feb. 12, 2015
  • yumikofujisaki

    Feb. 9, 2015
  • shinsk1

    Feb. 9, 2015
  • tosikawa

    Feb. 9, 2015
  • Kazukiterada

    Feb. 9, 2015

2008/6/15 WACATE

Views

Total views

2,370

On Slideshare

0

From embeds

0

Number of embeds

122

Actions

Downloads

26

Shares

0

Comments

0

Likes

13

×