| layout | title |
|---|---|
default |
STEP3-3.テストとは |
ソフトウェアテストとは、ソフトウェアの動作が正しいかどうかや、速度が十分かなどを確認する作業のことです。ソフトウェアを作成したあとは、テストを行って問題が無いかを確認します。テストには、観点の違いや、発見したい問題の違い、手法の違いなどから、いろいろな種類があります。
- 単体テスト、結合テスト 単体テストは低レベル（実装に近い面）から行うテスト。関数が正しい値を返すか？等をテストします。結合テストは、単体の機能を組み合わせて、より高レベル（抽象的、仕様に近い面）から行うテストです。何を単体とするかは場合によります。
- 受け入れテスト システムの発注者が、発注したシステムが要求し機能や性能を満たしているかどうかを確認するテストです。
- 運用テスト システムが完成した物として運用を行ってみた場合に問題が無いかどうかを確認する。仕様のテストです。
- 負荷テスト システムにアクセスが集中した場合などを想定し、多数のコンピュータなどから擬似的にアクセスを行って問題が発生しないか確認する。
- セキュリティテスト セキュリティー的に問題ないかどうかを確認する。セキュリティーについてはSTEP3-9 で説明します。
- モンキーテスト テスト計画書がなく、とにかく触ってみて、異常が無いかどうか確認するテスト。
- ホワイトボックステストとブラックボックステスト 内部構造が分かっている状態で問題が無いことを確認するテストはホワイトボックステストと呼ばれ、内部構造にかかわらず入力と出力だけを見て仕様が満たされていることを確認するテストはブラックボックステストと呼ばれます。
ただし、これらの名前を厳密に区別することには、あまり意味がありません（現場によって、同じ名前で全く違う事を指す場合もあります）。
個々のテストにはそれぞれ専門の技術が必要とされ、「テストエンジニア」という専門の肩書きもあります。
開発を行う場合、より高レベルの視点からのテストに通っていないと、それが完成したとは見なされません。例えば「掲示板に書き込めること」などです。ただし、高レベルのテストが通らない場合に、低レベルのテスト（「フォームの名前欄に名前を入れて送信ボタンを押すと、内容がデータベースに書き込まれていること」など）があれば、原因の特定がより早くなります。
テストを行うには、まずテスト項目書と呼ばれるチェックリストを作成します。そして、すべての項目が達成されていることを確認します。
開発したソフトウェアの品質を担保するために、あるいは完成しているかどうかを確認するためにテストは必要ですが、ソフトウェアが複雑になるにつれて、非常に時間がかかります。通常の開発現場では全体の１／３～１／２程度の時間がテストにあてられます。
テストに失敗した場合、修正を行ってテストに通ることを確認しますが、ある部品を修正として動作を変更してしまったために、今まで成功していた別のテストに失敗する、ということもよく起こります。そのため、一度成功したテストでも、修正があれば再度行うべきです。
このようにテストは何度も繰り返し行われるため、自働化するのが合理的です。
テストの自働化とはテストをプログラム化するということです。
PHPUnit のようなテスト自働化フレームワークがあり、STEP 3-4 でその手法について学びます。テスト用のフレームワーク･ライブラリには、これらの他に、behat のようなBDD（ビヘイビア駆動開発）という開発手法に即して、仕様書のようにテストを書けるフレームワーク、selenium のようなブラウザを動かしてテストを行うライブラリ、QUnitのようなjavascript のテストを行うライブラリなどが存在します。
また、それらと Jenkins のようなCI(継続的インテグレーション)ツールと呼ばれるツールを組み合わせることで、少しでも修正を加えれば、すべてのテストを再度やり直す、テストに失敗したらチャットでお知らせする、等といった環境を構築することが可能になり、バグの発見がより素早く行えることになります。
ところが、高レベルなテストは自働化することが難しくなります。
例えば結合テストでデータベースとの連携が間違っていないことを確認するためには、データベースを用意し、データベースをテスト可能状態にして、確認プログラムを行う、などの必要があり、テスト環境を構築するのが難しくなります。
またより高次元な「相手と楽しく会話出来ること」のような要求についてはそれの定義から考えてプログラム化する必要があります。
他に、「ブラウザから送信ボタンを押す」というテスト用の動作を行うためには、簡単に実現することができません。例えばHTTPリクエストを行ってHTMLを解析してDOMを操作してボタンを押すことも可能ですが（例えば selenium というテストフレームワークは実際にブラウザを動かしてテストを行う事が出来ます）、ブラウザによる挙動の違いや、「実はボタンが重なっていてボタンを押すことができない」などの異常を検知することが難しく、最終的には人間が確認しないと安心とはいえません。そして javascript を動かす ajax なども PHP からプログラム化しようとするとかなりハードルが高くなります。
そのため、見た目に近い層や高レベルのテストは人間の手で行う事が多くなっています。
[課題]テスト項目書を作ってみよう
単体テストの書き方に関しては次回行うので、ここではブラウザから人間の手で行う高レベルなテストに関する項目書を作ってみましょう。以下にあるSTEP2-7.CakePHPでログイン機能を書いてみるで作成したログイン機能のみを持つアプリケーションのテスト項目書のサンプルを参考にしてみてください。