1. システムテスト自動化 標準ガイド
第7章 保守性の高いテストを構築する
@nihonbuson

2. メンテナンスに関する問題
テストのメンテナンスは軽視される
• ソフトウェアのメンテナンスは重要視するのに…
• 自動テストはメンテナンスコストが特に重要

3. テストケースの数
• 新規機能、不具合修正の度に追加すべき

4. テストケースの数
• 新規機能、不具合修正の度に追加すべき
• メンテナンスコストがどんどん増えていく
• 過剰・重複するテストケースが存在する可能性あり
• 「沢山テストケースがあるから良いよね？」
• 追加するテストケースが何の役に立つのか？

5. テストケースの数
• 新規機能、不具合修正の度に追加すべき
• メンテナンスコストがどんどん増えていく
• 過剰・重複するテストケースが存在する可能性あり
• 「沢山テストケースがあるから良いよね？」
• 追加するテストケースが何の役に立つのか？
• 定期的に草刈りすべき（？）

6. テストデータの量
• 沢山のテストデータを用いて、徹底的なテストをしよう

7. テストデータの量
• 沢山のテストデータを用いて、徹底的なテストをしよう
• メンテナンスコストがかかる
• テスト失敗の分析とデバッグ作業の工数が増加

8. テストデータの量
• 沢山のテストデータを用いて、徹底的なテストをしよう
• メンテナンスコストがかかる
• テスト失敗の分析とデバッグ作業の工数が増加
• テストケース1つ当たりのディスク容量の使用制限を設ける（？）
• テスト計画に多くの時間を割く
• 構成管理システムにテストケースを登録すること
巨大なテストデータの検知＆受け入れなくなる

9. テストデータの形式
• ソフトに使用できるならどんな形式でもOK
• 変換の手間も省けるし

10. テストデータの形式
• ソフトに使用できるならどんな形式でもOK
• 変換の手間も省けるし
• 形式変更時、テストデータの更新or再作成が必要
• ソフトウェア独自拡張子のテストレポートの変換が…

11. テストデータの形式
• ソフトに使用できるならどんな形式でもOK
• 変換の手間も省けるし
• 形式変更時、テストデータの更新or再作成が必要
• ソフトウェア独自拡張子のテストレポートの変換が…
• テキスト形式にすべき
• バイナリ形式なら、変換プログラムを作成せよ

12. テストケースの実行時間
• セットアップと後片付けの回数を減らすためにも、
好きなだけ長く
コンピュータは注意力散漫にもならないし

13. テストケースの実行時間
• セットアップと後片付けの回数を減らすためにも、
好きなだけ長く
コンピュータは注意力散漫にもならないし
• 長いテストケースの最初の失敗は後の失敗を隠す
成
功
失
敗
失
敗
？
失
敗
？

14. テストケースの実行時間
• セットアップと後片付けの回数を減らすためにも、
好きなだけ長く
コンピュータは注意力散漫にもならないし
• 長いテストケースの最初の失敗は後の失敗を隠す
• 短いテストケースを何度も回し、分析やデバッグを行う

15. テストケースのデバッグ能力
• テストツールの仕事は成功、失敗判定のみでしょ？

16. テストケースのデバッグ能力
• テストツールの仕事は成功、失敗判定のみでしょ？
• 失敗の原因を調査する必要がある

17. テストケースのデバッグ能力
• テストツールの仕事は成功、失敗判定のみでしょ？
• 失敗の原因を調査する必要がある
• 「失敗した場合、どのようなことを知りたいのか」
を念頭に置いて設計すべき

18. テストの相互依存性
• 前のテストケースの結果を次のインプットにすれば
多くの包括的なテストを行える

19. テストの相互依存性
• 前のテストケースの結果を次のインプットにすれば
多くの包括的なテストを行える
• 前のテストケースが正しい結果を生み出せないと、
次のテストケースは正しく開始することすらできない
（ドミノ効果）

20. テストの相互依存性
• 前のテストケースの結果を次のインプットにすれば
多くの包括的なテストを行える
• 前のテストケースが正しい結果を生み出せないと、
次のテストケースは正しく開始することすらできない
（ドミノ効果）
• 最初は少数の短いテストケースの繋がりから試すべき

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. 命名規則
• 好きなように付けろ。そんなところに時間を使うな

23. 命名規則
• 好きなように付けろ。そんなところに時間を使うな
• ファイルの検索性や再利用性にも関わる、重複する

24. 命名規則
• 好きなように付けろ。そんなところに時間を使うな
• ファイルの検索性や再利用性にも関わる、重複する
• 開始時点で命名規則を採用しよう

25. テストの複雑性
• ツールで、複雑なものもテスト可能に！

26. テストの複雑性
• ツールで、複雑なものもテスト可能に！
• 人間が理解できなくなる

27. テストの複雑性
• ツールで、複雑なものもテスト可能に！
• 人間が理解できなくなる
• テストケースが理解しづらいので最小限にすべき
• 複雑で数回しか実行しないなら自動化する価値なし

28. テストドキュメンテーション
• 必要ない。テストケースを読むのはツールだから

29. テストドキュメンテーション
• 必要ない。テストケースを読むのはツールだから
• 「ソフトウェアを実行するのはコンピュータだから、
ソフトウェアにドキュメンテーションは必要ない」
と言えるのか？

30. テストドキュメンテーション
• 必要ない。テストケースを読むのはツールだから
• 「ソフトウェアを実行するのはコンピュータだから、
ソフトウェアにドキュメンテーションは必要ない」
と言えるのか？
• ドキュメンテーションは書くべき
• この際、重要なのは量より質

31. 落とし穴
• ツールが間違っていることを誘導している
導入コスト小 メンテナンスコスト大
• 容易なアプローチが高いメンテナンスコストへ…

32. 最初の熱意
• 「できるだけ多くのソフトウェア
にとりあえず投げ込んでみる」
が大きなダメージを
発生させる

33. 投資利益率
• 最初の80%の工数が20%の利益を生み、
最後の20%の工数が80%の利益を生む
工数
利益

34. 戦略
• テストのメンテナンスに一番大きな影響を与えうる
要素をまずは見極め、それを減少させる行動をとる
• 行動とその結果を評価し、将来に向けた判断を行う
（評価については第8章にて）

35. 戦術
1. 推奨値と基準値を定めよ（容量、テスト時間）
2. ツールによるサポートを提供せよ（not運用ルール）
3. 更新を自動化する（統一した更新に）
4. 草刈りの予定を立てる
5. 手作業にせず、メンテナンスユーティリティを用意する

36. まとめ①
以下の部分に注意してメンテナンスを考える
• 数は確認せずに増やさない
• 容量もコントロールすべき
• 柔軟性のある形式にすべき
• 実行時間は最小化されるべき

37. まとめ②
• デバッグが簡単なように設計されるべき
• テストケースは可能な限り独立してるべき
• 命名規則は早い段階で採用すべき
• テストケースは可能な限り単純であるべき
• 正確かつ簡潔にドキュメント化されるべき

38. 感想
• メンテナンスを考えて自動化しよう
• テスト基盤も設計が大事！

39. 画像について
こちらからお借りしました
GATAG
http://01.gatag.net/