Slide 1

Slide 1 text

AI as a Tester AIによる開発支援 勉強会 in 奈良 Yasuyuki Higa @yh65743

Slide 2

Slide 2 text

自己紹介 名前: 比嘉 康至(ひが やすゆき) X(旧Twitter): @yh65743 勤務先: 株式会社ことば研究所 居住地: 奈良(フルリモートで勤務しています) ❏ PHP ❏ React ❏ TypeScript 普段はこのあたりを使ってWebアプリケーション開発/保守やってます

Slide 3

Slide 3 text

面倒なことは AIにやらせたい ソフトウェアエンジニアにとって面倒なこと それはテストである

Slide 4

Slide 4 text

AIを使わなくても自動化できるテスト describe('add function', () => { test('adds 1 + 2 to equal 3', () => { expect(add(1, 2)).toBe(3); }); test('adds 0 + 0 to equal 0', () => { expect(add(0, 0)).toBe(0); }); }); こういうシンプルな関数に対してならテスト コードをよく書く(書いてない)

Slide 5

Slide 5 text

UIのテストは自動化しづらい Selenium や Puppeteer で頑張ってテストコードを書くけど ● 遅い ● 壊れやすい ● 結局不具合を検知できない

Slide 6

Slide 6 text

// Googleのホームページを開く await driver.get('https://www.google.com'); // 検索ボックスを見つけて検索語を入力 let searchBox = await driver.findElement(By.name('q')); await searchBox.sendKeys('Selenium testing', Key.RETURN); await driver.wait(until.titleContains('Selenium testing'), 5000); // 検索結果のタイトルを取得 let firstResult = await driver.findElement(By.css('h3')); let resultText = await firstResult.getText(); console.log(`最初の検索結果: ${resultText}`); // タイトルに"Selenium"が含まれているか確認 let title = await driver.getTitle(); assert(title.includes('Selenium'), 'Seleniumが検索結果のタイトルに含まれていません '); リクエストを送る ので遅い セレクタが壊れや すい 一部要素を比較でき るだけ

Slide 7

Slide 7 text

UIのテストは自動化しづらい こういう表示の崩れは検知 できなかったりする。。。 ー> そこで AI 活用、、、 の前に Visual Regression Test を 紹介

Slide 8

Slide 8 text

Visual Regression Test 既存のUIに予期せぬ変更がないかチェックするためのテスト手法 UIのスナップショットを撮っておき、テスト実行時に以前撮ったスナップショットと差分が 出ていたらアサーションで引っかかるようにする。

Slide 9

Slide 9 text

Visual Regression Test

Slide 10

Slide 10 text

Visual Regression Test

Slide 11

Slide 11 text

Visual Regression Test

Slide 12

Slide 12 text

VRTのつらみ ● 動的に値が変わる箇所等も差分として検知されてしまう -> 特定の要素を指定して マスキングすることもできるが、その要素を指定するためのセレクタが壊れやすい ● ピクセル単位でスクショを比較するので、ちょっとしたずれでも差分検知され、本当 に壊れている箇所がどこなのかわかりにくい

Slide 13

Slide 13 text

VRTのつらみ ● 動的に値が変わる箇所等も差分として検知されてしまう -> 特定の要素を指定して マスキングすることもできるが、その要素を指定するためのセレクタが壊れやすい ● ピクセル単位でスクショを比較するので、ちょっとしたずれでも差分検知され、本当 に壊れている箇所がどこなのかわかりにくい -> これを AI でなんとか出来ないか ?

Slide 14

Slide 14 text

AI を取り入れたテスト用 SaaS の紹介 E2E テスト用 SaaS には AI を取り込んでこの類の問題の解決を目指すものが多々あ る。 applitools, MagicPod, mabl, TestSigma, Autify 等。。。 どれもやってることは割と似通っているので今回は代表として applitools を紹介

Slide 15

Slide 15 text

applitools ● AIを活用した包括的なソフトウェアテスト自動化プラットフォーム ● ビジュアルテストに特化 ● VRTテストの際の差分判定、テストメンテナンスの自動化

Slide 16

Slide 16 text

AIによるVRT 差分検出 今回はAIによる差分検出機能の検証のために相応しいWebサイトを用意しました

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

まずは普通に VRT

Slide 19

Slide 19 text

まずは普通に VRT 今日の日付と訪問者数が差分として検出されていることがわかります ちなみにマーキーが側にあると差分検出アルゴリズムがそちらに気を取られて他の差分を 一切無視するため一旦マスクしてあります

Slide 20

Slide 20 text

applitools による差分検出 applitoolsでは差分検出する方法と程度を次の中から選べる ● Exact : ピクセルレベルの完全一致 ● Dynamic : 日付、番号、URLのような特定パターンの動的値の変化を無視してくれる ● Ignore colors : 色を無視 ● Layout : 値を無視してレイアウトのみ比較 ● Strict : 人間の目で見たときの差分のみ検出(デフォルト) 今回は Dynamic を選択

Slide 21

Slide 21 text

applitools による差分検出

Slide 22

Slide 22 text

Self-healing ● テスト時に要素を指定する際のセレクタに変更があっても、AIが自動で判定して変 更に追随してくれる機能、らしい ● feature request しないと使えない機能のようで残念ながら検証できませんで した

Slide 23

Slide 23 text

