Top / ソフトウェアテスト

ソフトウェアテスト

目次 †

ソフトウェアテスト †

• 限られた期間に行う最大公約数的な仕事。
• ソフトウェアを完全にテストすることは非常に困難である。そこで、より少ないテストケースでより多くのプログラムのエラーを検知することになる。
• IBMの調査によると、平均的なソフトウェアのコード1,000行のうち60個のバグが存在するといわれている。
• バグは早く発見すればするほど開発コストが減る。
  • バグを解析段階で見つける場合と機能テスト段階で見つける場合のコストを比較すると、25倍以上の開きがあるという。
  • ただし、要求仕様のバグは非常に優秀なテストエンジニアでないと発見できない。逆に機能テスト上で発見するのは、それほどテストエンジニアのスキルは要求されない。
• 欲張って高い高機能なツールを買うよりも、絶対に自動化したい部分を実現してくれる安いツールを買った方がよい。
• テストコードにコメントを書く。
  • 実行したメソッドやクラスの中身が短くシンプルであれば、コメントも極力減らせる。ただし、テストコードの場合はテスト対象のメソッドに渡す引数の値、検証のための値などをコメントに残すべきである。
  • テスト対象のコードとテストコードは性質が異なるのである。テスト対象のコードにはロジックが書かれ、テストコードには具体的な数値を使う。
• テストの実行時間に注意を払う。
  • 時間のかかるテストのところには注意を払うと、改善すべきテストクラスが見えてくることがある。
  • またテストに時間がかかるようだと、頻繁にテストを実行する気がなくなったり、無意識のうちにテストの実行を避けてしまったりしてしまう可能性がある。これではTDDのリズムが失われてしまう。
• テスト同士が影響しあうようにしてはいけない。
  • それぞれのテストは完全に独立しているべきである。もしテスト同士が依存する必要があれば、それは1つのテストとしてまとめるべきである。
• ソースコードのリファクタリングの際には、テストコードの見直しも行う。
  • これにより、ソフトウェアの仕様を見直すこともできる。
  • テストコードは後から読み返したときにわかりやすいものであるべきであり*1、そのために日頃テストコードを確認してわかりにくいところがあればコメントも含めて修正する。こうすることで、テストコード自体のわかりやすさを保ちつつ、ソフトウェアを大きくすることができる。
• テストコードは仕様書やサンプルコードとしての意味を持つ。
  • テスト対象クラスのように完全に重複をなくすことを目指してリファクタリングすると読みにくくなることがある。そこで、テストコードの場合は多少冗長になったとしても、読みやすさに重点を置いたリファクタリングを行う。
• TDDで開発を行う場合は、テスト対象のコードとテストコードを同じディレクトリに配置した方がわかりやすい。
  • テストコードから作るというTDDの本質を忘れないようにできる。
  • チーム内の他のメンバーがTDDを徹底せずにテストクラスを作らずにテスト対象クラスを実装していたとしても、発見しやすい。
  • また、同一パッケージ内なので、パッケージ可視性のメソッドについても、リフレクションを使わずにテストできる。
  • しかしこのままだとクラスモジュール（classファイル）の場所もテストクラスとテスト対象クラスが混在してしまい、納品するソフトウェアの中にテストモジュールが含まれてしまう。そこで、earファイルやwarファイルなどのアーカイブを作る際には、Antなどのビルドツールを使って圧縮時に不要なファイルを外すようにする。
• 自動生成されたコードはテスト不要。
  • 例えば、Eclipseによって自動生成されたsetter/getterなどがそうである。ただし、そのsetter/getterの内部に手を入れて、状態を保持する以外の操作をしている場合にはテストは必要になる。
  • 自動生成されたソースの責任はそのソースを自動生成したツールにあるからである。
  • 自動生成されたソースは基本的に手を入れない方がよい。将来的にその元ネタが変わった場合に、再び自動生成することになり、手を入れた部分は消えてしまうからである。
  • Generation Gapパターンを使うという方法もある。
    • 自動生成されたものがクラスであった場合、そのクラスを継承したクラスを作り、そのサブクラスのほうで手を入れたい部分をオーバーライドすることで、自動生成の影響を受けにくくできる。
  • ツールやライブラリを信用しないとなれば、Javaに付属するクラスライブラリすべてにテストを用意しなければならないことになってしまう。
