バックエンドエンジニアがテストについて考えた

現在、スマホアプリを通じて、一般ユーザーにサービスを提供するシステムのバックエンドの開発、運用を実施しています。 今回はバックエンドの開発（運用は除外）の観点からテストについて考えたことをまとめたいと思います。

テストに対する考え方を抽象的にまとめました。 （ツールや手法に関する具体的な内容は別の機会を設ける予定です。）

前提

開発対象

• インフラの開発
• データベースの開発
• WebAPIの開発

インフラ環境の種類・特徴

• ローカル環境：Feature
  • 機能実装時のデバッグ環境
• 開発環境（≒バックエンド開発環境）：Develop
  • 機能実装時の動作検証環境
• 結合テスト環境（≒フロントエンド開発環境）：Staging
  • 本番環境と同等のスペック
• 本番環境：Production
  • 実際のユーザーがアクセスする環境
• （本番修正環境：Hotfix）
  • 必要に応じて稼働する環境。平常時はsleepしている。

環境別実施テスト

開発環境でのテストの目的

機能要件に対する確認
- 機能が正しく実装されていることを確認する
バグの発見+除去
- バグに対するコードの変更が、想定外の部分へ影響を及ぼしていないことを確認する

結合テスト環境でのテストの目的

フロントエンドとのI/Fの確認
非機能要件に対する確認
- 本番環境相当の性能が前提となるテスト

テストの種類

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

概要

• プログラムを構成する比較的小さな単位（ユニット）が想定通り動作しているかどうかを検証するテスト。
• 関数やメソッド単位で実施する。
• カバレッジ解析、及びテスト拡充を行うことがバグの早期発見につながる。（ホワイトボックステスト）

メリット

• 問題原因の特定や修正が容易。開発全体のバグ修正コストを下げる効果が高い。

課題

• 開発者にかかる負担が大きくなりやすい。

結合テスト

バックエンド内のパーツ結合

• 外部に提供する形（私の場合のI/FはWebAPI）で使用し、正常系および異常系が仕様通りの振る舞いをしていることを確認する
• 公開仕様を網羅するようにテストを拡充する

フロントエンドとの結合

• 外部（私の場合はスマホアプリ）から実際に使用して、想定通りの振る舞いをしていることを確認する
  • 私の場合はスマホアプリ開発が他のグループなので、疎通確認程度の確認を実施してもらっている
• 疎通確認

差分検証

• バグ修正をマージした際にバグ修正が正しく反映されていることを確認する。
• ブラックボックステスト

シナリオテスト（WebAPIの組み合わせテスト）

• 複数のWebAPIを順番に利用し、個々の結果及び最終結果が想定通りであることを確認する。

システムテスト

• ユースケースを想定したテスト
• エンドユーザーが実施する操作を想定したシナリオテストを実施する

性能テスト（非機能要件に対する確認）

ロードテスト

• 想定ユーザー数、想定アクセス数相当での負荷をかけた際に、想定通り機能することを確認する。

ストレステスト

• 実際に限界を超える負荷を与え、最初に発生する部分はどこか、どのような問題が生じるかを確認するテスト。
  • 結果をもとに、発生する問題が許容可能な内容か、問題に対しどのように対応を行うかをあらかじめ想定しておく。

脆弱性検証（リリース準備期に実施）

• インターネット上に公開されるサービスであるため、あらゆる攻撃に対する耐性が必要になる。
• 重大な問題が発覚した場合は、リリースを中止せざるを得ない場合もある。

WebAPI

• WebAPIを悪用する攻撃への耐性を確認する。

インフラ

• インフラの使用方法等により生じる可能性がある脆弱性の確認を実施する。

システムテスト（リリース準備期に実施）

• ユースケースを想定したテスト

疎通確認テスト（リリース時に実施）

• リリース内容が正しく反映されていることを確認するためのテスト

テスト機能のためにポイント

テストに対するコスト（時間、手間、予算）は品質と連動しやすい要素だと思いますが、計画の範囲内で効果を最大化することを検討する必要があります。
効率的な開発のために出来ることを検討します。

品質を高める

開発環境へのテスト実施回数を増やす

• 開発段階で実施するテストを充実させることが、早い段階での品質向上に貢献しするとともに、手戻りを減らすことがができます。

自動化する

• 開発環境に対するテスト（単体テスト、結合テスト、シナリオテスト）は自動化するためのツールがそろっていることが多いです。
  • テストの実施～テスト結果の通知を自動化することで、バグ発生～バグの発見～バグ修正の時間サイクルを短縮することが可能になります。

ルール化する

• テストはスキルの違いと意識の違いの両方が影響する項目です。
• この違いにより、作成・実施されるテストの質と量が大きく影響を受けます。
• この差を埋めるための手段として、プログラムをリリースするための条件にユニットテストのカバレッジ、結合テストの実施レポート作成等を定めることをお勧めします。

効率を高める

専門性が高い項目は業務委託をする。

• 脆弱性検証は最新の攻撃手法や対応方法に対する情報更新コストが非常に大きいので専門家に委託することをお勧めします。
• 社内で専門チームを育成しても、世間的に需要の高い技術なので転職による機能喪失のリスクが高いです。

その他の記事へ

overworker.hatenablog.jp