第二回 システムテスト自動化 標準ガイド 読書会

1. テスト自動化読書会
第3章 スクリプティングの技法
3.1 イントロダクション
2015年5月23日
1

2. 自己紹介
【名前】
@d_noguchi
【何やっている人？】
サーバ寄りのWEBエンジニア。みんなのサポート屋さん。最近は，社内SE的な感じ。
【技術】
PHP, Ruby, Java, Scala, Ansible, fabric, Jenkins, AWS,...
【仕事に対する姿勢】
自分のパフォーマンス下がってでも，全体最適化を図りたい。
技術どっぷりというより，みんなが幸せになりますように，という考えにシフトしてきた。
【好きなもの】
ジョジョ，森博嗣作品全般
2

3. 第3章の要約
● 3.1 イントロダクション ※ここの説明をさせていただきます。
保守性の高いスクリプトを作る技術 = 保守性の高いプログラムを作る技術
スクリプティングとプログラミングには類似性がある。
きちんと設計しようず。※ただし，使い捨てスクリプトはこの限りではない。
● 3.2 スクリプティングの技法
５つのスクリプトの技法の概要と各スクリプティングの特徴を解説する
● 3.3 スクリプト前処理
スクリプトの作成・メンテナンスのプロセスを簡単でエラーの入りにくいものにするテクニック
3

4. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
4

5. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性 ← ココ
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
5

6. 3.1.1 プログラミングとの類似性
テストの自動化 = テストをプログラミング（スクリプティング）すること
プログラミング言語の目指すところ
● 生産性の向上
● プログラミングを簡単にすること
スクリプティングにもプログラミングと同じように様々な技法があるので、
長所・短所を見ていきましょう。
6

7. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか ← ココ
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
7

8. 3.1.2.1 テストスクリプトは何のために使われるのか
テストスクリプトをコーディングするメリット（の一つ）
= テストケースの自動化に必要なスクリプティングの量を減らせること。
スクリプティングの量を減らす方法
1. コードの共通化・部品化
2. （繰り返し処理などの）制御構造を入れること
以下を天秤に掛けることになる。
・スクリプトの作成およびメンテナンスのコスト
・スクリプトを使うことで得られるメリット
8

9. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト ← ココ
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
9

10. 3.1.2.2 良いスクリプトと悪いスクリプト
良いスクリプト
= 「目的に沿ったスクリプト」
= 使うのもメンテナンスするのも簡単なスクリプト
※1回きりの自動テストケースでは要らないかもね。
以下の指標で良し悪しを比較してみる。
※次図参照。
10

11. 3.1.2.2 良いスクリプトと悪いスクリプト（参考図）
属性 良いテストスクリプト 悪いテストスクリプト
スクリプトの数 より少ない より多い
スクリプトの大きさ 小さい 大きい
機能 明確な単一機能 多くの機能を持つ
ドキュメンテンーション より少ない明快で簡潔で具体的な最新状
態のドキュメントがある。
多くの機能を持つドキュメントがない
か、最新でない。情報が足りない。
再利用 再利用される 再利用されない
構造化 理解しやすい、変更簡単 スパゲッティコード
メンテナンス メンテナンスが容易 変更箇所大。間違えやすい。
11

12. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則 ← ココ
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
12

13. 3.1.2.3 良いスクリプトの原則
1. 使う人、メンテする人にも分かりやすい注釈
2. 機能的、単一タスク、再利用
3. 読みやすさ、理解しやすさ、メンテナンスしやすさ
13

14. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？ ← ココ
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
14

15. 3.1.2.4 「読みやすい」スクリプト？
ツールベンダーの提供する（誤解を招く、目先のことしか考えていない）ツールの特徴
1. 読みやすく
2. 自分でドキュメント化する
ような記録スクリプト（一連の入力からなるテストスクリプト）を生成する。
ツールによっては，自動的にコメントを埋め込む。
略語が使われる場合もありうるので、読みやすいかどうかは人によるかも。
⇒ 「読みやすい」とは、言い難い。
15

16. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？ ← ココ
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
16

17. 3.1.2.5 自分でドキュメント化するスクリプト？
スクリプトをドキュメント化する際によく記載される情報
1. スクリプトの内容
2. スクリプトの目的
3. ユーザのための情報（入出力，事前・事後条件，テスト中の状態，など）
4. 実装に関する情報
5. アノテーション
ツールが生成できるのは，1番目のみ。※結局、自分で書かなきゃいけないじゃん。。。
質問：ほんと？ 多機能なドキュメントツールとかないの？ IBM ならできるの？
17

18. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計 ← ココ
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
18