• テストメソッドの名前にこだわりを持つ。
  • 接頭語に「test」を付け、何の検証を行っているかがわかるようなテストメソッド名にする。
  • 例外を発生させるようなテストメソッドならば、「WithException」を付けるなどする。
  • Eclipseのリファクタリング機能を使えばいつでもテストメソッド名を変更できるからと思い、一時的にでも変なメソッド名にしておくと、仮にメソッド名の変更がされなかった場合に問題になる。
• テストコードを書くのは最終的に開発者である。人を大事にしなければならない。
  • チームとしての目的やビジョンを明確化したり、目に見える形で進捗管理を行うことで、TDDを行うためのモチベーションを上げることができる。TDDを行う意義をわかっていないで、単にテストクラスを最初に作ればよいという認識だと、TDDの強制によりテストコードから書くようになったがそのテストの中身をしっかり作っていなかったという問題が後でわかることもある。
  • モチベーションの向上こそがよいテストを書くための秘訣。
    • 対策のひとつとしてXPがある。
• Layersアーキテクチャパターンを応用すると単体テストがしやすくなることが多い。
  • このパターンはアーキテクチャをいくつかのレイヤーに分割することで、各層間の依存性を下げるというものである。
  • テストがしやすい部分とそうでない部分（例えばGUIやDB関連）を分けて、なるべくテストしやすい部分が大きくなるようにする。
• テストクラスがあるとデバッグしやすい。
  • テストがある状態でのデバッグであれば、その怪しい部分にダイレクトにテストからデバッグできる。
    • これはクラスとクラスで構成されているトレーサビリティに対して、横から割り込むことができるということである。
• よいテストとはバグを見つけるテストのことである。
  • システムがすべてのテストに合格するようにするのは簡単である。いい加減なテスト群（テストスイート）を使えばよい。しかし、すべてのバグを排除するのは簡単ではない。
• Javaの場合、checkstyleの警告を「@SuppressWarnings("unchecked")*2」などを使用して無視できるが、なるべく無視しないようにする。
• テストでは欠陥を示すことはできるが、どんなに時間をかけても欠陥がないことを明らかにすることはできない。
• テストがしにくい・複雑になってしまうテスト対象のメソッドがあったら、メソッドで一連の処理をすべて行おうとしている可能性がある。もし1つのメソッドであらゆることを実行していれば、それはメソッドの構造が悪く、処理によってメソッドを分割すべきである。こうすることで構造としても正しく、なおかつテストもしやすい状態になる。またこのように分割しておくことで、新しい機能拡張に対応した後にテストをしてバグが見つかった場合に、デグレードした箇所を早期に発見しやすい。
  • 例えば、メールを送信する処理のメソッドがあった場合、このメソッドだけでメールの送信先のチェックやメールの送信処理などを含めるのではなく、メールの送信先のチェックのメソッド、メールの送信処理のメソッドを用意し、これらのメソッドを一覧の流れにあうように呼び出すメソッドがあればよい。
• 外部システムと連携する部分のテストにはモックフレームワークを利用すると楽（モッククラスを作成して、リフレクションを用いるという方法もある）。
• 連鎖的に呼び出される処理はなるべく最小限に抑える。
  • 例えば、テスト対象のメソッドが実行するメソッド内で画面を表示したり、ログを出力したりするときは、画面を表示せずログを出力しないモックオブジェクトに置き換えるとテストしやすい。
  • 画面を表示したりログを出力したりするクラスがFactoryによって生成されていれば、そのFactoryで生成されるものをモックに置き換えてしまえばよい。
  • インスタンスを生成するためにnewさせるのではなく、Abstract FactoryクラスのgetInstance()から取得できるようにする。getInstance()で返すオブジェクトは自身の派生クラスとする。
    • テストのときはAbstract Factoryクラスにモックオブジェクトに対応する派生クラスを作り、リフレクションなどを使ってgetInstance()時にその派生クラスのオブジェクトを返すようにする.
