備忘録:ソフトウェアテストを学ぶ

こんにちは。ヨシトキです。   今回はソフトウェアソフトの書籍で学んだことを章ごとにまとめてみます。    

第一章:自己診断テスト

ここでは簡単なプログラムを実際にテストしてみて自分の実力を判断するという物です。 実はこのテスト。熟練のプログラマでも50点ほどしかとれないもので、プログラムテストがいかに容易ではないか。ということを目の当たりにします。    

第二章:プログラムテストの心理学と経済学

この章ではプログラムテストを心理学的、経済学的に考えてみよう。となっています。 まず、テストの心理学として 「プログラムはエラーをふくんでいるという仮定のもとでテストをはじめるべきである。」 「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 という定義で行うことが大切であると説いています。 つぎにテストの経済学として 「プログラムの全てのエラーをみつけることは、非現実的であり、不可能である」 「テストする人がそのプログラムに対して持つ仮定と、テストケースのを設計する方法をどうするか」 とあります。 経済学についてはすこし分かりづらいのですが、ここからこの定義に戦略をたてています。 これらを前提にソフトウェアテストの原則を述べているのもこの章で、それぞれ
  1. テストケースの必須条件は、予想される出力または結果を定義しておくことである。
  2. プログラマは自分自身のプログラムをテストしてはならない。
  3. プログラム開発グループは、自分たちのプログラムをテストしてはならない。
  4. それぞれのテストの結果を完全に検査せよ。
  5. テストケースは、予想できる正しい入力条件ばかりでなく、予想しない誤った場合も考えなて書かなくてはならない。
  6. プログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功しただけにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることである。
  7. プログラムが本当に使い捨てのもので無い限り、そのテストケースも使い捨てにしてはならない。
  8. エラーは見つからないだろうという仮定のもとにテストの計画をたててはいけない。
  9. プログラムのある部分でエラーがまだ存在している確率はすでにその部分で見つかったエラーの数に比例する。
  10. テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である。
という原則を根本原則としていくことが大切である。と説いています。    

第三章:プログラムの検査、ウォークスルー、検討

ここではまず、コンピュータによらないテスト仮定、つまり人間によるテスト、を扱っており、その技法を説いています。 まず最初に「検査」と「ウォークスルー」についてです。 これらは人間によるテストの基本的な物で共通点がおおい似たものになっています。 共通点としてあげられることを先に挙げると
  • 準備をし、チームの人々がプログラムを読む(会合)
  • 開発者のグループ3、4人で行われる。
  • 机上チェック作業の改良である
となっています。 次に、それぞれについて詳しくみていっています。

検査

4人の検査チームを構成し、検査会を開きます。検査会はそれぞれがプログラムのリストと設計仕様を調べておき、次の活動を行います。
  1. プログラマはプログラムの論理を1命令ずつ読み上げる。そして参加者が疑問点をあげ、エラーがあるかどうか判定する。
  2. 共通のプログラムエラーリスト(よくあるプログラムの間違いのリストのようなもの)を見ながら分析する。
という内容で行われます。検査後再び見つかったエラーをリストとし、再検査を行うか検討します。 大事なことはエラーの発見に集中し、その場でエラーを修正しないということである。と説いています。 検査の為のエラーリストを大まかにあげると
  • データ参照エラー
  • データ宣言エラー
  • 計算エラー
  • 比較エラー
  • 制御流れエラー
  • インタフェイスエラー
  • 入力・出力エラー
  • その他のエラー
となっています。  

ウォークスルー

3人から5人のチームで構成され、検査同様に勉強した状態で会合を行います。 しかし検査と違い読み上げたりエラーチェックリストを使ったりするのではなく、参加者がコンピュータを演じることとなります。 すなわち、前もって準備されたテストケースを頭の中、または紙、黒板で実行されます。 その中で質問が投げられエラーを見つける手法です。 ウォークスルーもまた、追試仮定をもつことが大切だとあります。  

更なる方法

さらに挙げられる方法として机上チェック仲間内の検討というものが挙げられています。効果が高いとは言えないがプログラマが自己評価できる。という点で役に立つそうです。    

第四章:テストケースの設計

  さて、実際にテストケースを設計する手法を挙げていく章となります。まず今回の前提条件としてあげられているのが 「可能なテストケースのどのようなサブセットがもっともエラーを発見できる確率が高いか」 となります。 そして、それに当てはまる解をそれぞれの手法を精査し検討していきます。 検討する手法は以下の通りで
  • ブラックボックステスト
    1. 同値分割
    2. 限界値分析
    3. 原因-結果グラフ
    4. エラー推測
  • ホワイトボックステスト
    1. 命令網羅
    2. 判定条件網羅
    3. 条件網羅
    4. 判定条件・条件網羅
    5. 複数条件網羅
