質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Q&A

1回答

2323閲覧

結合テストの定義と方法について

key_FoolyCooly

総合スコア19

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

0グッド

1クリップ

投稿2019/09/02 17:32

編集2019/09/02 23:43

前提・実現したいこと

結合テストについての一般常識を知りたいです。
なお、テスト対象は仮にJavaとSTSで作れるECサイト、MVCモデルとします。

まだ勉強中なため内容がふわっとしてるかもしれません。

結合テストのイメージ

私は結合テストがいまいちイメージできず勉強しています。
私が調べたところ、結合テストとは以下のようなものだとイメージしました。
以下のイメージが合っているか教えてください。

  • 複数モジュールの連携、また、モジュール間のインターフェイスのテスト。

→登録機能ないし画面で登録したデータを、検索機能ないし画面にて表示してみる……など。

  • ホワイトボックス・テストを行わないテスト。

→サービスなどはデータが入出力されるかのみ見る。中身のロジックが正確かは考慮しない(単体テストの担保)。

  • 複数の単体テストを結合したもの。また、単体テストにおけるモック、スタブ、ドライバを実装したもの。また、複数のテストケースを結合したもの。

→この場合、単体の更新機能でも結合テストになりうる。
つまり、モジュールは「リクエストを送信するビュー」、「リクエストを受信するコントローラ」、「リクエストを処理するサービス」、「リクエストを処理するDB」に分かれる。
インターフェイスは上記「ビュー」と「DB」の間の処理といえる。

  • IT環境で行うもの。換言すれば、複数モジュールの連携したテストでもローカル環境なら結合テストといわない。

→これはイメージしがたい。
「登録機能ないし画面で登録したデータを、検索機能ないし画面にて表示してみる。」ことも結合テストと言えなくなる?

  • リクエスト~レスポンスを確認するテスト

→データ登録ボタンを押して、登録しましたというメッセージが出るまで……など

  • ローカルとリモートの隔たりがあるテスト

→ローカルから送信したデータがリモートのサーバにより更新されているかDBMSにより確認する。
あるいは、同じ画面にて、リクエストによるレスポンスが正しいか確認する。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

直接の回答じゃないですが、各テスト工程で「何をすべきか」というのはプロジェクトや人によって結構解釈がブレてる事が多いので、教科書的な答え(それも大事ではありますが)を期待するよりは個別にプロマネに確認した方が良かったりします。

というのも、プロジェクトの工程の区切り方って別に正解があるわけではなく、テスト計画全体を通してどの工程でどういうテストをしてどのように品質を担保するのか、というのはマネジメントの考え方次第だったりするからです。

なので、プロマネ側であれば各工程でどういうテストを行うべきか、は自分が線引してちゃんとメンバーに伝える必要がありますし、メンバー側であればその考え方をちゃんと理解している必要があります。

教科書的な線引きをして「これが結合テストだ」という事に凝り固まってしまうと、そのコミュニケーションを疎かにしてしまい、結果として抜けや漏れが生じる危険があります。

テストは、その定義や方法自体が目的ではなく、最終的にプロダクトの品質を保証する事を目的にしているはずです。この「品質」には一応規格があって、割とちゃんと分類できます。
https://ja.wikipedia.org/wiki/ISO/IEC_9126

で、例えば

同じ画面にて、リクエストによるレスポンスが正しいか確認する。

という内容について、これを「結合テストである」と定義したとします。

しかし、この「正しい」とは何でしょうか?

機能性の話であれば、リクエストをして30秒後に期待した値が取れれば「正しい」となります。
でも、本来は「3秒未満」で終わる事が期待されている(非機能要件)処理であれば「正しくない」となります。
このように、前提をきちんと決めずに「〇〇だからこのテスト」みたいな決め打ちは結構無理があるわけです。

非機能要件はシステムテストで確認することも多いですが、後の工程で発見される不具合ほど手戻りの工数が多くなるため、早期のテストでちゃんと確認するのが理想ではあります。でも、そもそも開発期間に余裕があったり、規模の小さいプロジェクトであれば、そこはあんまり問題にならなかったりもします。

要するにケースバイケースで判断する必要がどうしても残るので、あんまり頭でっかちになるのはよろしくないのかな、という意見です。

あなたがどう考えるか、は重要です。
テスト工程のなかで、挙げられた項目はどこでテストするべきか、はよく悩んで決めてください。
でも、それは万人にとっての絶対ではない、という事も肝に銘じておきましょう。

投稿2019/09/02 19:09

編集2019/09/02 19:20
gentaro

総合スコア8949

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

m.ts10806

2019/09/03 02:07

単体テストも「JUnit通して終わり」のところもあるし、 試験表作って画面動かして確認するところもあるし 色々ありますね。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問