2022.12.15_azuma_ryoga_reteigi_テスト自動化ツールT-DASHを使ってみた.pptx__1_.pdf

Transcript

1. T-DASHを使ってみた Repharmacy 東遼河
2. 今回のLTは自分で書いたQiitaの記事をベースに組み立ててます https://qiita.com/R-Az/items/e30f5f9fd32fedcdfd4e はじめに
3. アジェンダ • E2Eテストって大変だよね • T-DASHって？ ◦ 概要 ◦ できそうなこと • 実際に使ってみた ◦ 簡単なテストを動かすまでxx時間 • ぶっちゃけ…
4. E2Eテストって大変だよね
5. システムのバグを減らしたい
6. UIのテストは避けられない
7. E2Eテストの自動化は カロリーが高い…
8. E2Eテストの自動化のこれが辛い • テストを書く・維持 ◦ 理想はプロダクトの走り出しのときからコツコツ書くことだけど、実際にはそうは行かない ▪ UIの変化が激しいから追従にコストがかかる ▪ エンジニアが少ないと、まずは機能開発優先になる ◦ かといって、プロダクトの機能が増えてからいれるのも大変 ▪ 機能数が多いと、必然的にテストシナリオも増えるので工数がかかる • 自動テストの導入 ◦ テスト用の環境構築 ◦ テストケースの整理 • 実行にも時間がかかる ◦ UIの操作なので、シナリオが増えれば増えるほどしんどい
9. T-DASHって？
10. https://service.valtes.co.jp/t-dash/
11. T-DASHが解決できそうなこと(主観) • 導入コストの削減 ◦ 難しい環境構築はない。 ◦ (macなら)アプリを2つとpython3を入れるだけでテストが動く ▪ python3はだいたい元から入ってる • 作成・維持のコストを下げる ◦ エンジニア不要 ▪ テストをエクセルっぽく書ける ▪ xPathなどの取得も簡単 ◦ テストの書き味もわるくない ▪ テストシナリオを共通化できるので、ログインみたいな共通動作を毎回書く必要がない ▪ 画像比較も難しいこと考えずにできる
12. 実際に使ってみた
13. 1時間 T-DASHのホームページをひらいてから簡単なテストを動かすまでの時間
14. T-DASHでテストを作るときの工程 1. 対象の画面の要素をT-DASH上に定義する（画面定義） 2. テストシナリオを書く 3. 実行してみる ※この後流れを説明しますが、だいぶざっくりになるので、興味があれば公式HP読んでください！
15. 1. 対象の画面の要素をT-DASH上に定義する（画面定義）
16. スプレッドシートに画面の要素を定義
17. T-DASHのツールで実際の画面から要素のxPathを抽出 ※xPathとは 画面の各要素の住所み たいなもの
18. こんな感じ
19. 2. テストシナリオを書く
20. スプレッドシートにテストシナリオを書く
21. こんな感じ
22. 3. 実行してみる
23. テストを動かすとレポートが出る
25. エラーが出るとこう
27. ぶっちゃけ…
28. T-DASHは リテイギだと導入できる プロダクトが限られる印象
29. T-DASHのここがリテイギだと使いづらいかも • CI/CDに組み込む機能がない ◦ 頑張れば自分で組み込めるけど … • OSがmac or Windows ◦ 上記とかぶるが、CI/CDに組み込む場合どっかしらに仮想環境立てたくなるが、 win/macだとちょっ と大変 ◦ azureとかで仮想デスクトップでか、 ngrokとかでローカルマシンにつなぐとかになる • Gitでのソースの共有とか現状つらそう ◦ プロジェクトのエクスポートはできるのでバージョン管理自体はできなくはない ◦ テストコードを直に書くわけではないのでコンフリクトしたら多分治すの大変
30. まとめ
31. 良い点 • エンジニアでなくてもテスト自動化できる • 環境構築に手間がかからない 悪い点 • CI/CDへの組み込みが大変そう • ソースの管理が大変そう