単体・結合テスト観点表
概要
現場にテスト観点表がなかったため、私がテスト観点表を作成しました。
以下の内容は、私が作成したテスト観点表です。
また、現場がLaravelのため、ところどころLaravel特有の観点などが出てきます。
背景
現場にテスト観点表がなかったため、私が作ることになりました。
テスト観点表作成のために、以下の書籍を読んだのですが、そのときのメモについても投稿していますので、少しでもこの記事を読んでいる方のためになれば幸いです。
「テスト駆動開発」の読書メモ:https://zenn.dev/hana_boy/articles/585fb00267e8c2
「単体テストの考え方/使い方」の読書メモ:https://zenn.dev/hana_boy/articles/bf013d92b9956c
感想
テスト観点表を作った自分のテスト観点は、レベルアップしたと思います。
ただ、正直テストに興味がないメンバーからすると、すべて読むのはかなり大変だと思うので、分類などを変更し、わかりやすくできればベストなのかなと思っています。
また、単体テストのモックの使用については賛否両論ありますが、私の現場では基本的に外部API以外はモックを使わないようなルールとなっています。
テスト観点表
単体テスト実装時の観点
なぜテスト観点だけでなく、実装時の観点も書いているか
単体テストのテストコードを実装する際、基本的にテスト対象のコードに沿って実装します。
テストコードを実装するファイルは、ビジネスロジック等を記載している箇所に依存するため、可能な限りテストコードを実装しやすいアーキテクチャで、プロダクション・コードを実装した方がよいです。
上記のような観点を持ってテストを作成する場合、アーキテクチャの修正をした方が良いと判断される可能性があります。
そのため、アーキテクチャに影響する可能性がある実装時の観点と、アーキテクチャに影響しないテスト観点を分けて記載しております。
観点
思想としては、「単体テストの考え方/使い方」に書いてある内容を基に書いています。
観点 | Goodパターン | Badパターン | 理由 |
---|---|---|---|
ControllerやConsoleのテストファイルにて、ビジネスロジックの観点の単体テストを書いていないかどうか。 | HelperやTraitにビジネスロジックを記載し、単体テストではそのインスタンスorメソッドのレスポンスについてテストする。 | 複雑なビジネスロジックも、ControllerやConsoleのテストファイルに記載する。 | Controllerでビジネスロジックをテストする場合、同じロジックを他のControllerで使うときに、同じ観点のテストを2つ以上作る必要があるため。 |
1つのテストメソッドの中で、複数の観点のテストを記載していないかどうか。 | 観点ごとに、テストを分割して実装する。 データプロバイダの利用を検討する。 |
Assertした後に、テストデータを作成して、再びAssertする。 | 単体テストが失敗した際、どの観点にてテストが失敗したかが、分かりにくくなるため。 ロジックを修正した際、どのテストコードを修正すればいいか分からなくなるため。 |
Mockを使わずに単体テストを実装できる場合でも、Mockを利用していないかどうか。 | なるべくMockは利用しない。 外部メソッドを呼び出す場合のみMockを利用するようにする。 |
AssertDatabaseHas()メソッド等でテストできるにも関わらず、Mockを利用する。 | Responseに影響のないリファクタリングを行った際、正しい挙動にもかかわらずテストが失敗する可能性があるため。 |
プライベート関数をテストしていないかどうか。 | プライベート関数をテストしたい場合、プライベート関数を利用するpublicの関数をテストする。 | プライベート関数をテストするために、アクセス修飾子を変更してテストする。 | リファクタリングを行った際、正しい挙動にもかかわらずテストが失敗する可能性があるため。 |
テストコードのロジックに、プロダクション・コードのロジックを使用していないかどうか。 | テストコードで、同じロジックを使う必要がある場合は、期待する返り値を定義して、ロジックを使わないようにする。 | テストコード内で、プロダクションコードのロジックを使って値を作成する。 | テストコード内で同じロジックを使ってテストした場合、通るのが当たり前のテストになってしまうため。 |
プロダクション・コードの中に、テストでのみ使用するメソッドが含まれていないかどうか。 | インターフェースを使い、プロダクション用とテスト用でクラスを分ける。 | プロダクション・コードの中に、テストでしか使わないメソッドを記載する。 | 障害が起こった際などでコードを見たときに、そのロジックがプロダクション・コードに影響しているかどうかわからないため。 |
「メソッドが呼び出されているかどうか」自体を観点にテストしていないかどうか。 | Responseの値や、DBやファイルの値をテストする。 「メソッドが呼び出された結果どうなったか」という観点でテストを作る。 |
テストコード内で操作を行い、「メソッドが呼び出された」ことをテストする。 | リファクタリングを行った際、正しい挙動にもかかわらずテストが失敗する可能性があるため。 |
テストコードが、AAAパターンとなっているかどうか。 参考:https://tech.pepabo.com/2021/08/23/writing-unit-test-with-aaa/ |
AAAパターンとなっていない場合、「データ作成→動作実行→結果や影響チェック」となるような順番で実装する。 | Assertした後にデータ作成(Arrange)する。 | 上から下に向かってテストするため、可読性が落ちるため。 |
テスト作成時の観点
ブラックボックステストなどの観点については、「知識ゼロから学ぶソフトウェアテスト 【改訂版】」を参考にしました。
細かい観点については、以下のQiitaの記事を参考にさせていただきました。
入力観点
大観点 | 中観点 | 小観点 | 観点の説明 | 備考 |
---|---|---|---|---|
入力チェック | 共通 | 未入力 | 何も入力されていない場合、期待通りの動作となるかどうか。 | |
エラーチェック | バリデーションエラーなど期待されるエラー以外のエラーが返ってこないかどうか。 | |||
最小桁数 | 最小桁数より小さい場合、期待通りの動作となるかどうか。 | |||
最大桁数 | 最大桁数より大きい場合、期待通りの動作となるかどうか。 | |||
半角英字 | 半角英字が入力された場合、期待通りの動作となるかどうか。 | |||
半角数字 | 半角数字が入力された場合、期待通りの動作となるかどうか。 | |||
半角カナ | 半角カナが入力された場合、期待通りの動作となるかどうか。 | |||
全角英字 | 全角英字が入力された場合、期待通りの動作となるかどうか。 | |||
全角数字 | 全角数字が入力された場合、期待通りの動作となるかどうか。 | |||
全角かな | 全角かなが入力された場合、期待通りの動作となるかどうか。 | |||
全角カナ | 全角カナが入力された場合、期待通りの動作となるかどうか。 | |||
混合(フリーテキスト) | フリーテキストの場合は全ての文字種が入力された場合、期待通りの動作となるかどうか。 | |||
混合(特定文字種) | 特定文字種のみの場合は、他の文字種が入力された場合、期待通りの動作となるかどうか。 | |||
禁則文字 | 禁則文字が入力された場合、期待通りの動作となるかどうか。 | |||
形式(メールアドレス・URL・日付など) | 指定の形式に沿った形で入力した場合、期待通りの動作となるかどうか。 | |||
指定値以外 | 指定値以外を入力した場合、期待通りの動作かどうか。 | |||
存在 | セレクトボックス等で選択した場合、期待通りの値が入力されているかどうか。 | |||
数値系 | 0を入力する | 0を入力した場合、期待通りの動作かどうか。 | ||
最小値未満 | 最小値未満の値を入力した場合、期待通りの動作かどうか。 | |||
最大値超過 | 最大値超過した値を入力した場合、期待通りの動作かどうか。 | |||
指定値以外 | 指定値以外を入力した場合、期待通りの動作かどうか。 | |||
小数 | 小数を入力した場合、期待通りの動作かどうか。 | |||
マイナス | マイナスの値を入力した場合、期待通りの動作かどうか。 | |||
日時系 | 過去日 | 過去日を入力した場合、期待通りの動作となるかどうか。 | ||
未来日 | 未来日を入力した場合、期待通りの動作となるかどうか。 | |||
日付大小 | 開始日や終了日があった際、開始日が終了日より後だった場合に期待通りの動作となるかどうか。 | |||
うるう年 | 日付のみの入力の場合、2/29の存在を考慮できているか。 | |||
その他 | 相関チェック | FromToそれぞれ指定する場合など、フォーム間で何らかの相関性がある場合。 | ||
ファイル | ファイル名 | ファイル名が、指定された名前の場合、期待通りの動作かどうか。 | ||
拡張子 | 拡張子が、指定された拡張子の場合、期待通りの動作かどうか。 | |||
サイズ | ファイルサイズが、指定されたサイズの場合、期待通りの動作かどうか。 | |||
空ファイル | ファイルの中身が空の場合、期待通りの動作かどうか。 | |||
文字コード・改行コード | 文字コード・改行コードが入力されている場合、期待通りの動作かどうか。 | |||
ファイル(CSVインポート) | 項目数 | CSVの項目数が、指定された数の場合、期待通りの動作かどうか。 | ||
ヘッダ有無 | CSVのヘッダが存在する場合、期待通りの動作かどうか。 | |||
データ件数 | CSVの件数が指定の件数の場合、期待通りの動作かどうか。 | |||
最大データ件数 | CSVの件数が最大データ件数を超過した場合、期待通りの動作かどうか。 | |||
変換観点 | 空白除去 | 空白が入力されていた場合、除去されるなど期待通りの動作かどうか。 | ||
形式 | 日付や郵便番号の形式変換や、0埋め、「¥」の付与などが、期待通りにされるかどうか。 | |||
全角←→半角 | 全角or半角で入力された場合、それぞれ変換されるかどうか。 | |||
大文字←→小文字 | 大文字or小文字で入力された場合、それぞれ変換されるかどうか。 |
画面観点
大観点 | 中観点 | 小観点 | 観点の説明 | 備考 |
---|---|---|---|---|
表示内容 | 共通 | ページング | ページネーションが、期待通りの動作・レイアウトかどうか。 | |
表示限界個数 | 一覧などで、表示の限界までコンテンツを表示させた際、レイアウトが崩れないかどうか。 | |||
文言 | 表示文言 | 設計書など、正となる文言との比較を行い、条件ごとに期待通りの文言が表示されるかどうか。 | ||
最大長・最小長 | 最大長または最小長の文字の内容を表示し、レイアウトが崩れないことを確認する。 | |||
連続した半角英字 | 連続した半角英字を表示し、レイアウトが崩れないことを確認する。 | |||
表示形式 | 日付や数値のカンマ、0埋めなど、期待通りの表示形式かどうか。 | |||
NULL・空文字・空白 | NULLや空文字を表示した際、期待通りの表示となるか。 | |||
特殊文字・絵文字 | 特殊文字や絵文字を出力した際、文字化けなど起こらないか。 | |||
HTML関連 | <>などHTMLに使用される文字が、期待通りに反映or表示されるかどうか。 | |||
ソート | 一覧表示の場合、ソート順が正しいかどうか。 | |||
特定文言 | 禁止されている特定の文言が、表示されないかどうか。 | |||
フォント | フォントが、設計書通りのフォントとなっているかどうか。 | |||
画像 | SRC属性 | 画像のSRC属性が、期待通りかどうか。 | ||
ALT属性 | 画像のALT属性が、期待通りかどうか。 | |||
画面制御 | 表示 | 初期表示 | 入力フォームの初期値などが、期待通りの表示かどうか。 | |
条件表示 | データやフォームの状態での表示/非表示制御をしている場合、条件ごとに期待通りかどうか。 | |||
エラーメッセージ | エラー表示位置やレイアウトが崩れていないかどうか。 | |||
タブ遷移 | タブ押下時の、フォーカスの移動順が、期待通りかどうか。 | 意識しないまま実装すると、時に変なタブ遷移をしてしまい、ユーザビリティが悪くなる可能性がある。 | ||
リストボックス | リストボックスの選択項目が、期待通りかどうか。 | |||
広告 | 広告が表示されるか、レイアウトが崩れていないかどうか。 | 広告が表示されるタイミングや条件についても確認する。 | ||
地図 | 地図が表示されるか、座標通りに位置が指定されるかどうか。 | |||
TDK | TDKが期待通りかどうか。 | 参考:TDKについて | ||
計測系 | GA | GAのイベントを実施した際、期待通りに動作するかどうか。 | 参考:GAについて | |
遷移 | 画面遷移 | 自画面/他画面遷移が、期待通りとなるかどうか。 | ボタンにリンクがないなどを検知する。 | |
ブラウザバック | ブラウザバック時に、期待通りの挙動となるかどうか。 | |||
不正パラメータ | GETパラメータが不正であった場合、期待通りの動作となるかどうか。 | |||
URL直接入力 | 正規の画面遷移をせずに、URLを直接入力し遷移した際、期待通りとなるかどうか。 | |||
多重送信 | サブミットを連打した場合、期待通りとなるかどうか。 | 「JSでダブルクリックさせないよう、ボタンを非活性にする 」や、「多重送信されても問題ないよう、システムで制御する」などができているか。 | ||
リダイレクト | リダイレクト設定がある場合、遷移先が正しいか。 パラメータ引き継ぎがある場合は引き継がれているかどうか。 |
未ログイン・ログイン済みなどで、ログイン画面からのリダイレクト先を検証する。 | ||
ブラウザ | ブラウザバリエーション | Win・Mac・Android・iOSそれぞれ、システムで指定された推奨ブラウザで期待通りに動作するかどうか。 | ブラウザによって表示が乱れる、JavaScriptが動作しないなどが起こりうる。 メーラ起動もエンコードの違いなどにより文字化けが発生する事があるため注意する。 |
機能観点(データなど)
大観点 | 中観点 | 小観点 | 観点の説明 | 備考 |
---|---|---|---|---|
データ取得 | 共通 | 検索条件 | 仕様通りの条件で、データが取得できているかどうか。 | 条件が複雑な場合、マトリクス表を作る。 |
範囲指定 | ページネーションなど、取得件数を制限する場合、期待通りとなるかどうか。 | |||
取得項目 | 仕様通りの項目が、取得できているかどうか。 | |||
ソート | 仕様通りのソート条件で、データが取得できるかどうか。 | |||
ページネーション | 仕様通りに、指定の件数でページネーションしたデータが取得できるかどうか。 | |||
データ登録・更新 | 正常系 | データ追加 | 仕様通りに、データ追加ができるかどうか。 | |
データ更新 | 仕様通りに、データ更新ができるかどうか。 | |||
異常系 | データサイズ不正 | データ型毎の制限を超えた値を、登録できないかどうか。 | ||
データ非存在 | 更新対象のデータが存在しないときに、期待通りの動作となるかどうか。 | |||
型不正 | データ型が異なるデータを投入しようとしたときに、期待通りの動作となるかどうか。 | |||
主キー、ユニークキー違反 | キー重複となるデータを投入しようとしたときに、期待通りの動作となるかどうか。 | |||
NotNull制約違反 | NotNull制約があるカラムに、NULLを追加したときに、期待通りの動作となるかどうか。 | |||
データ削除 | 正常系 | データ削除 | 対象のデータのみが、正しく削除されるかどうか。 | |
論理・物理削除 | 論理・物理削除が、仕様通りにされているかどうか。 | |||
異常系 | データ非存在 | データが存在しない場合、何も削除されないかどうか。 | ||
共通 | トランザクション | ロック | 更新対象のレコード、テーブルに対し適切にロックがかかり、ロックがかかった対象への参照、更新が想定通り待機状態となるかどうか。 | 処理内で複数のテーブルに対しロックをかける場合、他の処理と同時実行することで、デッドロックが発生しないことも確認する。 |
ロールバック | トランザクション内でのデータ登録、更新削除について、(エラー発生などで)ロールバックした場合、全てがキャンセルされるかどうか。 | 例外処理が起こった場合、ロールバックされることを確認する。 | ||
コミット | トランザクション内でのデータ登録、更新削除について、コミットした場合にそれらが全て確定されるかどうか。 | |||
マスター・スレイブ | 参照先 | 最新のデータを取得する必要がある際に、マスターDBへデータ参照をしているかどうか。 | 登録、更新処理のコミット直後に、再度データ取得をする処理を行う場合、マスター参照をしていないと古い情報を取得している場合がある。 | |
異常系 | ログ出力 | 処理が異常終了した場合、ログが出力されるかどうか。 | ||
ビジネスロジック | 共通 | 仕様比較 | 入力、出力が仕様通りかどうか。 | 他機能からのデータ入力、他機能へのデータ出力がある場合、それらが相互に正しく機能していることを確認する。 |
条件分岐 | 条件分岐を伴う場合、各条件の真偽の組み合わせを網羅し、期待通りとなるかどうか。 | 複雑な機能要件となっている場合、マトリクスでテストケースを表現すると網羅性が高まる。 | ||
複数データ(ループ) | 複数のデータをループして処理するような機能である場合、全ての処理が正常に機能するかどうか。 | 1件1件での機能テストでは通っても、複数件同時に処理した時にループ処理の仕方によっては想定通り動かない場合もある。 | ||
複数データ(統計、グループ化) | 複数のデータに対し統計を取ったり、グループ化する場合に、取得するデータが正しいかどうか。 | |||
年月日跨ぎ | 操作・処理が年、月、日を跨いだ場合に正しく機能するかどうか。 | |||
競合 | 同一機能同時操作 | 複数人操作 | 同一の機能を複数人が、同時に操作した場合に、正しく機能するか。 | |
同一セッション操作 | 同一の機能を同一ブラウザ(セッション)内で、並行して操作した場合、正しく機能するかどうか。 | 複数タブ立ち上げなどで確認する。 | ||
(バッチ)多重起動 | バッチが多重起動した場合に、後続の処理への対処が、期待通りにできるかどうか。 | |||
他機能同時操作 | 同一データを複数機能から同時操作 | 複数の機能が同じデータを同時に参照・更新する場合に、正しく機能するか。 | ||
メール | メール送信 | 送信条件 | 指定の条件のユーザーにのみ、メールが送付されるかどうか。 | |
送信内容 | 送信内容が、条件ごとに期待通りになっているかどうか。 | 文言、画像がある場合は画像を確認する。 | ||
送信元 | 送信元が、指定のメールアドレスかどうか確認する。 | |||
PUSH通知 | PUSH送信 | 送信条件 | 指定の条件のユーザーにのみ、PUSHが送付されるかどうか。 | |
送信内容 | 送信内容が、条件ごとに期待通りになっているかどうか。 | 文言、アイコンがある場合は画像を確認する。 | ||
OSごと | OSごとに、送信内容が違っていないかどうか。 | |||
ネットワーク | 異常系 | 悪いネットワーク環境 | ネットワーク環境が悪く、通信できないとき、期待通りとなるかどうか。 |
参考文献・サイト
参考サイトURL
テスト観点一覧(2024/08/16閲覧)
URL:https://qiita.com/nittannittan/items/2d8a342a8d77db53b70a
テスト観点とは?(2024/08/16閲覧)
URL:https://service.shiftinc.jp/column/5029/
単体テストの観点とは?(2024/08/16閲覧)
URL:https://biz.techvan.co.jp/tech-quality/quality-blog/000242.html
テスト観点一覧(2024/08/16閲覧)
AAAパターンを意識して単体テストを書く(2024/08/16閲覧)
URL:https://tech.pepabo.com/2021/08/23/writing-unit-test-with-aaa/
参考文献
「単体テストの考え方/使い方」
著者:Vladimir Khorikov
訳:須田 智之
出版年:2022年
出版社:マイナビ出版
リンク:https://www.amazon.co.jp/単体テストの考え方-使い方-Vladimir-Khorikov/dp/4839981728
「ソフトウェアテスト入門 押さえておきたい<<要点・重点>>」
著者:ソフトウェア・テストPRESS編集部 (編集)
出版年:2008年
出版社:技術評論社
リンク:https://www.amazon.co.jp/ソフトウェアテスト入門-押さえておきたい-要点・重点-ソフトウェア・テストPRESS編集部/dp/4774134546
「知識ゼロから学ぶソフトウェアテスト 【改訂版】」
著者:高橋 寿一
出版年:2013年出版
出版社:翔泳社
リンク:https://www.amazon.co.jp/知識ゼロから学ぶソフトウェアテスト-【改訂版】-高橋-寿一/dp/4798130605
Discussion