• プロジェクトの責任者はテストクラスを作成する工数を認め、スケジュールにはその工数を加味しなければならない。
  • 品質保証チームでプロジェクトの進捗を可視化する仕組みを導入していたとしても、テストクラスがなければカバレッジ率を参照してテストの進度を客観的に把握することができないからである。
• ブラックボックステストでは、詳細設計（JavaDocなども含む）がきちんとかかれている必要がある。
• ホワイトボックステストは時間がないときに有効。
  • 内部処理が自明なとき（ロジックがなくJavaの機能を単に利用している。エラー時は例外をスローする）はそのテストを省略できる。また、詳細設計が不十分のときでもテストケースが記述できる。
• UTの1つのテストメソッドに複数のテストを同時にやらない。
  • 例えば、データの状態を初期状態にしてから管理するメソッドのテストにおいて、管理されているデータのチェックと初期状態で管理されていることを同時にやるなどは好ましくない。やるならば、別々のテストメソッドにわける。
• テストがうまいかどうかは、「網羅性」を持ったテストを作成し実施できるかどうか、またうまく「ピンポイント」で狙っていけるかにかかっている。
  • 仕様書に書かれていることを順番に飛ばさずに確認することは、仕様書を網羅的にテストしていることになる。
  • テストの工数を考えると、同じ深さのテストを全体に対して実施することはできないが、部分的に複雑な確認をしたい、バグが潜んでいそうといった部分をピンポイントで狙う。
• 仕様のチェックの場合には仕様書が汚れることを恐れずに、三色ボールペンを用いて行うとよい。
  • Wordベース（セキュリティの観点からあまり紙に印刷することが望ましくない場合など）のときは、読みながら文字列の背景色をつけていく。
  • ボールペンをノックする動作が頭のスイッチを切り替えることになるらしい。
  • 三色はそれぞれ次の意味を持つ。
    • 赤色：客観的に見て、最も重要な箇所
    • 青色：客観的に見て、まあまあ重要な箇所
    • 緑色：主観的に見て、自分が怪しいと感じた箇所
• 例示したデータを見て、「間」「対称」「類推」「外側」を考える癖を付けることで、どんどんテストがうまくなっていく。
• 原因が書いていないバグ票はほとんど役に立たない。
  • バグの原因を読んで「どうしてそのようなバグを作りこんでしまったのか」と想像することがバグ発生の負けに図無を自分の中に蓄えるよい訓練になる。
• テストは開発プロセスと同じようにプロセスとして扱う必要がある。
• テストは欠陥があることしか示せない。
• テストを実施して不具合が1件も見つからなかった場合は次の2つの可能性が考えられる。
  • ソフトウェア（テスト対象）の品質が高い。
  • テストの品質が低い。
    • 回帰テスト以外の場合で不具合が0件というのはほとんどありえないので、上記の結果はこちらが要因である可能性が非常に高い。
• 開発者とテスト実施者（品質管理担当者を含む）は違う人がやるべきとよくいわれるのは、それぞれが姿勢が異なり、状況に応じてその姿勢を切り替えにくいからである。
  • 開発者とテスト実施者は品質のよい製品をリリースするという最終目的は同じだが、それを実現するための個々の作業の姿勢が異なるのである。
    • 開発者はできる限り不具合を出さないという姿勢を持ち、テスト実施者はできる限り不具合を出すという姿勢を持つためである。
• テストのことを考えながら設計・コーディングを行うと、事前によく考える癖がつくために、バグが少なく試験もしやすい高品質なコードになりやすい。
• 有効な値（正常系）は複数同時に確認できるが、無効な値（異常系）については1回に1つずつしか確認できない。
  • つまり、異常値は他の異常値を隠す。
• テスト技法にとらわないこと。
  • 同値分割や境界値分割といったテスト技法を適用すると、それ以外のテストをやらなくてもよいと考える人がいるが、それはよくない。思いついたものはどんどんテストケースに追加すべきである。
