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.

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

125 vues

Publié le

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

Publié dans : Formation
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

  1. 1. 第8回「テスト道具とその他の手法」 2011年7月29日(金) 服部 健太 ソフトウェア・テスト入門
  2. 2. 自動単体テストツール  単体テストのテストケースを事前に定義しておく と,自動的にテストの実行,結果の判定をおこ なってくれるツール  単体テストは本講義で説明したモジュールテストに 相当  広く使われている  代表的なプログラミング言語に対応して揃ってい る  CUnit/CppUnit/JUnit/RubyUnit/PythonUnit/…  *Unit系 2011/7/292 ソフトウェア・テスト入門8
  3. 3. JUnitの例  テストしたいクラスAについて,テストケースをATestというク ラスにメソッドとして書いていく  Java版Othelloライブラリの例: public class ServerTest { …略… @Test public void testConnect() { assertTrue(server.connect(host, port)); assertFalse(server.connect(host, port)); } @Test public void testDisconnet() { assertTrue(server.connect(host, port)); … 2011/7/293 ソフトウェア・テスト入門8
  4. 4. JUnitの例(2)  テストの自動実行  antのbuild.xmlに,たとえば以下のように定義しておくとant runtestsで全テストケースが実行され,レポート出力される <target name="runtests" depends="compiletests"> <junit printsummary="yes" haltonfailure="false"> <classpath>…省略…</classpath> <formatter type="plain"/> <batchtest> <fileset dir="${tests.dir}"> <include name="**/*Test.java" /> </fileset> </batchtest> </junit> </target> 2011/7/294 ソフトウェア・テスト入門8
  5. 5. 静的フロー解析ツール  プログラムを実行せずに,静的に解析することで, エラーを調べる  自動コード検査のようなもの  検出できる問題  未定義の値をもつ変数  使われない値を代入された変数  モジュール間のインタフェースの不一致  到達不能コード  ⇒多くは最近のコンパイラの警告オプションで発見可能  より進んだ機能をもつ製品もある  Coverity  スレッド解析して競合を発見するなど. 2011/7/295 ソフトウェア・テスト入門8
  6. 6. テストカバレッジモニタ  ホワイトボックス・テストに応用できるツール  実行中に対象プログラムのモニタを行い,命令網 羅基準と判定条件網羅基準にあっているかどうか を判定する統計的手法を提供する  使ったことは無いが,調べてみたところ,テクマ トリックス株式会社というところが以下のツール を販売している  http://www.techmatrix.co.jp/quality/ctest/test/covera ge.html 2011/7/296 ソフトウェア・テスト入門8
  7. 7. プログラムの正当性の数学的証明  テストの基本的な問題は,エラーがないことをしめすのは 不可能である点.  プログラム検証法/プログラムの正当性の証明  テストにかわるものとして,プログラムにエラーがないこと を実際にしめすための手法  Coq/Agdaなどの定理証明支援系ツールを使うことも多い  問題点:  非常に頭を使う必要がある  証明が間違っているかもしれない  規模の大きなプログラムでは難しい  個人的には,プログラマは自分で書いたコードの正しさを 確信できるよう,非形式的でよいので証明する習慣を身に つけた方が良いと思う. 2011/7/297 ソフトウェア・テスト入門8
  8. 8. テスト・データ・ジェネレータ  テスト・データを見分けたり作成するのをたすけ るためのツール  テスト・ケース・ジェネレータではないことに注意  プログラムの論理の流れを分析し,たとえば,あ る特定の基準を実行するのに必要な入力データの セットを推測する  特殊なものとしては,コンパイラのテストデータ を生成するもので,形式文法で入力を記述するも のもある 2011/7/298 ソフトウェア・テスト入門8
  9. 9. 環境シミュレータ  実際のなまの環境でのテストが不可能だったり, 高価になるとき,そのシステムのまわりの環境を シミュレートするツール  ストレステストと大容量テスト  ハードウェア故障など現実の環境でつくりだすこ とが困難な状況をつくりだすこと  核反応制御プログラムや宇宙システムなどなまの 環境のもとでのテストが問題外であるとき 2011/7/299 ソフトウェア・テスト入門8
  10. 10. 仮想計算機 2011/7/29ソフトウェア・テスト入門810  一種の環境シミュレータ  複数個のプログラムをそれぞれが別々の単体の機 械のもとで実行しているかのようにみせかける  新しいオペレーティングシステムのテストに使え る  1台の計算機しかない場合でも,複数のテストを 同時に実行することができる.
  11. 11. ソフトウェア・エラーの研究 2011/7/29ソフトウェア・テスト入門811  研究事例  大規模レーダ制御システムで2165個のエラーを分類し たもの  Fortran, PL/I, Algol, Basic, Cobolで書かれた小さなプロ グラム開発をふくむ大学の実験で得られた1189個のエ ラーの研究  3個の大型ソフトウェア・パッケージでのエラーの研究  TRWシステムで作成された4個の大きなプログラムでの エラーの研究  IBMのDOS/VSオペレーティングシステムの発注にあ たってのテストで発見されたエラーの分析  かのKnuthもTeXのエラーを分析している  文芸的プログラミングの第10章参照
  12. 12. 予測モデル 2011/7/29ソフトウェア・テスト入門812  プログラムに何個のエラーが残っているか予測する  いつテストをやめればよいかの判断  ソフトウェアが出荷可能かどうかの判断  一般的なカテゴリ: 1. ハードウェアの信頼性モデルから得られるモデル  ハードウェアの信頼性理論にもとづくもの  Markov法にもとづくもの 2. プログラムの構造にもとづくモデル  モデルのパラメータとして,プログラムの大きさ,分岐命 令数,ネスティングのレベル,データ型の数などをふくむ 3. 「エラーをばらまく」モデル  意図的にプログラムの中にエラーをばらまき,ばらまかれ た数と発見された本来のエラーn数の比率から全体のエ ラー数を推測する
  13. 13. ソース管理システム 2011/7/29ソフトウェア・テスト入門813  コード,文書,テストケースを自動的に管理する ツール  バージョン管理システムとも呼ばれる  古くはSCCS, CVSなど.最近では,SVNやgitな ど  大きなプロジェクトでは欠かせないツール
  14. 14. 対話型デバッガ 2011/7/29ソフトウェア・テスト入門814  プログラマに一連のデバッグ機能を提供する  メモリダンプ機能  ブレイクポイントの設定  変数が変更される箇所の検出  部分的な実行  現在では,統合開発環境に組み込まれている  フリーの代表的なデバッガとしてはGDBがある  個人的には,最近はほとんどデバッガを使ってま せん...
  15. 15. コンパイラ・デバッグ補助機能 2011/7/29ソフトウェア・テスト入門815  デバッグ時だけ有効になるような命令を指定できる機能  Cでいえば,#if DEBUG~#endなどで命令を囲み,コンパイ ル時に-DDEBUGを指定したりする  アサーション  ASSERT <ブール式> 文  のように,ブール式が偽のもつ場合は,それに関連した命令 が実行され,プログラムが中断される  Javaのassert文  アサーションを有効に活用することで,素早くバグを見つ け,デバッグすることができる  インタフェースの契約を明示化するのにも有効  例:ある手続きの引数nが非負整数であることが前提の場合, 入口にassert (n >= 0)と記述しておく.
  16. 16. メモリエラー検出ツール  未確保のメモリ領域へのアクセス,配列の範囲外ア クセス,二重解放など,メモリに関するエラーを検 出するツール  実際にプログラムを実行し,検出を行うため,すべての エラーを発見できるわけではない.  Valgrind  フリーのメモリリーク検出ツール  Purify  昔からある割と有名な商用ツール  自動GCを備えた言語を使うことが多い今日では,あ まり使う場面が少なくなっているような気がする 2011/7/2916 ソフトウェア・テスト入門8
  17. 17. モデル検査ツール  ソフトウェアの設計に対応するモデルを記述し,そ のモデルが,形式的に定義された仕様を満たすかど うかを検査する.  モデル記述言語  システムの設計を記述する  仕様記述  様相(時相)論理を用いて記述するものが多い  代表的なモデル検査ツール  SPIN/Promela  モデルをある種のオートマトンに変換し,ランダムに実 行したり,すべての取りうる状態を検査することで,仕 様を満たすかどうか検査する  並行/分散システムなどでは,強力なツールとなりうる 2011/7/2917 ソフトウェア・テスト入門8

×