AIさんもうちょっと色々できません ? ● ここまで紹介してきたのはあくまでAIによる「お手伝い」機能 ● それはそれで便利だけどやはりAIには人の「目」と「手」を完全に代替してほしい expect(ai('表示が崩れていない')).toBe(true) ● ↑みたいな抽象的なアサーションをAIにやってほしい ● 個人的には、ダークテーマに切り替えたときに見辛くないかの検証をAIにやって ほしい。

Slide 24

Slide 24 text

Auto Playwright ● AIにより自然言語によるアクション、クエリ、アサーションを可能に test("auto Playwright example", async ({ page }) => { await page.goto("/"); const headerText = await auto("get the header text", { page, test }); await auto(`Type "${headerText}" in the search box`, { page, test }); const searchInputHasHeaderText = await auto( `Is the contents of the search box equal to "${headerText}"?`, { page, test } ); expect(searchInputHasHeaderText).toBe(true); });

Slide 25

Slide 25 text

Auto Playwright 検証のため抽象的なアサーションを与えてみた const notDistorted = await auto( 'The display is not distorted',aiArgs) expect(notDistorted).toBe(true) 結論から言うとダメでした

Slide 26

Slide 26 text

Auto Playwright ● 人間が見ると明らかに表示崩れしていても true と判定される ● 「枠から商品名がはみ出していない」のような多少具体的なアサーションにすると今 度は回答できずにエラーになる

Slide 27

Slide 27 text

Auto Playwright の実装を見てみる ● Auto Playwright の実装を見ると OpenAI API の Function Calling という機能を 利用し、テスト対象の DOM 丸ごと全部と DOM 操作に必要なツール(要素をクリッ クする、チェックする、テキストをインプットする、idから要素のテキストを取得する、 など)を渡している。つまり、 「 君のタスクは ”表示が崩れていないか”だよ。 これがテスト対象のHTMLです。必 要なら君はこれらのツールを使うことができるので、使いたいならツールを使う上で 必要なパラメータを伝えてね」 というような事を指示しているようなもの。

Slide 28

Slide 28 text

AI はテスターの「目」になれるか ● この実装だと、AIはあくまで HTML というマークアップテキストから得られた情報を もとに判定しているだけなので「表示崩れ」のような視覚的情報は間接的にしか得 られていない ● ページのスクリーンショットをもとに直接的視覚情報から判断できるならもっと抽象 的タスクをこなせるのでは?

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

AI にスクショを見せて検証 ● AI が使えるツールに “takeScreenshot” を追加 takeScreenshot: { function: async () => { const buffer = await page.screenshot(); return { screenshot: buffer.toString("base64") }; }, name: "takeScreenshot", description: "Takes a screenshot of the current page and returns it as a base64 string.", …… },

Slide 31

Slide 31 text

AI にスクショを見せて検証 ● 指示文を色々と変更 そのままだとスクショを使ってくれないので「スクリーンショット を撮って表示が崩れていないか確認して」などとしておく。 ● がっ……駄目っ……! ● やはり回答できなかったり異常検知できなかったり ● 表示が崩れていないかの問いに「提供されたスナップショットにはレイアウトの問題 はなさそうです。すべてのテキストがそれぞれの要素内に適切に収まっているよう に見えます。」と返してきたこともあった ● Function Calling というフレームワークが悪さをしているのか、それとも base64 encoding された画像をうまく認識できていない?

Slide 32

Slide 32 text

プロセスやツールより対話(誤用) Function Calling をやめて直接聞いてみる Q. 「この画像は表示崩れしていますか?」 A. 「画像は歪んでいないようで、鮮明で3つのセクションに分かれており、それぞれに 製品(スマートフォン、ノートパソコン、イヤホン)とそれに対応するテキストの説明が 表示されている。」 うーむ。 ん? もしかして画像そのものが壊れてないかどうかって問いだと思っている?

Slide 33

Slide 33 text

プロセスやツールより対話(誤用) Q. 「この画像はとあるWebサイトのスクリーンショットだけど、このサイト表示崩れして る?」 A. 「はい、このウェブサイトの表示は崩れているようです。ヘッダーのテキストが重なり 合って指定領域を超えており、読みにくくなっています。各商品の説明は正しく表示 されているようですが、重なりを防ぐためにヘッダーのレイアウトを調整する必要が あります。」 いけた!

Slide 34

Slide 34 text

ダークモードの判定 Q. 「この画像はとあるwebサイトのダークモード時のスク リーンショットですが、このサイトは見づらいですか?」 A. 「はい、ウェブサイトのテキストは暗い背景に対して コントラストが低いため読みにくいです。明るさを上 げるか、より明るいテキスト色を選択すると、読みや すさが向上する可能性があります。」

Slide 35

Slide 35 text

AIツールを使ってみてわかった問題点 ● 日本語だと日付扱いされてくれなかった ● 等幅フォントでないと、数字の変化に伴い微妙に要素の幅などが違ってくるのでそ れが差分として検出される場合がある ● やっぱりマーキーには弱かったです ● しょうがないが、やはり遅い ● 画像のトークン数が重たく、複数ブラウザを同時検証しようとすると一分あたりの レートリミットに引っかかることも。

Slide 36

Slide 36 text

まとめ ● 正直、AIにテストさせるよりAI様が書いたコードを人間がテストするほうが楽 ● とはいえモデルそのものの性能というよりはツールとしての洗練の方がボトルネッ クになっている感じがするので研究していきたい ● CI/CD からリリースやコミットごとにテストという使い方はしにくいが、裏で非同期/定 期で動かしておいて異常検知してもらうというのはありでは

Slide 37

Slide 37 text

オチ