19. 3.1.3.1 テストケースの設計
テストケースには，検証項目を纏めるものとそうでないものが存在する。
※でも，確認したいことは多分どっちも同じ。
テストケース = テスト手順 = テストスクリプト
テストケースとは，
「まとめて1つのステータスを割り振られれる，最短の検証項目の連なり」
とする。
19

20. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装 ← ココ
3.1.4 スクリプトドキュメンテーションの勧め
20

21. 3.1.3.2 テストケースの実装
テストケースとテスト実行ツールに直接的な関係は（通常）ない。
「1つのテストケースに1つのスクリプト」は推奨されない。
※コスト高くなる。
21

22. 「3.1 イントロダクション」について
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め ← ココ
22

23. 3.1.4 スクリプトドキュメンテーションの勧め
テストスクリプトのドキュメンテーションは、スクリプトそのもののヘッダー部分に置かれること、
また簡潔であることが望ましい。
規約に則って書くのが大事。
● ルールを誰もが知っているので、共有しやすい。
● 一覧表など自動生成しやすい。
23

24. 3.1.4 スクリプトドキュメンテーションの勧め
オススメのスクリプトヘッダー
● TITLE
● SCRIPT
● AUTHOR
● DATE：冗長かも。
● PURPOSE：DESCRIPTION ではなく、こっちで！
● PARAMETERS
● PRE- AND POSTCONDITIONS
● MAINTENANCE：複雑な処理になっている経緯とか。
● AMENDMENTS：冗長かも。
24

25. 3.1.4 スクリプトドキュメンテーションの勧め(具体例)
U01-001 ユーザモデルテストスクリプト
SCRIPT
spec/models/user_spec.rb
AUTHOR
@d_noguchi
DATE
2015/05/23
PURPOSE
ユーザモデルが正しく動作することを確認する。
PARAMETERS
user_name : 田中 一郎
mail_address : test@example.com
PRE- AND POSTCONDITIONS
テスト実行時には、条件検索のために10件のテストデータをあらかじめ登録しておく。
テスト実行後は、次のテストスクリプトのために使用したテストデータを空にする。
MAINTENANCE
テストデータ以外のデータを削除しないこと。
AMENDMENTS
@d_noguchi ： 2015/05/23 ユーザデータ更新処理を追加しました。
@d_noguchi ： 2015/05/20 ユーザデータ登録処理を追加しました。
25

26. 次は、「3.2 スクリプティングの技法」です！
26

27. 自己紹介
[氏名]
小野 貴昭
[仕事]
2011年 株式会社シーエー・モバイルに入社 現在は新規サービス開発を担当
担当は iOS アプリ開発、サーバ開発、DB・サーバチューニング、開発管理など中間管理職
テスト自動化 ← NEW!!!
[趣味]
サーバを速くすること, チューニンガソン, ISUCON 好き
[好きな言葉]
死ななきゃ安い
27

28. 3.2 スクリプティングの技法
28

29. 3.2章の概要
● 各種スクリプトの特徴やと使い方を述べる
o リニアスクリプト
o 構造化スクリプティング
o 共有スクリプト
o データ駆動スクリプト
o キーワード駆動スクリプト
● 解説する技法は排他的なものではなく共存する
● 重要なのはテストケースをどんなアプローチで作成するかである
29

30. 3.2.1 リニアスクリプト
30

31. リニアスクリプト
● テスト実行ツール上でテストケースを手動で実行し、それを記録したもの
でキー入力全てからなる
● １つのテストケースに１つのスクリプト
31

32. 長所
● 事前作業や計画が不要
● 自動化を素早く始められる
● 利用者がプログラマでなくても良い
o 実行して結果を見れば良い
32

33. 短所
● 自動テストを作成するためには手動の２倍から１０倍の時間を要する
● 毎回全てを「一から」やることになりがち
● ソフトウェアの変更に弱い
● 入力と比較がスクリプト内に「直書き」
● スクリプトの共有や再利用がない
● 記録時に起こらなかった何かが起こるとテスト全体が失敗する
33

34. 3.2.2 構造化スクリプティング
34

35. 構造化スクリプティング
● 「制御構文」「呼び出し構造」をもつ
o 制御構文 : IF 文
o 呼び出し構造 : あるスクリプトから別のスクリプトを呼び出す
● 構造化プログラミングに似ている
35

36. 例
36

37. 利点
● 制御構文によりリニアスクリプトでは失敗になるような個々の事象を検出
可能にする
● ループさせて繰り返し処理が可能
● 別のスクリプトを呼び出すことでモジュール化可能
37

38. しかし
● 比較的複雑となった
● テストデータはスクリプト内に「直書き」
38

