タイトルの通り、ソフトウェアテストの教科書を読んだので備忘録がてらにまとめてみます。
【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]を読んだので、自分が得られたものをまとめてみようと思います。
下記が今回読んだ本です。
前提として、この本のすべてをまとめるものではなく、特に関心興味があるところをピックアップしてまとめています。
テスト技法に関する細かい説明はぜひこちらの本を読んでください。非常にわかりやすく例とともに紹介されています。
テストの種類について
テストフェーズと対応する開発フェーズ
| テストフェーズ | 目的 | 対応する開発フェーズ | 含まれるテスト項目 |
|---|---|---|---|
| 単体テスト(UT) | 詳細設計書通りにモジュールが動くかどうかをテストする | 実装/詳細設計 | 機能確認テスト*1 制御フローテスト データフローテスト |
| 結合テスト(IT)・機能テスト | 結合テストはソフトウェアの論理構造が適切かどうかをテストする。 機能テストは組わせたモジュールを1つの機能として振る舞いをテストする。 |
設計 | 状態遷移テスト 機能確認テスト*2 |
| システムテスト(ST) | 要求定義の内容が実現されているかを確認する | 要件定義 | 確認テスト RT 評価テスト 負荷テスト(PT) 環境テスト 機能確認テスト*3 |
*1 1つのモジュールが詳細設計書や機能仕様所通りに動作することを確認するテスト
*2 モジュール同士の連携や複数のモジュールで実現される気宇が、詳細設計書通りに動作することを確認するテスト
*3 ユーザの要求を満たすために、ソフトウェアに備わった各機能の働きが詳細設計書どおりに動作することを確認するテスト
次に、機能確認テストと、システムテストに含まれる、負荷テスト、確認テストを対象に深堀します。
機能確認テストのイメージ
機能確認テストが3つあるんでそれについてちょっと深堀をします。
それぞれの機能確認テストは見ているスコープが違うよっていう感じです。
下記のように外部から呼ばれているAPIを考えます。
単体テストはController、Serviceとかのレイヤーの中にあるpublicメソッドの振る舞いをテストする。
結合テストだと、WEB APIのテストをする場合、外部からcurlで読んだ時にController 、Service、Repositoryを通った結果をテストする形。イメージとしては外部システムから、各対象の単一エンドポイントを呼び出している状態。
システムテストの場合ユーザが利用する環境において期待通りの動きをしているかをテストする。UIに表示されるのは外部システムが複数のAPIからのレスポンスを処理して画面に表示するように整形したようなテストです。
テストフェーズが後になるほどテストのスコープが広がっていく感じです。
負荷テスト
負荷テストはパフォーマンステスト共呼ばれるもので、ここではさらに以下の6つに分類されています。
- 性能テスト
- 処理能力が要求を満たしているかを確認すr
- ロングランテスト
- 長時間の連続稼働によって処理能力や稼働率に問題が生じないか確認する
- 大容量テスト(ボリュームテスト)
- 大容量又は大量のデータを処理できるかを確認する
- 記憶領域テスト(ストレージテスト)
- リソースが不足している状況下での動作を確認する
- 高頻度テスト
- 一定期間内にクエリ返した医療の処理を行った場合に問題が生じないことを確認する
- 負荷テスト(ストレステスト)
- 極端に高い負荷をかけた状態での動作を確認する
- こちらの本では説明されていませんが、スパイクテストがあります。スパイクテストは瞬間的にストレステストよりもさらに高い負荷をかけるテストです。出展
確認テスト
このテストでは一度テストされている事項を再度確認するテスト。この中にさらに下記のようなテストが含まれています。
- 修正確認テスト
- ソフトウェを修正変更した後に、変更箇所及び関連する箇所が正しく動作するかを確認するテスト
- リグレッションテスト(RT)
- ソフトウェアの修正・変更後に新たなバグが入ってないことを確認する
- 範囲は直接・間接的に関係あるもの
- スモークテスト
- テスト実施前にテスト対象のソフトウェアがテスト実施に値する品質であるかをテストする。
- リリースチェックテスト
- 出荷候補に対する動作確認テスト
- 実感としてはリリースをするタイミングで行う判定チェックのようなものかなと
実際のテストでやること
各テストで共通すること
- テスト計画
- リソースの調達スケジュール管理
- 各テスト工程の目的と範囲を明確にする
- 成果物：テストスケジュール、テスト目的や役割が示されたドキュメント
- テストスケジュールはJiraなどに含まれている場合もあると思います。
- いっぽうで、本番のリハーサルを伴う場合については、タイムチャートなどもこれに当たるかと思います。
- テスト設計
- 各テスト工程について下記を決める
- テストの種類や目的
- テスト対象機能
- 使用するテスト技法
- テストの入力・出力に何を使用するか
- 合否判断の基準
- 成果物：テストフェーズの目的・実施時に利用する方法
- ディシジョンテーブル
- 各テスト工程について下記を決める
- テストケース作成
- 下記を明示したドキュメントを作る
- 開始前の状態
- 期待結果
- 判定欄
- 成果物：テスト仕様書
- 場合によっては下記もここに含まれる
- 状態遷移表
- テストマップ
- 場合によっては下記もここに含まれる
- 下記を明示したドキュメントを作る
- テスト実施
- テストケースを見ながら実際にソフトウェアをどうさせてテストを行う
- 期待値と異なるものがある場合についてはここで下記を記載する
- 操作
- 入力値
- 条件
- 実際の結果
- 成果物：テスト結果
- 中間成果物：テストデータ、テストコード
- テスト報告
- 下記を見てストを評価する
- 各種データ
- 不具合データの件数やランク別の不具合件数
- 成果物：テストレポート、不具合レポート
- 下記を見てストを評価する
ホワイトボックステストとブラックボックステスト
ホワイトボックステスト ：ソフトウェアの論理構造に注目する
ブラックボックステスト ：ソフトウェアの論理構造に注目しない
論理構造とは各モジュールが必要とされる処理結果を得るためには複数の処理の流れや実行順序のこと。
ホワイトボックステスト
個々に含まれるのは制御フローテストや状態遷移テスト
この時に意識するのがカバレッジ基準です。
大きく3つでよく言う網羅と対応させるとこうです。
| カバレッジ | 網羅 |
|---|---|
| ステートメントカバレッジ | 命令網羅 |
| ディシジョン(ブランチ)カバレッジ | 条件網羅、判定条件網羅 |
| 復号条件カバレッジ | 復号条件網羅 |
復号条件網羅は真偽値しかないのであれば、ビット全探索で作ると楽なんだろうなというイメージですね。
テスト自動化
これまでの章では手動テストかつウォータフォールの進め方が前提です。
この章ではアジャイル開発の話と混ぜて自動化について語られています。
アジャイルのことは詳しく説明しませんが、ざっくりとリリースまでの期間が非常に2週間とかの短い単位で複数回行う開発スタイルだと思ってください。
詳しく知りたい人は
本ならアジャイルサムライ https://amzn.asia/d/052jL688
記事だとここら辺が分かりやすいと思います。 https://qiita.com/kyawphyonaing/items/8cd30ac818da2c7ce0e0
そんなアジャイル開発の中ではテストを手動でやりながら短い期間で開発し、リリースするのは非常に困難です。
そこで、自動化の話が出てきます。
導入前に考えること
- ツールの選定
- 小さなプロジェクトでPoC
- 費用対効果の見積もり
- ツール利用に関する教育
- 属人化防止
導入フェーズ
- 自動化対象の識別
- 期待値が作れるもの
- 費用対効果を見込めるものを対象とする
- テストデータの作成
- 手動テストとは異なるテストデータを用意する
- テストケースの作成
- スクリプティング
- テスト実行するスクリプトを作る
- ツールについてはよくまとめている方がいたので備忘録がてらいい記事を残しておきます
- 動作確認と調整
- テストの実行単位の選択
- 実行したいテストケースのみを実行できるようにする
運用フェーズ
- スクリプトのメンテナンス
- テストデータのメンテナンス
- テストケースのメンテナンス
- ここで面白かったのが一回も失敗していないテストケースが削除対象になると言及されていたことです。これは下記の理解ですが、間違っていたら指摘ください
- 一度も失敗していない → 失敗することがないので無駄である
自動化をしても最終的にかかるメンテナンスコストや、導入時のイニシャルコストを回収するためには自動化されたテストが複数回行われることで回収されます。
所感
ウォータフォール的な開発については応用情報等の学習した気になっていましたがテストを主軸に開発全体を深掘ってみたいと感じてこの本を読みました。
今回で、大まかになんのテストがどのフェーズにありどういった役割なのかというのが分かってきました。
手動でテストをするのはうげーって感じですが
テストを自動化することも実装の一つだと考えているので、テスト設計から実装というフェーズはやはり楽しいので、自動化する打ち手を持てるとシンプルに開発面でも行きそうだなとリアルと合わせて感じた次第です。
次はTDD、CICD関連の本を読んでみたいなと。