ソフトウェアテストの基礎知識（モックとスタブ、テストピラミッド、テストケース例、負荷テスト）

テスト工程の種類

ユニットテスト（単体テスト）

クラスやメソッドを対象にしたテストであり、ソフトウェアテストの中では最も粒度が小さいテストのことです。

結合テスト

トップダウンテスト

テスト対象のモジュールを上位から下位に実行していくこと。トップダウンテストを行う際に実行できないテストがあった場合はスタブという仮の下位モジュールを用いてテストを行うことになります。

システムの中枢に致命的なバグがある場合に早期に検出できるメリットがあります。ただ、スタブを大量に用意しないといけないというデメリットがあります。

ボトムアップテスト

テスト対象のモジュールを下位から上位に実行していくこと。利用できない上位モジュールがある場合はドライバというダミーの上位モジュールを用意します。

上位のモジュールの方が数は少ないためドライバを用意するとしても手間はそんなにないが、中枢のプログラムの致命的なバグ検出ができないです。

ユーザー受け入れテスト

テストケースについて

テストケースとは？

テスト対象のクラス、メソッドに対して開発者が想定している様々なユースケースを記述したものです。

テストケース数の妥当性について

テストケース数の妥当性を評価する際はアプリケーションのステップ数が考慮する値になります。これをテスト密度と呼びます。アプリケーションの要望数とかではありません。最近流行りのCIツールによる自動テストを導入する場合でもアプリケーションのステップ数を加味して妥当かどうかを決めると良いでしょう。CIの中にステップ数カウンタを用意して、テストコードのテストケース数と照合するというようなことも行っていたりします。

テストケース例

認証のテストケース

• ログイン成功時に成功メッセージが表示されていること。
• ログイン失敗時に画面遷移してないこと。
• ユーザー登録に成功すること。
• ユーザー登録に失敗すること。
• ユーザー登録に成功したが、ログインに失敗すること。

通常のページのテストケース

• ボタンやテキストが存在しているか。（例えば、ログイン後のユーザー名が表示されているかなど）
• あるボタンを押した時にページ遷移がされるか。
• テキストボックスへの入力テスト
• APIからデータを取得するテスト（取得する前は何もデータがなく、awaitして取得したらデータが存在することを確認）
• APIからデータの取得に失敗した場合にデータがないことのテスト。（取得前は何もデータがなく、awaitして取得後も何もないこと）
• 削除して存在しないかチェック（awaitが必要）
• 関連削除も行われるかチェック(cascade)

モック(テストダブル)とは？

本物のオブジェクトのふりをするオブジェクトです。テストダブルと呼ばれる場合もあります。Rspecで言えばFactoryBotもモックの一つです。モックはデータベースにはアクセスをしないため処理速度は早いです。

テストダブル

検証機能付きのダブル

こちらの方が場合によっては通常のテストダブルよりも安全です。

モック化の危険性

もし、サードパーティ製のライブラリまでモック化してしまった場合はもし、そのライブラリに変更が入ってしまった場合はエラー報告をしてくれません。

スタブとは？

オブジェクトのメソッドをオーバーライドして事前に決められた値を返すダミーのメソッドです。DBやネットワークを使う処理が対象となります。

テストピラミッド

逆ピラミッドは手動テスト（UIテスト）の比率が多い状態を指しています。手動テストは非常にコストがかかるのでUIテストのテスト項目が多いと非常に開発コストがかかってしまいます。なので、できるだけアジャイルではUIテストの数は減らしたほうが良いと言われます。

テストの種類

ST(システムテスト）

• E2E(エンドツーエンド）に近い
• SIerなどで多いテスト専用部隊が画面を使ってテストに近い。(Web業界でも行うが）
• テストの実行速度が遅い。
• 実リソースを使うので実行コストが高い。
• 範囲が広い。

具体的に何をテストするか。

全てのサービスをスタブなどを使わずにつなぎあわせてテストする。（実リソースを使う。）

IT(インテグレーションテスト）

• STとUTの特徴の中間
• 「ユニットテストでカバーできない範囲」と「つながりの部分」を結合テストでカバーする。

具体的に何をテストするか。

システム内の他のサービスに接続されたサービスのスタック全体をテストする。（外部サービスはスタブを使う。）

UT(ユニットテスト）

• テストの実行速度が速い。
• 実行コストは低い。
• 範囲が局所的。

具体的に何をテストするか。

クラスのパブリックインターフェースをテストする。

ソフトウェアテスト手法の種類

ホワイトボックステスト

内部ロジックや、仕様について考慮した上でテストケースを設計し、ユニットテストではこれを中心にテストを実施します。

基本的には、プログラムの内部仕様について理解しているプログラマしかテストすることはできません。

内部ロジックに依存しすぎると落とし穴も…。

内部ロジックに依存しすぎたテストケースやテストデータの作成は、変更に弱くなってしまいます。

なので、できればホワイトボックステストに、ブラックボックステストを組み合わせるとより良いです。

例

• 命令網羅
• 条件網羅
• 分岐網羅
• 判定網羅

ブラックボックステスト

ソフトウェアの内部仕様について考慮せずに、外部仕様のみ考慮してテストを実施することで、ユーザー受け入れテストや、機能テストを実施する場合に採用します。

プログラムの知識よりも、業務知識が必要になるので、プログラマというよりは、業務に詳しいSEやプロジェクトマネージャーがテストケースを作成します。

例

• 同値分割
• 境界値分割

負荷テスト

ツール

以下のようなツールがあるので実際に想定されるリクエスト量を流す。

• Locust
• Apache HTTP server benchmarking tool(ab)
• Apache JMeter

Locust

Python製のツール、シンプルなシナリオが書けてメンテナンス製が高いです。Dockerでコンテナ化もできる。

事前の少量チェック観点

事前に少量だけ流して以下の観点でチェックします。

• 期待する一連のCloudWatchメトリクスは取得できているか。
• Auto Scalingのスケールアウトおよび、スケールインは設定されているか。
• アプリケーションのエラーは出力されているか。
• ログ出力の内容は適切か（欠損等はしてないか、ログレベルは妥当か）

本テスト

以下の観点でチェックをします。

• パフォーマンス要件で定義したリクエスト量が満たせているか。
• ECSタスク定義に割り当てられたCPU/メモリリソースに対して、余剰や逼迫が発生してないか。
• ECSタスク定義内の各コンテナに割り当てたCPU/メモリリソースに対して余剰や逼迫が発生してないか。
• Auto Scalingのスケールイン・スケールアウトが発生してないか。
• スケールアウトまたはスケールイン時にアプリケーションエラーが出力されていないか。