39. 3.2.3 共有スクリプト
39

40. 共有スクリプト
● 1つ以上のテストケースで使用される
● アプリケーションの特定の箇所に至るまでの 操作を１つのスクリプトにまとめる
40

41. 例
41

42. 長所
● 似たようなテストを実装する工数が少なくなる
● メンテナンスコストがリニアスクリプトより小さくなる
● あからさまな繰り返しをなくせる
● 共有スクリプトにもっと知性を持たせることができる
42

43. 短所
● 把握、ドキュメント化、名前付け、保管の対象となるスクリプトが増える
● すべてのテストに特有のスクリプトが必要となりメンテナンスコストが高いまま
● 共有スクリプトはテスト対象ソフトウェアの 一部分に特化されたものになりがちである
43

44. 共有スクリプトを最大限活かすために
● 規律に従うこと、適切な場所で共有されてなければならない
● 特定の処理に再利用できるスクリプトがあることと見つけ出せることは別なので、見つけ出せ
ず自前のものを書いてしまわないようにする
o プログラマが再利用可能なものを探すのは最大２分
● これが何でどう使えば良いのかをドキュメント化しておかなければならない
44

45. 3.2.4 データ駆動スクリプト
45

46. データ駆動スクリプト
● テストにおける入力値をテストスクリプトではなくデータファイルに記述する
● メニューのナビゲーションなどの制御はスクリプト内に残す
● 入力を変えることによって別のテストを同じスクリプトで実行できる
46

47. 例
47

48. 洗練されたデータ駆動スクリプト
● データファイルのフォーマットに意味を持たせる
● ただし制御スクリプトは複雑なものになる
● ソフトウェアのテストの前にテストのテストとデバッグが発生する
48

49. 例
49

50. 長所
● ほとんど追加工数無しにテストケースを追加できる
● データフォーマットが自由、コメントなども記述可
● プログラムの知識がなくともテストを追加可能
● 追加メンテナンス工数がかからない
● データ駆動スクリプティングの段階に至れば テスト自動化のメリットを享受し始める
50

51. 短所
● セットアップに多くの工数がかかる
● プログラミングについてのサポートが必要
● よく管理されてなくてはならない
51

52. 3.2.4 キーワード駆動スクリプト
52

53. キーワード駆動スクリプト
● データ駆動を洗練して論理的に拡張した技法
● 実行すべきタスクを意味する「キーワード」を用いてテストケースを記述する
● テストファイルと補助スクリプトと制御スクリプトで構成される
● テストファイルにテストケースを記述する
o テストファイルはテストケースをどのように行うかは記述しない
● 制御スクリプトがテストファイルに書かれたキーワードにより補助スクリプトを呼び出す
● この技法のみ「記述的アプローチ」
53

54. 例
http://itpro.nikkeibp.co.jp/article/COLUMN/20121023/431821/?ST=upper
キーワード駆動テストによるGUIテストの効率化
2012/11/01 熊川 一平＝NTTデータ
54

55. 長所
● 補助スクリプトが整備されればスクリプトを増やさずにテストの実装が可能
● プログラムがわからなくてもテストケースが作れる
● ツール非依存にすることが可能である
o 例えばツールベンダーが倒産してもテストケースは作り直さなくて済む
● フォーマットを最適化することで新しいテストを安全に素早く実装できる
55

56. 事例紹介
進化するGUIテスト自動化
http://www.nttdata.com/jp/ja/insights/trend_keyword/2014012301.html
工期短縮の実現に向けたキーワード駆動テストへの取り組み - NTT データ
http://jasst.jp/symposium/jasst14tokyo/pdf/D5-2.pdf
56

57. スクリプト技法 構造化 含むもの 賢さ 定義 アプローチ
リニア していない 定数 なし スクリプト 指示的
構造化 している 定数
IF
ループ スクリプト 指示的
共有 したりしなかったり
定数
変数
IF
ループ スクリプト 指示的
データ駆動 している 変数
IF
ループ
データ読み取り スクリプトデータ 指示的
キーワード駆動 している
変数
キーワード
IF
ループ
データ読み取り
キーワード翻訳 データ 記述的
57

58. 現在実施しているスクリプティングはどれでしょうか？
- リニアスクリプト
- 構造化スクリプティング
- 共有スクリプト
- データ駆動スクリプト
- キーワード駆動スクリプト
- その他
付箋に下記を記入して壁に貼りましょう！＼(^o^)／
・良い点
・悪い点
・そのスクリプティングを使用している理由
58

