Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

知識ゼロから学ぶ ソフトウェアテスト(2章 ソフトウェアテストの基本 -ホワイトボックステスト-)

More than 1 year has passed since last update.

知識整理のために投稿しています。
本は 知識ゼロから学ぶ ソフトウェアテスト[改訂版]です。
テストってなかなか書けない。

ホワイトボックステストの特徴

  • プログラムの論理構造が正しいかテストする
  • ソフトウェアの仕様が間違っていることによるバグは発見できない

ホワイトボックステストの手法

制御パステスト法

  • プログラムの振る舞い、制御、実行の流れをテストする
  • カバレッジ率を取るために使われる

    • ステートメントカバレッジ
  • コード内の命令文(ステートメント)を必ず1回は実行する

  • 分岐はテストしない

  • 非常に弱いテスト手法

    • ブランチカバレッジ
  • 分岐に対するTRUE / FALSEの結果を必ず1回ずつ持つようにする

  • テストコードがかなり増える

  • バグが起きやすい部分にだけ絞って行うことが多い

カバレッジ基準

  • 一般の商用ソフトウェアなら60~90%
    • ソフトウェアの種類によって変わる(命に関わるものは当然高くなる)
  • 製品によって妥当な目標を適切に設定すべき

カバレッジテストの限界

  • エラー処理 / 使われていないコードはカバーできない
  • 以下のバグは検出が困難
    • プログラムのループに関するバグ
    • 仕様自体が違っていたり機能が備わっていないバグ
    • データに関するバグ
    • タイミングに関するバグ
    • マルチタスク/ 割り込みなど

TDDによるホワイトボックステストの復権

  • 赤・緑・リファクター
  • 単体テストができるようにフレームワークを選定する必要がある
  • 「単体テストをやっている暇はない」という言い訳を無くせる
  • 確実な品質保証 <<< スピードを持った開発 & 変更に対する耐性
    • TDDではホワイトボックステストの一部しか実現できない
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away