AI自動テストツールを支える開発・テストプロセス

by Nozomi Ito

Slide 1

Slide 1 text

AI自動テストツールを支える開発・テストプロセス TRIDENT 伊藤望

Slide 2

Slide 2 text

About Me p 伊藤望(Ito Nozomi) p 株式会社TRIDENT代表取締役 n AI自動テストツール「Magic Pod」の運営 p 日本Seleniumユーザーコミュニティ主宰 p 著書

Slide 3

Slide 3 text

Magic Pod (@TRIDENTInc) p E2Eテスト自動化クラウドサービス p Webとモバイルアプリのテストに対応 p AI技術を活用 n テストスクリプトを読みやすい日本語化 n テスト対象画面に変更があったら、テスト手順を自動修正 p 利用者も順調に増加中

Slide 4

Slide 4 text

今日話すこと 1. なぜ今テスト自動化なのか 2. Magic Pod開発の体制 3. Magic Pod開発のテスト自動化 4. Magic Pod開発のCI運用

Slide 5

Slide 5 text

1. なぜ今テスト自動化なのか 2. Magic Pod開発の体制 3. Magic Pod開発のテスト自動化 4. Magic Pod開発のCI運用

Slide 6

Slide 6 text

テスト自動化とは p テスト手順をプログラム化しておくと、コンピュータが自動でテスト実行してくれる。システム全体を通しでテスト UIテストツールなどを活用複数の部品を結合してテスト APIテストツールなどを活用個々の関数やクラスのテストユニットテストツールなどを活用 E2E Test Integration Test Unit Test

Slide 7

Slide 7 text

アジャイル開発で重要なことプロセス技術カギは「自動化」

Slide 8

Slide 8 text

アジャイル開発と「自動化」ビルドテストリリース設計開発ビルドテストリリース設計開発ビルドテストリリース設計開発

Slide 9

Slide 9 text

アジャイル開発と「自動化」ビルドテストリリース設計開発ビルドテストリリース設計開発ビルドテストリリース設計開発自動化しないと繰り返し困難

Slide 10

Slide 10 text

アジャイル開発と「自動化」ビルドテストリリース設計開発ビルドテストリリース設計開発ビルドテストリリース設計開発一番工数がかかるのに一番自動化が難しい

Slide 11

Slide 11 text

なぜ今テスト自動化なのか p フィードバックのサイクルを早くするには「テストの自動化」がカギだから p 「開発サイクルの高速化」を目的とした自動化が増加 n 従来は「コスト削減」がメイン

Slide 12

Slide 12 text

1. なぜ今テスト自動化なのか 2. Magic Pod開発の体制 3. Magic Pod開発のテスト自動化 4. Magic Pod開発のCI運用

Slide 13

Slide 13 text

Magic Podの開発環境 p Webサーバ・AIエンジン: Python、Django p 自動テストエンジン: Node.js p 開発者: 約6人 p QA: 0人 n ただし、 n 本書いている人とか、Selenium/Appiumコントリビュータとか p ほぼフルリモート p 読み書き(Slack、GitHub等)は英語テスト自動化のエキスパートは多数

Slide 14

Slide 14 text

Magic Podの開発フロー p アジャイル的開発 p 2週間ごとのイテレーション(& リリース) n 細かいパッチリリースは随時 p ビルド、デプロイは自動化

Slide 15

Slide 15 text

Magic Podの開発フロー p テスト n 新規開発部分は各自手動テスト n 一部のテストは自動化 n リリース前の３日間は社内ドッグフーディング３日前 main branch 次の開発 feature branches リリース次の開発

Slide 16

Slide 16 text

1. なぜ今テスト自動化なのか 2. Magic Pod開発の体制 3. Magic Pod開発のテスト自動化 4. Magic Pod開発のCI運用

Slide 17

Slide 17 text

Magic Podのテスト自動化 p 全テスト自動化はできないので、絞って自動化 p 手動テスト量の削減 & リグレッションの削減を目指す

Slide 18

Slide 18 text

どのテストを自動化するか 1. 自動化コストが低いところ 2. 処理が複雑なところ 3. 重要なところ

Slide 19

Slide 19 text

どのテストを自動化するか 1. 自動化コストが低いところ 2. 処理が複雑なところ 3. 重要なところ AIエンジン静的解析セキュリティ、自動テストエンジン、主要画面

Slide 20

Slide 20 text

1. 自動化コストが低いところ p ツールを設定するだけでチェックができるもの p スクリプトのメンテナンスが(ほぼ)不要なもの p Magic Pod開発でやっているもの: n ソースコード静的解析 p やっていないもの: n Botでサイトリンクをたどり404エラー検出(モンキーテスト) n アプリクラッシュ検知(Firebase Crashlytics)

Slide 21

Slide 21 text

ソースコード静的解析 p Python: PyLint p JavaScript: ESLint p nginx: 構文チェック

Slide 22

Slide 22 text

ソースコード静的解析 p PyLint、ESLint n 動的型言語だと、コンパイラ代わりになるので効果的 n 静的型言語だと、書式統一以上のメリットは少ないかも p nginx構文チェック n 構文が間違っているとサーバが起動しなくなるので、チェックは効果的

Slide 23

Slide 23 text

2. 処理が複雑なところ p そもそも複雑すぎて人力では品質を担保できないロジック n テストコードを書きながら開発を進めることが不可欠 p Magic Pod開発でやっているもの: n AIエンジンのUnit Test、Integration Test

Slide 24

Slide 24 text

AIエンジンのUnit Test - UI解析AIのテスト p UI画像とツリーを解析し、操作できる要素をリストアップするAI n 特殊な画面のパターンを多数テスト

Slide 25