59. 今後実施したいスクリプティングはどれでしょうか？
- リニアスクリプト
- 構造化スクリプティング
- 共有スクリプト
- データ駆動スクリプト
- キーワード駆動スクリプト
- その他
付箋に下記を記入して壁に貼りましょう！＼(^o^)／
・使用したい理由
・実施するにあたりでてきそうな課題点
59

60. 今後実施したいスクリプティングはどれでしょうか？
・リニアスクリプト
・構造化スクリプト
・共有スクリプト
・データ駆動スクリプト
・キーワード駆動スクリプト
・使用が多いスクリプティング
・使用が少ないスクリプティング
・その他のスクリプティング
60

61. 3-3.スクリプト前処理
スクリプトの作成・メンテナンスのプロセスを簡単で
エラーの入りにくいものにするテクニック
61

62. 自己紹介
[氏名]
kyan Takashi
[出身]
沖縄
[好きな言葉]
No Silver Bullet(銀の弾は存在しない)
[前職]
Webアプリケーション開発(SI),テストマネージャ(という名のぼっち...)
[テスティングについて]
- 前職で絶賛大炎上中Prjにアサインされた時,炎上している理由は品質では..?と思い自習を始めた
- (個人的な)テスティングで目指すのは「低コストだけど品質は保障」
- 一応JSTQB FLです
[東京所感]
- 3ヶ月(2/23に引っ越してきましたので今日が3ヶ月記念日です！すっかり都会人！)
- 電車めちゃくちゃ便利！とにかく何でもある！
- 「沖縄出身です」というと優しくしてもらえる！
- 明らかにもう乗れないだろと思う電車に突撃する人を見て驚愕
62

63. 3.3.1.1 整形処理
63

64. 3.3.1.1 整形処理
スクリプトのレイアウトとフォーマットをチェックし,
必要であれば標準に合致するよう編集すること.
[メリット]
・可読性が上がり,理解が容易になる
・スクリプトを書く担当が作業に集中できる
[デメリット]
・標準を定義する必要がある
・関係者に共有,教育が必要になるかもしれない
64

65. 65

66. Google Chrome developer tools
66

67. Google Chrome developer tools
通信速度高速化を目指しJavaScriptライブラリを圧縮するため,インデントや改行を削除
→可読性の低下.デバッグの難易度☝️
整形スクリプトを機能追加することで可読性の確保！
67

68. 3.3.1.2 静的解析
68

69. 3.3.1.2 静的解析
[静的解析とは]
ソフトウェア開発の成果物を実行せず解析する
[目的]
発見しうる全ての欠陥と異常を検出すること
69

70. 3.3.1.2 静的解析
[C, C++]
→anyWarp CodeDirector for C/C++
→AdLint
[Java]
→Covertura
→PGRelief J
[Ruby]
→RuboCop
有償ツールが多いです..
70

71. 3.3.1.2 静的解析
[検出項目]
・メモリリーク
・NULLポインタ参照
・未到達コード(デッドコード)
・未使用値
・冗長な条件
71

72. 3.3.1.3 一般的な置換
72

73. 3.3.1.2 一般的な置換
[メリット]
・複雑,難解な文字列を別の表現に置換し,
理解しやすいようにする(スクリプトの改善)
・改修が入る場合の修正箇所を集約する
73

74. 3.3.1.2 一般的な置換
置換前
74

75. 3.3.1.5 置換を行う際に注意すべきこと
75

76. 3.3.1.5 置換を行う際に注意すべきこと
やたらめったら置換をしない!
→入力ミスしそうなものまで置換しがちで,デバッグが複雑になる傾向がある
置換の定義自体に欠陥が入りやすいのも注意
76

77. 3.4 まとめ
77

78. 3.4 まとめ
良いスクリプトとは
・コメントなどの注釈がつけられている
・１つのタスクを行う
・構造化されている
・理解しやすい
・ドキュメント化されている
・再利用可
重要なのはスクリプトが理解できるということであり,またドキュメンテーションが
意味のある内容を持っていること
78

79. スクリプト技法 構造化 含むもの 賢さ 定義 アプローチ
リニア していない 定数 なし スクリプト 指示的
構造化 している 定数
IF
ループ スクリプト 指示的
共有 したりしなかったり
定数
変数
IF
ループ スクリプト 指示的
データ駆動 している 変数
IF
ループ
データ読み取り スクリプトデータ 指示的
キーワード駆動 している
変数
キーワード
IF
ループ
データ読み取り
キーワード翻訳 データ 記述的
テストの情報と実装の分離が最も進んでいるキーワード駆動スクリプティングが最も洗練されている.
79

80. ご静聴ありがとうございました!＼(^o^)／
質問などありましたらどうぞ！
80