• 内部カウンタのようなものは仕様書に表れず、設計で作りこまれてしまう場合も多い。
• バグが多いということは、テスト設計ミスも犯しやすい。
  • テスト設計ミスを犯さないために、仕様を図にして理解し直すとよい。
• 同値分割と境界値分析のテスト設計の結果は、開発者と共にレビューする。
  • 日付と時刻の終端処理、ループ境界や隠れた境界は仕様書だけでは見落とす場合が多いからである。
• テストをやりやすくするアーキテクチャについて、テスト担当者は開発者と共に議論するとよい。
  • 開発者とテスト担当者がお互いの仕事を理解しあうことで全体がよくなっていくはずである。
• 開発者はプログラミングの前に気をつけなければならない点に気が付けば、バグの総数を減らすことができる。

エラー・欠陥・処理不正 †

1：人間はエラー（error）を起こす。

2：エラーがコード・ソフトウェア・ドキュメントの欠陥（defect）になる。

3：コードの欠陥が実行されると不正処理（failure）が起こる。

ソフトウェアが期待通りに動かないことによる不都合 †

1. 経済的な損失
   • トラブルが発生したソフトウェアの修正や再テストにかかるコスト、クレーム受付や製品回収などのトラブル対応にかかるサポートコスト
   • ソフトウェアを使用しているユーザ企業の業務が泊まってしまうことにより発生する損害への補償や機会損失（機会費用）*3
   • 2002年5月に発表された米国NISTの調査報告書によれば、ソフトウェアが正しく動作しないことにより米国経済は年間595億ドルの損害を被っているという。そのうち3分の1は適正なテストを実施することにより回避可能なものと見込まれている。
2. 時間の浪費
   • システムのトラブルによって起こるソフトウェアの修正作業は本来別の開発に使う予定であった開発担当者の時間を圧迫する。
     • 単純に対象の製品に対するコストが増加するのではなく、一見関係ないと考えられる他の製品の開発コストやスケジュールにまで影響を及ぼし、マネジメント的な調整が必要になる。
   • 開発担当者の労務時間を増やすことで対処することも多く、この場合は精神的・体力的なストレスから健康問題に繋がることもある。
3. 信用の失墜
   • 品質の低下は信用の失墜に繋がり、製品競争力の低下に繋がる。
4. 傷害や死亡事故
   • 2001年にパナマの病院でがん治療に利用する放射線装置のソフトウェアにミスがあり、患者に対して許容量異常の放射線を浴びせたために、5名の命を奪ってしまった事件があった。

テストの一般原則 †

1. テストは欠陥があることしか示せない。
2. 完全なテストは不可能。
3. 初期テスト
   • テストできることはなるべく早くテストした方が、効率的に品質のよいシステムあるいはソフトウェアを開発できる。
4. 欠陥の偏在
   • 欠陥の多くは特定のプログラムやコンポーネントに集中する傾向にある。
5. 殺虫剤のパラドックス
   • テストケースとして定義したもの以上の欠陥は見つからないので、品質を継続的に向上させたければ、テストケースを見直したり、追加すべきである。
6. テストは条件次第
7. バグゼロの落とし穴
   • たとえすべてのケースをテストしてバグがないことが証明されても、要求仕様の漏れや間違いがないことが証明されたわけではない。

ソフトウェアテストの分類 †

工程による分類 †

開発側による工程 †

1. 単体テスト（コンポーネントテスト、ユニットテスト）：モジュールごとに行うテスト。
   • 増加テスト：単体テストが終わっているモジュールを、順にテストしていく。
     • トップダウンテスト
     • ボトムアップテスト
     • サンドイッチテスト（折衷テスト）
2. 結合テスト（統合テスト、集積テスト）：モジュールを結合して行うテスト。
   • 一斉テスト
   • ビッグバンテスト
3. システムテスト（総合テスト）：システム全体の動作を確認するテスト。
   • 機能テスト
   • 性能テスト
   • 負荷テスト
   • 操作性テスト
   • 耐久テスト

顧客側による工程 †

