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

第8回「テスト道具とその他の手法」
2011年7月29日（金）
服部健太
ソフトウェア・テスト入門

自動単体テストツール
 単体テストのテストケースを事前に定義しておく
と，自動的にテストの実行，結果の判定をおこ
なってくれるツール
 単体テストは本講義で説明したモジュールテストに
相当
 広く使われている
 代表的なプログラミング言語に対応して揃ってい
る
 CUnit/CppUnit/JUnit/RubyUnit/PythonUnit/…
 *Unit系
2011/7/292 ソフトウェア・テスト入門8

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));
…

JUnitの例(２)
 テストの自動実行
 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>

静的フロー解析ツール
 プログラムを実行せずに，静的に解析することで，
エラーを調べる
 自動コード検査のようなもの
 検出できる問題
 未定義の値をもつ変数
 使われない値を代入された変数
 モジュール間のインタフェースの不一致
 到達不能コード
 ⇒多くは最近のコンパイラの警告オプションで発見可能
 より進んだ機能をもつ製品もある
 Coverity
 スレッド解析して競合を発見するなど．

テストカバレッジモニタ
 ホワイトボックス・テストに応用できるツール
 実行中に対象プログラムのモニタを行い，命令網
羅基準と判定条件網羅基準にあっているかどうか
を判定する統計的手法を提供する
 使ったことは無いが，調べてみたところ，テクマ
トリックス株式会社というところが以下のツール
を販売している
 http://www.techmatrix.co.jp/quality/ctest/test/covera
ge.html

プログラムの正当性の数学的証明
 テストの基本的な問題は，エラーがないことをしめすのは
不可能である点．
 プログラム検証法／プログラムの正当性の証明
 テストにかわるものとして，プログラムにエラーがないこと
を実際にしめすための手法
 Coq/Agdaなどの定理証明支援系ツールを使うことも多い
 問題点：
 非常に頭を使う必要がある
 証明が間違っているかもしれない
 規模の大きなプログラムでは難しい
 個人的には，プログラマは自分で書いたコードの正しさを
確信できるよう，非形式的でよいので証明する習慣を身に
つけた方が良いと思う．

テスト・データ・ジェネレータ
 テスト・データを見分けたり作成するのをたすけ
るためのツール
 テスト・ケース・ジェネレータではないことに注意
 プログラムの論理の流れを分析し，たとえば，あ
る特定の基準を実行するのに必要な入力データの
セットを推測する
 特殊なものとしては，コンパイラのテストデータ
を生成するもので，形式文法で入力を記述するも
のもある

環境シミュレータ
 実際のなまの環境でのテストが不可能だったり，
高価になるとき，そのシステムのまわりの環境を
シミュレートするツール
 ストレステストと大容量テスト
 ハードウェア故障など現実の環境でつくりだすこ
とが困難な状況をつくりだすこと
 核反応制御プログラムや宇宙システムなどなまの
環境のもとでのテストが問題外であるとき

仮想計算機
2011/7/29ソフトウェア・テスト入門810
 一種の環境シミュレータ
 複数個のプログラムをそれぞれが別々の単体の機
械のもとで実行しているかのようにみせかける
 新しいオペレーティングシステムのテストに使え
る
 1台の計算機しかない場合でも，複数のテストを
同時に実行することができる．

ソフトウェア・エラーの研究
 研究事例
 大規模レーダ制御システムで2165個のエラーを分類し
たもの
 Fortran, PL/I, Algol, Basic, Cobolで書かれた小さなプロ
グラム開発をふくむ大学の実験で得られた1189個のエ
ラーの研究
 3個の大型ソフトウェア・パッケージでのエラーの研究
 TRWシステムで作成された4個の大きなプログラムでの
エラーの研究
 IBMのDOS/VSオペレーティングシステムの発注にあ
たってのテストで発見されたエラーの分析
 かのKnuthもTeXのエラーを分析している
 文芸的プログラミングの第10章参照

予測モデル
 プログラムに何個のエラーが残っているか予測する
 いつテストをやめればよいかの判断
 ソフトウェアが出荷可能かどうかの判断
 一般的なカテゴリ：
1. ハードウェアの信頼性モデルから得られるモデル
 ハードウェアの信頼性理論にもとづくもの
 Markov法にもとづくもの
2. プログラムの構造にもとづくモデル
 モデルのパラメータとして，プログラムの大きさ，分岐命
令数，ネスティングのレベル，データ型の数などをふくむ
3. 「エラーをばらまく」モデル
 意図的にプログラムの中にエラーをばらまき，ばらまかれ
た数と発見された本来のエラーｎ数の比率から全体のエ
ラー数を推測する

ソース管理システム
 コード，文書，テストケースを自動的に管理する
ツール
 バージョン管理システムとも呼ばれる
 古くはSCCS, CVSなど．最近では，SVNやgitな
ど
 大きなプロジェクトでは欠かせないツール

対話型デバッガ
 プログラマに一連のデバッグ機能を提供する
 メモリダンプ機能
 ブレイクポイントの設定
 変数が変更される箇所の検出
 部分的な実行
 現在では，統合開発環境に組み込まれている
 フリーの代表的なデバッガとしてはGDBがある
 個人的には，最近はほとんどデバッガを使ってま
せん．．．

コンパイラ・デバッグ補助機能
 デバッグ時だけ有効になるような命令を指定できる機能
 Cでいえば，#if DEBUG～#endなどで命令を囲み，コンパイ
ル時に-DDEBUGを指定したりする
 アサーション
 ASSERT <ブール式> 文
 のように，ブール式が偽のもつ場合は，それに関連した命令
が実行され，プログラムが中断される
 Javaのassert文
 アサーションを有効に活用することで，素早くバグを見つ
け，デバッグすることができる
 インタフェースの契約を明示化するのにも有効
 例：ある手続きの引数nが非負整数であることが前提の場合，
入口にassert (n >= 0)と記述しておく．

メモリエラー検出ツール
 未確保のメモリ領域へのアクセス，配列の範囲外ア
クセス，二重解放など，メモリに関するエラーを検
出するツール
 実際にプログラムを実行し，検出を行うため，すべての
エラーを発見できるわけではない．
 Valgrind
 フリーのメモリリーク検出ツール
 Purify
 昔からある割と有名な商用ツール
 自動GCを備えた言語を使うことが多い今日では，あ
まり使う場面が少なくなっているような気がする

モデル検査ツール
 ソフトウェアの設計に対応するモデルを記述し，そ
のモデルが，形式的に定義された仕様を満たすかど
うかを検査する．
 モデル記述言語
 システムの設計を記述する
 仕様記述
 様相（時相）論理を用いて記述するものが多い
 代表的なモデル検査ツール
 SPIN/Promela
 モデルをある種のオートマトンに変換し，ランダムに実
行したり，すべての取りうる状態を検査することで，仕
様を満たすかどうか検査する
 並行／分散システムなどでは，強力なツールとなりうる

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

Recomendados

Recomendados

Mais conteúdo relacionado

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

Semelhante a ソフトウェア・テスト入門8 (20)

Mais de Kenta Hattori

Mais de Kenta Hattori (20)

Último

Último (7)

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