LoginSignup
39
52

More than 5 years have passed since last update.

単体テストおよび結合テストを作成・実施するときに気をつけたいこと

Last updated at Posted at 2016-12-05

WithOne AdventCalendar 5日目の記事です。
今回は、ソフトウェアテストを実施する上で私が最近感じたことを書いていきます。

なお、私自身もまだ不慣れであるため、誤った内容を書いている可能性があります。
見つけた際はご指摘いただけると幸いです。

ソフトウェアテストとは

既にご存知かもしれませんが改めて説明すると、コンピュータのプログラムから仕様には存在しない動作やバグを見つけ出す作業のことを指します。
一言で「ソフトウェアテスト」と言ってしまうと範囲が広すぎるので、今回は単体テストと結合テストに焦点を当ててお話しします。

単体テストと結合テストの違い

一言に「単体テスト」や「結合テスト」と言われても、実際のところどういったテストがどちらに含まれるか、という点はIT業界に入りたての人にはわかりにくいかもしれません(実際、私自身も曖昧でした)。
なので、まずはここから整理していきましょう。

単体テスト

まずは単体テストについてです。
単体テストは「UT(Unit Test)」とも呼ばれ、関数やメソッドなどの小さな単位で行うテストのことを指します。
このため、個々の画面や機能で実施される動作を確認することが主たる目的となります。

とはいえ、実際のプログラムとなると、画面や機能が複数存在する場合のほうが圧倒的に多くあるはずです。
それらの連携に関する部分は単体テストでは実施せず、後述の結合テストで行う内容となります。

テストケースについては、下記の観点で考えていきましょう。

  • 画面上の表示におかしいところがないか
  • リンクやボタンを押した時の動作はどうか
  • データベースとの連携(登録、編集、削除)ができているか
  • 表示されるメッセージが正しいか
  • 想定外の動作をしていないか

単体テストでは基本的に、その画面内でできることはすべて確認する必要があります。

画面上の項目ばかりに気を取られ、データベースとの連携を見落としたり、検索パターンの検討をし忘れたりしないようにしましょう。

結合テスト

次に結合テストについてです。
結合テストは「IT(Integration Test)」とも呼ばれ、単体テストが完了したプログラムを組み合わせて行うテストのことを指します。
なので、単体テストで確認したひとつの画面内で完結する内容については、省略することができます。

テストケースについては、下記の観点で考えていきましょう。

  • 他の機能から必要な情報を取得できているか
  • 他の機能で変更を加えたデータが反映されているか

結合テストでは、単体テストでは実施しなかった画面間および機能間の連携に問題がないかを中心に確認していきましょう。
個々の機能に問題がなくても、他の機能との連携で問題が発生する可能性もないとは言い切れません。

テストケースを作る上で気をつけたいこと

テストケースを作る上で気をつけたいことは、なにも「実施するケースに間違いや漏れがないか」だけではありません。
ケースの意図を正確に伝えることもテストを実施する上で重要なので、以下の項目についても気をつけていきましょう。

表記のブレをなくす

ある同じ内容を異なる人に「説明せよ」と言っても、人によって説明の仕方はさまざまです。
文章も同じで、記載方法が変わると受け手の印象は変わるものです。
操作手順や期待結果など、似たような文言が多くなる部分については、作成する前に方向性を決めておくといいでしょう。

「誰が」「どこで」「何を」「どうする」「どうなる」をしっかりと表す

操作手順に「~される」と書かれていたり、期待結果に「~すること」なんて書かれていると、何となく違和感を覚えませんか?
また、操作する場所が明記されていないと、どの画面のどの部分なのかがわかりにくくなります。
なので、ケースを作成するときは「テストを実施する人は、その機能について全く知らない人なのかもしれない」と思いながら作ってみましょう。

テストを実施する上で気をつけたいこと

テストケースができたら、あとはそれに沿って実施するだけ・・・!、ではありません。
何かしらのバグが見つかった場合は、それについてしっかりと報告する必要があります。
これについても、以下の項目には気をつけていきましょう。

バグの内容を「わかりやすく」報告する

ただ一言「表示されるメッセージが違う」なんて報告されたら、直す側も一から調べる必要があるので面倒です。
これもテストケースを作る時と同じく「どこで」「何を」「どうした」ときに出たものかを書いてみましょう。

見つけたバグには責任を持つ

何らかのバグを見つけた時、見つけたら終わりではありません。
しっかりと報告することはもちろん、直っているかを確認する必要があります。
発生したバグを管理している場合は、管理簿への起票はもちろん、修正結果の確認とその結果を管理簿に反映するところまでは責任をもって対応しましょう。

終わりに

以上、ソフトウェアテストの中から単体テストと結合テストについて書いてきました。
作成したプログラムの品質に直結する重要な部分であるだけに、規模が大きくなればなるほど確認すべき項目もどんどん増えてしまいます。
しかし、大変かもしれませんが面倒だとは思わず取り組んでみましょう。

39
52
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
39
52