1. 運用テスト：ユーザー側の運用担当者が中心となり、実際にシステムを使用しながら不都合な点がないかどうかを確認するテスト。
2. 受け入れテスト（承認テスト）
3. 導入テスト（システム移行テスト）

品質による分類 †

• 機能テスト
• 性能テスト
• 負荷テスト
• ユーザビリティテスト
• セキュリティテスト

実行方法による分類 †

• 動的テスト（dynamic testing）：プログラムを実行して、その結果を確かめる方法。
• 静的テスト（static testing）：プログラムを実行せずにテストする方法。
  • レビュー
  • 静的解析

テスト技法による分類 †

• ブラックボックステスト
• グレーボックステスト
• ホワイトボックステスト

その他 †

• レグレッションテスト（退行テスト）
  • プログラムの修正後、他の機能に影響を及ぼしていないかどうかを確認するテスト。

テストデータ設計の手法 †

　各設計工程では何をどう検証するのかについて、設計担当者がテスト計画として作成する。テスト計画では「テストで何を確認すべきか」「どんなテストを用いるか」「どんな人員・機材でいつ行うのか」などを決定しておく。テストデータ（テストケース）設計とは、「必要なテストを行うにはどんなテストデータが必要なのか」を計画し、テスト用のデータを作成することである。

　テストデータ設計技法は、マイヤーズ（G.J.Myers）によって、次の2つの方法が提案されている。

• ブラックボックステスト
• ホワイトボックステスト

ソフトウェアテストの問題点 †

• テストは実は欠陥を増やしている。
  • 一般的に欠陥の修正は前の開発工程に遡って行うことが多いが、この後戻りの長さが長いほど修正を間違いやすいものである。そのため、テストで欠陥を発見・修正することは、設計工程での欠陥チェックに比べて後戻りの長さが非常に長く、間違った修正や新たな欠陥を作りこむ可能性が大きいとされている。
• テストで欠陥を発見するのはコストがかかる。
  • 一般的に後戻りの長さが開発コストの高さに比例する。つまり、開発の初期段階に修正するほどコストが低く済む。
• テストですべての欠陥を除去するのは不可能である。
  • たまたま入力した値に対して期待する出力値が得られたとしても、入力として考えられるすべての値に対して予期した出力が得られるという証明にはならない。しかも、すべての入力値を用いてテストすることは実際問題として不可能である。

　ソフトウェア開発における選択肢として次が挙げられる。

• 問題点はあるがソフトウェアテストを行って、バグが見つかったら修正する。
  • 一般的なソフトウェア開発手法ではこちらを採用している。
• ソフトウェアテストを行わずに、バグがあったらそのプログラムを破棄する。
  • このアプローチを採用したのがクリーンルーム手法である。

テストケース †

• 日立ソフトの報告によれば、ソースコード10〜15行あたりに1つのテストケースが必要であるという。

テストケースの書き方 †

• 曖昧な表現・記述をしない方がよい。
  • なぜならばテストケースは普通テストサイクルで利用されると共に、正しくバグ修正が行われたかをチェックする回帰テストにも使われる。開発期間中何度となく利用されるため、いつ誰がやっても同じような結果が得られるように書く必要がある。

テストケースの実行 †

• 日付、テスト結果、実施者、ビルド番号（どのビルドでテストを実行したのか）、環境を書き込む。
  • こうしたログはメトリックスの資料として役立つ。
  • 万が一重大なバグがユーザー側で発生した場合、どのような経緯でそのバグが開発期間中に発見できなかったといった分析にも役立つ。
• テストケースを実行する上で、どの順番で実行するかについては考えた方がよい。
  • ただ上から順に実行するのではなく、リスクを考えながら実行すべきである。

テストの自動化 †

自動化に向くテスト †

• スモークテスト
  • たくさんの回数を繰り返すから。
• パフォーマンステスト
  • たくさんの人を集めるよりも、ツールでたくさんシミュレートした方が楽だから。
• APIのテスト
  • APIはそれほど変更がないから。

自動化に向かないテスト †

