質問

ソフトウェアテスト自動化に関する論文を書こうとしています。テスト スクリプトの記録とプログラミングの 2 つのアプローチを比較し、Abbot、Selenium、Yemmy、FEST などのいくつかの自動化フレームワークについて説明する予定です。また、私の論文では、ソフトウェアテスト技術についての短い概要と、おそらく自動テストとソフトウェアテストの比較も行う予定です。

編集:GUI を介してアプリケーションをテストすることを計画しています。したがって、私のテストは主にテスト世界のブラックボックス側にあることになります。単体テストについて書く予定はありません。

現時点では、さまざまな自動化フレームワークについてかなり読んでいますが、すべてを確認する時間がないかもしれません。そこで私はそれらについて読んで、より文学に基づいた論文を作成するつもりです。

  • このトピックは成功すると思いますか?
  • このトピックに関して他にアイデアはありますか?
  • お勧めの文学を教えてください。
  • このトピックについてあなたの意見は何ですか?
役に立ちましたか?

解決

修士論文では文献調査に重点を置く必要があります。ブラックボックス GUI を活用した顧客対応ツールについてだけ話したいようですが、これはかなり狭い分野です。

上で誰かが言及したように、単体テスト、セキュリティ、負荷など、テスト ツールの全世界について 1 ~ 2 ページを用意したいと思うかもしれません。しかし、自分のニッチをかなりうまくターゲットにしていると思います。

6 単位の論文の場合は、文献を調査するだけでなく、より大きな商用ツールやオープンソース ツールを探索して試してみるのに十分な時間が必要だと思います。商用ツール (クイック テスト プロ、テスト コンプリート) と、キーワード駆動の自動化 (たとえば、Selenium RC など) の両方を検討することをお勧めします。他の誰かが「GUI の背後で」テスト (例: FIT/Fitnesse) について言及しましたが、それは議論して評価する価値があるかもしれません。

私は、ソフトウェア テストとパフォーマンス マガジンの 2008 年 12 月号の月刊コラムで、ブラックボックスの機能テストの自動化について取り上げています。

http://www.stpmag.com/issues/stp-2008-12.pdf (7ページ)

以上が 1 ページの表面的な紹介です。5 文で紹介するのは、画面記録/再生ツールはすべてを比較するため、GUI が何らかの方法で変更されると (画面解像度を変更しただけでも)、誤ったエラーとして返される可能性があるということです。キーワード駆動ツールは、チェックするように指示されたものだけをチェックします。正当な理由もなくボタンが突然無効になったり、アイコンが透明でなかったりすると、ツールは見逃してしまいます。

すべてのテスト ケースの最後に隠されたアサーションをチェックできるのは人間だけです。」他に何も奇妙なことは起こりませんでした。」

したがって、コンピューターベースのテストの実行と評価にはある程度の価値がありますが、バランスの取れた朝食の一部である必要があります。

その他の検討事項:

  • James Bach 氏の「ソフトウェア テスト自動化スネーク オイル」
  • カーナー、バッハ、ペティコードの著書「ソフトウェア テストで学んだ教訓」
  • テスト フレームワークに関する私のブログ投稿 -http://xndev.blogspot.com/2007/09/whats-test-framework.html (これは「テスト フレームワークとは」の Google 検索結果で 4 位なので、安心してお勧めできます)
  • 地雷原のたとえ( http://www.testingperspective.com/tpwiki/doku.php?id=minefield )
  • テスト自動化に関する Doug Hoffman の論文:http://www.softwarequalitymethods.com/H-Papers.html
  • テスト自動化の古典的な「シェルフウェア」問題
  • ブラックボックステスト自動化コミュニティの一部の支持者によって推進される反知性主義
  • Kaner のブラック ボックス ソフトウェア テスト コース
  • James Bach の /認知/テストに関する研究
  • コンテキスト駆動型ソフトウェアテスト
  • Jon Kohl の「Man and Machine」に関する研究、またはサイボーグ アプローチ (コンピューター単独でのテストの実行と評価の代わり)

それが役立つことを願っています。

他のヒント

ソフトウェア テストの自動化は大きなトピックであるため、さまざまなフレームワーク、再生/記録、技術の概要、自動化と自動化の組み合わせをカバーしようとするのではなく、焦点を絞り込むことをお勧めします。ない。

ソフトウェア テストの自動化については、書籍全体が書かれています。

  • 一般的な話題として
  • 機能/機能テスト(FIT)に重点を置く
  • 単体テストに重点を置く
  • 特定の言語とフレームワークを使用した単体テストに焦点を当てる

フレームワークは、さまざまな種類のテストを目的としています。

  • 単体テスト
    • テスト駆動開発
    • 行動主導型開発
  • 機能/機能テスト
  • GUI テスト (Windows、Java GUI、X Windows など)
  • Webテスト
  • 性能試験
  • セキュリティテスト

すべてをカバーしようとするのではなく、これらの領域の 1 つのフレームワーク (またはテクニックなど) に焦点を当てることを検討します。または、これらの領域をいくつか選択して、それらを対比させます。

再生/録音の問題手書きのテストは私には古いように思えます。1980 年代、ベンダーは Windows GUI オートメーションの再生/録音を推進することを好みました。それは素晴らしいデモと大きな期待をもたらしました。しかし、それは脆性試験や棚用品にも役立ちました。再生/記録はツールを使い始めるには便利ですが、保守しやすくするには、通常、より高いレベルで書かれたスクリプトが必要です。これにより、スプレッドシートとキーワードベースのアプローチ、そして最終的には FIT/FitNesse の新時代が到来しました。

私は文学のことは知らないが、私はあなたの学校の図書館でのACMの出版物は、おそらく結果を生むだろうと思います。 href="http://portal.acm.org/browse_dl.cfm?linked=1&part=sig&coll=portal&dl=ACM" rel="nofollow noreferrer"> SIG *ニュースレターを特に SIGSOFT の? )

これは、私に良い修士論文のように聞こえるん。もちろん、あなたの論文の顧問は、その上の最後の言葉です。あなたは彼らに話をしに行く必要があります。

文学ベースのレビューのように、これは優れたトピックになります。材料の多くはそこにあります。それは著者としてあなたの仕事ですので、もちろん、私は、それのすべての詳細に入るために開始するつもりはありません。 : - )

私は修士論文のための独創的な研究の要件に精通していないんだけれども、

しかし、これは確かに博士論文のために十分ではないであろう。私はあなたがこれに追加することができ、元の仕事を探します。ひとつのアイデアは、テスト方法およびシステムの分類になります。また、フォーマル検証と比較して、テストの役割を調べることがあります。

私はそれがオンラインで入手可能かどう論文を読んで興味があると思います。 Webおよびアプリケーションの両方 - GUIへのプログラムによるアクセスを考慮に値します。その後、セレンまたはワチールなどの記録および再生ツールがあります。自動化のそしてもちろんの長所と短所 - ツールの制限(ほとんどたとえば、Webページ上のJavaアプレットやフラッシュに見ることができない)と自動化する際に、一部の人々は忘れて、最も重要なこと - は、すべて / <べきem>の自動化すること!

しかし、あなたはそれを行うの時に私達を知らせるために、この上でコメントすることは可能で、すべての場合、私は純粋に読み取りたいと思います。

テストの自動化に優れた本は、ちょうどこの年に公開されています。、Elfriedeダスティン、トム・ギャレット&バーニーGauf、「自動テストの実装を」アディソンウェズリー

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top