テスト自動化.pdf

サブスク管理システムの
統合テストを自動化した話

自己紹介
名前：池田
経歴：IT業界歴7年、主に通信インフラ開発、 Webアプリ開発
領域：バックエンド、インフラ (Python,Django,Bashとか)
趣味：コスプレ、カメラ、 3Dプリンタ造形
キャンプ、サウナ、ロードバイク、釣り
資格：基本情報、AWS SAA、JSTQB FL、小型船舶免許1級

目次
● 前提
● 自動化の流れ
○ Step1 テスト実行を自動化
○ Step2 確認対象データ出力を自動化
○ Step3 データ突合を自動化
○ Step4 ツールをキーワード駆動にしてチームに展開
○ Step5 リグレッションテスト導入
● 自動化して良かったこと
● 所感

前提1
サブスクリプション管
理システム
プロバイダー
ユーザ
ユーザ
ユーザ

前提2
メンバー
ベースシステム
開発チーム
リーダー
池
田
サブスクリプション管
理システム
アジャイル開発(スクラム、1スプリント2週間)
課題
・リーダー以外がジュニアエンジニア、リーダーの負担大
・テスト項目数が莫大で、アジャイル開発にも関わらずリリース頻度が低く、リ
ファクタリングも困難
・開発メンバーが仕様を把握して切れず、考慮漏れによるバグが多発
特徴
・モノリス構造
・ユースケースの入力パターンが多く、かつ条件が
複雑

アプリ
Controller
請求
前提3 テストの方法とシステムの動作
RDB
GUI
注文
開通日：1/1
期間：12ヶ月
支払：月々払い
請求：前払い
課金開始日：日割
数量：10
etc…
ポ
チ
ポ
チ
ポ
チ
ポ
チ
利用期間：1/1~1/31
請求日：1/1
契約
期間：1/1~12/31
自動更新：する
途中変更：可能
etc…
利用期間：2/1~2/28
請求日：2/1
:
利用期間：12/1~12/31
請求日：12/1
注文
契約請求

自動化の流れ
Step1 テスト実行を自動化
Step2 確認対象データ出力を自動化
Step3 データ突合を自動化
Step4 ツールをキーワード駆動にしてチームに展開
Step5 リグレッションテスト導入

アプリ
Step1 操作自動化(bf)
RDB
GUI
ポ
チ
ポ
チ
注文パターン1
契約請求
注文パターン2
注文パターン100
ポ
チ
ポ
チ
注文パターン3
:
開通日：3パターン
×
期間：2パターン
×
支払：2パターン
×
請求：3パターン
×
etc…
実行めんど
いな……

アプリ
Step1 操作自動化(af)
RDB
契約請求
API
CLI
(スクリプト)
APIエンドポイントを叩く
・Pythonのrequests
・PostMan
Webブラウザの操作自動化
・Selenium(バックグラウンド実行 )
・Selenium IDE(画面ポチポチでコード生成 )
・Autify(画面ポチポチで作成したシナリオを Autifyが提供するAPIから実行)
注文パ
ターン
100
※確認はGUI

アプリ
Step2 確認対象データ出力を自動化(bf)
RDB
契約請求
API
GUI
請求パ
ターン
100
画面キャプチャ
パターン100
キャプチャめ
んどいな
……

アプリ
Step2 確認対象データ出力を自動化(af)
RDB
契約請求
API
CLI
(スクリプト)
請求パ
ターン
100
●APIエンドポイントを叩く
・Pythonのrequests(GET系)
●SQLコマンドで取ってくる
●ブラウザに表示される値を取得
・Selenium(バックグラウンド実行 )
mysql db_name -ss -e “SELECT * FROM invoice”
id 利用開始日利用終了日請求日
1 1/1 1/31 2/1
2 2/1 2/28 3/1
3 :

アプリ
Step3 確認する値を突合(bf)
RDB
CLI
(スクリプト)
請求パ
ターン
100
mysql db_name -ss -e “SELECT * FROM table_name”
1 1/1 1/31 2/1
2 2/1 2/28 3/1
3 :
確認してOK/NGを入力
コピペ
確認めんどいな......

var1.0 ver1.1
Ver1.0
Step3 確認する値を突合(af)
CLI
(スクリプト)
Ver1.1
請求パ
ターン
100
請求パ
ターン
100
1 1/1 1/31 2/1
2 2/1 2/28 3/1
3 :
diff ver1.0_0001_start_day.txt
ver1.1_0001_start_day.txt
開始日
1/1
2/1
3/1
開始日
1/1
2/1
3/1
var1.0 ver1.1
終了日
1/31
2/28
3/31
diff ver1.0_0001_end_day.txt
ver1.1_0001_end_day.txt
1 1/1 1/31 2/1
2 2/1 2/28 3/1
3 :
result
0001_start_day OK
0001_end_day NG
0001_invoice_day OK
:
終了日
1/31
2/28
3/28
データを整形してtxt出力、diffコマンド
用にデータを整形してtxt出力、diff結
果を一覧表示

