Jasst14東北事例発表 share

SEPLANNING.CO
STAR : SOFTWARE TEST AUTOMATION RESEARCH
GROUP.JP
SHINATESU : SHINAGAWA TESTING TEAM
JASST’14 TOHOKU
SATSUKI URAYAMA : MAY PRESENTS
AUTOMATOR 2
M A NAGEME NT D AY S

浦山さつき
(株)エスイープランニングテストエンジニア
テスト自動化研究会(STAR) コミッター
しなてす
岩手県盛岡市出身
[最近の嬉しかったこと]
東京で「プチよ市」が開催されること
[最近の悲しかったこと]
「へっちょこだんご」が通じなかったこと
＆会場に「よ市」が通じなかったこと
M

はじめに
予稿集について
 本発表の参考資料あり、発表時のスライドと内容が異なります
 テスト自動化チームの人数は新規開発時のものであり、保守の段階
の自動化チームは最終的に２人まで減りました
キャプチャ＆リプレイツールを使用して画面を操作する
テストの実行を自動化していました
本資料は当日の会場の声を受けて、一部に修正を加えて
いますm(_ _)m
M

48%
10%
16%
8%
18%
近々自動化しようと検討し
ている
自動化しようとしたが障壁
があったため断念している
自動化したテストに問題が
出ている
自動化したテストが上手く
いっている
自動化しようとは現時点で
考えていない
TEST
Automation?
傾向
JaSST’14 Tohoku 参加者アンケートより
会場内で自動化し
たことのある人の
うち、約65％の人
が自動化後に問題
を抱えている
Q.テストを自動化していますか？

保守性
• 修正のしやすさに関するソフトウェア製品の能力
(JIS X 0129:2003)
解析性
変更性
安定性
試験性
保守性標準適合性
これを満たすような自動テストってどんなもの？

自身が経験した事例の中から
5年間保守し続けた自動テストを紹介
M

テスト対象システムのライフサイクル
①199X年
新規開発
⑤サービス終了
②設計
影響調査
③修正の実施
④テスト
⑥201X年
システム刷新
サービス追加要件
リリース
３か月毎

自動テストのライフサイクル
①2005年
新規開発
⑤不要な
テストの除外
②影響調査
③修正の実施
④試行
⑥2011年
テスト自動化
システム刷新
テスト実施
及び
リリース判定
３か月毎

レベル
受入れテスト
システムテスト
統合テスト
単体テスト
タイプ
機能テスト
ユースケース
テスト
回帰テスト
etc…
回帰テスト

レベル
受入れテスト
統合テスト
単体テスト
タイプ
機能テスト
ユースケース
テスト
回帰テスト
etc…修正できる
期間が短い
テスト対象に
バグが入り込みやすい修正する
期間がとれる
テスト対象の
バグが発生し
にくい
回帰テスト保守工数
UP
保守工数
UP
自動化のバグ？
テスト対象のバグ？
切り分けが必要
自動化したテストの
テストがしやすい

1.Aさんが新規契約。支払は口座振替。
プラン１、プラン２、割引１、割引２を適用。
2.Aさんのプラン１を廃止する変更登録。
3.Bさんが新規契約。プラン１と割引１を適用。使用料はAさんが一括で支払
う。
4.Aさんの支払いをクレジットカード払いに変更登録。
5.Aさんの契約を解除する。
回帰テストの一例
A
B
プラン１
プラン２
割引１
割引２
口振
プラン１
割引１
CR
A一括請求書

1.Aさんが新規契約。支払は口座振替。
プラン１、プラン２、割引１、割引２を適用。
2.Aさんのプラン１を廃止する変更登録。
3.Bさんが新規契約。プラン１と割引１を適用。使用料はAさんが一括で支払
う。
4.Aさんの支払いをクレジットカード払いに変更登録。
5.Aさんの契約を解除する。
回帰テストの一例
種別顧客支払プラン1 プラン2 割引1 割引2
新規 A 口振付付付付
変更 A 廃廃
新規 B 一括(親A) 付付
変更 A CR 廃付廃付
解約 A
種別新規契約
変更
利用停止
解約
変更取消

操作内容の細分化
支払方法を設定する
プランを外す
割引を付ける
割引を外す
プランを付ける
新規契約
変更
変更取消
利用停止
解約
登録種別を選択する
種別新規契約
変更
利用停止
解約
変更取消

完成したテスト自動化フレームワーク
操作順操作画面値
1 ユーザーID入力 ABC
2 検索
Class サービス設定画面
Function ユーザー名(Name)
TextBox(“UserName”).Type Name
Function ログイン
Button(“Login”).Click
Class 検索画面
Function ユーザーID入力(id)
TextBox(“UserId”).type id
Function 検索
Button(“Serch”).Click
パラメタ
なにを順番どこにどうする
スクリプトスクリプトスクリプト

操作順の変更操作対象の変更設定値の変更
パラメタ
なにを順番どこにどうする
スクリプトスクリプトスクリプト
完成したテスト自動化フレームワーク
変更箇所が
見つけやすい

自動テストの保守作業
②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
３か月毎

②影響調査 - 1
既存のテスト内容に影
響する要件がないか調
査する。
機能仕様書や画面仕様
書を以下の観点で調査
する。
 オペレーションの追加や
変更があるか
 必ず確認しなければなら
ないサービスや付与しな
ければならないサービス
の追加や変更があるか
②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
１か月

②影響調査 - 2
影響箇所と規模を見積
もる。
スクリプトは、追加さ
れるオブジェクトの種
類や数により工数を見
積もる。
パラメタ調査ツールを
使用し、既存パラメタ
に変更対象の箇所がど
れくらいあるか調査す
る。
②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
１か月

③修正の実施 ‐ 1
スクリプトを修正する
新しいボタンや画面が
追加された場合、スク
リプトを追加する。
パラメタを修正する
一括置換ツールを使用
し、変更箇所を一括で
置き換える。
②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
１か月

④試行 ‐ 1
環境を構築する
環境作成ツールを使用
し、テスト環境を用意
する。
修正に誤りや漏れがな
いか確認する。
修正したテストを抜粋
し、試験管理ツールを
使用して実行をコント
ロールする。
②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
２週間

④試行 ‐ 2
結果取得ツールを使用
し、OK/NGを一覧で取
得する。
NGの場合、自動化の
バグかテスト対象のバ
グかを切り分けるた
め、ログを確認する。
自動化のバグがなくな
れば完了。
②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
２週間

②影響調査
③修正の実施
④試行
テスト実施
及び
リリース判定
パラメタ調査ツール
試験管理ツール
環境作成ツール
一括置換ツール
結果取得ツール
変更による間違いが
起きにくい

変更による間違いが
起きにくい
変更箇所が
見つけやすい
自動化したテストの
テストがしやすい
試験性
解析性
安定性
自動化のスコープを
定める
自動テストを
構造化する
ツールを活用する

生み出した自動テストが
長生きできる仕組みを作ろう
M

 JIS X 0129:2003
 JIS X 0161：2008
 ISO/IEC 9126-1
 『ソフトウェア工学のすすめ』玉置彰宏
http://www.tamakiseoffice.jp/software_engineering/Chap_3
3.pdf
 TABOK(Test Automation Body Of Knowledge)
 Terminator Real NFI
http://www.dafont.com/terminator-real-nfi.font
PRESENTED BY
SATSUKI URAYAMA

Jasst14東北事例発表 share

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)