テストの自動化は、無敵の用心棒のように思える

Posted: 2012年11月03日

テストの自動化は、様々な方法が存在します。

  • ユニットテストの導入
  • マウスとキーボード入力の自動化

ユニットテスト

ユニットテストは、テストプログラムを作成し対象のプログラムをテストを行います。
主にTDD(テスト駆動開発)で使います。
プログラム設計ができた場合その対象の関数が
どのような動作を行うかすでにわかっているはずです。
つまり、ユニットテストでそれを記述するプログラムを作成する。

その後実際のプログラムを作成し
設計通りであるか確認をする手法です。

TDD以外でユニットテストを活用

目標は、TDDを行いたいですが
最近は、そこまでしっかりとした設計を行うことがないため(大規模開発の場合はありえない)
なかなか導入はできない。
そのため開発は以下の順で行なっています。

  1. 実装
  2. ユニットテストの作成
  3. リファクタリング
  4. 結合テスト

この順番で行うことで
リファクタリング、結合テストの障害対応時に誤った修正を加えていないか
が確認できるため安心して納品が可能です。

※ユニットテストは、関数の結果がわからない場合は、
何が正解かが不明なため実装時にそこは考慮する必要があります。

ユニットテストでは開発できない問題また、ユニットテストを行ったから問題ないかと言ったらそうではなく

以下の点は、テストができないため
そこは、別の方法てテストが必要になります。

  • 画面の描画
  • 画面操作
  • 性能チェック
  • 排他制御(デッドロック)

マウスとキーボード入力の自動化

ユニットテストの問題を一部解決できます。

  • 画面操作※
  • 性能チェック
  • 排他制御(デッドロック)

※一部の操作のみ

ユニットテストと一緒に導入することで
様々なテストを網羅することが可能です。
これは、マウス操作などを自動で行うことで

  • タイミングによるデッドロックの確認
  • 画面操作によるメモリーリークなどの性能チェック

これらの確認が可能になります。
こちらは、TDDには含まれていないと思いますが
画面は、設計時に決定しても仕様変更などがあり
変わる場合があるため、TDDで導入してもメンテナンスが大変だと思います。
(マウスの座標を記憶させるため)

まとめ

今回上げた、ユニットテストやマウスとキーボード入力の自動化を
行なっていたとしてもバグは発生します。
しかし、大幅に削減できるし
テストが自動化されることでSEの安心感は得られます。
テスト作成に時間がかかるという欠点はありますが
見積もりでその分上乗せすることで解決できると思っています。
相手もテスト自動化は安心できる材料であると思っています。

自動テストは、無敵ではないにしろ
心強い用心棒であることは間違いないと思います。

カテゴリー: バグ, ユニットテスト | タグ: , , , | コメント無し »

コメント