More Related Content
What's hot (20)
Similar to フ?ラウサ?テスト自动化入门 (20)
フ?ラウサ?テスト自动化入门
- 1. ブラウザテスト自动化入门
- 2. テスト自动化の前に
- 4. テストの自动化とは？
- 6. テスト自动化は简単か？
- 7. テストのコスト 種類 テスト方法 コスパ 項目数 単体テスト CUIテスト ? 多い 機能テスト ブラウザテスト + 手動テスト △ 普通 シナリオテスト ブラウザテスト △ 少ない 非機能テスト 手動テスト X 少ない
- 8. 自动化するメリットは？
- 10. もちろんデメリットもある
- 12. 自动テストの立ち位置
- 14. 自动化でできること?できないこと
- 17. ツールの绍介
- 18. ツール nodejs nightwatchjs(パッケージ) selenium-webdriver(パッケージ) mocha(パッケージ) Selenium Server 各種Web Driver
- 19. クロスブラウザのサーバ构成
- 22. ブラウザ设定
- 25. テストコード作成时のポイント
- 27. 开発时の流れ
- 29. まとめ
- 31. ありがとうございました
Editor's Notes
- #4: テストには大きく分けて4つあります。 単体テストは実装した処理が仕様を満たしているかをコードレベルでテストします。 機能テストはブラウザから操作して、その結果が仕様通りに表示されるか。DBに反映されているか。メールが送られているか。ログは書き込まれているか。などの外部装置との連携を含めたテストをします。 シナリオテストはお客さんとの間で決めた要求をみたしているかをユースケースを使ってテストします。 非機能テストは速度やセキュリティなど、機能に含めていない部分のテストをします。
- #8: 単体テストはCUI上で完結します。ブラウザやDBなどを含まないので動作が軽く、作成方法もシンプルです。項目数は多いですが作成が簡単なのでコスパはいいです。 機能テストはブラウザで確認できる部分はブラウザテスト、メールなどは手動でテストします。HTMLのタグを調べながらテストを作るので単体よりも時間がかかります。項目自体も多いため一番コストがかかる部分です。 シナリオテストは機能テストと同じ内容です。項目数は少ないため作成は割と簡単にできると思います。 非機能テストは人の目での確認になるので自動化はほぼ出来ません。「何秒以内に表示される」のようなテストはシナリオテストなどで自動化は可能です。 これから説明するのは機能テスト、シナリオテストにあるブラウザテストについてです。
- #10: テストから仕様を把握する：テストと仕様は1対1になるように作るので、アジャイル場合はテスト項目の一覧を仕様書代わりにしてたりします。 不具合を恐れずにリファクタリングができる：修正後にテストを回すことによって、不具合が出た場合に確認できるので安心感があります。 クロスブラウザや回帰テストのコストを削減：3回以上同じテストを繰り返す場合は自動化したほうがコストが下がります。 一定の品質を保証：自動テストが通ることで正しく実装されていることを保証できます。
- #12: たまに正常なテストであっても、OSに負荷がかかってブラウザの立ち上がりが遅いなどでエラーになったりします。 要求や機能に変更がなくてもボタンの位置が変更になったり、divタグをpタグに変更するなどでエラーになります。 テストの自動化全般に言えることですが、定期的に実行してメンテナンスしていかないとすぐに使えなくなってしまいます。 テストコード自体がバグっている可能性があります。ほんとは失敗するべきところで成功をかえすなど。 この後、説明しますがテストコード通りにブラウザを操作するために色々と設定が必要になってきます。 単体テストに比べるとブラウザテストは重いです。ですが、手動で行うよりかは速いです。
- #14: 先ほど述べた通り、メリットもあればデメリットもあるため、自动テストさえしていれば大丈夫というわけにはいきません。手动テストをなくすというよりも、手动テストから烦わしい部分をなるべく减らすために行うと考えたほうがいいです。
- #16: スクリーンショットを取ることが可能ですが、贵颈谤别蹿辞虫と颁丑谤辞尘别は画面外の部分は表示されません。テストコード上でスクロールする処理を书く必要があります。
- #17: デザイン崩れなどはスクリーンショットを取って目視で確認する必要があります。 DBやログなどの内容は確認できません。 テスト時に毎回DBを初期の状態に戻す必要があるので、ほかの人がDBをいじる環境ではテストが失敗する可能性があります。
- #19: 今回テストコードを書くためにnodejsを利用しましたが。JAVAやPHP、Rubyなどでも可能です。基本どのツールでも同じことができるのですがnightwatchjsが一番簡潔に書けました。 ローカル環境で実行する場合はSeleniumサーバは必須ではないですが、Macで仮想環境のIEで確認をする場合などに必要になります。 ブラウザごとにWebドライバを公式サイトからダウンロードしてくる必要があります。これがないとテストコードの内容をブラウザに伝えることができません。
- #21: ローカルの场合、笔丑补苍迟辞尘闯蝉という见えないブラウザをインストールすることで简単に环境を作ることができます。もし、颁丑谤辞尘别などでテストしたい场合は、この后に绍介する検証环境のサーバ构成を作ってテストする必要があります。
- #22: クロスブラウザテストの構成です。 仮想環境にChrome、Firefox、IE系をインストールして、各仮想環境とMacにSeleniumサーバを立てて、各Webドライバと連携させています。
- #25: IEの設定が一番煩雑です。また、モダンIEの場合、この煩雑な作業を3か月おきに各バージョンごとに行う必要があります。 phantomjsはCUIで動きます。なので、仮想の開発環境に一緒に入れておくことができるのですが、日本語フォントを入れておかないとスクリーンショットを取ったときに文字化けします。
- #27: ボタンやリンクにIDを振ることで、デザインが変わってもテストコードをなるべく修正する必要がなくなります。 ブラウザテストはコストパフォーマンスが悪いので、単体テストでできる内容までブラウザテストに回すとコストが高くつきます。 一つのテスト項目に複数のテスト結果を含めることができるのですが、エラーになったときに原因の特定が大変になります。項目はなるべく原因を特定しやすい単位まで小さくする必要があります。
- #29: テスト項目作成はテストコードの中身は書かずに項目部分だけをコーディングします。 実装と単体テストを繰り返します。 実装完了後に機能テストとシナリオテストを書きます。 マージリクエスト後にレビュアーは実装とテストコードのレビューをします。 実際にテストコードを動かしてみます。 自身で軽く操作もしてみる。 問題がなければマージします。