• 回帰テスト
  • プログラムの度重なるユーザーインタフェースの変更のせいで、自動化プログラムのほとんどが動かなくなるから。それでも自動化していくと、自動かするテストケースの数はまったく増えず、既存の自動化コードのメインテナンス作業だけになってしまうことが多い。
• グラフィックスやサウンドなどのメディア関連のテスト

後でまとめてテストすることがいけない理由 †

調査時間 †

• IT以降でバグが見つかったときに、バグの原因を特定するのが困難。
  • 関連するプログラムの内部処理をすべて調べて、さらに場合によってはプログラム間のデータ連携を調査する必要がある。
  • もし小さな単位でテストしていた場合ならば、怪しいのはプログラム間のデータ連携のみと原因と特定しやすい。

現場のモチベーション †

• 仕様の理解が不足していたために発生したケースから、入力チェック漏れのケースなど様々なレベルのバグが発見されてしまう。
• バグが報告されると、再現するかどうかを確認し、原因を特定する。その原因を修正し、バグが解決したかどうかを確認するという手順を行う。レベルの低いバグのときは、修正の際に他のプログラムへの影響を気にする必要がある。これを繰り返していると、現場は常に高負荷状態になってしまい、開発者は目先のタスクを減らすために修正したプログラムが他のプログラムへ影響を及ぼすことを確認しないまま対応完了としてしまうかもしれない。すると、後でデグレードが発生してしまい、さらに現場のモチベーションは下がってしまう。また時間をかけたにも関わらず、テスト開始前と開始後ではソースコードの総ステップ数があまり変化しないことより、生産的な作業をしていないと思うこともモチベーションの低下につながる。
  • UTを早い段階で行っていれば、開発とテストが同一人物であればソースコードの記憶がまだ残っているため、見つかったバグの原因を特定しやすく、また修正も早いはずである。
  • UTで軽微なバグを減らしておけば、その後のITでは仕様の理解ミスやしようバグへの対応だけに集中できる。

バグ対応の選択肢が限られる †

• リリース間際になってくるとバグに対する打つ手も限られてくる。
• UTを先送りすることはリスクの先送りであり、バグがあったときにプロジェクトの進捗に深刻な影響が出てしまう。

よいテストの条件 †

• 目的が明確である。
  • カバレッジ率を見るためだけに、テスト対象メソッドをテストメソッドから呼び出すのではテストをしていることにはならない。テスト対象メソッドを呼び出すことで何か変化が起こり、その変化が正しいものであるかを確認しなければ意味がないのである。
• 繰り返し実行可能である。
  • テストは何度実行しても同じ結果にならなければならない。
  • 実施するのにいくつもの手順を手動で行わなければならないテストもよくない。
  • テスティングフレームワークを使用することである程度自動的に繰り返しテストを行うことができる。
• 環境に依存しない。
  • テストはどのマシン上でも実行でき、同じ結果にならなければならない。
  • パッケージ開発のようにOSやJRE、DBMSのバージョンの組み合わせでテストをしなければならない場合はその限りではないが、同じ環境でありながら開発者が異なることでテスト結果が変わるようではいけない。
• テストが独立している。
  • どのテストも他のテスト結果に依存することなく実行できなければならない。
  • 他のテストが失敗したことによって、失敗するテストはよくない。

テスト設計技法の分類 †

JSTQBにおける分類 †

1. 仕様ベースのテスト技法
2. 構造ベースのテスト技法
3. 経験ベースのテスト技法

仕様ベースのテスト技法 †

• コンポーネントやシステムの内部構造を参照することなく、それらの機能的あるいは非機能的な仕様の分析に基づいてテストケースの取捨選択を行う手順のこと。
  • ブラックボックス技法に対応する。

仕様ベースのテスト設計技法 †

• 同値分析
• 境界値分析
• デシジョンテーブル・テスト
  • デシジョンテーブルとは、入力データや状態など入力条件の真偽の組み合わせと、起こりうる動作の有無や出力結果を表にしたもの。
    • V字モデルにおけるソフトウェア要求分析やソフトウェア設計で、ソフトウェアやコンポーネントの機能仕様を定義するために作成される。
  • デシジョンテーブルに表されるルールからテストケースを導き出すテスト設計技法。
  • アプローチとしてはすべてのケースを確認するだけではなく、各動作が行われるケースを洗濯して行うこともある。