となっています。 まずそれぞれの手法を検討していきますが、それぞれいいところ悪いところが挙げられています。 そこでそれぞれをうまく使い解を得る戦略がまとめとして載っています。 それは
  1. 仕様が入力条件の組み合わせを含んでいる場合は原因-結果グラフの作成からはじめる
  2. どんな場合でも限界値分析を行う。これは入力及び出力限界の分析である。しかし、これらの大部分は原因-結果テストに統合されうる
  3. 入力と出力の有効と無効の同値クラスを見分け、もし必要なら見分けたテストケースを補足する
  4. さらにテストケースを得る為にエラー推測を行う
  5. テストケースのセットを考慮にいれながら、プログラムの論理を調べる。判定条件網羅、条件網羅、判定条件・条件網羅、複数条件網羅基準のうちどれかを使う。この基準が十分満たされるだけのテストケースをつくる。
となっています。 しかし、繰り返し、全てのエラーがみつかることは保証されないということ、プログラムテストは簡単なものではんく厳しい仕事であること。ということを説いています。    

第五章:モジュール(単体)テスト

  ここまではプログラム大きさを考えずに勉強してきましたが、大きなプログラムについてはテスト過程を構造化する必要があります。 その最初の段階としてモジュールテストを考えてみます。 まずモジュールテストとは一つのプログラムのサブプログラム・サブルーチンのテスト過程を言うものです。つまり全体をいきなりテストするのではなく小さい構成をテストしていくことです。 モジュールテストの過程を三つにわけて書いてあります
  1. テストケースを設計する方法
  2. モジュールをテストして統合すべき順序
  3. このテストを行ううえでの実際的助言
1.2.をまとめると  

テストケースを設計する方法

一言で言えばホワイトボックステストであり、そして、その設計は、あるモジュールの仕様とは関係のないエラーを発見する為であるから。とあります。ホワイトボックステストは仕様とは関係のないエラーを発見するのに適しています。 ホワイトボックステストが終了したら補足的にブラックボックステストを行います。  

モジュールをテストして統合すべき順序

これは非常に重要なもので、費用などにも関わってくるものです。 さて、実際統合の順序とはどうするのでしょうか。 各モジュールを別々にテストしてからそのモジュールを結合していくのか、またはテストすべきモジュールをテストが終わったものと統合してからテストすべきなのか。前者を非増加テスト。後者を増加テストと呼ぶが、一般的に増加テストのほうがエラーを見つけることが出来るが、最終的に作業量が少なくなる。 どちらも一長一短があるが、近年の動向では増加テストの方が優れているとされている。    

第六章:上級テスト

  この章ではモジュールテストが終了した後、本格的なテスト過程について述べている。 そしてここで一つの定義を挙げている。 「ソフトウェアのエラーは、プログラムを使うユーザが当然のこととして期待していることを実行しない場合にあらわれる。」   つまりモジュールテストだけでは不完全であるからさらにテストが必要です。ということです。 そしてこれを上級テストと呼んでいます。   この上級テストをはじめる前にソフトウェア生産の開発サイクルについて書いてあり、その段階ごとにエラーを発見していくことが大切であると書いてあります。 そしてその理由として、一つの段階が終わった後次の段階では、前の段階のエラーと比較しながらテストをするという方法を取れるからであるとあります。 そしてそれぞれ適した方法のテストをすることが大切であるというものです。
  • 機能テスト
  • システムテスト
    • 機能部分テスト
    • 大容量テスト
    • ストレステスト
    • 有用度テスト
    • 秘密保護テスト
    • 効率テスト
    • 記憶域テスト
    • 構成テスト
    • 互換性テスト
    • 設置テスト
    • 信頼性テスト
    • 回復テスト
    • サービス性テスト
    • 文章テスト
    • 手続きテスト
  • 認可テスト
  • 導入テスト
  • モジュールテスト
  • 統合テスト
