Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

ソフトウェア・テスト入門5

92 vues

Publié le

ソフトウェア基礎講座資料

Publié dans : Formation
  • Soyez le premier à commenter

ソフトウェア・テスト入門5

  1. 1. 第5回「モジュール・テスト」 2011年7月7日(木) 服部 健太 ソフトウェア・テスト入門
  2. 2. モジュール・テストとは 2011/7/7ソフトウェア・テスト入門52  1つのプログラムのなかのサブプログラム,サブ ルーチン,プロシージャのテスト過程のこと  最初から全体としてテストするのではなく,まずプログ ラムのより小さな構成要素に焦点をあててテストする  動機:  テストで生じる組合せの問題をのがれることができる  エラーが見つかった時,デバッグ作業が容易になる  複数のモジュールを同時にテストすることができる  目的:  あるモジュールの機能を,そのモジュールを定義してい る機能仕様,あるいはインタフェース仕様と比較する
  3. 3. テスト・ケースの設計 2011/7/7ソフトウェア・テスト入門53  必要なもの  モジュールの仕様  入出力のパラメータ,機能など  モジュールのソース・コード  テスト・ケース設計の手順  ホワイトボックス手法を2つ以上つかってモジュー ルの論理を分析する  それから,モジュール仕様にブラックボックス手法 を適用して,これらのテスト・ケースを補足する
  4. 4. 例:BONUSモジュールのテスト 2011/7/7ソフトウェア・テスト入門54  機能  最大の売り上げをもつ1あるいは複数の部門の全従業員の給与に 200ドル加える  ただし,その資格のある従業員の現在の給与が15,000ドル以上か, 従業員がマネージャである場合には,100ドルだけの増額とする  モジュールへの入力  出力  エラーコード0:モジュールが正しく機能した  エラーコード1:どちらかのテーブルに項目が入っていない  エラーコード2:資格のある部門に従業員がみつからない 名前 仕事コード 部門 給与 部門 売上 従業員テーブル 部門テーブル
  5. 5. BONUSモジュールのソースコー ド 2011/7/7ソフトウェア・テスト入門55 SINC = 200.00; LINC = 100.00; LSALARY = 15000.00; MGR = ‘M’ def bonus(emptab, deptab, esize, dsize): errcode = 0; max_sales = 0 if esize <= 0 || dsize <= 0: errcode = 1 else: for i = 1 to dsize: # 最大の売上高を求める if deptab[i].sales >= max_sales: max_sales = deptab[i].sales for j = 1 to dsize: # 最大売上高の部門を探す if deptab[j].sales == max_sales: found = False for k = 1 to esize: # その部門の各従業員に対してボーナスを加える if emptab[k].dept == deptab.dept(j): found = True if emptab[k].salary >= LSALARY || emptab[k].code == MGR: emptab[k].salary += LINC else: emptab[k].salary += SINC if not found: errcode = 2 return errcode
  6. 6. プログラムの判定条件 2011/7/7ソフトウェア・テスト入門56  各for文は少なくとも1回は反復する  どんなテストケースでも両方向に分岐するのでfor文は特 に注意する必要なし  分析すべき対象: 1. if esize <= 0 || dsize <= 0 2. if deptab[i].sales >= max_sales 3. if deptab[j].sales == max_sales 4. if emptab[k].dept == deptab.dept(j) 5. if emptab[k].salary >= LSALARY || emptab[k].code == MGR 6. if not found
  7. 7. 判定結果に対応する状況 2011/7/7ソフトウェア・テスト入門57 判定 真の出力 偽の出力 1 esizeかdsizeが0以下 esizeとdsizeが1以上 2 いつも少なくとも1回はおきる 低い売上の部門がより高い売上 をもつ部門のあとにでてくるよ うにdeptabを並べる 3 いつも少なくとも1回はおきる すべての部門が同じ売上をもつ とはかぎらない 4 資格のある部門に1人の従業員 がいる 資格のある部門に所属していな い従業員がいる 5 資格のある従業員はマネージャ かLSALARY以上もらっている 資格のある従業員はマネージャ でなく,LSALARYより少ない給 与をもらっている 6 資格のある部門に従業員がいな い 資格のある部門に少なくとも1人 の従業員がいる
  8. 8. 判定条件(分岐)網羅基準を満たす テスト・ケース 2011/7/7ソフトウェア・テスト入門58 テスト ケース 入力 期待される出力 1 esize=0 他のすべての入力は無関係 errcode=1 esize,dsize,emptab,deptabは 変わらない 2 esize=dsize=3 emptab deptab errcode=2 esize,dsize,deptabは変わらな い emptab JON ES E D4 2 21,000.00 SMIT H E D3 2 14,000.00 LORI N E D4 2 10,000.00D4 2 10,000.00 D3 2 8,000.00 D9 5 10,000.00 JON ES E D4 2 21,100.00 SMIT H E D3 2 14,000.00 LORI N E D4 2 10,200.00 調べていない状況の例: エラーコードが0,従業員がマネージャ,部門テーブルが空白の状況,etc.
  9. 9. 条件結果に対応する状況 2011/7/7ソフトウェア・テスト入門59 判定 条件 真の出力 偽の出力 1 esize <= 0 esize が0以下 esizeが0より大きい 1 dsize <= 0 dsizeが0以下 dsizeが0より大きい 2 deptab[i].sales >= max_sales いつも少なくとも1回はおきる 低い売上の部門がより高い売 上をもつ部のんのあとにでて くるようにdeptabを並べる 3 deptab[j].sales == max_sales いつも少なくとも1回はおきる すべての部門が同じ売上をも つとはかぎらない 4 emptab[k].dept== deptab.dept(j) 資格のある部門に従業員がい る 資格のある部門に所属してい ない従業員がいる 5 emptab[k].salary >= LSALARY 資格のある従業員はLSALARY 以上もらってる 資格のある従業員は LSALARYより少ない給与を もらってる 5 emptab[k].code = MGR 資格のある従業員はマネー ジャである 資格のある従業員はマネー ジャでない 6 not found 資格のある部門に従業員がい ない 資格のある部門に少なくとも 1人の従業員がいる
  10. 10. 条件網羅基準を満たす テスト・ケース 2011/7/7ソフトウェア・テスト入門510 テスト ケース 入力 期待される出力 1 esize=dsize=0 他のすべての入力は無関係 errcode=1 esize,dsize,emptab,deptabは 変わらない 2 esize=dsize=3 emptab deptab errcode=2 esize,dsize,deptabは変わらな い emptab JON ES E D4 2 21,000.00 SMIT H E D3 2 14,000.00 LORI N M D4 2 10,000.00D4 2 10,000.00 D3 2 8,000.00 D9 5 10,000.00 JON ES E D4 2 21,100.00 SMIT H E D3 2 14,000.00 LORI N M D4 2 10,100.00 条件網羅基準は満たすが,p.8のテストケースより貧弱 たとえば,一部の命令は実行されない
  11. 11. 判定条件/条件網羅基準の検討 2011/7/7ソフトウェア・テスト入門511  JONESをマネージャに,LORINをヒラにするこ とで可能  判定条件5の両方の結果を生成し,すべての命令が 実行される結果が得られる  問題点:  p.8のテスト・ケースより本質的によくはなってい ない  例:コンパイラが論理式orの解釈を短絡する場合, emptab[k].code == MGRが真の結果になるパタンは実行さ れないので,この論理式にあやまりがあっても,このテス トケースでは,そのエラーを発見できない
  12. 12. 複数条件網羅基準を満たす テスト・ケース 2011/7/7ソフトウェア・テスト入門512 テスト ケース 入力 期待される出力 1 esize=dsize=0 他のすべての入力は無関係 errcode=1となる. esize, dsize, emptab, deptab は変わらない 2 esize=0, dsize>0 他のすべての入力は無関係 上記と同じ 3 esize>0, dsize=0 他のすべての入力は無関係 上記と同じ 4 esize=5, dsize=4 emptab deptab errcode=2 esize,dsize,deptabは変わらな い emptab JON ES M D4 2 21,000.00 WAR NS M D9 5 12,000.00 LORI N E D4 2 10,000.00 TOY E D9 5 16,000.00 SMIT H E D3 2 14,000.00 D4 2 10,000.00 D3 2 8,000.00 D9 5 10,000.00 D4 4 10,000.00 JON ES M D4 2 21,100.00 WAR NS M D9 5 12,100.00 LORI N E D4 2 10,200.00 TOY E D9 5 16,100.00 SMIT E D3 14,000.00
  13. 13. 考察 2011/7/7ソフトウェア・テスト入門513  複数条件網羅基準を満たすテストケースでも発見で きないエラーの例:  errcodeの初期化忘れエラーが発見できない  errcodeが0でかえってくる状況のケースが無い  LSALARYが15000.01に間違って設定されていた場合の エラー  emptab[k].salary >= LSALARYの>=が間違って>になっ ていた場合のエラー  そのほかの「1つ違いのエラー」  deptabやemptabの最後の項目が正しく処理されていない場合 ⇒ブラックボックステストによってテストケースを補足 する
  14. 14. BONUSモジュールのI/F仕様 2011/7/7ソフトウェア・テスト入門514  emptab:(入出力)従業員テーブル  最大売上部門にいる従業員の給与をあげる  給与が15000.00以上かマネージャの場合100ドル増やす.そうでなけ れば200ドル増やす  deptab:(入力)部門テーブル  esize:(入力)従業員テーブルの項目数  dsize:(入力)部門テーブルの項目数  errcode:(戻り値)エラーコード  esizeとdsizeが0より大きくなかったら1にして実行をやめる. それ以外なら機能は実行される  ただし,ある最大売上部門に従業員がいないとわかったら, 処理は続行されるがエラーコード2が返される  そうでなければ0がセットされる  備考  各テーブルの項目順についてはどのような仮定もない
  15. 15. 限界値分析 2011/7/7ソフトウェア・テスト入門515 【入力限界】 1. emptabは1項目をもつ 2. emptabは最大数の項目をもつ 3. emptabは空 4. deptabは1項目をもつ 5. deptabは最大数の項目をもつ 6. deptabは空 7. 最大売上部門に1人の従業員がいる 8. 最大売上部門に最大人数の従業員 9. 最大売上部門に従業員がいない 10. deptabのすべての部門は同じ売上高 11. 最大売上部門はdeptabの最初の項目 12. 最大売上部門はdeptabの最後の項目 13. 資格のある従業員はemptabの最初の 項目 14. 資格のある従業員はemptabの最後の 項目 15. 資格のある従業員はマネージャ 16. 資格のある従業員は非マネージャ 17. 管理者でない資格のある従業員が 14,999.99ドルの給与 18. 管理者でない資格のある従業員が 15,000.00ドルの給与 19. 管理者でない資格のある従業員が 15,000.01ドルの給与 【出力限界】 20. errcode=0 21. errcode=1 22. errcode=2 23. 資格のある従業員の増額された給与が 最大(99999.99)である 【エラー推測技法】 24. deptabで,従業員のいない最大売上部 門の直後に従業員のいる最大売上部門 がある 赤色はまだカバーされていない条件 灰色は非実際的なので除く条件
  16. 16. 限界値分析によるテスト・ケース 2011/7/7ソフトウェア・テスト入門516 テスト ケース 入力 期待される出力 5 esize = 3, dsize = 2 emptab deptab errcode = 0 esize,dsize,deptabは変らず emptab 6 esize = 1, dsize = 1 emptab deptab errcode = 0 esize,dsize,deptabは変らず emptab 7 esize = 2, dsize = 2 emptab deptab errcode = 2 esize,dsize,deptabは変らず emptab ALLY E D3 6 14,999.99 BES T E D3 3 15,000.00 CELT O E D3 3 15,000.01 D3 3 55,400.01 D3 6 55,400.01 ALLY E D3 6 15,199.99 BES T E D3 3 15,100.00 CELT O E D3 3 15,100.01 CHIE F M D9 9 99,899.99 D9 9 99,000.00 CHIE F M D9 9 99,999.99 DOL E E D6 7 10,000.00 FOR D E D2 2 33,333.33 D6 6 20,000.00 D6 7 20,000.00 DOL E E D6 7 10,200.00 FOR D E D2 2 33,333.33 条件7,10,14,17, 18,19,20をカバー 条件1,4,23 をカバー 条件24 をカバー
  17. 17. モジュール結合の方法 2011/7/7ソフトウェア・テスト入門517  増加テスト  テストすべき次のモジュールを,すでにテストした モジュールのセットと結合してからテストする  ビッグバンテスト  各モジュールを別々にテストしてから,最後にそれ らモジュールを結合してプログラムを形成する A CB D E F B A E スタブモジュール ドライバモジュール テストしたい モジュール
  18. 18. 増加テストvsビッグバンテスト 2011/7/7ソフトウェア・テスト入門518  ビッグバンテストのほうが多くの作業を必要とする  増加テストを使うと,モジュール間の適合しないインタ フェースあやまりが早期に発見できる  増加テストを使う方がエラーの位置を特定しやすいためデ バッグが容易  増加テストでは,最初の方に結合されたモジュールはその 後,何度もテストされることになるため,テストを進めて いくほど効果的になる  ビッグバンテストの方がコンピュータ使用時間が少なくて 済むが,より多くのドライバやスタブを必要とする  ビッグバンテストをつかうと,モジュールテストの最初の 段階で並行処理をおこなう機会が多くなる ⇒ 一般的には増加テストの方がすぐれている
  19. 19. モジュール・プログラム例 2011/7/7ソフトウェア・テスト入門519 A CB D F HE G I J K L I/O読み込み I/O書き出し
  20. 20. トップダウン・テスト 2011/7/7ソフトウェア・テスト入門520  プログラムの頂上のモジュールからはじめる  例の場合,モジュールAからテストする  モジュールAをテストするには,B,C,Dをあらわ すスタブモジュールを書かなければならない  スタブは正しい値を返す必要がある  スタブを作成するのはやさしい仕事ではない  モジュールAのテストケースをどうやってあたえ るか?  1つ以上のスタブからそのモジュールにテスト・ データを与える
  21. 21. トップダウン・テスト(2) 2011/7/7ソフトウェア・テスト入門521  Aをテストしたあとで,スタブのうちの1つが,次に テストするモジュールに置き変わり,そのモジュー ルに必要なスタブを追加する  プログラムにクリティカルな部分があるばあい,こ れらの部分を早めに加えるように順序を設計する  I/Oモジュールができるだけ早く加えられるように順 序を設計する A CB D FE
  22. 22. トップダウン・テスト(3) 2011/7/7ソフトウェア・テスト入門522  利点:実際に動く骨組みが早い時点でできあがる  欠点:この時点で,モジュールHを追加する場合,Hのテスト・ケースをカバー するようなモジュールJへのテスト・データをしめすことは不可能かもしれない. 可能だとしても,テストデータを何にするのか決めるのは頭の痛い作業になる ことが多い  欠点:あるテストの表示された出力とそのモジュールで実行された内容との関 連づけがむずかしいか不可能でさえあることが多い  欠点:他のモジュールにすすむまでは完全にそのモジュールをテストできない ことがある A CB D F HE I J
  23. 23. ボトムアップ・テスト 2011/7/7ソフトウェア・テスト入門523  プログラムの末端モジュール(他のモジュールを呼ばない モジュール)からはじめる  ドライバモジュールが必要  ドライバの方がスタブよりも作成しやすい  弱点:早期の骨組みプログラムの利点は得られない ドライバ F J D H I K L ドライバ
  24. 24. 比較 トップダウン・テスト ボトムアップ・テスト  長所  おもな流れがプログラムの頂点へ 向かっているならすぐれている  I/O機能が追加されれば,テスト・ ケースの表現がやさしくなる  骨組みプログラムが早くデモ可能  短所  スタブ・モジュールの作成が必要  スタブ・モジュールは最初に思っ ていたより複雑なことが多い  I/O機能が追加されるまでテスト・ ケースの表現が難しい  テスト条件の作成が困難  テストの出力をみるのが難しい  あるモジュールのテスト完了が遅 れる  長所  おもな流れがプログラムの 底辺のほうへ向かっている ならば,すぐれている  テスト条件がより作成しや すい  テスト結果をみるのが容易 である  短所  ドライバ・モジュールの作 成が必要  プログラムの本体は最後の モジュールが加わるまで存 在しない 2011/7/724 ソフトウェア・テスト入門5
  25. 25. テストの実行  モジュールの実際の結果と期待する結果が合わなかった場 合,モジュールのエラーかテストケースが正しくないかの いずれか  テストを行うまえにテスト・ケースのセットを検査しなけれ ばならない  自動テストツールを使うと,テストの単調な仕事を最小に できる  例:ユニットテストツール  到達不能コード,未初期化変数の使用などはコンパイラによっては検 出可能なものもある  モジュールをテストする人は作った人と別な方がよい(た だしデバッグは作った本人が行う)  モジュールの一部のサブセットで異常に多い数のエラーが 見つかった場合,そのようなモジュールはさらに詳しいテ ストを行い,また,多くのコードのウォークスルーか検査 を追加する 2011/7/725 ソフトウェア・テスト入門5
  26. 26. 次回予定  日にち  2011年7月15日(金)  時間  10:30~12:00  場所  LB/2FA  内容  上級テスト 2011/7/726 ソフトウェア・テスト入門5

×