• 状態遷移テスト
  • テストアイテムの状態遷移図や状態遷移表から、テストケースを導き出すテスト設計技法。
• ユースケース・テスト
  • ユースケースのシナリオを元にテストケースを導き出すテスト設計技法。
  • 基本フロー、代替フロー、代替フローの組み合わせなどといったどのシナリオをテストケースとするかはデシジョンテーブルと同様に、システムに求められる品質によって決定される。

構造ベースのテスト技法 †

• コンポーネントやシステムの内部構造の分析に基づいてテストケースの取捨選択を行う手順のこと。
  • ホワイトボックス技法に対応する。

構造ベースのテスト設計技法 †

• ステートメントカバレッジ（コードカバレッジ）
• デシジョンカバレッジ（ブランチカバレッジ）
• 条件カバレッジ
  • プログラム内の分岐で起こりえる条件に着目し、分岐内の条件をどの程度網羅できるかという観点でテストケースを作成する。

経験ベースのテスト技法 †

• テスト担当者の技量に依存する。
• 品質のバラツキが多い開発組織では、テストや品質に対する理解が不足しており、経験ベースのテスト技法だけでテストを行っていることが多い。
• 仕様ベースや構造ベースのテスト技法では見つからないような欠陥も見つけられることがあるため、仕様ベースや構造ベースのテスト技法と併用すると効果的である。

経験ベースのテスト設計技法 †

• エラー推測（error guessing）
  • ソフトウェア開発でありがちな誤り（エラー）を、テスト担当者が推測してテストケースを作成する技法。
    • 例：オーバーフロー、ゼロ除算、配列のインデックス、バイトの境界、うるう年など。
• 探索的テスト（exploratory testing）
  • テストアイテムの仕様がなかったり、アップデートされていなかったりしたときにテスト担当者が正しいであろう仕様を推測して、テストケースを作成すること。また、テスト期間が限られているときに、仕様ベースや構造ベースのテスト設計や実行と平行して、テスト担当者が自身の知識や経験からやっておくべきテストケースを作成して実行したりして、少しでも品位を上げるために行う経験ベースのテスト設計技法のこと。

テストコード †

• 可読性のよくないテストコードは作成者しか理解できず、保守性が落ちる。
  • 可読性の基準は人によって異なるので、実装に取りかかる前にプロジェクトの中でコンセンサスを取っておく必要がある。
• EclipseであればCheckStyleなどを活用する。

テストをしやすいように実装 †

• 実装時に静的解析ツールを使うことで、問題点になりそうな箇所を早期に発見できる。
• 処理の依存関係が疎である。
  • 他の処理に依存しないように小さな単位でメソッドに分けるとテストしやすい。
• テスト済みのユーティリティソフトを実装に使う。
• メソッドを呼び出す際の引数の与え方に配慮すると、単体テストがしやすくなることがある。
  • メソッドの引数の型に意味を持たせる。
    • 引数がString型のpublicメソッドの場合は、特に入念なチェックが必要である。
    • 引数がObject型のときは、そのメソッドの呼び出し元において、メソッドの呼び出し前に引数で与えるものは正しい状態かどうかを確認するコードが必要である。
    • 引数のオブジェクトを変更するメソッドの場合はJavadocに記述しておき、呼び出し元の実装者にその意図を伝える。
• 時間と共に変動するような値を用いるようなメソッドの場合はデバッグモードを作るか、時間と共に変動する値そのものを引数に受け取るようにする。
  • データの更新日などを設定するメソッドでは、システム日付を使用することがある。システム日付を元にしたデータを戻り値とするメソッドは、実行の度に戻り値が変わるために単体テストのときに期待値との比較が難しくなる。また、ファイルの更新チェックやSQLのWHERE句に日時の判定があるを行うメソッドも通常は単体テストが難しいだろう。
  • デバッグモード時には固定値を返すようにするとよい。

例：

1 2 3 4 5 6 7 8 9 10 11