これらを目的、終了基準、スケジュール、責任、道具、コンピュータの使用時間、ハードウェア構成、統合、追跡手続き、デバック手続き、復帰テストを考え計画をたてることが重要です。   もう一つ重要なことがテストの完了基準です。いつ終わりにするのか。ということです。前述したように全てのエラーを発見することは不可能だと言えますが、それだといつ終わりにするのかが問題になります。 ここでは 予定したテスト期間をがすぎた時に停止する すべてのテストケースを実行しエラーが発見出来ないとき停止する と書いてあります。 ただし前者の場合は無益であり、後者をすすめています。    

第七章:デバッグ

つぎにデバッグ作業です。これはテストケースに成功したあとの仕事です。 つまりプログラムに不具合が見つかった場合です。 そしてそれを修正することのことです。 まず述べているのは「力づくのデバッグ」は推奨しないということです。これは全てがうまくいかない時などに用いる物で、まず行うべきではないと述べています。 では何を行うのか。というところで 「帰納法によるデバッグ」
  • 適切なデータを見つける
  • データを組織化する
  • 仮説をたてる
  • 仮説を証明する
という方法が提案されています。次に 「推定によるデバッグ」
  • 可能な原因や仮説を列挙する
  • データを使って可能な原因を消去する
  • 残っている仮説を改善する
  • 残った仮説を証明する。
という方法。推理に近い考え方です。更に 「逆戻りデバッグ」 「テストによるデバッグ」 と挙げられています。 またデバッグの原則として心理的なものが挙げられています。   更に重要なこととしてエラー分析というものが挙げられています。 デバッグではエラーを取り除くだけでなく、分析することこそ有用である。というのです。 つまり「なぜこのようなエラーが起こったのか考えることで理解を深める」ということです。    

第八章エクストリーム・テスト

  エクストリームテストとはエクストリームプログラミングを利用して行われるテストであり、開発初期の段階の設計よりもコーディングとテストを重視したもので、各工程を常にフィードバックし、修正、再設計していくことを重視している物です。 具体的に 「エクストリーム単体テスト」モジュールが出来上がる前にテストケースを作る。 「受け入れテスト」設計・計画段階で作成する があり、これがエクストリームテストの概念となっています。 この方法は高速なアプリケーションの開発を支援することができます。    

WEBアプリケーションのテスト

  ここではWEBでのアプリケーションの重要性と手法を述べています。 WEBアプリケーションはパッケージアプリケーションに対し、並以上の品質を絶えず必要としており、その品質以下となるとすぐに顧客が流れてしまうという性質があるゆえにその品質の為にもテストの重要性が高いことが言えます。 そしてその基礎的な部分としてEC(電子商取引)の構造から説明されています。 主に図で説明されており構造は省略するが、問題の一つ目として、その構造の多くはWEBブラウザを介しておこなわれ、ブラウザの違いによる互換性の問題がある。というところが問題です。 問題の二つ目として、サーバの問題、三つ目としてデータベースの問題(データ層)についてとあります。   それらを考えテストの課題として、
  • 多種多様なユーザベース
  • ビジネス環境
  • 場所
  • テスト環境
  • セキュリティ
というものが挙げられています。   そしてそれらを解決する戦略として
  • プレゼンテーション層テスト
    • コンテンツ・テスト
      • 全体の美的感覚、フォント、色、綴り、コンテンツの正確さ
    • WEBサイト構造
      • 壊れたリンクか、表示
    • ユーザ環境
      • ブラウザ版とオペレーティングシステムの構成
  • ビジネス層テスト
    • パフォーマンス
      • 仕様をみたすかどうか
    • データの有効性
      • 顧客から集めたデータでのエラーを感知する
    • トランザクション
      • トランザクション処理でのエラー
  • データ層テスト
    • 応答時間
    • データ整合性
    • 無停止と復元性
を考えることが必要とされており、それぞれを行う際の考え方が述べられています。     これで全ての章となりますが、全体的に具体的なテスト方法というより考え方を述べている章が多いものでした。 使用した本はソフトウェアテストの元祖的な本なので時代にとらわれない方法を書いた故なのでしょう。   必要に応じて迷ったときなどに読むのが良さそうです。   使用した本はこちら     補足: この本は英語が原本なうえに翻訳者が技術者のせいか、翻訳が甘いところがあります。というか直訳ってかんじで日本語として破綻しているところがあります。 しかしながら、言いたいことは原則的なところであったり大切なことが多いので、都度その大切なところを読むことを重視して読みました。 それゆえにまとめに甘いところもあるかもしれませんが、自分がそれぞれの章で得た知識の要点をまとめたつもりです。   もし具体的なソフトウェアテストの技法を学ぶ場合は他の本がいいかなと思います。

id-entity.jp

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です