The Way of the Web Tester を読んでみました。 私が読んだ時は、まだBeta3でした。最近、Beta4が出て、JSによるテストコードの話が追加されている状態でした。 この書籍は、自動化されたテストを書くための、テストエンジニア向けの入門書という感じです。内容はいかが大まかなところです。 Unit/Integration/UIのテストピラミッドの話 Unit/Integration/UIのテストコードの書き方(Rubyを例に) コラムとして、例えばrecord/playbackの使えないところ、など 全般的にWebだけの言及なので、モバイルに関しては対象外でした。Selenium系の書籍のようにツールに特筆してはいないので、そういう意味では確かに全般的な入門書という感じです。 ただ、コードの書き方などの話になるとリーダブルコードの内容や実装に近いところの話が含まれてきていたので、そこらへんの実装よりを詳しく学びたいとなったら何かWebフレームワークを使った実装とそのテストコードを書く、というところを開発者向けのなんらかの書籍など見て行う方が良いかもしれないです。 ある程度、書籍などで学んでいたり実装を経験した人からすると確かに入門的なものなのでザーッと読み飛ばしながらコラム中心に読んで終わり、となりそうです。More
Tag Archives: softwaretest
reading “Advanced Software Testing – Vol. 3”
ISTQBのTTA(Technical Test Analyst)がどのようなことを学んでいるのか、を知るために読んでみました。 Advanced Software Testing – Vol. 3, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst ざっというと、様々なソフトウェアに関するメトリスクやその計測方法、カバレッジの話、さらにはテスト自動化に関する話までありました。 内容として、これはゆるSoftware Engineer in Testと呼ばれるような位置の人は頭に入れておくべき事柄、という感じでしょうか。 data driven や keyword driven なテストコードの話とか、静的/動的テストの分け方やその詳細への落とし込み、様々なコードカバレッジの定義やその役割など。 中でも、コードカバレッジをはじめとした様々なカバレッジ(それこそ、変更量とか含む)の厚みはすごくページを割いていて、その計算(アルゴリズム)の理解までこの書籍でできる感じです。 ただ、これだけできても十分ではなく、ここと実際の経験(開発など)が合わさって相乗効果を発揮する、という感じでしょうか。 効率性のテストの中で、以下のように数多くの xx testingという呼び名があったことは今回初めて気付きました… Load Testing Stress Testing Scalability Testing Resource utilization Testing Endurance or soak Testing Spike Testing Reliability…More
minimal ruby client for WebDriverAgent
WebDriverAgent developed by Facebook is one of WebDriver tool which run on iOS. Previous some posts, I investigated this module. And now, I develop minimal wrapper Ruby cli client to help some operations. https://github.com/KazuCocoa/wda_client I implemented some operations such as taking screenshots, getting source tree, status about the driver and install arbitrary app to the…More
memos ISSTA2016 for me
Site URL: https://issta2016.cispa.saarland/ Probabilistic Learning from Big Code / https://t.co/fnYjMG6VI6 — KazuCocoa (@Kazu_cocoa) July 24, 2016 Machine Learning for Programming とかしている人なんだ。 / https://t.co/OXfMFR8Iyx — KazuCocoa (@Kazu_cocoa) July 24, 2016 Cyber-Physical Systemsに対するコスト効率の良い手法を探して / Testing Dynamic Behaviour in Executable Software Model / https://t.co/9D84wXhj7N — KazuCocoa (@Kazu_cocoa) July 24, 2016 a search-based testing approachとな。initial desiredとfinal desiredを定義して、そのコストの最悪ケースを算出してシナリオを組み立てると。 — KazuCocoa…More
テスト計画とか(from GoogleTestingBlog)
Google Testing Blogの The Inquiry Method for Test Planning がちょうどまとめようとしていたことに重なっていたので、メモ。 ここでは大雑把なことしか書かないので、内容はGoogleのブログを読む、が良さそう。 test plan(テスト計画)の作成に関してです。 多くのソフトウェア開発においてテストを行う場合、実装コスト(implementation cost)、保守コスト(maintenance cost)、お金(monetary)、利益(benefit)、リスク(risk)を考える必要がありますね。 Test Plan vs Strategy この記事では、1つのテスト計画と、それらが多く集まってまとまったテスト設計、という関係性でテスト計画を定義しています。そして、その計画はだいたいがプロジェクトに依存する形です。 テスト計画必要？といった話も少しありますが、そこは置いておいて… リスク、カバレッジ、ツール、プロセス、ユーティリティという感じで内容は大別されてまとまっています。 リスク リスクドベーステストなどを行う場合、リスクの把握が大事です。例えば、データの欠損など。また、技術的な負債がどのくらいあるかとか、そういう技術的なところも大事。 カバレッジ ここでいうカバレッジはC0といった実装に閉じた話ではなく、もっと大きな枠でテストをどのくらいしているか？という指標です。S/M/L/Eのようなサイズ別のテストのそれぞれでどのくらいカバレッジがあるかとか、どのくらいmanual testingしたかとか。 ツール 環境整備やツールの用意などの話。 プロセス どのタイミングでテストを実施するかとか、バグレポート、市場に出た時にどうするかといった、リリースに関わるプロセス全般を考えるために。 Utility 誰がこのテスト結果を読むのか、とか。 締め 計画なので、ざっとしたまとまりな感じでした。ただ、こういった話はどこにでもあるわけではないので、ざっと読んでおくと良さそう。More
[iOS]EarlGreyを使ってシナリオを記述する
過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。 対象のproject: https://github.com/KazuCocoa/MyGithubSearch 対応コミット: https://github.com/KazuCocoa/MyGithubSearch/commit/bd83bf8668260978ec6941bd8c003470c9443167 幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。 EarlGreyについて EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。 リポジトリはこちら。 https://github.com/google/EarlGrey EarlGrey自体の説明はあるのでここでは書きません。 セットアップ、導入 https://github.com/google/EarlGrey/blob/master/docs/install-and-run.md Swiftサンプル https://github.com/google/EarlGrey/blob/master/Demo/EarlGreyExample/EarlGreyExampleSwiftTests/EarlGrey.swift 何か困った時 使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。 APIドキュメント https://github.com/google/EarlGrey/blob/1.0.0/docs/api.md Matcherの実装 – どのように動作しているか、といった説明も書かれているので、ざっと一読することをお勧めします – https://github.com/google/EarlGrey/blob/master/EarlGrey/Matcher/GREYMatchers.h – AccessibilytLabelやidentifierの他にも、Valueなど多くの要素が使えるのよいですね – ただ、 We strongly recommend using an accessibility identifier as it uniquely identifies an element. と書かれているように、やぱり accessibilityIdentifier を使うことが良いことには変わりなさそう。ここは激しく同意。 Other Tips 要素を見つけたい時 シミュレータだと、AccessibilityのAccessibility Inspectorを有効にしてそれを使うと良いです…More
[Elixir]concurrent integration test with Hound and handle it with tag
雑にしか書きませんが、Phoenixのcontrollerのテストでは、あるURLへの操作に対する結果のチェックにはstatus codeが何か、そのtitle要素は何かといった簡単なHTML要素をみます。そこは静的な要素をチェックできるのですが、画面の遷移が絡んでくるとintegration testと呼ばれる段階のテストを用意する必要があります。 Elixirでは、その手のツールに以下の2つがあります。 Hound Wallaby Wallabyのほうが後発です。これはconcurrentなテストを主眼に開発されているようです。ただ、対応ブラウザがPhantomJSだけだったので、私はHoundを選びました。 そして、concurrent integration testを行うにはphoenix_ecto3.0 + Ecto 2.0を使う必要があります。これは、Ecto2.0から入ったownership制のsandbox環境を使い、concurrentなテストを実行する必要があるためです。 ※Ectoのこのownership制の話とか気になる人はこちらを読むと良いと思います。コード 設定 以下の設定説明を参考にすると、基本的なところは完了。サクッと実行できます。なのでここではリンクだけ… https://github.com/phoenixframework/phoenix_ecto#concurrent-acceptance-tests https://github.com/phoenixframework/phoenix_ecto#hound 私はfirefoxとWebDriverのstandaloneを使ってサクッと実行しました。 WebDriverはこちらからダウンドード可能です=> https://selenium-release.storage.googleapis.com/index.html tips 通常、この手のintegration testはブラウザを使うのでテスト実行が遅かったり不安定だったりします。そのため、その他のmodelやcontrollerのテストとは別に制御できるようにして、不要なときはskipするなりしたいです。 ここでは、tagを使って制御しましょう。ただ、よくあるメソッドごとに @tag をつけるのでは煩雑になるいっぽうなので、 integration_case.ex なんかを作って、それを読み込んだ全てのモジュールに対して勝手にtagがつくようなやり方です。 tagを付与する support/integration_case.ex にtagを設定する 以下のようにヘルパーを作ってあげると、 use MyApp.IntegrationCase したモジュールは自動的に @moduletag :integration のtagが付与されます。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than…More
とてか04で多くのものを拾ってきた
とてか04とは 『とちぎテストの会議04』が正式名称。 toRubyを主催している方々が、主に”テスト”に関わる何かを主において開くイベントです。 その中で、今回は以下の通り「つくるいとなむ」を主なタイトルとして開かれました。 http://d.hatena.ne.jp/tochigitestnokaigi/20160423 私 私は以下のようにLTの1番目として発表いたしました。 これ自体は私の普段の学び方だったり、その中で特に業務に活かすために特に疑問に感じていたことをお話し致しました。 「チョットデキル人に訊け！」ででた”テストをうまくなるには？” こちら、何が自分、ひいては周りの向上を誘うか、ですよね。私も考えてみたのですが、やっぱり以下のようにやりたいことベースでいろいろ学ぶなーと感じました。それ以外だと、業務上だったり一時の知的好奇心から、というのはちらほら。 うまくなるには、みたいな話、私なりに考えてみると結局はやりたいことあるからベースが一番強そうです。 #toteka — KazuCocoa (@Kazu_cocoa) April 25, 2016 これ以外だと、何か興味を持っていることの周辺でテストに絡めて学ぶ、というのが面白いのでないですかね。 拾ってきたもの 多くの方々とのつながり。 とてか03で初めて足を運んだとてか。そこから1年後の2回目。前回よりもいろいろな人と話をしましたし、つながりもできました。これは私にとってとても良いつながりだと感じます。ありがとうございました。More
[Elixir]Ecto2.0-beta2のownership周りのコードを追う
Ectoが2.0(beta)になって、concurrent acceptance testingができるようになったのでいくつか調べてみた。 参考にした元記事は以下。 Concurrent Acceptance Testing in Elixir この中で、Ectoのownershipのところが気になったのでいくつかコードを追ってみました。 Ownweshipを取得する時、 Ecto.Adapters.SQL.Sandbox.checkout/2 が呼ばれます。 これはEcto2.0で必要になったところですね。 https://github.com/elixir-lang/ecto/blob/v2.0.0-beta.1/lib/ecto/adapters/sql/sandbox.ex#L281 ここの中で、もしsandboxであれば にあるように、ownership_poolのキーを持つDBConnectionのプロセスをとってきます。 これは、以下のdb_connectionのコードを呼びます。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership.ex#L47 この中で case されるのは以下。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership/manager.ex#L19 この DBConnection.Ownership.Manager はGenServerになってて、その自身に対して call します。 :checkout が call されるところを探すと、以下がみつかります。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership/manager.ex#L149 ここで、DBに対して処理を行うプロセスがcheckoutされていない場合、以下のprivateメソッドが呼ばれます。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership/manager.ex#L174 こう見ると、この段階でetsに対してcheckoutした、ということを保存するのですね。なるほど。 もう1つ。以下の通り allow されることがconcurrentlyにテストを実行する上では必要です。 これは、以下の通りドキュメントに書かれています。 https://hexdocs.pm/ecto/2.0.0-beta.1/Ecto.Adapters.SQL.Sandbox.html Summing up – Using allowances – requires explicit allowances via allow/3. Tests may run concurrently.…More
RedwoodHQ on Mac
http://qiita.com/ootaken/items/e6e85e7b91cb98b2e294 で知ったのですが、RedwoodHQというOSSのtest automation frameworkというものがあるらしいですね。 https://github.com/dmolchanenko/RedwoodHQ Webページを見るとどうやらサーバの動作環境のメインはWindows環境。 ただ、githubを見る限りはJavaとNodeぽいのでmacでもちゃんと動くだろうと思って動かしてみました。 必要だったこと。 mongodbをインストールする それ以外は、基本的に git clone する top directory で npm install する mongod を起動した上で、 node app.js agent配下で npm install node app.js (in agent) これで、 http://localhost:3000 でサーバ http://localhost:5009 でAgent にアクセス可能になります。 ただ、私の環境ではAgentへのアクセスの時にサーバからの応答はあるのですがページが表示されなかったので(not foundが返ってくる)、うまく動いていない部分があるのかもしれないです。そこらへんは少し見てみないといけなさそうでした… https://t.co/gdIFQkRmjF にあるRedwoodHQ、nodeなのでやればフルでMacやLinux上で動作させることできそう。私はAgentがイマイチできていない。ちなみにDBはmongodb使っている模様。 — KazuCocoa (@Kazu_cocoa) February 24, 2016More
~ my tech diary ~ 