- | | - - | ! | | ! !

public class MyClass { public static boolean isDebug; public static Date createCurrentData() { if (isDebug) { return Date.valueOf("1979-10-16"); } Date date = [システム時間から取得したDate]; return date; } }

テストクラスの存在意義 †

• テストクラスがないとUTのレベルから手動で確認する羽目になる。
• 繰り返しテストを実施することができ、開発の方向性の安心を得られる。
• テストクラスを実行するプラグイン（例：JUnit）の他に、コードカバレッジを計算するプラグイン（例：EclEmma,djUnit）を利用することで、テスト仕様書に実施済みのマークをつけるよりも簡単にテストの進捗を客観的に把握できる。
• ユースケースがずっと不変である保証はないため、仕様変更は避けられない。仕様変更のたびにゼロから作り直すことも考えられるが、ほんの少しの修正には時間とコストを十分かけられない。このとき元々テストクラスがあると、修正したことによってデグレードが発生していないどうかを効率よく確認することができる。
• システムで使用しているミドルウェアやフレームワークをバージョンアップする際に、テストクラスがあればバージョンアップの影響によって不具合が発生していないかどうかを確認できる。
• 単体テスト以降におけるテストにおいても利用される。
  • 結合テストでバグが発見され、その修正をしたときにデグレードしていないかどうかを確認するために単体テストのテストクラスが利用される。
  • 負荷テストでパフォーマンスを下げる箇所を特定できたときに、テストクラスがあればリファクタリングで内部ロジックを大幅に変更したとしても、他おプログラムの動作に影響がないことを手間をかけずに調べることができる。

テストクラスから派生されるファイル †

• テストクラスから生成されるファイルはバージョン管理システムの管理対象とする必要はない。

抽象クラスのテスト †

1. 抽象クラスの実装クラスを代用する方法。
2. 抽象クラスの実装クラス（抽象メソッドだけ実装し、中身の処理としては何もしない。戻り値のある抽象メソッドの実装であれば、単純な値を返すようにするだけでよい）をprivateのインナークラスにして、それを利用する方法。

モックフレームワーク †

分類 †

1. 実行する際に実際のオブジェクトとモックオブジェクトをバイトコードレベルで置き換えるタイプ
   • 例：JMockit
2. 処理対象のインスタンスに振る舞いを記録させたモックオブジェクトを置き換えるタイプ
   • 例：EasyMock

ソフトウェア開発での手戻り †

• テストでバグを見つけきれずに、バグを作りこんだプロセスまで遡って修正を行うこと。

手戻りによる影響 †

• 手戻りが発生すると、その影響はソフトウェア開発に広く波及する。
• 開発工数、予算、エンジニアのモチベーションに悪影響を及ぼす。

手戻りを防ぐ方法 †

• 動的テストを行う。
  • プログラムやシステムを動作させて確認するテストのこと。
• 静的テストを行う。
  • 机上での論理的な確認やエンジニア同士の相互チェックによってプログラムやシステムを動作させずに確認するテストのこと。
    • コードレビューやドキュメントのレビュー、ウォークスルーなど。

関連用語 †

• バグ
• デバッグ
• ダンプ

参考文献 †

• 『知識ゼロから学ぶソフトウェアテスト』
• 『経験ゼロでもできるプログラミング現場の単体テスト』
• 『バグがないプログラムのつくり方　JavaとEclipseで学ぶTDDテスト駆動開発』
• 『演習で学ぶソフトウェアテスト特訓150問』
• 『[ソフトウェアテスト教科書] JSTQB Foundation』
• 『ソフトウェアテスト入門』
• 『The BUG』
• 『ソフトウェアテスト技法ドリル』
• 『超図解mini　基本情報技術者試験　平成19年度版』
• 『2001秋　徹底解説　基本情報技術者本試験問題』
• 『1週間で分かる基本情報技術者集中ゼミ【午前編】　2006春秋』
• 『合格情報処理2006年9月号』
• 『平成12年度　【要点・重点】短期集中速攻対策　第1種』
• 『ソフトウェアテスト技法ドリル』