前回の続きです。
7.2 品質属性から見た自動化フレームワーク
カテゴリー4で学んだフレームワークを、8つの品質属性の得手・不得手で整理しているのがこの章です。
・・・正直、あまり見やすい表じゃない。横軸を品質属性にして、整理してみようかなと。もちろんExcelでね。
レベル1フレームワーク
リニア・フレームワークは、スコープの小さい限られた条件では、ユーザビリティ・性能面で長所があるとされています。
レベルが上がるとともに、スクリプト作りは簡単に、フレームワーク作りは大変になることを考えると、少ししか自動化しないならレベル1の方が楽なんですよね。
レベルが上がるとともに、スクリプト作りは簡単に、フレームワーク作りは大変になることを考えると、少ししか自動化しないならレベル1の方が楽なんですよね。
レベル2フレームワーク
データ駆動フレームワークも、基本的にはリニアとあまり変わりません。データ外出しによって、拡張性が向上する程度。
機能分解フレームワークは、TABOKが「手始めに選ぶならコレ！」と何度も一押ししてくるフレームワーク。ほとんどの品質属性でいい点を取れます。ただし、4.2.3で説明があったように、部品を作るための基準があって、それがちゃんと守られていないと、ユーザビリティが不十分になります。
レベル3フレームワーク
キーワード駆動フレームワークの長所・短所は機能分解とほぼ同様ですが、（テストを作るうえでの）ユーザビリティに大きなメリットがあります。ただし、フレームワーク自体の構築はいちばん大変。
ぼくが読んでいて理解できなかったのは、性能面で弱さがあるという記述です。何故？自然言語からスクリプトに読み替えるのに、他のフレームワークにはないオーバーヘッドがあるということでしょうか。
ぼくが読んでいて理解できなかったのは、性能面で弱さがあるという記述です。何故？自然言語からスクリプトに読み替えるのに、他のフレームワークにはないオーバーヘッドがあるということでしょうか。
モデルベースは、この系列には乗りません。他のフレームワークを補完する位置づけです。
なおここでも、「テスト自動化の目的が、exploratory testing の自動化にあるのなら・・・」という記述があります。以下の記事でも言及しましたが、やはり「exploratory testing」の意味が、いわゆる「探索的テスト」とは違うように思います。
なおここでも、「テスト自動化の目的が、exploratory testing の自動化にあるのなら・・・」という記述があります。以下の記事でも言及しましたが、やはり「exploratory testing」の意味が、いわゆる「探索的テスト」とは違うように思います。
7.3 キー属性の特定と、フレームワークの選択
組織やプロジェクトの制約に応じて、どのフレームワークの選ぶかの説明です。ここで出てくるのは、4.1に出てきた謎のドレイク方程式。
この式のパラメタに具体的な値を与えたうえで、8つの品質属性の優先度がどのようになるかをシミュレーションしています。
結論は、TABOKにおいて例外的にボールドで書かれており、「機能分解がオススメだぜ！」。
さてこれで、macroscopicに属する7つのカテゴリーは終わり。後半のmicroscopicの5カテゴリーに移ります。読んで理解できるのか心配ですが、続けます。みなさんTABOKを買って読んで、コメントください。
