10 返信 最新の回答 日時: Feb 27, 2012 11:18 PM ユーザー:honda

    FileMaker開発におけるテストの自動化について

    honda

      本田と申します。

       

      FileMaker開発において必要な各種テストを、自動化し継続的に適用する方法を模索しています。

      具体的には、いわゆるユニットテストと呼ばれるテストを、

      スクリプト、レイアウト、カスタム関数などの設計対象に対して行う事を想定しています。

       

      FileMakerは柔軟な変更が可能なため、不用意な変更も発生し易いです。

      しかし自動的なテストを適用する方法が用意されておらず、

      影響無し確認のテストによる負荷が非常に大きいです。

      それは工数の不要な増加の原因にもなっていると思います。

       

      カスタム関数だけでもと思い試みていますが、

      コードカバレッジなど得ようの無いものも多く、非常にもの足りません。

      filemaker-kou.seesaa.net/article/234005496.html

       

      TDDという程でないにせよ、継続的なテストはとても有用であり、

      それがカスタム関数の他にも適用できれば、開発効率は大きく向上します。

      テストデータの渡し方など、FileMakerの構造上多くの問題がありますが、

      何か自動テストの工夫や試みをされている方がいらっしゃいませんでしょうか。

        • 1. Re: FileMaker開発におけるテストの自動化について
          sago350@未来Switch

          少し違うアプローチなのですが、全レイアウトのスクリーンショットを自動的に撮るツールを作ろうと試みたことがあります。

          スクリーンショットを印刷して、テスターに全てのボタンやフィールドを赤ペンでチェックして貰えたらつまらないバグは防げるかなと。

           

          AppleScriptで考えたんですが、挫折しました・・・。

          • 2. Re: FileMaker開発におけるテストの自動化について
            honda

            反応ありがとうございます。

             

            昔ややこしい帳票の影響無し確認で、画像比較はやりましたね。

            たしか対象レコードが数万件あったので、スクリプトでレコード移動しながら、

            スクリーンショットをキャプチャから自動でファイル化するツールを使ったと思います。

            変更の前後で保存した画像を、ビットマップで差分確認して、

            両者に差が無ければ合格、という感じの処理でした。

            単発の検証だったので、あの時はPhotoshopのスクリプトで差分作成しましたが、

            自動化だったら、ImageMagickのdifferenceとかに吐き出させますかね。

             

            可能性として面白いと思うんですが、ネックは、

            テスト全体を制御する自動化フローの書きにくさでしょうか。

            FileMakerとキャプチャ動作を行き来しながら、

            差分書き出しのツールを呼び出したりがあるのに、

            その流れの中でFileMakerをスマートに扱えない。

            AppleScriptでも挫折するってことは、かなり難しいですよね……。

            • 3. Re: FileMaker開発におけるテストの自動化について
              sago350@未来Switch

              ちょっと作ってみました。

              AppleScriptを使っているのでMac限定ですが、全レイアウトのスクリーンショットを撮ってくれます。

              ただ、ウィンドウだけ撮る方法が解らずデスクトップ全体を撮ってしまいます。誰か教えてくれないかしら。

              • 4. Re: FileMaker開発におけるテストの自動化について
                honda

                中身拝見しました。

                スクリプトの書き方なんかも含めて、とても参考になります。

                 

                今Mac環境が手元に無いので動かせてないんですが、面白そうです。

                WindowsだとEvent送信でbatなり叩いて、

                そちらでウインドウ位置やサイズの調整と、

                スクリーンショットツールの操作させれば同様の事可能ですね。

                 

                問題は、このテストをどういう目的で行うかです。

                単純なレイアウトの誤変更などを検出するだけなら、

                DDRからXML出してdiffで済みますから、

                画像ベースで検証するのって、データ込で人の目で確認する場合ですよね。

                そうなると、その確認時に用いるテストデータなどは、

                どうしても泥臭い人手を伴って用意する必要があるんじゃないかと思います。

                 

                現在進行中の案件で、スクリプトの構造的な分割指針を探ってますが、

                レイアウトの存在がネックで、中々綺麗なユニットになりません。

                データの用意もそうですが、ちょっと進むと行き止まりな感じです。

                • 5. Re: FileMaker開発におけるテストの自動化について
                  sago350@未来Switch

                  実はhondaさんの「テストの自動化」というお題から外れてまして、撮ったスクリーンショットを印刷して新人に渡すことを想定しています。

                  紙に対して赤ペンで一つ一つタブ順やらIMEやらボタンやらの動作をチェックしていってもらおうかなと。泥臭いですね・・・。

                  • 6. Re: FileMaker開発におけるテストの自動化について
                    honda

                    なるほど、そういう用途なら一括キャプチャは便利ですね。

                    でも仰るように泥臭さは伴うんで、新人のチェック用というよりは、

                    視覚的にレイアウトを総ざらいして確認したい、

                    引き継ぎ直後とか、久々に取り組む場合や大規模改修前に使えます。

                    次そういう案件あったら、Macでこのスクリプト使って書きだしてみますね。

                    • 7. Re: FileMaker開発におけるテストの自動化について
                      yuhei.mukoyama

                      亀レス失礼します。

                       

                      FileMaker 以外の開発をあまり行ったことがないので、「テスト」という単語の指す具体的な処理が分からないのですが、読んだ限りで思ったことを書かせて頂きます。

                       

                      スクリプトに関してだけ言いますと、部分的には可能だと思います。

                      ある DB A から、別の DB B へ値を加工して書込む様な処理の場合。

                      スクリプトA に、DB A 値を変数化する処理を書きます。その変数達を、スクリプトBに渡し、スクリプトBでは値を加工します。

                      その後、スクリプト結果で変数をスクリプトAで受け取り、スクリプトAは帰ってきた値を DB B 書込む。

                       

                      こういった、スクリプトの書き方をすれば、スクリプトBは変数を受け取り、変数を返すだけのスクリプトになりますので、スクリプトBのテストは走らせることが出来るかと思います。

                       

                      --

                       

                      また、これは別の話ですが勝手に書き換えられていないのかを監視する方法としては、FileMaker Serverのバックアップ機能を使い 定期的にクローン(データ無しのファイル)を作ることが出来るので、それを利用して、FileMakerファイルのXMLを監視し、差違を見つけてメールで報告するような物は作れると思います。ただ、これは今考えついた方法なので、実際どうなるのかは分かりませんがw

                       

                      --

                       

                      最後に、hondaがおっしゃるテストというのが具体的にどういった内容なのかもし良かったら教えて頂けませんでしょうか。テストに関しては試行錯誤しながら今行っている段階なので、是非参考にさせて頂ければと思っております。

                      • 8. Re: FileMaker開発におけるテストの自動化について
                        honda

                        yuhei.mukoyama、はじめまして。お返事遅れました。

                         

                        私がはじめに想定した「テスト」は、一般的にユニットテストと呼ばれるものです。

                        ソフトウェアテストはそれだけで大きな分野で、私も卑しくつまみ食いをしているだけですが、

                        プログラミング言語を用いてシステムを構成するような場合、

                        ユニットテストはかなり当たり前になってきていると思います。

                         

                        単体で動作し検証可能なユニットの集合としてシステムを設計し、

                        個々のユニットが充分なテストを受けていると、色々な利点があります。

                        そして重要なのは、それらのテストが自動的に実行できる事です。

                         

                        まだ何も作らない内にテストを作って自動実行し、満たすべき実装をエラーからも得る。

                        何か変更を加えたら、テストを自動実行し、結果に問題が無いか把握できる。

                        仕様が変われば、テスト条件を変更し、自動実行し、出てきた仕様との不一致を潰す。

                         

                        もちろんユニットテストだけがテストではありませんが、

                        自動化されたユニットテストは特に開発する側にとって、心地良いと思います。

                        そのような自動化されたユニットテストを、幾らかでもFileMakerで実現できないか、

                        そういう趣旨でこの話題を投稿しました。

                         

                        -

                         

                        FileMakerでのユニットテストを阻むのは、

                        そもそもテストしたい各要素が単体で機能せず、

                        また各要素に一律の手法でのアクセスが提供されていないからです。

                         

                        仰るように、スクリプトは引数と結果の導入によって、単体で動作可能です。

                        但しそれが実用的に使えるのは、単純な値の受け渡しを行うスクリプトだけだと思います。

                        レイアウトの切り替えや、検索やソート、フィールド設定など、

                        その外との関連を前提としたスクリプトでは、単体になりえません。

                        一般的なプログラミング言語用のユニットテストフレームワークでは、

                        ユニットに渡すテスト用の入力は柔軟で、それはユニットもテストも入力も、

                        同じくコードベースで抽象化されているからです。

                         

                        FileMakerではテストしたい各要素が中途半端に依存し合う上、

                        全てに一律の方法でアクセスできる抽象化された層がありません。

                        結局、引数と結果で受け渡し可能な値の加工を行うだけのスクリプト

                        (その多くはカスタム関数で代用できる筈)や、

                        カスタム関数ぐらいにしか、ユニットとしてのテストが行えません。

                         

                        万が一、次のバージョンのFileMakerで、PythonやJavaScriptなど、

                        アプリケーション向けに採用されやすい言語が組み込まれたとします。

                        そして、テーブル、レイアウト、スクリプト、フィールド定義内の計算式、

                        Webビューア、ポータル、条件付き書式などなど、

                        FileMakerでの開発に必要な要素が全て単一の言語で扱えるよう、

                        充分に練られた抽象化を施され、まともなドキュメント付きで提供されたとします。

                        そうすれば、テーブルやリレーションシップはともかく、

                        仕様と実装の間のギャップが大きい、レイアウトや各種計算式、スクリプトは、

                        同一の方法をベースに自動的なテストが可能になります。

                        上述の言語であれば各要素がクラスやオブジェクトとして提供され、

                        「レイアウトが指定のレイアウトオブジェクトを含むかチェック」、

                        「テスト用の仮想テーブルを入力にスクリプトを実行し結果セットをチェック」、

                        「フィールドオブジェクトの入力制限をまとめてチェック」

                        といったテストも行えます。

                         

                        でも、そういった作りは非常にFileMaker的ではない上、

                        膨大な開発コストがかかりますから、まず望みはありません。

                        その上でなお、現状のFileMakerの範囲内で、少しでも楽に開発が進められないか、

                        少しでも納品時に「テスト足りてないよなあ、これ…」って不安を減らせないか、

                        高いと言われ見積からテスト工数分を削減されずに済まないか、と考えています。

                         

                        -

                         

                        カンファレンスなどでFileMaker関連の開発企業の方にお訊きしたり、

                        海外の情報を漁ってみたりしてみましたが、

                        FileMakerではテスト手法についての話題がほとんど見つからない状況です。

                        大きな開発会社はテストの負担も大きい筈なので、

                        もうちょっと情報が出てきてもいいのにと思います。

                         

                        ちなみに、私が通常FileMaker案件でやってるテストは、

                        カスタム関数のユニットテスト以外、ほとんど機能テストばかりです。

                        FileMakerで作ったテストソリューションをランタイム化し、

                        機能テストのケースを書き連ね、ひとつずつ手作業で潰しています。

                        嫌気が差しますし、自分テストは危険ですが、テスターもいないので我慢しています。

                        • 9. Re: FileMaker開発におけるテストの自動化について
                          sago350@未来Switch

                          FileMakerのテスト手法について、興味があります。

                          hondaさんの指摘しているFileMakerの仕様的な問題で、一般的なシステム開発のテスト手法が当てはめにくいとは私も感じています。

                          FileMaker的なテスト手法について、ここで整理できないですかね。

                          手法ごとにスレッドを分けていくとか・・・。

                          • 10. Re: FileMaker開発におけるテストの自動化について
                            honda

                            無茶苦茶放置しててごめんなさい。

                             

                            テストって切り口では英語でもあんまり情報の無いようですし、一覧するだけでもありがたいです。ソフトウェア工学もテストエンジニアリングもど素人なので、テストって文字列で凄い人が引っかかってくれるかも、という期待もあります。

                             

                            取り敢えず、FileMakerに関する「テスト」と名のつく何かから、実践してたり、思い付いたものを並べてみます。

                             

                            ・カスタム関数のユニットテスト

                            ・なんとなく動いてるよねテスト

                            ・テストケース手元にひたすら手動で色んなテスト

                            ・DDRXMLのdiffでリグレッションテスト

                            ・スクリプトで負荷テスト

                            ・JMeterでWeb経由の負荷テスト

                            ・GUI操作の自動化ツールで色々テスト(負荷とか衝突とか)

                             

                            なんかもっと色んな事やってる気がしますが、「手動で色んなテスト」に集約されちゃってて、思い出せません。他の方がどんなテストしてるのか見えると、もっと思い出すかもしれません。

                             

                            もしもうちょっと集まったら、以下の記事なんか参考にして、分類して、現行のFileMakerでもまともに扱える定形なんか見えてくると良いですね。

                             

                            ソフトウェアテスト基本テクニック:第1回 ソフトウェアテストを分類する|gihyo.jp … 技術評論社

                            http://gihyo.jp/dev/serial/01/tech_station/0001