モデル ベース テストで使用した戦略は何ですか?
- 統合テスト専用に使用しますか、それとも他の領域 (ユニット/機能/システム/仕様検証) に拡張しますか?
- 焦点を絞った「封印された」モデルを構築しますか、それとも複雑なオニバス モデルを徐々に進化させますか?
- 製品サイクルのどの時点で MBT の作成に投資しますか?
- MBT 専用に作成するベース テスト ライブラリはどのようなものですか?
MBT をより適切にサポートするために、機能ベースのテスト ライブラリにどのような違いを加えていますか?
モデル ベース テストで使用した戦略は何ですか?
MBT をより適切にサポートするために、機能ベースのテスト ライブラリにどのような違いを加えていますか?
[これについて読む価値のあるエッセイがいくつかあります。Stack Overflowでは複数の投稿を許可されないため、この回答の最後にリンクされているブログ投稿にそれらを集約しました。]
まず、用語について簡単に説明します。私は、ジェームズ・バッハのテストの定義を「製品を評価するために質問する」と使用する傾向があります。すべてのテストは、テスト対象のアプリケーションの/mental/モデルに依存しています。ただし、モデルベーステストという用語は、通常、自動化によって調査できるモデルのプログラミングを説明するために使用されます。たとえば、アプリケーションが存在できる状態の数、それらの状態間のさまざまなパス、およびそれらの状態間の遷移で何が発生するかについての特定のアサーションを指定できます。次に、スクリプトに状態モデル内の遷移の半ランダム順列を実行させ、潜在的に興味深い結果をログに記録させることができます。
ここには実際のコストがあります。有用なモデルの構築、モデルを探索するためのアルゴリズムの作成、興味深い障害を取り除くためのロギングシステムなどです。コストが妥当かどうかは、必要な質問と関係があります。答える?一般的に、「何を知りたいですか?そして、どうすればそれについて最もよく学ぶことができますか?」面白いテクニックの使い方を探すのではなく。
とはいえ、一部の優れたテスターは、自動化されたモデルベースのテストから多くのマイレージを獲得しています。自動化された大量のセミランダム化テストによって最もよく調査される、テスト対象のアプリケーションに関する重要な質問がある場合があります。ハリーロビンソン(モデルベーステストの主要な理論家および支持者の1人)は、モデルベーステスト(ルビーのワティルライブラリで作成)を使用して、Googleの運転方向に多くの興味深いバグを発見した非常にカラフルな例を説明しています。1
ロビンソンは、ベル研究所、マイクロソフト、グーグルなどの企業でMBTをうまく利用しており、役立つエッセイを数多く持っています。[2]
Ben Simo(もう1人の優れたテスト思想家およびライター)も、モデルベースのテストについて読む価値のあるものをかなり書いています。[3]
最後に、いくつかの注意点があります。戦略をうまく活用するには、その長所と短所の両方を調査する必要があります。そのために、James Bachは、モデルベーステストの限界と課題について優れた講演を行っています。バッハの1時間にわたる講演(および関連するスライド)へのリンクに関するこのブログ投稿。[4]
最後に、BorisBeizerが農薬パラドックスと呼んでいるものについてのメモで締めくくります。「バグを防止または発見するために使用するすべての方法は、それらの方法が効果的でない微妙なバグの残りを残します。」スクリプト化されたテスト(コンピューターまたは人によって実行されるかどうか)は、農薬のパラドックスに対して特に脆弱であり、同じスクリプトが実行されるたびに有用性の低い情報を見つける傾向があります。農薬の問題を回避できると考えて、モデルベースのテストに目を向けることがあります。状況によっては、モデルベースのテストで、特定のスクリプトテストのセットよりもはるかに大きなバグのセットが見つかる場合がありますが、農薬のパラドックスによって根本的に制限されていることを覚えておく必要があります。その限界を思い出し、MBTがうまく対処する質問から始めて、それは非常に強力なテスト戦略になる可能性があります。
上記のすべてのエッセイへのリンクはここで見つけることができます:http://testingjeff.wordpress.com/2009/06/03/question-about-model-based-testing/
MBTブックの著者であり、たとえばGoogleやMicrosoftで多くの作業を行ったハリー・ロビンソンは、このサイトにいくつかの優れた情報とホワイトペーパーを掲載しています。
私たちはI&Tをほとんど行っておらず、ユニットテストをほぼ独占的に使用しており、少しのシステムテストで経験を積んでいます。しかし、私たちの焦点は明らかにユニットテストにあります。私は私たちが構築/提供するAPIにかなり厳格なので、それが単独で機能する場合、それは連携して機能し、まだそれほど間違っていないことを前提としています。
私たちのモデルは、依存関係をできるだけ少なくした単一の目的/モジュールに焦点を合わせています。
焦点は常にできるだけ早く開始することです(TDD-ちょっと)が、残念ながら私たちは常にそれに到達するとは限りません。問題は、常にそれを経営陣に売らなければならないことです。テストによって安定性が向上する一方で(全体的なQA)、外部(技術者以外)の人々は、何か悪いことが起こるまで、それが何を意味するのかを実際に知ることができないためです。
PHPを使用しているため、単体テストにはPHPUnitを使用します。全体として、さまざまなツールを使用してCIを実行します。:)
最善の方法は、モデル ベースのテスト ツールを自分で試すことです。モデルベースのテストがあなたのコンテキストに適応しているかどうかを知るための最良の方法です. そして、どのような戦略が良い戦略なのか。
All4Tec (www.all4tec.net) の「MaTeLo」ツールをお勧めします。
「MaTeLo は、ブラック ボックスの機能およびシステム テスト用のテスト ケース ジェネレーターです。モデル ベースのテスト アプローチに準拠し、MaTeLo はマルコフ連鎖を使用してテストをモデル化します。この統計アドインにより、体系的な方法で製品を検証できます。効率は、削減によって達成されます。必要な人的資源の削減、モデルの再利用の増加、およびテスト戦略の関連性の強化 (信頼性の目標による) MaTeLo は独立しており、ユーザーフレンドリーであり、テストスクリプトから実際のテストに移行するための検証活動を提供します。エンジニアリングと、テストの真の付加価値であるテスト計画に焦点を当てること」
評価ライセンスを要求して、自分で試すことができます。
ここでいくつかの例を見つけることができます: http://www.all4tec.net/wiki/index.php?title=Tutorials