Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

システムテスト自動化標準ガイド第7章

1,790 views

Published on

  • Be the first to comment

システムテスト自動化標準ガイド第7章

  1. 1. システムテスト自動化 標準ガイド 第7章 保守性の高いテストを構築する @nihonbuson
  2. 2. メンテナンスに関する問題 テストのメンテナンスは軽視される • ソフトウェアのメンテナンスは重要視するのに… • 自動テストはメンテナンスコストが特に重要
  3. 3. テストケースの数 • 新規機能、不具合修正の度に追加すべき
  4. 4. テストケースの数 • 新規機能、不具合修正の度に追加すべき • メンテナンスコストがどんどん増えていく • 過剰・重複するテストケースが存在する可能性あり • 「沢山テストケースがあるから良いよね?」 • 追加するテストケースが何の役に立つのか?
  5. 5. テストケースの数 • 新規機能、不具合修正の度に追加すべき • メンテナンスコストがどんどん増えていく • 過剰・重複するテストケースが存在する可能性あり • 「沢山テストケースがあるから良いよね?」 • 追加するテストケースが何の役に立つのか? • 定期的に草刈りすべき(?)
  6. 6. テストデータの量 • 沢山のテストデータを用いて、徹底的なテストをしよう 
 
 

  7. 7. テストデータの量 • 沢山のテストデータを用いて、徹底的なテストをしよう • メンテナンスコストがかかる • テスト失敗の分析とデバッグ作業の工数が増加
  8. 8. テストデータの量 • 沢山のテストデータを用いて、徹底的なテストをしよう • メンテナンスコストがかかる • テスト失敗の分析とデバッグ作業の工数が増加 • テストケース1つ当たりのディスク容量の使用制限を設ける(?) • テスト計画に多くの時間を割く • 構成管理システムにテストケースを登録すること
 巨大なテストデータの検知&受け入れなくなる
  9. 9. テストデータの形式 • ソフトに使用できるならどんな形式でもOK • 変換の手間も省けるし
  10. 10. テストデータの形式 • ソフトに使用できるならどんな形式でもOK • 変換の手間も省けるし • 形式変更時、テストデータの更新or再作成が必要 • ソフトウェア独自拡張子のテストレポートの変換が…
  11. 11. テストデータの形式 • ソフトに使用できるならどんな形式でもOK • 変換の手間も省けるし • 形式変更時、テストデータの更新or再作成が必要 • ソフトウェア独自拡張子のテストレポートの変換が… • テキスト形式にすべき • バイナリ形式なら、変換プログラムを作成せよ
  12. 12. テストケースの実行時間 • セットアップと後片付けの回数を減らすためにも、 好きなだけ長く
 コンピュータは注意力散漫にもならないし
  13. 13. テストケースの実行時間 • セットアップと後片付けの回数を減らすためにも、 好きなだけ長く
 コンピュータは注意力散漫にもならないし • 長いテストケースの最初の失敗は後の失敗を隠す 成 功 失 敗 失 敗 ? 失 敗 ?
  14. 14. テストケースの実行時間 • セットアップと後片付けの回数を減らすためにも、
 好きなだけ長く
 コンピュータは注意力散漫にもならないし • 長いテストケースの最初の失敗は後の失敗を隠す • 短いテストケースを何度も回し、分析やデバッグを行う
  15. 15. テストケースのデバッグ能力 • テストツールの仕事は成功、失敗判定のみでしょ?
  16. 16. テストケースのデバッグ能力 • テストツールの仕事は成功、失敗判定のみでしょ? • 失敗の原因を調査する必要がある 

  17. 17. テストケースのデバッグ能力 • テストツールの仕事は成功、失敗判定のみでしょ? • 失敗の原因を調査する必要がある • 「失敗した場合、どのようなことを知りたいのか」
 を念頭に置いて設計すべき
  18. 18. テストの相互依存性 • 前のテストケースの結果を次のインプットにすれば 多くの包括的なテストを行える 
 

  19. 19. テストの相互依存性 • 前のテストケースの結果を次のインプットにすれば
 多くの包括的なテストを行える • 前のテストケースが正しい結果を生み出せないと、
 次のテストケースは正しく開始することすらできない
 (ドミノ効果)
  20. 20. テストの相互依存性 • 前のテストケースの結果を次のインプットにすれば
 多くの包括的なテストを行える • 前のテストケースが正しい結果を生み出せないと、
 次のテストケースは正しく開始することすらできない
 (ドミノ効果) • 最初は少数の短いテストケースの繋がりから試すべき
  21. 21. テストの相互依存性(補足) 相互依存がないテストケースの集まりは並列化しやすい A B C D 0 7 14 21 28 A B C D 0 7 14 21 28 15 10 8 7 5 6 4 3 15 10 8 7 6 5 4 3
  22. 22. 命名規則 • 好きなように付けろ。そんなところに時間を使うな
  23. 23. 命名規則 • 好きなように付けろ。そんなところに時間を使うな • ファイルの検索性や再利用性にも関わる、重複する
  24. 24. 命名規則 • 好きなように付けろ。そんなところに時間を使うな • ファイルの検索性や再利用性にも関わる、重複する • 開始時点で命名規則を採用しよう
  25. 25. テストの複雑性 • ツールで、複雑なものもテスト可能に!
  26. 26. テストの複雑性 • ツールで、複雑なものもテスト可能に! • 人間が理解できなくなる
  27. 27. テストの複雑性 • ツールで、複雑なものもテスト可能に! • 人間が理解できなくなる • テストケースが理解しづらいので最小限にすべき • 複雑で数回しか実行しないなら自動化する価値なし
  28. 28. テストドキュメンテーション • 必要ない。テストケースを読むのはツールだから 
 

  29. 29. テストドキュメンテーション • 必要ない。テストケースを読むのはツールだから • 「ソフトウェアを実行するのはコンピュータだから、 ソフトウェアにドキュメンテーションは必要ない」
 と言えるのか?
  30. 30. テストドキュメンテーション • 必要ない。テストケースを読むのはツールだから • 「ソフトウェアを実行するのはコンピュータだから、 ソフトウェアにドキュメンテーションは必要ない」
 と言えるのか? • ドキュメンテーションは書くべき • この際、重要なのは量より質
  31. 31. 落とし穴 • ツールが間違っていることを誘導している 導入コスト小 メンテナンスコスト大 • 容易なアプローチが高いメンテナンスコストへ…
  32. 32. 最初の熱意 • 「できるだけ多くのソフトウェア
 にとりあえず投げ込んでみる」
 が大きなダメージを
 発生させる
  33. 33. 投資利益率 • 最初の80%の工数が20%の利益を生み、
 最後の20%の工数が80%の利益を生む 工数 利益
  34. 34. 戦略 • テストのメンテナンスに一番大きな影響を与えうる 要素をまずは見極め、それを減少させる行動をとる • 行動とその結果を評価し、将来に向けた判断を行う
 (評価については第8章にて)
  35. 35. 戦術 1. 推奨値と基準値を定めよ(容量、テスト時間) 2. ツールによるサポートを提供せよ(not運用ルール) 3. 更新を自動化する(統一した更新に) 4. 草刈りの予定を立てる 5. 手作業にせず、メンテナンスユーティリティを用意する
  36. 36. まとめ① 以下の部分に注意してメンテナンスを考える • 数は確認せずに増やさない • 容量もコントロールすべき • 柔軟性のある形式にすべき • 実行時間は最小化されるべき
  37. 37. まとめ② • デバッグが簡単なように設計されるべき • テストケースは可能な限り独立してるべき • 命名規則は早い段階で採用すべき • テストケースは可能な限り単純であるべき • 正確かつ簡潔にドキュメント化されるべき
  38. 38. 感想 • メンテナンスを考えて自動化しよう • テスト基盤も設計が大事!
  39. 39. 画像について こちらからお借りしました GATAG http://01.gatag.net/

×