Ver1.0
Step4 ツールをキーワード駆動にしてチームに展開(bf)
CLI
(スクリプト )
Ver1.1
請求パ
ターン
100
請求パ
ターン
100
result_v1.0_vs_v1.1
0001_start_day OK
0001_end_day OK
0001_invoice_day OK
:
開発メンバー
開発メンバー
開発メンバー
ver1.0->1.1
分割系確認してほし
い
ver1.1->ver1.1.1
日割り系確認してほ
しい。
(仕様は口頭)
ver1.0->1.2
月跨ぎ確認してほし
い
仕様書
仕様書
仕様書
池
田
仕様書
Ver1.1
CLI
(スクリプト )
Ver1.1.
1
請求パ
ターン
100
請求パ
ターン
100
result_v1.1_vs_v1.1.1
0001_start_day OK
0001_end_day OK
0001_invoice_day OK
:
Ver1.0
CLI
(スクリプト )
Ver1.2
請求パ
ターン
100
請求パ
ターン
100
result_v1.1_vs_v1.2
0001_start_day OK
0001_end_day OK
0001_invoice_day OK
:
各々でシナリオ作ってテスト
回してくれないかな......

Step4 ツールをキーワード駆動にしてチームに展開
GAS
実行
Scenario.json
シナリオ生成ツール作ったから
各々で作っといて！
[{test_no:0001,
order_day:2023-01-01,
span:12,
:
},{test_no:0002,
order_day:2023-01-01,
span:12,
:
}
]

Ver1.0
Step4 ツールをキーワード駆動にしてチームに展開(af)
CLI
(スクリプト )
Ver1.1
請求パ
ターン
100
請求パ
ターン
100
result_v1.0_vs_v1.1
0001_start_day OK
0001_end_day OK
0001_invoice_day OK
:
開発メンバー
開発メンバー
開発メンバー
池
田
Ver1.1
CLI
(スクリプト )
Ver1.1.
1
請求パ
ターン
100
請求パ
ターン
100
result_v1.1_vs_v1.1.1
0001_start_day OK
0001_end_day OK
0001_invoice_day OK
:
Ver1.1
CLI
(スクリプト )
Ver1.2
請求パ
ターン
100
請求パ
ターン
100
result_v1.1_vs_v1.2
0001_start_day OK
0001_end_day OK
0001_invoice_day OK
:
問い合わせ
ツールメンテナンスは任せろ～
シナリオ
シナリオ
シナリオ

Step5 リグレッションテスト導入
注文
シナリオ
自動更新
シナリオ
変更注文
シナリオ
契約切替
シナリオ
自動更新
シナリオ
Ver1.0
CLI
(スクリプト)
Ver1.1
自動更新
シナリオ
本番環境1
本番環境1
本番環境1
本番環境1
実際に使われているパターンを
元にリグレッション用のシナリオ
を作成

自動化して良かったこと
● テスト工数削減(step1,2,3)
● バグの早期検出(step4)
開発メンバーが製造段階で影響範囲のテストを実施するので、統合テストでのバグが減った
● レビューの負担軽減(step5)
システムの仕様上、ユースケースの入力パターンが多く、条件が複雑だった為、開発メンバーが仕様を把握して切れず、考慮漏れに
よるバグが多発していた。※設計レビューはアドホック形式
→レビュー段階で「ユースケース一覧のこの範囲をテストする」というテスト項目(テスト実行シナリオ)レビューも一緒に行うことで、開
発担当とレビュアーの影響範囲の認識齟齬や場当たり的な指摘が減った。

所感
1. 誰が使うかを意識して自動化する
最初はbashとかpythonスクリプトに直接シナリオ書いてたけれど、やはり理想は「製造した人がその機能を担保する」なので、いずれ
は自分以外が使うことを想定して作るのがよいと思う。
2. 半端なツールは展開しないほうが良い
とはいえ他の人に展開する前提でいきなりツール作り始めるのはハードルが高い。
今回作ったテストツールを他メンバーに展開する際には少なくとも以下の情報を正確に伝える必要があった。
・使用できる条件(環境やバージョン等)
・対応範囲(実行可能なシナリオ)
・実行手順
・出力(何が実行、確認、担保できるか。OK/NG、差分、スナップショット等)

テスト自動化.pdf

テスト自動化.pdf

Recommandé

Contenu connexe

Similaire à テスト自動化.pdf

Similaire à テスト自動化.pdf(20)

Dernier

Dernier(11)

テスト自動化.pdf