Recommended
More Related Content
Similar to 00001_test_automation_portfolio_20240313
Similar to 00001_test_automation_portfolio_20240313 (20)
Recently uploaded
Recently uploaded (9)
00001_test_automation_portfolio_20240313
- 2. 目次 ● 前提 ● 自動化の流れ ○ Step1 テスト実行を自動化 ○ Step2 確認対象データ出力を自動化 ○ Step3 データ突合を自動化 ○ Step4 ツールをキーワード駆動にしてチームに展開 ○ Step5 リグレッションテスト導入 ● 自動化して良かったこと ● 所感
- 6. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 7. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 9. アプリ Step1 操作自動化(af) RDB API CLI (スクリプト) APIエンドポイントを叩く ・Pythonのrequests ・PostMan Webブラウザの操作自動化 ・Selenium ・Selenium IDE(画面ポチポチでコード生成 ) ・Autify 注文パ ターン 100
- 10. import requests import json url = 'https://api.example.com/order' headers = {~~~~} # テストシナリオの数だけループ for scenario in scenarios: # 'test_actual'の内容をdataに代入 data = scenario['test_actual'] # 注文情報をJSON形式に変換したり整形したり order_data_json = ~~~~ # POSTリクエストを送信 response = requests.post(url, data=order_data_json, headers=headers) print(f"Test No: {scenario['test_no']}, Status Code: {response.status_code}") test_order.py Step1 操作自動化(af) Scenario.json [{ "test_no": "0001", "test_actual":{ "order_day": "2023-01-01", "span": 12 : } }, { "test_no": "0002", :
- 11. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 13. Step2 確認対象データ出力を自動化(af) RDB CLI (スクリプト) ●APIエンドポイントを叩く ・Pythonのrequests(GET系) ●SQLコマンドで取ってくる ●ブラウザに表示される値を取得 ・Selenium mysql db_name -ss -e “SELECT ~~~” 利用開始日 利用終了日 請求日 1/1 1/31 2/1 利用開始日 利用終了日 請求日 1/1 1/31 2/1 利用開始日 利用終了日 請求日 1/1 1/31 2/1 整形してコピペ
- 14. ~~~~~ # POSTリクエストを送信 response = requests.post(url, data=order_data_json, headers=headers) # SQLコマンドで確認したいデータ出力 output_path = xxxxx mysql_command = f'mysql db_name -ss -e "SELECT ~~~" > {output_path}{scenario["test_no"]}.txt' # コマンドの実行 result = subprocess.run(mysql_command, shell=True, check=True, capture_output=True, text=True) test_order.py TEST0001.txt TEST0001.txt TEST0001.txt 利用開始日 利用終了日 請求日 1/1 1/31 2/1 ・データをどう確認(整形)するかは後で考える！ ・とはいえパッと見で何のデータかは解るようにはし ておく 追加 Step2 確認対象データ出力を自動化(af)
- 15. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 17. var1.0 ver1.1 Ver1.0 Step3 確認する値を突合(af) CLI (スクリプト) Ver1.1 利用開始日 利用終了日 請求日 1/1 1/31 2/1 2/1 2/28 3/1 : 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/31 2/1 2/1 2/28 3/1 : result 0001_start_day OK 0001_end_day NG 0001_invoice_day OK : 終了日 1/31 2/28 3/28 ： データを整形してtxt出力、diffコマンド 用にデータを整形してtxt出力、diff結 果を一覧表示 請求パ ターン 100 請求パ ターン 100 仕 様
- 18. Ver1.0 Step3 確認する値を突合(af) CLI (スクリプト) Ver1.1 請求パ ターン 100 請求パ ターン 100 result 0001_start_day OK 0001_end_day NG 0001_invoice_day OK : var1.0 ver1.1 開始日 1/1 2/1 3/1 ： 開始日 1/1 2/1 3/1 ： var1.0 ver1.1 終了日 1/31 2/28 3/31 ： 終了日 1/31 2/28 3/28 ： diff ver1.0_0001_start_day.txt ver1.1_0001_start_day.txt diff ver1.0_0001_end_day.txt ver1.1_0001_end_day.txt 意図した差分か確認 (リグレッション検出) 利用開始日 利用終了日 請求日 1/1 1/31 2/1 2/1 2/28 3/1 : 利用開始日 利用終了日 請求日 1/1 1/31 2/1 2/1 2/28 3/1 : 仕 様
- 19. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 20. 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->1.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 : 各々でシナリオ作ってテスト 回してくれないかな......
- 21. Step4 ツールをキーワード駆動にしてチームに展開 GAS 実行 Scenario.json シナリオ生成ツール作ったから 各々で作っといて！ [{ "test_no": "0001", "test_actual":{ "order_day": "2023-01-01", "span": 12 : } }, { "test_no": "0002", :
- 22. 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 : 問い合わせ ツールメンテナンスは任せろ～ シナリオ シナリオ シナリオ
- 23. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 25. 自動化して良かったこと ● テスト工数削減(step1,2,3) ● バグの早期検出(step4) 開発メンバーが製造段階で影響範囲のテストを実施するので、統合テストでのバグが減った ● レビューの負担軽減(step5) システムの仕様上、ユースケースの入力パターンが多く、条件が複雑だった為、開発メンバーが仕様を把握して切れず、考慮漏れに よるバグが多発していた。※設計レビューはアドホック形式 →レビュー段階で「ユースケース一覧のこの範囲をテストする」というテスト項目(テスト実行シナリオ)レビューも一緒に行うことで、開 発担当とレビュアーの影響範囲の認識齟齬や場当たり的な指摘が減った。