tag:crieit.net,2005:https://crieit.net/users/kareyama_r/feed Crieitでユーザーkareyama_rによる最近の投稿 2020-12-05T17:35:35+09:00 https://crieit.net/users/kareyama_r/feed tag:crieit.net,2005:PublicArticle/16263 2020-12-05T17:35:35+09:00 2020-12-05T17:35:35+09:00 https://crieit.net/posts/2020-5fcb4657b3d34 <p>2020/12/5(土)開催「ソフトウェアテスト自動化カンファレンス2020」に参加した記録です。<br /> 聴きながら書いた自分用メモなので、間違っている内容があるかもしれません。</p> <h2 id="CIパイプラインでのテスト戦略とその実現方法"><a href="#CI%E3%83%91%E3%82%A4%E3%83%97%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E6%88%A6%E7%95%A5%E3%81%A8%E3%81%9D%E3%81%AE%E5%AE%9F%E7%8F%BE%E6%96%B9%E6%B3%95">CIパイプラインでのテスト戦略とその実現方法</a></h2> <p>大きなPJではブランチ開発が増えて、Merge時にコンフリクトが発生する。<br /> また、本番環境に行って初めて問題が発覚するケースもある。</p> <p>CI/CDのメリット：<br /> 手作業の自動化だけでなく、継続的にマージ・デプロイを行って常に動作するソフトウェアを維持できる。</p> <h3 id="コミットステージ"><a href="#%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%82%B9%E3%83%86%E3%83%BC%E3%82%B8">コミットステージ</a></h3> <p>開発者がチェックインしたタイミングで実施されるステージ。<br /> ソースコードの解析、ビルド、バイナリのアップを行う。</p> <p>ここで実行されるテストはほぼxUnit系のユニットテスト。</p> <p>失敗率やカバレッジが閾値を超えたら（切ったら）パイプラインを失敗させる！<br /> 閾値は、新しくコミットされたコードに対するカバレッジや重複率を参照して設定すると良い。</p> <h3 id="受け入れステージ"><a href="#%E5%8F%97%E3%81%91%E5%85%A5%E3%82%8C%E3%82%B9%E3%83%86%E3%83%BC%E3%82%B8">受け入れステージ</a></h3> <p>バイナリをステージング環境で検証。<br /> この環境では外接は繋がない。</p> <p>ビジネス視点での試験を行う。<br /> 要件に合っているか、環境や設定でアプリがコケないかを確認。</p> <p>自動テストはシステム用語ではなくビジネスルールで記述したBDDを記述。<br /> これらのテストは開発環境でも実行し、問題を再現できるようにする。</p> <h3 id="テスト戦略"><a href="#%E3%83%86%E3%82%B9%E3%83%88%E6%88%A6%E7%95%A5">テスト戦略</a></h3> <p>アジャイルテストの４象限・テストピラミッドを用いて自動化を検討する</p> <p><a href="https://crieit.now.sh/upload_images/f3a8970cc390433bcc81301c9b59971a5fcb09d6a4f04.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/f3a8970cc390433bcc81301c9b59971a5fcb09d6a4f04.png?mw=700" alt="image.png" /></a></p> <ul> <li>コミットステージでは主にQ1。特に境界値試験など多くのパターンが発生するテストは重要。</li> <li>受け入れステージではQ2～Q3。</li> </ul> <h3 id="テストアワーグラス"><a href="#%E3%83%86%E3%82%B9%E3%83%88%E3%82%A2%E3%83%AF%E3%83%BC%E3%82%B0%E3%83%A9%E3%82%B9">テストアワーグラス</a></h3> <p>ITを減らしてSTを増やそうという動き。<br /> IT＞＞STになると機能の目的がつかめなくなり、仕様変更に対応しずらい。<br /> EtoE自動化・実行環境整備の技術が発展したことも後押ししている。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>CI/CDが重要なのは各所で言われているし、やってもいるけれど、現場ではテストのメンテナンスやフェーズの切り替えがなぁなぁになってしまうケースもあるので、閾値を設定して開発者にテストのメンテナンスを強制したり、４象限で試験内容を整理して維持管理していくことが重要そうです。</p> <h2 id="&quot;全部乗せ&quot; フレームワーク CodeceptJS でE2Eテストを楽にしよう"><a href="#%26quot%3B%E5%85%A8%E9%83%A8%E4%B9%97%E3%81%9B%26quot%3B+%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF+CodeceptJS+%E3%81%A7E2E%E3%83%86%E3%82%B9%E3%83%88%E3%82%92%E6%A5%BD%E3%81%AB%E3%81%97%E3%82%88%E3%81%86">"全部乗せ" フレームワーク CodeceptJS でE2Eテストを楽にしよう</a></h2> <p>WebアプリのE2Eテストではクロスブラウザ対応や、<br /> メーラーやダウンロードしたファイルなど、ブラウザ以外のチェックが必要なこともある。</p> <p>色々なユースケースに対応したCodeceptJSの紹介。</p> <h3 id="できること"><a href="#%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%93%E3%81%A8">できること</a></h3> <ul> <li>データドリブンに対応、アサーション時にデータの参照も可能。</li> <li>オートログイン <ul> <li>Cookieがあってログインされていればそのまま、画面を判定してログアウト状態ならばログイン処理を行う</li> </ul></li> <li>メールのチェック</li> <li>表示待機時の自動リトライ</li> </ul> <p>（Ask Speakerで聞いた話）<br /> - レポートはAllureというフレームワークを利用している<br /> - テストの実行結果の統計を取って、Flakyなテストにはアイコンを付けてくれる！</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>以前CodeceptJSについて聞いた時にはSelenideで十分では？という感想でしたが、<br /> メールのチェックなどただのブラウザ操作フレームワークではカバーできない部分まで実装できると聞いて興味が湧いてきました。<br /> レポートも良さげ。<br /> JSちゃんと書いたことないので、この機会に勉強します。。</p> <h2 id="テスト自動化ツールで考えるモデルベースドテスト"><a href="#%E3%83%86%E3%82%B9%E3%83%88%E8%87%AA%E5%8B%95%E5%8C%96%E3%83%84%E3%83%BC%E3%83%AB%E3%81%A7%E8%80%83%E3%81%88%E3%82%8B%E3%83%A2%E3%83%87%E3%83%AB%E3%83%99%E3%83%BC%E3%82%B9%E3%83%89%E3%83%86%E3%82%B9%E3%83%88">テスト自動化ツールで考えるモデルベースドテスト</a></h2> <p>（このセッションは上手くまとめられなかったので、後日資料公開されたら再編集します）</p> <p>自動化以前にテストをモデリングしていないと効果的なテストができない（目的不明・非効率・実現不能…etcなテストができる）。<br /> 関係者とのコミュニケーションツールとしても有効。</p> <h3 id="モデルベースドテストとは"><a href="#%E3%83%A2%E3%83%87%E3%83%AB%E3%83%99%E3%83%BC%E3%82%B9%E3%83%89%E3%83%86%E3%82%B9%E3%83%88%E3%81%A8%E3%81%AF">モデルベースドテストとは</a></h3> <p>テスト設計モデルを用いてテストケースを設計する。<br /> モデルはテスト対象やテスト目的を議論しやすくするためのもの。</p> <p>モデルの例：人のアクティビティ、状態遷移、構造<br /> 状態遷移図やフローチャート、ユースケース図、ツリー（マインドマップ）を使って表現する。</p> <p>手順<br /> ①モデリング<br /> テスト対象のワークフローや同値クラス、テストの値</p> <p>②テストの選択<br /> テスト目的に沿ったテストを選択する。<br /> 要件、モデル要素、データカバレッジ、シナリオベース…etc.</p> <h3 id="注意点"><a href="#%E6%B3%A8%E6%84%8F%E7%82%B9">注意点</a></h3> <p>テスト目的を満たすか粒度を確認しながら作ること<br /> ▼アンチパターン<br /> - 何でもかんでも一つの図に書いてしまう<br /> - ざっくりしすぎor詳細すぎる</p> <h3 id="テストの要件と紐づける"><a href="#%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E8%A6%81%E4%BB%B6%E3%81%A8%E7%B4%90%E3%81%A5%E3%81%91%E3%82%8B">テストの要件と紐づける</a></h3> <ul> <li>確認したいことをリストアップしてモデル作成する</li> <li>要件↔テストのトレーサビリティを記録する</li> </ul> <h3 id="Eggplant"><a href="#Eggplant">Eggplant</a></h3> <p>モデルからテストケース自動選択・生成、自動実行を行える。</p> <h2 id="E2Eのリトライを少し賢くして、落ちにくくしてみた"><a href="#E2E%E3%81%AE%E3%83%AA%E3%83%88%E3%83%A9%E3%82%A4%E3%82%92%E5%B0%91%E3%81%97%E8%B3%A2%E3%81%8F%E3%81%97%E3%81%A6%E3%80%81%E8%90%BD%E3%81%A1%E3%81%AB%E3%81%8F%E3%81%8F%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F">E2Eのリトライを少し賢くして、落ちにくくしてみた</a></h2> <p>画面遷移・リグレッションテストをクロスブラウザで自動実行している。<br /> テストデータはExcelからyamlに変更した。Diffを取りやすくなる。</p> <h3 id="リトライ"><a href="#%E3%83%AA%E3%83%88%E3%83%A9%E3%82%A4">リトライ</a></h3> <p>操作のリトライ＋テストのリトライを実施する。</p> <p>テストごと再実行すると失敗率が上がるため、操作の再実行がメイン。<br /> 画面Elementの取得に失敗したら一定間隔待って再度Getする。</p> <p>Elementの存在確認をリトライするだけで実現できている。<br /> Sleepなどは使用していない。</p> <p>テストのリトライについて。<br /> Exceptionをキャッチしたら一定時間スリープし、テストごと再実行する。<br /> ただし、再起不可能なエラーが発生した場合は即座に終了する。</p> <h3 id="次の課題"><a href="#%E6%AC%A1%E3%81%AE%E8%AA%B2%E9%A1%8C">次の課題</a></h3> <p>AWS上に乗せてスケールアウト、テストの並列実行を実現したい。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>操作リトライについては最近は自動化フレームワークが充実していて意識しなくても実行できてしまいますが、エラー内容によってテスト事実行・強制終了といったハンドリングをきちんと行っているのが良いなと思いました。<br /> 全部最初から作ると大変なので、うまくフレームワークと組み合わせて判定できるように作りたい。</p> <h2 id="reg-suitとQA Wolfを活用したVisual Regression Test"><a href="#reg-suit%E3%81%A8QA+Wolf%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%97%E3%81%9FVisual+Regression+Test">reg-suitとQA Wolfを活用したVisual Regression Test</a></h2> <p>暗黙で目視確認しているところも自動テストにしたい。<br /> →Visual Regression Test</p> <p>修正前後を画像比較して同じならテストOKになる仕組み<br /> いくつかのツールを試してみた<br /> - Visual Regression Test：画像取得の方法が独特で難しい<br /> - Desemble.js：結果を目視チェックできない<br /> →reg-suitを採用</p> <h3 id="reg-suit"><a href="#reg-suit">reg-suit</a></h3> <p>画像を比較するだけのシンプルなツール</p> <p>比較結果を重ねたり並べたりしたレポートを出してくれる。<br /> （便利だ…！）</p> <p>期待値・実際の画像の配置などはプラグイン機能で実現できる。</p> <h3 id="QA Wolf"><a href="#QA+Wolf">QA Wolf</a></h3> <p>ブラウザ操作のリプレイキャプチャ。（コードの保守性は高くない…）<br /> Playwright・Jestが組み込まれている。<br /> →ブラウザ操作とスクショの取得を実施。</p> <h3 id="運用"><a href="#%E9%81%8B%E7%94%A8">運用</a></h3> <p>Unit Testと同様にCIで実行し、この実行結果の確認も開発者の責務とした。<br /> 公式Dockerは日本語フォントが含まれていないので注意！</p> <p>良かったこと：画面キャプチャがあることで、レビューア・QAにも変更内容が直感的に理解できる。<br /> 大変だったこと：CIに乗せるためのインフラ整備。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>画像の重ね合わせは、スクリーンサイズとかでブレが発生するので運用が大変なイメージがありますが、<br /> Dockerなどで均一な試験環境をちゃんと用意したうえで、ある程度のブレはレポートの方を見やすくして、レポート確認の時にこれはOKな差分・これは意図しない差分、とサクサク確認できるように運用を工夫するのが良いのかなと。</p> <h2 id="総括"><a href="#%E7%B7%8F%E6%8B%AC">総括</a></h2> <p>自動テストについて、E2Eだけでなく設計やCIなど色んな観点から話が聞けてとても楽しかったです！<br /> 聞けなかったセッションにも興味深いタイトルが多いので、資料を読んだら追記します。</p> kareyama_r tag:crieit.net,2005:PublicArticle/16239 2020-11-26T18:36:53+09:00 2020-11-26T18:36:53+09:00 https://crieit.net/posts/LINE-DEVELOPER-DAY <p>「LINE DEVELOPER DAY 2020」２日目に参加しました。<br /> 聞いたセッションのメモ書き程度の投稿です。<br /> 知識不足や聞き落としで間違ったことを書いているかもしれないので悪しからず。</p> <h2 id="Kubernetesを用いたPull Request駆動E2Eテスト"><a href="#Kubernetes%E3%82%92%E7%94%A8%E3%81%84%E3%81%9FPull+Request%E9%A7%86%E5%8B%95E2E%E3%83%86%E3%82%B9%E3%83%88">Kubernetesを用いたPull Request駆動E2Eテスト</a></h2> <p>同時に同じ機能に修正が入ると、E2Eテストがコケる。<br /> サーバにデプロイしないとE2Eテストを実行できないので開発者へのフィードバックが遅い。</p> <p>k8sを使ってE2Eのテストをユニットテストと同レベルで実行できるようにした話。</p> <h3 id="SETとは"><a href="#SET%E3%81%A8%E3%81%AF">SETとは</a></h3> <p>Software Engineer in Test<br /> 自動テストに関わるフレームワークやパッケージを組み立てるのがメイン業務。<br /> E2Eだけではない<br /> DX（Developer eXperience）を高めて、その結果として製品の品質を高めることが目的。</p> <p>Test Automation Engineerが製品品質をメイン目的にするため、役割として住み分けされている。</p> <h3 id="k8s活用"><a href="#k8s%E6%B4%BB%E7%94%A8">k8s活用</a></h3> <p>E2Eテスト実行にはアプリのサーバデプロイまで必要。<br /> ならばプルリクを起点にk8s上にサーバを構築してしまう。<br /> プルリクごとに独立したNameSpaceが立ち上がるため、他の変更やテスト実行に影響されない。</p> <p>実施した結果、元々の課題改善だけでなく、レビューにも効果が！<br /> ローカルで立ち上げて実行していると、ローカル環境でしか再現しない問題が出た時、フィードバックしずらい。<br /> k8s環境に移したら、そこで再現して見せられるのが良い。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>自分がk8s初心者なのとスピーカーのテンポが早めだったので、付いていけない部分が多かった。<br /> かなり凄いことを実現しているので、資料が公開されたら改めて確認したい。<br /> 以前は色んな構築や課題が発生していた試験環境準備が、DevOpsとコンテナ技術の発展でどんどん進化しているなーと思いました。</p> <h2 id="LINEのテスト自動化システムがどのように動いているのか"><a href="#LINE%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E8%87%AA%E5%8B%95%E5%8C%96%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%8C%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E5%8B%95%E3%81%84%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%8B">LINEのテスト自動化システムがどのように動いているのか</a></h2> <h3 id="ドキュメンテーション"><a href="#%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3">ドキュメンテーション</a></h3> <p>テスト自動化においてもドキュメンテーションは重要。</p> <p>Page Objec Patternを採用しているので、スクリーンごとにページを作成し、<br /> スクリーンショット、プロパティ（ページの要素）、アクション（イベント）をまとめている。</p> <p>このページはMarkdownで書いて簡単にデプロイできる。</p> <h3 id="モニタリング"><a href="#%E3%83%A2%E3%83%8B%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0">モニタリング</a></h3> <p>LINEには世界中に開発のためのハードウェアがある。<br /> サーバの故障や不具合で試験が失敗した時、監視できるよう、<br /> ElasticserchにFilebeatとMetricbeatでデータを収集して、Grafanaでダッシュボード表示している。</p> <h3 id="レポーティング"><a href="#%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0">レポーティング</a></h3> <p>様々なLINEサービスのテスト結果をどうまとめるか。<br /> eggplantやappiumのデータをElasticsearchに収集し、Pythonでデータを成型、Veu.jsでWebに表示している。</p> <h3 id="Bot"><a href="#Bot">Bot</a></h3> <p>LINEとSlackを利用している。<br /> コミュニケーションツールだけでなく自動ツールの通知にも活用している。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>ドキュメンテーションはアジャイル開発だといかに手軽に必要十分な情報をまとめていくかが重要になるので、<br /> フレームワークを作って更新していっているのは魅力的だなーと感じました。</p> <h2 id="The CI/CD Automation make happiness from small pieces"><a href="#The+CI%2FCD+Automation+make+happiness+from+small+pieces">The CI/CD Automation make happiness from small pieces</a></h2> <h3 id="リリース自動化"><a href="#%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E8%87%AA%E5%8B%95%E5%8C%96">リリース自動化</a></h3> <p>リリースと言えば、デプロイを行い、問題なければリリースステータスが更新され、Gitタグが切られ、リソースを収集、マーケットにアーティファクトがアップロードされればリリース…と多くのタスクがあり、抜けが発生しやすく、また各フローが終了するまでチームが緊張状態になっていた。</p> <p>そこで自動化を進めた。</p> <p>ネットワークが遮断されている環境でもリリースステータスを取得できる仕組みを作り、リリース結果がフィードバックされるようになった。<br /> これによって、CIタスクを増やしても実施が漏れない・負担が増えない環境になった。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>扱っている内容自体はCI/CDを地道にやったよ！という話なので、もう少し突っ込んで実現時に直面した課題とその対処策を聞きたかったなと。</p> <h2 id="How to quickly develop static pages in LINE"><a href="#How+to+quickly+develop+static+pages+in+LINE">How to quickly develop static pages in LINE</a></h2> <p>静的コンテンツを1日で開発・デプロイできるようになった話。</p> <p>動的コンテンツはキャッシュ利用やサーバ間通信など考えることが多く、重くなりがちなため、静的ページへのニーズが増えている。<br /> そこで、多くのページを作るためのリソース不足が課題となった。<br /> 静的コンテンツ作成には具体的に以下のようなタスクが発生する。<br /> - デザイン<br /> - JavaScriptコーディング<br /> - Minify（難読化）<br /> - 多言語化<br /> - Webサーバへのデプロイ<br /> - ドメイン設定</p> <p>→多くは繰り返し作業なので、自動化できるのでは？と考えた。</p> <h3 id="共通作業の自動化"><a href="#%E5%85%B1%E9%80%9A%E4%BD%9C%E6%A5%AD%E3%81%AE%E8%87%AA%E5%8B%95%E5%8C%96">共通作業の自動化</a></h3> <p>Node.jsでCLIツールを作成し、init, dev, build, deployといったコマンドで実行できるようにした。<br /> が、ビルド時に開発者のローカル環境の影響を受けることが問題になったので、<br /> Web画面（Dashboard）からGitHubのレポジトリを参照できるように変更した。</p> <h3 id="コンテンツ作成"><a href="#%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E4%BD%9C%E6%88%90">コンテンツ作成</a></h3> <p>コンテンツ作成はサービスごとに異なり、共通化が難しい。<br /> →JAMStackを利用することにした。<br /> - JavaScript<br /> - APIs<br /> - Markup</p> <p>Headless CMSをDockerコンテナ上に立て、Dashboard画面からGUI画面を呼び出せるようにした。<br /> これにより、コンテンツ作成・更新時にエンジニアがソースコードを操作する必要がなくなった。<br /> さらに画面コンポーネントを定義しておき、コンテンツ作成を素早く行えるようにした。</p> <h3 id="感想"><a href="#%E6%84%9F%E6%83%B3">感想</a></h3> <p>色んなサービスを扱っているLINEだからこそ独自フレームワーク化・自動化が生きるのかなと思った。<br /> MkDocsなど、単純なページを生成するフレームワークは既にあるので、それをパイプラインに乗せるだけで手軽に静的コンテンツの自動更新はできる。<br /> が、サービスごとに凝ったコンテンツを作りたければ、このようなビルドが必要になるのだなと。</p> <h2 id="総括"><a href="#%E7%B7%8F%E6%8B%AC">総括</a></h2> <p>LINE DEVELOPER DAY初参加でしたが、予め登録していたセッションが近づくとLINEに通知されたり、ライブ画面の横でLINEスタンプ風のリアクションが送れたり、LINEさんならではの意匠がこらされていて面白かったです。<br /> セッション内容としては、10～20分の短いセッションも多く、ちょっと駆け足な印象も否めず。<br /> もう少しじっくり聞きたかったなーと思います。<br /> 次回予告が出ているセッションもあるので、続報を待ちます。</p> <p>本日は参加させていただき、ありがとうございました！</p> kareyama_r