Slide 25 text

AIエンジンのUnit Test - 自動修復AIのテスト p テスト対象画面のバージョンアップでテストが失敗しそうになった時に、スクリプト側を自動修正するAI n どんな失敗をどう修正するかのパターンを多数テスト

Slide 26

Slide 26 text

AIエンジンのIntegration Test - 自動修復AIのテスト p 複数のテストで使い回されている要素の修復など p DBを使ったテスト n レコード数を少なくすれば、DBアクセスしても十分高速 p 画面やWeb APIは特に利用しない MySQL テストコード (pytest)

Slide 27

Slide 27 text

3. 重要なところ p 不具合があるとビジネスインパクトが大きいところ p Magic Pod開発でやっているもの: n セキュリティテスト(Integration Test) n 自動テストエンジンのテスト(E2E Test) n 主要な画面のテスト(E2E Test)

Slide 28

Slide 28 text

セキュリティテスト (Integration Test) p ふだん目に見えないので軽視しがちなので注意 p 問題が起きると最悪サービス終了くらいのインパクト p テスト内容は割愛

Slide 29

Slide 29 text

自動テストエンジンのテスト (E2E Test) 自動テストツールが最も避けるべきこと

Slide 30

Slide 30 text

自動テストエンジンのテスト (E2E Test) 自動テストツールが最も避けるべきことテスト対象にバグが無いのにテスト失敗すること

Slide 31

Slide 31 text

自動テストエンジンのテスト (E2E Test) 偽のテスト失敗が続くと… テスト結果をチェックする優先度が下がるテストのエラーが放置されるようになる自動化プロジェクト失敗

Slide 32

Slide 32 text

自動テストエンジンのテスト (E2E Test) p ユーザーが作ったテストがMagic Podのバージョンアップで落ちないことはとても重要 p 対策は、TRIDENT社内で大量のMagic Podテストを流すこと

Slide 33

Slide 33 text

自動テストエンジンのテスト (E2E Test) 各コマンド各ブラウザ・OS 各環境 × × Magic Podクラウドローカル端末

Slide 34

Slide 34 text

自動テストエンジンのテスト (E2E Test) p 各コマンドのテスト(モバイルアプリテスト)

Slide 35

Slide 35 text

自動テストエンジンのテスト (E2E Test) p 各コマンドのテスト(ブラウザテスト)

Slide 36

Slide 36 text

自動テストエンジンのテスト (E2E Test) p ひたすら色々なブラウザ・OS・環境で実行モバイルアプリテスト (On CircleCI) ブラウザテスト (On CircleCI) ブラウザテスト (On AppVeyor)

Slide 37

Slide 37 text

自動テストエンジンのテスト (E2E Test) p テスト結果(iOSアプリテスト)

Slide 38

Slide 38 text

自動テストエンジンのテスト (E2E Test) p テスト結果(ブラウザテスト)

Slide 39

Slide 39 text

自動テストエンジンのテスト (E2E Test) p テストパターンは他にも… p Magic Pod内スケジューラからのテスト実行 p Bitriseからのモバイルアプリテスト実行 p 下位バージョンのクライアントの互換性テスト

Slide 40

Slide 40 text

主要な画面のテスト (E2E Test) p ユーザー登録、テスト作成・編集、有料プラン申込、などなど p Magic PodでMagic Podの画面テストを自動化 n ドッグフーディングにもなる

Slide 41

Slide 41 text

主要な画面のテスト (E2E Test) p Magic PodによるMagic Pod画面のテスト

Slide 42

Slide 42 text

主要な画面のテスト (E2E Test) p Magic PodによるMagic Pod画面のテスト

Slide 43

Slide 43 text

主要な画面のテスト (E2E Test) p Magic PodによるMagic Pod画面のテスト(テスト結果)

Slide 44

Slide 44 text

主要な画面のテスト (E2E Test) p ついでに画像差分チェックも実施(reg-cli) p 正解画像1枚で画面全体の項目とレイアウトがチェックできるので、コスパがいい

Slide 45

Slide 45 text

主要な画面のテスト (E2E Test) p 画像差分チェック(reg-cli)

Slide 46

Slide 46 text

どのテストを自動化するかまとめ 1. 自動化コストが低いところ 2. 処理が複雑なところ 3. 重要なところ AIエンジン静的解析セキュリティ、自動テストエンジン、主要画面

Slide 47

Slide 47 text

1. なぜ今テスト自動化なのか 2. Magic Pod開発の体制 3. Magic Pod開発のテスト自動化 4. Magic Pod開発のCI運用

Slide 48

Slide 48 text

Magic Pod開発のCI運用 p GitHubにプルリクエストを出しながら開発を進める p 変更がコミットされた各タイミングでCircleCIによるビルドを実施 main branch プルリクエストプルリクエスト feature branches

Slide 49

Slide 49 text

プルリクエストをマージする前 p feature branchesでは、高速に終わる「静的解析」「Unit Test」を実施 p コードレビュー前に一定の品質を担保

Slide 50

Slide 50 text

プルリクエストをマージした後 p main branchでは、さらに「Dockerコンテナのビルド」「結合テスト」も実施 p 変更がコミットされるたび

Slide 51

Slide 51 text

E2E Test p 1日 1〜2回実施 p メンバーが増えたら、ここの頻度もあげた方がいいかも

Slide 52

Slide 52 text

1. なぜ今テスト自動化なのか 2. Magic Pod開発の体制 3. Magic Pod開発のテスト自動化 4. Magic Pod開発のCI運用

Slide 53

Slide 53 text

まとめ p テスト自動化により、アジャイル開発・継続的リリースが容易になる p 自動テストツールも自動テストしてます